코드 작성보다 먼저 해야 할 일: 요구사항 파악
코딩보다 먼저 할 일이 있다면 바로 요구사항 파악입니다. 흐릿한 요구사항을 바탕으로 코드를 작성하면, 코드를 쓰고 지우고를 반복하게 됩니다. 협업 중심의 실무 환경에서, 주니어 개발자가 시간을 아끼고 빠르게 성장할 수 있는 요구사항 파악 루틴을 공유합니다.
주니어 개발자였던 저는 오직 코드를 잘 작성하는 것에만 집중했습니다. 프로젝트를 시작하면 일단 에디터를 열고 코드를 쓰기 바빴습니다. 그런데 프로젝트의 규모가 클수록, 기간이 길어질수록, 협업 포인트가 많을수록 일이 자꾸만 꼬이고, 개발했던 내용을 반복해서 수정하게 되었습니다.
결국 처음 계획했던 아키텍처는 흐트러지고, 누더기 같은 코드만 남는 경우가 많았습니다.
지금 돌이켜보면 이유는 분명했습니다.
‘무엇을 어떻게 만들어야 하는지’가 명확하지 않았던 것입니다.
애자일 조직과 속도감이 만든 함정
저희 회사 대부분의 제품 조직은 기획자, 디자이너, 개발자, 데이터 분석가 등 다양한 직군이 한 팀에 있는 목적 조직입니다. 이 구조는 하나의 목표를 빠르게 달성하기 위해 설계된 구조이고, 문서 기반의 커뮤니케이션보다는 회의나 구두를 통한 유연한 협업이 일반적이며, 주로 애자일 방식으로 일합니다. 요구사항은 고정된 명세가 아니라, 개발 중간에도 얼마든지 바뀔 수 있습니다. 기술적 한계, 우선순위, 더 나은 아이디어가 생기면 기획 자체가 달라지기도 합니다.
이런 구조는 빠르고 민첩한 협업이 가능하다는 장점이 있지만, 한편으로는 요구사항 파악을 건너뛰고 바로 코드를 작성하게 되는 함정을 만들기도 합니다.
- “일단 짜 보고 고치면 되지”
- “처음부터 전부 다 알 필요는 없어. 코드를 작성하다가 헷갈리는 게 있으면 옆자리 동료한테 물어보면 되니까.”
- “나는 개발자니까 코딩만 잘하면 되는 거 아니야? 요구사항을 명확히 제시해줘야지”
이런 생각들이 프로젝트의 진행을 더디게 만들었습니다.
애자일 개발에 대한 오해
많은 사람이 애자일 개발을 ‘계속 바꾸는 방식’ 또는 ‘자주 바뀌는 방식’으로 오해하곤 합니다. 하지만 애자일은 본질적으로 ‘짧은 주기로 고객에게 가치를 전달하며 점진적으로 개선하는 방식’입니다.
즉, 스프린트와 같은 하나의 주기 안에서는 요구사항이 명확히 확정돼야 합니다. 그렇지 않으면, 코드를 쓰고 또 지우고를 반복하다가 결국 아무것도 완성하지 못하게 됩니다.
요구사항 파악은 개발의 시작이다
프로젝트를 시작할 때 저는 이렇게 생각합니다.
“내가 해야 할 일은 TO-BE와 AS-IS의 차이(diff)를 구현하는 것이다.”
기획자가 설계한 미래 결과물을 TO-BE, 현재 코드의 상태를 AS-IS라고 할 수 있습니다. 이 두 상태의 차이가 바로 제가 해야 할 작업입니다. 즉, 개발해야 할 범위(diff) = TO-BE - AS-IS인 셈입니다. TO-BE는 기획자나 디자이너가 기대하는 결과물이지만, 항상 구체적이지는 않습니다. 그래서 개발자의 관점에서 이것이 구현 가능한지, 누락된 부분은 없는지를 꼼꼼히 살펴야 합니다.
이를 위해 먼저 현재 코드의 상태(AS-IS)를 정확히 이해하고, TO-BE를 달성하려면 어떤 수정(diff)이 필요한지를 정리합니다. 이 과정이 바로 요구사항 파악입니다. 요구사항을 정확히 파악했을 때 비로소 코드 작성을 시작할 수 있습니다.
그렇다면, 요구사항을 실제로 어떻게 파악하면 좋을까요?
요구사항 파악 루틴 만들기
요구사항 파악은 습관이자 루틴입니다. 저는 다음과 같은 방식으로 요구사항을 파악하고 있습니다.
- TO-BE 파악
기획자에게 정책을, 디자이너에게 시안을 꼼꼼히 요청합니다. - AS-IS 파악
현재 코드에서 수정이 필요한 부분을 확인합니다. - diff 계산
어떤 변경이 필요한지(API, UI 등)를 정리하고, 서버 개발자, 디자이너와 협의합니다. - 공유
정리한 요구사항을 팀원과 공유하고 피드백을 받아 이해도를 맞춥니다.
실용적인 요구사항 파악 팁
요구사항 파악이 막막하게 느껴질 수 있지만, 다음 팁들을 적용하면 체계적으로 접근할 수 있습니다.
- 페이지 단위로 파악하기
몇 개의 페이지에서 수정이 필요한지 먼저 구분하고, 페이지별로 파악하면 놓치는 부분 없이 모든 요구사항을 파악할 수 있습니다. - 페이지별로 수정되어야 할 API 파악하기
각 페이지에서 어떤 API가 변경되거나 추가돼야 하는지 파악하면, 서버 개발자와 논의가 수월해집니다. - 작업 계획 초안을 작성하고 팀원에게 리뷰받기
파악한 요구사항을 바탕으로 작업 계획을 간단히 세우고 난 뒤에 팀원에게 검토를 받으면, 놓친 부분을 빠르게 발견할 수 있습니다. - 도메인 지식 익히기
기존 코드나 정책, 데이터 흐름을 잘 이해하고 있으면 TO-BE와 AS-IS를 파악하는 속도가 빨라집니다.
도메인에 익숙해질수록 요구사항 파악도 빨라지고 정확해집니다.
마무리
개발자에게 코드란 요리사의 칼과 같습니다. 요리사는 무엇을 요리할지 정하고 나서야 칼을 들어 재료를 손질합니다. 개발자 또한 요구사항을 확실히 정하고 나서야 코드를 작성해야 합니다.
요구사항 파악은 협업의 시작점이자 주니어 개발자가 빠르게 성장할 수 있는 핵심 역량입니다. 요구사항을 명확히 파악하는 것은 결국 시간을 아끼는 일입니다. 막연한 상태로 코딩을 시작하면, 더 오래 걸리고 더 많이 고치게 됩니다.
혹시 여러분만의 요구사항 파악 루틴이 있나요? 댓글로 함께 나눠주세요.