프로덕트 메이커를 찾아오시는 분들 중에는 대기업 개발 조직 출신이나 기술 베이스의 대표님도 많지만, 개발 경험이 없는 분들도 적지 않습니다. 기술 의사결정 앞에서 막막함을 느끼시는 경우가 있습니다. 개발을 잘 모르시더라도 기술 의사결정을 개발사에 전적으로 맡길 필요는 없습니다. 기술 자체를 몰라도, 올바른 질문을 할 줄 알면 충분합니다.

진짜 위험은 기술 무지가 아니라 정보 비대칭이다

비개발자 대표가 기술을 모르는 것 자체는 문제가 아닙니다. 세상의 모든 CEO가 모든 분야의 전문가일 수는 없으니까요. 진짜 위험은 정보 비대칭입니다. 외주 개발사가 "이 프로젝트에는 마이크로서비스 아키텍처가 필수입니다"라고 말했을 때, 그것이 정말 필요한 건지 아니면 견적을 높이기 위한 것인지 판단할 근거가 없는 상황이 문제입니다.

개발사 입장에서 기술적으로 틀린 말을 한 것은 아닐 수 있지만, 초기 MVP에 과도한 아키텍처를 적용하면 예산과 일정 모두 낭비됩니다. 저희가 인수받은 프로젝트 중 이런 경우가 있었습니다. 사용자 1,000명 규모의 초기 서비스인데, 8개 이상의 마이크로서비스로 분리되어 있었습니다.

서비스마다 사용하는 언어가 달랐고(Node.js, PHP가 혼재), 각 서비스가 특정 클라우드 인프라에 종속되어 있어서 다른 환경으로 이전하는 것도 어려웠습니다. 인수인계 문서는 없었습니다. 서비스 간 통신 구조를 파악하는 데만 몇 주가 걸렸고, 단순한 기능 하나를 수정하려면 여러 서비스를 동시에 건드려야 했습니다.

모놀리식 구조로 충분했을 규모에 대기업급 아키텍처를 적용한 결과, 유지보수 비용만 눈덩이처럼 불어난 케이스입니다.

기술 의사결정에서 꼭 확인할 것들

첫째, "왜 이 기술인가요?"라고 반드시 물어보세요. 좋은 개발사라면 기술 선택의 이유를 비개발자도 이해할 수 있는 언어로 설명할 수 있어야 합니다. "업계 표준이니까요"라는 답변은 충분하지 않습니다. 프로젝트의 특성, 향후 확장 계획, 팀 역량을 고려한 구체적인 이유가 있어야 합니다. 설명을 들었을 때 납득이 되지 않는다면, 그것은 여러분의 이해력 부족이 아니라 상대의 설명 부족일 가능성이 높습니다.

둘째, 최소 2~3곳의 비교 견적을 받으세요. 단순히 가격만 비교하는 것이 아닙니다. 각 업체가 제안하는 기술 스택과 그 이유를 비교하면, 공통적으로 언급되는 부분과 한 곳만 유독 다르게 제안하는 부분이 보입니다. 세 곳 중 두 곳이 React를 제안하는데 한 곳만 Angular를 제안한다면, 그 이유를 깊이 물어볼 가치가 있습니다. 그 차이점이 바로 질문해야 할 지점입니다.

셋째, 포트폴리오만 보지 말고 라이브 레퍼런스를 요청하세요. 포트폴리오에 올라온 스크린샷은 디자인만 보여줄 뿐, 실제 서비스 품질을 알 수 없습니다. 현재 운영 중인 서비스의 URL을 받아서 직접 접속해보세요. 로딩 속도는 어떤지, 모바일에서도 잘 동작하는지, 결제 플로우가 매끄러운지. UI만 봐도 이 회사의 퀄리티를 어느 정도 가늠할 수 있습니다.

버튼 하나하나에 인터랙션이 신경 쓰여 있는지, 화면 전환이 자연스러운지, 사용자 입장에서 헷갈리는 흐름은 없는지 — 이런 디테일이 개발사의 수준을 말해줍니다.

넷째, AI에게 물어보세요. 요즘은 ChatGPT나 Claude 같은 AI에게 "이 기술 스택이 우리 프로젝트에 적합한지", "이 견적이 합리적인지"를 물어보면 꽤 수준 높은 답변을 받을 수 있습니다. 개발사가 제안한 기술과 구조를 AI에게 검증받는 것만으로도 큰 실수를 막을 수 있습니다. 물론 AI의 답변이 100% 정확한 것은 아니지만, 최소한 "이상한 점이 없는지" 정도는 충분히 걸러줍니다.

개발사가 특정 기술을 고집하는 이유

개발사가 특정 기술을 강하게 추천할 때 주의가 필요합니다. 그 기술이 프로젝트에 최적이어서가 아니라, 그 회사가 그 기술에 락인(lock-in)되어 있기 때문일 수 있습니다.

자기네가 쓰는 기술만 세계 최고라고 하고, 다른 기술에 대해서는 잘 모르거나 부정적으로만 이야기하는 개발사가 있습니다. 그 기술의 장점은 너무 잘 알지만, 단점은 말하지 않습니다. 다른 기술로 하면 자기네가 수주를 못 받으니까요.

문제는 그 기술이 마이너한 경우입니다. 나중에 유지보수를 다른 곳에 맡기려 해도 해당 기술을 다루는 개발자를 구하기 어렵습니다. 특정 개발사에 영원히 종속되는 구조가 만들어집니다. 기술을 추천할 때 아래 기준으로 확인해보세요.

1. 생태계: 핵심 기능이 오픈소스 라이브러리로 이미 존재하는지. 잘 갖춰진 생태계일수록 개발 속도가 빠르고 비용이 줄어듭니다
2. 개발 생산성: 해당 기술로 실제 개발할 때 속도가 빠른지. 같은 기능을 만드는 데 기술에 따라 2~3배 차이가 날 수 있습니다
3. 인력 수급: 해당 기술을 다루는 개발자가 시장에 충분한지. 나중에 유지보수를 맡길 때 사람을 구할 수 있어야 합니다
4. 인건비: 해당 기술 개발자의 몸값이 적정한지. 마이너한 기술일수록 단가가 높아지고, 대체 인력도 없습니다
5. 단점: "왜 이 기술인지"뿐 아니라 "이 기술의 단점은 뭔지"도 물어보세요. 단점을 말하지 않는 개발사는 그 기술밖에 모르거나, 다른 기술로는 수주가 안 되는 것입니다
6. 이전 가능성: 나중에 다른 업체에서도 유지보수할 수 있는 구조인지

프로덕트 메이커의 접근 방식

저희는 기술 의사결정 과정에서 중간 전달자를 두지 않습니다.

일반적인 개발사에서는 PM이나 영업 담당자가 기술 내용을 전달하는 과정에서 정보가 왜곡되는 경우가 많습니다.

외주 개발사 담당자가 "기술적으로 어렵습니다"라고 하면, 그게 정말 어려운 건지, 단순히 귀찮은 건지, 추가 비용을 받고 싶은 건지 구분할 수 없습니다.

프로덕트 메이커에서는 대표가 직접 기술 의사결정의 배경을 설명드립니다.

"Next.js를 선택한 이유는 SEO가 중요한 프로젝트이기 때문이고, 만약 SEO가 필요 없는 관리자 페이지의 경우 React SPA로도 충분합니다"처럼 대안과 함께 설명드리는 방식입니다. WebGL 프로젝트의 경우에도 "Three.js를 선택한 이유는 커뮤니티 규모와 레퍼런스가 풍부하기 때문이며, 만약 2D 인터랙션만 필요하다면 더 가벼운 라이브러리로도 가능합니다"처럼 구체적으로 안내합니다.

기술적 배경이 있든 없든, 의사결정의 근거가 명확하게 공유되는 구조가 중요합니다. 왜 이 기술인지, 다른 선택지는 뭐가 있었는지, 이 선택의 트레이드오프는 뭔지 — 이걸 설명할 수 있는 개발사와 일해야 나중에 후회가 없습니다.