난 풀스택이지만 FE 개발자로 참여한 프로젝트가 여러 번 있었다. 프로젝트의 상황은 각기 아주 다양했다. 빠른 수익을 내지 않아도 되는 모델도 있었고 영혼이 다치는 경험을 맛본 프로젝트도 있었다. 최근에 진행했던 작업은 수 개월 내내 밤낮을 새는건 당연하고 시간은 촉박, 페이지 제작 분량은 태산이었다. 그 프로젝트 성격상 많은 리스크(…)가 있었지만 개발을 하다보면 이런 저런 다양한 경험을 하게 되는 것 같다.
오늘은 보편적인 프로젝트에서 미리 인지하면 좋을 것들을 프론트엔드 작업자로서 느낀 시각으로 기록하려고 한다.

확인할 목록

  • A. 개발 작업 방식을 알리고 맞추기
  • B. 중도 기획이 달라지거나 추가되는 경우 메모하기
  • C. 변경 사항이 잦은 페이지인지 확인
  • D. 리스크를 미리 알리기
  • E. 라이브러리 사용은 독이 될 수도 있다.
  • F. 중도 입력 투입은 독이 될 수 있다.

위의 목록은 초반 작업부터 마무리까지 상당한 영향을 미쳤다. 만약 위에서 어느 항목들을 지켰음에도, 뜻대로 상황이 돌아가지 않는 경우는 어떻게 해야할까?

기획이 계속 변경되는 상황

예전 프로젝트에서 초반 미팅에서 정해진 미디어쿼리 규칙이 개발 착수 한 두달 후 365px에서 300px이 되는 매직이 일어났다. 이미 만든 페이지가 수십개인 상황에서 다시 검수하는데 상당 시간이 소요되었다. 일정이 긴박한 프로젝트에서 이미 한번 검수한 페이지를 또 다시 검수하고 수정해야 하는 일은 업무자 입장에서 매우 곤혹스럽다. 구두로 협의된 미디어 쿼리가 중간에 바뀌는 정도의 변경이면 계약 조항을 검토하거나 무리한 일정이 될 수 있다는 사실을 알려야 한다. 중도 변경이 없는 프로젝트는 지금까지 본 적이 없기에 어떻게 핸들링 할 수 있을지 고민해야 한다. 어쨌든 이 상황에서는 A를 구두로 이행했으나 변경되었기 때문에 B.로 가야 한다. 추가 견적서를 요구할 수 있는 부분이다. 하지만 이 또한 발생시 무조건 요구를 해야한다는 의미보단 이걸 하면 앞으로의 작업이 얼마나 딜레이가 될 것인가 혹은 얼만큼 시간이 드는가를 따져보면서 융통성 있는 판단이 필요하다는 얘기이다.

기획이 계속 변경되는 프로젝트의 경우 본인이 생각한 작업 방식이 실제로 착수된 이후 적용이 어려워지는 상황을 직면할 수 있다. 이럴땐 어떻게 대처하면 좋을까?
예시를 위해 조금 극단적인 상황을 가정해본다.

동일한 성격의 100개 페이지를 2주간 제작해야 하는 기획안을 받았다. 작업자는 침착하게 디자인을 일반화하고 예외 컨텐츠를 고려한 스타일링 컴포넌트 혹은 mdx 도입을 결정했다. 그런데 막상 개발을 진행하면서 복잡한 로직이 한 군데라도 들어가거나 React Hook 메서드를 써야하는 상황이 왔다. 하지만 이미 제작한 페이지는 몇십개인 상황이다. 물론 다시 jsx로 돌아가거나 혹은 돌아가지 않고도 해결 할 수 있는 방법을 찾을 수 있겠지만 요런 추가 시간을 소요시키지 않는게 중요한 법이다. 이 상황에서 A.를 잘 활용하려면 작업 이전에 본인이 생각한 방식을 알리고 합의가 분명히 되어야 한다. 만약 그렇지 못했을 경우 C. 변경 사항이 잦은지 다시 확인한 이후 개발 방식을 재정비 하고 갈 필요가 있다.

기획변경에 대한 뼈 아픈 경험이 있다. 수정이 들어와도 방어하거나 도무지 거절할 수 없어 해야만 했던 상황이었다. 클라이언트와 작업자가 1:1 관계라면 조정이 상대적으로 쉬울 수 있으나 업무자들 이해 관계도가 복잡할수록 기획 변경에 대해 거부하기가 쉽지 않다. B. 변경 혹은 추가된 기획은 메모해두었다가 추가 견적서를 요구하자… 절대 무리하게 자신의 영혼을 갈아넣어 프로젝트를 진행시키는 일은 없도록 하자.

라이브러리, 잘못 들이면 독이 될 수도

라이브러리는 남이 짠 코드를 사용하는 개념이다. 라이브러리의 의도는 이미 구현해놓은 완제품을 ‘사용하는데’에 목적이 있다. 때문에 라이브러리를 직접 수정하거나 변경하는 일엔 제약이 있다. 기획과 시안을 꼼꼼히 확인하고 혹시 ‘거의 새로 짜는 것’과 동일한 노력이 Custom에 들어가진 않는지 파악하자. 그리고 문제가 없다는 확신이 들떄 도입하도록 한다. 라이브러리 커스텀은 경험이 많을수록 새로운 라이브러리를 접했을때 커스텀 러닝커브가 낮은 것 같다.

상업 프로젝트에서 어떤 기술을 도입하기 전에는 몇 가지 기준을 확인한다. 전 직장에서 경험한 바로는 아래와 같았다.

  • 너무 최신 혹은 오래된 기술은 아닌지 (정보성, 신뢰성)
  • 가장 최근 업데이트가 언제인지 (호환성, 기능성)
  • 얼마나 많은 사람들이 쓰고 있는지 (러닝커브, 정보성)

라이브러리 도입도 비슷하다고 느꼈다. ‘완전하 새로운 기능 추가가 있을 예정인가?’ 등을 추가하는 식으로 팀에서 라이브러리를 도입하는 규칙을 세워보는 것도 의미가 있을 것이다. 신중히 들여도 나중에 들어내는 일이 없다고 장담하기는 힘들지 않을까.

추가 인력이 모든 면에서 좋은 것은 아니다

  • 소프트웨어 공학의 ‘브룩스의 법칙’. 새로 들어온 인력이 제 역할을 충분히 해 개발 속도를 낼 수 있을거라는 기대로 최종 결정자가 인력을 투입하나 되려 개발을 늦추는 현상

제아무리 평소 자기 몫을 잘하는 사람이어도 인력이 새로 투입되는 일에는 큰 비용이 발생한다. 오래 전 진행했던 프로젝트에서 10년 이상의 경력자가 프론트 팀에 들어왔다. ESMA 문법을 능숙하게 다루지만 우리 프레임워크는 처음 경험해본 것 이었고 팀에서 사용하는 협업 방식에 대한 경험이 없는 상태였다. 초반에 온보딩을 진행했지만 지속적으로 프레임워크 동작, 내장 메서드 사용 등에 대한 질문이 들어왔는데 일정이 급한 프로젝트에선 이런 상황이 위험이 될 수 있을 것 이다. 주니어로서 인사 평가 혹은 면접을 봐온 나로선 반대로 면접관의 심정을 이해할 수 있는 경험이었다.

협업자에게 요구되는 필요 기술 스택을 모두 기재했지만 인사 과정에서 잘 지켜지지 않는 경우도 있었다. 이런 경우를 대비하기 위해서는 커뮤니케이션이 조금 들더라도 프로젝트를 위해선 요구한 스택을 가진 후보자가 맞는지 확인이 필요하다. 자신이 업무자 본인이라면 더더욱 말이다.

미리 알리기

리스크를 미리 알리는건 사실 너무 당연하다. 하지만 작업 과정에서는 철저히 지켜지지 않는 것 같다. 전체 일정이 딜레이 될 정도의 위험이라면 상황을 무마하거나 대응할 수 있는 시간이 필요하다. 내가 존경하는 개발자 스승님께서 말씀하신 적이 있다. 리스크가 있는건 괜찮은데 모두가 대응할 수 있도록 미리 알리는게 중요하다고. 또한 상대 작업자도 리스크를 알게 된 당장의 상황에서 해결 방법을 찾기 위해 시간이 필요할 수 있다. 이때 같이 논의해보면 좋을만한 솔루션 혹은 사례들 몇 가지를 사전에 준비하면 도움이 될 수 있다. (실제로 리스크를 기획자에게 전했을때 ‘그럼 어떻게 하는게 좋을까요?’ 라는 질문들을 종종 받곤 했다)
회사 서버가 터지거나 당장 클라이언트가 확인해야 하는 테스트 서버의 build가 time out 되거나 하는 이유로 몸살을 앓아야 했던 내 어두운 과거… 리스크는 나에게 두려움의 대상이 되었다. 이 리스크는 나에게 영향을 미치고 팀에게 영향을 미치고 결과물에 영향을 미치기에 모두가 알 수 있도록 그리고 함께 대응할 수 있도록 반드시 공유해야 한다는 사실을 잊지 말자.



다음 포스트에는 Google Cloud Build 로그 분석하는 방법을 담아볼 예정이다.