저는 홈페이지 만드는 회사를 차리기 전에 SI 개발자였습니다. 발주처의 시스템을 대신 만들어주는 일이었고, 제가 있던 현장은 대체로 규모가 컸습니다.

계약서는 수십 장이었고, 요구사항 정의서에는 담당자 서명이 있었습니다. 회의록은 매번 확인을 받아 보관했고, 변경이 생기면 정식 요청서로 접수했습니다. 문서로 할 수 있는 건 다 하는 현장이었다는 뜻입니다.

그런데도 오픈하고 나면 현업에서 안 쓰는 시스템이 나옵니다. 검수는 통과했습니다. 요건도 다 충족했습니다. 그런데 정작 그걸 매일 써야 하는 사람들이 예전 엑셀을 다시 꺼냅니다.

외주 개발은 정해진 금액과 기간 안에 끝나야 하는 일이고, 범위를 넘어서는 만큼이 그대로 손해입니다. 그러니 개발사 입장에서 가장 합리적인 선택은 계약서에 적힌 요건을 정확히, 딱 그만큼만 충족시키는 것입니다.

프로젝트의 질을 가르는 건 대개 요구사항 정의서에 안 적힌 것들입니다. 아는 사람에게는 공기 같고, 모르는 사람에게는 아예 존재하지 않는 정보입니다.

첫 번째 실패를 ‘업체를 잘못 골랐다’로 정리한 분들은 두 번째에 더 나은 회사를 고릅니다. 견적을 더 많이 받고, 포트폴리오를 더 오래 보고, 계약서를 더 꼼꼼히 읽습니다. 전부 맞는 노력입니다.

그런데 두 번 다 확인하지 않은 게 하나 있습니다.

요즘은 화면 만드는 속도가 빨라졌고 결과물의 평균 수준도 올라갔습니다. 어지간한 곳이면 다 그럴듯한 화면을 뽑아냅니다.

그래서 차이가 나는 구간이 옮겨갔습니다. 만드는 단계가 아니라 무엇을 만들지 정하는 단계로요. 단가, 마감, 결재선 같은 보이지 않는 규칙을 캐내서 구조로 옮기는 일은 아직 사람의 몫입니다. AI는 알려주지 않은 규칙을 대신 물어봐주지 않습니다.

거창한 기획서는 필요 없습니다. 필요한 것들을 정리해서 직접 만나보시면 됩니다. 그 자리에서 볼 것은 세 가지입니다.

소유권 조항, 검수 기준, 유지보수 범위는 여전히 계약서에 있어야 합니다. 소스코드와 도메인이 누구 것인지 적히지 않은 계약은 위험합니다.

솔직히 말씀드리면 저도 그 자리에 있던 사람입니다. 요건에 없다는 이유로 그냥 넘어간 적이 있고, 물어보면 일이 늘어난다는 걸 알아서 묻지 않은 적도 있습니다.

그때의 저를 탓하려는 건 아닙니다. 그렇게 굴러가도 아무 문제가 없는 구조였으니까요. 다만 그 구조가 싫어서 나왔습니다.

그래서 저희는 미팅에서 질문이 많은 편입니다. 이 업계는 어떤 순서로 돌아가는지, 하루에 어떤 일을 반복하시는지, 예외적으로 처리하는 건 무엇인지, 고객이 전화로 가장 많이 묻는 게 무엇인지. 홈페이지 만드는 사람이 왜 이런 걸 캐묻나 싶으실 수도 있는데, 그게 저희가 아는 유일한 방법입니다.