거짓말이 아니라 침묵입니다

외주에서 발주자가 당하는 일의 대부분은 거짓말 때문이 아닙니다. 묻지 않으면 말하지 않는 것들 때문입니다. 특정 회사를 비난하려는 글이 아닙니다. 업계의 구조가 그렇게 생겼고, 구조는 질문으로만 뚫립니다.

1. 실제로 만드는 사람이 누구인지

계약서에 적힌 회사와 코드를 쓰는 사람이 다른 경우는 생각보다 흔합니다. 하청, 재하청, 프리랜서 재위탁까지 내려가면 발주자가 낸 돈에서 실제 개발에 닿는 몫은 단계마다 줄어듭니다.

물어볼 것: "설계와 코드를 실제로 누가 하나요? 그분과 직접 이야기할 수 있나요?"

2. 견적 안의 버퍼

요구사항이 불확실할수록 견적에는 보험료가 들어갑니다. 그 자체는 합리적입니다. 문제는 그 버퍼가 얼마인지, 요구가 명확해지면 줄어드는지 아무도 먼저 말하지 않는다는 것입니다.

물어볼 것: "범위가 확정되면 조정되는 항목이 있나요? 어떤 가정 위에서 산정된 금액인가요?"

3. 유지보수의 락인 설계

문서가 없고, 인수인계가 부실하고, 소스 소유권이 애매하면, 그 시스템은 만든 회사만 고칠 수 있게 됩니다. 어떤 곳에서는 이게 사고가 아니라 재계약 장치입니다.

물어볼 것: "소스와 Git 소유권, 문서와 인수인계 범위가 계약서에 있나요? 다른 팀이 이어받을 수 있는 상태로 납품되나요?"

4. '무료 수정'의 범위 게임

"수정 무제한 해드립니다"는 영업 단계에서 가장 후하게 나오는 약속입니다. 말하는 쪽에서는 당장 비용이 드는 게 아니니 쉽게 붙여 줄 수 있는 문구이기 때문입니다. 문제는 계약서에 '수정'이 무엇인지 정의가 없다는 데서 시작합니다. 발주자는 화면 구성을 바꾸는 것도 수정이라 생각하고, 개발사는 문구와 색상 손보는 정도를 수정이라 생각합니다. 같은 단어에 서로 다른 뜻으로 서명한 셈이니, 분쟁은 예정돼 있습니다.

무제한이라는 말 자체가 나쁜 게 아닙니다. 기준 없는 무제한이 문제입니다. 참고로 저희도 무제한 피드백을 내겁니다. 다만 기준을 같이 겁니다. 해당 스프린트 범위 안에서는 횟수 제한 없이 반영하되, 자전거를 자동차로 바꾸는 요구는 수정이 아니라 새 프로젝트라는 것. 이 기준이 문서에 있느냐 없느냐가 같은 '무제한'의 운명을 가릅니다.

물어볼 것: "수정과 추가의 기준이 문서로 정의돼 있나요? 판단이 갈리면 누가 어떻게 정하나요?"

5. 일정 지연의 진짜 원인

지연 공지는 보통 기술 문제로 설명되지만, 실제 원인은 여러 프로젝트를 병렬로 돌리는 리소스 구조인 경우가 많습니다. 내 프로젝트가 지금 몇 순위인지는 아무도 먼저 말해 주지 않습니다.

물어볼 것: "진행 상황을 어떤 주기로, 어떤 형태로 보여 주시나요? 동작하는 결과물 기준인가요?"

질문이 곧 계약 조건입니다

다섯 가지 질문에 구체적으로 답하는 회사라면, 어디든 꽤 믿을 만한 곳입니다. 얼버무린다면, 그 침묵이 답입니다. 발주자가 겪는 반대편 이야기는 외주 개발사의 '을질'에서 이어집니다.

저희가 이 질문들에 어떻게 답하는지는 회사 소개에 그대로 적어 두었습니다. 확인 가능한 약속의 형태로요.