[Java 풀스택 개발자] 팀 프로젝트 편: 기획

 

0. 들어가기 전에

이번 시간부터 팀 프로젝트를 진행하게 되었다. 그러하여 TIL 또한 주로 프로젝트 개발과 관련된 부분이 될 거 같다. 이번에는 프로젝트의 기획을 진행하게 되었는데 이에 대하여서 개발자들이 프로젝트를 할 때 어떤 것을 주로하는지, 어떻게 기록하는지에 대해서 공부한 것들을 써보고자 한다. 그리고 우리 프로젝트를 진행하면서 무엇을 어떻게 결정했는가 등에 대해서 말할 예정이다.

 

1. 프로젝트에서 기획의 중요성

많은 사람들이 ‘개발자’라고 하면 코드를 만드는 일만 잘하면 되는 직업이라고 생각한다. 실제로 프로젝트에서는 기획이 기획 파트에서 정리되어 내려오는 경우가 많고, 새 프로젝트를 시작하지 않는 이상 업무의 상당 부분이 유지·보수로 흘러가는 것도 사실이다. 그럼에도 개발자에게 기획은 생각보다 훨씬 중요하다. 어떤 기능을, 어떤 기준으로, 누구에게 제공할지 정해지는 순간 그것이 곧 개발의 지침서가 되기 때문이다.

개발자에 대한 편견 중 하나는 “코드만 잘 쓰면 소통이 조금 부족해도 괜찮은 전문직”이라는 이미지다. 그런데 막상 프로젝트를 해보면 오히려 개발자만큼 소통이 중요한 직업도 드물다. 같은 개발팀 안에서의 소통은 기본이고, 디자인·기획 같은 타 직군과의 소통, 그리고 최종적으로는 고객 요구를 해석하고 구현으로 옮기는 간접적인 소통까지 개발자의 책임이 된다. 이 때문에 많은 회사에서 팀 프로젝트나 타 오픈 소스 등의 프로젝트에서의 참여를 크게 본다. 특히 AI의 시대가 온 만큼, 개발자 개인의 기술력보다 타인과 얼마나 발을 맞추어나갈 수 있을지가 큰 기점이 되었다.

본론으로 들어가, 기획은 개발자가 ‘코드를 어떻게 짤지’를 정하기 전에 무엇을 만들어야 하는지와 성공 기준이 무엇인지를 먼저 합의하는 과정이다. 기획을 탄탄하게 해두면 프로젝트는 흔들림이 없고, 변동성이 있어도 예측이 가능하거나 수습할 수 있다. 우리 과정인 현대이지웰 Java 풀스택 개발자 과정에서 팀 프로젝트로 기획부터 직접 하게 하는 까닭은 이 이유가 클 것이다.

 

기획은 단순한 '문서'가 아니라, 구현을 흔들리지 않게 만드는 기준선이다

 

이에 따라 내가 속한 조는 아이템 회의, 요구사항 정의서, 정책(Policy) 정하기, API 명세, WBS와 업무분장하기 등의 과정을 수행했다.

 

2. 아이템 회의와 최종 주제 설정

이번 과정에서는 프로젝트 아이템이 5가지로 한정되어 있고, 그중 하나를 선택한 뒤 세부사항을 확장해 나가는 방식으로 진행된다. 아이템을 고르는 순간 큰 방향은 잡히지만, 실제로는 그때부터 “무엇을 접근성으로 볼 것인지”, “누구를 고객으로 둘 것인지”, “핵심 기능을 무엇으로 만들 것인지” 같은 결정이 연쇄적으로 따라온다.

우리 조는 ‘접근성을 주제로 한 중계 쇼핑몰’ 을 주제로 선택했다. 다만 접근성(Accessibility)은 범위가 넓기 때문에, 먼저 우리가 말하는 접근성이 무엇인지부터 정의할 필요가 있었다. 우리는 접근성의 여러 갈래 중에서도 상황적·인지적 접근성에 초점을 두기로 했다. 즉 사용자가 ‘원하는 것을 찾는 과정’에서 겪는 부담을 줄이는 방향으로 서비스를 설계하겠다는 의미다.

다음으로 중요한 건 타깃, 즉 고객 페르소나다. 현대이지웰이 복지몰이라는 점에 착안해, 3–40대 직장인을 주 타깃으로 설정했다. 이 타깃을 기준으로 서비스의 중점 기능도 자연스럽게 좁혀졌다. 결론적으로 우리가 구현하려는 핵심은 메타데이터 기반 큐레이션이다.

큐레이션의 목적은 3–40대 직장인의 퍼스널 데이터(또는 선호/상황 데이터)를 바탕으로, 사용자가 원하는 상품을 더 빠르게 찾게 만드는 것이다. 결과적으로 UI/UX 관점에서 사용자가 느끼는 탐색 비용을 줄이고, “찾기 쉬운 복지 쇼핑 경험”을 제공하는 것이 목표가 된다. 정리하면 이번 프로젝트의 주제는 “접근성 중심의 상품 중계 복지 쇼핑몰(3040 직장인 큐레이션)” 이다. 또한 부가적으로 웹 접근성 요소도 일부 반영할 수 있도록 이 부분 역시 염두에 두기로 했다.

 

3. 요구사항 정의서

이후에는 요구사항 정의서를 작성하였다. 요구사항 정의서란 IT 프로젝트나 시스템 개발을 시작할 때, 고객 또는 사용자가 요구하는 목표, 기능, 제약 사항 등을 구체적으로 명시한 문서를 의미한다. 이 요구사항 정의서는 주로 표로 작성하게 되는데, 보통 다음과 같은 항목을 넣게 된다. 1) 요구사항 ID 2) 구분/분류 3) 중요도/우선순위 4) 상세 요구사항 5) 수용 조건.

 

표의 칸 하나하나가 협업의 ‘공통 언어’가 된다

 

먼저 요구사항 ID는 요구사항을 식별하는 번호다. 처음에는 그냥 1, 2, 3으로 적어도 되지 않을까 싶었는데, 실제로는 회의록이나 이슈, API 명세, 테스트 케이스를 정리할 때 “그 요구사항”을 정확히 가리키는 이름표가 필요했다. 요구사항이 많아질수록 “회원가입 말고, 아이디 중복검사 요구사항”처럼 구체적으로 지칭해야 하는 상황이 늘어나기 때문이다. ID가 있으면 수정사항이 생겨도 “REQ-003이 바뀌었다”처럼 정확히 추적할 수 있고, 팀원 간 커뮤니케이션도 덜 헷갈린다.

 

다음으로 구분/분류는 요구사항을 성격별로 묶기 위한 칸이다. 프로젝트 초반에는 모든 요구사항이 다 ‘기능’처럼 보이지만, 사실 요구사항에는 기능 요구사항뿐 아니라 비기능 요구사항도 같이 섞여 있다. 예를 들면 로그인/추천/검색은 기능 요구사항이지만, 접근성이나 보안, 응답 속도 같은 요소는 비기능 요구사항에 더 가깝다. 분류를 해두면 요구사항을 한눈에 정리하기 쉽고, 나중에 API 명세나 ERD로 내려갈 때도 “이 요구사항이 어느 파트로 이어지는지”가 선명해진다. 특히 우리 프로젝트처럼 ‘접근성’이 중요한 주제에서는, 접근성 관련 요구사항을 따로 묶어두는 것만으로도 설계 방향이 흐트러지지 않는다.

 

중요도/우선순위는 말 그대로 “지금 당장 해야 하는 것”을 정하는 칸이다. 팀 프로젝트에서는 시간이 무한하지 않기 때문에, 결국 모든 요구사항을 다 구현할 수는 없다. 그래서 우선순위를 매기는 작업은 단순히 급한 일을 골라내는 게 아니라, MVP 범위를 확정하는 과정에 가깝다. 우선순위가 없으면 ‘다 중요한데요’ 상태가 되고, 개발이 진행되면서 충돌이 생길 때마다 팀이 다시 논쟁을 해야 한다. 반대로 우선순위가 정해져 있으면, 어떤 기능이 밀리거나 빠지더라도 “우리가 합의한 기준”에 따라 결정했다고 설명할 수 있다. 결과적으로 우선순위는 개발 일정뿐 아니라 팀의 스트레스를 줄여준다.

 

표의 핵심은 결국 상세 요구사항이다. 여기에는 “무엇을 만들어야 하는가”가 적히는데, 이 칸이 애매하면 개발도 애매해진다. 그래서 상세 요구사항은 가능한 한 사용자가 실제로 하게 될 행동 중심으로 쓰는 편이 좋다. 예를 들어 “큐레이션 제공”처럼 큰 단어로 끝내기보다, 어떤 조건에서 무엇이 추천되고, 사용자는 어떻게 탐색하며, 결과가 없을 때는 어떤 fallback을 적용할지까지 문장으로 쪼개는 것이 필요하다. 이때 중요한 건 구현 방법을 먼저 쓰기보다, 팀이 합의할 ‘규칙’을 먼저 쓰는 것이다. 규칙이 정해져야 API도, DB도 결정할 수 있으니까.

 

마지막으로 수용 조건은 요구사항이 “완료됐다”고 판단할 수 있는 기준을 적는 칸이다. 사실 요구사항 정의서에서 가장 협업에 도움이 되는 부분이 바로 이 수용 조건이다. 요구사항이 충족되었는지 판단할 기준이 없다면, 개발이 끝나도 “이게 된 건가?”라는 질문이 남는다. 수용 조건은 테스트 관점과도 연결된다. 성공했을 때 어떤 결과가 나와야 하는지, 실패했을 때는 어떤 메시지나 상태로 처리할지 같은 것들이 명확하면, 구현뿐 아니라 검증도 쉬워진다. 결국 수용 조건은 팀이 기대하는 ‘정답’을 문서에 고정하는 장치다.

 

정리하면 요구사항 정의서의 표는 단순히 “요구사항을 적어두는 문서”가 아니라, 프로젝트 전체를 흔들리지 않게 만드는 기준점에 가깝다. ID로 추적 가능하게 만들고, 분류로 요구사항을 묶고, 우선순위로 범위를 고정하고, 상세 요구사항으로 규칙을 문장화하고, 수용 조건으로 완료 기준을 합의한다. 이렇게 기획 단계에서 문서를 조금 더 신경 써두면, 이후 단계에서 API 명세나 ERD를 만들 때도 훨씬 덜 헤매게 된다.

 

우리 조의 경우 구분을 User, Product, Order, MyPage, Admin, QNA의 6가지로 나누었고, 우선순위의 경우는 P0부터 P2까지 차등을 두어 설정하였다. 요구사항 정의서를 작성하던 중 어려웠던 지점은 바로 (1) 무슨 기능이 필요한지와 (2) 이 기능에 대한 수용기준을 만드는 것이었다.

 

개인적인 생각으로 좋은 개발자가 되는 방법 중 하나는 좋은 사용자가 되는 것이라 생각한다. 기획에서의 세심함은 바로 다양한 사이트를 직접 써보고, 그 불편함과 장점을 캐치하는 것에서 나타난다. 무슨 기능이 필요한지를 적으면서 참고로 한 것은 이런 사이트에 대한 이용과 분석이었다. 예를 들어, 쿠팡과 테무와 같은 입점 중계 사이트를 확인해보면, 다음과 같다.

 

 

일단 User 인증과 관련된 부분(로그인/회원가입), 마이페이지(MyPage), 장바구니 기능, 카테고리 기능, 고객센터 등의 기능을 보유하고 있다. 이것을 큰 기능으로 분류하고, 상세 기능을 쿠팡(혹은 그 외 사이트들)을 사용하면서 확인한다. 이렇게 벤치마킹을 대상으로 한 사이트를 이용하고 분석하다보면, 우리가 개발해야할 사이트에 대한 청사진이 완성된다.

 

이 요구사항 정의서를 적다보면 자연스레 의문점이 드는 것들이 있는데, 그것이 바로 정책(Policy) 정하기로 이어진다.

 

 

4. 정책 정하기

개발에서 정책(Policy)은 우리 팀 사이의 규칙과 약속같은 것이다. 코드 한 줄을 쓰기 전에 무엇이 옳고 그른지 기준을 세우는 작업으로, 개발자간 혼동을 막기 위한 일종의 법전 같은 것이다. 나는 실제로 이전 프로젝트에서 이 정책 정하기를 잘 모르고 있었는데, 이 때문에 백엔드와 프런트엔드 사이에서 임의로 한 일들 때문에 상호 곤란해진 부분이 존재했다. 이러한 점을 반면교사로 삼아, 이번에는 확실히 정책을 정해보기로 했다.

 

우리는 정책을 아무렇게나 나열하기보다는, 비즈니스 로직을 먼저 정리한 뒤 정책을 내려오는 순서로 합의를 잡아보기로 했다. 먼저 “사용자가 하는 행동”을 기준으로 핵심 시나리오를 뽑았다. 예를 들면 로그인/회원관리, 상품 탐색과 추천, 결제와 환불, 주문 상태 변화, 운영(취소·반품·리뷰 관리) 같은 흐름이다. 그리고 각 시나리오마다 꼭 결정해야 하는 질문을 던졌다. “이 상황에서는 성공인가 실패인가?”, “실패라면 어떤 메시지와 상태로 처리할까?”, “데이터는 언제 확정되고 언제 되돌릴까?” 같은 질문들이다. 이런 질문에 대한 답을 문장으로 고정한 뒤, 그 문장이 API와 DB 설계를 밀어주도록 만들었다.

이 과정을 거치면서 정책도 자연스럽게 몇 가지 묶음으로 정리됐다. 첫 번째는 계정 운영과 보안에 대한 정책이다. 비밀번호를 얼마나 자주 바꾸도록 권고할지, 그것이 ‘권고’인지 ‘강제’인지, 사용자가 언제 어떤 방식으로 안내를 받는지까지가 포함된다. 단순히 “비밀번호는 암호화한다” 수준이 아니라, 운영 기준이 있어야 프론트에서도 화면과 UX를 일관되게 맞출 수 있기 때문이다. 그래서 우리는 이를  POL-01 로 분리해 계정/비밀번호 운영정책으로 고정했다. 변경 권고 주기(예: 90일)를 둘지, 강제 여부는 어떻게 둘지, 그리고 안내 방식(배너/모달/알림)을 어떻게 할지까지가 이 정책의 범위가 된다.

두 번째는 이번 프로젝트의 핵심인 추천(큐레이션) 정책이다. 추천은 “똑똑하게 보여야 하는 기능”인 동시에, 기준이 없으면 팀원마다 결과를 다르게 상상하는 기능이기도 하다. 그래서 우리는 추천을 감각으로 만들기보다, 사용자의 행동 이벤트를 점수화해 가중치로 반영하는 방식으로 합의했다. 예를 들어 클릭/장바구니/찜/구매/검색 같은 이벤트가 각각 어떤 점수를 갖는지, 점수는 시간이 지나면 감쇠되는지, 특정 조건에서는 삭제되는지, 그리고 추천 결과가 실제로 어느 화면에 어떻게 반영되는지까지를  POL-02 로 묶었다. 추천 정책은 단순한 기능 정의가 아니라 “우리 서비스가 사용자를 어떻게 이해할 것인가”를 결정하는 기준이므로, 초반에 문서로 고정하는 게 중요하다고 느꼈다.

 

세 번째는 결제 단계에서 흔히 갈리는 포인트 및 복합결제 정책이다. 결제는 성공/실패만 정하면 끝나는 것 같지만, 실제로는 취소·환불·부분취소 같은 예외 케이스에서 정책이 없으면 혼란이 가장 크게 생긴다. 포인트를 먼저 차감할지, 카드 결제와 포인트를 섞었을 때 취소는 어떤 순서로 되돌릴지, 부분취소가 발생했을 때 포인트를 어떻게 처리할지 같은 질문은 “나중에 정하자”로 넘기기 쉽지만, 결국 그 ‘나중’이 가장 고통스럽다. 그래서 우리는 이를  POL-03 으로 분리해 포인트/복합결제 정책으로 먼저 합의해두었다.

 

네 번째는 운영 관점에서의 정책이다. 쇼핑몰은 결국 운영 이슈가 계속 발생한다. 반품이 가능한 기간은 어디까지인지, 배송 상태에 따라 취소가 가능한지, 리뷰나 콘텐츠는 어떤 기준으로 숨김/삭제할지, 삭제 후 복구는 가능한지 같은 것들은 모두 서비스의 신뢰와 직결된다. 이런 기준이 없으면 “프론트는 가능하다고 만들었는데 백엔드는 막는다”거나, 반대로 “백엔드는 열어뒀는데 화면에서는 막혀 있다” 같은 어긋남이 생긴다. 그래서 운영 관련 기준은  POL-04 로 묶어 취소/반품/콘텐츠 모더레이션 운영정책으로 정리했다.

 

마지막으로 시간과 상태가 얽히는 정책이다. 예를 들어 무통장 입금 기한을 3일로 둘지, 기한이 지나면 자동 취소를 할지, 그리고 휴면 전환은 어떤 기준으로 할지 같은 것들은 “데이터가 언제 어떻게 바뀌는가”를 결정한다. 이 부분은 ERD의 상태 컬럼과도 바로 이어지고, 배치/스케줄러 같은 구현 방식에도 영향을 준다. 그래서  POL-05 로 기한/상태 전환 정책을 따로 둬서, 상태가 바뀌는 기준과 자동 처리 규칙을 먼저 고정했다.

 

정리하면 정책을 정한다는 건 기능을 ‘만들겠다’에서 끝내는 게 아니라, 그 기능이 어떤 기준으로 동작하고 어떤 예외를 어떻게 처리할지를 팀이 같은 문장으로 합의하는 과정이었다. 이 정책이 잡히고 나니, 다음 단계인 API 명세서에서도 “이 엔드포인트는 어떤 정책을 만족해야 하는가”가 분명해졌고, ERD에서도 어떤 제약과 상태값이 필요한지 더 구체적으로 내려갈 수 있었다.

 

5. API 명세 만들기

API 명세란 두 소프트웨어가 서로 소통하는 방식에 대한 공식적인 약속인데, 여기서 소프트웨어는 백엔드와 프런트엔드라고 이해하면 편하다. 같은 화면을 보더라도 프런트는 “어떤 요청을 보내야 하는지”가 필요하고, 백엔드는 “어떤 형태의 데이터를 받아서 어떤 형태로 돌려줄지”가 필요하다. 이때 API 명세는 단순히 URL을 나열하는 문서가 아니라, 팀이 같은 기능을 서로 다르게 상상하지 않게 만드는 기준점이 된다.

 

요구사항 정의서가 “무엇을 만들 것인가”를 정리하는 문서라면, API 명세는 그 요구사항을 실제로 구현 가능한 형태로 바꾸는 단계에 가깝다. 특히 팀 프로젝트에서는 개발을 시작한 뒤에 “아 이건 이렇게 주는 줄 알았는데?”, “난 배열로 줄 줄 알았어”, “에러는 그냥 문자열로 보내면 되는 거 아냐?” 같은 대화가 빈번하게 나온다. 이런 충돌은 능력 문제가 아니라 계약이 없어서 생기는 문제다. 그래서 API 명세를 한 번 제대로 잡아두면, 개발 과정에서 생기는 소모적인 소통 비용이 눈에 띄게 줄어든다.

 

우리는 API 명세를 만들 때, 기술 설명을 길게 쓰기보다 프런트와 백엔드가 같은 기능을 같은 방식으로 구현할 수 있도록 ‘약속’을 고정하는 데 집중했다. 그래서 명세 표는 API 명칭 / Method / 엔드포인트 / Request Body(JSON) 또는 Query / 비고로 통일했고, 각 행이 “한 기능의 계약”이 되도록 구성했다. 특히 Request 쪽은 프런트가 바로 호출 코드를 작성할 수 있도록 JSON 구조(키 이름과 타입)를 최대한 명확히 적어두었다.

 

또한 URL만 정리하면 끝이 아니라, 앞서 정한 정책에 맞춘 비고도 작성하였다. 사실 명세를 쓰다 보면 URL이나 Method보다 더 자주 팀을 헷갈리게 만드는 건 “이 기능이 어떤 규칙을 따라야 하는가”였다. 그래서 우리는 비고 칸을 단순한 메모가 아니라, 정책(Policy)이 실제 구현으로 내려오는 체크포인트처럼 사용했다. 즉 “요청이 오면 무엇을 반드시 확인해야 하는지”, “예외 상황은 어떤 기준으로 처리할지”, “저장 방식이나 운영 기준은 무엇인지” 같은 내용을 비고에 짧은 문장으로 고정해두는 식이다.

URL보다 중요한 건 요청 형식과 규칙을 먼저 고정하는 일이다.

 

명세를 정리하면서 느낀 점은, API 문서는 단순히 “엔드포인트 목록”이 아니라 정책(Policy)과 구현을 연결하는 중간 다리라는 것이다. 정책에서 정한 규칙이 API의 요청/처리 조건으로 내려오고, 그 결과가 다시 화면과 데이터 설계로 이어진다. 결국 API 명세는 개발을 시작하기 전에 팀이 같은 그림을 보게 만드는 장치였고, 덕분에 구현 단계에서 생길 소모적인 커뮤니케이션을 줄일 수 있을 것이라 기대한다.

6. ERD 설계하기

ERD는 Entity-Relationship Diagram, 즉 데이터베이스 설계도라고 할 수 있다. 구성 요소는 엔티티(Entity) / 속성(Attribute) / 관계(Relationship) 세 가지로 정리할 수 있다. 우리는 앞서 요구사항 정의서, 정책, API 명세를 먼저 정해두었기 때문에 ERD를 설계할 수 있는 ‘재료’는 갖춰진 상태였다. 다만 이번에는 ERD를 처음부터 직접 그리기보다는, 팀장이 1차로 설계한 ERD를 팀원들이 함께 컨펌하는 방식으로 진행했다.

 

 

처음에는 “이미 만들어진 걸 확인만 하면 되겠지”라고 생각했지만, 막상 컨펌을 시작하니 확인해야 할 지점이 생각보다 많았다. ERD는 문서로 합의한 내용을 결국 데이터로 고정하는 단계이기 때문에, 사소한 차이도 구현에서는 크게 돌아올 수 있다. 그래서 우리는 단순히 그림을 보는 데서 끝내지 않고, 앞에서 정한 문서들과 ERD가 자연스럽게 맞물리는지 중심으로 점검했다.

가장 먼저 확인한 것은 요구사항에서 반복해서 등장하는 핵심 개념들이 엔티티로 잘 잡혀 있는지였다. 요구사항에 자주 등장하는 대상이 ERD에 없거나, 반대로 근거가 약한 엔티티가 불필요하게 들어가 있으면 이후 구현이 흔들릴 수 있기 때문이다. 다음으로는 API 명세에서 주고받는 데이터가 테이블 구조와 크게 충돌하지 않는지를 봤다. 요청/응답에서 자주 쓰이는 값이 누락되어 있거나, 반대로 데이터가 과하게 복잡하게 저장되는 구조라면 개발 난이도가 급격히 올라갈 수 있다.

 

마지막으로는 정책에서 정했던 규칙들이 ERD에서도 지켜질 수 있는지를 확인했다. 예를 들어 “중복이 허용되지 않는다”는 규칙은 유니크 제약과 연결될 수 있고, “삭제 대신 상태로 관리한다” 같은 정책은 상태값 컬럼과 같은 구조적 근거가 필요해진다. 물론 모든 정책을 DB 제약으로 강제할 수 있는 것은 아니지만, 최소한 정책과 데이터 구조가 서로 모순되지 않도록 만드는 것이 컨펌의 핵심이었다.

 

또 하나 인상적이었던 점은, ERD가 한 번 정해지면 끝나는 산출물이 아니라는 사실이었다. 팀 내부 합의만으로는 괜찮아 보이던 구조도, 강사님 컨펌처럼 외부 리뷰가 들어오면 설계 방향이 한 번 더 정리되는 경우가 있었다. 실제로 우리는 피드백 이후 ERD를 한 차례 수정했는데, 이는 “처음 설계가 틀렸다”기보다는 요구사항과 관계를 더 명확하게 만들기 위한 다듬기 과정에 가까웠다. 결과적으로 애매했던 관계가 정리되고, 불필요하게 복잡했던 부분이 단순해지면서 구현 난이도도 함께 낮아졌다.

 

ERD를 실제 DB 스키마로 옮기는 과정에서도 현실적인 조정이 한 번 더 필요했다. ERD는 개념 설계에 가깝고, 스키마화는 DB에 “어떤 타입으로 저장할 것인가”를 결정하는 물리 설계에 가깝다 보니, 여기서도 수정이 발생할 수 있다. 예를 들어 어떤 텍스트 컬럼은 처음에 큰 텍스트 타입으로 잡았지만, 실제 데이터 길이를 다시 고려해보니 그 정도까지 필요하지 않아 더 가벼운 문자열 타입으로 조정했다. 이런 타입 변경은 사소해 보이지만 저장 공간, 인덱싱, 성능 같은 부분에도 영향을 줄 수 있어 생각보다 중요한 결정이라고 느꼈다. (Oracle 기준으로는 보통 큰 텍스트는 CLOB, 일반 문자열은 VARCHAR2를 많이 사용한다.)

 

결국 이번 과정을 통해 ERD와 스키마는 “한 번에 완성하는 문서”라기보다, 리뷰와 구현을 거치면서 계속 맞춰가는 결과물이라는 점을 확실히 체감했다.

 

7. WBS 작성-업무분장

WBS와 업무분장은 프로젝트라는 큰 덩어리를 잘게 쪼개서 “누가, 언제까지, 무엇을 할지” 정하는 실행 계획서라고 할 수 있다. WBS는 Work Breakdown Structure의 준말로, 전체 프로젝트 목표를 달성하기 위해 필요한 모든 작업을 계층적으로 쪼개둔 표이다.

여기서 WBS가 필요한 이유는 단순히 일정표를 만들기 위해서가 아니다. 프로젝트가 진행되면서 생기는 문제 대부분은 “일이 많아서”가 아니라, 해야 할 일이 무엇인지가 애매하거나, 완료 기준이 공유되지 않거나, 순서가 엉키는 것에서 시작한다. WBS는 작업을 기능 단위로 분해하고(큰 작업 → 중간 작업 → 세부 작업), 각 작업의 범위를 명확히 만든다. 그 결과 “이건 누가 하고 있지?”, “어디까지가 끝난 거지?”, “이게 먼저 돼야 다음을 할 수 있나?” 같은 질문이 줄어든다. 특히 팀 프로젝트에서는 모두가 머릿속에 같은 계획을 들고 있는 게 아니기 때문에, WBS가 일종의 공통 지도처럼 작동한다. 일을 쪼개서 적어두는 것만으로도 숨은 의존관계가 드러나고, 초반에 리스크를 발견할 확률이 커진다는 점에서 의미가 있다.

 

 

업무분장이 필요한 이유도 비슷하다. 팀플에서 “다 같이 하면 되지”라는 말은 처음엔 든든해 보이지만, 실제로는 책임이 흐려지기 쉽다. 업무분장은 각자 맡은 영역을 정해 결정권과 책임을 분명히 해준다. 책임이 정리되면 속도가 붙는다. 질문이 생겼을 때 누구에게 물어봐야 하는지 명확하고, 리뷰도 “내 영역이 아닌데도 전체를 이해해야 하는 부담”이 줄어든다. 동시에 업무분장은 협업을 막는 장치가 아니라, 오히려 협업을 가능하게 만드는 장치라는 점도 느꼈다. 각자 맡은 영역이 분명해야, 서로가 어디에서 맞물려야 하는지(인터페이스, API, 데이터 계약)가 더 또렷해지기 때문이다.

 

우리는 업무분장을 크게 네 영역으로 나눴다. 보안과 인증, 구매 및 결제, 큐레이션, 시스템 및 UI 총괄처럼 역할을 잡아두면, 각 파트가 무엇을 먼저 정해야 하는지도 자연스럽게 따라온다. 인증 파트는 접근 권한과 토큰/세션 같은 기준을, 결제 파트는 상태 흐름과 예외 케이스를, 큐레이션 파트는 이벤트와 추천 기준을, 시스템/UI 파트는 화면 흐름과 공통 규칙을 중심으로 작업을 끌고 갈 수 있다. 이렇게 역할을 나눠두고 WBS로 일정과 작업 단위를 맞추니, “각자 따로”가 아니라 “같이 맞물려서” 진행할 수 있는 형태가 만들어졌다.

 

 

 

7.5. 한 차례의 피드백 그리고 공부

이 파트는 앞에서 정리한 요구사항 정의서나 API 명세, ERD처럼 ‘문서 산출물’과는 결이 조금 다르다. 하지만 이번 주차에서 가장 기억에 남았던 흐름이라 따로 적어두고 싶다. 설계가 어느 정도 정리되었다고 생각했는데, 강사님 피드백 한 번으로 “우리가 정한 기준이 정말 근거가 있는가?”를 다시 점검하게 되었기 때문이다.

 

이번에 받았던 피드백은 "큐레이션"에 관해서였다. 강사님 피드백은 두 가지 질문으로 정리할 수 있었다. 첫째, 사용자 행동 피드백의 기준과 점수(가중치)는 무엇을 근거로 정할 것인가였다. 단순히 “클릭은 1점, 구매는 10점”처럼 숫자를 적어두는 건 쉬운데, 그 숫자가 왜 그런지 설명할 수 없으면 설계는 쉽게 흔들린다. 특히 추천/개인화처럼 정답이 없는 영역에서는 “감”으로 정한 기준이 구현 단계에서 계속 논쟁으로 되돌아오기도 한다. 그래서 나는 이 질문에 답하기 위해, 단순히 팀 내부 합의로 끝내지 않고 외부 레퍼런스를 근거로 삼는 방식을 택했다. 예를 들어 행동 데이터(인터랙션)를 어떤 형태로 쌓고 어떤 이벤트를 의미 있는 신호로 볼지에 대한 사례를 찾아보면서, 우리가 정한 가중치와 기준이 완전히 뜬금없는 방향은 아닌지 점검했다. 이 과정에서 나는 Google 쪽 문서와 Amazon 쪽 문서를 참고했고, “행동 이벤트를 어떻게 수집·정의하는지”를 기준으로 우리 설계를 다시 정리하게 되었다.

 

둘째, 강사님은 클릭을 어떻게 다룰 것인지를 짚어주셨다. 클릭은 가장 흔한 이벤트이지만, 그만큼 잡음도 많다. 단순 클릭을 그대로 DB에 쌓아버리면 의미 없는 데이터가 대량으로 들어오고, 반대로 너무 엄격하게 걸러버리면 신호가 부족해질 수도 있다. 그래서 우리는 클릭을 단순한 ‘버튼 눌림’으로 보지 않고, 일정 조건을 만족한 행동만 의미 있는 신호로 반영하는 쪽으로 기준을 세웠다. 그리고 이 과정에서 발생하는 고빈도 이벤트를 안정적으로 처리하기 위해, 클릭 로그를 Redis로 먼저 모아 처리하는 방식을 팀 내부적으로 결정했다.

 

이러한 피드백은 결국 ‘개발자끼리 납득하는 설계’가 아니라, 고객이 실제로 체감할 결과로 설계를 되돌려 놓는 과정이라고 느꼈다. 우리가 내부에서 문서를 잘 써두고, 기능을 그럴듯하게 정의해둔다고 해도, 고객 입장에서 중요한 건 “그 기능이 내 문제를 정말 해결해 주는가”와 “그 결과가 믿을 만한가”이다. 그런데 추천이나 개인화 같은 기능은 특히, 결과가 조금만 어색해도 사용자는 바로 신뢰를 잃는다. 그래서 강사님 질문은 단순히 기술적인 지적이라기보다, “이 기준이 사용자 경험으로 설명 가능한가?”, “이 데이터가 정말 의미 있는 신호인가?”를 묻는 고객 관점의 질문에 더 가까웠다.

그리고 이번 피드백을 통해 확실히 깨달은 건, 설계에서 “그냥”은 없다는 점이었다. “클릭은 일단 다 쌓자”, “점수는 적당히 정하자”, “나중에 고치면 되지” 같은 말은 처음엔 편해 보이지만, 결국 그 ‘그냥’이 나중에 비용이 되어 돌아온다. 로그를 어떻게 쌓을지 하나만 해도, 데이터 품질이 흔들리면 추천 결과가 흔들리고, 추천이 흔들리면 서비스의 신뢰가 흔들린다. 반대로 너무 엄격하게 걸러버리면 학습할 신호가 부족해져 기능 자체가 의미를 잃을 수도 있다. 결국 “어떤 클릭을 신호로 볼 것인가” 같은 질문은 사소한 구현 디테일이 아니라, 서비스가 고객에게 제공하려는 가치를 지키기 위한 선택이었다.

 

그래서 이번에는 가능한 한 모든 결정을 그냥 두지 않기로 했다. 왜 이 이벤트를 기록하는지, 어떤 조건에서만 반영하는지, 점수는 어떤 근거로 잡는지, 그리고 이렇게 쌓인 로그가 결국 어디에 쓰이는지까지 스스로 설명할 수 있어야 한다고 느꼈다. 그 설명이 가능해지는 순간부터는 팀 내 소통도 달라진다. “내가 이렇게 생각했어”가 아니라 “이 기준이면 사용자 경험이 이렇게 달라지고, 데이터 품질은 이렇게 지킬 수 있다”로 대화가 바뀌기 때문이다.

 

정리하면, 이번 피드백은 기능을 더 ‘똑똑하게’ 만들기 이전에, 설계를 더 ‘정직하게’ 만드는 계기였다. 고객이 체감하는 결과를 기준으로 근거를 다시 세우고, 그 근거가 코드와 데이터 구조로 이어지게 만드는 경험이었다.

 

 

 

8. 마무리하며

프로젝트에 들어가면 공부를 덜할 수도 있다고 생각했지만, 생각보다 해야할 공부가 많았다. 특히 피드백을 통하여 내가 미처 보지 못한 부분이 생긴다는 지점은, 아직도 개발자로서 갈 길이 멀다는 점을 시사하기도 하지만, 동시에 다음 차례의 개발에서는 이러한 일이 없을 경험이 되어준다.

 

다음 시간부터는 본격적으로 내 파트에 대해서 다뤄볼 것이다. 나의 파트는 이전에 얘기했듯 큐레이션 로직을 다루게 되는, 이 부분에 대한 공부 이야기를 시작해볼 예정이다.