대표가 개발을 모르면 생기는 일 — 그리고 최소한 알아야 할 것

먼저 분명히 해두겠습니다. 창업자가 개발을 할 줄 알아야 한다는 얘기가 아닙니다.

훌륭한 대표 중에 코드 한 줄 못 짜는 분들 많습니다. 문제는 개발을 못 하는 게 아니라, 개발을 판단할 기준이 없는 것입니다. 이 둘은 완전히 다릅니다.

개발을 몰라서 생기는 실제 손해

18년 동안 옆에서 지켜본, 비개발 대표가 반복해서 겪는 손해는 대략 이렇습니다.

• "거의 다 됐다"는 말을 그대로 믿는다. 진척을 확인할 방법이 없어서, 눈에 보이는 화면만으로 판단합니다. 그러다 마지막에 몰아서 문제가 터집니다.
• 비싼 게 좋은 건 줄 안다. 반대도 마찬가지입니다. 견적의 근거를 물어볼 수 없으니 숫자만 보고 결정합니다.
• "이거 하나만 추가"의 무게를 모른다. 버튼 하나 같은데 실제론 구조를 바꿔야 하는 요청인지 구분이 안 됩니다.
• 나중에 딴 개발사로 못 옮긴다. 코드가 어떻게 관리되는지, 내 소유가 맞는지 확인 안 하고 넘어갔다가 발이 묶입니다.

이건 대표의 잘못이 아닙니다. 아무도 알려주지 않았을 뿐입니다.

개발자가 될 필요는 없습니다

다행히, 위 손해를 막는 데 코딩 실력은 필요 없습니다. 필요한 건 질문하는 능력과 최소한의 판단 기준입니다.

알아야 할 최소한

① 진척은 화면이 아니라 "쓸 수 있는 범위"로 묻는다. "거의 다 됐죠?" 대신 "지금 실제로 끝까지 동작하는 기능이 뭐예요?"라고 물으세요. 화면이 뜨는 것과 실제로 쓸 수 있는 건 다릅니다.

② 견적의 근거를 요구한다. 총액만 보지 말고 "이 금액이 어떤 작업들로 나온 건가요?"를 물으세요. 근거를 설명 못 하는 견적은 위험합니다. 설명할 수 있는 개발사는 신뢰할 수 있습니다.

③ 중간 산출물을 자주 본다. 완성될 때까지 기다리지 말고, 2~3주에 한 번은 실제로 만져볼 수 있는 걸 요구하세요. 방향이 틀렸을 때 빨리 바로잡는 게 가장 큰 비용 절감입니다.

④ 코드 소유권과 인수인계를 처음에 못 박는다. "작업 결과물(코드·계정·데이터)은 제 소유가 맞나요?", "나중에 다른 팀에 넘길 수 있나요?"를 계약 전에 확인하세요. 이걸 안 물으면 나중에 발이 묶입니다.

⑤ "간단한 거"라는 말을 경계한다. 개발에서 정말 간단한 건 생각보다 적습니다. 요청이 간단해 보여도 "이거 하면 일정에 얼마나 영향 가요?"를 한 번 물으면, 서로 오해가 줄어듭니다.

결국 필요한 건 통역이 되는 파트너

솔직히 말하면, 위 다섯 가지를 매번 챙기는 것도 쉽지 않습니다. 그래서 더 중요한 건 개발을 창업자의 언어로 설명해주는 파트너를 만나는 겁니다.

좋은 개발 파트너는 대표를 개발자로 만들려 하지 않습니다. 대신 대표가 판단할 수 있게 근거를 풀어서 설명합니다. 그런 파트너 한 명이 위 다섯 가지를 대신 지켜줍니다.

---

개발을 모르는 건 흠이 아닙니다. 다만 판단 기준 없이 통째로 맡기면 손해를 봅니다. 코딩을 배우실 필요는 없습니다. 질문할 줄 알고, 설명해주는 파트너를 고르실 줄 알면 충분합니다. MVP 개발이 고민되신다면 mvpit.dev에서 편하게 이야기 나눠보고 싶습니다.