들어가며
사실 기술에 대한 글은 많지만, 개발자가 어떻게 업무를 분석하고 작게 나눠야 하는지에 대한 글은 상대적으로 적다.
이 글은 업무 분석에 어려움을 겪는 주니어 개발자분들을 위해 작성됐다.
신입 땐 업무를 어떻게 분석하고 파악하고 구현해야 하는지를 잘 알지 못했다.
무작정 만들어본 뒤 빠진 케이스를 뒤늦게 추가하거나 요구사항 분석을 잘못해 구현 방향이 잘못되어 구현 자체를 다시 한 적도 있었다.
재작업을 하게 됨에 따라 시간도 오래 걸렸고, 급하게 구현하면서 품질을 어느 정도 포기하기도 했다.
이러한 일련의 과정에서 어떻게 하면 이러한 비효율을 줄이고 올바른 기능을 제대로 만들 수 있는지 고민해왔었는데, 답을 내기가 쉽지 않았다.
그도 그럴게, 구현하기전에 모든 문제를 정의하고 설계하는건 굉장히 어렵다. 불투명한 요구사항을 구체화하며 모든 케이스를 정의하는건 어려운 일이다.
그렇다고 해서, 대략적으로 파악하고 구현을 시작하면 종종 예상치 못한 문제에 맞닥뜨리게 된다.
그러한 고민 과정에서 동료의 피드백이 있었고 이를 바탕으로 업무 분석하는 방법을 정의하게 됐다.
지금은 주어진 요구사항이 복잡한 경우 이 포스팅에서 설명할 방법을 사용하여 해결하고 있으며, 이러한 노력으로 시간의 손실은 줄이며 어느 정도 내가 원하는 ‘올바른 기능을 제대로’ 만들 수 있게 됐다.
요구사항을 분석하고 설계하는 방법
처음에 기능 구현 요구사항을 받으면 문제가 하나의 큰 덩어리처럼 느껴지고 어느 부분부터 어떻게 접근해야 할지 감이 잘 오지 않는다.
숙련도가 높은 시니어라면, 보자마자 어떤 지뢰가 있고 어떻게 해결해야 목적을 달성할 수 있는지 알 것이다.
하지만 나는 어디에 어떤 지뢰가 있고, 어떻게 해결해야 하는지 하나하나 고민하고 확인해봐야 했다.
다음은 내가 사전 분석과 설계 구현 정의를 위해 나에게 던지는 질문이다.
(사용자는 포괄적인 의미로 API 혹은 모듈에서 공개한 기능을 사용하는 클라이언트를 의미한다)
1 | - 요구사항 분석 |
위 질문에 맞춰 요구사항에 대한 분석과 설계가 끝났다면 설계에 맞춰 작업계획을 아주 작게 나눈다.
보통 작업 계획 항목대로 PR을 나누게 된다.
- 참고 (PR이 너무 클 경우 리뷰어에게 피로감을 줄 수 있으므로 PR 사이즈는 4~500줄이 넘지 않는 선으로 유지하는 게 좋다)
작업 계획까지 다 정의했다면 동료와 이러한 컨텍스트를 공유한다. 이 크로스 체킹 과정에서 잘못된 방향 혹은 누락된 부분, 더 좋은 방법등에 관해 얘기를 나눌 수 있고 올바른 구현을 할 수 있게 된다.
하지만 이 모든 원칙이 늘 지켜져야만 하는 건 아니다.
원칙이 지금 상황과 맞지 않는다 판단되면 원칙을 무시할 수도 있다. 가장 중요한건 현재 상황에 가장 적합한 해결책이다.