개발을 배우지 않았어도 AI 코딩 도구로 업무 프로그램의 시제품은 만들 수 있다. 나는 코드를 짜 본 적 없는 인사 담당자다. 그런데도 Claude Code로 주문부터 출하까지 관리하는 프로그램 시제품을 만들었고, 이걸 본 외주 개발 업체는 자체 개발을 해도 되겠다고 했다.

해 보니 화면을 만드는 일은 AI가 대부분 맡는다. 사람에게 남는 일은 두 가지다. 만들기 전에 무엇을 어떤 기준으로 만들지 정하는 일, 그리고 만든 뒤에 결과가 맞는지 확인하는 일이다. 이 글은 그 두 가지를 중심으로 순서대로 정리했다.

글에 넣은 화면은 실제 시제품의 구성을 그대로 두고 색, 회사 정보, 데이터를 바꿔 다시 그린 것이다.

시제품이 할 수 있는 일과 못 하는 일

시제품은 실제 제품을 만들기 전에 화면과 흐름을 확인하는 견본이다. 말이나 문서로 설명하기 어려운 요구사항을 직접 눌러 보게 할 수 있다는 점이 가장 큰 쓸모다.

내가 만든 시제품도 지금은 쓰지 않는다. 회사 전체가 함께 써야 하는 프로그램이라 운영하려면 완성도를 훨씬 높여야 하고, 지금 규모에서는 그 비용만큼 얻는 게 크지 않다고 판단했다. 처음부터 운영용이 아닌 견본으로 보고 시작하면 기대와 결과가 어긋나지 않는다.

시작 전에 준비할 것

• Claude Code: 말로 요청하면 코드를 짜고, 고치고, 실행해서 결과를 보고하는 AI 도구다. 데스크톱 앱이나 터미널에서 쓰며, Claude 유료 요금제나 API 결제가 필요하다.
• Node.js: 웹 프로그램을 실행하는 환경이다. 깔려 있는지는 AI에게 확인해 달라고 하면 된다.
• PC 한 대: 만든 프로그램을 띄워 두는 서버 역할까지 이 PC가 맡는다.
• 가짜 데이터: 실제 거래처나 직원 정보는 넣지 않는다. 가상의 거래처 세 곳과 주문 스무여 건이면 흐름을 시험하기에 충분했다.

코드를 읽을 줄 몰라도 된다. 다만 AI가 보고하는 표와 숫자를 보고 맞는지 틀린지는 판단할 수 있어야 한다.

만들기 전에 정할 네 가지

화면은 나중에 얼마든지 고칠 수 있다. 아래 네 가지는 늦게 바꿀수록 고칠 곳이 늘어나므로 먼저 정한다. 시제품을 만들고 나서 가장 크게 남은 생각도 처음 기획을 잘 해야 한다는 것이었다.

누가 어떤 화면을 쓰는가

쓰는 사람을 먼저 나누고, 사람마다 볼 수 있는 화면을 정한다. 역할을 나누지 않으면 거래처가 다른 거래처의 주문을 보는 식의 문제가 생긴다.

내 경우는 주문을 넣는 거래처와, 접수부터 출하까지 처리하는 사내 관리자 두 역할이었다. 거래처 화면은 작업 요청, 진행 단계 확인, 주문 내역, 공지 정도였고 나머지는 모두 관리자 화면이었다. 위쪽 바에 두 화면을 오가는 전환 버튼을 두어, 시연할 때 한 사람이 양쪽을 번갈아 보여 줄 수 있게 했다.

업무가 어떤 단계를 거치는가

주문이 접수에서 출하까지 거치는 단계의 이름과 순서를 적는다. 목록, 필터, 건수 집계가 모두 이 단계 값을 기준으로 건을 골라 보여 준다. 글 맨 위 화면에서 공정 번호가 붙은 필터 버튼이 그 예다.

단계 사이에 빈틈이 있으면 건이 사라진다. 내 시제품에서는 출하 단계로 넘긴 주문이 어느 목록에도 보이지 않았다. 출하 대기 목록이 바로 앞 단계의 주문만 보고 있었기 때문이다.

한 건을 무엇으로 셀 것인가

“한 건”이 주문 하나인지, 주문 안의 제품 하나인지 정한다. 검사, 포장, 라벨, 로트 번호(같은 조건으로 만든 묶음 번호), 전표(거래를 기록하는 문서)가 모두 이 단위를 따라 만들어진다.

내 시제품의 접수 화면은 위와 같았다. 품목과 규격을 주문마다 하나씩만 고르게 되어 있다. 이 부분은 화면을 다 만든 뒤에야 문제가 드러났다. 한 주문에 제품을 여러 개 넣을 수 있는데, 실제로는 제품마다 조건이 다를 수 있었다.

제품 단위로 바꾸려면 검사부터 전표까지 다시 만들어야 했다. 그래서 시제품은 그대로 두고, 바꿀 구조를 그림으로 그려 견적 자료에 넣었다. 제품을 고를 때마다 줄이 하나씩 생기고, 조건이 같은 경우가 많으니 첫 줄 값을 나머지에 복사하는 버튼을 두는 방식이다.

숫자는 언제 바뀌는가

재고처럼 여러 단계에서 건드리는 숫자는 바뀌는 시점을 한 곳으로 정한다.

내 시제품은 공정에서 자재를 투입할 때 재고를 한 번 빼고, 출하할 때 기본 구성표(제품 하나에 들어가는 자재 목록)를 기준으로 한 번 더 뺐다. 실제로 쓴 양은 0.7인데 1.7이 빠졌다. 시험 데이터에 재고를 넉넉히 넣어 두어서 마이너스가 나지 않았고, 그래서 한동안 알아채지 못했다.

“재고는 공정에서 투입할 때만 뺀다”로 규칙을 정한 뒤로는 숫자가 맞았다. 출하 화면에는 이 규칙을 안내 문구로 적어 두었다.

기존 시스템과 주고받는 숫자도 이때 정한다. 나는 ERP(주문·재고·회계를 관리하는 기존 프로그램)와 직접 연결하지 않았다. 입고 목록은 엑셀로 받아 올리고, 출하를 확정하면 ERP에 올릴 전표가 만들어지게 했다. 시제품 단계에서는 파일로 주고받는 정도면 충분했다.

요청은 이렇게 한다

개발 용어를 몰라도 된다. 무엇이 불편한지와 어떻게 되면 좋겠는지를 그대로 적으면, AI가 코드에서 해당하는 곳을 찾아 고친다. 실제로 보낸 요청은 이런 식이었다.

요청 범위는 넓게 줘도 된다. 화면 이동을 확인해 달라는 요청에 AI는 이동이 일어나는 곳 15군데를 모두 찾았고, 12군데는 문제가 없다고 보고한 뒤 3군데를 고쳤다. 저장할 때마다 다른 메뉴로 넘어가던 접수 화면이 그 자리에 머물게 된 것도 이때다.

여러 안을 받을 때는 무엇을 다르게 할지 짚어 준다. 디자인 컨셉을 여러 번 요청했을 때 처음 받은 일곱 안은 색과 카드 모양만 다를 뿐, 왼쪽 메뉴에 카드를 늘어놓는 골격은 같았다. “구성 전체를 다른 형태로”라고 짚어 주고 나서야 탭, 촘촘한 표, 시간 막대, 단계 표시줄처럼 뼈대가 다른 안이 나왔다.

결과는 이렇게 확인한다

AI는 고친 뒤 직접 실행해 보고 결과를 보고한다. 그 보고와 별개로 다음 네 가지는 따로 챙긴다.

1. 주문 한 건을 끝까지 돌려서 숫자를 맞춰 본다. 화면을 하나씩 볼 때는 보이지 않던 재고 이중 차감이 이때 나왔다.
2. 사람이 직접 써 본다. 저장할 때마다 다른 메뉴로 넘어가는 불편은 AI 보고에 없었고, 써 본 뒤 요청해서 고쳤다.
3. 처리해야 할 문제는 첫 화면에 모아 보여 주게 한다. 재고가 마이너스가 된 자재, 전표가 안 만들어진 주문, 납기가 지난 주문이 위에서부터 뜨고, 옆 링크를 누르면 처리 화면으로 간다.
4. 큰 수정 전에는 원본이 백업됐는지 확인한다. 색을 한꺼번에 바꾸다 흐린 회색 글자가 파란색으로 바뀐 적이 있는데, 백업이 있어서 되돌리고 다시 적용했다.

다른 사람에게 보여 주는 방법

사내망에서 주소로 연다

만든 PC에서 프로그램을 띄워 두면, 같은 사내망(회사 안에서만 연결되는 네트워크)에 있는 다른 PC에서 브라우저에 주소만 넣고 들어올 수 있다. 담당자에게 써 보게 하고 의견을 받을 때 가장 편한 방법이다.

외부 인터넷에는 열지 않는다. 시험 계정 비밀번호는 실제로 쓰는 비밀번호와 다르게 두고, 노트북이라면 바깥 와이파이에 연결한 채로 띄워 두지 않는다.

설치 없이 실행되는 압축 파일로 넘긴다

사내망 밖에 있는 외주 업체에는 압축 파일로 넘겼다. 받는 사람은 압축을 풀고 실행하기.bat(더블클릭하면 필요한 명령을 차례로 실행하는 파일)을 누르면 브라우저에서 시제품을 볼 수 있다. 받는 PC에는 Node.js만 있으면 된다.

시제품-배포/
├─ 실행하기.bat      더블클릭하면 시제품이 열린다
├─ 데이터초기화.bat  시험 데이터를 처음 상태로 되돌린다
├─ 읽어보세요.txt    실행 방법 안내
├─ 기능정리서.md     견적용 기능 목록
└─ (프로그램 파일)

기능 정리 문서는 AI에게 지금 만든 화면을 기준으로 뽑아 달라고 하면 된다.

압축 파일은 넘기기 전에 안에 든 것까지 확인한다. 처음 만든 파일은 105MB였는데, 실행에 필요한 파일만 추리게 해서 19.3MB로 줄였다. 이 과정에서 데이터 파일 하나가 임시 파일로 잘못 분류돼 빠졌다. 압축본 속 데이터를 따로 열어 보니 출하 5건과 기록 7건이 비어 있었다. 주문 25건은 남아 있어서 겉보기에는 멀쩡했으니, 그대로 보냈다면 업체는 빈 거래명세서를 받아 봤을 것이다.