말로 들은 요청을 기능 명세로 바꾸는 과정

첫 외주 프로젝트를 시작하면서 가장 먼저 느낀 건, 클라이언트의 요청은 처음부터 “기능 명세” 형태로 오지 않는다는 점이었다.
개발자 입장에서는 기능명, 데이터 구조, 화면 흐름, 예외 상황, 관리자 권한 같은 것들이 필요하다.

하지만 클라이언트 입장에서는 보통 이렇게 말하게 된다.
“견적을 볼 수 있으면 좋겠어요.”
“후기도 있으면 좋을 것 같아요.”
“관리자가 관리할 수 있으면 좋겠어요.”
“수정은 어렵지 않았으면 좋겠어요.”
이 말들은 분명 중요한 요구사항이지만, 그대로는 개발을 시작하기 어렵다.

그래서 이번 프로젝트에서 가장 먼저 해야 했던 일은 클라이언트의 말을 개발 가능한 기능 단위로 바꾸는 것이었다.

처음 받은 요청 정리하기

처음 클라이언트가 원했던 것은 기본적으로 회사 소개 홈페이지였다.
기존에는 아임웹 같은 홈페이지 제작 툴을 사용해 간단히 만들려고 했지만, 원하는 레이아웃이나 기능을 자유롭게 넣기 어렵고 수정도 불편하다고 했다.

처음 들은 요청을 정리하면 이런 느낌이었다.

• 회사 소개용 홈페이지가 필요하다
• 서비스 내용을 보여주고 싶다
• 사용자가 예상 비용을 확인할 수 있으면 좋겠다
• 후기를 작성할 수 있으면 좋겠다
• 관리자가 후기를 관리할 수 있으면 좋겠다
• 나중에 가격이나 옵션을 수정하기 쉬웠으면 좋겠다
• 실제 운영할 사이트이기 때문에 배포까지 필요하다

이 상태에서는 아직 “무엇을 어떻게 만들지”가 명확하지 않았다.

예를 들어 “견적을 확인할 수 있으면 좋겠다”는 말만 해도 여러 방식이 가능하다.

• 단순히 가격표를 보여주는 방식
• 사용자가 옵션을 선택하면 합산되는 방식
• 견적 문의 내용을 DB에 저장하는 방식
• 관리자에게 접수 내역이 보이는 방식
• 문자나 알림까지 연결하는 방식

같은 말이라도 구현 범위에 따라 개발 난이도와 구조가 완전히 달라진다.
그래서 바로 코드를 작성하기보다는, 먼저 요구사항을 기능 단위로 쪼개야 했다.

견적문의 기능으로 구체화하기

가장 먼저 구체화한 기능은 견적문의였다.
클라이언트가 원한 것은 사용자가 사이트에서 예상 상조 비용을 한눈에 확인할 수 있는 기능이었다.
여기서 중요한 건 “견적 문의”라는 이름이지만, 실제로는 처음 단계에서는 문의 접수보다 “견적 계산기”에 가까웠다는 점이다.

그래서 다음과 같은 질문을 던졌다.

• 기본 금액은 얼마로 고정할 것인가?
• 어떤 옵션을 선택할 수 있어야 하는가?
• 옵션 가격은 자주 바뀌는가?
• 가격 수정은 누가 할 것인가?
• 사용자가 선택한 견적 결과를 저장해야 하는가?
• 관리자에게 견적 이용 횟수를 보여줘야 하는가?

이 질문을 바탕으로 기능 범위를 정리했다.

최종적으로 견적 기능은 이렇게 정리되었다.

• 기본 금액은 600,000원으로 고정
• 음식 서빙 도우미, 수의, 관, 서비스, 차량 옵션 제공
• 사용자가 select 박스로 옵션 선택
• 선택할 때마다 총액 실시간 계산
• 옵션 데이터는 Google Sheet에서 불러오기
• 가격이 비어 있거나 숫자가 아니면 0원 처리
• 네트워크 오류 시 안내 문구 표시
• 관리자 페이지에서 견적 사용 횟수 확인

처음에는 단순히 HTML에 옵션을 하드코딩할 수도 있었다.
하지만 실제 운영에서는 가격이나 옵션명이 바뀔 가능성이 있었다.
클라이언트가 개발자가 아니기 때문에, 나중에 옵션을 수정할 때마다 코드를 수정해야 한다면 유지보수가 어려워질 것 같았다.

그래서 Google Sheet를 견적 옵션 관리용 데이터 소스로 사용하는 방향을 잡았다.
이렇게 하니 클라이언트는 스프레드시트에서 가격을 수정할 수 있고, 사이트는 해당 데이터를 API로 불러와 화면에 보여주는 구조가 되었다.

후기 기능으로 구체화하기

다음으로 정리한 것은 후기 기능이었다.
처음에는 “후기 작성 탭이 있으면 좋겠다” 정도의 요청이었다.

하지만 후기는 단순히 입력창 하나를 만드는 것으로 끝나지 않는다.
후기를 작성하면 어디에 저장할지, 누가 삭제할 수 있을지, 비밀번호는 어떻게 처리할지, 관리자는 어떤 권한을 가질지 정해야 했다.

처음에 확인한 질문은 이런 것들이었다.

• 회원가입이 필요한가?
• 작성자는 이름만 입력하면 되는가?
• 동명이인이 있으면 어떻게 구분할 것인가?
• 사용자가 본인 후기를 삭제할 수 있어야 하는가?
• 삭제할 때 어떤 인증을 사용할 것인가?
• 관리자는 모든 후기를 삭제할 수 있어야 하는가?
• 후기가 많아지면 페이지네이션이 필요한가?

클라이언트와 이야기하면서 회원가입은 만들지 않기로 했다.
사이트 성격상 사용자가 후기를 남기기 위해 회원가입까지 하는 건 부담스럽다고 판단했다.
대신 작성자가 이름과 비밀번호를 입력하고, 나중에 같은 비밀번호를 입력하면 삭제할 수 있도록 정리했다.

최종 후기 기능은 이렇게 정리되었다.

• 이름 입력
• 비밀번호 입력
• 후기 내용 입력
• 비밀번호는 최소 4자리
• 후기 내용은 1자 이상이면 등록 가능
• 등록 후 최신순으로 목록 표시
• 25개 초과 시 페이지 이동
• 작성자는 작성 시 입력한 비밀번호로 삭제 가능
• 비밀번호가 틀리면 안내 문구 표시
• 관리자는 모든 후기를 강제 삭제 가능
• 후기 비밀번호는 DB에 평문 저장하지 않고 해시 저장

이 과정에서 “간단한 후기 기능”도 실제로는 꽤 많은 정책이 필요하다는 걸 느꼈다.
특히 비밀번호 저장 방식은 중요했다.
외주 프로젝트라고 해서 보안을 대충 처리할 수는 없었다.
그래서 비밀번호는 평문이 아니라 해시로 저장하는 방식으로 정리했다.

관리자 기능으로 구체화하기

처음에는 관리자 페이지가 꼭 필요한지 애매했다.
하지만 후기 기능이 생기고, 견적 계산 기능이 생기면서 관리자가 확인해야 할 정보도 생겼다.
클라이언트가 직접 후기 목록을 보고 삭제하거나, 사이트가 얼마나 사용되는지 확인할 수 있으면 좋겠다는 방향으로 정리되었다.

관리자 기능을 정리하면서 확인한 질문은 다음과 같았다.

• 관리자 계정이 필요한가?
• 단일 비밀번호로 충분한가?
• 관리자는 어떤 데이터를 볼 수 있어야 하는가?
• 후기를 강제로 삭제할 수 있어야 하는가?
• 방문 수나 견적 사용 횟수를 볼 필요가 있는가?
• 통계는 누적, 연도, 월 단위로 볼 수 있어야 하는가?

처음부터 복잡한 로그인 시스템을 만들 필요는 없다고 판단했다.
관리자가 여러 명이 아니고, 운영 규모도 크지 않았기 때문에 단일 관리자 비밀번호 방식으로 시작했다.

최종 관리자 기능은 이렇게 정리했다.

• 관리자 비밀번호 입력 후 접속
• 전체 후기 목록 조회
• 후기 강제 삭제
• 페이지 방문 수 확인
• 견적 사용 횟수 확인
• 등록 후기 수 확인
• 누적, 올해, 이번 달 기준 통계 표시
• 관리자 API는 비밀번호 헤더 없이는 접근 불가

관리자 페이지는 단순해 보여도 운영자에게는 중요한 화면이다.
그래서 너무 화려하게 만들기보다는, 필요한 데이터를 빠르게 확인할 수 있도록 구성하는 데 집중했다.

“이건 필요할까?”를 질문으로 바꾸기

이번 요구사항 정리 과정에서 가장 많이 했던 생각은 “이 기능이 정말 지금 필요한가?”였다.
외주 프로젝트에서는 기능을 많이 넣는다고 항상 좋은 결과가 나오지는 않는다.
기능이 늘어나면 개발 기간도 늘고, 유지보수도 어려워진다.

그래서 어떤 기능이 떠오를 때마다 바로 구현하기보다는 질문으로 바꿔 확인하려고 했다.

예를 들어 이런 식이다.

“후기가 있으면 좋겠다.”
→ 회원가입 없이 작성해도 괜찮을까?
→ 삭제는 누가 할 수 있어야 할까?
→ 비밀번호를 잊어버리면 어떻게 할까?
→ 관리자가 강제로 삭제할 수 있어야 할까?

“견적 기능이 있으면 좋겠다.”
→ 가격은 자주 바뀔까?
→ 가격 수정은 누가 할까?
→ 선택한 견적을 저장해야 할까?
→ 지금은 계산만 보여줘도 충분할까?

“관리자 페이지가 있으면 좋겠다.”
→ 어떤 데이터를 봐야 할까?
→ 통계는 얼마나 자세해야 할까?
→ 여러 관리자 계정이 필요한가?
→ 단일 비밀번호로 충분한 규모인가?

이렇게 질문으로 바꾸니 기능 범위가 훨씬 명확해졌다.
그리고 클라이언트도 막연히 “있으면 좋겠다”고 생각했던 기능을 실제 운영 관점에서 다시 생각해볼 수 있었다.

요구사항 정리가 중요한 이유

이번 프로젝트를 하면서 요구사항 정리가 개발의 시작이라는 걸 많이 느꼈다.
요구사항이 흐릿한 상태에서 바로 개발을 시작하면, 나중에 수정이 계속 발생한다.

물론 외주 프로젝트에서 변경은 어느 정도 자연스러운 일이다.

하지만 처음에 방향을 정리하지 않으면, 작은 수정이 아니라 구조를 다시 바꿔야 하는 상황이 생길 수 있다.
예를 들어 견적 옵션을 처음부터 코드에 하드코딩했다면, 나중에 “가격을 직접 수정하고 싶다”는 요구가 나왔을 때 구조를 다시 바꿔야 했을 것이다.

후기 기능도 마찬가지다.
처음에 비밀번호 없이 삭제 기능을 만들었다면, 나중에 본인 확인 문제가 생겼을 수 있다.

요구사항 정리는 단순히 문서를 만드는 일이 아니라, 나중에 생길 문제를 미리 줄이는 과정에 가깝다.

외주에서 기능 범위를 정하는 법

외주 프로젝트에서는 “어디까지 만들 것인가”를 정하는 게 정말 중요하다.
기능을 많이 넣을수록 좋아 보일 수 있지만, 실제로는 비용, 기간, 유지보수까지 함께 늘어난다.

특히 클라이언트가 개발을 잘 모르는 경우에는 어떤 기능이 간단하고 어떤 기능이 복잡한지 감을 잡기 어렵다.
그래서 이번에는 기능을 크게 세 가지로 나눠서 생각했다.

첫 번째는 반드시 필요한 기능이다.

• 회사 정보
• 서비스 안내
• 견적 계산
• 연락처
• 기본 후기 기능

두 번째는 운영 편의를 위해 필요한 기능이다.

• Google Sheet로 견적 옵션 관리
• 관리자 후기 관리
• 방문/견적/후기 통계
• 관리자 페이지

세 번째는 나중에 추가해도 되는 기능이다.

• 복잡한 회원 시스템
• 견적 문의 저장 및 알림
• 관리자 계정 여러 개
• 결제 기능
• 문자 발송 연동

이렇게 나누니 지금 당장 필요한 범위와 나중에 확장할 수 있는 범위가 구분되었다.
처음부터 모든 기능을 넣기보다는, 현재 운영 규모에 맞는 기능을 먼저 만들고 이후 필요할 때 확장하는 쪽이 더 현실적이라고 판단했다.

이번 과정에서 배운 점

이번 요구사항 정리 과정에서 가장 많이 배운 건, 개발자는 코드를 작성하기 전에 먼저 번역을 해야 한다는 점이다.
여기서 번역은 언어 번역이 아니라, 클라이언트의 말을 개발 가능한 기능으로 바꾸는 일이다.

“견적을 보고 싶다”는 말을 데이터 구조, API, UI, 예외 처리, 운영 방식으로 바꿔야 한다.
“후기를 쓰고 싶다”는 말을 저장 방식, 삭제 정책, 관리자 권한으로 바꿔야 한다.

이 과정을 대충 넘기면 개발 중간에 계속 흔들린다.
이번 프로젝트에서는 처음부터 완벽하게 정리한 것은 아니었지만, 기능을 하나씩 구체화하면서 방향을 잡아갈 수 있었다.

그리고 그 과정 자체가 외주 프로젝트에서 중요한 경험이 되었다.

회고

두 번째 기록을 쓰면서 다시 느낀 건, 요구사항 정리는 생각보다 개발자의 역량이 많이 드러나는 부분이라는 점이다.

단순히 “가능합니다”라고 말하는 것보다, 어떤 방식이 유지보수에 좋은지, 지금 필요한 기능인지, 나중에 확장할 수 있는 구조인지 함께 고민하는 것이 중요했다.

이번 프로젝트에서는 클라이언트가 처음부터 명확한 기획서를 준 것이 아니었기 때문에, 대화를 통해 기능을 계속 다듬어야 했다.
그 과정이 쉽지는 않았지만, 덕분에 실제 운영을 고려한 구조로 프로젝트를 발전시킬 수 있었다.

다음 글에서는 이 요구사항을 바탕으로 어떤 기술 스택을 선택했는지 정리해보려고 한다.
단순히 익숙한 기술을 고른 것이 아니라, 비용, 유지보수, 운영 방식까지 고려하며 선택한 과정이었다.