이 글의 독자: 업무용 웹 시스템(사내 프로그램)을 도입·관리하는 기업 담당자·경영진
목표: 개발자와 같은 언어로 소통하고, 1단계 → 2단계 → 3단계로 시스템을 실제로 쓰는 수준까지 완성하기
수십 명 규모 중소기업의 업무 시스템은 “최첨단 기술”보다 문제없이 돌아가고, 직원이 매일 쓰며, 데이터가 쌓이는 것이 성공입니다.
그런데도 많은 프로젝트가 반쪽짜리로 끝나거나, 오픈 직후 다시 엑셀로 돌아갑니다.
이 지침서는 그 실패를 막는 담당자의 실무 매뉴얼입니다.
0. 한 장으로 보는 전체 그림
| 단계 | 이름 | 담당자가 확인해야 할 것 | 대략 기간(참고) |
|---|---|---|---|
| 1단계 | 입력·수집 | 직원이 매일 자료를 넣을 수 있는가 | 1~2개월 |
| 2단계 | 확인·출력 | 조회·엑셀·양식 출력이 업무에 도움이 되는가 | 정착 후 2~6주+ |
| 3단계 | 통계·지표 | 쌓인 데이터로 경영 지표를 보는가 | 데이터 3~6개월 후 |
[실패하는 순서] 대시보드부터 → 입력 안 함 → 빈 화면 → 시스템 방치
[성공하는 순서] 입력 정착 → 엑셀/양식 활용 → 그다음 통계
불변의 원칙: 데이터가 없는데 분석·AI·멋진 대시보드부터 만들면 실패합니다.
1. 왜 실패하는가 — 담당자가 먼저 알아야 할 현실
1-1. “데이터도 없는데 이상적인 솔루션”을 원한다
경영진이 원하는 것은 대개 실시간 통계·자동 분석·예쁜 대시보드입니다.
하지만 그 화면을 채울 기초 입력조차 없는 경우가 많습니다. 데이터가 없으면 분석은 작동하지 않고, “돈 들였는데 쓸모없다”로 끝납니다.
담당자가 할 일
- 분석(출력)보다 입력 편의성에 개발 공수의 대부분을 쓰자고 합의한다.
- “엑셀 업로드 / 복사·붙여넣기”를 1단계 필수 요구사항으로 넣는다.
1-2. 한 번에 다 만들려는 ‘빅뱅’ 오픈
요구사항을 한꺼번에 담으면 기간이 늘고, 요구는 계속 바뀌며, 비용은 바닥나고, 이도 저도 아닌 기능만 남습니다.
담당자가 할 일
- 계약·킥오프에서 3단계 로드맵을 문서에 명시한다.
- “지금 말하는 화려한 화면은 3단계”라고 경영진·실무에 미리 공지한다.
1-3. ‘페이스메이커’ 담당자가 없다
사장은 결과만 보고 싶어 하고, 직원은 “일만 늘어난다”며 입력을 피합니다.
이 갭을 메울 사람이 없으면 시스템은 고사합니다.
담당자가 할 일
- 본인이 그 페이스메이커가 되거나, 엑셀을 가장 많이 쓰는 실무자 1명을 사내 전도사로 지정한다.
- 1단계 기간에는 “입력이 귀찮아도 강제한다”는 경영 지원을 확보한다.
경영진에게 전달할 한 문장
“첫 달에는 직원이 귀찮고 사장님이 편해질 겁니다. 데이터가 쌓여야 몇 달 뒤 원하시는 분석이 나옵니다. 지금 단계의 수고는 경영진이 밀어주셔야 합니다.”
2. 단계별 완성 가이드 — 담당자와 개발자가 같이 볼 체크리스트
2단계가 아니라, 반드시 1 → 2 → 3 순서
1단계: 자료 입력·수집 (가장 중요)
목표: 시스템에 업무 자료가 들어온다.
| 체크 | 항목 | 설명 |
|---|---|---|
| ☐ | 핵심 업무 1개만 | 수주·출고·재고 등 가장 아픈 프로세스 하나부터 |
| ☐ | 필수 입력 최소화 | 필수 항목은 최대 3~4개, 나머지는 기본값 자동 |
| ☐ | 엑셀만큼 편한 입력 | 한 줄씩 등록 폼형태로 개발하면 실패하기 쉬움 |
| ☐ | 엑셀 업로드·붙여넣기 | Ctrl+V / 일괄 Import를 1단계에 포함 |
| ☐ | 입력 현황 가시화 | 미입력 부서·담당을 메인에 표시(심리적 강제) |
| ☐ | 실제 사용 2~4주 | “만들어졌는가”가 아니라 매일 사용하는가를 본다 |
개발자에게 이렇게 요청하세요
- “등록 폼만 만들지 말고, 시트처럼 행 단위 입력·엑셀 붙여넣기를 우선해 주세요.”
- “작성일·작성자·기본 부서는 로그인 정보로 자동 채워 주세요.”
2단계: 확인·가공·엑셀/양식 출력
목표: 입력한 보람이 바로 느껴진다.
| 체크 | 항목 | 설명 |
|---|---|---|
| ☐ | 조회 + 필터 | 기간·담당·거래처 등 실무 필터 |
| ☐ | 즉시 엑셀 다운로드 | 화면에 보이는 그대로 .xlsx |
| ☐ | 업무 양식 출력 | 거래명세서·발주서 등 기존 양식에 맞춰 출력 |
| ☐ | 재가공 가능 | 엑셀로 다운로드해서 원하는 형태로 재가공해서 쓰는 흐름 유지 |
직원이 “버튼 한 번에 양식이 나온다”를 느끼는 순간, 1단계 입력률이 올라갑니다.
3단계: 통계·지표
목표: 쌓인 데이터로 경영이 본다. (최소 3~6개월 정제 데이터 후)
| 체크 | 항목 | 설명 |
|---|---|---|
| ☐ | 초기엔 메뉴 잠금 | [데이터 수집 중 · OO월 예정]으로 기대 조율 |
| ☐ | 단순 합계 → 원인 추적 | 합계만이 아니라 합계가 나온 근거를 볼 수 있어야 함 |
| ☐ | 1·2단계 안착 후 착수 | 빈 대시보드로 신뢰를 깨지 말 것 |
3. 담당자 ↔ 개발자 소통 운영 규칙
3-1. 킥오프에서 반드시 합의할 문장
- 이 프로젝트는 1·2·3단계로 나뉜다. 화려한 통계는 3단계다.
- 1단계가 정착되지 않으면 2·3단계는 하지 않거나 보류한다.
- 검수·대금은 날짜가 아니라, 동작하는 기능 단위로 한다.
- 소스(GitHub)·서버 계정은 회사 소유다.
3-2. 매주 스프린트 (잠수·지연 방지)
- “한 달 뒤에 다 주세요”는 금지.
- 매주 금요일: 실제로 열리는 화면 URL(또는 스크린 공유)로 진행 확인.
- 그주에 끝난 기능만 “완료”로 인정한다.
3-3. 사내 전도사(실무자) 1명
- 엑셀 노가다가 가장 많은 실무자 1명을 지정한다.
- 그 사람의 가려운 곳을 먼저 해결하면, 그 사람이 동료에게 시스템을 퍼뜨리는 ‘전도사’가 된다.
4. 기술·인프라 기준 (담당자가 알아야 할 최소선)
수십 명 사내 시스템은 넷플릭스급 인프라가 필요 없습니다.
**“관리하기 쉽고, 개발자가 바뀌어도 이어갈 수 있는 기술”**이 정답입니다.
4-1. 추천 기술 방향 (가성비·유지보수)
| 구분 | 피하기 | 추천 | 이유 |
|---|---|---|---|
| 인프라 | 쿠버네티스, 복잡한 MSA | VPS + Docker | 수십 명 규모면 서버 1대로 충분 |
| DB/백엔드 | NoSQL·분산 DB 남발 | PostgreSQL + Supabase | 표준·안정·개발 속도 |
| 프론트 | 처음부터 커스텀 디자인 | Svelte(Kit) 또는 React + Tailwind, 기성 어드민 템플릿 | 속도·비용 |
| 모바일 | 네이티브 앱 이중 개발 | 반응형 웹 / PWA | 스토어·이중 비용 회피 |
4-2. Supabase를 자체 서버(Self-hosting) 할 때 서버 사양
관리형 SaaS가 아니라, VPS에 Docker로 Supabase를 직접 올리면
DB·인증·API·스토리지·게이트웨이 등 여러 컨테이너가 동시에 돌아갑니다.
| 항목 | 권장 |
|---|---|
| CPU | 4 vCPU |
| RAM | 8 GB |
| 디스크 | 100 GB SSD 이상 |
| OS | Ubuntu LTS |
| 월 비용(현실) | 대략 5~8만 원대 (업체·대역·백업에 따라 다름) |
테스트·초기는 2 vCPU / 4GB로 시작할 수 있으나,
Supabase self-hosting 본격 운영이면 4 / 8 / 100을 기준으로 잡는 것이 안전합니다.
백업
- 서버 디스크에만 쌓지 말고, 오브젝트 스토리지(S3 등)로 일 1회 자동 백업을 요구하세요.
4-3. 처음부터 크게 잡지 말 것
- 1단계 기간: 작은 스펙으로 시작 → 사용량 늘면 Scale-up
- AWS를 처음부터 복잡하게 깔면 고정비만 커지는 경우가 많습니다.
5. 비용·공수 부풀리기 방어 (담당자 체크리스트)
5-1. 이런 제안이 나오면 한 번 더 물어보세요
| 제안 | 현실적인 대응 |
|---|---|
| “쿠버네티스·무중단 클러스터 필요” | 동시 접속 수십 명이면 단일 Docker로 충분 |
| “실시간 웹소켓 서버 필수” | 화면 열 때 / 1~5분 폴링이면 충분한 경우가 많음 |
| “NoSQL·초고속 실시간 DB” | PostgreSQL + 인덱스부터 |
| “iOS/Android 앱 별도” | 반응형/PWA로 시작 |
| “회원가입·본인인증·복잡한 권한” | 초기는 관리자가 계정 수동 발급 |
| “실시간 DB 이중화” | Daily Backup부터 |
5-2. 계약·견적에서 챙길 3가지
- 오픈소스·상용 그리드/엑셀/차트 라이브러리 사용을 명시
(바닥부터 짜겠다는 공수는 이의 제기) - 기능별 일정표(며칠 단위) 요구
예: “로그인 7일” → 템플릿·라이브러리 기준 설명이 없으면 재협의 - 단계별 검수 후 대금 (날짜 자동 지급 금지)
5-3. 권장 마일스톤 (비용지불)
계약(착수)
1단계 검수(입력·수집이 실제로 돌아감)
2단계 검수(조회·필터·엑셀/양식 출력)
3단계 완료보고
4단계 유지보수
6. 개발회사 vs 1인 풀스택 — 선택 가이드
개발회사에 맡기면 기획·디자인·프론트·백엔드·PM이 쪼개지며
인건비와 미팅 비용이 커지고, 실무는 주니어가 맡는 일도 많습니다.
중소 업무 시스템은 종종
비즈니스를 이해하고, 화면부터 DB·서버까지 혼자 마무리할 수 있는 1인 풀스택이
비용·완성도 면에서 유리합니다.
6-1. 이상적인 1인 개발자 프로필
- 프론트: Svelte(Kit) 또는 React
- 백엔드·DB: Supabase + PostgreSQL, Docker self-hosting 경험
- 인프라: Ubuntu, Nginx, 백업 스크립트
- 핵심: 예쁜 화면보다 엑셀 장부를 보고 DB 구조를 설계하는 능력
6-2. 미팅 때 던질 검증 질문 3개
Q1. Supabase self-hosting (4CPU/8GB, Docker) 직접 구축 가능한가?
- 합격: Docker Compose, Nginx, 일일 백업까지 본인이 세팅한다.
- 주의: “클라우드 SaaS만 써봤다”만 반복하면 인프라 리스크.
Q2. 엑셀 대량 붙여넣기·일괄 업로드 구현 경험이 있는가?
- 합격: SheetJS·그리드 등으로 시트형 입력 설계.
- 주의: “한 줄씩 등록이 낫다”만 고집하면 1단계 실패 확률↑.
Q3. 1→2→3 단계로 쪼개 검수할 수 있는가?
- 합격: 최소 기능(입력부터) → 리포트 → 통계 순서를 스스로 제안.
(한꺼번에 다 만들지 않고, 직원이 매일 넣는 입력 화면을 먼저 오픈) --> 직원의 Feedback을 받아 사용자 편의성을 개선. - 주의: “한 번에 다 만들고 오픈”만 고집.
6-3. 먹튀·중단 방지 안전장치
| 항목 | 규칙 |
|---|---|
| 코드 | 회사 GitHub에 커밋 (개인 저장소만 사용 금지) |
| 서버 | 루트/관리 계정은 회사 담당자가 보유 |
| 비밀값 | .env, 키, DB 비밀번호 문서 인계 |
| 진행 | 매주 또는 매일 업데이트 하면서 직원이 사용하면서 개발이 되는 것이 좋음 |
7. 담당자용 실행 체크리스트 (인쇄·공유용)
프로젝트 시작 전
- 해결할 핵심 업무를 문장으로 적었다
- 1·2·3단계와 3단계는 나중임을 경영진과 합의했다
- 엑셀을 가장 많이 쓰는 실무자 1명을 ‘사내 전도사’로 지정했다
- 서버 예산(self-hosting 시 월 5~8만 원대 등)을 잡았다
- GitHub·서버 소유권이 회사에 있음을 계약에 넣었다
개발 중 (매주)
- 개발 진행중인 화면을 직접 클릭해 봤다
- “예쁜 화면”보다 **기능위주의 화면(입력·엑셀)**이 우선인지 확인했다
- 일정표보다 늦어진 것·추가 요청으로 늘어난 일을 기록했다
1단계 완료 기준
- 실무자가 데이터 입력을 하는데 문제가 없다
- 엑셀 업로드/붙여넣기 로 Data가 저장되는 되고 추가/삭제가 가능하다
- 이제 엑셀이 없오도 되겠다는 신뢰가 생겼다
2단계 완료 기준
- 입력/수정/삭제된 Data를 엑셀로 다운로드 할 수 있다
- 필터 조회 + 엑셀 다운로드가 업무에 쓰인다
- 기존 양식(명세서 등) 출력이 가능하다
3단계 착수 조건
- 1·2단계가 정착했다
- 의미 있는 기간(예: 3개월+)의 데이터가 쌓였다
8. 맺음말
중소기업 업무 웹 시스템의 성패는
쿠버네티스나 최신 프레임워크가 아니라,
- 입력이 되는가
- 출력·엑셀이 쓸모 있는가
- 그다음에야 통계가 의미가 있는가
그리고 그 순서를 담당자가 개발자와 함께 지켜내는가에 달려 있습니다.
이 지침서를 킥오프 자료·계약 부속·주간 미팅 안건으로 그대로 쓰셔도 됩니다.
단계만 지키면, 비용은 줄이고 결과는 “실제로 쓰는 시스템”에 가까워집니다.
마지막 한 가지 — 코딩만 맡기지 말고, 경험을 배우라
대부분의 회사는 시스템 개발에 대해 전혀 지식이 없습니다.
그래서 “기능 목록만 넘기고 결과물만 받는” 방식보다, 경험이 많은 개발자에게 컨설팅을 받으며 같이 만들어 가는 방식이 훨씬 안전합니다.
- 무엇을 1단계에 넣고, 무엇을 나중으로 미룰지
- 직원이 실제로 쓰게 만드는 운영 요령
- 엑셀·입력·출력·통계를 어떤 순서로 가져갈지
- 비용·공수가 어디서 새는지
이런 판단은 코드만 짜는 사람과, 여러 업체를 거쳐 본 개발자의 경험이 다릅니다.
단순 개발자보다는 전반적인 컨설팅과 시스템 활용 노하우를 알려 줄 수 있는 경험자와 함께하세요.
시스템을 “납품받는” 것이 아니라, 만드는 과정에서 회사의 디지털 운영 역량까지 배우는 것이 이 프로젝트의 진짜 성과입니다.


주파수 소통방 (0)
로딩 중...