개발사를 선택하는 기준은 제안서 밖에 있습니다

제안서와 포트폴리오는 발표 역량을 보여줄 뿐 실제 작업 품질을 증명하지 않습니다. 제안서 문서 밖에서 확인할 수 있는 신호만 모았습니다.

제안서 두 곳을 받아보셨습니다. 한 곳은 표지부터 화려하고 사례 사진이 빼곡합니다. 다른 한 곳은 수수하고 문장도 짧습니다. 둘 중 어느 쪽이 일을 더 잘할지는 이 문서만으로 알 수 없습니다.

제안서는 발표 역량을 보여줍니다

제안서를 쓰는 일과 화면을 설계하고 코드를 짜는 일은 다른 기술입니다. 발표 자료를 잘 만드는 팀과 프로젝트를 끝까지 끌고 가는 팀이 항상 같지는 않습니다.

포트폴리오도 마찬가지입니다. 완성된 화면만 나열되어 있습니다. 그 화면에 이르기까지 무엇을 물었는지, 어디를 고쳤는지는 보이지 않습니다.

그래서 제안서와 포트폴리오 바깥을 봐야 합니다. 발표 자료에는 담기지 않는 부분들입니다. 회의 중 오가는 질문, 계약서에 적힌 문장, 계정을 여는 방식이 그렇습니다.

질문을 되던지는지 보십시오

견적을 요청했을 때 돌아오는 답이 금액뿐인지, 되묻는 질문이 붙어 있는지가 첫 신호입니다. 화면 수와 기능 목록만 보고 바로 숫자를 냈다면 빈칸을 스스로 채워 넣었다는 뜻입니다.

무엇이 포함되고 무엇이 빠지는지, 어떤 방식으로 만들지, 프로젝트 종료 후에 무엇이 이어지는지. 이런 질문을 먼저 던지는 곳이 있습니다. 같은 조건을 여러 곳에 똑같이 보내면 어느 쪽이 되묻는지 바로 드러납니다. 왜 같은 조건에 다른 금액이 오는지는 같은 사양인데 견적이 다른 이유에 적어 두었습니다.

되묻는 질문의 수준도 함께 보십시오. 화면 개수를 확인하는 질문이 있고 데이터를 누가 책임지고 권한을 어디에 둘지 확인하는 질문이 있습니다. 둘은 무게가 다릅니다.

못 하는 것을 먼저 말하는 곳이 있습니다

무엇이든 가능하다고 답하는 제안은 다시 살펴봐야 합니다. 기술적으로 어렵거나 일정이 빠듯한 항목은 실제로 존재합니다.

안 되는 부분이나 시간이 걸리는 부분을 먼저 짚어주는 곳이 있습니다. 이런 설명은 회의 중 질문에서 드러나지, 제안서 문서에는 잘 나오지 않습니다.

범위는 문서에 적혀야 남습니다

회의에서 오간 말은 양쪽 기억에 다르게 남습니다. 문서에 항목으로 적히지 않으면 나중에 「그건 포함인 줄 알았다」는 말이 나옵니다. 그때는 이미 만드는 중입니다.

견적서나 계약서에 포함 항목과 제외 항목이 나란히 적혀 있는지 확인하십시오. 포함만 적고 제외를 안 적은 문서는 절반만 적은 문서입니다.

관리자 페이지, 디자인 수정 횟수, 콘텐츠 입력처럼 구체적인 항목이 적혀 있는지 보십시오. 있으면 그 회사는 범위를 실제로 따져본 셈입니다. 항목 없이 「요청사항 반영」이라는 문장 하나로 끝나 있으면 그 자리에서 되물으십시오.

계정과 자산의 명의를 계약 전에 묻습니다

스토어 계정, 도메인, 호스팅, 소스 저장소, 분석 도구 권한. 이것들이 누구 이름으로 열리는지는 계약 전에 정해집니다. 열고 난 뒤에 바꾸려면 절차가 따로 붙습니다.

항목별로 무엇이 걸리는지는 웹사이트를 넘겨받을 때 확인할 목록에 정리해 두었습니다. 앱이면 스토어 계정 쪽을 보십시오. 여기서 볼 것은 그 항목을 개발사가 먼저 꺼내는가입니다.

계정을 개발사 이름으로 먼저 열고 나중에 옮기겠다는 제안을 받으실 수 있습니다. 이전 과정에서 잃는 이력과 권한이 생긴다는 점은 짚고 넘어가야 합니다.

계약 전에 「이 프로젝트에서 만들어지는 계정과 코드는 누구 이름으로 남습니까」라고 물어보십시오. 이 질문에 바로 답이 나오는지, 확인 후 알려드리겠다고 하는지를 보시면 됩니다.

완성 이후는 계약서에만 적힙니다

유지보수 조항과 인계 문서가 계약서 안에 있는지 확인하십시오. 만들고 넘기는 계약만 맺으면 완성 이후에 생기는 일을 맡을 사람이 계약서 안에 없습니다.

재빌드, 버전 업데이트, 서버 갱신. 시간이 지나야 생기는 일들입니다. 만들 때는 존재하지 않으니 제안서에도 나오지 않습니다.

이 항목이 계약서에 조항으로 있는지가 그래서 신호가 됩니다. 조항이 없다는 것은 그 일을 아직 아무도 생각하지 않았다는 뜻입니다.

연락 창구가 한 사람인지 보십시오

제안 단계에서 만난 담당자와 실제 작업을 진행하는 담당자가 같은 사람인지 확인하십시오. 프로젝트 중간에 창구가 바뀌면 앞서 나눈 이야기를 처음부터 다시 설명해야 하는 상황이 생깁니다.

창구가 여러 명으로 나뉘어 있어도 괜찮습니다. 다만 질문 하나를 보냈을 때 누구에게 물어야 하는지 고객이 알고 계셔야 합니다. 답이 돌아오는 속도도 제안서에는 적히지 않는 정보입니다.

첫 미팅에서 「프로젝트가 진행되는 동안 연락할 사람은 누구입니까」라고 물어보십시오. 이름 하나로 명확히 답하는 곳과 부서 이름으로 뭉뚱그리는 곳이 있습니다.

에이전시가 필요 없는 경우도 있습니다

지금 필요한 것이 랜딩 페이지 한 장이라면 에이전시를 쓸 이유가 크지 않습니다. 템플릿 기반 빌더로도 원하는 형태를 충분히 만들 수 있는 규모입니다.

사내에 개발 인력이 있다면 외주보다 채용이나 내부 배정이 나을 수 있습니다. 반복해서 손이 가는 프로젝트라면 매번 밖에 맡기는 쪽보다 안에서 계속 다루는 쪽이 유리합니다.

지금 사이트나 앱이 문제없이 돌아가고 있다면 굳이 손대지 않는 편이 맞습니다. 잘 돌아가는 것을 바꾸는 작업은 새로 만드는 작업보다 위험이 더 클 수 있습니다.

세 경우가 아니라면, 특히 처음 만드는 프로젝트이거나 범위가 크다면 위의 신호를 하나씩 확인해 보십시오.

그래서 지금 이 신호들을 다 확인해야 합니까?

네, 지금 확인하셔야 합니다. 제안서를 받아 놓고 고민하는 사이에도 계약 조건은 정해지지 않은 채 남아 있습니다.

계약서에 포함과 제외가 적히지 않은 채 서명하면 범위를 되돌릴 방법이 마땅치 않습니다. 계정 명의도 같습니다. 개발사 이름으로 먼저 열면 이전 과정에서 이력과 권한을 잃을 수 있습니다. 질문을 미룬 만큼 되돌리는 비용이 커집니다.

연락 창구와 완성 이후 조항도 마찬가지입니다. 작업이 시작된 뒤에 담당자가 바뀌거나 유지보수 조항이 없다는 사실을 알게 되면 선택지는 이미 줄어 있습니다. 묻기 가장 쉬운 때는 서명 전인 지금입니다.

결론은 하나입니다. 포함 항목과 계정 명의, 종료 후 조항, 연락 창구를 서명 전에 문서로 확인하는 것입니다.