프로젝트 진행 방식
프로젝트가 잘못되는 지점은 대개 개발 중간이 아니라 시작 부분입니다. 무엇을 만들지 정하기 전에 개발부터 시작하면 방향을 바꾸는 비용이 계속 커집니다.
일을 시작하는 순서
Bilberrry는 웹 개발, 모바일 앱, 소프트웨어, 디지털 플랫폼을 만드는 미국 시애틀의 IT 개발 회사입니다. 한국과 미국 양쪽 발주처와 일해 온 경험에서 공통으로 확인한 것이 하나 있습니다. 요구사항을 문서로 합의하지 않은 채 화면부터 그리기 시작하면, 나중에 그 화면을 버리는 비용이 훨씬 커집니다.
그래서 이 페이지에는 각 단계에서 무엇을 만들고, 발주처가 어디를 확인하고 어디에 동의해야 다음으로 넘어갈 수 있는지를 순서대로 적었습니다. 단계 이름은 저희가 실제로 쓰는 순서 그대로입니다.
이 페이지에서 다루는 것
요구사항 정리
첫 단계는 만들 것을 문서로 확정하는 일입니다. 사용자가 누구인지, 어떤 문제를 해결하는지, 이번 버전에서 무엇을 빼는지를 정합니다. 빼는 것을 정하는 게 넣는 것보다 어렵고, 대개 더 중요합니다.
이 단계에서는 화면을 그리지 않습니다. 대신 우선순위를 세우고, 기능 사이의 의존 관계를 확인합니다. 결과물은 짧은 범위 문서이고, 발주처가 여기에 동의해야 다음 단계로 넘어갑니다.
발주처가 확인할 것
다음 두 단계
두 단계를 나란히 놓고 보면 차이가 분명합니다. 하나는 만져 보는 초기 형태이고, 다른 하나는 실제로 쓸 수 있는 첫 버전입니다. 목적이 다르므로 확인할 것도 다릅니다.
프로토타입은 실제로 만져 볼 수 있는 초기 형태입니다. 클릭과 화면 이동이 가능한 수준이라, 사용자 흐름에서 어색한 부분을 개발 전에 발견할 수 있습니다. 여기서 발견한 문제는 수정 비용이 거의 들지 않습니다.
이 단계에서 발주처가 확인할 것은 예쁜 모양이 아니라 이 순서로 쓰는 것이 자연스러운가입니다. 실제 사용자 몇 명에게 보여 주면 더 좋습니다.
확인 항목
MVP는 실제로 쓸 수 있는 첫 버전입니다. 핵심 기능만 남기되, 데이터가 저장되고 사용자가 끝까지 흐름을 완료할 수 있어야 합니다. 데모용 화면 모음이 아니라 운영 가능한 제품이어야 합니다.
이 단계에서 기능 경계가 계속 흔들리면 일정이 밀립니다. 그래서 저희는 요구사항 문서를 기준으로 삼고, 범위 변경은 따로 기록합니다.
확인 항목
디자인 시스템
버튼, 입력 필드, 오류 메시지 같은 요소를 한곳에서 정의하고 재사용합니다. 이렇게 하면 새 화면을 만들 때마다 처음부터 디자인하지 않아도 됩니다.
디자인 시스템은 예쁘게 보이려고 만드는 것이 아닙니다. 개발 속도와 일관성을 위해 만듭니다. 발주처가 나중에 다른 팀에 맡기더라도 기준이 남습니다.
정의하는 요소
남는 결과
아키텍처 결정
이 시점에 마이크로서비스냐 서버리스냐 같은 결정을 내립니다. 팀이 작으면 단순한 구조가 유리하고, 트래픽 변동이 크면 관리형 서비스가 부담을 줄여 줍니다. 결정의 이유를 기록해 두면 나중에 팀이 바뀌어도 판단 근거가 남습니다.
팀이 작고 기능이 단순할 때
서버리스와 관리형 데이터베이스로 시작하는 편이 유지보수 부담이 적습니다.
트래픽 변동이 클 때
관리형 서비스를 쓰면 사용량에 따라 자원을 늘리고 줄이는 작업을 직접 하지 않아도 됩니다.
도메인 경계가 분명할 때
마이크로서비스로 나누는 것이 이후 확장에 유리하지만, 운영 인력이 먼저 필요합니다.
기존 인프라를 이어 쓸 때
AWS Amplify처럼 기존 환경과 이어지는 도구를 쓰면 인증과 배포를 새로 만들지 않아도 됩니다.
결정의 이유는 짧은 기록으로 남깁니다. 새 팀이 합류했을 때 같은 논의를 처음부터 다시 하지 않기 위해서입니다.
출시 준비
출시 전에는 배포 절차와 롤백 방법을 확인합니다. 문제가 생겼을 때 이전 버전으로 되돌릴 수 있는지, 로그가 충분한지, 알림이 오는지를 점검합니다. Vercel 같은 플랫폼의 미리보기 배포를 쓰면 변경 사항을 실제 환경에 가깝게 확인할 수 있습니다.
되돌리기
이전 버전으로 되돌리는 절차를 문서로 확인하고, 실제로 한 번 연습해 봅니다.
기록과 알림
오류를 추적할 로그가 충분한지, 문제가 생겼을 때 누구에게 알림이 가는지 정합니다.
저장소와 규칙
코드는 GitHub를 기준으로 정리하고, 배포 파이프라인과 브랜치 규칙을 문서로 남깁니다.
유지보수
출시 후 첫 몇 달은 실제 사용 데이터가 쌓이는 시기입니다. 여기서 나온 피드백으로 우선순위를 다시 정합니다. 유지보수 계약이 있든 없든, 인수인계 문서와 저장소 접근 권한은 발주처에 남습니다.
쌓이는 것
실제 사용 흐름, 자주 막히는 지점, 요청이 몰리는 기능이 드러납니다.
남는 것
인수인계 문서, 저장소 접근 권한, 배포 절차가 발주처에 그대로 남습니다.
일정이 밀릴 때
일정이 밀리는 이유는 대개 기술이 아니라 의사결정입니다. 확인이 늦어지거나 범위가 중간에 바뀌면 그만큼 밀립니다. 그래서 각 단계마다 결정권자를 정해 두고, 확인 기한을 함께 정하는 것을 권합니다.
확인이 늦어질 때
다음 단계 착수가 그대로 밀립니다. 확인 기한을 미리 정해 두면 늦어지는 순간을 알아차릴 수 있습니다.
범위가 중간에 바뀔 때
변경 자체보다, 변경을 기록하지 않는 것이 문제입니다. 요구사항 문서를 기준점으로 두고 변경은 따로 남깁니다.
결정권자가 여럿일 때
최종 결정을 내릴 사람을 단계마다 한 명으로 정해 두는 편이 논의를 줄입니다.
협업 방식
회의를 길게 하는 대신 확인할 것을 명확히 하고, 결정이 필요한 지점에서 발주처의 답을 받습니다. 시간대가 다르면 비동기로 진행하고, 필요한 경우 통화를 잡습니다.
시애틀과 서울처럼 시차가 있는 팀과 일할 때는, 결정이 필요한 항목과 단순히 알려 드리는 항목을 구분해서 보내 드립니다. 답이 필요한 것만 골라 회신하실 수 있습니다.
데모
동작하는 화면을 짧게 공유하고 그 자리에서 확인합니다.
문서
범위, 결정 이유, 배포 절차를 짧게 남겨 기준으로 씁니다.
비동기 진행
시차가 있으면 서면으로 먼저 정리하고 필요할 때 통화합니다.
결정 지점
답이 필요한 시점을 미리 알려 드리고 기한을 함께 정합니다.
단계별 요약
이번 버전에서 빼기로 한 기능 목록, 기능 사이의 의존 관계, 문서에 이름을 올릴 결정권자가 정해졌는지 확인합니다.
화면 모양이 아니라 사용 순서가 자연스러운지 봅니다. 실제 사용자 몇 명에게 보여 주고 나온 의견을 정리할 시점도 함께 정합니다.
데이터가 실제로 저장되고 다시 불러와지는지, 사용자가 끝까지 흐름을 완료할 수 있는지, 범위 변경이 어디에 기록되는지 확인합니다.
버튼, 입력 필드, 오류 화면 같은 반복 요소가 한곳에 정의되어 있는지, 웹과 모바일 화면이 같은 규칙을 쓰는지 봅니다.
마이크로서비스와 서버리스 중 무엇을 골랐는지보다, 왜 그렇게 정했는지가 기록으로 남았는지 확인합니다.
이전 버전으로 되돌리는 절차, 오류를 추적할 로그, 문제 발생 시 알림 대상, 배포 파이프라인과 브랜치 규칙이 문서로 있는지 확인합니다.
인수인계 문서와 저장소 접근 권한이 발주처에 남았는지, 피드백으로 우선순위를 다시 정하는 주기가 있는지 확인합니다.
단계마다 결정권자가 한 명으로 정해졌는지, 확인 기한이 함께 정해졌는지 확인합니다.
만들려는 것이 아직 정리되지 않았더라도 괜찮습니다. 지금 가진 자료와 목표만 알려 주시면 어느 단계부터 시작하는 것이 맞는지 함께 정리해 드립니다.
Bilberrry
600 1st Ave Unit 413, Seattle, WA 98104, United States
월요일–금요일: 오전 9:00 – 오후 6:00
