관리 프로그램 제작 2026 — 기성 SaaS vs 맞춤 개발, 비용 800만 원부터 판단 7단계

# 관리 프로그램 제작 2026 — 기성 SaaS vs 맞춤 개발, 비용 800만 원부터 판단 7단계

관리 프로그램이 필요해지는 순간은 정해져 있다

학원이든 제조 현장이든 도매업이든, 관리 프로그램을 찾기 시작하는 시점은 거의 똑같다. 엑셀로 버티다가 아래 중 하나가 터진다.

• 파일이 여러 개로 갈라져 어느 것이 최신인지 모르게 된다
• 두 사람이 동시에 열어 덮어쓰기가 발생한다
• 담당자만 아는 수식·매크로가 있고 그 사람이 자리를 비우면 멈춘다
• 지난달 숫자를 확인하려는데 이력이 남아 있지 않다
• 거래처·회원이 늘어 검색과 필터가 느려진다

이 다섯 중 두 개 이상이면 이미 도구를 바꿀 시점이다. 여기서 선택지는 두 갈래다 — 기성품을 사서 쓰거나, 맞춤으로 만들거나.

기성 SaaS vs 맞춤 개발 — 무엇으로 갈리나

대부분의 경우 기성품이 먼저다. 월 몇만 원으로 해결될 일을 수천만 원 들여 만드는 것은 손해다.

맞춤 개발이 정당해지는 조건은 분명하다.

1. 업무 흐름이 업계 표준과 다르다 — 기성품에 맞추면 오히려 일이 늘어난다
2. 기존 장비·시스템과 연동해야 한다 — 기성 SaaS는 대개 막혀 있다
3. 인당 과금이 누적돼 3년 총비용이 역전된다
4. 데이터를 외부에 둘 수 없다 — 규제 또는 계약상 제약
5. 이미 기성품을 써봤고 한계를 겪었다

⚠️ 5번이 가장 강한 근거다. 기성품을 한 번도 안 써보고 바로 맞춤 개발로 가면, 요구사항이 상상에 기반해 만들어져 재작업이 크게 난다.

3년 총비용으로 계산해야 한다

초기 비용만 비교하면 판단이 틀어진다. 인당 과금 구조는 사용자가 늘수록 급격히 불리해진다.

대략 20~30명 구간에서 역전된다. 다만 이건 순수 비용만 본 것이고, 기성품이 주는 지속적인 기능 개선과 보안 업데이트는 계산에 없다. 사용자가 적고 업무가 표준적이면 기성품이 거의 항상 낫다.

유형별 비용·기간

아래는 국내에서 통상 형성되는 범위다. 기능 수와 연동 범위에 따라 달라지므로 견적 비교의 기준선으로만 쓰는 것이 맞다.

견적을 가르는 최대 변수는 기능 개수가 아니라 화면 개수와 권한 설계다. 요구사항을 화면 단위로 세어보면 견적이 왜 그렇게 나왔는지 대체로 설명된다.

웹·데스크톱·모바일 중 무엇으로 만드나

특별한 이유가 없으면 웹이 기본이다. 설치가 필요 없고 업데이트가 즉시 반영되며, 나중에 모바일을 붙이기도 쉽다.

장비를 직접 제어해야 한다면 이야기가 다르다 — 그 경우는 장비 제어 프로그램 개발 외주 가이드를 참고하면 된다.

요구사항 정의서에 반드시 넣을 것

견적 편차의 대부분은 요구사항이 비어 있어서 생긴다. 아래만 채워도 업체 간 견적을 같은 기준으로 비교할 수 있다.

• 화면 목록 — 필요한 화면을 이름만이라도 전부 나열 (가장 중요)
• 사용자 수와 권한 구분 (관리자/일반/조회 전용)
• 기존 데이터 이관 대상과 형식 (엑셀 파일 몇 개, 몇 행)
• 필요한 통계·리포트 목록과 출력 형식
• 외부 연동: 결제·문자·이메일·회계·기존 시스템
• 동시 접속 예상 인원
• 접근 환경: 사내망만인지 외부에서도 쓰는지
• 데이터 보관 기간과 백업 요구
• 납품 형태: 소스 코드, 서버 구성, 문서

데이터 이관을 과소평가하지 말 것

실무에서 가장 자주 일정이 밀리는 지점이 여기다. 기능 개발이 끝났는데 기존 엑셀을 옮기지 못해 오픈이 미뤄진다.

전형적인 문제는 이렇다.

• 같은 거래처가 표기가 달라 중복으로 들어가 있다 (「(주)가나다」 / 「가나다」 / 「가나다상사」)
• 날짜 형식이 섞여 있다 (`2026-01-05` / `26.1.5` / `1월 5일`)
• 필수여야 할 칸이 비어 있다
• 한 칸에 여러 정보가 들어 있다 (「서울 강남 010-1234-5678」)

→ 발주 전에 기존 엑셀을 열어 정리 상태를 확인하고, 정리 작업을 누가 할지 정해야 한다. 개발사에 맡기면 별도 비용이고, 직접 하면 시간이 든다. 어느 쪽이든 일정에 반드시 잡아 둔다.

권한 관리는 처음부터 설계한다

"일단 다 보이게 만들고 나중에 권한을 넣자"는 요청이 흔한데, 권한은 나중에 얹는 기능이 아니다. 데이터 조회 구조 자체에 들어가기 때문에 뒤에 넣으면 대부분을 다시 짠다.

최소한 이 세 가지는 착수 전에 정해야 한다.

1. 역할 구분 — 몇 종류인가 (관리자/담당자/조회 전용 등)
2. 데이터 범위 — 본인 것만 보는가, 부서 것을 보는가, 전체를 보는가
3. 이력 추적 — 누가 언제 무엇을 바꿨는지 남겨야 하는가

외주 업체 선택 기준 6가지

1. 비슷한 업무 도메인 경험 — "관리 시스템 경험"이 아니라 *학원*, *제조*, *유통* 같은 구체적 도메인을 확인한다
2. 화면 설계안을 먼저 주는가 — 견적만 던지는 곳보다, 화면 목록과 흐름을 그려 오는 곳이 요구사항을 이해한 것이다
3. 데이터 이관 범위가 견적에 있는가 — 빠져 있으면 나중에 추가 비용으로 돌아온다
4. 소스 코드 인도 조건 — 계약서에 소스 인도와 저작권 귀속을 명시한다
5. 유지보수 단가 — 하자보수 기간과 이후 유상 지원 단가를 미리 정한다
6. 서버 운영 주체 — 우리가 운영하는지, 업체가 대행하는지, 대행이면 월 비용은 얼마인지

흔한 실패 4가지

① 기능을 다 넣으려다 오픈이 미뤄진다

1차에는 매일 쓰는 화면만 넣고 나머지는 2차로 미룬다. 쓰면서 요구사항이 정확해진다.

② 쓸 사람이 요구사항 논의에 없다

결재자만 참여해 만든 시스템은 현장에서 안 쓰인다. 실제 입력할 사람을 반드시 참여시킨다.

③ 엑셀 병행을 방치한다

새 시스템을 열어도 엑셀을 계속 쓰면 데이터가 둘로 갈라진다. 전환 시점을 정하고 엑셀을 닫는다.

④ 소스 코드 조건을 빠뜨린다

2~3년 뒤 기능을 추가할 때 소스가 없으면 처음부터 다시 만든다. 개발비의 몇 배가 나중에 드는 항목이다.

AI-Native 팀이 관리 프로그램을 만드는 방식

나무숲은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 관리 프로그램처럼 화면이 많고 패턴이 반복되는 영역에서 이 방식의 효과가 특히 크다.

• 화면 골격 생성 — 목록·등록·수정·검색처럼 반복되는 화면을 빠르게 세워 두고, 사람은 업무 규칙에 집중한다
• 기존 엑셀 분석 — 수백 열짜리 엑셀에서 중복 표기와 형식 불일치를 찾아내 이관 전에 정리 목록을 뽑는다
• 테스트 자동화 — 권한별로 보이면 안 되는 데이터가 새지 않는지 화면 단위로 반복 검증한다

관리 프로그램의 품질은 화려한 기술이 아니라 실제 업무와 얼마나 맞는가로 갈린다. 반복 작업을 자동화해 사람이 업무 이해에 시간을 쓰게 만드는 것이 AI-Native 개발 방식의 핵심이다.

AI 기능 없이 순수 웹·앱 개발이 필요하다면 포텐랩(Potenlab)도 좋은 선택이다. MVP부터 플랫폼 개발까지 전문으로 한다.

자주 묻는 질문

엑셀로 계속 버티면 안 되나요?

사용자가 3명 이하이고 동시 편집이 없다면 엑셀이 여전히 합리적이다. 동시 편집·이력 추적·권한 구분 중 하나라도 필요해지면 그때가 전환 시점이다.

기성품을 먼저 써봐야 하나요?

가능하면 그렇게 하는 편이 좋다. 한 달만 써봐도 "우리 업무에 안 맞는 지점"이 구체적으로 드러나고, 그것이 맞춤 개발의 요구사항이 된다.

개발 기간을 줄일 방법이 있나요?

1차 범위를 매일 쓰는 화면으로 좁히는 것이 가장 확실하다. 그리고 기존 엑셀 정리를 발주 전에 끝내두면 이관 단계에서 시간이 크게 준다.

서버는 우리가 준비해야 하나요?

클라우드를 쓰면 별도 장비 없이 월 비용으로 운영된다. 사내망에서만 써야 하는 경우에만 자체 서버를 검토한다.

만들고 나서 기능을 추가할 수 있나요?

가능하다. 다만 소스 코드를 인도받아 두어야 다른 업체에도 맡길 수 있다. 계약서에 반드시 넣는다.

정리

관리 프로그램은 기성품으로 되는 일을 굳이 만들지 않는 것에서 시작한다. 그 다음 순서는 이렇다.

1. 기성품을 먼저 써보고 한계 지점을 구체적으로 적는다
2. 3년 총비용으로 비교한다 (인당 과금은 20~30명에서 역전된다)
3. 화면 목록을 세어 요구사항을 만든다
4. 기존 엑셀 정리 주체와 일정을 먼저 정한다
5. 권한 구조를 착수 전에 확정한다
6. 1차 범위를 매일 쓰는 화면으로 좁힌다
7. 소스 코드 인도 조건을 계약서에 넣는다

이 일곱 가지가 정리되면 견적을 같은 기준으로 비교할 수 있고, 오픈이 미뤄지는 대부분의 원인이 미리 제거된다.

요구사항 정의서를 실제로 어떻게 쓰는지는 외주 개발 산출물 문서 총정리에 화면 목록 작성법과 함께 정리했다.