[카테고리:] IT 시스템

사내 시스템 구축을 검토하는 회사는 대부분 같은 장면에서 출발합니다. 부서마다 엑셀 파일이 따로 돌고, 같은 숫자를 두 번 세 번 옮겨 적고, 월말이 되면 누군가 남아서 취합합니다. 담당자가 바뀌면 그 파일이 어디 있는지부터 다시 찾아야 합니다. 그래서 시스템을 만들기로 합니다. 예산을 잡고, 개발사를 정하고, 몇 달 뒤에 오픈합니다.

그리고 반년쯤 지나면, 현업 담당자 모니터에 다시 엑셀 파일이 열려 있습니다. 시스템은 살아 있지만 실제 업무는 그 바깥에서 돌아갑니다. 결재만 시스템에 남기고, 진짜 일은 여전히 메신저와 전화로 처리합니다.

이 결과는 개발이 부실해서 생기는 일이 아닙니다. 화면은 다 있고 버튼도 다 눌립니다. 문제는 만들어진 시스템이 실제 업무와 다르게 생겼다는 것입니다. 그리고 그 차이는 개발이 아니라 발주 단계에서 결정됩니다.

디비컨설팅은 100건 이상의 프로젝트를 수행하면서, 대외 서비스보다 오히려 조직 내부에서 쓰는 시스템을 반복적으로 구축해 왔습니다. 가천대학교의 학사관리 시스템, 센터필드·센트로폴리스·그랑서울 등 프라임 오피스 빌딩의 관리 시스템, LS일렉트릭 테크스퀘어의 산업 B2B 거래 플랫폼이 그런 사례입니다. 이 글은 그 과정에서 반복해서 확인한 실패 지점과, 발주 전에 정리하면 대부분 예방되는 여섯 가지를 정리한 것입니다.

사내 시스템이 대외 서비스보다 실패하기 쉬운 이유

같은 규모, 같은 예산이라도 사내 시스템은 고객용 서비스보다 실패 확률이 높습니다. 기술 난도가 높아서가 아닙니다. 요구사항이 존재하는 방식이 다르기 때문입니다.

요구사항이 문서가 아니라 사람 머릿속에 있습니다

고객용 서비스는 기획서가 곧 정답입니다. 아직 없는 것을 만드는 일이니까요. 반면 사내 시스템은 이미 몇 년째 돌아가고 있는 업무를 옮기는 일입니다. 그 업무의 규칙은 문서가 아니라 오래 그 일을 해 온 담당자의 경험 안에 있습니다.

“이 거래처는 세금계산서를 월말에 한 번에 끊습니다”, “이 품목은 재고가 마이너스로 잡혀도 출고를 막으면 안 됩니다” 같은 규칙은 어느 문서에도 적혀 있지 않습니다. 물어보지 않으면 나오지 않고, 물어봐도 담당자는 그게 특별한 규칙이라고 인식하지 못합니다. 너무 당연해서 말할 생각을 못 하는 것입니다. 이런 규칙은 보통 오픈 직후, 시스템이 정상 처리를 거부할 때 처음 드러납니다.

발주 담당자와 실제 사용자가 다릅니다

대외 서비스는 발주하는 쪽과 성과를 보는 쪽이 대체로 같습니다. 사내 시스템은 다릅니다. 예산과 일정을 관리하는 사람은 경영지원이나 전산 담당이고, 매일 그 화면을 쓰는 사람은 영업·물류·회계 현업입니다.

그래서 검수는 통과하는데 현장에서는 쓰이지 않는 상황이 만들어집니다. 발주 담당자는 “요청한 기능이 다 있는지”를 확인하고, 현업은 “이걸로 오늘 일을 끝낼 수 있는지”를 봅니다. 기준이 다르면 결과도 다릅니다. 무엇을 완료로 볼 것인지의 문제는 개발 검수 기준에서 따로 다뤘습니다.

예외 처리가 업무의 절반을 차지합니다

정상 흐름만 놓고 보면 사내 시스템은 단순합니다. 등록하고, 승인하고, 처리하고, 마감합니다. 실제 업무 시간의 상당 부분은 그 바깥에서 소비됩니다. 승인자가 휴가일 때, 이미 마감한 달의 숫자를 고쳐야 할 때, 계약서와 실제 단가가 다를 때 어떻게 할 것인가.

견적서에는 보통 정상 흐름만 적힙니다. 예외 처리는 “협의”라는 두 글자로 넘어갑니다. 그리고 개발이 끝날 무렵 그 협의가 시작되면, 이미 만들어진 구조를 뜯어야 하는 상황이 됩니다. 견적의 1.5배가 되는 일은 드물지 않습니다. 견적서에서 반복적으로 빠지는 항목은 관리자 페이지 개발 글에서도 같은 패턴으로 확인됩니다.

발주 전에 정리할 6가지

아래 여섯 가지는 개발사가 대신 정해 줄 수 없는 항목입니다. 발주사 안에서만 답이 나오고, 답이 없으면 개발 중에 반드시 재작업으로 돌아옵니다.

1. 이 시스템을 매일 여는 사람이 누구인가

부서 이름이 아니라 역할 단위로 적습니다. 하루에 열 번 쓰는 사람과 월말에 한 번 쓰는 사람은 필요한 화면이 다릅니다. 실사용자 서너 명의 이름을 적을 수 없다면, 아직 발주할 준비가 되지 않은 것입니다.

2. 지금 그 업무가 실제로 어떻게 돌아가는가

이상적인 모습이 아니라 현재 모습을 기록합니다. 지금 쓰는 엑셀 서식, 메신저로 오가는 확인 절차, 종이로 남기는 대장까지 포함합니다. 현행 업무를 적어 두지 않으면 개발사는 교과서적인 흐름을 가정하고, 그 가정은 거의 항상 틀립니다. 문서를 어느 수준까지 써야 하는지는 요구사항 정의서에 정리해 두었습니다.

3. 예외 처리를 어디까지 시스템이 감당할 것인가

모든 예외를 시스템에 넣으면 비용이 몇 배가 되고, 아무것도 넣지 않으면 현업이 다시 엑셀을 엽니다. 자주 일어나는 예외는 시스템에 넣고, 드문 예외는 관리자가 수동으로 처리할 수 있는 통로만 열어 두는 식으로 선을 그어야 합니다. 이 선을 발주 전에 긋는 것과 개발 중에 긋는 것은 비용이 전혀 다릅니다. 무엇을 1차에서 빼도 되는지는 MVP 개발 범위 기준을 참고하실 수 있습니다.

4. 기존 데이터를 어떻게 옮길 것인가

사내 시스템에는 항상 과거 데이터가 있습니다. 몇 년치 엑셀, 예전 시스템의 데이터베이스, 부서별로 다르게 적어 온 거래처명이 섞여 있습니다. 어디까지 옮길지, 형식이 안 맞는 값은 누가 정리할지, 정리 작업을 발주사가 할지 개발사가 할지를 먼저 정해야 합니다. 데이터 이관은 견적에서 가장 자주 누락되면서 실제로는 가장 오래 걸리는 작업 중 하나입니다.

5. 기존 시스템·외부 서비스와 무엇을 연동할 것인가

회계 프로그램, 그룹웨어, 사내 인증, 문자·알림톡, 세금계산서 발행처럼 이미 쓰고 있는 것들과 어디서 만날지 정해야 합니다. 연동 대상마다 문서가 있는지, 담당 벤더에게 협조를 받을 수 있는지도 함께 확인해야 합니다. 상대 쪽 문서가 없거나 담당자가 응답하지 않으면, 그 연동은 기술 문제가 아니라 일정 문제가 됩니다.

6. 오픈 이후 누가 바꿔 주는가

사내 시스템은 오픈이 끝이 아니라 시작입니다. 조직이 바뀌면 결재선이 바뀌고, 제도가 바뀌면 항목이 바뀝니다. 이 변경을 누가, 어느 속도로 처리할지 정해 두지 않으면 시스템은 6개월 만에 현실과 어긋나고, 그 시점에 현업은 엑셀로 돌아갑니다. 출시 이후의 대응 책임을 어떻게 정의하는지는 서버 운영·유지보수에서 자세히 다뤘습니다.

세 가지 발주 방식, 무엇이 실제로 다른가

사내 시스템을 맡길 때 선택지는 보통 세 가지입니다. 단가만 비교하면 판단을 그르치기 쉽습니다. 사내 시스템에서 진짜 변수는 현업의 업무 규칙을 누가 캐낼 것인가이기 때문입니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
현업 인터뷰 가능 여부	가능	사실상 어려움	가능
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
개발 단가	높음	낮음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

표에서 사내 시스템에만 해당하는 줄은 맨 윗줄입니다. 대외 서비스라면 기획서를 영어로 번역해 해외 팀에 넘기는 방식이 성립합니다. 그러나 사내 시스템의 요구사항은 번역할 원본 자체가 없습니다. 경리 담당자에게 마감 절차를 묻고, 창고 담당자에게 재고가 안 맞을 때 어떻게 하는지 물어야 나옵니다. 이 인터뷰는 한국어로, 그 조직의 맥락을 아는 사람이 해야 합니다.

그래서 사내 시스템에서 해외 직접 발주는 단가가 싸도 위험한 선택이 됩니다. 개발 실력의 문제가 아니라, 요구사항을 캐내는 일이 발주사 담당자에게 통째로 넘어오기 때문입니다. 사내에 그 일을 전담할 사람이 없다면 그 방식은 성립하지 않습니다. 왜 외주가 납기 후 분쟁으로 끝나는지는 IT 외주 구조에서 더 자세히 정리했습니다.

디비컨설팅이 이 문제를 다루는 방식

IT 아웃소싱 구조에서 한국인 PM은 통역이 아니라 요구사항의 책임자입니다. 진행은 다섯 단계로 나뉩니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요건을 한국어로 문서화합니다. 사내 시스템에서는 이 단계에 현업 인터뷰가 포함됩니다. 뒤에 생기는 재작업 대부분이 이 단계에서 제거됩니다.
2. 개발팀 구성 — 프로젝트 성격에 맞춰 2~4주 안에 전담팀을 구성합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 고객사 담당자가 하루를 조율에 쓰지 않아도 되는 구조입니다.
4. 테스트 및 배포 — QA 프로세스를 거쳐 배포합니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기 지원합니다.

사내 시스템에서 특히 중요한 것은 1단계와 5단계입니다. 1단계에서 현업의 규칙을 꺼내지 못하면 완성도와 무관하게 안 쓰이는 시스템이 되고, 5단계에서 문서 없이 인계받으면 조직이 바뀔 때마다 손을 댈 수 없게 됩니다.

실제 구축 사례

디비컨설팅이 수행한 프로젝트 가운데 내부 운영 시스템 성격이 강한 사례입니다.

• 가천대학교 — 학사관리 시스템
• 센터필드 · 센트로폴리스 · 그랑서울 — 프라임 오피스 빌딩 관리 시스템
• LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
• 교보생명 — 사내벤처(글펍) 커뮤니티 서비스
• 삼성물산 — 홈닉, 주거 플랫폼 앱
• GS건설 — 엘리시안 리조트 웹·앱 통합 구축

교육, 금융·핀테크, 제조·물류, 이커머스, 스마트빌딩·IoT 등에서 구축 경험을 보유하고 있습니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 부서별로 엑셀이 흩어져 있고, 같은 데이터를 여러 번 입력하고 있는 기업
• 업무 규칙이 담당자 경험에 의존하고 있어 인수인계마다 혼선이 생기는 조직
• 사내에 개발 인력이 없거나, 있어도 기존 시스템 운영만으로 여력이 없는 기업
• 기존 시스템이 현재 업무와 어긋나 있어 개편 여부를 판단해야 하는 기업
• 국내 개발사 견적이 예산을 넘지만 품질과 한국어 커뮤니케이션은 포기할 수 없는 기업

반대로, 이런 경우에는 권하지 않습니다

• 현업 담당자가 인터뷰에 응할 시간이 전혀 없는 경우. 사내 시스템은 발주사의 시간이 최소한은 필요합니다. 그 시간을 낼 수 없다면 어느 개발사가 맡아도 결과는 같습니다.
• 표준 패키지로 충분한 업무인 경우. 일반적인 회계나 급여처럼 시장 솔루션이 성숙한 영역은 구독형 제품이 더 저렴하고 안전합니다.
• 무엇을 개선할지 아직 정하지 못한 경우. “시스템이 있으면 나아질 것 같다”는 단계라면 개발보다 업무 정리가 먼저입니다.
• 이번 달 안에 오픈해야 하는 경우. 데이터 이관과 연동이 있는 사내 시스템은 그 일정에 맞추기 어렵습니다.

자주 묻는 질문

해외 개발팀인데 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 현업 인터뷰, 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 개발팀과 직접 영어로 대화하실 일은 없습니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 있으면 개략 견적을 드립니다. 사내 시스템이라면 현재 쓰고 계신 엑셀 서식을 보여 주시는 것이 기획서보다 정확할 때가 많습니다.

비용은 어떻게 산정되나요?

등급별 단가에 투입 기간을 곱하는 방식이며, 기획·디자인·개발·QA·배포·유지보수를 항목별로 구분해 제시합니다. 사내 시스템은 데이터 이관과 연동 범위에 따라 편차가 크므로 이 두 항목을 별도로 확인하시기 바랍니다. 국내 채용 대비 평균 40~60% 절감이 일반적인 범위입니다.

팀 규모를 중간에 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 가능합니다. 사내 시스템은 오픈 이후 변경 요청이 이어지는 특성이 있어, 축소된 형태로 유지 인력을 남기는 방식을 많이 선택하십니다.

소스코드는 누구 소유인가요?

발주사 귀속입니다. API 명세, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 사내 시스템에서는 이 조건이 특히 중요합니다. 코드와 문서를 확보하지 못하면 이후 어떤 작은 수정도 원 개발사를 거쳐야 하고, 그 의존이 몇 년간 이어지기 때문입니다.

정리

사내 시스템 구축의 성패는 개발 실력보다 요구사항을 캐내는 능력에서 갈립니다. 그 요구사항은 문서가 아니라 현업 담당자의 경험 안에 있고, 한국어로 묻고 조직의 맥락을 이해해야 나옵니다. 실사용자, 현행 업무, 예외 처리 범위, 데이터 이관, 연동 대상, 오픈 이후 변경 주체 — 이 여섯 가지를 발주 전에 정리해 두시면 대부분의 재작업은 발생하지 않습니다. 그리고 이 질문들을 대신 물어 줄 사람이 사내에 없다면, 그 역할을 맡는 한국인 PM이 있는 구조가 필요합니다. 웹 개발 외주를 검토 중이시라면 이 기준부터 확인해 보시기 바랍니다.

웹사이트 리뉴얼을 검토하기 시작하는 시점은 회사마다 놀라울 만큼 비슷합니다. 5년 전에 만든 사이트가 아직 돌아가기는 합니다. 다만 모바일에서 표와 이미지가 깨지고, 첫 화면이 뜨는 데 몇 초가 걸립니다. 관리자 페이지는 만들어 준 개발사만 손댈 수 있어서, 카테고리 하나를 추가하려면 메일을 보내고 이틀을 기다립니다. 영업팀이 요청한 상담 신청 폼 하나를 붙이는 데 처음 들었던 금액보다 높은 견적이 돌아옵니다. 그 개발사는 이미 담당자가 두 번 바뀌었고, 지금 남아 있는 사람은 이 시스템을 처음 설계한 사람이 아닙니다.

그래서 회의를 잡습니다. 그리고 그 회의는 대개 결론 없이 끝납니다. 지금 있는 것을 고쳐 쓸 것인지, 아니면 아예 다시 만들 것인지 판단할 기준이 회사 안에 없기 때문입니다.

이것은 취향의 문제가 아니라 예산의 문제입니다. 똑같이 “리뉴얼”이라고 부르지만, 부분 개선과 전면 재구축 사이에서 비용은 열 배까지 벌어집니다. 그리고 대부분의 회사는 이 판단을 내린 다음에 발주하는 것이 아니라, 발주한 다음에 판단하게 됩니다. 비용이 통제되지 않는 진짜 이유가 여기에 있습니다.

이 글은 고칠 것과 다시 만들 것을 가르는 기준, 그리고 그 기준을 누가 세워야 하는지를 정리합니다. 이미 웹 개발 외주를 검토 중이시라면, 발주서를 쓰기 전에 먼저 읽어 보시기 바랍니다.

디비컨설팅은 100건 이상의 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 함께 프로젝트별 개발팀을 구성합니다. 고객 만족도는 98%입니다. 삼성물산 홈닉(주거 플랫폼 앱), GS건설 엘리시안 리조트(리조트 웹·앱 통합 구축), 직방 호갱노노(부동산 데이터 서비스), LS일렉트릭 테크스퀘어(산업 B2B 거래 플랫폼) 등 국내 대기업의 실서비스를 함께 만들어 왔습니다. 디비컨설팅은 시원스쿨(Siwon School) 계열사입니다. 회사에 대한 자세한 내용은 디비컨설팅 소개에서 확인하실 수 있습니다.

리뉴얼 프로젝트의 견적은 왜 계속 올라가는가

리뉴얼이 실패하는 방식은 몇 가지로 정해져 있습니다. 기술이 부족해서가 아니라, 발주 구조가 같은 자리에서 반복해서 무너지기 때문입니다. 신규 개발에서도 같은 구조적 문제가 반복되지만, 리뉴얼에서는 기존 시스템이라는 변수가 하나 더 붙습니다.

리뉴얼의 범위를 발주 전에 아무도 정의하지 않습니다

대부분의 리뉴얼은 “디자인만 좀 바꾸면 된다”에서 출발합니다. 그런데 새 디자인을 얹으려면 지금의 화면 구조로는 안 된다는 사실이 드러납니다. 화면 구조를 바꾸려니 데이터가 그 형태로 저장되어 있지 않습니다. 결국 처음에는 손댈 생각이 전혀 없었던 데이터 구조까지 열게 됩니다.

이 확장은 개발사가 욕심을 부려서 생기는 것이 아닙니다. 범위가 처음부터 정의된 적이 없기 때문에, 작업을 시작한 뒤에야 하나씩 발견되는 것입니다. 발주사 입장에서는 요청한 적 없는 일이 계속 추가되는 것처럼 보이고, 개발사 입장에서는 하지 않으면 완성이 안 되는 일입니다. 양쪽 다 맞는 말이라서 협상으로 풀리지 않습니다.

기존 시스템을 만든 개발사가 문서를 남기지 않았습니다

리뉴얼은 신규 개발과 다릅니다. 이미 돌아가고 있는 시스템을 읽는 일부터 시작합니다. 그런데 API 명세도, DB 스키마도, 배포 절차도 문서로 남아 있지 않은 경우가 많습니다. 남아 있는 것은 코드뿐이고, 그 코드를 쓴 사람은 이미 회사에 없습니다.

그러면 새 개발사는 견적에 “분석 기간”을 넣습니다. 그 기간은 정확히 예측되지 않기 때문에 넉넉하게 잡히고, 그럼에도 부족해서 다시 늘어납니다. 초기 견적의 1.5배가 되는 일은 드물지 않습니다. 앞선 프로젝트가 문서를 남기지 않았다는 이유 하나로, 이번 프로젝트의 예산이 올라가는 구조입니다. 서비스 개발에서 가장 비싼 비용이 사람을 관리하는 시간인 이유도 같은 자리에 있습니다.

고칠 것과 다시 만들 것을 섞어서 발주합니다

가장 비용이 많이 드는 실수입니다. 유지보수로 충분한 영역과 재구축이 필요한 영역이 하나의 발주서 안에 섞여 들어갑니다. 개발사는 어느 쪽 기준으로 견적을 내야 할지 알 수 없으므로, 리스크를 얹어서 산정하거나 일단 낮게 부르고 진행 중에 조정합니다.

어느 쪽이든 발주사에게는 같은 결과입니다. 견적이 계속 움직이고, 일정이 밀리고, 회사 안에서 “그래서 이 프로젝트 얼마짜리냐”에 답할 수 있는 사람이 없어집니다. 이것이 문제가 개발사가 아니라 구조에 있다고 말씀드리는 이유입니다.

선택지는 셋입니다 — 그리고 진짜 쟁점은 개발 단가가 아닙니다

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

표에서 가장 중요한 줄은 개발 단가가 아니라 “요구사항 정의 책임”입니다. 해외 직접 발주가 기대만큼 저렴해지지 않는 이유가 정확히 여기에 있습니다. 시간당 단가는 분명히 내려가지만, 무엇을 만들 것인지 정의하는 일이 통째로 발주사에게 넘어옵니다. 화면 단위로 기능을 쪼개고, 예외 상황을 정리하고, 산출물을 검수하고, 시차를 넘겨 가며 커뮤니케이션하는 일을 발주사 담당자가 직접 해야 합니다.

사내에 개발팀과 PM이 있는 회사라면 가능합니다. 그러나 개발 조직이 없는 회사가 해외 개발팀을 직접 운영하는 것은 사실상 불가능에 가깝습니다. 요구사항을 정의할 사람이 없는 상태에서 개발이 시작되면, 저렴한 단가로 잘못된 것을 빠르게 만들게 됩니다. 그리고 재작업 비용은 단가가 낮다고 해서 낮아지지 않습니다. 오히려 커뮤니케이션 비용이 붙어서 국내 발주보다 총비용이 커지는 경우도 있습니다. IT 외주개발 비용이 견적보다 항상 더 나오는 구조에서 같은 패턴을 확인하실 수 있습니다.

그래서 실제 의사결정 문제는 “인도냐 베트남이냐”가 아닙니다. “요구사항을 누가 정의하고, 그 결과에 누가 책임지는가”입니다. 세 번째 선택지, 즉 한국인 PM이 한국어로 요구사항을 정의하고 검수까지 책임지면서 글로벌 개발팀이 구현을 맡는 구조가 유일하게 이 질문에 답합니다. 발주사는 국내 채용 대비 평균 40~60%의 비용 절감을 가져가면서도, 커뮤니케이션과 정의 책임은 국내 발주와 동일한 조건으로 유지합니다. 디비컨설팅의 IT 아웃소싱이 제공하는 것이 이 구조입니다.

디비컨설팅이 리뉴얼을 통제하는 5단계

1. 상담 및 요구 분석

비즈니스 목표와 기술 요구사항을 한국어로 문서화합니다. 어느 영역을 고치고 어느 영역을 다시 만들지, 이 단계에서 문장으로 확정합니다. 앞서 이야기한 재작업의 대부분은 여기서 사라집니다. 범위가 문서로 있으면 개발 중에 발견되는 일이 아니라 계약 전에 합의되는 일이 되기 때문입니다.

2. 개발팀 구성

확정된 요구사항에 맞춰 전담팀을 2~4주 내에 구성합니다. 필요한 역할만 넣습니다. 범위가 먼저 정해졌기 때문에 팀을 과하게 잡을 이유도, 부족하게 잡아 중간에 늘릴 이유도 줄어듭니다.

3. 프로젝트 개발

애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 발주사 담당자는 영어로 개발자와 조율하지 않습니다. 한국인 PM하고만 한국어로 이야기하고, 산출물을 확인하고, 다음 스프린트 우선순위를 정합니다. 담당자가 하루를 커뮤니케이션에 쓰지 않는 것이 이 구조의 목적입니다.

4. 테스트 및 배포

QA 프로세스를 거친 뒤 릴리스합니다. 리뉴얼은 기존 사용자와 기존 데이터가 있는 상태에서 전환하는 작업이므로, 기능 검증만이 아니라 전환 자체를 검증합니다.

5. 운영 및 유지보수

문서와 함께 인계합니다. API 명세, DB 스키마, 배포 절차를 남기고 장기 지원을 이어갑니다. 이번 리뉴얼이 비쌌던 이유가 앞선 개발사가 문서를 남기지 않은 것이었다면, 다음 리뉴얼에서 같은 일이 반복되지 않도록 하는 것이 이 단계의 역할입니다.

실제 수행 프로젝트

• GS건설 엘리시안 리조트 — 리조트 웹·앱 통합 구축
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼
• 직방 호갱노노 — 부동산 데이터 서비스
• 가천대학교 — 학사관리 시스템
• 센터필드·센트로폴리스·그랑서울 — 프라임 오피스 빌딩 관리 시스템
• 하나투어 하나오픈챗 — 여행 상담 채팅 서비스

교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역에서 실서비스를 운영 중인 기업들과 함께 진행한 프로젝트입니다. 전체 목록은 포트폴리오에서 보실 수 있습니다.

이런 기업에 적합합니다

• 웹사이트나 웹 서비스가 오래되어 리뉴얼이 필요하지만, 사내에 개발팀이나 PM이 없는 기업
• 기존 개발사에서 문서를 넘겨받지 못해 인수인계가 막혀 있는 기업
• 해외 개발 비용을 검토했지만 직접 관리할 인력이 없어 실행하지 못한 기업
• 개발 예산을 줄여야 하지만 커뮤니케이션 품질은 국내 발주 수준으로 유지해야 하는 기업
• 리뉴얼 이후에도 기능 추가와 운영이 계속 이어질 서비스를 가진 기업

반대로, 권하지 않습니다

• 사내에 개발팀과 PM이 이미 있고 요구사항을 직접 정의할 수 있는 기업이라면, 이 구조는 굳이 필요하지 않습니다. 파트너 없이 해외 인력을 직접 운영하시는 편이 낫습니다.
• 2주 안에 끝내야 하는 단순 페이지 수정이나 배너 교체라면 과한 구조입니다. 기존 유지보수 업체에 맡기시는 것이 빠르고 저렴합니다.
• 요구사항을 문서로 정의하는 과정 자체를 생략하고 바로 개발부터 시작하기를 원하신다면, 저희와는 맞지 않습니다. 저희가 비용을 줄이는 방식이 정확히 그 단계에 있기 때문입니다.

자주 묻는 질문

해외 개발자와 직접 소통해야 하나요?

아닙니다. 발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 산출물 검수는 모두 PM의 책임입니다. 개발팀과의 커뮤니케이션은 PM이 처리하므로, 발주사 담당자가 영어로 회의에 들어가거나 시차를 맞출 일은 없습니다.

비용은 어떻게 산정됩니까?

투입 인력의 등급별 단가와 투입 기간을 기준으로 산정합니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로 어느 단계에 얼마가 들어가는지 확인하실 수 있습니다. 범위가 바뀌면 어느 항목이 얼마나 움직이는지도 같은 기준으로 설명드립니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 그리고 일정과 예산 범위만 정리되어 있으면 개략 견적을 드릴 수 있습니다. 상세 기획은 1단계인 상담 및 요구 분석에서 함께 문서로 만듭니다.

프로젝트 중간에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고, 진행 중에도 범위와 일정에 맞춰 인원을 조정합니다. 리뉴얼은 초기 단계에 설계·기획 비중이 크고 후반에 개발·QA 비중이 커지므로, 실제로 조정이 필요한 경우가 많습니다.

소스코드 소유권은 누구에게 있습니까?

발주사에 귀속됩니다. 코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 이번 리뉴얼의 비용이 올라간 원인이 앞선 개발사가 아무 문서도 남기지 않은 것이었다면, 그 상황을 다시 만들지 않는 것이 저희 계약의 기본 조건입니다. 다음 개발사가 누가 되든, 시스템을 읽는 데 다시 몇 주를 쓰지 않아도 되도록 넘겨드립니다.

정리

웹사이트 리뉴얼에서 예산을 결정하는 것은 개발 단가가 아니라 요구사항 정의입니다. 고칠 것과 다시 만들 것을 발주 전에 문서로 가르면 견적은 움직이지 않고, 가르지 못하면 어떤 단가로 발주해도 비용은 올라갑니다. 그리고 사내에 개발팀이 없는 회사가 이 정의를 혼자 해내기는 어렵습니다. 한국인 PM이 한국어로 범위를 확정하고 검수까지 책임지며, 검증된 글로벌 개발팀이 구현을 맡는 구조가 필요한 이유입니다. 지금 사이트의 어느 부분을 고치고 어느 부분을 다시 만들어야 할지 판단이 서지 않으신다면, 그 판단부터 함께 정리해 드립니다.