한 팀 프로젝트에서 회원이 관심 있는 상품을 저장할 수 있는 기능을 만들기로 했습니다. 회의에서는 찜 기능이라는 이름만 정했고, 화면에도 하트 버튼을 배치했습니다. 프런트엔드 담당자는 버튼을 누르면 색상이 바뀌는 기능으로 이해했고, 백엔드 담당자는 회원별로 선택한 상품을 데이터베이스에 저장하는 기능으로 생각했습니다. 기획을 맡은 팀원은 찜한 상품을 별도 목록에서 확인하고 삭제하는 기능까지 포함된다고 예상했습니다.
개발 중간에 결과물을 합쳤을 때 각 담당자가 만든 범위는 서로 달랐습니다. 프런트엔드 화면에는 선택 상태가 임시로 표시되었지만 페이지를 새로 열면 사라졌고, 서버에는 저장 기능만 있어 목록을 불러오는 기능이 없었습니다. 기획자는 사용자가 찜한 상품을 한 화면에서 관리할 수 있어야 한다고 요청했습니다. 팀은 이미 만든 코드를 수정하고 조회 API와 목록 화면을 추가해야 했고, 다른 기능을 개발할 시간도 줄어들었습니다.
문제의 원인은 개발자의 구현 능력이 아니었습니다. 찜 기능이라는 이름에는 합의했지만 누가, 언제, 어떤 행동을 하고, 결과가 어디에 저장되며, 어떤 화면에서 다시 확인할 수 있는지 정하지 않은 것이 원인이었습니다. 기능 이름만 같았을 뿐 각자가 예상한 완성 모습은 달랐던 것입니다.
IT 프로젝트에서 요구사항을 정리해야 하는 이유는 문서를 길게 만들기 위해서가 아닙니다. 기능의 범위와 완료 기준을 같은 의미로 이해하고, 필요한 작업을 일정에 반영하며, 변경이 발생했을 때 영향을 받는 담당자와 기능을 확인하기 위해서입니다. 처음부터 모든 내용을 완벽하게 확정할 수는 없지만 현재 합의한 범위와 변경된 이유를 팀이 함께 확인할 수 있는 상태는 만들어야 합니다.
기능정의는 같은 완성 모습을 예상하게 만듭니다
- 기능 이름보다 사용자의 행동을 먼저 정해야 합니다
로그인, 검색, 게시판, 알림처럼 익숙한 기능 이름만 작성하면 팀원이 내용을 쉽게 이해할 것처럼 보입니다. 하지만 같은 이름 안에도 여러 조건과 세부 동작이 포함될 수 있습니다.
검색 기능을 예로 들어보겠습니다. 누군가는 상품명만 입력하는 단순 검색을 떠올릴 수 있고, 다른 사람은 카테고리와 가격 조건을 함께 선택하는 상세 검색을 예상할 수 있습니다. 검색어가 없을 때 전체 목록을 보여줄지, 최근 검색어를 저장할지, 결과가 없을 때 어떤 안내를 제공할지도 결정해야 합니다.
한 프로젝트에서는 게시글 검색 기능을 구현하기로 했습니다. 프런트엔드 담당자는 제목과 내용을 모두 검색하는 화면을 만들었지만 백엔드에서는 제목만 조회하도록 구현했습니다. 화면에는 작성자 검색 선택지도 있었지만 서버에는 이를 처리하는 조건이 없었습니다. 구현이 끝난 뒤 서로 예상한 범위가 다르다는 사실을 알게 되어 화면과 서버를 다시 수정했습니다.
기능을 정리할 때는 이름만 적지 말고 사용자의 행동 흐름을 함께 작성해야 합니다.
- 사용자는 어느 화면에서 기능을 시작하는가
- 어떤 값을 입력하거나 선택해야 하는가
- 실행하면 화면과 데이터가 어떻게 달라지는가
- 결과는 저장되는가 아니면 일시적으로만 표시되는가
- 사용자는 결과를 어디에서 다시 확인할 수 있는가
검색 기능을 만든다는 문장보다 사용자가 게시판에서 검색어와 검색 대상을 선택하면 조건에 맞는 게시글 목록을 확인할 수 있다는 문장이 더 구체적입니다. 여기에 검색 결과가 없을 때의 처리와 입력 가능한 글자 수까지 정리하면 담당자들이 같은 결과를 예상하기 쉬워집니다.
- 정상 동작만 정하면 예외 상황에서 해석이 갈립니다
기능을 설명할 때 사용자가 올바르게 입력하고 정상적으로 처리되는 상황만 작성하는 경우가 많습니다. 그러나 실제 개발 시간은 잘못된 입력, 권한 부족, 중복 요청, 연결 실패와 같은 상황을 처리하는 데도 사용됩니다.
회원가입 기능에서 이메일과 비밀번호를 입력해 계정을 생성한다는 내용만 정하면 입력 형식이 잘못되었을 때의 처리와 이미 가입된 이메일의 안내가 빠질 수 있습니다. 프런트엔드에서는 버튼을 비활성화하고, 백엔드에서는 오류 응답만 반환하면 된다고 생각할 수도 있습니다. 기획자는 입력창 아래에 구체적인 안내 문구가 표시되기를 기대할 수 있습니다.
한 팀은 파일 업로드 기능을 구현하면서 이미지 파일을 선택해 저장할 수 있다는 정상 흐름만 정했습니다. 개발 후반에 용량이 큰 파일, 지원하지 않는 형식, 같은 이름의 파일을 업로드했을 때 문제가 발생했습니다. 팀원마다 처리 방식이 달라 오류 안내와 저장 규칙을 다시 맞춰야 했습니다.
예외 상황은 모든 가능성을 처음부터 작성하는 방식보다 우선 발생 가능성이 높은 조건부터 정리하는 것이 현실적입니다.
- 필수 입력값이 비어 있는 경우
- 허용된 형식이나 길이를 벗어난 경우
- 같은 데이터가 이미 존재하는 경우
- 접근 권한이 없는 사용자가 요청한 경우
- 외부 서비스나 서버 연결에 실패한 경우
- 처리 도중 사용자가 같은 요청을 반복한 경우
이러한 조건을 작성하면 화면 담당자는 안내 방식과 버튼 상태를 준비할 수 있고, 서버 담당자는 필요한 검증과 응답을 설계할 수 있습니다. 테스트 항목도 개발이 끝난 뒤 급하게 만드는 것이 아니라 기능과 함께 준비할 수 있습니다.
- 완료 기준이 있어야 구현 여부를 함께 판단할 수 있습니다
작업 목록에 회원가입 완료라고 표시되어 있어도 담당자마다 완료의 의미는 다를 수 있습니다. 화면을 만들면 끝났다고 생각할 수 있고, API 연결까지 되어야 한다고 볼 수도 있습니다. 오류 처리와 테스트, 문서 반영까지 마쳐야 완료라고 판단하는 팀도 있습니다.
한 프로젝트에서는 댓글 수정 기능이 완료된 것으로 표시되어 있었습니다. 화면에서 수정 버튼을 누르면 입력창으로 바뀌었지만 서버 연결은 되어 있지 않았습니다. 프런트엔드 담당자는 자신의 화면 작업이 끝났다는 의미로 완료 처리했고, 팀장은 사용자가 실제로 수정한 내용을 저장할 수 있다고 이해했습니다. 발표 전날 서버 연결이 빠졌다는 사실을 발견해 일정이 흔들렸습니다.
완료 기준에는 사용자가 확인할 수 있는 결과가 포함되어야 합니다.
- 수정 버튼을 누르면 기존 내용이 입력창에 표시됩니다.
- 작성자는 내용을 변경한 뒤 저장할 수 있습니다.
- 작성자가 아닌 사용자는 수정 버튼을 볼 수 없습니다.
- 빈 내용은 저장되지 않고 안내가 표시됩니다.
- 저장된 내용은 페이지를 다시 열어도 유지됩니다.
- 관련 API와 화면의 정상·예외 상황을 확인합니다.
이처럼 완료 여부를 행동과 결과로 표현하면 개발자와 기획자, 테스트 담당자가 같은 기준으로 검증할 수 있습니다. 기능정의는 무엇을 만들 것인지뿐 아니라 어떤 상태가 되어야 완성되었다고 판단할 것인지까지 포함해야 합니다.
일정관리는 작업 범위와 우선순위에서 시작됩니다
- 기능을 세분화해야 필요한 시간을 예상할 수 있습니다
프로젝트 일정을 정할 때 로그인 3일, 게시판 5일처럼 큰 기능 단위로 시간을 배정하면 실제 작업량을 놓치기 쉽습니다. 로그인 하나에도 화면 작성, 입력 검증, 서버 요청, 인증 정보 저장, 권한 확인, 오류 처리, 테스트가 포함될 수 있습니다.
한 학생은 팀 프로젝트에서 마이페이지 기능을 사흘 안에 완료하겠다고 계획했습니다. 프로필 화면과 정보 수정만 생각해 기간을 정했지만 실제 개발에서는 비밀번호 확인, 이미지 업로드, 중복 닉네임 검사, 회원 탈퇴까지 필요했습니다. 각 작업에 필요한 서버 기능과 데이터 구조도 달랐기 때문에 예정한 기간을 넘겼습니다.
일정을 현실적으로 정하려면 기능을 담당자가 실행할 수 있는 작업으로 나눠야 합니다.
- 화면과 입력 항목을 구성합니다.
- 필요한 데이터를 불러오는 기능을 연결합니다.
- 사용자 입력값을 검사합니다.
- 변경된 정보를 서버에 저장합니다.
- 권한과 인증 상태를 확인합니다.
- 정상 동작과 주요 오류 상황을 시험합니다.
기능을 나누면 예상하지 못한 작업도 빨리 발견할 수 있습니다. 이미지 업로드에 외부 저장소 설정이 필요하거나 회원 탈퇴가 다른 데이터와 연결되어 있다면 일정에 별도로 반영해야 합니다.
작업을 작게 나누는 목적은 목록을 복잡하게 만드는 것이 아닙니다. 누가 어떤 일을 해야 하고 무엇이 끝나야 다음 작업을 시작할 수 있는지 확인하는 것입니다.
- 모든 기능을 같은 우선순위로 두면 핵심 흐름이 늦어집니다
팀 프로젝트에서는 아이디어를 논의할수록 추가하고 싶은 기능이 늘어납니다. 추천, 알림, 채팅, 소셜 로그인과 같은 기능은 결과물을 풍부하게 만들 수 있지만 모든 항목을 필수로 지정하면 핵심 기능도 완성하지 못할 수 있습니다.
한 쇼핑 프로젝트에서는 개인 추천과 실시간 알림을 차별화 기능으로 정했습니다. 그러나 상품 조회, 장바구니, 주문과 같은 기본 흐름도 완성되지 않은 상태에서 추천 기능을 먼저 개발했습니다. 필요한 사용자 행동 데이터가 충분하지 않았고 주문 구조도 계속 변경되어 추천 로직을 여러 번 수정해야 했습니다.
팀은 일정을 다시 검토한 뒤 사용자가 상품을 찾고 주문을 완료하는 흐름을 필수 범위로 정했습니다. 추천 기능은 기본 구매 흐름이 정상적으로 동작한 뒤 추가하는 항목으로 옮겼습니다.
우선순위를 정할 때는 기능이 흥미로운지보다 다음 기준을 확인해야 합니다.
- 프로젝트가 해결하려는 핵심 문제와 직접 연결되는가
- 다른 기능이 동작하기 위해 먼저 필요한가
- 사용자가 서비스의 주요 목적을 달성하는 데 필요한가
- 현재 인원과 기간 안에서 검증할 수 있는가
- 제외하더라도 핵심 흐름이 유지되는가
우선순위를 낮춘 기능은 실패한 아이디어가 아닙니다. 현재 기간과 인력에서 먼저 완성해야 할 범위를 선택한 것입니다. 면접에서도 많은 기능을 구현했다고 강조하기보다 제한된 기간에 어떤 기준으로 범위를 조정했는지 설명하면 계획 능력을 보여줄 수 있습니다.
- 변경 요청은 추가 작업과 영향 범위를 함께 계산해야 합니다
프로젝트 도중 새로운 아이디어나 사용자 의견을 반영하는 것은 자연스러운 일입니다. 문제는 변경 자체가 아니라 기존 일정과 연결된 기능에 미치는 영향을 확인하지 않고 바로 추가하는 것입니다.
한 팀에서는 개발 후반에 게시글에 파일 첨부 기능을 넣기로 했습니다. 처음에는 화면에 버튼 하나를 추가하는 간단한 작업처럼 보였습니다. 그러나 파일 형식과 크기 제한, 저장 위치, 다운로드 권한, 게시글 삭제 시 파일 처리, 서버 배포 환경까지 함께 결정해야 했습니다.
변경 요청을 바로 적용하면서 백엔드 담당자의 일정이 늘어났고, 기존에 계획한 검색 기능의 테스트가 미뤄졌습니다. 팀은 이후 새로운 요청이 나오면 다음 내용을 먼저 확인했습니다.
- 변경하려는 이유와 해결할 문제는 무엇인가
- 새로 필요한 화면, 서버, 데이터 작업은 무엇인가
- 기존 기능 중 다시 수정해야 하는 부분은 어디인가
- 담당자와 예상 작업 시간은 어떻게 달라지는가
- 기존 일정에서 미루거나 제외할 항목은 무엇인가
- 이번 일정에 반영할지 이후 개선으로 남길지 결정했는가
새로운 기능을 추가하면서 일정은 그대로 유지하려 하면 작업의 질이나 테스트 시간이 줄어들 수 있습니다. 변경 내용을 기록하고 기존 범위와 비교해야 팀이 현실적인 선택을 할 수 있습니다.
협업은 합의된 내용과 변경 이유를 공유하는 과정입니다
- 회의에서 결정한 내용은 실행 가능한 형태로 남겨야 합니다
회의에서 충분히 이야기했다고 생각해도 시간이 지나면 각자가 기억하는 내용은 달라질 수 있습니다. 결정된 사항과 검토 중인 의견이 섞이거나 담당자가 정해지지 않은 채 회의가 끝나면 실제 작업으로 이어지기 어렵습니다.
한 팀은 매주 회의를 진행했지만 결정 내용을 별도로 정리하지 않았습니다. 회의에서 사용자 신고 기능을 추가하기로 논의했으나 신고 사유 선택, 관리자 확인, 신고 누적 처리 중 어디까지 구현할지는 정하지 않았습니다. 프런트엔드 담당자는 신고 화면을 만들었고 백엔드 담당자는 다음 프로젝트로 미뤄진 기능이라고 기억했습니다.
회의 기록에는 대화 전체를 그대로 옮길 필요가 없습니다. 작업에 영향을 주는 내용을 중심으로 남겨야 합니다.
- 최종적으로 결정된 기능과 범위
- 아직 결정되지 않아 추가 확인이 필요한 내용
- 담당자와 완료 목표 시점
- 다른 작업보다 먼저 처리해야 하는 이유
- 기존 계획에서 변경된 항목
- 다음 회의 전에 확인할 질문
회의록이 길어도 결정 사항을 찾기 어렵다면 실제 작업에 도움이 되지 않습니다. 결정, 담당, 기한, 보류 항목이 빠르게 보이도록 구성해야 합니다.
- 화면과 서버의 기준을 연결해야 재작업을 줄일 수 있습니다
프런트엔드와 백엔드가 각각 기능을 이해하고 있어도 주고받는 데이터의 기준이 다르면 통합 과정에서 문제가 발생합니다. 화면에는 필요한 값이 있지만 서버에서 제공하지 않거나, 서버는 값을 전달하지만 화면에서 다른 이름으로 예상할 수 있습니다.
한 프로젝트에서는 주문 상태를 준비 중, 배송 중, 완료로 표시하기로 했습니다. 기획 화면에는 세 단계만 있었지만 서버에서는 결제 대기, 결제 완료, 상품 준비, 배송 시작, 배송 완료로 세분화해 저장했습니다. 두 구조를 어떻게 연결할지 정하지 않아 화면마다 다른 상태가 표시되었습니다.
팀은 사용자에게 보여주는 상태와 내부에서 관리하는 상태를 구분하고 연결 기준을 정했습니다. 결제 완료와 상품 준비는 준비 중으로 표시하고, 배송 시작은 배송 중, 배송 완료는 완료로 보여주기로 했습니다. 취소와 환불 상태도 별도 처리했습니다.
다른 직무가 연결되는 기능에서는 다음 항목을 함께 확인해야 합니다.
- 화면에서 필요한 데이터와 표시 형식
- 서버가 전달하는 필드와 데이터 형태
- 값이 없거나 오류가 발생했을 때의 처리
- 권한에 따라 달라지는 화면과 응답
- 상태가 변경되는 조건과 순서
- 담당자가 각각 구현하고 함께 확인할 지점
이 기준을 미리 맞추면 통합 단계에서 서로의 코드를 문제로 지목하는 상황을 줄일 수 있습니다. 협업은 업무를 나눠 각자 완성하는 것만이 아니라 서로 연결되는 기준을 확인하는 과정입니다.
- 변경 이력이 있어야 결정의 배경을 다시 확인할 수 있습니다
요구사항이 바뀌면 최신 내용만 남기고 이전 내용을 지우는 경우가 있습니다. 하지만 왜 변경했는지 알 수 없으면 같은 논의가 반복되거나 예전 기준으로 만든 기능이 다시 등장할 수 있습니다.
한 팀에서는 회원가입 시 전화번호를 필수로 받기로 했다가 개인정보를 최소한으로 수집하기 위해 선택 항목으로 변경했습니다. 변경된 화면만 남기고 이유를 기록하지 않자 다른 팀원이 주문 연락에 필요하다고 판단해 다시 필수 항목으로 수정했습니다.
팀은 변경 전후의 내용과 결정 이유를 간단하게 남겼습니다. 주문 단계에서 필요한 연락처는 회원가입이 아니라 주문 과정에서 받기로 했고, 회원정보에서는 필수로 저장하지 않기로 했다는 기준도 함께 작성했습니다.
변경 기록에는 다음 내용이 있으면 됩니다.
- 변경된 날짜와 대상 기능
- 이전 내용과 새로 적용할 내용
- 변경이 필요했던 이유
- 영향을 받는 화면과 데이터
- 확인하거나 수정해야 할 담당자
- 일정과 우선순위의 변화
모든 수정 사항을 복잡한 문서로 관리할 필요는 없습니다. 다만 현재 기준이 무엇이고 이전 결정에서 왜 달라졌는지는 확인할 수 있어야 합니다. 이러한 기록은 팀 내부의 혼란을 줄이고 면접에서는 변경에 대응한 경험을 설명하는 근거가 됩니다.
- conclusion
IT 프로젝트에서 요구사항을 정리하는 이유는 개발을 시작하기 전에 모든 내용을 완벽하게 확정하기 위해서가 아닙니다. 팀원들이 같은 기능을 예상하고, 필요한 작업을 일정에 반영하며, 변경이 발생했을 때 영향을 받는 범위를 함께 판단하기 위해서입니다.
기능 이름만 합의하면 각자가 다른 결과를 만들 수 있습니다. 사용자의 시작 행동과 입력 조건, 처리 결과, 예외 상황, 완료 기준까지 정리해야 화면과 서버, 테스트의 범위가 연결됩니다.
일정은 희망하는 완료 날짜만 적는다고 관리되지 않습니다. 기능을 실행 가능한 작업으로 나누고 핵심 사용자 흐름을 기준으로 우선순위를 정해야 합니다. 새로운 요청을 추가한다면 기존 계획에서 무엇을 조정할지도 함께 결정해야 합니다.
- 기능정의에서는 사용자의 행동과 결과, 주요 예외 조건을 작성해야 합니다.
- 일정관리에서는 큰 기능을 담당자가 실행할 수 있는 작업으로 나눠야 합니다.
- 우선순위는 구현하고 싶은 기능보다 핵심 사용자 흐름을 기준으로 판단해야 합니다.
- 변경 요청은 필요한 작업과 기존 기능에 미치는 영향을 함께 확인해야 합니다.
- 협업에서는 결정된 내용과 담당자, 변경 이유를 다시 찾을 수 있어야 합니다.
실제 신입 프로젝트를 살펴보면 기능 목록은 많지만 어떤 조건에서 완료되는지 설명하지 못하는 경우가 있습니다. 개발이 늦어진 이유도 팀원의 실력이나 소통 부족으로만 표현하는 경우가 많습니다. 그러나 내용을 자세히 확인하면 처음 정한 범위가 모호했거나 변경된 기능이 일정에 반영되지 않은 사례가 적지 않습니다.
면접에서는 요구사항을 분석했다는 말만 하기보다 처음 요청에서 불분명했던 부분, 확인한 조건, 팀과 합의한 범위, 변경 이후 조정한 작업을 설명해야 합니다. 기능 하나라도 이러한 과정을 구체적으로 보여준다면 프로젝트를 단순한 코딩 실습이 아니라 업무 흐름을 이해한 경험으로 전달할 수 있습니다.
자신의 프로젝트 기능 목록을 다시 살펴보세요. 기능 이름만 보고도 사용자의 행동과 결과를 설명할 수 있는지, 정상 상황과 주요 오류 조건이 정리되어 있는지, 완료 여부를 팀원이 같은 기준으로 판단할 수 있는지 확인해야 합니다.
결국 요구사항 정리가 실무 역량으로 보이는 순간은 문서를 완성했을 때가 아닙니다. 팀이 같은 결과를 예상하고, 작업 범위와 일정을 현실적으로 조정하며, 변경된 이유를 근거로 다음 행동을 결정할 수 있을 때입니다.
