AX 프로젝트 컨설팅 프로세스
10회차 진행 사례

학습 안내1회차 전에 완료. 아래 두 가지를 준비해서 1회차 컨설팅에 가져오면, 첫 회차부터 곧바로 본론(과제 정의)으로 들어갈 수 있습니다.

① 이미 진행한 것이 있다면 — OVERVIEW.md를 먼저 제출

컨설팅 착수 전에 과제별로 미리 작성한 기획서나 일부 개발한 코드가 있다면, 그 내용을 요약한 OVERVIEW.md 파일(md)을 미리 제출해 주십시오. 시범 운영 중인 챗봇, 부서에서 이미 쓰고 있는 자동화 도구처럼 움직이는 것이 있는 과제라면 특히 그렇습니다. 컨설턴트가 사전에 읽고 오면 1회차의 밀도가 완전히 달라집니다.

② 산출물 형식 규칙 — md 또는 html

이번 프로젝트에서 제출하는 모든 문서 산출물은 마크다운(.md) 또는 HTML(.html) 파일을 기본으로 합니다. 이유는 단순합니다.

학습 안내작성. SIPOC의 I와 O를 데이터 명세 수준까지 구체화합니다. 완료 기준: 인풋마다 항목 명세표가 있고, 실물 샘플 파일을 확보했는가.

1회차에서 인풋·아웃풋 데이터를 정의하고, 구체적인 데이터 템플릿까지 정합니다. "발주 정보를 입력받는다" 수준으로는 개발을 시작할 수 없습니다. 항목 하나하나를 아래 명세표 양식으로 확정하십시오.

템플릿을 정의할 때의 원칙 세 가지입니다.

학습 안내작성. 저장 계획(백엔드)과 화면 계획(프론트엔드)을 각각 표로 만듭니다. 완료 기준: 두 표만 보고 무엇을 저장하고 어떤 화면을 만들지 남이 이해할 수 있는가.

백엔드 기획 — 어떤 데이터를 저장할 것인가

화면 뒤에서 데이터를 저장하고 처리하는 부분이 백엔드입니다. 기획 단계에서 답할 질문은 하나입니다: "무엇을 저장할 것인가." 아래 질문에 하나씩 답하면 저장 계획이 됩니다.

테이블과 필드를 정의한다 — 인풋과 결과가 담길 그릇

저장할 데이터가 정해지면 그것을 담을 테이블을 정의합니다. 테이블은 한 종류의 데이터를 담는 표입니다 — 한 행이 데이터 1건, 각 필드(열)가 항목 하나입니다. 인풋으로 들어온 것을 담는 테이블과 프로세싱된 결과를 담는 테이블을 구분해서, 테이블마다 아래 양식(테이블 정의서)을 채웁니다.

핵심은 연결 필드입니다. 관계형 DB에서 테이블끼리는 고유번호(id) 필드로 연결됩니다 — 발주서 테이블에 업체의 "이름"이 아니라 업체 테이블의 id를 담는 식입니다. 이름은 바뀌고 중복될 수 있지만 id는 유일하기 때문입니다. 어떤 테이블의 어떤 필드가 어느 테이블을 가리키는지 정하는 것이 관계 정의이고, 관계의 종류는 네 가지뿐입니다.

프론트엔드 기획 — 어떤 화면에서 무엇을 하게 할 것인가

사용자들에게 어떤 화면을 보여주고 어떤 기능을 제공할지 화면 목록으로 정리합니다. 화면 하나당 한 행이면 충분합니다.

학습 안내작성. 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. 일정            — 10회차 로드맵에 맞춘 우리 조의 계획

학습 안내작성. 개발계획서의 화면·테이블·처리 목록을 "MVP에서 만들 것"과 "미룰 것"으로 나눠 범위표를 만듭니다. 완료 기준: 핵심 흐름 하나에 필요한 최소 조각만 "만들 것"에 남았는가.

선정한 핵심 흐름을 기준으로, 백엔드·프론트엔드 기획 전체를 두 칸으로 나눕니다. 흐름이 지나가는 조각만 만들고, 나머지는 전부 미룹니다.

미룬 것들은 사라지는 것이 아닙니다 — 4회차(추가 기능)와 5회차(고도화·연계)의 재료로 개발계획서에 그대로 남습니다. 범위표는 "안 만든다"가 아니라 "나중에 만든다"의 기록입니다.

학습 안내실행. 개발계획서와 MVP 범위표를 AI 코딩 도구에 주고 Plan 모드로 구현 계획을 받은 뒤, 검토·승인하고 집중 구현합니다. 완료 기준: 인풋을 넣으면 아웃풋이 나오는 핵심 사이클 하나가 동작하는가.

범위가 정해졌으면 바로 개발을 시작합니다. Claude Code 같은 AI 코딩 도구에는 Plan 모드가 있습니다 — 코드를 바로 고치지 않고, 먼저 구현 계획을 세워서 사람에게 승인받는 모드입니다. 개발계획서와 범위표를 주고 Plan 모드로 시작하면, AI가 "이런 순서로 이렇게 만들겠다"는 계획을 내놓습니다. 계획을 읽고, 이상한 부분을 바로잡고, 승인하면 코딩이 시작됩니다.

MVP의 기준은 완성도가 아니라 관통입니다. 화면이 투박해도, 예외 처리가 없어도 됩니다. 대표 인풋 하나를 넣었을 때 프로세스를 통과해 아웃풋이 나오는 것 — 그 한 사이클이 돌면 MVP입니다. 골격이 관통되면 남은 여덟 회차는 이 골격에 살을 붙이는 일입니다.

학습 안내실험 수행. 대표 인풋 5~10건을 MVP에 투입하고 아웃풋을 눈으로 확인해 가능성을 판정합니다. 완료 기준: 판정(가능 / 조건부 가능 / 재설계 필요)과 근거가 기록되었는가.

MVP가 돌았다고 끝이 아닙니다 — MVP는 실험 장치입니다. 실물 데이터에서 뽑은 대표 인풋(전형적인 케이스 3~5건 + 일부러 고른 어려운 케이스 2~5건)을 넣고, 아웃풋을 기존 방식의 결과와 나란히 놓고 비교하십시오. 실험의 결론은 셋 중 하나입니다.

"재설계 필요"가 나와도 실패가 아닙니다 — 2회차에 아는 것과 8회차에 아는 것의 비용은 수십 배 차이입니다. 이 조기 발견이 MVP를 만드는 진짜 이유입니다.

학습 안내사이클 수행. 현수준 측정에서 나온 실패 건들을 원료로 개선 사이클을 최소 1회 완주합니다. 완료 기준: Before/After 지표 비교표가 있는가.

① 원인분석. 실패한 건들을 전부 모아 오류 유형별로 분류합니다. "명칭 불일치 41건, 날짜 형식 오류 17건, 빈 필드 9건…"처럼 세어 보면 대개 상위 2~3개 유형이 실패의 대부분을 차지합니다(파레토). 거기부터 공략합니다.

② 개선 아이디어 도출. 유형별로 "규칙 추가로 잡을 수 있는 것 / 입력 단계에서 막을 수 있는 것 / 사람 확인으로 보낼 것"을 나눠 개선안을 만듭니다. AI에게 실패 건들을 주고 "이 실패들의 공통 패턴과 개선안을 제안해"라고 묻는 것도 효과적입니다.

③ 적용과 효과 평가. 개선안을 한 번에 하나씩 적용하고, 같은 시드의 하네스를 다시 돌려 지표를 재측정합니다. 한꺼번에 여러 개를 바꾸면 무엇이 효과를 냈는지 알 수 없게 됩니다.

| 개선안 | 대상 오류 유형 | Before | After | 판정 |
|--------|--------------|--------|-------|------|
| 고객사 별칭 사전 추가 | 명칭 불일치 | 87% | 94% | 채택 |
| 날짜 파서 형식 3종 추가 | 날짜 형식 오류 | 94% | 96% | 채택 |

학습 안내반복 수행. 아래 루프를 기능 목록의 전 항목이 "완료"가 될 때까지 돌립니다. 완료 기준: 기능 목록표의 모든 행이 세 가지 확인(동작/정확/사용성)을 통과했는가.

이 루프를 돌리다 보면 데이터 구조를 바꿔야 하는 큰 결정을 만나기도 합니다. 미루고 싶어지지만 — 구조 결정을 미루면 이자가 붙습니다. 코드가 쌓일수록 같은 변경의 비용이 커지므로, 구조 문제는 발견한 회차에 해결하는 것이 원칙입니다.

학습 안내실행. 개발용 DB를 운영용 DB로 전환하고, 서버 기능을 운영 환경에 올립니다. 완료 기준: 운영 DB에 실데이터가 전량 이관·검증되었고, 서버 기능이 운영 환경에서 응답하는가.

백엔드 배포의 중심은 DB 전환입니다. 개발 중에는 가벼운 개발용 DB(예: SQLite — 파일 하나짜리 DB)로 충분하지만, 여러 명이 동시에 쓰는 운영에는 운영용 DB(예: PostgreSQL)가 필요합니다. 전환은 곧 이관이고, 이관은 검증과 한 몸입니다 — 테이블별 건수 일치, 금액 합계 일치, 날짜·시간대 보존까지 대조해야 이관이 끝난 것입니다(2회차 이후 몸에 익은 전수 대조 그대로).

또 하나가 환경변수입니다. DB 접속 주소, API 키, 메일 계정 같은 민감 정보는 코드에 적지 않고 환경변수로 분리합니다. 그래야 같은 코드가 로컬에서는 개발 DB를, 운영에서는 운영 DB를 바라보고 — 키가 코드 저장소에 노출되는 사고도 막을 수 있습니다.

학습 안내실행. 화면을 호스팅에 올리고, 운영 백엔드와 연결합니다. 완료 기준: 운영 URL에서 전 화면이 열리고, 화면의 데이터가 운영 DB에서 나오고, 쓰기가 저장되는가.

프론트엔드 배포는 화면 코드를 호스팅에 올려 URL을 받는 일입니다. Next.js처럼 프론트엔드와 백엔드가 한 몸인 구성이면 한 번의 배포로 함께 올라가고, 분리된 구성이면 프론트엔드가 바라볼 백엔드 주소를 환경변수로 지정해 연결합니다. 연결 확인은 세 줄이면 됩니다.

학습 안내실행 · 점검. 로그인을 붙이고, 화면(정문)과 서버 기능(뒷문)이 모두 막혔는지 시험합니다. 완료 기준: 비로그인·일반권한으로 전 기능 호출 시험을 통과했는가.

배포된 순간부터 시스템은 "아무나 접속을 시도할 수 있는 곳"에 놓입니다. 점검할 것은 세 가지입니다 — 로그인 없이 접근되는 화면·기능이 없는가, 화면만 막고 서버 기능(API·서버 액션)은 열려 있는 "뒷문"이 없는가, 관리자 기능이 일반 사용자에게 열려 있지 않은가. 확인 방법은 하나뿐입니다: 비로그인·일반권한 상태로 전 기능을 직접 호출해 보는 것.

사내 시스템이라면 가입 방식도 결정합니다 — 아무나 가입할 수 있게 둘 것인가, 가입 신청 → 관리자 승인제로 통제할 것인가. 사내 시스템은 승인제가 기본값입니다.

학습 안내작성 · 게시. 결정 로그와 코드를 원료로 문서 4종을 만들고, 사용자가 찾을 수 있는 곳에 게시합니다. 완료 기준: 이 문서들만 읽고 다른 사람이 시스템을 사용·운영할 수 있는가.

시스템 문서는 네 벌이 표준입니다. 독자가 다르므로 한 문서로 합치지 않습니다.

사용자 매뉴얼의 요령은 세 가지입니다. 짧게, 화면 캡처 위주로, 그리고 기능 나열("이 버튼은 ~입니다")이 아니라 업무 시나리오 단위("발주 1건을 등록하려면")로 쓰십시오. AI에게 화면별 사용법 초안을 쓰게 하고, 사람이 실제 화면과 대조하며 다듬는 순서가 빠릅니다.

문서도 배포가 필요합니다. 시스템 안의 도움말 링크, 부서 공유 폴더, 사내 게시판 — 사용자가 실제로 찾을 위치에 게시하십시오. 만든 문서가 작성자 PC에만 있으면 없는 것과 같습니다.

학습 안내운영 수행. 소수 사용자 실사용 → 피드백 반영 → 대상 확대(오픈베타)의 2단계로 진행합니다. 완료 기준: 팀 밖의 사용자가 실제 업무 1건을 시스템으로 처리했는가.

① 실사용 테스트(클로즈드). 팀 밖의 실제 사용자 2~5명에게 진짜 업무 1~2건을 시스템으로 처리하게 합니다. 관찰 포인트는 "어디서 멈칫하는가"입니다. 피드백은 접수 채널을 하나로 정하고(메신저 방·시트·게시판), 이슈 로그(번호·내용·심각도·상태)로 관리합니다.

② 오픈베타. 치명 이슈가 잡히면 대상을 부서 또는 사내 전체로 넓힙니다. 이때 결정해야 할 것이 병행 운영 계획입니다 — 기존 방식(엑셀·수작업)과 새 시스템을 언제까지 병행하고, 언제부터 새 시스템을 유일한 원본(single source of truth)으로 삼을지. 전환일을 정하지 않으면 이중 입력이 영원히 계속됩니다.

학습 안내주간 리듬 수행. 주 1회 실사용 데이터를 열어 분석 → 디버깅 → 개선 → 하네스 재실행의 리듬을 돌립니다. 완료 기준: 실사용 데이터에서 발견해 고친 개선이 최소 1건 있는가.

분석의 질문은 세 가지입니다. ① 에러 — 가장 자주 실패하는 기능은 무엇인가? 에러 로그를 유형별로 분류합니다(3회차 원인분석과 같은 요령 — 상위 2~3개 유형이 대부분을 차지합니다). ② 마찰 — 시작했다가 끝내지 못한 작업, 유난히 오래 걸리는 화면은 어디인가? ③ 외면 — 만들었는데 아무도 안 쓰는 기능은 무엇인가? 홍보가 안 된 것인지, 필요 없는 기능이었는지를 사용자에게 물어 확인합니다.

디버깅은 재현에서 시작합니다. 에러 로그의 입력을 그대로 개발 환경에 재현 → 원인 수정 → 하네스 재실행(기존 품질 유지 확인) → 운영 반영. 그리고 실사용에서 나온 새 예외 케이스는 테스트 데이터에 편입하십시오 — 하네스가 실사용을 닮아 갈수록 강해집니다.

학습 안내운영. 이슈 로그와 실사용 데이터 발견을 하나의 백로그로 합치고 우선순위를 매깁니다. 완료 기준: 백로그의 모든 항목에 출처·빈도·심각도가 붙어 있는가.

이슈 로그(피드백)와 실사용 데이터의 발견(에러·마찰·외면)을 하나의 개선 백로그로 합치고, 항목마다 두 숫자를 붙입니다 — 빈도(얼마나 자주 일어나는가) × 심각도(업무에 얼마나 치명적인가). 목소리 큰 요청이 아니라 이 곱이 순서를 정합니다. 상위 2~3개 항목이 불편의 대부분을 차지하는 파레토는 여기서도 반복됩니다 — 3회차 원인분석과 같은 프레임입니다.

| 항목 | 출처(로그/이슈) | 빈도 | 심각도 | 우선순위 | 상태 |
|------|---------------|------|--------|---------|------|
| 정산 화면 저장 실패 | 에러 로그 주 14건 | 상 | 상 | 1 | 수정 중 |
| 검색 결과 느림 | 사용 로그 (평균 8초) | 상 | 중 | 2 | 대기 |
| 새 통계 화면 요청 | 이슈 #12 | 하 | 하 | 보류 | 기록만 |

개선 요청에는 "새 기능"도 섞여 들어옵니다. 범위 관리는 1회차의 원칙 그대로 — 지금 고칠 것(결함·마찰), 다음에 만들 것(기능 확장), 만들지 않을 것을 구분해 기록합니다. 백로그는 거절의 기록이기도 합니다.

학습 안내반복 수행. 백로그 상위 항목부터 개선 사이클을 돌리고, 핵심 지표를 주 단위로 재측정합니다. 완료 기준: 지표의 주 단위 추세 기록이 쌓이고 있는가.

개선 한 건의 리듬은 이미 몸에 익은 그대로입니다 — 원인분석 → 수정 → 하네스 재실행(기존 품질 유지 확인) → 운영 반영 → 실사용 데이터로 효과 확인. 여기에 하나를 더합니다: 지표의 추세 기록. 3회차 지표 정의서의 지표들을 주 단위로 다시 재서, 개선이 누적되는 모습을 시계열로 남기십시오. 이 추세가 10회차 효과 정량화의 가장 힘 있는 증거가 됩니다.

학습 안내마감 작업. 이슈 로그의 잔여 건을 처리(수정 또는 "알려진 한계"로 명시)하고, 효과를 산식과 함께 숫자로 만듭니다. 완료 기준: 효과 평가표의 모든 숫자에 산식과 근거가 붙어 있는가.

최종 코드 완성은 "이슈 0"이 아니라 "남은 이슈가 무엇인지 아는 상태"입니다. 베타 이슈 로그에서 고칠 것은 고치고, 이번 범위 밖의 것은 "알려진 한계"로 OVERVIEW.md에 명시합니다. 마지막으로 하네스와 안정화 점검을 한 번씩 다시 돌려 최종 상태를 확정합니다.

효과 정량화는 산식이 생명입니다. 인상이 아니라 계산으로 말하십시오.

기준선은 1회차 기획서에 적었던 목표와 대조합니다 — "작성 시간 70% 단축", "분석 3~4주 → 3~5일" 같은 목표 수치를 세웠던 과제라면, 달성 여부를 정면으로 보고하십시오. 미달이어도 원인과 함께 보고하는 것이 신뢰를 만듭니다.

학습 안내작성. 결정 로그를 원료로 히스토리를 완성하고, 7회차에 만든 문서·매뉴얼을 개정합니다. 완료 기준: 문서의 내용이 오늘의 시스템과 일치하는가.

개발 히스토리는 2회차부터 쌓아 온 결정 로그(D번호)를 시간순으로 훑으며 "무엇을 왜 그렇게 결정했는지"의 흐름으로 정리합니다. 처음부터 쓰려면 큰일이지만, 로그가 있다면 반나절 작업입니다. 시스템 문서 4종(OVERVIEW.md·설계·운영·사용자 매뉴얼)은 7회차에 초판을 만들었습니다 — 10회차의 일은 revision입니다. 8·9회차의 실사용과 개선으로 시스템은 초판 문서와 달라져 있습니다. 아래 네 가지를 점검해 개정하십시오.

Lessons Learned는 "소감문"이 아니라 다음 과제가 재사용할 수 있는 형태로 만듭니다. 세 가지 형식을 권장합니다.

학습 안내구성 후 리허설. 아래 6부 구성으로 발표를 만들고, 시연은 반드시 사전 리허설합니다. 완료 기준: 시연 시나리오가 이번 주에 실제로 돌려 본 경로인가.

유일한 발표입니다. 10회 동안의 산출물이 곧 발표 재료이므로 새로 만들 것은 거의 없습니다 — 모으고 편집하는 일입니다.