도메인 이해 없이 분석/설계하고, 협의 없이 개발하면 망합니다.

개발 프로젝트를 리드하다 보면, 새로운 프로젝트에 새로운 팀원들을 데리고 어떻게든 완료해야 하는 상황이 옵니다.

이때 리더의 가장 큰 바람은, 팀원들이 스스로 프로젝트 업무를 이해하고 담당자와 미팅을 주도하면서 분석/설계를 끝낸 후에 개발에 들어가게 만드는 것입니다.

하지만 저를 포함해서 제가 겪어본 개발자들은 기본적으로 '개발만' 하고 싶어 하는 경향이 있습니다. 그래서 분석/설계를 슬쩍 피하거나, 시켜도 마지못해 수동적으로 진행하는 경우가 태반입니다.

이 글의 핵심입니다: 프로젝트 초반에 개발 팀원들이 분석/설계부터 적극적으로 참여하도록 만드는 가장 현실적인 방법은 무엇일까요?

---

그런데 왜 개발자들은 분석/설계를 피하려 할까?

사실, 개발자들이 분석/설계를 피하는 건 정상입니다.

제 경험에 비추어 보면 이유는 명확합니다.

• 업무의 분업화: 프론트엔드, 백엔드, 인프라, 보안... 각자 맡은 전문 분야가 다르다 보니 전체를 아우르는 분석/설계를 해볼 기회도 적고, 개인적으로 할 필요도 못 느낍니다.
• 시간 부족: 프로젝트 일정은 늘 빡빡합니다. 당장 내 앞에 놓인 개발 업무만 해도 익혀야 할 기술과 절차가 너무 많습니다.
• 커뮤니케이션 부담: 분석/설계는 결국 사람과 업무를 이해하는 일입니다. 커뮤니케이션에 익숙지 않은 성향이라면 이게 여간 부담스러운 게 아닙니다.
• 책임지기 싫은 마음: 분석/설계가 틀어지면 프로젝트 전체가 밀립니다. 괜히 나섰다가 욕먹을까 봐 책임을 지기 싫은 마음이 드는 건 당연합니다.
• 뇌의 도피: 코딩은 결과가 바로 눈에 보이고 명확합니다. 반면 분석/설계는 막막하죠. 뇌는 자연스럽게 익숙하고 편한 코딩으로 도망치려 합니다.

이런 상황에서 단순히 "분석해 오세요"라고 지시 하면 개발자들은 잘 움직이지 않습니다.

프로젝트 리더는 팀원들이 분석/설계/개발 업무에 자연스럽게 참여하도록 '판'을 짜주는 역할을 해야 합니다. 거창한 프레임워크가 아니라, 우리 팀에 맞는 현실적인 시스템을 만드는 것이 중요합니다.

---

분석/설계 업무, 정말 개발자 일일까?

답: 네, 맞습니다.

도메인 이해 없이 대충 설계한 데이터베이스 테이블을 생각해 보세요. 장담컨대 100% 다시 뜯어고치게 됩니다.

프로젝트 중간에 테이블 구조를 바꾸는 건, 연관된 모든 코드를 수정해야 하는 엄청난 비용과 고통을 동반합니다. 이 과정을 피하게 해줄 수 있는 핵심 역할은 기획자나 팀장이 아니라 개발자입니다.

해결책: 구체적인 루틴 만들기

개발자 입장에서 분석/설계는 눈에 보이지 않는 작업이라 싫어할 수 있습니다. 그래서 이걸 눈에 보이는 '결과물'로 만들어줘야 합니다. 역할 → 결과물 → 검증이라는 구체적인 루틴을 만드는 겁니다.

구체적인 방법

1. 기능 개발 전, 아래 3가지를 필수로 작성하게 합니다.

   • API 목록
   • 요청 파라미터 및 응답 구조
   • 데이터 모델(테이블) 초안

2. 이 결과물을 Git에 PR 올리듯 공유하고, 동료 리뷰 → 승인되면 개발에 착수할 수 있게 합니다.

3. 핵심은 분석/설계가 더 이상 막연한 일이 아니라, 코드처럼 관리되는 '작업물'이 되도록 하는겁니다. 개발자들은 익숙한 코드 리뷰 방식으로 이 과정을 훨씬 쉽게 받아들입니다.

핵심 아이디어: 개발 팀원들이 '개발만 하고 싶다'는 마음은 유지하되, 대신, '개발'을 하려면 반드시 이 단계를 통과해야만 하도록 구조를 짜서 스스로 움직이게 만드는 과정을 만들어 주도하도록 해야합니다.

---

바로 써먹는 체크리스트와 프로세스

팀장 또는 기획자가 고객의 요구사항을 간단하게 나마 정리를 한 수준에서 개발 팀원들에게 다음의 체크리스트를 작성하기 위한 일정에 대한 마일스톤을 수립합니다.

업무 분석 체크리스트

1. 기능의 배경과 목적

• 이 기능(업무)은 왜 필요하신가요?
• 어떤 문제가 있어서 이 기능을 요청하셨나요?
• 현재는 이 일을 어떻게 처리하고 계신가요?

2. 업무 처리 순서

• 이 업무는 어떤 순서(Step)로 진행되나요?
• 누가(어떤 역할/부서)가, 언제, 무엇을 처리하나요?
• 예시로 실제 업무 한 건이 어떻게 처리되는지 처음부터 끝까지 말씀해주실 수 있나요?

3. 데이터 및 처리 기준

• 이 업무에 쓰이는 데이터에는 어떤 것들이 있나요? (Excel, 문서, 기존 시스템 화면 캡처 등 뭐든 좋습니다.)
• 어떤 값(상태값, 기준값 등)을 기준으로 처리 여부를 판단하시나요?
• '처리 완료'나 '성공/실패'는 어떤 기준으로 확인하시나요?

4. 예외 및 특이 케이스

• 업무 처리 중 자주 발생하는 예외 상황이 있나요?
• 빈도는 낮지만 반드시 처리해야 하는 특수 케이스가 있나요?

5. 완료 후 확인 사항

• 업무가 끝난 뒤 어떤 결과(리포트, 통계 등)가 필요하신가요?
• 완료된 건은 이후에 어떻게 관리되거나 다른 업무에 쓰이나요?

개발 프로세스 표준안

업무 분석 체크리스트를 기준으로 데이터와 기능에 대한 설계/개발 단계에 대한 작업을 진행하는 표준안에 대해 팀원들과 합의합니다.

분석/요구사항 정리 단계

• 업무 담당자와 인터뷰 진행
• 인터뷰 내용으로 기능 명세서(템플릿) 작성
• [필수] 작성된 기능 명세서에 대해 팀 리뷰 완료 및 승인 후 다음 단계 진행

설계 단계

• 확정된 명세서 기준으로 테이블 초안 작성 (테이블/컬럼명/타입 등)
• 화면별 API 목록 및 요청/응답 데이터 정의
• [필수] 설계 내용 등록 후 팀/팀장 리뷰 완료 → 승인 후 개발 착수 가능

개발 단계

• 승인된 설계 산출물을 기준으로 개발 진행
• 퇴근 전, 오류 없는 상태로 일일 커밋 진행

테스트 단계

• 개발 담당자가 직접 테스트 시나리오 작성 및 기능 확인
• 담당자 확인 후 승인 시 최종 완료

프로젝트 운영 규칙

이것만은 반드시 지킵시다.

• 규칙 1: 분석 및 설계 승인 없이는 개발 시작 절대 불가.
• 규칙 2: 구두/메신저 요청은 업무 요청으로 인정 안 함. 모든 요청은 기능 명세서로.
• 규칙 3: 모든 테이블/핵심 기능 변경은 반드시 팀 공유 및 승인 후 반영.

어떤 이유에서든 분석/설계 단계를 대충 넘어가는 것은 단기적으로 시간을 버는 것 같지만, 장기적으로는 운영 및 유지보수에 더 큰 비용과 리스크로 돌아옵니다.

개발자들이 자연스럽게 분석/설계에 참여하도록 구조화된 프로세스와 명확한 산출물을 정의하고, 이를 코드 리뷰와 같은 당연한 문화로 만들어야 합니다.

결국 가장 중요한 것은, 이 모든 과정을 통해 "개발을 하려면, 분석/설계부터 해야 한다"는 인식을 팀원들이 자연스럽게 받아들이도록 만드는 것입니다.