인하우스 vs 외주, 비용이 아니라 변경 횟수로 갈립니다

개발자를 뽑을지 외주를 줄지 고민하실 때 대부분 계산기부터 켜십니다. 연봉과 견적을 나란히 놓고 어느 쪽이 싼지 따집니다. 그런데 그 계산은 끝까지 가도 답이 안 나옵니다.

인하우스와 외주의 손익분기는 금액이 아니라, 그 프로젝트에서 요구사항이 몇 번 바뀌느냐에서 갈립니다. 변경이 거의 없는 프로젝트는 외주가 압도적으로 쌉니다. 변경이 잦은 프로젝트는 아무리 계산해도 외주가 싸게 나오지 않습니다. 금액이 비슷해 보여도 그렇습니다.

개발 인력을 고민하시면서 이런 생각 하셨을 겁니다.

"개발자 한 명 연봉이면 외주 한 번 돌리는 값인데… 어느 쪽이 싼 거지…"

"외주 맡겼다가 나중에 바꿔달라고 하면 또 돈 달라고 하겠지. 지난번에도 그랬는데.."

"우리 프로젝트가 어느 쪽에 맞는지를 내가 무슨 수로 판단해…"

세 질문에 순서대로 답하겠습니다.

인하우스와 외주는 실제로 무엇이 다른가요?

두 방식의 차이는 비용 구조가 아니라, 변경이 발생했을 때 무슨 일이 벌어지는가에 있습니다.

표를 보시면 알겠지만, 비용 항목만 놓고는 우열이 안 갈립니다. 갈리는 건 세 번째 줄입니다.

인하우스 개발 비용은 연봉으로 계산하면 되나요?

연봉으로 계산하면 실제 회사가 부담하는 금액의 상당 부분이 빠집니다.

한국인공지능·소프트웨어산업협회(KOSA)가 공표한 2026년 적용 기준으로, 응용SW개발자의 월 평균임금은 775만 원입니다. 이 금액은 기본급만이 아니라 제수당·상여금·퇴직급여충당금·4대 보험 사업자 부담금까지 모두 포함된 실지급 인건비입니다. (아이티데일리 보도)

단순 계산으로 연 9,300만 원입니다. 채용 공고에 적히는 연봉 숫자와는 다른 값입니다.

여기에 견적서에는 절대 안 나오지만 인하우스에는 반드시 붙는 것들이 있습니다.

• 채용에 들어가는 시간과 비용, 그리고 채용이 안 될 경우의 지연
• 장비, 소프트웨어 라이선스, 업무 공간
• 프로젝트와 프로젝트 사이의 유휴 기간
• 퇴사 시 인수인계에 드는 공수

반대로 외주에도 견적서 밖의 비용이 있습니다. 발주사 담당자가 회의하고 검수하고 피드백하는 시간입니다. 이건 청구되지 않을 뿐 사라지지 않습니다.

그래서 양쪽 다 계산하면, 상당수 프로젝트에서 두 숫자는 생각보다 가깝게 나옵니다. 비용으로 답이 안 나온다는 건 이런 뜻입니다.

외주에서 요구사항이 바뀌면 어떻게 되나요?

외주 계약은 특정 시점의 요구사항을 기준으로 맺어지고, 그 기준을 벗어나는 변경은 매번 협의 절차를 거칩니다.

이건 외주사가 야박해서가 아닙니다. 소프트웨어 개발이 원래 그런 성격을 갖고 있어서입니다. 과학기술정보통신부가 배포한 공공소프트웨어사업 과업변경 가이드도 소프트웨어사업이 시스템을 구축하는 과정에서 요구사항이 구체화되는 특성을 갖는다는 점을 전제로 절차를 설계하고 있습니다. (보안뉴스 보도)

문제는 협의 자체가 비용이라는 점입니다.

변경이 한 달에 한 번이면 협의 절차는 감당할 만합니다. 그런데 변경이 주 단위로 들어오면 어떻게 될까요. 개발보다 협의에 쓰는 시간이 더 길어집니다. 이 지점에서 외주는 금액과 무관하게 비효율적인 선택이 됩니다.

요구사항이 자주 바뀌는 프로젝트에서 외주가 비싸지는 이유는 견적이 올라가서가 아니라, 협의가 개발을 밀어내기 때문입니다.

우리 프로젝트는 어느 쪽이 맞나요?

아래 다섯 문항 중 세 개 이상에 '예'라면 인하우스가 맞습니다.

1. 기획이 아직 확정되지 않았고, 만들면서 정해야 할 것이 많은가
2. 시장이나 기술 환경이 빠르게 바뀌어서 방향 수정이 잦을 것 같은가
3. 출시가 끝이 아니라 오랫동안 계속 고쳐 나갈 서비스인가
4. 이 기술이 회사의 핵심 경쟁력이라 사내에 남아야 하는가
5. 개발 수요가 프로젝트 단위가 아니라 상시로 발생하는가

반대로 '아니오'가 많다면 외주가 맞습니다. 범위가 명확하고, 한 번 만들면 크게 바뀌지 않고, 개발 수요가 상시가 아닌 프로젝트라면 인하우스는 대부분 과잉입니다. 만들고 나서 그 인력이 할 일이 없어집니다.

크로플 대표 임호범은 이 기준을 이렇게 정리합니다.

"기획이 완성되지 않았고, 변수가 많은 프로젝트, 그리고 지속적으로 유지보수가 장기적으로 필요한 기획은 인하우스로 개발하는 게 낫습니다." — 임호범, 주식회사 크로플 대표

외주사가 할 말은 아니라고 생각하실 수 있습니다. 그런데 저희는 실제로 상담에서 이렇게 말합니다. 맞지 않는 프로젝트를 받으면 결국 양쪽 다 손해이기 때문입니다.

크로플은 왜 알레오를 직접 개발했나요?

저희가 만든 서비스 알레오는 위 다섯 문항에 전부 '예'가 나오는 프로젝트였습니다. 그래서 외주를 주지 않고 인하우스로 개발했습니다.

알레오는 AI 검색 최적화와 콘텐츠 자동화를 다루는 서비스입니다. 이 영역은 몇 달 단위로 판이 바뀝니다. 검색엔진의 기준이 바뀌고, AI 답변 엔진의 인용 방식이 바뀌고, 그때마다 제품이 해야 할 일이 달라집니다.

"외주로 개발했다면, 빠르게 변하는 AI 시대에 중간중간 기획이 바뀌기 마련인데 그걸 다 반영할 수 없었을 겁니다. 인하우스로 개발했기 때문에 그때그때 변화하는 기획이나 아이디어를 바로 반영할 수 있었습니다." — 임호범, 주식회사 크로플 대표

이 경험은 저희가 클라이언트 프로젝트를 볼 때 기준이 됐습니다. 상담에서 기획이 아직 안 잡혔고 변수가 많다는 게 보이면, 전체를 한 번에 계약하기보다 범위를 쪼개거나, 아예 인하우스를 권합니다.

어떤 형태의 프로젝트가 외주로 잘 굴러갔는지는 크로플이 진행한 프로젝트 사례에서 확인하실 수 있습니다.

정리하면

인하우스와 외주는 비용으로 우열이 갈리지 않습니다. 양쪽 다 견적서 밖에 숨은 비용이 있고, 제대로 계산하면 생각보다 비슷해집니다.

갈리는 지점은 하나입니다. 이 프로젝트에서 요구사항이 얼마나 자주 바뀔 것인가. 자주 바뀐다면 인하우스, 범위가 명확하다면 외주입니다. 기획이 미확정이고 변수가 많고 장기 유지보수가 필요하다면, 외주사가 드리는 말이지만 사람을 뽑으시는 게 맞습니다.

지금 고민 중인 프로젝트가 있다면, 위 다섯 문항부터 체크해 보세요. 세 개 이상 '예'가 나오는지가 먼저입니다.

범위가 명확한 쪽이라면, 견적을 어떻게 읽어야 하는지는 외주 개발 견적이 3배씩 차이 나는 이유에서 다뤘습니다.

크로플에 프로젝트 문의하기 →

자주 묻는 질문

Q. 인하우스와 외주를 섞어서 쓸 수도 있나요? 가능하고, 실제로 흔한 방식입니다. 초기 구축은 외주로 빠르게 끝내고 운영·개선만 사내에서 맡거나, 반대로 핵심 로직은 사내에서 하고 주변 기능을 외주로 돌리는 구조입니다. 이 경우 소스코드 인수인계 조건을 계약 단계에서 반드시 정해야 합니다.

Q. 개발자 한 명만 뽑아도 인하우스가 되나요? 서비스 규모에 따라 다릅니다. 기획·디자인·개발·배포를 한 사람이 전부 감당해야 하는 구조라면 속도가 나지 않고, 그 사람이 퇴사하면 서비스가 멈춥니다. 인하우스를 택한다면 최소 인원 구성을 먼저 계산하시는 게 안전합니다.

Q. 외주로 시작해서 나중에 인하우스로 전환할 수 있나요? 가능합니다. 단 전환 시점에 소스코드·산출물·문서가 온전히 넘어와야 합니다. 계약서에 소유권과 인계 범위를 명시하지 않으면 전환 자체가 어려워집니다.

Q. 스타트업 초기에는 어느 쪽이 유리한가요? 초기 제품은 대부분 기획이 확정되지 않아 위 다섯 문항에서 '예'가 많이 나옵니다. 다만 채용이 늦어지면 출시 자체가 늦어지므로, MVP까지는 외주로 빠르게 만들고 이후 인하우스로 넘기는 방식도 자주 쓰입니다. 자금 상황과 시장 진입 시점에 따라 판단이 갈리며, 투자·재무 관련 결정은 전문가 확인이 필요합니다.

글쓴이 · 임호범 — 주식회사 크로플 대표. 자체 서비스 알레오를 인하우스로 개발·운영하며, 그 경험을 클라이언트 프로젝트의 판단 기준으로 씁니다.