Internship musma 회고

💌 회사에 대한 첫 인상

회사는 입구부터 시작해서 사무실까지 굉장히 깔끔했다. 자리를 배치받았을 때 깔끔했던 사무실과 책상을 잊지 못한다.

다음에 들어올 사람도 이런 좋은 분위기를 느끼면 좋겠어서.. 인턴십 마무리 후에 내 자리를 깔끔하게 청소하고 나왔다.

💬 회사의 서비스

자리 셋팅을 마치고 토니님께 회사의 소개에 대해 오리엔테이션을 받았다.

 

musma는 IoT 기술로 건설 현장에서 안전과 자산을 관리하는 플랫폼을 서비스 하고 있다.

센서를 통해 정보를 수집하여 충돌 위험을 알린다던지, 안전사고를 예방하는 서비스이다.

 

나는 비록 건설현장에서 일하던 현장 작업자는 아니었지만, 공장에서 일하던 현장 작업자였기 때문에, 안전이 얼마나 중요한지 몸소 깨닫고 있다. 또한 대학생 때, 아버지가 일하던 공사 현장도 많이 갔었다. 안전 사고를 예방하는 것이 얼마나 중요한지 알고 있기 때문에, musma는 정말 가치 있는 서비스를 하고 있구나 라고 생각했다.

 

이 링크는 musma의 서비스에 대한 소개하는 페이지이다. 관심이 있다면 보는 것이 어떨까?

https://musma.net/solution-safety/

❓ 건네받은 기능 명세서와 혼란스러운 우리들

약 4주 간의 시간과 함께 우리가 만들어야할 서비스에 대한 기능 명세서를 받았다. 기능 명세서를 받은 후에는 나 포함해서 4명 모두 정적이었다. 어떻게 기획해야할지 감이 잡히지 않아서, 회사가 서비스하고 있는 플랫폼을 분석했다.

 

🤣  하지만 너무 많이 들여다봤는지 회사의 서비스와 거의 비슷하게 기획했다.

 

기획하면서 많은 어려움을 겪었는데,

 

첫 번째는 도메인의 용어였다.

센서와 디바이스, 장비, 중장비, 장비 관리자, 장비 담당자 이런 용어들이 혼잡하게 기능 명세서에 난재해있었고, 그런 용어를 잘 모르다보니, 의문점이 투성이인 기획서가 탄생하고야 말았다.

 

두 번째는 미팅이 끝나면 미팅에 참가한 인원 모두 다른 생각을 하고 있다는 점이었다.

한명은 나무 의자를 생각하고, 또 다른 한명은 철제 의자, 그리고 또 다른 한명은 호화스러운 의자.. 이렇게 생각한다는 점이다. 프론트 앤드인 나와 자네님은 미팅이 끝나면 야근을 하며, 스토리 보드를 만들었었는데, 서로 이해한 내용이 달랐던 것이었다.

 

세 번째는 시간이라는 리소스를 너무 간과했다. 우리의 서비스 제작기간은 4주이다.

musma에서 우리의 서비스를 담당하고 있는 사이먼님과 매일 아침에 애자일한 회의를 하는데, 사이먼님께 우리의 내용이 맞는지 검증을 하고 확정을 받았어야 하지 않았나 싶다. 우리끼리 이 내용이 맞을까? 안맞을까 하고 많은 의견을 나누는 것도 좋지만, 시간이라는 리소스는 한정되어 있기 때문에, 가설을 많이 세웠다면 애자일 회의때 검증을 받고, 확정을 지었어야 했다.

⚠️ ➡️ ✌️회사의 Templete으로 초기세팅을 하다

기획이 어느정도 마무리되어, 확정지은 날이었다. 이제 프론트앤드 끼리 초기세팅을 해야했다. 프론트 앤드의 초기세팅은 악명 높다. 맥북이나 윈도우에 따라 어려울 수도 있고, 새로운 기술스택이 있다면 그에 대한 셋팅도 따로 해야하기 때문이다.

 

초기세팅을 하기 전에 나는 진짜 혹시나하고 musma의 React-templete이 있는지 찾아보았고 역시 존재하고 있었다. 회사의 컨벤션을 맞추기 위해 분명히 만들어뒀을 것 같은 느낌이 들었기 때문이다. 약간의 해프닝은 있었지만 덕분에 초기세팅은 1시간 내외로 종료되었다. 있는지 모르고 진행했다면 정말 고생했을 것이다.

 

회사의 Templete에서 배운, 앞으로 진행할 프로젝트에 적용하고 싶은 점

• Import 순서가 정해져있어서 이전에 진행해왔던 프로젝트와는 달리 깔끔해진다.
• Vite에 대해 학습하고, 적용해보아야겠다.
• 더 최적화된 React-templete을 만들어두고 싶다. ( 현재는 정말 기초적인 templete를 만들어서 사용하고 있다 )

👍 점차 내 마음 속으로 스며들은 TailwindCSS

이전에는 SCSS, Styled-components를 사용해왔기 때문에, 새로운 CSS 라이브러리를 사용하는 것에 대해 두려움과 걱정이 앞섰지만, 점차 내 마음 속으로 스며들어 넘버원이 되었다.

 

내가 느낀 TailwindCSS의 장점은 다음과 같다.

1. SCSS나 Styled-components와는 다르게 클래스 이름, 컴포넌트의 이름을 짓는 고민을 할 시간이 필요가 없다. ⇒ 개발자들의 숙명.. 이름 짓기에서 많이 벗어날 수 있게 해준다.
2. 앞서 말한 라이브러리를 사용하면 UI를 위해 MUI라던가 ANT라는 라이브러리를 사용해야한다. 커스텀도 복잡하고 익힐려면 시간이 꽤 소요된다. 하지만 TailwindCSS는 자체에 해당 UI를 위한 Templete이 존재한다. 커스텀도 많이 쉬웠다.
3. 내가 구현해야할 View를 생각하며, 바로바로 작성할 수 있다.
4. 공식문서가 친절하다. 내가 본 공식 문서 중에 원 탑이다.

단점은 익숙해질려면 시간이 소요된다는 점이다.

회사의 수잔님께서 어떤 확장앱을 설치하면 더 편해진다는 말을 듣고 설치하게 되어 더욱더 편해졌다. 수잔님 고맙습니다.

🙅‍♂️ 바보 같았던 일주일

기획이 끝난 2주차에는 정말 뻘짓 아닌 뻘짓을 했다. 난 불만족스러웠던 위코드에서의 2차 프로젝트를 끝내고 자신감이 많이 하락해있었다. 그 여파로 TypeScript와 TailwindCSS, 국제화i18, Mobx에 대해 너무 두려워했다. 너무 두려워한 나머지 1주일을 거의 날렸다 해도 과언이 아니다.

 

다시한번 나에게 말한다.. 모든 걸 강의로 해결하려는 것은 정말 하수다. 시간이 널널한 것도 아니고, 당장 코앞의 문제를 해결해야하는데, 강의를 들으면 정말 시간낭비이고, 남는 것도 없다. 중요한 것은 실전이다. 실전으로 깨달아라

 

그냥 해보니 별거 없었다. 물론 TypeScript가 아니라 anyScript가 많이 되긴했다. Mobx는 상태 관리를 어중간하게 되긴했다. 근데 상태관리를 하긴 했다. TailwindCSS는 정말 익숙해졌다. 국제화는 적용해보진 않았지만 샘플 코드로 해보긴 했다.

 

한정된 시간 속에서 못한다고 강의를 보면서 완벽하게 하려고 해서 지연되는 것보다 서비스는 구현해놓고, 나중에 고쳐나가는 것이 베스트이지 아닐까 싶다.

😥 재사용 가능한 컴포넌트를 만들지 못했다.

동일한 구성으로 3개의 페이지가 있었는데, 재사용 가능하게 만들지를 못했다. 물론 재사용이 불가능하다해서 시간이 많이 소요된 것은 아니다. 다만 나중에 유지보수에 들어갈 리소스가 많이 소모할 것으로 판단된다.

 

이것은 인턴십을 마친 후에도 여전히 의문이고 수수께끼인 상태로 남았다.

API의 컬럼 값이 다른데, 어떻게 재사용 가능하게 만드는 것인가?

// equipment page
<td className="py-1.5 text-center">{data.equipmentType}</td>
<td className="py-1.5 text-center">{data.company}</td>
// device page
<td className="py-1.5 text-center">{data.serialNumber}</td>
<td className="py-1.5 text-center">{data.status}</td>

데이터 바인딩을 해본 사람이라면 다들 알다시피 { data.status} 라는 식으로 바인딩을 하게 된다. 그런데 다른 페이지에는 status라는 컬럼이 없다면, 해당 페이지는 status라는 컬럼이 없기 때문에, ‘ 없는 데이터에 대해 어떻게 접근을 하냐 ’ 라는 에러를 띄워 렌더링을 방해한다. 이런식으로 3개의 페이지 모두 API의 컬럼 값과 형식이 모두 달랐다. 1차적 데이터 가공이라면 할 수 있지만, 컬럼 값은 어찌할 도리가 없었다.

 

그래서 시간을 먼저 고려했다. 내가 이것을 재사용 가능한 컴포넌트를 만드는데 얼마나 시간이 걸릴 것인가?

시간이 얼마나 소요될지 감조차 오지 않아 차선책을 고려하여, 적용했다.

 

해당 페이지에 똑같은 코드를 복사해서 붙여넣는 것보다는 현재 페이지의 경로를 변수로 저장하여 그 변수의 값에 따라 조건문으로 분기점을 만들어서 다른 컬럼 값이 적용되도록 해두었다.

const pathCheckerOptionData: any = () => {
    switch (pathName) {
      case 'equipmentList':
        return equipmentData
      case 'deviceList':
        return deviceData
      case 'adminHistory':
        return adminHistoryData
    }
  }

{
  ;(() => {
        if (pathName === 'equipmentList') {
          return (
            ...your code
          )
        }
	
	if (pathName === 'deviceList') {
	  return (
		...your code
	  )
	}

	if (pathName === 'adminHistory') {
	  return (
  		...your code
	  )
	}
  })()
}

⚠️ 스노우볼 효과로 미완성한 프로젝트

1주차에서 기획이 오래걸린 점과 2주차에서 새로운 기술스택에 대한 막연한 두려움으로 시간을 허비한 것이 스노우볼이 되어 부족한 QA 시간을 불러 왔고, 허둥된 발표시간 등, 이는 우리의 결과물을 회사에 중요한 프로젝트였다는 것을 인식시키는데 실패했다.

실패의 원인은 앞서 말한 것과 중복되지만 피드백을 받은 것을 위주로 다시 정리해본다.

 

1. 4주라는 시간이 있었는데, 플래닝에 실패했다. 3주면 개발이 끝나야하고, 마지막 1주는 QA의 시간이다
2. 기획에 너무 오랜시간을 쏟았다. 가설을 세웠으면 그 가설에 대한 검증을 빨리빨리 받아서 피드백을 받는 루틴을 빠르게 해야한다.
3. 안되는 것에 대해 너무 붙잡지 않는다. 그런 것에 대해 오래 붙잡는 것은 업무 태만이다.
4. 개인으로서 일하는 것이 아니라, 팀원으로서 일해야한다.

내가 프로젝트의 진행이 느렸기 때문에, 혹은 팀원이 프로젝트의 진행이 느렸다가 아니라 팀의 실패였다. 물론 실패했다고 해서 낙담하지 않는다. 이 실패 속에서 많은 것을 배웠으며, 이 프로젝트의 팀장님께 더 많은 피드백을 받았다

물론 프로젝트는 인턴십이 끝나고 마무리 지었고, 리팩토링은 진행중이다.

❤️ 프로젝트로 배운 것과는 별개로 동료에게 배울 점이 많았다.

같은 프론트앤드 포지션인 자네님에게 배울점이 많았다. 나는 1,2차 때 이런것을 많이 경험해본적이 없었기 때문에, 더 많이 배울 수 있었다. 내가 계속 지켜봤던 나의 팀 동료의 장점을 공유하고자 한다.

첫 번째는 백앤드에서 API 명세서를 공유했을 때, 꼼꼼하게 체크하는 점이다. 빠진 데이터는 없는지, 필요 없는 값이 있다던지, 형식을 고쳐줬으면 한다던지, 질문이 있다던지 체크해서 백앤드와 계속 피드백을 주고 받았다.

두 번째는 기능 명세서를 받았을 때, 자신만의 가설을 계속 세운 점이다. 비록 검증은 못했지만 계속 가설을 세우고 나와 의견을 주고 받았다.

세 번째는 어떤 기술 스택의 적용 방법에 대해서 어떻게 정할 것인지 정하고자 할 때, 딱 이것으로 정하자가 아니라, 서로가 모르는 방법을 공부해서 서로에게 설명해, 더 나은 방법으로 나아가자! 라고 하는 점이다. Mobx의 사용 방법을 두고 의견을 주고 받게 됬고, 두 가지 방법 모두 사용하게 되었다.

네 번째는 자신감 넘치는 사람이라는 점이다. 프로젝트 2주차까지 자신 없던 나와는 다르게, 항상 자신감이 넘쳐서 나에게도 긍정적인 영향을 줬고, 80% 이상 개발을 진행할 수 있었다.

 

우리가 만든 서비스가 궁금하다면 이 링크로 이동하길 바란다.

현재 개발 상태로는 백앤드가 배포되어 있지 않아, 안열리므로, Dev에서 리팩토링을 진행 중이다.

https://github.com/conqueror-G/Mars-monitoring-system