화면 흐름과 데이터 모델
설계가 끝나면 무엇을 만들지에 대한 문서가 남습니다. 이후 변경이 생기면 이 문서를 기준으로 논의합니다. 바뀐 내용은 문서에 반영해 다시 공유드립니다.
다섯 단계
발견 · 설계 · 구축 · 출시 · 운영의 순서를 그대로 따릅니다
고객 결정 지점
단계마다 무엇을 확인하고 승인할지 미리 정해 둡니다
문서로 공유
완료 · 진행 · 막힌 항목을 나눠 매주 정리합니다
발견
무엇을 왜 만드는지 정리합니다
첫 단계에서는 코드를 쓰지 않습니다. 해결하려는 문제, 지금 쓰는 도구, 사용자가 누구인지, 예산과 기간의 범위를 정리합니다. 여기서 나온 내용이 이후 모든 판단의 기준이 됩니다.
이 단계에서 "이건 만들 필요가 없다"는 결론이 나오기도 합니다. 그런 경우 솔직하게 말씀드립니다. 대신 지금 있는 도구로 해결할 수 있는 부분과, 그래도 개발이 필요한 부분을 나눠서 정리해 드립니다.
설계
화면과 데이터 구조를 확정합니다
발견 단계에서 정리한 내용을 실제 구조로 옮깁니다. 화면 흐름, 데이터 모델, 외부 시스템 연동 범위, 기술 선택을 확정합니다. 이때 플랫폼별 차이와 예외 상황도 함께 다룹니다.
플랫폼별 차이와 예외
웹 · 모바일 · 데스크톱에서 달라지는 동작을 설계 시점에 함께 정리합니다.
연동 범위와 기술 선택
외부 시스템과 주고받는 데이터의 경계를 확정하고, 선택 이유를 문서로 남깁니다.
구축
짧은 주기로 확인합니다
구축은 한 번에 끝내지 않고 짧은 주기로 나눠 진행합니다. 각 주기가 끝나면 실제로 동작하는 결과를 확인하실 수 있습니다. 피드백은 다음 주기에 반영합니다.
이렇게 하면 프로젝트 후반에 방향이 크게 바뀌는 상황을 줄일 수 있습니다. 진행 상황과 남은 작업은 문서로 공유합니다.
- 주기 시작 이번 주기에 만들 기능 범위를 확정하고 착수합니다. 범위 밖으로 넘어가는 요청은 다음 주기 후보로 따로 적어 둡니다.
- 중간 점검 막힌 항목과 예상보다 오래 걸리는 부분을 그때그때 알려드립니다. 결정이 필요한 사항은 선택지와 함께 별도로 표시합니다.
- 동작 확인 주기가 끝나면 실제로 눌러보고 확인할 수 있는 결과를 보여드립니다. 문서로만 확인하는 방식과 다릅니다.
- 피드백 반영 확인하신 내용은 다음 주기에 반영합니다. 반영 여부와 이유는 완료 · 진행 · 막힘 항목에 함께 남깁니다.
출시
배포와 안정화
출시는 서버에 올리는 일로 끝나지 않습니다. 배포 절차, 모니터링, 장애 대응, 되돌리기 방법을 함께 준비합니다. 실제 사용자가 몰릴 때 예상하지 못한 문제가 나오는 경우가 많습니다.
그래서 출시 직후 일정 기간은 안정화에 집중합니다. 이 기간에 발견된 문제는 우선순위를 정해 처리합니다.
- 배포 절차와 되돌리기 방법을 미리 문서로 정리합니다.
- 모니터링 지표와 장애 대응 연락 체계를 함께 확정합니다.
- 안정화 기간에 발견된 문제는 영향도에 따라 우선순위를 매깁니다.
운영
개선을 이어갑니다
출시 이후에는 실제 사용 데이터를 봅니다. 어디서 이탈하는지, 어떤 기능이 느린지, 어떤 요청이 반복되는지를 확인합니다. 그 결과에 따라 개선 순서를 정합니다.
라이브러리 업데이트와 보안 패치도 이 단계에서 다룹니다. 필요하면 인수인계가 가능한 상태로 코드와 문서를 정리합니다. 다른 팀이 이어받을 수 있게 저장소 구조와 배포 권한도 함께 넘겨드립니다.
운영 단계에서 고객이 하는 일
개선 우선순위를 결정합니다. 반복되는 요청과 실제 사용 흐름을 함께 보고, 다음 주기에 무엇을 먼저 손댈지 정합니다.
AI 솔루션
AI 프로젝트에는 두 단계가 더 붙습니다
AI 기능이 포함되면 데이터 준비와 품질 검증이 추가됩니다. 어떤 문서를 쓸지, 권한을 어떻게 나눌지, 답변 품질을 어떤 기준으로 볼지를 먼저 정합니다. 그다음 대표 질문 세트로 반복 검증합니다.
이 과정을 건너뛰면 데모에서는 잘 되지만 실제 업무에서는 쓰기 어려운 결과가 나옵니다. 이 장은 여러 페이지에서 언급하지 않고 여기서만 다룹니다.
데이터 준비
어떤 문서를 쓰고 누가 어떤 범위까지 접근할 수 있는지 먼저 정합니다. 권한이 정리되지 않으면 답변 품질 검증 자체가 어긋납니다.
품질 검증
대표 질문 세트를 정해 반복 실행합니다. 좋은 답변과 그렇지 않은 답변의 기준을 문서로 남겨, 결과가 흔들릴 때 되돌아볼 수 있게 합니다.
출시 이후
실제 사용에서 나온 질문을 검증 세트에 계속 추가합니다. 운영 단계 개선 우선순위에 AI 항목도 함께 반영됩니다.
일정이 밀릴 때
일정이 밀리는 원인은 대개 범위 변경이나 외부 의존입니다. 외부 API 응답이 늦어지거나, 스토어 심사가 길어지거나, 요구사항이 중간에 늘어나는 경우입니다.
범위를 줄일지 일정을 늘릴지는 고객이 결정합니다. 결정 없이 그냥 넘어가는 상황을 만들지 않습니다.
범위가 늘어날 때
추가 요청이 들어오면 이번 릴리스에 넣을지 다음으로 넘길지 선택지를 정리해 보내드립니다.
외부 승인 · 심사
스토어 심사처럼 외부에서 결정되는 대기 시간은 초기 일정에 여유로 반영하고, 리스크가 보이면 미리 알립니다.
우선순위 조정
일정을 지키려면 무엇을 먼저 출시할지 정해야 합니다. 시작점과 보류 항목을 나눠서 보여드립니다.
미리 알리는 원칙
일정에 영향이 생기면 즉시 알립니다. 문제가 확정되고 나서 알리는 방식은 쓰지 않습니다.
내부 팀과 협업할 때, 그리고 진행 상황 확인
역할 나누기
사내 개발팀이 있으면 역할을 나눕니다. 어디까지가 외부 몫이고 어디부터가 내부 몫인지 시작 전에 문서로 정합니다.
공유 채널과 절차
코드 저장소, 배포 권한, 리뷰 절차도 함께 합의합니다. 정기 회의와 공유 채널을 정해 두면 진행 중 혼선이 줄어듭니다.
진행 상황 확인
진행 중인 작업은 문서로 공유됩니다. 완료된 항목, 진행 중인 항목, 막힌 항목을 구분해 볼 수 있습니다. 결정이 필요한 사항은 별도로 표시합니다.
매사추세츠 지역이라면 대면 미팅도 가능하며, 그 외 지역은 미국 동부 시간대 기준으로 화상 회의를 잡습니다. 대면 미팅은 18 Shipyard Dr #2a, Hingham, MA 02043에서 진행됩니다.
자주 받는 질문
프로젝트 기간은 보통 얼마나 걸리나요?
범위에 따라 다릅니다. 초기 릴리스 기준으로 범위를 나눠 제안드리며, 발견 단계에서 대략적인 기간을 함께 정리합니다.
개발 중간에 요구사항을 바꿀 수 있나요?
가능합니다. 다만 일정과 범위에 미치는 영향을 함께 알려드립니다. 범위를 줄일지 일정을 늘릴지는 고객이 결정합니다.
출시 후에도 지원이 가능한가요?
네. 안정화 기간 이후에도 개선과 유지보수를 이어갑니다. 다른 팀이 이어받을 수 있게 문서와 코드를 정리하는 작업도 합니다.