# 자체 제작한 소프트웨어는 신규 직원을 누가 교육할까요?

> Published: 2026-08-04
> Updated: 2026-08-04
> Author: Mathias Nielsen
> Category: POS
> Canonical: https://finalpos.com/ko/blog/who-trains-staff-software-you-built-in-house-ko

자체 개발 대 구매(Build vs Buy) 논쟁에서는 개발 비용만 따지고 교육 비용은 무료인 것처럼 다룹니다. 하지만 그렇지 않습니다. 자체 제작한 소프트웨어를 운용하면, 신규 입사자는 이를 만든 사람에게 교육을 받아야 하며, 그 비용은 첫 근무 날부터 즉시 발생합니다.

바로 여러분입니다. 자체 제작한 소프트웨어 교육은 결국 제작자의 몫이 됩니다. 사장이든, 프롬프트를 입력해 소프트웨어를 만들어낸 매니저든, 혹은 초기 설정 방식을 기억하는 마지막 직원이든 상관없이 말이죠. 자체 개발 대 구매(Build vs Buy) 논쟁은 개발 비용을 시간과 금전 가치로 산정하지만 교육 비용은 무료처럼 취급합니다. 하지만 절대 그렇지 않습니다. 교육은 새로운 직원이 카운터에 설 때마다 반복적으로 발생하는 청구서이며, 이에 대한 예산을 미리 편성하는 사람은 거의 없습니다.

## 신규 직원이 자체 제작 도구를 접하면 실제로 어떤 일이 벌어질까요?

어깨 너머 교육(Shoulder training)입니다. 도구를 잘 아는 사람이 미숙한 사람 옆에 서서 일일이 설명해 줍니다. 한 번쯤은 효과가 있습니다. 문제는 이 과정이 절대 한 번으로 끝나지 않는다는 점입니다. 소매업과 요식업은 미국 노동통계국[¹](https://www.bls.gov/jlt/)이 추적하는 업종 중 이직률이 항상 가장 높은 축에 속하므로, 신규 채용이 이뤄질 때마다 이 설명 과정이 반복됩니다. 그것도 근무 한가운데, 피크 타임, 또는 제작자의 휴무일처럼 항상 최악의 시점에 말이죠.

더 깊은 문제는 '암묵지(tribal knowledge, 문서화되지 않고 사람의 머릿속에만 존재하는 노하우)'입니다. 자체 제작 소프트웨어는 이를 더욱 집중시킵니다. 환불 절차가 왜 그렇게 작동하는지 알고 있는 유일한 권위자가 존재하는데, 그 사람 역시 관리해야 할 비즈니스가 있습니다. 그 사람이 휴가를 가면 정답도 휴가를 가고, 그 사람이 퇴사하면 정답도 퇴사합니다. 엔지니어들은 이를 '버스 요인(bus factor: 시스템이 정지하기 전에 사라져도 되는 인원수)'이라고 부릅니다. 대부분의 자체 제작 도구에서 이 숫자는 '1'입니다.

![자체 제작 소프트웨어의 비공식 매뉴얼 역할을 하는 손글씨 메모로 가득 찬 계산대 화면](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/8b89e6457ddd2075-in-house-software-tribal-knowledge-sticky-notes.png)

## 구매한 소프트웨어가 자체 제작 소프트웨어보다 교육하기 쉬운 이유는 무엇일까요?

더 뛰어난 소프트웨어라서가 아닙니다. 공유되는 소프트웨어이기 때문입니다. 대중적인 POS나 회계 도구는 도움말 센터, 튜토리얼 비디오, 커뮤니티 포럼, 고객지원 라인을 제공하며, 신규 직원이 이전 직장에서 이미 해당 도구를 사용해 보았을 가능성도 큽니다. 즉, 광범위한 사용자 기반 자체가 일종의 교육 부서 역할을 하는 것입니다.

반면 자체 제작 도구의 사용자 기반은 단 1명에 불과합니다. 이를 미리 알고 입사하는 사람은 없으며, 설명해 주는 비디오도 없고, 발생한 오류 메시지를 본 포럼도 없습니다. 모든 질문은 결국 동일한 한 사람에게 몰립니다.

그럼에도 이러한 절충이 가치 있을 수 있습니다. 저희 역시 직접 경험해 보고 [2026년에 우리 비즈니스가 자체 내부 소프트웨어를 구축해야 할까요?](/blog/build-its-own-internal-software)에서 다룬 바 있습니다. 또한 [SaaS는 끝났는가?](/blog/is-saas-dead-build-in-house)에서 제시한 대원칙은 여전히 유효합니다. 차별화를 만들어내는 레이어는 직접 구축하고, 매번 정확해야 하는 인프라는 구매하라는 것입니다. 그러나 AI 덕분에 개발 비용이 저렴해지면서 문서화되지 않은 도구가 소상공인 매장에서 남몰래 늘어났습니다. 프롬프트가 소프트웨어를 만들어줄 수는 있지만, 매뉴얼까지 작성해 주지는 않습니다. [POS를 바이브 코딩으로 개발하기](/blog/vibe-coding-a-point-of-sale)도 또 다른 관점에서 동일한 패턴을 보여줍니다. 작동하는 데모를 만드는 것은 쉬운 부분일 뿐, 그 주변의 모든 과정을 정비하는 것이 진짜 작업입니다.

![신규 직원이 혼자서도 교육받을 수 있도록 자체 소프트웨어 작동법을 문서화하는 사업주](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/2dc2d84b9b1e2b30-documenting-in-house-software-runbook.png)

## 자체 제작 소프트웨어를 교육 가능하게 만들려면 어떻게 해야 할까요?

교육 자료를 개발 완료 후의 허드렛일이 아니라, 개발 과정의 일부로 다루세요. 다음 6가지 실천 방법으로 대부분 해결할 수 있습니다.

- 개발을 진행하는 동안 런북(단계별 작업 가이드)을 작성하세요. 어떤 작업에 탭 다섯 번이 필요하다면, 문서에도 다섯 줄을 적으면 됩니다. 나중에 쓰겠다는 것은 안 쓰겠다는 뜻입니다.
- 작업당 짧은 화면 녹화 영상을 하나씩 만드세요. 20분짜리 전체 안내 영상 하나보다 2분짜리 영상 5개가 훨씬 낫습니다. 신규 직원은 전체 안내 영상이 아니라 환불 안내 영상을 다시 돌려보기 때문입니다.
- 신규 직원의 모든 질문을 문서화 오류(버그)로 취급하세요. 말로 한 번 답변해 준 다음, 다음 입사자가 실제로 찾아볼 수 있는 위치에 답변을 글로 기록해 두세요.
- 인터페이스 복잡도를 최소화하세요. 화면이 적고 예외 상황이 적을수록 가르칠 내용도 줄어듭니다. 맞춤형 소프트웨어의 가치는 더 많은 버튼이 아니라 비즈니스 프로세스와의 정확한 부합에서 나옵니다.
- 제2의 슈퍼유저를 지정하세요. 나에게 전화를 걸지 않고도 환불 처리를 포함한 교대 근무 전체를 처리할 수 있는 사람이어야 합니다. 그런 사람이 생기기 전까지 버스 요인은 여전히 1입니다.
- 변경 사항을 직접 공지하세요. 구매한 소프트웨어는 릴리스 노트를 제공합니다. 사용자들에게 변경된 점을 알리지 않으면, 여러분의 도구는 소리 소문 없이 바뀌어 혼란을 줍니다.

이 중 어느 것도 화려하지 않습니다. 하지만 같은 환불 절차를 아홉 번째 다시 가르치는 것보다는 모두 훨씬 저렴합니다.

![자체 제작 소프트웨어 교육을 제대로 받은 후 혼자서 카운터를 담당하는 신규 직원](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/f28aca1dcc8a0df0-new-hire-running-shift-alone.png)

## 그렇다면, 자체 제작한 소프트웨어는 신규 직원을 누가 교육해야 할까요?

머릿속에 있는 노하우를 신규 직원이 스스로 보고 따라 할 수 있는 형태로 바꿀 때까지는 여러분의 몫입니다. 이는 철저한 문서화를 의미하거나, 하부 인프라가 일관되게 유지되는 기반 위에서 맞춤형 도구를 구축하는 것을 의미합니다. 이것이 바로 Final과 같은 프롬프트 기반 플랫폼이 제시하는 은밀한 강점입니다. 인터페이스는 비즈니스 특성에 맞게 자유롭게 커스텀할 수 있지만, 하단의 결제, 환불, 리포팅 기능은 플랫폼의 모든 가맹점이 공통으로 사용하는 검증된 매커니즘을 따릅니다. 또한 [결제 플로우 설치](https://finalpos.com/help/install-a-checkout-flow)부터 [Merchant Hub 문제 해결](https://finalpos.com/help/merchant-hub-faq-troubleshooting)까지 모든 과정을 커버하는 공개 도움말 센터의 지원을 받습니다. 상단은 커스텀하되 하단은 공유되므로, 맞춤형 환경이라도 교육을 바닥부터 다시 시작할 필요가 없습니다.

경험 법칙: **가장 최신에 들어온 신규 직원이 여러분을 찾지 않고는 환불 처리를 할 수 없다면, 여러분이 가진 것은 소프트웨어가 아니라 종속성입니다.** 그리고 자체 개발 여부를 여전히 고민 중이라면 [2026년에 우리 비즈니스가 자체 내부 소프트웨어를 구축해야 할까요?](/blog/build-its-own-internal-software) 글부터 참고해 보세요.

## FAQ

**Q: 맞춤 제작한 소프트웨어는 신규 직원을 누가 교육해야 하나요?**
A: 제작자가 첫 번째 슈퍼유저를 교육한 후에는 문서화된 자료가 역할을 맡아야 합니다. 모든 신규 직원이 여전히 제작자의 개인 지도에 의존해야 한다면 교육 시스템이 실패한 것이며, 직원 이직이 일어날 때마다 문제가 계속 노출될 것입니다.

**Q: 자체 제작 소프트웨어에는 어떤 문서가 필요한가요?**
A: 각 작업별(결제, 환불, 마감) 짧은 런북, 작업당 1개의 짧은 화면 녹화 영상, 변경 사항을 파악할 수 있는 변경 이력이 필요합니다. 개발 후에 쓰지 말고 개발하는 동안 작성하세요.

**Q: 버스 요인(bus factor)이란 무엇인가요?**
A: 시스템 작동이 중단되기 전까지 떠나도 괜찮은 사람의 수입니다. 자체 개발한 업무 도구의 대부분은 버스 요인이 '1', 즉 도구를 만든 사람 한 명에 불과합니다.

**Q: AI로 만든 소프트웨어는 직원 교육을 더 쉽게 만드나요, 아니면 더 어렵게 만드나요?**
A: 개발은 쉬워지지만 교육은 쉬워지지 않습니다. AI는 소프트웨어를 작성하지만 매뉴얼은 작성하지 않으므로, 문서화를 개발의 일부로 다루지 않는 한 문서화되지 않은 도구만 늘어나게 됩니다.

**Q: Final을 기반으로 구축된 POS는 바닥부터 직접 개발한 소프트웨어와 어떻게 다른가요?**
A: 인터페이스는 완전히 맞춤 설정할 수 있지만 결제, 환불, 리포팅 기능은 공개 도움말 센터 지원을 받는 공통의 문서화된 메커니즘으로 작동하므로 신규 직원 교육을 처음부터 다시 할 필요가 없습니다.