104. AX 프로젝트 수행 가이드라인
과제 리더가 여섯 번의 컨설팅에서 어떤 순서로 어떤 활동을 하게 되는지 미리 그려 봅니다.
전체 그림 — 6회차에 과제가 완성됩니다
- 6회차 컨설팅의 전체 흐름과 각 회차의 목표·산출물을 설명할 수 있다.
- 컨설팅 데이에 하는 일과 회차 사이에 팀이 스스로 해야 할 일을 구분할 수 있다.
- 착수 전에 준비·제출할 자료와 산출물 형식 규칙(md/html)을 안다.
진행 방식 — 컨설팅 6회, 그 사이는 팀의 시간
이번 프로젝트는 총 6회의 컨설팅을 거치며 각 조의 AX 과제를 실제로 동작하는 자동화 시스템으로 완성하는 여정입니다. 각 회차는 "지난 진도 점검 → 이번 회차 활동(컨설턴트와 함께) → 다음 회차까지 할 일 확정"의 리듬으로 진행되고, 회차와 회차 사이에는 팀이 스스로 개발과 검증을 이어 갑니다. 컨설팅 데이는 방향을 잡고 막힌 곳을 뚫는 날이고, 실제 진도는 그 사이의 시간에 쌓입니다.
회차마다 답해야 할 핵심 질문이 하나씩 있습니다. 이 질문에 답이 나왔으면 그 회차는 성공입니다.
| 회차 | 핵심 질문 | 주요 활동 | 대표 산출물 |
|---|---|---|---|
| 1회차 | 우리는 무엇을 자동화하는가? | 과제 범위·SIPOC 정의, 휴먼 프로세스 → 프로그램 프로세스 재설계, 인풋·아웃풋 데이터 템플릿 정의, 백엔드·프론트엔드 기획, 개발계획서 완성, Plan 모드 가동, ver1.0 코딩 | 개발계획서 · ver1.0 코드 |
| 2회차 | 기획한 기능이 전부 동작하는가? | 기능 확인·데이터 확인, 실데이터 대조 검증, 개선 반복 — 기능 목록 100% 구현 | 검증 보고 · 기능 완성 코드 |
| 3회차 | 아웃풋 품질은 몇 점인가? | 테스트 데이터 자동 생성, 대량 인풋 투입·아웃풋 측정, 품질 지표 정의·현수준 측정, 원인분석 → 개선 → 효과 평가 | 지표 정의서 · 측정/개선 리포트 |
| 4회차 | 어디까지 확장할 것인가? | 자동화 로직 고도화, 인접 시스템(메일·알림·스토리지·사내 시스템)으로 확장·연계 개발 | 고도화·연계 기능 코드 |
| 5회차 | 배포해도 되는가? | 전체 시스템 안정화(인증·에러·백업), 실사용 테스트, 오픈베타 서비스 시작 | 베타 서비스 · 이슈 로그 |
| 6회차 | 무엇이 얼마나 좋아졌는가? | 최종 코드 완성, 활용 효과 평가·정량화, 개발 히스토리 정리, 시스템 문서화, Lessons Learned, 최종 발표 | 최종 코드 · 효과 평가서 · 발표 |
대상 과제 — 함께 완성해 갈 15개 과제
이번 컨설팅의 대상은 미래엔 각 조가 기획한 아래 과제들입니다. 분야도 진도도 다르지만 — 이미 프로토타입이 운영 중인 과제부터 기획서만 있는 과제까지 — 6회차의 진행 골격은 모두 같습니다. 각자 자기 과제를 떠올리며 이 교재를 읽으십시오.
| 분류 | 과제명 | 한 줄 요약 |
|---|---|---|
| 서책 | AI 기반 어문교열 에이전트 | 규칙 DB 중심 교정·교열 + 팩트체크 후보 검출로 편집자 QA 보조 |
| 삽화 발주 관리 에이전트 | 삽화 발주~수정~정산을 한곳에서 관리, AI 샘플 이미지로 발주서 표준화 | |
| 교육과정 분석·기획 보조 에이전트 | 교육과정 PDF·경쟁사 교과서 분석으로 신구대조표·비교분석·구성안 초안 생성 | |
| 교과서 개발 워크플로우 에이전트 | 성취기준 등록~원고 다면 검토~대시보드를 한 플랫폼으로 연결 | |
| 디지털 | 스마트PPT 자동 생성 | 교과서(인디자인) 데이터를 추출·구조화해 수업용 PPT 자동 생성 |
| 퀴즈·게임 생성기 | 템플릿 선택 + 문항 입력만으로 독립형 HTML 퀴즈·게임 제작 | |
| 엠티처 교수·학습 문서 작업 도구 | 학교급·단원 선택으로 지도안·퀴즈·평가자료 초안을 자동 생성, 다포맷 추출 | |
| 플랫폼 | 라이브레인(LibrAIn) | 프롬프트 워크플레이스 + 콘텐츠 DB를 연결한 통합 AI 업무 플랫폼 |
| 디자인실 DNA | 디자인 자산 태깅·DB화와 프롬프트 아카이브로 AI 시안 생성·검색·추천 | |
| 일반 | 교사 네트워크 컨트롤타워 | 교사 데이터 통합·세그먼트 분류·협업 교사 추천 대시보드 |
| MAMA (인사·총무 챗봇) | 기존 인사·복지 Q&A 챗봇에 인증·KB 고도화를 더해 사내 공식 서비스화 | |
| EASY기안 | AI 채팅으로 기안 초안~결재라인 추천~그룹웨어 자동 상신까지 한 흐름 | |
| 업무간소화 프로그램 (Workflex) | ERP 자료를 기초 DB화, 피벗 포맷 저장·재사용으로 반복 엑셀 가공 자동화 | |
| 전결규정 챗봇 | 기존 챗봇에 문서 첨부 문의와 근거 규정 원문 분할 화면 추가 | |
| P&P본부 업무 자동화 CELL | 출고문서·영업대시보드·견적엔진 등 소형 자동화 도구 릴레이 개발 |
착수 전에 준비할 것
학습 안내1회차 전에 완료. 아래 두 가지를 준비해서 1회차 컨설팅에 가져오면, 첫 회차부터 곧바로 본론(과제 정의)으로 들어갈 수 있습니다.
① 이미 진행한 것이 있다면 — README를 먼저 제출
컨설팅 착수 전에 과제별로 미리 작성한 기획서나 일부 개발한 코드가 있다면, 그 내용을 요약한 README 파일(md)을 미리 제출해 주십시오. 삽화 발주 프로토타입, MAMA·EASY기안·전결규정 챗봇, P&P본부의 운영 중인 도구처럼 이미 움직이는 것이 있는 과제라면 특히 그렇습니다. 컨설턴트가 사전에 읽고 오면 1회차의 밀도가 완전히 달라집니다.
| README에 담을 것 | 내용 |
|---|---|
| 과제 개요 | 무엇을 자동화하려는가, 누가 쓰는가 — 3~5문장 |
| 현재 상태 | 기획서만 있음 / 프로토타입 있음 / 일부 운영 중 — 있는 그대로 |
| 지금까지 만든 것 | 화면·기능 목록, 사용 기술, 실행 방법(코드가 있는 경우) |
| 막힌 곳·고민 | 컨설팅에서 풀고 싶은 문제 — 구체적일수록 좋습니다 |
② 산출물 형식 규칙 — md 또는 html
이번 프로젝트에서 제출하는 모든 문서 산출물은 마크다운(.md) 또는 HTML(.html) 파일을 기본으로 합니다. 이유는 단순합니다.
1AI가 읽고 쓰는 형식
md는 AI 코딩 도구가 가장 잘 읽고 쓰는 형식입니다. 개발계획서가 md면 그대로 AI에게 주고 "이 계획서대로 만들어"라고 할 수 있습니다.
2코드와 함께 산다
문서가 코드 저장소 안에 md로 있으면 코드와 함께 버전 관리되고, 수정 이력이 남고, 개발이 진행될수록 문서도 함께 자랍니다.
3바로 열리고 바로 공유
html은 더블클릭으로 열리고 링크로 공유됩니다. 보고용 문서는 md로 쓰고 html로 변환하면 두 마리를 다 잡습니다.
사례로 보기 — 이 교재의 길잡이 사례를 소개합니다
이 교재는 매 회차 설명 끝에 실제로 완성된 하나의 시스템을 사례로 붙여, "그 회차의 활동을 실전에서는 이렇게 했다"를 보여줍니다. 사례 부분은 지금 보시는 것처럼 테두리가 있는 주황색 박스로 구분됩니다.
사례의 주인공은 AI 교육·컨설팅사 알앤비디파트너스의 사내 업무관리 시스템입니다. 내부 직원 7명과 외부강사 약 20명이 쓰는 시스템으로, 이런 문제에서 출발했습니다.
출발점 — 하나의 업무 흐름, 세 개의 연결되지 않은 도구
영업 → 견적 → 수주 → 일정 배정 → 강의 수행 → 계산서 발행 → 수금 → 외부강사 정산. 하나로 이어진 업무가 구글 시트(일정) · 에어테이블(프로젝트와 돈) · 엑셀(정산 지급대장) 세 곳에 흩어져 있었습니다. 영업이 성사되면 시트와 에어테이블에 이중 입력하고, 강의와 계약의 연결은 담당자의 기억에 의존하고, 월 매출·미수금·강사 실적은 매번 손으로 집계했습니다.
이 문제를 Next.js + PostgreSQL 웹 시스템 하나로 통합했습니다. 코드는 사람이 한 줄도 직접 쓰지 않고 AI 코딩 도구와의 대화(바이브코딩)로 개발했으며, 첫 코드부터 배포까지 약 5일, 그 과정의 모든 결정이 D1~D46 결정 로그로 남아 있습니다. 규모가 커 보이지만 화면 9개, 테이블 10개짜리 시스템입니다 — 여러분 과제와 다르지 않은 체급입니다.
코드는 AI가 짭니다.
과제 리더의 일은 정의하고, 결정하고, 검증하는 것입니다.
6회차 동안 여러분은 개발자가 되는 것이 아닙니다. 업무를 가장 잘 아는 사람으로서 무엇을 만들지 정의하고(1회차), 갈림길마다 결정을 내리고 기록하고(매 회차), AI가 "다 됐습니다"라고 할 때마다 정말 됐는지 확인하는(매 회차) 사람이 됩니다. 이 세 가지를 놓치지 않으면 코딩 경험이 없어도 시스템은 완성됩니다.
1회차 — 과제 정의와 ver1.0 개발
- 조별로 정의한 과제의 범위와 업무처리 프로세스를 재정의하고, SIPOC으로 분석할 수 있다.
- 사람이 하던 프로세스를 그대로 옮기지 않고, 프로그램 자동화에 맞는 프로세스로 재설계할 수 있다.
- 인풋·아웃풋 데이터와 구체적인 데이터 템플릿, 백엔드(저장)·프론트엔드(화면) 기획을 정의할 수 있다.
- 개발계획서를 완성하고, Plan 모드로 개발을 시작해 ver1.0을 만든다.
1회차는 6회차 전체에서 가장 중요한 날입니다. 이날 정의한 범위·프로세스·데이터가 남은 다섯 회차의 궤도를 결정합니다. 그리고 정의에서 멈추지 않습니다 — 1회차의 목표는 정의를 끝내고 실제 코딩까지 진행해 ver1.0을 만들어 보는 것입니다. 활동 순서는 다음과 같습니다.
STEP 1 · 업무 범위와 SIPOC 정의
첫 활동은 조별로 정의해 온 과제의 범위를 다시 긋고, 업무처리 프로세스를 재정의·분석하는 것입니다. 기획서의 과제 설명은 대개 "무엇이 불편한지"까지는 잘 담고 있지만, "그 업무가 정확히 어디서 시작해서 어디서 끝나는지"는 흐릿한 경우가 많습니다. 이걸 선명하게 만드는 도구가 SIPOC입니다.
SIPOC은 하나의 업무 프로세스를 다섯 칸으로 정리합니다 — 어떤 공급자(Supplier)로부터 어떤 데이터(Input)를 받아, 어떻게 처리(Process)해서, 어떤 산출물(Output)을 만들고, 그것을 어떤 고객(Customer)에게 제공하는가.
예시 — 삽화 발주 업무의 SIPOC
미래엔 과제 중 하나인 삽화 발주 관리를 예로 들면 이렇게 정리됩니다. 여러분 과제도 이 표 한 장으로 시작하십시오.
| 구분 | 내용 |
|---|---|
| S 공급자 | 삽화를 발주하는 편집자(발주 요청), 삽화 작가(시안·완성본), 단가 기준을 관리하는 부서 |
| I 인풋 | 발주 요청 정보(도서명·컷 수·삽화 유형·사이즈·작가풍·마감일), 컷별 단가표, 참고 이미지 |
| P 프로세스 | ① 발주서 작성 → ② 작가 발주 → ③ 시안 수신·검토 → ④ 수정 요청(반복) → ⑤ 최종본 검수 → ⑥ 정산 처리 |
| O 아웃풋 | 표준 발주서(AI 샘플 이미지 포함), 진행 현황·수정 이력 대시보드, 정산 자료 |
| C 고객 | 삽화 작가(발주서 수신), 편집팀(진행 현황), 정산 담당(정산 자료) |
STEP 2 · 휴먼 프로세스를 프로그램 프로세스로 재설계한다
SIPOC의 P(프로세스)를 채울 때 반드시 거쳐야 할 단계가 있습니다. 먼저 기존에 사람이 하던 프로세스(휴먼 프로세스)를 있는 그대로 정리하고, 그다음 이것을 프로그램이 수행하는 프로세스로 어떻게 바꿀 것인지 재정의하는 것입니다.
가장 흔한 실패가 휴먼 프로세스를 그대로 코드로 변환해서 자동화 프로세스를 만드는 것입니다. 사람의 일 순서를 그대로 프로그램에 옮기면, 사람의 한계까지 그대로 물려받은 어색한 시스템이 나옵니다. 이 둘은 원래 다릅니다.
휴먼 프로세스 — 사람의 방식
- 한 건씩 순차 처리한다
- 맥락을 기억과 눈치로 보완한다
- 예외를 만나면 즉석에서 판단한다
- 중간 결과를 머릿속·개인 파일에 둔다
- 같은 정보를 여러 곳에 반복 입력한다
- 판단 기준이 담당자의 암묵지로 존재한다
프로그램 프로세스 — 기계의 방식
- 수백 건을 일괄·병렬 처리한다
- 저장된 데이터만 안다 — 맥락을 데이터로 명시해야 한다
- 예외는 미리 정의된 규칙으로 처리하거나 사람에게 넘긴다
- 모든 중간 산출물을 저장·추적할 수 있다
- 한 번 입력하면 필요한 모든 곳에서 참조한다
- 판단 기준이 명문화된 규칙·코드로 존재한다
진행 순서 — 정리하고, 의심하고, 다시 설계한다
① 휴먼 프로세스 정리. 실제로 쓰는 파일을 열어 놓고, 업무를 하는 순서대로 단계를 나열합니다. 각 단계에서 "무엇을 보고(인풋), 무엇을 판단하고(기준), 무엇을 남기는지(아웃풋)"를 적습니다. 담당자 머릿속에만 있는 판단 기준("이런 건은 대충 이렇게 처리해요")과 예외 케이스("가끔 이런 게 들어오는데 그땐…")를 최대한 끄집어내 명문화합니다.
② 단계별 의심. 정리된 휴먼 프로세스의 각 단계에 다섯 가지 질문을 던집니다.
| 재설계 질문 | YES라면 |
|---|---|
| 이 단계는 사람의 한계 때문에 존재하는가? (기억 보조, 옮겨 적기, 찾기) | 프로그램에선 단계 자체가 사라질 수 있습니다 |
| 여러 단계를 한 번에 처리할 수 있는가? | 합치십시오 — 사람은 못 해도 프로그램은 합니다 |
| 판단 기준을 규칙으로 쓸 수 있는가? | 규칙으로 명문화해 자동화 대상에 넣습니다 |
| 규칙으로 못 쓰는 판단인가? | 사람 확인 지점으로 남기되, 프로그램이 후보와 근거를 준비해 주게 합니다 |
| 예외가 들어오면 어디로 보내는가? | 예외 격리 경로(별도 목록·상태)를 프로세스에 명시합니다 — 예외를 버리면 데이터가 사라집니다 |
③ 프로그램 프로세스 확정. 질문을 통과한 결과를 to-be 프로세스로 다시 그립니다. as-is(휴먼)와 to-be(프로그램)를 나란히 놓은 표가 개발계획서의 핵심 페이지가 됩니다.
to-be 프로세스는 플로우차트로 확정한다
재설계한 프로그램 프로세스는 문장 목록으로 두지 말고 플로우차트로 그려서 확정합니다. 플로우차트 한 장에는 다섯 가지가 다 보여야 합니다 — 어떤 정보가 어디서 들어오고(인풋), 어떤 정보와 합쳐지고(결합), 어떻게 처리되고(프로세싱), 결과가 어떤 형식에 담기고(아웃풋), 누구에게 전달되는지(고객). SIPOC이 다섯 칸짜리 표라면, 플로우차트는 그 표에 흐름과 분기를 입힌 설계도입니다.
| 요소 | 그리는 법 | 반드시 적을 것 |
|---|---|---|
| 인풋 | 흐름의 시작에 데이터 모양(평행사변형)으로 | 누가·어디서 주는지, 형태(파일·입력 폼·시스템) |
| 결합 데이터 | 처리 상자 옆에서 화살표로 합류 | 무엇을 기준(키)으로 합쳐지는지 — 고객사명, 프로젝트 번호 등 |
| 처리 | 사각형, 동사로 | 자동인지 사람 확인인지 — 색으로 구분 |
| 판단·분기 | 마름모, 질문형으로 | 예/아니오 각각의 경로 — 예외 경로 포함 |
| 아웃풋·전달 | 데이터 모양 + 받는 사람 | 형식(PDF·화면·메일·DB 저장)과 customer |
플로우차트는 그림 도구 없이 mermaid 문법으로 md 파일 안에 그릴 수 있습니다. 이렇게 만든 플로우차트는 사람이 보는 설계도이자, AI에게 "이 흐름대로 구현해 줘"라고 그대로 건네는 사양서가 됩니다.
flowchart LR
A[/발주 요청 입력 · 편집자/] --> B[표준 발주서 생성 · 자동]
P[/단가표 · 참조 데이터/] --> B
B --> C[/발주서 PDF → 작가 메일 발송/]
C --> D{시안 승인?}
D -- 아니오 --> E[수정 요청 기록 → 재발송]
D -- 예 --> F[/정산 자료 → 정산 담당/]
STEP 3 · 인풋·아웃풋 데이터 정의와 데이터 템플릿
학습 안내작성. SIPOC의 I와 O를 데이터 명세 수준까지 구체화합니다. 완료 기준: 인풋마다 항목 명세표가 있고, 실물 샘플 파일을 확보했는가.
1회차에서 인풋·아웃풋 데이터를 정의하고, 구체적인 데이터 템플릿까지 정합니다. "발주 정보를 입력받는다" 수준으로는 개발을 시작할 수 없습니다. 항목 하나하나를 아래 명세표 양식으로 확정하십시오.
| 항목명 | 형식 | 예시 값 | 필수 | 비고 |
|---|---|---|---|---|
| 도서명 | 텍스트 | 중학 수학 1 | 필수 | 도서 마스터에서 선택 |
| 컷 수 | 숫자 | 12 | 필수 | 1 이상 |
| 삽화 유형 | 선택 | 인물 / 배경 / 도해 | 필수 | 선택지 고정 — 자유 입력 금지 |
| 마감일 | 날짜 | 2026-08-14 | 필수 | 오늘 이후만 허용 |
| 참고 이미지 | 파일 | ref_01.png | 선택 | 여러 장 가능 |
템플릿을 정의할 때의 원칙 세 가지입니다.
1실물 데이터를 먼저 확보
가짜 데이터로 개발하지 않습니다. 지금 실제로 쓰는 엑셀·문서·시스템 내보내기 파일을 확보해서 그 안의 진짜 항목·진짜 지저분함(빈칸, 오타, 제각각인 표기)을 보고 템플릿을 정의합니다.
2자유 입력을 줄인다
사람은 "인물삽화", "인물 컷", "인물"을 같은 것으로 알지만 프로그램은 모릅니다. 선택형으로 바꿀 수 있는 항목은 전부 선택형으로 — 데이터 품질은 입력 단계에서 결정됩니다.
3아웃풋도 템플릿으로
산출물(보고서·발주서·결과표)도 항목과 서식을 미리 확정합니다. 아웃풋 템플릿이 확정돼야 "결과가 맞게 나왔는지"를 2·3회차에서 판정할 수 있습니다.
STEP 4 · 백엔드·프론트엔드 기획
학습 안내작성. 저장 계획(백엔드)과 화면 계획(프론트엔드)을 각각 표로 만듭니다. 완료 기준: 두 표만 보고 무엇을 저장하고 어떤 화면을 만들지 남이 이해할 수 있는가.
백엔드 기획 — 어떤 데이터를 저장할 것인가
화면 뒤에서 데이터를 저장하고 처리하는 부분이 백엔드입니다. 기획 단계에서 답할 질문은 하나입니다: "무엇을 저장할 것인가." 아래 질문에 하나씩 답하면 저장 계획이 됩니다.
| 질문 | 판단 기준 |
|---|---|
| 인풋 원본도 저장하는가? | 원본을 남기면 "처리 결과가 이상할 때 원본과 대조"가 가능해집니다. 파일 원본은 보관하고, DB에는 구조화된 형태로 넣는 이원화가 보통 정답입니다 |
| 중간 산출물을 저장하는가? | 단계가 여러 개면 중간 결과를 저장해야 어느 단계에서 틀어졌는지 찾을 수 있습니다 |
| 결과 이력을 남기는가? | "언제 누가 무엇을 처리했나"가 필요한 업무(발주·정산·검수)라면 이력은 필수입니다 |
| 수정 이력이 필요한가? | 수정 횟수·사유가 관리 대상인 업무(삽화 수정 요청 등)라면 수정 자체를 데이터로 저장합니다 |
| 사용자·권한을 저장하는가? | 여러 명이 쓰면 로그인·권한이 필요합니다. 단, 본격 구현은 5회차 — 지금은 "필요하다"만 기록 |
테이블과 필드를 정의한다 — 인풋과 결과가 담길 그릇
저장할 데이터가 정해지면 그것을 담을 테이블을 정의합니다. 테이블은 한 종류의 데이터를 담는 표입니다 — 한 행이 데이터 1건, 각 필드(열)가 항목 하나입니다. 인풋으로 들어온 것을 담는 테이블과 프로세싱된 결과를 담는 테이블을 구분해서, 테이블마다 아래 양식(테이블 정의서)을 채웁니다.
| 테이블 정의서 양식 — 예: 발주서(Order) 테이블 | |||
|---|---|---|---|
| 필드명 | 형식 | 설명 | 연결 |
| id | 고유번호 | 발주서 1건마다 자동 발번 (O001…) | 기본 키(PK) |
| bookId | 고유번호 | 어느 도서의 발주인가 | → 도서.id |
| illustratorId | 고유번호 | 어느 작가에게 발주했나 | → 작가.id |
| cutCount · type · dueDate | 숫자·선택·날짜 | 컷 수 · 삽화 유형 · 마감일 | — |
| status | 선택 | 진행 / 수정중 / 완료 | — |
핵심은 연결 필드입니다. 관계형 DB에서 테이블끼리는 고유번호(id) 필드로 연결됩니다 — 발주서 테이블에 작가의 "이름"이 아니라 작가 테이블의 id를 담는 식입니다. 이름은 바뀌고 중복될 수 있지만 id는 유일하기 때문입니다. 어떤 테이블의 어떤 필드가 어느 테이블을 가리키는지 정하는 것이 관계 정의이고, 관계의 종류는 네 가지뿐입니다.
| 관계 | 뜻 | 예 | 구현 방법 |
|---|---|---|---|
| 1 : 1 | 한 건에 정확히 한 건 | 강의 1건 ↔ 지급행 1건 | 한쪽이 상대 id를 유일(unique)하게 보유 |
| 1 : 다 (1:N) | 한 건 아래에 여러 건 | 발주서 1건 → 수정 요청 N건 | 자식(수정 요청)이 부모의 id(orderId)를 필드로 보유 |
| 다 : 1 (N:1) | 여러 건이 한 건을 가리킴 | 강의 N건 → 강사 1명 | 1:다를 반대쪽에서 본 것 — 구조는 같음 (강의가 instructorId 보유) |
| 다 : 다 (N:M) | 서로가 서로를 여러 건씩 | 교과서 N권 ↔ 집필자 M명 | 중간(연결) 테이블을 하나 만들어 양쪽 id를 한 행에 담는다 |
프론트엔드 기획 — 어떤 화면에서 무엇을 하게 할 것인가
사용자들에게 어떤 화면을 보여주고 어떤 기능을 제공할지 화면 목록으로 정리합니다. 화면 하나당 한 행이면 충분합니다.
| 화면명 | 보여주는 것 | 할 수 있는 것 | 주 사용자 |
|---|---|---|---|
| 발주 목록 | 전체 발주 건 + 상태(진행/수정중/완료) | 검색·필터, 새 발주 등록 | 편집자 |
| 발주 상세 | 발주 내용, 수정 이력, 정산 정보 | 수정 요청 등록, 상태 변경 | 편집자·관리자 |
| 대시보드 | 진행 현황 집계, 지연 건 경고 | 기간·작가별 조회 | 팀장 |
STEP 5 · 개발계획서 완성
학습 안내작성. STEP 1~4의 산출물을 개발계획서 한 벌(md)로 묶습니다. 완료 기준: 이 문서 하나만 주면 AI가 개발을 시작할 수 있는가.
STEP 1~4의 산출물을 md 파일 하나로 묶으면 그것이 개발계획서입니다. 목차는 다음 여덟 개면 충분합니다.
1. 문제 정의 — 무엇이 불편한가, 한 문장의 문제 정의문 2. SIPOC — 공급자 · 인풋 · 프로세스 · 아웃풋 · 고객 3. 프로세스 재설계 — as-is/to-be 대비표 + to-be 플로우차트(인풋·결합·처리·아웃풋·전달) 4. 데이터 정의 — 인풋 템플릿 명세, 테이블 정의서(필드·연결·관계), 아웃풋 템플릿 5. 화면·기능 — 화면 목록표 (화면명 | 보여주는 것 | 할 수 있는 것 | 사용자) 6. 기술 스택 — AI에게 물어서 결정 (아래 프롬프트 참고) 7. 만들지 않을 것 — 이번 범위에서 제외하는 것들 8. 일정 — 6회차 로드맵에 맞춘 우리 조의 계획
STEP 6 · Plan 모드 가동, ver1.0 만들기
학습 안내실행. 개발계획서를 AI 코딩 도구에 주고 Plan 모드로 구현 계획을 받은 뒤, 검토·승인하고 첫 코딩을 진행합니다. 완료 기준: 인풋을 넣으면 아웃풋이 나오는 한 사이클이 동작하는가.
정의가 끝났으면 그날 바로 개발을 시작합니다. Claude Code 같은 AI 코딩 도구에는 Plan 모드가 있습니다 — 코드를 바로 고치지 않고, 먼저 구현 계획을 세워서 사람에게 승인받는 모드입니다. 개발계획서를 주고 Plan 모드로 시작하면, AI가 "이런 순서로 이렇게 만들겠다"는 계획을 내놓습니다. 계획을 읽고, 이상한 부분을 바로잡고, 승인하면 코딩이 시작됩니다.
ver1.0의 기준은 완성도가 아니라 관통입니다. 화면이 투박해도, 예외 처리가 없어도 됩니다. 대표 인풋 하나를 넣었을 때 프로세스를 통과해 아웃풋이 나오는 것 — 그 한 사이클이 돌면 ver1.0입니다. 골격이 관통되면 나머지 다섯 회차는 이 골격에 살을 붙이는 일입니다.
사례로 보기 — RNBD의 과제 정의와 ver1.0
문제 정의문과 SIPOC
RNBD 팀은 소스 파일 3개를 열어 놓고 관찰한 끝에 문제를 한 문장으로 압축했습니다 — "영업부터 정산까지 하나의 흐름인 일이, 세 개의 연결되지 않은 도구에 흩어져 있어 이중 입력과 수작업 집계가 발생한다. 한 곳에 한 번만 입력하면 나머지가 자동으로 연결되는 시스템이 필요하다." SIPOC으로 정리하면 이렇습니다.
| 구분 | 내용 |
|---|---|
| S 공급자 | 영업 담당(견적·수주 정보), 고객사(계약·담당자 정보), 내부 직원·외부강사(일정·수행 실적), 회계법인(원천징수 계산 기준) — 그리고 기존 3개 도구가 초기 데이터 공급원 |
| I 인풋 | 에어테이블 내보내기 CSV(프로젝트 159행), 회사 캘린더 엑셀(색칠 셀 + 셀 노트 1,022개), 외부 인건비 지급대장 엑셀(지급내역 + 계좌번호 시트) |
| P 프로세스 | 견적서 작성·발송 → 프로젝트 등록 → 캘린더 일정 배정(강의↔프로젝트 연결) → 강의 수행 → 계산서 발행 → 수금 추적 → 외부강사 지급행 자동 생성 → 지급 |
| O 아웃풋 | 캘린더·프로젝트·계산서·지급대장 화면, 견적서 PDF와 발송 이력, 대시보드(계약총액·매출·미청구·미수금) |
| C 고객 | 전 직원(조회·입력), 관리자(개인별 실적·승인), 외부강사(정산 수령), 고객사(견적서 수신) |
휴먼 프로세스 → 프로그램 프로세스 재설계
RNBD가 휴먼 프로세스를 그대로 옮기지 않은 지점들이 이 사례의 백미입니다.
| 휴먼 프로세스 (as-is) | 프로그램 프로세스 (to-be) |
|---|---|
| 시간·장소·주제를 캘린더 셀의 메모(셀 노트)에 적음 — 검색 불가 | 시간·장소·주제를 구조화된 필드로 저장 — 검색·집계 가능 |
| 외부강사는 "외부 1~4"라는 자리 행으로 관리 — 누가 강의했는지 추적 불가 | 내부·외부를 통합한 멤버 테이블에 실명으로 — 강사별 실적·정산 자동 연결 |
| 영업 성사 시 시트와 에어테이블에 이중 입력 | 한 번 입력 — 견적서에서 "프로젝트로 반영" 클릭이면 끝 |
| 외부강사 강의 후 지급대장에 수기로 행 추가, 수식으로 세금 계산 | 외부강사 강의를 등록하면 지급행이 자동 생성되고 원천징수가 자동 계산 |
| 월 매출·미수금을 매번 손으로 집계 | 대시보드가 실시간 자동 집계 — 특히 "미청구 = 계약총액 − 발행완료 합계"는 시트 시절엔 아무도 계산하지 않던 숫자 |
자동 연결 흐름 — 견적에서 미청구까지, 플로우차트로 본 to-be
재설계된 to-be 프로세스를 플로우차트로 그리면 이 시스템의 본질이 한눈에 보입니다. 사람이 하는 일은 파란 상자 네 개뿐 — 나머지 생성·발송·등록·계산·집계는 전부 시스템이 잇습니다.
데이터 정의 — 실물 파일에서 출발한 템플릿
인풋 3종은 전부 실물 파일로 확보한 뒤 구조를 명세화했습니다. 가짜 예시 데이터가 아니라 빈칸·별칭·비정형 메모가 섞인 진짜 데이터로 시작했기 때문에, 뒤 회차의 함정들을 미리 만날 수 있었습니다.
| 인풋 파일 | 템플릿(구조) 명세 |
|---|---|
| 모든 프로젝트.csv 에어테이블 내보내기 | 1행 = 계약 1건, 22컬럼 — 고객사 · 프로젝트명 · 담당자 · 금액 3종(총액/공급가액/세금) · 업무 단계 · 계산서/수금 상태 · 수금계좌 · 사업자등록증 URL |
| 회사 캘린더.xlsx | 행 = 사람(내부 7명 + 외부 1~4), 열 = 날짜, 셀 값 = 고객사명, 셀 노트 = * 시간 / * 장소 / * 주제 / * 담당자 연락처 / * 특이사항 정형 템플릿 |
| 지급대장.xlsx | 회계처리연월 · 지급일자 · 대상자 · 소득구분 · 금액 배분(회사/강사 share) · 소득세 · 지방세 · 실지급액 + 계좌번호 별도 시트. 세금 수식: 소득세 = share × 3%(사업소득) 또는 8%(기타소득)를 10원 절사, 지방세 = 소득세 × 10% 절사 |
백엔드·프론트엔드 기획과 ver1.0
백엔드: "인풋도 저장할 것인가"에 대한 RNBD의 답은 이원화였습니다 — 원본 파일은 sources/ 폴더에 그대로 보존하고, DB에는 구조화해 이관. 저장 구조는 프로젝트·계산서·강의의 3층 구조(프로젝트 1건 : 계산서 N장 : 강의 N건)를 뼈대로 테이블 10개. 프론트엔드: 대시보드·캘린더·프로젝트·강의·계산서·견적서·고객사·멤버·지급 화면 9종을 화면 목록표로 확정했습니다.
저장 설계의 산출물이 아래 테이블 관계도입니다. 모든 연결이 이름이 아니라 id 필드로 맺어져 있습니다. 참고로 이 시스템에 다:다 관계는 없었습니다 — 필요했다면(예: 강의 N건 ↔ 교재 M권) 중간 테이블을 두는 표준 방식으로 풀었을 것입니다.
그리고 정의 당일(D1, 첫날)에 코딩까지 진행했습니다. 프로젝트 스캐폴드 → 테이블 8개 스키마 → 실데이터 이관 초안 → 전 화면 초안 → 프로덕션 빌드 통과까지가 하루. 이것이 ver1.0입니다. 흥미로운 결정 하나 — 팀은 "목업(가짜 화면) 대신 실데이터 먼저"를 원칙으로 세워, 화면을 예쁘게 만들기 전에 실데이터 이관부터 했습니다(결정 로그 D9).
1회차 자가 점검
- 과제의 범위(만들 것 / 만들지 않을 것)와 SIPOC 표가 완성되었다.
- 휴먼 프로세스(as-is)와 프로그램 프로세스(to-be)를 나란히 놓은 대비표가 있다.
- to-be 프로세스가 플로우차트로 그려져 있다 — 어떤 정보가 어디서 들어와 무엇과 합쳐지고, 결과가 어떤 형식으로 누구에게 가는지 한 장에 보인다.
- 인풋마다 항목 명세표(데이터 템플릿)가 있고, 실물 샘플 파일을 확보했다.
- 무엇을 저장할지(백엔드), 어떤 화면에서 무엇을 하게 할지(프론트엔드)가 표로 정리되었다.
- 테이블 정의서가 있다 — 테이블·필드·연결 필드(id)와 관계(1:1 / 1:N / N:M)가 정의되어 있다.
- 개발계획서(md)가 8개 목차를 갖춰 완성되었다.
- Plan 모드로 구현 계획을 검토·승인했고, 인풋 → 아웃풋 한 사이클이 도는 ver1.0이 있다.
1회차 산출물 (md / html)
- 개발계획서.md — SIPOC · 프로세스 재설계와 플로우차트 · 데이터 템플릿 · 테이블 정의서 · 화면/저장 기획 포함
- ver1.0 코드 + README.md — 실행 방법, 현재 동작 범위
2회차 — 기능 확인, 데이터 확인, 그리고 전 기능 구현
- ver1.0의 기능과 데이터를 체계적으로 확인하고, 문제를 개선 요청으로 바꿀 수 있다.
- 실데이터 전수 대조로 처리 결과의 정확성을 검증할 수 있다.
- 기능 목록의 모든 기능을 구현해 "기능 완성" 상태에 도달한다.
2회차의 목표는 하나입니다 — 계획서의 기능 목록을 100% 구현하는 것. ver1.0은 골격 하나가 관통된 상태였습니다. 이제 기능을 하나씩 확인하고, 데이터를 확인하고, 다듬기를 반복해서 모든 기능이 실제로 동작하는 상태(기능 완성)까지 갑니다. 이 회차의 리듬은 확인 → 기록 → 요청 → 재확인의 반복입니다.
기능 확인 — 목록 대비, 화면 대비
기능 확인의 기준은 느낌이 아니라 1회차 개발계획서의 화면·기능 목록표입니다. 표의 각 행에 대해 세 가지를 확인하고 상태를 기록합니다.
| 확인 항목 | 확인 방법 |
|---|---|
| 동작하는가 | 화면을 직접 열고, 대표 케이스 하나를 처음부터 끝까지 수행해 본다 |
| 맞게 동작하는가 | 결과 값을 손으로 계산한 값·기존 방식의 결과와 대조한다 |
| 쓸 만하게 동작하는가 | 실제 업무 리듬으로 써 본다 — 클릭이 너무 많은가, 찾는 게 안 보이는가 |
세 번째 항목에서 발견한 불편이 이 회차의 원료입니다. 프론트엔드 다듬기의 80%는 불편을 말로 정확히 묘사하는 것입니다. "캘린더가 이상해"가 아니라 — "월을 넘기면 스크롤이 맨 위로 튀어서, 보던 주를 다시 찾아야 해. 월을 바꿔도 보던 위치가 유지되면 좋겠어"처럼, 상황 + 현재 동작 + 기대 동작의 3요소로 말하면 AI는 거의 항상 한 번에 고칩니다.
데이터 확인 — 전수 대조와 숨은 데이터 발굴
기능이 돌아도 데이터가 틀리면 아무도 그 시스템을 믿지 않습니다. 데이터 확인의 원칙은 표본이 아니라 전수입니다. 특히 돈·건수처럼 기존 방식(엑셀 등)에 정답이 이미 있는 데이터는, 기존 결과물과 전 행을 대조해서 몇 건 중 몇 건이 일치하는지를 숫자로 확인합니다.
또 하나 — 인풋 데이터에는 눈에 보이는 값 말고도 정보가 숨어 있는 경우가 많습니다. 엑셀의 셀 메모, 셀 색깔, 숨긴 시트·열, 파일명 규칙 같은 것들입니다. 이관·처리 후 "뭔가 빠진 것 같다" 싶으면 이렇게 물으십시오.
개선 루프 — 기능 완성까지 반복
학습 안내반복 수행. 아래 루프를 기능 목록의 전 항목이 "완료"가 될 때까지 돌립니다. 완료 기준: 기능 목록표의 모든 행이 세 가지 확인(동작/정확/사용성)을 통과했는가.
이 루프를 돌리다 보면 데이터 구조를 바꿔야 하는 큰 결정을 만나기도 합니다. 미루고 싶어지지만 — 구조 결정을 미루면 이자가 붙습니다. 코드가 쌓일수록 같은 변경의 비용이 커지므로, 구조 문제는 발견한 회차에 해결하는 것이 원칙입니다.
사례로 보기 — RNBD의 검증과 개선
연결률 33% → 89% — 확인이 만든 개선
ver1.0의 강의↔프로젝트 자동 연결률은 33%(756건 중 185건)였습니다. 원인을 들여다보니 같은 고객사가 파일마다 다른 이름으로 적혀 있었습니다 — "한화인경원"과 "한화인재경영원"처럼. 사람 눈엔 당연히 같은 회사지만 프로그램은 모릅니다(1회차에서 본 "눈치 판단"의 전형). 대화로 별칭 규칙을 추가해 이관 로직 v2를 다시 만들자 연결률이 89%(555건 중 493건)로 뛰었고, 고객사 명칭 통합으로 498건까지 올라갔습니다. 남은 미연결 강의는 버리지 않고 "(미연결 강의)" 프로젝트에 격리한 뒤 화면에서 사람이 재배정했습니다 — 예외를 규칙 또는 격리 경로로 처리하는 원칙 그대로입니다.
셀 노트 1,022개 — 숨은 데이터 발굴
이관 후 "시간·장소 정보가 다 사라졌다"는 문제가 발견됐습니다. 알고 보니 그 정보는 셀 값이 아니라 셀 노트(메모)에 들어 있었습니다. "이 파일에서 값 말고 또 읽을 수 있는 게 있어?"라는 질문으로 노트 파서를 추가해, 셀 노트 1,022개에서 강의 555건의 시간 209건·장소 142건·메모 181건을 복원했습니다.
원천징수 전수 대조 — "거의 같은" 계산은 없는 것과 같다
정산 세금 계산을 처음엔 "1원 단위 버림"으로 구현했는데, 엑셀 지급대장과 값이 미묘하게 달랐습니다. 값이 채워진 전 36행을 전수 대조한 끝에 회계법인의 실제 규칙이 "10원 단위 절사 + 순차 계산"임을 발견했고, 수정 후 36건 중 36건 일치(100%)를 확인했습니다. 회계 숫자는 1원만 어긋나도 시스템 전체의 신뢰를 잃습니다.
기능 다듬기와 구조 결정
기능 완성 구간(D20~D32)에서는 불편 묘사 → 개선의 반복으로 표 컬럼 순서·폭 조절, 엑셀처럼 셀을 클릭해 고치는 인라인 편집(방향키·복사/붙여넣기), 드롭다운 선택 같은 사용성 기능이 완성됐습니다. 큰 구조 결정도 이 시기에 있었습니다 — 내부 직원과 외부강사를 두 테이블로 나눠 시작했다가 코드가 전부 이중화되는 문제를 겪고 단일 멤버 테이블로 병합하는 대공사(D26)를 치렀습니다. 교훈은 한 줄입니다: "구조 결정을 미루면 이자가 붙습니다."
2회차 자가 점검
- 기능 목록표의 모든 행이 동작·정확성·사용성 확인을 통과했다 (기능 100% 구현).
- 정답이 있는 데이터는 기존 결과물과 전수 대조했고, 일치율을 숫자로 안다.
- 인풋 파일의 숨은 데이터(메모·색·숨긴 시트)를 조사했다.
- 결정 로그(DEV-LOG.md)를 시작했고, 주요 결정이 번호로 기록되어 있다.
2회차 산출물 (md / html)
- 기능 확인 결과표 — 기능 목록 대비 상태·발견 문제·처리 결과
- 데이터 검증 보고 — 전수 대조 결과(N건 중 N건 일치), 불일치 원인과 조치
- 결정 로그(DEV-LOG.md) — D번호 기록 시작
- 기능 완성 버전 코드 + 갱신된 README.md
3회차 — 하네스 엔지니어링: 품질을 측정하고 개선한다
- 테스트 데이터를 자동으로 생성하고, 대량 인풋을 넣어 아웃풋을 측정하는 하네스를 만들 수 있다.
- 아웃풋 품질에 대한 측정 지표를 정의하고, 현수준을 측정할 수 있다.
- 지표 개선을 위한 원인분석 → 개선 아이디어 → 적용 → 효과 평가의 사이클을 돌릴 수 있다.
2회차까지는 "기능이 도는가"를 봤다면, 3회차부터는 "아웃풋의 품질이 몇 점인가"를 봅니다. 손으로 한 건씩 넣어 보는 확인으로는 품질을 말할 수 없습니다. 필요한 것은 하네스(harness) — 시스템에 인풋을 자동으로 대량 투입하고 아웃풋을 자동으로 수집·채점하는 시험 장치입니다. 하네스가 있으면 "고쳤더니 좋아졌나?"를 1분 만에 숫자로 답할 수 있습니다.
테스트 데이터 자동 생성
실데이터만으로는 시험 케이스가 부족합니다. 실데이터의 구조와 분포를 닮은 테스트 데이터를 스크립트로 자동 생성하십시오. 세 가지 원칙이 있습니다.
1재현 가능하게
난수 시드(seed)를 고정해 돌릴 때마다 같은 데이터가 나오게 합니다. 그래야 "어제의 87%"와 "오늘의 91%"가 같은 시험지 위의 비교가 됩니다.
2실데이터를 닮게
깨끗한 데이터만 만들면 시험이 안 됩니다. 실데이터에 있는 빈칸·오타·별칭·형식 위반을 비율까지 흉내 내서 섞습니다.
3엣지 케이스를 심기
경계값(0건, 최대치, 마감일 당일), 특수문자, 중복, 극단적으로 긴 입력 등 일부러 어려운 케이스를 포함합니다. 정답을 알고 심었으니 채점도 가능합니다.
품질 지표 정의와 현수준 측정
"품질이 좋다/나쁘다"를 숫자로 바꾸는 것이 지표 정의입니다. 과제 유형별로 자주 쓰는 지표는 다음과 같습니다 — 이 중 2~4개를 골라 우리 과제의 지표로 확정하십시오.
| 지표 | 정의 · 산식 | 어울리는 과제 |
|---|---|---|
| 정확도 / 일치율 | 정답과 일치한 건 ÷ 전체 건 (정답: 기존 결과물 또는 심어 둔 기대값) | 정산·집계 계산, 데이터 추출·변환, 교열 검출 |
| 처리 성공률 | 에러 없이 끝까지 처리된 건 ÷ 투입 건 | 파일 처리, 문서 생성, 파이프라인형 과제 |
| 검출률 / 누락률 | 찾아야 할 것 중 찾은 비율 / 놓친 비율 | 교열, 팩트체크, 규정 위반 점검 |
| 오탐률 | 지적한 것 중 사실은 문제가 아니었던 비율 | 교열·점검류 — 오탐이 많으면 사람이 안 씁니다 |
| 사람 수정률 | AI 초안 중 사람이 고친 비율(분량 기준) | 초안 생성형 과제(지도안·기안·시안) |
| 처리 시간 | 건당 평균 처리 시간, 최대 시간 | 모든 과제 — Before/After 비교의 기본 |
지표마다 아래 다섯 칸을 채우면 지표 정의서가 됩니다. 그리고 하네스를 돌려 현수준 칸을 실측값으로 채웁니다 — 이 숫자가 우리 과제의 출발선입니다.
| 지표명 | 정의(산식) | 측정 데이터 | 현수준 | 목표 | |--------|-----------|------------|--------|------| | 연결 정확도 | 자동 연결 성공 건 ÷ 전체 건 | 테스트 500건 | 87% | 95% | | 처리 성공률 | 무에러 완료 ÷ 투입 | 테스트 500건 | 96% | 99% |
원인분석 → 개선 → 효과 평가
학습 안내사이클 수행. 현수준 측정에서 나온 실패 건들을 원료로 개선 사이클을 최소 1회 완주합니다. 완료 기준: Before/After 지표 비교표가 있는가.
① 원인분석. 실패한 건들을 전부 모아 오류 유형별로 분류합니다. "명칭 불일치 41건, 날짜 형식 오류 17건, 빈 필드 9건…"처럼 세어 보면 대개 상위 2~3개 유형이 실패의 대부분을 차지합니다(파레토). 거기부터 공략합니다.
② 개선 아이디어 도출. 유형별로 "규칙 추가로 잡을 수 있는 것 / 입력 단계에서 막을 수 있는 것 / 사람 확인으로 보낼 것"을 나눠 개선안을 만듭니다. AI에게 실패 건들을 주고 "이 실패들의 공통 패턴과 개선안을 제안해"라고 묻는 것도 효과적입니다.
③ 적용과 효과 평가. 개선안을 한 번에 하나씩 적용하고, 같은 시드의 하네스를 다시 돌려 지표를 재측정합니다. 한꺼번에 여러 개를 바꾸면 무엇이 효과를 냈는지 알 수 없게 됩니다.
| 개선안 | 대상 오류 유형 | Before | After | 판정 | |--------|--------------|--------|-------|------| | 고객사 별칭 사전 추가 | 명칭 불일치 | 87% | 94% | 채택 | | 날짜 파서 형식 3종 추가 | 날짜 형식 오류 | 94% | 96% | 채택 |
측정하지 않으면 개선할 수 없습니다.
이번 회차부터 품질을 숫자로 말합니다.
"좋아진 것 같다"는 개선이 아닙니다. 같은 시험지(시드 고정 테스트 데이터)로 재 본 Before/After 숫자가 개선입니다. 3회차에 만든 하네스와 지표는 이후 회차의 모든 변경에 재사용됩니다 — 4회차의 고도화가 품질을 해치지 않았는지, 5회차의 안정화 작업 후에도 결과가 같은지, 6회차의 최종 효과가 얼마인지. 하네스는 한 번 만들어 끝까지 쓰는 자산입니다.
사례로 보기 — RNBD의 측정과 개선 사이클
시드 고정 테스트 데이터 생성기
RNBD에는 시드를 고정한 실습 데이터 재생성 스크립트가 있습니다. 돌릴 때마다 고객사 50 · 멤버 19(내부 7 + 외부 12) · 프로젝트 72 · 강의 225 · 계산서 52 · 견적서 53 · 지급 55 · 일정 47건이 똑같이 만들어집니다. 실데이터의 구조(3층 구조, 소득 구분별 세금 규칙)를 그대로 닮았고, 재현 가능하므로 어떤 변경 후에도 같은 조건에서 재검증할 수 있습니다.
전수 대조를 지표로 — 측정의 실제 모습
RNBD의 품질 측정은 화려한 도구가 아니라 전수 대조와 감사(audit) 스크립트였습니다. 원천징수 계산 일치율 36/36(100%), 강의 시간 형식 감사 526건 중 위반 0건, 강의 제목 정리 492건 반영에 오탐 0건. 그리고 거의 모든 작업 단위의 말미에 "타입 검사 0 에러 · 린트 0 에러 · 전 페이지 200 응답"이라는 3종 루틴 검사를 돌렸습니다 — 사람으로 치면 매번 같은 건강검진을 받는 셈입니다.
원인분석 → 개선 → 재측정의 실례: 연결률 사이클
2회차 사례로 소개했던 연결률 개선을 3회차의 프레임으로 다시 보면 완벽한 개선 사이클입니다.
| 단계 | 실제 활동 |
|---|---|
| 현수준 측정 | 자동 연결률 33% (756건 중 185건) |
| 원인분석 | 미연결 건을 조사 → 최대 유형은 고객사 명칭 불일치(별칭·축약형) |
| 개선 아이디어 | 별칭 사전("한화인경원 ↔ 한화인재경영원" 등) + 매칭 규칙 v2 |
| 적용 · 재측정 | 연결률 89% (555건 중 493건) |
| 2차 개선 | 고객사 명칭 자체를 통합 정리 → 498건 연결, 잔여는 격리 후 사람 재배정 |
부하 시험도 이 시기의 하네스적 활동입니다 — 동시 50건의 캘린더 요청, 80건의 정산 요청을 자동 투입해 에러 0건을 확인했습니다. 손으로는 못 하는 시험을 스크립트가 하는 것, 그것이 하네스입니다.
3회차 자가 점검
- 시드 고정 테스트 데이터 생성 스크립트가 있고, 대량 인풋 → 아웃풋 측정이 자동으로 돈다.
- 품질 지표 2~4개가 정의서(정의·산식·측정 데이터·현수준·목표)로 확정되었다.
- 실패 건을 유형별로 분류한 원인분석이 있다.
- 개선안을 적용하고 재측정한 Before/After 비교표가 최소 1건 있다.
3회차 산출물 (md / html)
- 테스트 하네스 — 데이터 생성 + 투입·채점 스크립트, 실행 방법 문서
- 품질 지표 정의서 — 지표·산식·현수준·목표
- 측정·개선 리포트 — 원인분석, 개선안, Before/After 효과
4회차 — 자동화 로직 고도화와 인접 시스템 연계
- 자동화 로직을 고도화해 사람 개입 구간을 더 줄일 수 있다.
- 인접 시스템(메일·알림·스토리지·사내 시스템)으로의 확장·연계를 설계하고 개발할 수 있다.
- 연계 개발에서 반드시 점검할 항목(인증·실패 처리·데이터 계약)을 안다.
3회차까지의 시스템은 "정의한 범위를 잘 해내는 시스템"입니다. 4회차는 그 범위를 두 방향으로 넓힙니다. 안으로는 자동화 로직의 고도화 — 아직 사람이 하고 있는 판단·처리를 더 흡수하고, 밖으로는 인접 시스템으로의 확장·연계 — 우리 시스템의 앞뒤에 있는 도구들과 데이터를 주고받게 만듭니다. 1회차에 적어 둔 "만들지 않을 것" 목록을 다시 꺼낼 시점이 바로 지금입니다.
자동화 로직의 고도화
고도화의 재료는 3회차의 원인분석에서 나옵니다. "사람 확인으로 보냈던 것들"과 "규칙으로 못 잡았던 예외들"의 목록을 보고, 이번엔 어디까지 자동화할지 정합니다.
| 고도화 방향 | 내용 | 예시 |
|---|---|---|
| 규칙의 확장 | 수집된 예외 케이스를 규칙에 편입 — 예외가 정규 케이스가 됨 | 별칭 사전 확대, 형식 변형 자동 보정 |
| 연쇄 자동화 | 사람이 잇던 단계 사이를 프로그램이 직접 연결 | 강의 등록 → 정산 지급행 자동 생성 |
| AI 판단 단계 추가 | 규칙으로 못 쓰는 판단에 LLM을 투입하되, 후보 + 근거 + 확신도를 제시하고 확정은 사람이 | 교열 후보 검출, 유사 사례 추천, 분류 제안 |
| 확인 지점의 재배치 | 사람 확인을 없애는 게 아니라 가장 값어치 있는 지점으로 옮김 | 건별 확인 → 예외 건만 확인 + 일괄 승인 |
인접 시스템으로의 확장과 연계 개발
우리 시스템의 업스트림(데이터가 들어오는 쪽)과 다운스트림(결과가 나가는 쪽)을 그려 보면 연계 후보가 보입니다. 자주 나오는 연계 유형은 다음과 같습니다.
OUT알림 · 메일 발송
산출물(발주서·보고서·견적서)을 시스템 밖의 사람에게 전달 — 이메일 발송, 사내 메신저 알림. "만들어 두면 사람이 퍼 나르던" 마지막 구간의 자동화입니다.
IN/OUT파일 스토리지
첨부파일·증빙·이미지를 개인 PC가 아닌 공용 스토리지에 저장하고 시스템에서 링크로 관리합니다.
IN사내 시스템 데이터
ERP·그룹웨어·기간계에서 데이터를 받아옵니다. API가 없으면 정기 내보내기 파일 업로드부터 시작해도 됩니다 — 연계의 시작은 형식 합의입니다.
OUT타 과제·타 시스템
우리 아웃풋이 다른 과제의 인풋이 되는 경우입니다. 이번 프로젝트의 과제들처럼 연말에 통합될 시스템이 있다면, 지금부터 데이터 형식을 맞춰 두는 것이 연계 개발입니다.
연계는 기능보다 계약이 먼저입니다. 개발 전에 아래 세 가지를 점검표로 확정하십시오.
| 점검 항목 | 확정할 것 |
|---|---|
| 인증 · 권한 | 상대 시스템에 무엇으로 접속하는가(계정·키·IP 제한). 키를 코드에 하드코딩하지 않고 환경변수로 관리하는가 |
| 실패 처리 | 상대가 응답하지 않으면? — 재시도 횟수, 실패 시 알림, 실패 건의 격리·재처리 경로를 정의합니다. 연계는 반드시 실패합니다. 실패해도 무너지지 않게 설계합니다 |
| 데이터 계약 | 주고받는 데이터의 항목·형식·인코딩을 문서로 고정(스키마). 상대편 담당자와 합의된 문서가 있는가 |
사례로 보기 — RNBD의 고도화와 연계
연쇄 자동화 — 강의를 등록하면 정산이 따라온다
고도화의 대표 사례는 강의 → 지급행 자동 동기화입니다. 외부강사의 강의를 등록하면 정산 지급행이 자동 생성되고, 원천징수(소득세·지방세·실지급액)가 자동 계산됩니다. 사람이 하던 "강의 끝나면 지급대장에 행 추가하고 수식 끌기"라는 연결 작업 자체가 사라졌습니다. 단, 과거 데이터를 건드리지 않도록 자동 동기화 컷오프 날짜를 두는 안전장치를 함께 설계했습니다.
다운스트림 연계 — 견적서가 시스템 밖으로 나가는 길
견적서 기능은 연계의 묶음입니다. 화면에서 견적서를 만들면 PDF로 생성되고, SMTP 이메일로 고객사에 직접 발송되며(발송 이력 저장), 계약이 성사되면 "프로젝트로 반영" 클릭 한 번으로 프로젝트가 등록됩니다. 계산서에는 '발행요청' 상태와 담당자 알림 설정이 붙어, 회계 처리 담당에게 가는 전달도 시스템 안으로 들어왔습니다.
스토리지 연계와 운영 연계
고객사 사업자등록증 265건은 만료된 외부 URL에서 전량 다시 내려받아 Supabase Storage(비공개 버킷)로 옮기고, 시스템에서는 서명된 임시 URL로만 열람하게 했습니다. 운영 환경과 로컬 환경 사이에는 데이터 동기화 스크립트(diff → pull/push)를 만들되, --force 옵션 없이는 미리보기만 되는 안전장치를 달았습니다 — 연계 지점마다 "실패하거나 실수해도 무너지지 않게"라는 원칙이 반복됩니다.
4회차 자가 점검
- 3회차 원인분석에서 나온 "사람이 하던 판단·처리" 중 자동화로 흡수할 것을 정해 구현했다.
- 고도화 후 하네스를 재실행해 품질 지표가 유지·개선됨을 확인했다.
- 업스트림/다운스트림 연계 대상을 정하고 최소 1개의 연계를 개발했다.
- 연계 지점마다 인증·실패 처리·데이터 계약이 문서로 정리되어 있다.
4회차 산출물 (md / html)
- 고도화 내역서 — 무엇을 더 자동화했고, 지표에 어떤 영향이 있었는지
- 연계 설계서 — 연계 대상, 데이터 계약, 실패 처리 방식
- 고도화·연계가 반영된 코드 + 갱신된 README.md
5회차 — 전체 시스템 안정화, 실사용 테스트, 오픈베타
- 인증·권한·에러 처리·백업 관점에서 시스템을 안정화할 수 있다.
- 실제 사용자를 투입한 실사용 테스트를 설계하고 피드백을 수집·처리할 수 있다.
- 오픈베타 서비스를 시작하고, 기존 방식과의 병행·전환 계획을 세울 수 있다.
지금까지는 만든 사람이 쓰는 시스템이었습니다. 5회차의 질문은 "만들지 않은 사람에게 맡겨도 되는가"입니다. 그러려면 시스템이 낯선 사용자의 실수와 예상 밖의 입력에도 버텨야 하고(안정화), 실제 사용자가 써 본 피드백이 반영돼야 하며(실사용 테스트), 정식 오픈 전의 완충 구간(오픈베타)이 필요합니다.
전체 시스템 안정화
안정화 점검은 네 영역입니다. 각 영역을 AI에게 점검시키고, 결과를 확인하고, 고치게 하십시오.
| 영역 | 점검 내용 | 확인 방법 |
|---|---|---|
| 인증 · 권한 | 로그인 없이 접근되는 화면·기능이 없는가. 화면만 막고 서버 기능(API·서버 액션)은 열려 있는 "뒷문"이 없는가. 관리자 기능이 일반 사용자에게 열려 있지 않은가 | 비로그인·일반권한으로 전 기능 호출 시험 |
| 에러 처리 | 잘못된 입력·빈 파일·중복 제출에 시스템이 알아들을 수 있는 메시지로 응답하는가, 아니면 그냥 죽는가 | 일부러 틀린 입력 투입 |
| 데이터 보호 | 백업이 자동으로 되는가, 복원을 해 봤는가. 삭제는 복구 가능하거나 확인을 거치는가 | 백업 → 복원 리허설 1회 |
| 성능 | 실사용 규모의 데이터·동시 사용자에서 버티는가 | 3회차 하네스로 부하 시험 |
실사용 테스트와 오픈베타
학습 안내운영 수행. 소수 사용자 실사용 → 피드백 반영 → 대상 확대(오픈베타)의 2단계로 진행합니다. 완료 기준: 팀 밖의 사용자가 실제 업무 1건을 시스템으로 처리했는가.
① 실사용 테스트(클로즈드). 팀 밖의 실제 사용자 2~5명에게 진짜 업무 1~2건을 시스템으로 처리하게 합니다. 관찰 포인트는 "어디서 멈칫하는가"입니다. 피드백은 접수 채널을 하나로 정하고(메신저 방·시트·게시판), 이슈 로그(번호·내용·심각도·상태)로 관리합니다.
② 오픈베타. 치명 이슈가 잡히면 대상을 전체 사용자로 넓힙니다. 이때 결정해야 할 것이 병행 운영 계획입니다 — 기존 방식(엑셀·수작업)과 새 시스템을 언제까지 병행하고, 언제부터 새 시스템을 유일한 원본(single source of truth)으로 삼을지. 전환일을 정하지 않으면 이중 입력이 영원히 계속됩니다.
사례로 보기 — RNBD의 안정화와 오픈
뒷문 46개 — 안정화의 실제 모습
로그인 기능을 붙이는 과정에서 화면 접근은 막았지만 서버 기능 46개가 인증 없이 직접 호출 가능한 "뒷문"으로 남아 있음이 발견됐습니다. 팀은 46개 전부에 인증 가드를 일괄 삽입하고, 비로그인 차단·관리자 구분·위조 쿠키 차단을 10가지 시나리오 전부 통과(10/10)로 검증했습니다. 로그인은 가입 승인제(가입 신청 → 관리자 승인)로 설계해 사내 시스템다운 통제를 갖췄습니다.
DB 전환 검증과 부하 시험
개발용 경량 DB(SQLite)에서 운영용 PostgreSQL(Supabase)로 옮기며 1,382행 전량을 이전하고, 테이블별 건수 일치·계약총액 합계 일치·시간대(KST) 보존까지 대조해 확인했습니다. 부하 시험(동시 50·80 요청, 에러 0)도 이 단계의 관문이었습니다.
배포의 시행착오 — 갈아타는 것도 능력
첫 배포 대상이었던 호스팅(Cloudflare)에서는 빌드 실패가 반복되어 이틀을 소모했습니다. 팀은 매몰비용에 붙들리지 않고 Vercel로 전환해 한 번에 성공했고, 이 시행착오 전체를 결정 로그(D46)에 남겼습니다. 안정화 단계에서 도구·인프라 문제로 막히면, 뚫는 것과 갈아타는 것을 저울질하십시오 — 시행착오도 기록하면 자산입니다.
5회차 자가 점검
- 인증·권한을 점검했고, 화면 뒤의 서버 기능(뒷문)까지 막혀 있음을 시험으로 확인했다.
- 일부러 틀린 입력을 넣어도 시스템이 죽지 않고 안내 메시지를 준다.
- 백업·복원을 1회 리허설했다.
- 팀 밖 사용자가 실제 업무를 처리했고, 이슈 로그가 관리되고 있다.
- 오픈베타를 시작했고, 기존 방식과의 병행 기간·전환일이 정해져 있다.
5회차 산출물 (md / html)
- 안정화 점검 보고 — 인증·에러·백업·성능 점검 결과와 조치
- 실사용 테스트 이슈 로그 — 접수·심각도·처리 상태
- 오픈베타 공지문과 병행·전환 계획 — 전환일 명시
6회차 — 완성, 효과 정량화, 그리고 최종 발표
- 최종 코드를 완성하고, 활용 효과를 정량화된 숫자로 평가할 수 있다.
- 개발 히스토리와 시스템 문서(README·설계·운영)를 완성할 수 있다.
- Lessons Learned를 조직 자산 형태로 정리하고, 최종 발표를 구성할 수 있다.
마지막 회차는 새 기능을 만드는 회차가 아니라 마무리하고, 증명하고, 물려주는 회차입니다. 여섯 가지 활동 — ① 최종 코드 완성 ② 활용 효과 평가·정량화 ③ 개발 히스토리 정리 ④ 최종 자동화 시스템 문서화 ⑤ Lessons Learned ⑥ 최종 발표 — 을 순서대로 진행합니다.
최종 코드 완성과 효과 정량화
학습 안내마감 작업. 이슈 로그의 잔여 건을 처리(수정 또는 "알려진 한계"로 명시)하고, 효과를 산식과 함께 숫자로 만듭니다. 완료 기준: 효과 평가표의 모든 숫자에 산식과 근거가 붙어 있는가.
최종 코드 완성은 "이슈 0"이 아니라 "남은 이슈가 무엇인지 아는 상태"입니다. 베타 이슈 로그에서 고칠 것은 고치고, 이번 범위 밖의 것은 "알려진 한계"로 README에 명시합니다. 마지막으로 하네스와 안정화 점검을 한 번씩 다시 돌려 최종 상태를 확정합니다.
효과 정량화는 산식이 생명입니다. 인상이 아니라 계산으로 말하십시오.
| 효과 유형 | 산식 예 | 근거 데이터 |
|---|---|---|
| 시간 절감 | (기존 건당 시간 − 현재 건당 시간) × 월 건수 × 인원 | Before/After 실측, 처리 건수 로그 |
| 품질 개선 | 지표 변화 — 오류율·누락률·재작업률의 Before → After | 3회차 지표 정의서와 최종 측정값 |
| 비용 절감 | 외주·인력 비용의 감소분 | 기존 외주 단가 × 대체된 물량 |
| 새로 보이게 된 것 | 기존 방식에서는 아무도 계산하지 못하던 숫자가 상시 가시화됨 | 대시보드 캡처, 발견 사례 |
기준선은 1회차 기획서에 적었던 목표와 대조합니다 — "작성 시간 70% 단축", "분석 3~4주 → 3~5일" 같은 목표 수치를 세웠던 과제라면, 달성 여부를 정면으로 보고하십시오. 미달이어도 원인과 함께 보고하는 것이 신뢰를 만듭니다.
히스토리 정리, 문서화, Lessons Learned
학습 안내작성. 결정 로그를 원료로 히스토리와 문서 4종을 완성합니다. 완료 기준: 이 문서들만 읽고 다른 사람이 시스템을 실행·운영할 수 있는가.
개발 히스토리는 2회차부터 쌓아 온 결정 로그(D번호)를 시간순으로 훑으며 "무엇을 왜 그렇게 결정했는지"의 흐름으로 정리합니다. 처음부터 쓰려면 큰일이지만, 로그가 있다면 반나절 작업입니다. 시스템 문서는 네 벌이 표준입니다.
| 문서 | 내용 | 독자 |
|---|---|---|
| README.md | 시스템 소개, 설치·실행 방법, 알려진 한계 | 다음 개발자·인수자 |
| 설계 문서(DESIGN.md) | 데이터 구조, 핵심 원칙, 집계·계산 규칙 | 다음 개발자, 미래의 나 |
| 운영 가이드 | 백업·복원, 계정 관리, 장애 시 대응 | 운영 담당 |
| 사용자 안내 | 화면별 사용법 — 짧게, 그림 위주로 | 일반 사용자 |
Lessons Learned는 "소감문"이 아니라 다음 과제가 재사용할 수 있는 형태로 만듭니다. 세 가지 형식을 권장합니다.
1잘된 결정 / 다시 한다면
결정 로그에서 "효과가 컸던 결정"과 "다시 한다면 다르게 할 결정"을 각각 3~5개씩 뽑아 이유와 함께 적습니다.
2프롬프트 패턴집
이번 개발에서 반복적으로 효과를 낸 프롬프트(검증 요구, 불편 묘사, 비교 후 추천 등)를 패턴 이름과 예문으로 정리합니다.
3함정 사전
실제로 빠졌던 함정("거의 같은 계산", "다 됐습니다 믿기", 구조 결정 미루기)과 회피법을 목록으로 만듭니다. 다음 조가 같은 곳에서 넘어지지 않게.
최종 발표 — 6회차의 스토리를 15분에
학습 안내구성 후 리허설. 아래 6부 구성으로 발표를 만들고, 시연은 반드시 사전 리허설합니다. 완료 기준: 시연 시나리오가 이번 주에 실제로 돌려 본 경로인가.
유일한 발표입니다. 6회 동안의 산출물이 곧 발표 재료이므로 새로 만들 것은 거의 없습니다 — 모으고 편집하는 일입니다.
| 순서 | 내용 | 재료가 되는 산출물 |
|---|---|---|
| 1 | 문제와 범위 — 무엇을 왜 자동화했나 | 1회차 문제 정의문 · SIPOC |
| 2 | Before / After — 프로세스가 어떻게 바뀌었나 | 1회차 휴먼/프로그램 프로세스 대비표 |
| 3 | 시연 — 실제로 돌아가는 모습 | 오픈베타 중인 시스템 (대표 사이클 1개) |
| 4 | 품질 — 지표와 개선의 스토리 | 3회차 지표 정의서 · Before/After 측정 |
| 5 | 효과 — 정량화된 숫자 | 6회차 효과 평가표 (산식 포함) |
| 6 | Lessons Learned — 물려줄 것 | 프롬프트 패턴집 · 함정 사전 |
사례로 보기 — RNBD의 마무리와 자산화
기록이 문서가 되고, 문서가 교재가 되다
RNBD의 마무리 단계 산출물은 개발 중에 쌓인 기록에서 그대로 나왔습니다. 결정 로그 D1~D46(DEV-LOG.md)이 개발 히스토리가 되었고, 데이터 구조와 핵심 원칙 3가지를 담은 DESIGN.md, AI 작업 규칙을 담은 AGENTS.md(로컬 우선, 운영 반영은 매번 허락, 동기화는 스크립트로만), 실행 방법을 담은 README.md가 문서 체계를 이뤘습니다. 나아가 이 기록 전체가 프롬프트 패턴 사전 8종·함정 사전 8종을 부록으로 갖춘 교육용 교재 한 권으로 재구성되었습니다 — Lessons Learned의 극단적 완성형입니다.
효과의 백미 — 아무도 몰랐던 숫자가 보인다
RNBD 효과 평가에서 가장 힘 있는 항목은 시간 절감이 아니었습니다. 대시보드의 "미청구 금액 = 계약총액 − 발행완료 계산서 합계" — 시트와 엑셀 시절에는 아무도 계산하지 않아서 어디서 돈이 새는지 몰랐던 숫자가, 시스템에서는 항상 화면에 떠 있습니다. 이중 입력 소멸, 수작업 집계 소멸과 함께 "기존 방식에서는 보이지 않던 것이 보이게 된 것"이 정량 효과의 축이 되었습니다. 여러분의 효과 평가에서도 이 항목을 찾아보십시오 — 거의 모든 과제에 하나씩은 있습니다.
6회차 자가 점검
- 잔여 이슈가 처리되었거나 "알려진 한계"로 문서에 명시되었다.
- 효과 평가표의 모든 숫자에 산식과 근거 데이터가 붙어 있고, 1회차 목표와 대조했다.
- 개발 히스토리(결정 로그 기반)와 문서 4종(README·설계·운영·사용자)이 완성되었다.
- Lessons Learned가 재사용 가능한 형태(잘된 결정·프롬프트 패턴·함정 사전)로 정리되었다.
- 최종 발표를 6부 구성으로 만들었고, 시연 경로를 리허설했다.
6회차 산출물 (md / html)
- 최종 코드 + 최종 README.md — 알려진 한계 포함
- 활용 효과 평가서 — 산식·근거 포함 정량화
- 개발 히스토리 — 결정 로그 기반
- 시스템 문서 — 설계 문서 · 운영 가이드 · 사용자 안내
- Lessons Learned — 프롬프트 패턴집 · 함정 사전 포함
- 최종 발표 자료
부록 — 회차별 산출물 총괄표
6회차 동안 제출할 산출물의 전체 목록입니다. 모든 문서는 md 또는 html이 기본이고, 코드 산출물에는 항상 README가 따라갑니다. 회차가 끝날 때마다 이 표에서 자기 조의 진도를 확인하십시오.
| 시점 | 산출물 | 비고 |
|---|---|---|
| 착수 전 | 기존 기획서·개발 코드의 README.md | 진행분이 있는 과제 — 제출 권장 |
| 1회차 | 개발계획서.md (SIPOC · 프로세스 플로우차트 · 데이터 템플릿 · 테이블 정의서 · 화면/저장 기획) / ver1.0 코드 + README | 이후 모든 회차의 기준 문서 |
| 2회차 | 기능 확인 결과표 / 데이터 검증 보고(전수 대조) / 결정 로그 시작 / 기능 완성 코드 | 기능 목록 100% 구현 |
| 3회차 | 테스트 하네스 / 품질 지표 정의서 / 측정·개선 리포트(Before/After) | 하네스는 이후 회차에서 재사용 |
| 4회차 | 고도화 내역서 / 연계 설계서(데이터 계약·실패 처리) / 고도화·연계 코드 | 변경마다 하네스 재실행 |
| 5회차 | 안정화 점검 보고 / 실사용 이슈 로그 / 오픈베타 공지·전환 계획 | 전환일 명시 |
| 6회차 | 최종 코드 / 효과 평가서 / 개발 히스토리 / 시스템 문서 4종 / Lessons Learned / 최종 발표 | 발표는 6회차 1회뿐 |
매 회차 공통 — 컨설팅 데이 전 체크
- 지난 회차 산출물이 md/html로 정리되어 공유 가능한 상태다.
- 회차 사이에 한 작업이 결정 로그에 기록되어 있다.
- 막힌 곳·질문을 구체적인 문장으로 준비했다 ("안 돼요"가 아니라 "무엇을 했더니 무엇이 됐다").
- 시스템이 컨설팅 자리에서 바로 시연 가능한 상태다.