# 파생상품감사보고서 자동화 서비스 구축: 기획 및 프로토타입 구축 - 작성자: [산뜻한 수달](https://community.clauders.ai/member/imported-member-Zmxv4yrHMT) - 공간: [에이전트 / 노코드 자동화](https://community.clauders.ai/automation) - 게시: 2026-05-24 - 연재: [문서 자동화 시스템 설계](https://community.clauders.ai/series/document-automation-systems) 3/5편 - 태그: #문서자동화 - 주소: https://community.clauders.ai/automation/post/%ED%8C%8C%EC%83%9D%EC%83%81%ED%92%88%EA%B0%90%EC%82%AC%EB%B3%B4%EA%B3%A0%EC%84%9C-%EC%9E%90%EB%8F%99%ED%99%94-%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B5%AC%EC%B6%95-%EA%B8%B0%ED%9A%8D-%EB%B0%8F-%ED%94%84%EB%A1%9C%ED%86%A0%ED%83%80%EC%9E%85-%EA%B5%AC%EC%B6%95-93f13105-5572-8e44-8568-5458f7d8eee1 --- ## ⏺ 📝 한줄 요약 파생상품 감사지원 웹사이트를 만들어달라는 요청이 왔을 때, 바로 코딩을 시작하지 않고 폴더 구조부터 설계한 덕분에 5개 워크플로우·20개 step·31개 파일을 일관성 있게 완성할 수 있었습니다. --- 바쁘시면 이것만 읽어도 돼요: - 웹사이트 제작은 HTML 짜는 것보다 폴더 구조 = 업무 흐름 설계가 본질입니다. - 먼저 코딩을 시작하려다 "설계부터 해달라"는 방향 수정이 결정적이었습니다. 그 한 마디가 전체 구조를 잡아줬습니다. - 기획서 1개보다 실무 가이드라인 + 조서 예시 두 문서가 콘텐츠 품질을 좌우했습니다. - 공통 레이어(CSS·JS)를 먼저 깔면, 20개 step 페이지에서 중복 코드가 0이 됩니다. - 실제 조서 예시 수치를 그대로 넣으면 데모가 현실감이 완전히 달라집니다. --- 🎯 이런 분들께 도움돼요 - 기획서를 받았을 때 바로 구현부터 달려드는 개발자·기획자 - AI에게 웹사이트 만들어달라고 했더니 파일 하나짜리 HTML이 나와서 당황한 분 - 복잡한 다단계 업무 흐름을 UI로 구현하려는 분 - 파생상품 평가·감사 업무를 AI로 자동화하고 싶은 금융·회계 실무자 --- 😫 문제 상황 (Before) 기획안에는 이렇게 적혀 있었습니다. ▎ - 상품명: CB, RCPS, EW, SO, 주주간 계약 ▎ - 고객사/감사인 두 유형, 각각 평가·질의 두 워크플로우 ▎ - 평가: 계약서 업로드 → AI 분석 → 조건 선택 → 파라미터 입력 → 평가 실행 → 다운로드 텍스트로 읽으면 단순해 보이지만, 실제로 화면으로 옮기면 다음이 결정이 안 된 상태였습니다. - 고객사와 감사인의 step이 비슷하지만 미묘하게 다른데, 파일을 어떻게 나눌 것인가 - 감사인 질의는 "최초질의"와 "답변검토" 두 갈래인데, 이걸 어떤 폴더 구조로 표현할 것인가 - CSS·JS는 20개 페이지가 공유하는데, 중복 없이 어떻게 관리할 것인가 - 조서 예시 파일의 실제 수치를 어떻게 가져다 쓸 것인가 이 질문들에 답이 없는 채로 코딩을 시작하면, 나중에 step 하나 추가할 때마다 같은 HTML을 20군데서 고쳐야 하는 상황이 옵니다. --- 🛠️ 사용한 도구 - Claude (Claude Code CLI) — 전체 설계·구현 담당 - 바닐라 HTML + CSS + JavaScript — 프레임워크 없이 순수 웹 표준 - sessionStorage 기반 state.js — 페이지 간 데이터 전달 - 참고 문서 3종: 기획안_v0.1_20260524.txt, 실무 가이드라인.txt, 조서예시_CB_[1.md](http://1.md) --- 🔧 작업 과정 Phase 1 — 기획서 읽기: "문서 3개가 서로 다른 역할을 한다" 첫 번째로 한 일은 3개 파일을 읽는 것이었습니다. - 기획안: 업무 흐름과 사용자 유형 정의. "무엇을 만들 것인가" - 실무 가이드라인: 파생상품 평가 실무 규칙. "AI가 어떤 내용을 알아야 하는가" - 조서예시_CB_[1.md](http://1.md): 실제 전환사채 감사 조서 전문. "화면에 어떤 데이터가 들어가야 하는가" 기획안만 읽었으면 껍데기 UI가 나왔을 겁니다. 실무 가이드라인과 조서 예시가 있었기 때문에 "변동성 이상치 제거 금지" 규칙을 AI 패널에 넣고, 예시 수치를 step5 비교 테이블에 그대로 채울 수 있었습니다. --- Phase 2 — 방향 전환: "설계부터" 처음에는 바로 index.html을 짜기 시작했습니다. 그런데 사용자가 이렇게 말했습니다. ▎ "결과물을 만들기에 앞서 주요단계별로 폴더구조를 만들고 각 단계에 맞게 실행하도록 설계해줘." 이 한 마디가 전체 작업의 방향을 바꿨습니다. 즉시 멈추고 [DESIGN.md](http://DESIGN.md)를 먼저 작성했습니다. [DESIGN.md](http://DESIGN.md)에는 다음을 정의했습니다. ┌──────────────────────┬─────────────────────────────────────────────────────────────┐ │ 항목 │ 내용 │ ├──────────────────────┼─────────────────────────────────────────────────────────────┤ │ 폴더 구조 │ 기획서의 업무 흐름을 폴더로 1:1 매핑 │ ├──────────────────────┼─────────────────────────────────────────────────────────────┤ │ 각 step의 입력/출력 │ 이전 단계가 넘겨주는 state 키, 다음 단계로 전달하는 데이터 │ ├──────────────────────┼─────────────────────────────────────────────────────────────┤ │ 공통 레이어 역할 │ state.js(데이터), router.js(이동), components.js(UI 렌더링) │ ├──────────────────────┼─────────────────────────────────────────────────────────────┤ │ 구현 순서 │ CSS → JS → 데이터 → HTML │ ├──────────────────────┼─────────────────────────────────────────────────────────────┤ │ 상품데이터 폴더 역할 │ AI 응답 목업 + 평가 수치를 JS 파일로 분리 │ └──────────────────────┴─────────────────────────────────────────────────────────────┘ 폴더 구조를 먼저 생성하고 빈 stub 파일을 만들었을 때, 전체 지도가 눈에 보였습니다. 이후 구현은 지도의 빈칸을 채우는 작업이었습니다. 파생상품 감사지원 플랫폼/ ├── 공통/ ← 공유 리소스 (CSS, JS) ├── 상품데이터/ ← AI 응답 목업 (CB.js 등) ├── 고객사/평가/ ← step1~6 ├── 고객사/질의/ ← step1~3 ├── 감사인/평가/ ← step1~6 └── 감사인/질의/ ├── 최초질의/ ← step1~2 └── 답변검토/ ← step1~4 --- Phase 3 — 공통 레이어 먼저: "중복 없는 구조의 전제조건" HTML 페이지 작업 전에 3개 JS 파일을 먼저 완성했습니다. - state.js: sessionStorage로 step 간 데이터 전달. State.set('product','CB'), State.get('parameters') 형태 - router.js: 페이지 이동 + 숫자 포맷 유틸. Router.formatNumber(n) 하나로 31개 페이지에서 원화 표시 통일 - components.js: AI 로딩 패널, 드롭존, step 표시바 렌더링 함수. 반복 HTML을 함수 호출 한 줄로 대체 이 3개를 먼저 만든 덕분에, 이후 HTML 페이지들은 비즈니스 로직에만 집중할 수 있었습니다. step 표시바가 모든 페이지에서 같은 모양인 이유도, step5의 숫자 포맷이 통일된 이유도 여기서 나왔습니다. CSS도 두 파일로 분리했습니다. - global.css: 색상 변수, 타이포그래피, 레이아웃 기초 — "이것만 바꾸면 전체 색이 바뀐다" - components.css: 드롭존, AI 패널, step 표시바, 결과 카드, 조서 스타일 등 컴포넌트별 스타일 --- Phase 4 — 상품 데이터: "조서 예시가 콘텐츠 품질을 결정했다" CB.js 하나에 조서예시_CB_[1.md](http://1.md)에서 읽어온 실제 수치를 전부 담았습니다. demoResults: { client: { bondValue: 44266964500, // 주사채 putValue: 5422017869, // 상환권 equityValue: 8814459654, // 전환권 total: 58503442023 // 전체가치 }, auditor: { bondValue: 44268490070, ... } } 이 수치들이 들어가자 step5 비교 테이블이 실제 감사 현장 같은 느낌이 됐습니다. 가상의 숫자로 채웠으면 나오지 않았을 현실감입니다. 실무 가이드라인의 핵심 규칙도 JS 데이터로 박아뒀습니다. guideline: '⚠️ 변동성 산출 시 IQR, MAD 등 통계적 방법으로 이상치를 제거해서는 안 됩니다.' 이 한 줄이 step4(파라미터 입력) AI 패널에서 자동으로 표시됩니다. 페이지마다 같은 내용을 따로 쓸 필요가 없습니다. --- Phase 5 — HTML 구현: "핵심 워크플로우부터" [DESIGN.md](http://DESIGN.md)에 정의한 구현 순서대로 진행했습니다. 1. 랜딩 → 메뉴 페이지들 (뼈대 확인) 2. 감사인/평가 step1~6 먼저 (가장 복잡하고 핵심적인 워크플로우) 3. 고객사/평가 step1~6 (감사인 패턴을 참고해 빠르게) 4. 질의 워크플로우 전체 감사인/평가 step5가 가장 공을 들인 페이지입니다. 진행 애니메이션(7단계, 500ms 간격) → 비교 테이블 → AR 자동 판정 → AI 검토 의견 순서로 화면이 구성됩니다. 실제 감사 현장에서 "허용 오차 범위 내 — 적정" 판정이 나오는 순간을 화면으로 재현했습니다. --- ✅ 결과 (After) Before vs After ┌────────────────────────┬────────────────────────┬─────────────────────────────────────────┐ │ 항목 │ Before │ After │ ├────────────────────────┼────────────────────────┼─────────────────────────────────────────┤ │ 파생상품 감사지원 도구 │ 기획안 텍스트 파일 1개 │ 31개 HTML+JS+CSS 파일, 완성된 웹 플랫폼 │ ├────────────────────────┼────────────────────────┼─────────────────────────────────────────┤ │ 화면 구성 │ 없음 │ 5개 워크플로우, 20개 step 페이지 │ ├────────────────────────┼────────────────────────┼─────────────────────────────────────────┤ │ AI 분석 데이터 │ 없음 │ 조서예시 실제 수치 전부 탑재 (CB.js) │ ├────────────────────────┼────────────────────────┼─────────────────────────────────────────┤ │ 중복 관리 │ 해당 없음 │ 공통 레이어 3개 파일로 31개 페이지 통일 │ ├────────────────────────┼────────────────────────┼─────────────────────────────────────────┤ │ 실무 가이드라인 │ txt 파일 보관 │ 각 step AI 패널에 자동 표시 │ └────────────────────────┴────────────────────────┴─────────────────────────────────────────┘ 산출물 ┌──────────────────────────────────────┬────────────────────┬──────────────────────────────────────┐ │ 파일 │ 위치 │ 역할 │ ├──────────────────────────────────────┼────────────────────┼──────────────────────────────────────┤ │ global.css + components.css │ 공통/css/ │ 전체 디자인 시스템 │ ├──────────────────────────────────────┼────────────────────┼──────────────────────────────────────┤ │ state.js + router.js + components.js │ 공통/js/ │ 공통 로직 │ ├──────────────────────────────────────┼────────────────────┼──────────────────────────────────────┤ │ CB.js │ 상품데이터/ │ 조서예시 실제 수치 + 가이드라인 탑재 │ ├──────────────────────────────────────┼────────────────────┼──────────────────────────────────────┤ │ step1~6 × 고객사·감사인 │ 각 워크플로우 폴더 │ 단계별 UI·로직 │ ├──────────────────────────────────────┼────────────────────┼──────────────────────────────────────┤ │ [DESIGN.md](http://DESIGN.md) │ 루트 │ 전체 설계 문서 (입력/출력/구현순서) │ ├──────────────────────────────────────┼────────────────────┼──────────────────────────────────────┤ │ RCPS·EW·SO·SA.js │ 상품데이터/ │ 향후 확장용 스텁 │ └──────────────────────────────────────┴────────────────────┴──────────────────────────────────────┘ --- 💬 이 과정에서 배운 AI 활용 팁 1. "바로 코딩" 대신 "설계 먼저" — 그 한 마디가 30개 파일을 구했다 처음에 바로 HTML을 짜기 시작했습니다. 사용자가 "설계부터"라고 방향을 잡아줬고, [DESIGN.md](http://DESIGN.md) 하나를 먼저 쓴 덕분에 이후 구현이 지도를 따라가는 작업이 됐습니다. 방향 수정 없이 그냥 갔으면 나중에 step 하나 추가할 때마다 여러 파일을 동시에 건드려야 했을 겁니다. 2. 참고 문서의 역할을 구분해라 — 기획서·가이드라인·예시는 각자 쓰임이 다르다 기획서는 "무엇을 만들지"를 알려줍니다. 실무 가이드라인은 "AI가 어떤 내용을 알아야 하는지"를 알려줍니다. 조서 예시는 "실제 데이터가 어떻게 생겼는지"를 알려줍니다. 이 세 역할을 분리해서 읽어야, 각각을 어디에 활용할지가 보입니다. 3. 데이터 레이어를 먼저 만들면 UI가 살아난다 CB.js에 실제 수치를 넣기 전과 후의 step5 화면은 완전히 달랐습니다. "주사채 *****원"이 들어가는 순간 감사 현장의 느낌이 납니다. 가상의 숫자 1,000원, 2,000원으로 채운 데모와는 설득력이 다릅니다. 이렇게 하면 안 돼요 1. 기획서만 읽고 바로 구현 — 참고 문서를 전부 읽어야 콘텐츠 품질이 나옵니다. 2. 공통 레이어 없이 페이지부터 — CSS 하나 바꾸는 데 20개 파일을 고쳐야 하는 상황이 옵니다. 3. 더미 데이터로 끝까지 가기 — 실제 예시 수치를 넣는 순간 데모의 설득력이 완전히 달라집니다. --- 🌍 다른 업무에 적용한다면? 이 구조는 단계가 있는 모든 반복 업무 UI에 적용 가능합니다. - 계약서 검토 도구 — 업로드 → AI 조항 분석 → 위험 조항 선택 → 검토 보고서 - 세금 신고 보조 — 항목 입력 → AI 검증 → 수정 → 신고서 다운로드 - HR 평가 시스템 — 목표 입력 → 중간 체크 → 최종 평가 → 레포트 핵심은 같습니다. 설계서([DESIGN.md](http://DESIGN.md)) → 공통 레이어 → 데이터 레이어 → 화면 레이어 순서로 쌓으면, 나중에 step 하나를 추가하거나 상품 하나를 추가할 때 영향 범위가 명확합니다. --- 🚀 앞으로의 계획 1. 상품 확장 — RCPS, EW, SO, SA.js에 실제 데이터 탑재. 각 상품별 특수 구조와 가이드라인 반영. 2. 실제 AI 연동 — 현재 목업(Mock) 데이터로 시뮬레이션하는 AI 응답을 실제 Claude API로 교체. 계약서 PDF 파싱 → 실시간 구조 분석. 3. 파일 변환 파이프라인 — 보고서 다운로드 버튼에 실제 Word/Excel 생성 기능 연결. --- 📋 재사용 가능한 프롬프트 프롬프트 1: 구현 전 설계 요청 ▎ [기획서/요구사항]을 읽고 바로 코딩하지 말고 먼저 이것부터 해줘: ▎ ▎ 1. 폴더 구조를 업무 흐름에 1:1로 매핑해서 설계해줘 ▎ 2. 각 단계(step)의 입력·처리·출력을 [DESIGN.md](http://DESIGN.md)에 표로 정리해줘 ▎ 3. 공통 레이어(CSS, JS)와 데이터 레이어를 먼저 식별해줘 ▎ 4. 구현 순서를 구체적으로 정해줘 (어떤 파일을 먼저 만들어야 나머지가 수월한지) ▎ ▎ 설계 확인 후에 구현 시작해줘. 프롬프트 2: 공통 레이어 먼저 구축 ▎ [프로젝트]에서 모든 페이지가 공유하는 공통 레이어를 먼저 만들어줘: ▎ ▎ - 디자인 토큰(색상·간격·폰트)은 CSS 변수로 한 곳에만 정의 ▎ - 반복되는 UI 패턴(헤더, 단계 표시바, AI 응답 패널 등)은 JS 함수로 분리 ▎ - 페이지 간 데이터 전달은 [sessionStorage/localStorage/URL params] 중 [선택]으로 통일 ▎ ▎ 이 파일들이 완성된 후에 개별 페이지 구현 시작해줘. 프롬프트 3: 실제 예시 데이터 활용 지시 ▎ [화면/데모]를 만들 때 더미 데이터("샘플", 1000원, OOO) 대신 [제공한 문서]의 실제 수치와 내용을 그대로 써줘: ▎ ▎ - 수치: [문서명]에 있는 실제 숫자 그대로 ▎ - 텍스트: [문서명]의 실제 표현·용어·계층 구조 그대로 ▎ - 예외: 개인정보·기밀에 해당하는 항목만 마스킹 ▎ ▎ 실제 데이터가 들어가야 데모의 현실감이 살아납니다. --- 이번 작업은 웹사이트 결과물보다 폴더 구조 = 업무 흐름이라는 원칙을 실증한 기록입니다. 다음 단계인 실제 AI 연동과 상품 확장까지 마치면 다시 정리해 올리겠습니다.