PRD가 도착 했다. 개발자로서 나는

글 작성 시점을 기준으로 최근에 근무 했던 회사에서의 업무 방식을 정리 한다.

 

스타트업에서 제품 개발팀의 서버 프로그래머인 나에게, 업무의 시작을 알리는 PRD가 도착 했다.

PRD(Product Requirements Document)가 도착 했다.

PRD를 리뷰하는 개발자.

PRD는 주로 이런 내용으로 구성 되었다. 대상 고객, 문제 상황, 해결 방안, 사고 실험, FAQ. 대략 우리의 고객이 이러한 문제를 겪고 있는데, 이런 방식으로 해결 해보고자 한다 잘 되었을 경우 이런 사고의 흐름이 예상 된다와 같은 내용이 포함되어 있다.

PRD를 리뷰하는 자리에서 개발자의 역할은 PRD의 완성도를 높힐 수 있는 모든 행위를 하겠지만, 특히 개발자가 할 수 있는 부분을 찾아서 기여 하는 것이다. 개발자로서 PRD를 리뷰하는 자리에서 다음과 같은 책임을 가진다.

• PRD 구성요소에 대한 이해 및 이해를 하려는 시도
• 해결 방안에 대한 구체화 및 최적화

PO가 작성한 PRD에 대해서 명확히 이해 하는것이 필요하다. 우리가 만든 소프트웨어를 실행 하는 컴퓨터는 두루뭉술한 내용을 절대 이해 할 수 없기 때문에 PRD를 명확히 이해하고 정리 되지 않은 부분이 있다면 명확히 질문 해서 결정이 필요하다면 결정하고 정리 하여야 한다. 또한 문제 해결을 위해 시스템적으로 다른 최적의 방안이 있다면 제안 할 수 있어야 한다. 어디까지나 PO에 대한 존중을 기저에 깔아 놓고 말이다.

PRD 리뷰가 끝났고, 우선순위가 높은 고객의 문제에 대해 해결방안까지 PRD 리뷰에 참여한 이해관계자가 모두 이해 하였다면 이제 부터는 개발자들의 시간이 시작 된다.

ADM(Architecture Decision Making)

ADM은 기술적으로 의사결정이 필요한 사안들을 결정하는 시간이다. 이 시간에는 PRD 리뷰 후 작성된 유저 스토리를 기반으로 고수준 아키텍처에 대한 설계, 인터페이스 설계, 도메인 모델링을 진행 하고, 유저 스토리를 개발에 착수 할 수 있는 Task 수준으로 세분화 하는 것을 목표로 한다. 세분화 된 Task를 바탕으로 예상 공수를 측정하고 각 태스크별 기간을 스케쥴링 하여 개발 종료 시점을 이해 관계자에게 전달 하는것 또한 ADM의 목표이다. 이 과정에서 설계의 문서화 까지 자연스럽게 진행 된다.

예를들어 회원가입 기능을 만든다고 가정 해보자.

유저 스토리는 다음과 같다

• 유저는 회원가입을 할 수 있다.

먼저 고수준 아키텍쳐를 결정한다. 회원가입 기능을 구현 하기 위해서 UI 애플리케이션, BFF, 내부서비스인 identity 서비스가 필요 하다. 그리고 각 시스템간의 통신은 HTTP API를 활용 하기로 하였다.

고수준 아키텍쳐 설계

다음으로 도메인 모델링이 진행 된다.

회원가입을 위해서는 유저를 모델링 하는 과정이 필요한데, 모델링이란 실제 개념에서 필요한 부분만 남기는 것을 말한다. 유저는 실제로 무수한 속성을 가지고 있지만, 계정 시스템에서 유저 모델은 이메일, 이름, 패스워드 만 있으면 되겠다. 또한 유저는 식별성을 가져야 하므로 엔터티로 설계 한다.

유저 모델링

또한 사용자의 회원가입 명령을 해결 하기 위해서는 다양한 모델이 필요하다. 우선 회원가입 명령을 실행 하는 명령 실행기, 명령 메세지에 대한 정의, 회원가입 명령을 수행 하고 유저 모델을 영속화 하기 위해 필요한 저장소 추상화인 repository 설계 까지 필요하다.

(회원가입의 경우 패스워드를 단방향 해싱 하는 과정이 당연히 필요 하지만, 게시글 작성 편의상 생략 하겠다.)

도메인 모델 설계

설계를 마쳤다면 Task로 세분화 하고 미팅을 종료 한다. UserStory는 유저의 시나리오 형식으로 티켓을 작성한다면, Task는 실제 개발자가 해야 하는 업무로 티켓을 작성한다. 익숙한 업무의 경우 티켓을 덜 세분화 할 수 있겠지만 설명을 위해 극단적으로 세분화 한다. 참고로 Task의 세분화는 소스코드 커밋 단위에 영향을 미치며 세분화된 커밋은 코드 변경점을 줄인 Pull Request를 만들어 효율적인 코드리뷰 문화 정착에 도움이 된다. 특히 명령 모델이나 엔드포인트 커밋의 경우 외부로 노출 되는 인터페이스 그 자체이므로 꼭 커밋을 분리하여 리뷰를 거치는 편이 좋다.

• [User Story] 유저는 회원가입을 할 수 있다.
  • [Task] BFF Gateway /sign-up 라우팅 추가
  • [Task] IdentityApi /customer/sign-up 엔드포인트 추가
  • [Task] User 모델 추가
  • [Task] SignUpCommand 명령모델 추가
  • [Task] SignUpCommand 명령 처리기 추가
  • [Task] UserRepository 추상화 추가
  • [Task] UserJpaRepository 구현체 추가

공수 측정 및 스프린트 계획 까지 포함 되겠지만 해당 부분은 생략 한다.

개발 시작

TDD 기법을 활용하는 개발자로서 개발 시작 단계에서 가장 먼저 하는 일은 각 구현체의 할 일 목록(테스트케이스)을 작성 하는 것이다.

• [Task] BFF Gateway /sign-up 라우팅 추가
  • [ ] 올바른 명령으로 요청하면, 다운스트림으로 요청을 위임 한다
  • [ ] 다운스트림에서 201 Created를 반환하면, 그대로 반환 한다
  • [ ] 다운스트림에서 400 BadRequest를 반환하면, 그대로 반환 한다
• [Task] IdentityApi /customer/sign-up 엔드포인트 추가
  • [ ] 올바른 명령으로 요청하면, 201 Created 상태코드를 반환 한다
  • [ ] 이미 존재 하는 이메일로 가입을 시도하면, 400 BadRequest 상태코드를 반환 한다
• [Task] SignUpCommand 명령 처리기 추가
  • [ ] 올바른 명령으로 요청하면, 유저가 생성 된다
  • [ ] 이미 존재하는 이메일로 가입을 시도하면 예외를 반환 한다
  • [ ] 패스워드 길이가 정책 보다 짧은 경우 예외를 반환 한다
• [Task] UserJpaRepository 구현체 추가
  • [ ] findByEmail 메서드를 호출하면, 해당 이메일을 가진 유저 모델을 반환 한다
  • [ ] save 메서드를 호출 하면, 유저를 생성 한다

할 일 목록(테스트케이스) 작성을 마쳤다면, 개발을 시작한다. 개발은 TDD 방식으로 실패하는 테스트 하나를 추가 하고, 테스트를 통과하는 운영 코드를 작성 하며 이 과정을 할 일 목록을 모두 소진 할 때 까지 반복 한다.

작성한 코드를 리뷰를 거쳐 메인스트림에 반영 하는것 까지가 개발자의 책임 이지만, 코드리뷰를 마치고 병합된 코드가 CI/CD 프로세스를 통해 운영 환경에 배포되는 회사라고 가정 하겠다.

마치며

이상 개발자로서의 업무 프로세스를 정리해보았다. 어디까지나 단순한 기능 하나를 개발하는 단순한 과정에 불과 하지만 이 글을 통해서 나의 경험과 업무를 대하는 방식에 대해서 전달 할 수 있기를 기대한다. 또한, 드물겠지만 개발 업무 프로세스를 고민하고 있는 분이 계시다면 조금이나마 도움이 되었으면 한다.