개발사와의 첫 미팅은 대개 발주자가 설명하고 개발사가 질문하는 자리입니다.
그런데 그 질문의 대부분은 첫 미팅에서 답할 수 없는 것들입니다.
"락업 기간은 몇 개입니까."
"보상 계수는 바뀔 수 있습니까."
"키는 누가 보관합니까."
답이 없으면 개발사는 가정으로 채우고, 그 가정이 몇 달 뒤 추가 비용과 재작업으로 돌아옵니다.
요구사항은 기능의 이름 목록이 아닙니다
발주자가 준비하는 요구사항은 대개 기능의 이름 목록입니다. 토큰, 지갑, 예치, 보상, 운영 규칙.
개발사가 필요로 하는 것은 이름이 아니라 각 기능이 어떻게 동작해야 하는지, 무엇이 정해졌고 무엇이 미정인지입니다.
이 차이를 메우는 일은 개발사의 일이 아닙니다.
개발사는 사업을 모르고, 사업을 아는 사람만이 어느 값이 바뀔 수 있고 어느 값이 굳었는지 압니다.
그래서 요구사항 정리는 개발 착수 전에 발주자 쪽에서 끝나 있어야 하는 일입니다.
FD인터내셔널이 프로젝트를 보는 순서는 진단 → 설계 → 실행 → 운영 → 확장입니다.
개발사에 넘기는 시점은 실행의 시작이고, 그 앞의 진단과 설계가 이 목록입니다.
정리 1 · 정해진 값과 미정인 값을 먼저 나눕니다
각 기능의 세부 값을 두 칸으로 나눕니다. 지금 정할 수 있는 것과 나중에 바뀔 수 있는 것.
정해진 값은 그대로 코드에 들어가고, 미정인 값은 나중에 바꿀 수 있게 설계돼야 합니다.
이 구분이 없으면 개발사는 전부 결정으로 가정해 굳히거나, 전부 미정으로 가정해 크게 잡습니다.
미정인 값은 없애는 것이 아니라 표시하는 것입니다.
"보상 계수는 시장 반응을 보고 조정할 예정"이라는 한 줄이 있으면 개발사는 그 값을 설정 가능하게 만듭니다.
그 한 줄이 없으면 코드에 박히고, 바꾸려면 재배포입니다.
정리 2 · 되돌릴 수 없는 항목의 답은 미리 있어야 합니다
배포 뒤에 고칠 수 없는 항목이 있습니다.
총 발행량.
발행 권한.
초기 배분.
관리자 권한의 종류.
전송 제한 여부.
이 항목의 답은 개발사가 물어보기 전에 있어야 합니다.
이 답은 기술 답이 아니라 사업 답입니다.
발행량은 토큰 경제구조에서, 권한은 규제 검토와 운영 계획에서, 전송 제한은 법률 검토에서 나옵니다.
법률 검토가 필요한 항목은 법무법인의 의견이 필요한 영역이고, 그 의견이 나오기 전에 배포 일정을 잡으면 순서가 뒤집힙니다.
이 목록의 답이 비어 있는 상태로 착수하면 개발은 진행되다가 그 항목 앞에서 멈춥니다. 멈춘 기간은 개발사의 일정에도 발주자의 비용에도 들어갑니다.
정리 3 · 운영을 누가 맡는지 정합니다
배포 뒤에 키를 누가 보관하는지, 모니터링을 누가 하는지, 장애가 나면 누가 대응하는지, 거래소 연동 요청이 오면 누가 답하는지.
이 답에 따라 개발사에 요구할 범위가 달라집니다.
자체 인력이 맡는다면 인수인계 문서와 운영 도구가 요구사항에 들어가야 하고, 개발사가 맡는다면 운영 기간과 대응 조건이 계약에 들어가야 합니다.
인수인계 문서는 코드 설명이 아니라 운영 절차서여야 합니다. 누가 언제 무엇을 확인하는지가 적혀 있어야 실제로 쓰입니다.
가장 흔한 문제는 이 답이 없는 상태로 개발만 계약하고, 배포 다음 날부터 대응할 사람이 없는 경우입니다.
개발사와의 계약은 끝났고, 팀에는 코드를 아는 사람이 없습니다.
정리 4 · 책임의 경계는 발주자가 먼저 문서로 제시합니다
감사는 누가 받고 지적 사항은 누가 고치는가.
요구사항이 바뀌면 그 비용은 누가 부담하는가.
배포는 누가 실행하는가.
문제가 생기면 누가 책임지는가.
이 답은 개발사가 제안서에 각자 다르게 적어옵니다.
발주자가 먼저 문서로 제시하면 개발사들이 같은 조건 위에서 제안하게 되고, 제안서가 비교 가능해집니다.
정리 5 · 만들지 않기로 한 것을 적습니다
요구사항에 빠져 있는 것이 무엇인지도 적어야 합니다.
이번에 만들지 않는 기능.
나중으로 미룬 기능.
온체인이 아니라 서버에 두기로 한 부분.
이것이 없으면 개발사는 관례대로 채웁니다. 웹3 프로젝트니까 이것도 온체인, 저것도 온체인.
만들지 않기로 한 것을 적는 것은 범위를 줄이는 가장 확실한 방법입니다.
하지 않는 결정 역시 전략입니다. 다만 하지 않는 것에도 다음 계획이 있어야 합니다. 나중으로 미룬 기능은 어떤 조건이 되면 다시 볼지를 함께 적습니다.
정리해두면 첫 미팅의 성격이 바뀝니다
이 다섯 가지를 정리한 뒤 개발사를 만나면 첫 미팅이 달라집니다.
질문에 답하는 자리가 아니라 방식을 논의하는 자리가 됩니다.
제안서는 비슷한 크기로 돌아오고, 남는 차이는 개발사의 경험과 방식의 차이입니다.
착수 뒤에도 달라집니다. 개발이 멈추는 지점이 줄어듭니다.
가정으로 채운 부분이 없으니 나중에 "그건 그렇게 하는 줄 알았다"는 대화가 사라집니다.
회의의 절반이 사업 질문으로 채워지는 장면
FD가 발주자 옆자리에서 개발 회의를 지켜보며 반복해서 본 장면은 회의의 절반이 사업 질문으로 채워지는 것입니다.
개발사가 묻고, 발주자가 그 자리에서 처음 생각합니다. 회의는 길어지고 결정은 다음 회의로 넘어갑니다.
반대로 위의 다섯 가지가 한 장으로 정리돼 있던 팀은 첫 회의가 짧게 끝났습니다.
개발사가 "이 문서면 됩니다"라고 말하는 순간을 여러 번 봤습니다.
그 한 장을 만드는 데 걸린 시간은 대개 며칠이었고, 그것이 몇 달의 재작업을 줄였습니다.
기술은 사업을 위해 존재합니다. 요구사항 문서는 그 문장을 실제 형태로 옮긴 것입니다.
이 목록을 그대로 가져가 직접 정리하셔도 충분합니다. FD가 제공하려는 것은 업무 수행이 아니라 판단의 질을 높이는 것이기 때문입니다.