SW 외주 개발 절차 총정리: 문의부터 인수인계까지 실제 과정 공개

이 글을 쓴 사람: 외주 개발사 대표 (공학박사, 개발 경력 18년)

SW 외주 개발 회사를 6년째 운영하고 있습니다. 이 글은 클라이언트분들이 가장 많이 궁금해하시는 것 — "실제로 어떻게 진행되나요?" — 에 대한 답입니다. 실제 프로젝트 사례를 곁들여 설명하겠습니다.

※ 이 글에 등장하는 사례는 실제 프로젝트를 바탕으로 하되, 고객사 정보 보호를 위해 업종·규모·기능 등을 각색했습니다.

"견적 좀 받아보려고요"

SW 외주 개발은 대부분 이 한 마디로 시작합니다.

전화, 이메일, 카카오톡 — 경로는 다양하지만, 첫 문의의 90%는 비슷합니다.

"○○ 같은 거 만들고 싶은데, 비용이 얼마나 드나요?"

이 시점에서 클라이언트가 기대하는 건 "3,000만원이요" 같은 숫자입니다.

그런데 저희가 하는 건 숫자를 말하는 대신, 질문을 합니다.

"어떤 서비스인가요?" "누가 쓰나요?" "꼭 있어야 하는 기능이 뭔가요?" "언제까지 필요하세요?"

가끔 이 질문이 귀찮으실 수 있습니다. "그냥 대충 얼마인지만 알려주면 되는데..." 싶으실 거예요. 하지만 이 단계를 대충 넘기면, 나중에 나오는 견적이 쓸모가 없습니다.

소프트웨어 외주 개발 비용 가이드에서 자세히 다뤘지만, 같은 "앱 하나"라도 범위에 따라 1,000만원이 될 수도, 1억이 될 수도 있습니다. 질문 없이 나오는 견적은 최대 범위로 부풀리거나, 아니면 빠진 게 많거나 둘 중 하나입니다.

사실, 기획서를 갖고 오시는 분은 거의 없습니다

이게 현실입니다. 저희 프로젝트의 80% 이상은 기획서 없이 시작합니다.

사례: 공공기관 홈페이지 리뉴얼

한 공공기관에서 연락이 왔을 때, 주신 자료는 이것이 전부였습니다.

"이 사이트 보셨어요? (URL 하나) 이거랑 비슷하게 만들고 싶어요."

기획서 없음. 기능 목록 없음. 화면 설계 없음.

이 한 줄에서 시작해서, 저희가 한 일:

1. 벤치마크 사이트를 분석해서 기능 목록을 뽑았습니다
2. "이 기능은 필요하세요? 이건요?" 하나하나 확인했습니다
3. 벤치마크 사이트를 그대로 따라가면 안 되는 부분을 찾아서 개선안을 제안했습니다
4. 기능명세서를 만들고, 그걸 기반으로 견적을 냈습니다

"비슷하게 만들어주세요"라고 하셨지만, 똑같이 만드는 게 답이 아닌 경우가 많습니다. 벤치마크 사이트의 구조가 해당 기관의 상황과 안 맞는 부분이 있었고, 저희가 다른 방식을 제안드렸습니다. 벤치마크 사이트 하나에서 시작해서, 기획과 개선 제안까지 나온 겁니다.

비슷한 경우가 또 있었습니다.

사례: 교육용 모바일 앱

"실습을 도와주는 학습 앱을 만들고 싶어요."

이게 전부였습니다. 학습 콘텐츠를 어떤 형태로 보여줄지, 실습 결과를 어떻게 기록할지, 진도 관리는 어떻게 할지 — 아무것도 정해진 게 없었습니다.

저희가 요구사항 분석부터 시작해서, 기술 조사를 하고, 기능명세서를 쓰고, 화면 설계를 하고, 그 다음에야 개발에 들어갔습니다.

이게 SW 외주 개발의 현실입니다. "코딩을 시키는 것"이라고 생각하시는 분이 많지만, 실제로는 기획과 설계가 전체 프로젝트의 절반 이상입니다.

기획서가 없다고 걱정하실 필요 없습니다. 대신, 요구사항 1페이지 작성 틀에 적힌 정도만 정리해서 보내주시면 대화를 시작하기 훨씬 수월합니다.

기획이 끝나면, 개발은 생각보다 빠릅니다

기획/설계 단계에서 시간을 제대로 쓰면, 개발 단계는 오히려 순탄합니다. 문제가 생기는 프로젝트의 대부분은 기획을 대충 하고 개발부터 시작한 경우입니다.

개발 중에 저희가 중요하게 생각하는 건 중간 공유입니다.

사례: 시나리오 기반 앱 개발

한 프로젝트에서, 클라이언트가 작성한 기획 문서에 사용 시나리오가 있었습니다. 하지만 시나리오와 실제 구현 사이에는 간극이 있습니다.

저희는 핵심 기능이 하나 붙을 때마다 클라이언트에게 보여줬습니다. "이 시나리오대로 동작하는데, 이게 의도하신 흐름이 맞나요?"

매번 확인하는 게 번거로울 수 있지만, 이렇게 안 하면 3개월 뒤에 전혀 다른 결과물을 받게 됩니다.

검수를 미루면, 프로젝트가 망가집니다

개발사 입장에서 가장 난감한 상황이 있습니다.

중간 시연을 보내드리고 검토를 요청했는데, 연락이 없습니다. 한 달이 지나고, 두 달이 지나고. 그러다 갑자기 연락이 옵니다.

"죄송한데, 이 부분 다 바꿔야 할 것 같아요. 그리고 이것도요. 아, 그리고 이 기능은 빼주세요."

두 달 전에 확인하셨으면 반나절이면 고칠 걸, 그 사이에 그 위에 다른 기능을 얹어놨기 때문에 구조째 뜯어고쳐야 합니다.

이런 경우를 종종 겪습니다. 클라이언트가 본업이 바쁘신 건 이해하지만, 검토가 늦어지면 결국 프로젝트 전체 일정이 밀립니다.

클라이언트가 해주셔야 할 것:

길지 않습니다. 하지만 이걸 안 하시면 개발사는 멈춰야 하고, 다른 프로젝트에 인력을 돌리게 되고, 다시 돌아오는 데 시간이 걸립니다. 일정이 밀리는 이유 중 상당수가 여기에 있습니다. 자세한 내용은 외주 개발 일정이 밀리는 이유 7가지에 정리해뒀습니다.

피드백을 주실 때는 "이거 이상해요"보다 **"이 화면에서 이 버튼 누르면 이렇게 되는데, 이렇게 바꿔주세요"**라고 해주시면 훨씬 빠릅니다. 용어가 어려우시면 비개발자를 위한 개발 용어 정리를 참고하세요.

작은 변경, 큰 변경 — 그 경계

개발 중에 변경 요청은 반드시 생깁니다. 문제는 "이 정도는 당연히 해주는 거 아닌가요?"와 "이건 추가 비용입니다"의 경계가 사람마다 다르다는 것입니다.

사례: 소셜 로그인 추가 요청

한 프로젝트에서, 처음 제안서에는 소셜 로그인이 하나만 명시되어 있었습니다. 개발을 진행하던 중 미팅에서 "다른 소셜 로그인도 넣어주실 수 있나요?"라는 요청이 왔습니다.

솔직히 이건 작은 작업이 아닙니다. 소셜 로그인이 하나냐 두 개냐는 설계부터 차이가 많이 납니다. 인증 플로우, 계정 연동/통합 처리, 에러 핸들링까지 — 겉으로는 "로그인 버튼 하나 추가"처럼 보이지만, 안에서는 꽤 많은 것이 바뀝니다.

그런데 저희는 그냥 "알겠습니다" 하고 넣었습니다.

이건 업체마다 다릅니다. 어떤 업체는 "제안서에 없었으니까 추가 비용입니다"라고 할 수 있고, 그것도 틀린 말은 아닙니다. 저희는 프로젝트 전체를 봤을 때 흡수할 수 있는 범위라고 판단해서 해드린 겁니다. 하지만 새로운 화면을 통째로 추가하거나, 핵심 기능의 방향을 바꾸는 것은 이야기가 다릅니다.

이런 판단이 매번 달라지면 양쪽 다 불편합니다. 그래서 처음에 기준을 정해두는 게 좋습니다:

이 기준이 계약서에 있으면 양쪽 다 편합니다. 비용 구조가 궁금하시면 소프트웨어 외주 개발 비용 가이드를 참고하세요.

인수인계: 끝이 아니라 시작입니다

개발이 끝나면 끝이 아닙니다. 소스코드와 서버를 인수받는 과정이 남아있습니다. 여기를 대충 넘기면, 나중에 다른 업체에 유지보수를 맡기거나 내부 개발자가 이어받을 때 처음부터 다시 분석해야 합니다.

사례: 다른 업체에서 넘어온 웹 프로젝트

한 기업의 웹 서비스 프로젝트는 저희가 처음 시작한 게 아닙니다. 이전 업체가 개발하다가 진행이 안 되어서 저희한테 넘어왔습니다.

코드를 받아봤습니다. 문서는 없었습니다. API 명세도 없었습니다.

코드를 분석해보니, 이후 기능 추가나 유지보수가 매우 힘든 구조였습니다. 저희는 결국 처음부터 다시 개발했습니다. 이전 업체의 코드를 살리는 것보다, 새로 만드는 게 더 빠르고 확실하다고 판단한 겁니다.

이런 일이 생기는 이유는, 이전 업체에서 인수인계를 제대로 안 했기 때문이기도 하지만, 클라이언트가 인수인계를 요구하지 않았기 때문이기도 합니다.

납품받을 때 이것들을 확인하세요:

잔금 지급 전에 받으세요. "나중에 보내드릴게요"는 높은 확률로 안 옵니다.

API 서버와 인수인계에 대해 더 자세한 내용은 API 서버 외주 개발 가이드에서 다뤘습니다.

런칭 후 — 진짜 시작

소프트웨어는 런칭하면 끝이 아닙니다. 실제 사용자가 쓰기 시작하면, 테스트 때 못 잡은 문제가 나옵니다. 이건 버그가 아니라 정상입니다. 어떤 소프트웨어든 그렇습니다.

보통 계약에 하자 보수 기간(런칭 후 1~3개월)이 있습니다. 이 기간에 최대한 많이 쓰고, 문제를 찾아서 수정 요청하세요. 이 기간이 지나면 같은 수정도 비용이 발생합니다.

그 이후의 유지보수는 업체와 별도 협의합니다. 월 정액으로 계약하는 경우도 있고, 건별로 하는 경우도 있습니다. 중요한 건 런칭 전에 이 이야기를 해두는 것입니다. 런칭하고 나서 "유지보수 어떻게 하죠?"라고 물으면 늦습니다.

정리: SW 외주 개발의 실제 흐름

SW 외주 개발에서 가장 흔한 오해는 "돈을 내면 알아서 해주겠지"입니다.

실제로는, 잘 되는 프로젝트일수록 클라이언트가 적극적으로 참여합니다. 업체가 만들고, 클라이언트가 확인하고, 같이 조율하는 과정입니다. 이 과정이 잘 돌아가면 결과물의 완성도가 확연히 달라집니다.

외주 자체가 맞는 상황인지부터 점검하고 싶으시면 외주 개발을 하면 안 되는 5가지 경우를 먼저 보세요.

궁금한 점 있으시면 편하게 문의해 주세요. 상담은 무료입니다.

About

Things workshop (띵스워크샵)

2020년 설립, 소프트웨어 개발 전문 기업입니다.

"안 된다는 말 대신 방법을 찾습니다."

📧 contact@thingsw.com 📞 032-889-0410 🌐 thingsw.com