더 줄게 프로젝트 최종 회고 현실적인 타협과 트레이드오프

이번 팀 프로젝트를 마치며 팀 단위 개발에서 기본기가 얼마나 중요한지 뼈저리게 느낄 수 있었다. 프로젝트를 진행하며 겪었던 나의 경험과 의사결정 과정을 START(Situation, Task, Action, Result, Takeaway) 기법을 이용해 정리해 본다.

S (Situation: 상황)

'더 줄게' 프로젝트를 선택한 이유는 유저 계정 타입에 따라 서비스를 분기하는 비즈니스 로직 구현이 해보고 싶었다. 사장님 계정과 일반 회원 계정의 서로 다른 요구사항을 효과적으로 처리할 수 있는 아키텍처 설계가 이 프로젝트의 핵심 과제였다.

T (Task: 과제)

프로젝트 개발 주제가 확정된 직후 팀원 한 명이 이탈하면서 전체적인 개발 기간이 매우 부족해지는 위기가 발생했다. 이 위기를 극복하고 제한된 시간 내에 프로젝트를 완성하기 위해서는 아주 전략적이고 현실적인 의사결정이 필요했다. 완벽한 코드보다는 '프로젝트 완성' 자체를 최우선 목표로 두고 일정과 라이브러리를 선택해야만 했다.

A (Action: 행동)

일정 내 프로젝트 완주를 위해 다음과 같은 세 가지 핵심 전략을 실행에 옮겼다.

• UI 라이브러리(Material UI) 적극 활용: Material UI를 적극적으로 도입하여 UI 구현에 들어가는 시간을 대폭 단축했다. 이미 검증된 컴포넌트를 사용함으로써 빠른 개발 속도는 물론, 일관된 디자인까지 동시에 확보할 수 있었다.
• 도메인 단위의 철저한 분업: 담당 개발 범위를 도메인 단위로 명확하게 나누어 팀원들이 서로 다른 도메인의 코드를 파악하는 데 낭비되는 시간을 최소화했다. 그 결과 철저히 독립적인 개발이 가능해져 병렬 작업 효율이 크게 향상되었다.
• 공통 컴포넌트 개발 우선순위 조정: 이상적으로는 공통 컴포넌트와 훅을 세팅한 뒤 도메인 개발에 들어가는 것이 좋다고 생각한다. 하지만 기한 내 완성을 위해 공통 작업에 쏟을 시간을 줄이고 도메인 개발을 시작하는 실용적인 결정을 내렸다.

R (Result: 결과)

원래 계획했던 완료 목표일은 1월 5일이었고, 남은 기간을 온전히 QA와 발표 준비에 쏟으려 했다. 하지만 일정이 밀리면서 실제로는 1월 7일에 개발이 완료되어 QA 기간이 부족해지는 아쉬움이 있었다. 그럼에도 불구하고 발표일까지 남은 이틀이라는 시간을 밀도 있게 활용하여 QA와 발표 자료 준비를 마쳤다. 결과적으로 부족한 인원과 시간 속에서도 모든 요구 사항을 성공적으로 구현해냈고, 발표 당일 치명적인 버그 없이 성공적으로 프로젝트 시연을 마칠 수 있었다.

T (Takeaway: 교훈)

그동안 멘토님들이 말씀하시던 '트레이드오프(Trade-off)'의 진정한 의미를 프로젝트 현장에서 제대로 이해할 수 있었다. 프로젝트를 진행하며 많은 의사결정의 순간이 있었고 그때마다 팀의 상황과 우선순위를 고려한 실용적인 판단을 내렸다. 이번 프로젝트에서 과감하게 포기하고 취했던 모든 선택은 오직 '기한 내 프로젝트 완성'이라는 뚜렷한 목표가 있었기에 가능했다고 생각한다. 앞으로 실무에서 개발할 때도 항상 명확한 목표를 설정하고 그에 맞는 현실적인 트레이드오프를 도출하는 개발자가 되어야겠다.