사내 관리 시스템 구축 2026 — 부서별 요구 충돌과 범위 자르는 법 7단계

# 사내 관리 시스템 구축 2026 — 부서별 요구 충돌과 범위 자르는 법 7단계

사내 시스템이 실패하는 방식은 하나다

기능이 부족해서 실패하지 않는다. 기능이 너무 많아서 실패한다.

사내 관리 시스템은 발주 단계에서 여러 부서가 요구를 낸다. 영업은 거래처 관리를, 재무는 정산을, 인사는 근태를 원한다. 이걸 다 받으면 다음이 벌어진다.

• 개발 기간이 3개월에서 9개월로 늘어난다
• 오픈 시점에 어느 부서도 만족하지 않는다 — 각자 요구의 60%만 들어갔기 때문이다
• 쓰는 사람이 없어 6개월 뒤 엑셀로 돌아간다

범위를 자르는 것이 이 프로젝트의 본체다. 무엇을 만들지 정하는 일보다 무엇을 안 만들지 정하는 일이 어렵고, 그걸 못 하면 나머지가 다 소용없다.

기성품으로 될지 맞춤으로 만들지를 먼저 판단해야 한다면 관리 프로그램 제작 — 기성 SaaS vs 맞춤 개발을 먼저 보는 편이 맞다. 이 글은 맞춤으로 가기로 정한 뒤 범위를 어떻게 자르나를 다룬다.

전사 도입과 부서 단위 도입은 다른 프로젝트다

같은 「사내 시스템」이라도 이 둘은 설계·비용·실패 방식이 전부 다르다.

대부분의 조직은 부서 단위로 시작해야 한다. 전사 시스템은 부서 시스템이 실제로 쓰이는 것을 확인한 뒤 확장하는 편이 성공률이 높다.

⚠️ 경영진이 「어차피 할 거면 한 번에」를 요구하는 경우가 많다. 그 요구가 나오면 기간과 비용을 부서 단위 안과 나란히 놓고 비교해서 보여준다. 대개 3~4배 차이가 난다.

요구가 충돌하는 지점은 정해져 있다

부서마다 다른 것을 원하는 게 아니라, 같은 대상을 다르게 부른다. 충돌은 거기서 난다.

착수 전에 용어집을 만든다. 한 페이지짜리로 충분하다.

```

거래처 = 사업자등록번호 기준 단일 레코드

(영업의 「고객사」, 운영의 「납품처」는 거래처의 속성)

금액 = VAT 별도를 기본값으로 저장, 화면에서 포함/별도 전환

매출인식일 = 세금계산서 발행일 (계약일·출고일과 별도 컬럼)

```

⚠️ 이 문서 없이 개발에 들어가면 개발사가 임의로 하나를 고른다. 그리고 그 선택은 대개 요구사항을 가장 많이 말한 부서의 것이 된다.

용어집을 만드는 자리에서 부서 간 이견이 나오면 그게 정상이다. 그 자리에서 합의하지 못한 항목은 「미정」으로 표시해 남긴다. 지우지 말고 남겨야 나중에 개발사가 임의로 정하지 않고 다시 물어본다.

범위를 자르는 기준 — 「매일 쓰는가」

기능 목록이 나오면 부서마다 우선순위를 매기라고 한다. 그러면 모두가 자기 것을 1순위로 낸다. 우선순위 대신 빈도를 묻는다.

빈도는 부서가 부풀리기 어렵다. 「중요하다」는 주관이지만 「매일 연다」는 사실이라 확인이 된다.

그리고 빈도를 물으면 대화의 성격이 바뀐다. 우선순위를 물으면 부서 간 경쟁이 되지만, 빈도를 물으면 각자 자기 업무를 설명하게 된다. 경쟁이 아니라 서술이 되면 조율이 쉬워진다.

실제로 확인하는 방법도 있다. 지금 쓰는 엑셀 파일의 수정 이력을 보면 된다. 「매일 쓴다」고 말한 파일이 마지막으로 열린 게 3주 전이면 그 기능은 1차 범위가 아니다.

실무에서 이 기준을 적용하면 대체로 이렇게 갈린다.

• 1차 포함 — 목록 조회, 등록, 검색, 상태 변경, 담당자별 내 건 보기
• 2차로 미룸 — 통계 대시보드, 엑셀 일괄 업로드, 결재선 커스터마이징, 외부 연동
• 아예 안 함 — 「나중에 필요할 수도 있는」 기능 전부

⚠️ 통계 대시보드가 1차에서 가장 자주 잘리는 항목이고, 가장 강하게 요구되는 항목이기도 하다. 데이터가 쌓이기 전의 대시보드는 빈 화면이다. 3개월치 데이터가 모인 뒤에 만드는 편이 옳고, 그때는 무엇을 봐야 하는지도 더 정확해진다.

거절할 때는 「안 만든다」가 아니라 「3차에 만들되, 그때 어떤 숫자를 볼지 지금 적어두자」로 말한다. 요구를 기각당한 게 아니라 순서를 잡은 것이 되고, 실제로 3개월 뒤 그 목록을 다시 보면 절반이 바뀌어 있다.

엑셀 일괄 업로드도 비슷하다. 초기 데이터 이관 때 한 번 필요하고 그 뒤로는 거의 안 쓰인다. 일회성 이관은 개발사가 스크립트로 처리하고, 화면 기능으로는 만들지 않는 편이 싸다.

기존 시스템과의 경계를 먼저 그린다

대부분의 조직에 이미 그룹웨어·ERP·회계 프로그램이 있다. 새 시스템이 그것과 겹치면 데이터가 두 곳에 생긴다.

원칙: 다른 시스템이 이미 주인인 데이터는 복제하지 않고 참조한다.

경계를 그릴 때 실무적으로 유용한 질문이 하나 있다. 「이 값이 틀렸을 때 어디를 고치러 갈 것인가」를 묻는다. 답이 기존 시스템이면 그건 새 시스템이 가질 데이터가 아니다.

⚠️ 「연동이 어려우니 우리가 따로 관리하자」가 가장 비싼 결정이다. 조직도를 새 시스템에 따로 입력하기 시작하면, 인사이동이 있을 때마다 두 곳을 고쳐야 하고 결국 한쪽이 낡는다. 연동이 어려우면 연동을 미루되 데이터 주인은 옮기지 않는다 — 초기엔 수동 CSV 동기화라도 단방향으로 한다.

권한은 조직도를 따라가면 안 된다

가장 흔한 설계 실수다. 「부장은 다 보고 사원은 자기 것만」으로 만들면 실무가 막힌다.

권한은 조직도가 아니라 업무 흐름을 따라간다.

실제로 필요한 조합은 대개 3~5개다. 그걸 역할로 묶어 이름을 붙인다.

```

담당자 본인 건 조회·등록·수정 / 완료 건 수정 불가

팀장 팀 건 전체 조회 + 승인 / 등록은 불가

정산 전체 조회 + 금액 필드만 수정

감사 전체 조회만 (수정 일절 불가, 이력 조회 가능)

```

⚠️ 「나중에 권한 넣자」는 가장 비싼 미루기다. 권한은 데이터를 가져오는 구조 자체에 들어가서, 뒤에 넣으면 조회 로직 대부분을 다시 짠다. 그리고 화면에서 버튼만 숨기고 서버에서 안 막으면 보안 구멍이 남는다.

권한별 화면 차이를 문서로 남기는 법은 화면설계서 작성법에, 기능 단위로 세는 법은 기능 정의서 작성법에 정리했다.

데이터 주인을 정한다

여러 부서가 같은 데이터를 쓰면 누가 고칠 수 있는가를 정해야 한다. 안 정하면 서로 고치다가 값이 뒤집힌다.

주인이 아닌 부서가 값을 바꿔야 하면 「수정 요청」으로 만든다. 직접 수정을 열어두면 이력이 사라지고 책임이 불분명해진다.

수정 요청은 결재 시스템처럼 무겁게 만들 필요가 없다. 값 옆에 「수정 요청」 버튼과 사유 한 줄, 그리고 주인 부서에 알림이면 충분하다. 승인 단계를 여러 개 두면 아무도 안 쓰고 결국 전화로 처리한다.

특히 계좌번호·사업자등록번호처럼 틀리면 금전 사고가 나는 항목은 주인을 좁게 잡는다. 「재무팀 전체」보다 「재무팀 담당자 2명」이 낫고, 변경 시 이력에 누가 언제 무엇을 바꿨는지 남긴다.

⚠️ 이 표를 만들다 보면 조직에 실제로 합의가 없던 지점이 드러난다. 그게 이 작업의 진짜 소득이다 — 시스템을 만들지 않더라도 정리할 가치가 있다.

유형별 비용·기간

국내에서 통상 형성되는 범위다. 부서 수와 연동 범위에 따라 달라지므로 견적 비교의 기준선으로만 쓴다.

다부서 이상에서 기간을 늘리는 건 개발이 아니라 합의다. 요구 정리에 6주가 걸리는 프로젝트가 흔하고, 그 기간은 견적서에 잘 안 적힌다. 착수 전에 의사결정권자가 누구인지를 확정해 두면 여기가 줄어든다.

단계적 확장 순서

한 번에 다 만들지 않기로 했으면, 다음 단계를 언제 여는지도 미리 정한다. 안 정하면 「2차」가 영원히 안 온다.

```

1차 (6~10주) 한 부서 · 매일 쓰는 화면만 · 권한 2종

→ 3개월 실사용

판정 매일 쓰는 사람이 실제로 매일 쓰는가?

아니면 2차로 넘어가지 말고 1차를 고친다

2차 (+6주) 두 번째 부서 확장 + 권한 세분화

→ 데이터 3개월치 축적

3차 (+4주) 통계·리포트 (이때 무엇을 볼지가 정확해진다)

4차 외부 시스템 연동

```

판정 기준을 미리 적어두는 것이 핵심이다. 「잘 되면 확장」은 판정이 아니다. 「담당자 5명 중 4명이 주 4일 이상 접속」처럼 세어질 수 있어야 한다.

그리고 미달했을 때 무엇을 할지도 같이 적는다. 대개는 확장이 아니라 1차를 고쳐야 하는데, 기준만 있고 조치가 없으면 미달해도 그냥 다음 단계로 넘어간다.

접속 로그는 1차부터 남긴다. 나중에 붙이면 판정할 데이터가 없다. 로그인 시각과 주요 화면 진입만 기록해도 충분하고, 이건 개발 공수가 거의 안 든다.

흔한 실패 5가지

① 요구를 다 받고 시작한다

가장 흔하고 가장 비싸다. 빈도 기준으로 자른다.

② 용어집 없이 개발에 들어간다

「거래처」가 세 가지 뜻으로 쓰이는 채로 만들면 나중에 데이터를 합칠 수 없다.

③ 기존 시스템의 데이터를 복제한다

조직도를 따로 관리하기 시작하면 반드시 낡는다.

④ 권한을 조직도로 만든다

실무는 직급이 아니라 담당 건으로 돌아간다.

⑤ 실사용자가 요구 정리에 없다

결재자만 참여한 시스템은 오픈 후 안 쓰인다. 매일 입력할 사람이 회의에 있어야 한다. 그 사람이 「이 항목은 저희가 모르는 값인데요」라고 말하는 순간이 프로젝트에서 가장 값진 지점이다.

⑥ 오픈을 전사 공지로 시작한다

1차는 한 부서 5~10명이 쓰는 것이다. 전사 공지를 하면 안 쓸 사람들이 먼저 보고 「이게 뭐냐」는 피드백이 쏟아진다. 쓸 사람에게만 알리고, 2주 뒤 그들이 계속 쓰면 그때 확장한다.

범위 확정 7단계

```

[ ] 1. 부서 단위로 시작할지 전사로 갈지 결정 (기간·비용 비교표로)

[ ] 2. 용어집 1장 작성 — 같은 대상을 뭐라 부르는지 통일

[ ] 3. 기능 목록을 「매일 / 주 1회 / 월 1회 이하」로 분류

[ ] 4. 기존 시스템과의 경계선 — 복제하지 않고 참조할 것 확정

[ ] 5. 데이터 주인 표 작성 — 누가 고칠 수 있나

[ ] 6. 권한을 업무 흐름으로 설계 (범위 × 동작 × 상태)

[ ] 7. 2차 확장 판정 기준을 숫자로 미리 등록

```

AI-Native 팀이 사내 시스템을 다루는 방식

나무숲은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 사내 시스템에서 어려운 것은 만드는 일이 아니라 부서마다 다른 말을 같은 구조로 정리하는 일이다.

• 용어 충돌 추출 — 각 부서가 제출한 요구사항 문서에서 같은 대상을 다르게 부르는 지점을 찾아 용어집 초안을 만든다
• 권한 조합 검증 — 설계한 역할 × 상태 조합에서 빠진 경우와 서로 모순되는 규칙을 찾아낸다
• 기존 시스템 경계 확인 — 그룹웨어·ERP가 이미 갖고 있는 데이터를 새 시스템이 복제하려 하는지 대조한다

사내 시스템의 성패는 기능 수가 아니라 6개월 뒤에도 쓰이는가로 판가름난다. 정리 작업을 자동화해 사람이 조직 합의에 시간을 쓰게 만드는 것이 AI-Native 개발 방식의 관점이다.

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

자주 묻는 질문

부서 단위로 시작하면 나중에 합칠 때 문제가 되지 않나요?

용어집과 데이터 주인 표를 1차에 만들어 두면 문제가 되지 않는다. 오히려 그 문서 없이 전사로 시작하는 쪽이 위험하다.

요구를 다 받아야 부서들이 협조하지 않나요?

반대다. 다 받으면 오픈이 늦어지고 각자 60%만 받게 되어 모두가 불만이다. 한 부서를 완전히 만족시키고 확장하는 편이 협조를 얻기 쉽다.

통계 대시보드를 왜 미루나요?

데이터가 없으면 빈 화면이고, 3개월 쌓인 뒤라야 무엇을 봐야 하는지가 정확해진다. 미루는 게 아니라 순서를 지키는 것이다.

기존 ERP와 연동이 어렵다는데요?

연동을 미루되 데이터 주인은 옮기지 않는다. 초기에는 단방향 CSV 동기화라도 한다. 양쪽에서 입력하기 시작하면 되돌리기 어렵다.

의사결정권자를 어떻게 정하나요?

부서장 협의체보다 한 사람이 낫다. 협의체는 범위를 늘리는 방향으로만 결정한다. 실무를 아는 한 명에게 최종 결정권을 주고 그 사람이 부서 요구를 조율하게 한다.

정리

사내 관리 시스템은 무엇을 만들지가 아니라 무엇을 안 만들지로 결정된다.

실무에서 결과를 가르는 지점은 셋이다.

1. 빈도로 잘랐는가 — 우선순위를 물으면 모두가 1순위를 낸다. 「매일 쓰나」는 확인이 된다
2. 용어집이 있는가 — 같은 대상을 세 부서가 다르게 부르는 채로 만들면 나중에 데이터를 못 합친다
3. 데이터 주인을 정했는가 — 안 정하면 서로 고치다가 값이 뒤집히고 이력이 사라진다

이 셋만 챙겨도 「만들었는데 아무도 안 쓰는」 결과가 대부분 예방된다.