--- title: "분석에서 위키까지 — 우리가 만든 AI 업무 파이프라인 (AX 전환기 2편)" description: "1편에서는 백엔드1팀이 왜 일하는 방식을 다시 설계하게 됐는지를 이야기했습니다. 2편에서는 그래서 무엇을 만들었는지 — 요청 하나가 들어와서 위키 문서가 되어 나가기까지의 파이프라인을 소개합니다. 1편 끝에서 세 가지 문제를 이야기했습니다. 인원 부족, 온보딩 부족, " canonical_url: "https://allrafintech.co.kr/blog/140" category: "개발" publisher: "올라핀테크" date_published: "2026-07-31 13:50:11" date_modified: "2026-08-05 15:16:09" language: "ko-KR" image: "https://static.revn.co.kr/in-blog/prod/20260731_135004_24307ec3.png" --- # 분석에서 위키까지 — 우리가 만든 AI 업무 파이프라인 (AX 전환기 2편) 올라핀테크 · 개발 · 2026-07-31 13:50:11 원문(HTML): https://allrafintech.co.kr/blog/140 --- > [1편](https://allrafintech.co.kr/blog/139 "여섯 명이 하던 일을 세 명이 하게 됐을 때 — 백엔드1팀 AI 전환기 (1편)")에서는 백엔드1팀이 왜 일하는 방식을 다시 설계하게 됐는지를 이야기했습니다. > 2편에서는 그래서 무엇을 만들었는지 — 요청 하나가 들어와서 위키 문서가 되어 나가기까지의 파이프라인을 소개합니다. 1편 끝에서 세 가지 문제를 이야기했습니다. 인원 부족, 온보딩 부족, 히스토리 문서 부재. 그리고 새로 합류한 동료의 실험에서 발견한 가능성 — AI가 서비스 전체를 가로질러 분석할 수 있다면, 일하는 방식 자체를 바꿀 수 있겠다는 것까지요. 2편은 그 결과물에 대한 이야기입니다. 다만 도구 설명서처럼 쓰진 않으려고 합니다. 핵심은 도구가 아니라 **구조**거든요.
## 발상의 전환: AI를 '쓰는' 게 아니라, AI가 일할 '환경'을 만든다 이전까지 우리가 AI를 쓰는 방식은 이랬습니다. 개발자가 문제를 파악하고, 어느 서비스의 어느 코드를 고칠지 판단한 다음, AI에게 "이거 해줘"라고 시키는 것. AI는 똑똑한 일손이었지만, 일을 준비시키는 건 전부 사람이었습니다. 바뀐 방식은 비유하자면 이렇습니다. **아주 똑똑한 신입사원이 들어왔다고 생각해보세요.** 머리는 비상한데 우리 회사를 전혀 모릅니다. 이 신입에게 성과를 내게 하려면 뭐가 필요할까요? * 회사의 모든 자료를 열람할 수 있는 **권한** (\= 전체 서비스 코드를 한곳에 모은 작업 공간) * "이런 요청이 오면 이렇게 처리한다"는 **업무 매뉴얼** (\= 표준화된 분석·설계 절차) * 선배들이 남긴 **과거 업무 기록** (\= 히스토리 문서와 위키) * 그리고 일이 끝나면 **보고서를 남기는 규칙** (\= 결과가 자동으로 문서화되는 구조) 신입사원이 AI라고 한다면, AI에게 이 네 가지를 갖춰주는 작업을 엔지니어들은 **'하네스(harness)를 만든다'** 고 부릅니다. 마구(馬具)라는 뜻인데, 좋은 말도 마구 없이는 마차를 끌 수 없듯이, 좋은 AI도 환경 없이는 제 능력을 못 냅니다. 우리가 네 달간 만든 건 새로운 AI가 아니라 이 하네스였습니다.

## 모든 일은 한곳에서 시작한다 — 분석 워크스페이스 그 하네스의 본체가 `allra-ai-analysis`라는 작업 공간입니다. 구조는 단순합니다. 올라 서비스를 구성하는 20여 개의 코드 저장소(레포)를 전부 한 지붕 아래에 모았습니다. ```ts allra-ai-analysis/ ├── project/ ← 올라의 모든 코드가 여기에 │ ├── backend/ 백엔드 서비스 8개 (선정산의 심장) │ ├── front/ 셀러 웹앱, 관리자 페이지 │ ├── python/ 크롤러, 데이터 수집기 │ ├── external/ 보증보험·결제·출금 등 외부 연동 서버 6개 │ ├── infra/ DB 설계도 원본 │ └── heum/ 제휴사(혜움) 연계 서비스 ├── docs/ ← 일하면서 쌓이는 위키 │ ├── history/ 분석·설계·장애대응·작업 기록 (현재 152건) │ └── reference/ 아키텍처, 용어집, 운영 가이드, 종합 문서 └── .claude/commands/ ← AI에게 가르친 업무 매뉴얼 14종 ``` 중요한 건, 여기서는 **코드를 고치지 않는다**는 점입니다. 이곳은 분석하고, 설계하고, 기록하는 곳입니다. 실제 코드 수정은 각 서비스의 저장소에서 따로 합니다. 회사로 치면 여기는 기획·분석실이고, 코드 저장소들이 생산 현장인 셈이죠. ### 왜 모았느냐 1편에서 말한 그 장면 때문입니다. 선정산 서비스는 서버별로 처리하는 역할이 나뉘어 있어서, "셀러분이 돈을 못 받았어요"라는 문의 하나에도 원인이 어디 숨어 있을지 알 수 없습니다. 예전에는 그 판단을 사람의 경험이 했다면, 이제는 AI가 20여 개 저장소를 함께 훑으며 원인 후보를 좁히는 데 도움을 줍니다.

## 일이 흘러가는 길 — 다섯 단계 CX팀의 운영 문의든 기획팀의 개발 요청이든, 이제 모든 일은 같은 길을 따라 흐릅니다.
요구사항 접수에서 문서화까지 이어지고, 다시 다음 분석으로 돌아오는 지식 루프. *▲요구사항 접수에서 문서화까지 이어지고, 다시 다음 분석으로 돌아오는 지식 루프.* 각 단계를 일반 언어로 풀면 이렇습니다. ### **1단계, 요구사항 접수.** 요청이 들어오면 성격부터 분류합니다. 장애인지, 기능 문의인지, 신규 개발인지. 이 분류에 따라 AI에게 시킬 업무 매뉴얼이 달라집니다. ### **2단계, 분석·설계.** 분석실(allra-ai-analysis)에서 AI와 함께 원인이나 변경 지점을 파악합니다. 여기서 중요한 약속이 하나 있는데 — AI는 분석을 시작하기 전에 **반드시 과거 기록을 먼저 찾아봅니다.** "비슷한 장애가 전에도 있었나?" "이 기능, 누가 언제 왜 바꿨었지?"를 사람이 아니라 AI가 위키에서 찾아 읽고 시작하는 겁니다. 분석이 끝나면 결과를 바탕으로 GitHub에 이슈를 발행합니다. 전체 그림을 담은 **마스터 이슈** 하나와, 실제 수정할 저장소별 **서브 이슈** 여러 개로 쪼개서요. 작업 지시서가 자동으로 만들어지는 셈입니다. 이 이슈 구조가 우리 협업의 뼈대라서, 그림으로 한번 보면 이렇습니다.
하나의 마스터 이슈가 저장소별 서브 이슈와 PR로 갈라졌다가, 최종 아카이브 문서로 다시 모이는 구조. *▲하나의 마스터 이슈가 저장소별 서브 이슈와 PR로 갈라졌다가, 최종 아카이브 문서로 다시 모이는 구조.* 하나의 요구사항이 마스터 이슈로 시작해 저장소별 서브 이슈로 갈라졌다가, 각각의 PR과 보고를 거쳐 다시 하나의 아카이브 문서로 모입니다. 일이 흩어졌다 다시 모이는 이 모양 덕분에, 몇 달 뒤에 누가 보더라도 "이 변경이 왜 있었는지"를 마스터 이슈 하나에서부터 끝까지 따라갈 수 있습니다. ### **3단계, 구현.** 개발자는 코드 저장소 쪽 작업 공간으로 넘어가 이슈를 하나씩 처리합니다. 여기에도 하네스가 있습니다. 각 저장소 안에는 그 서비스만의 코딩 규칙과 도메인 지식이 담긴 스킬 문서가 내장돼 있어서, AI가 해당 저장소의 코드를 만질 때 그 규칙을 참고하도록 설계되어 있습니다. 저장소마다 다른 사수가 옆에 붙는 구조라고 보시면 됩니다. ### **4단계, 리뷰·검증.** 코드가 완성되면 사람이 보기 전에 AI가 두 번 거릅니다. 만든 쪽 AI가 스스로 한 번(셀프 리뷰), 그리고 PR이 올라가면 독립된 리뷰 AI(CodeRabbit)가 또 한 번. 그 뒤 QA 환경에 배포해서 실제로 검증하고, 통과하면 개발자가 최종 확인 후 머지합니다. AI가 많이 일하는 만큼, 검증 단계는 오히려 더 촘촘해졌습니다. ### **5단계, 보고·문서화.** 여기가 우리 파이프라인의 백미입니다. 구현이 끝나면 AI가 마스터 이슈와 모든 서브 이슈, PR을 수집해서 **"무엇을 왜 어떻게 바꿨는지"를 정리한 아카이브 문서**를 만들고, 분석실의 히스토리 폴더에 저장합니다. 그리고 이 문서는 — 2단계에서 말했듯 — 다음 분석 때 AI가 먼저 찾아볼 수 있는 지식이 됩니다. 이 마지막 화살표 하나가 전체 구조의 핵심입니다. **문서화가 다음 분석을 더 똑똑하게 만들고, 똑똑해진 분석이 다시 더 좋은 문서를 만듭니다.** 일을 할수록 시스템이 우리 서비스를 더 잘 알게 되는 거죠.
## 슬래시 커맨드 — 업무를 '동사'로 만들다 이 절차들이 매번 사람의 기억에 의존하면 결국 무너집니다. 그래서 각 업무를 AI용 매뉴얼로 만들어 명령어 한 줄에 담았습니다. 현재 14종이 있고, 자주 쓰는 것들은 이렇습니다. | 이런 상황이 오면 | 이 명령어를 칩니다 | AI가 하는 일 | | ----------------------- | ------------------------ | ---------------------------------------------------------- | | "선정산 신청이 안 돼요" (운영 이슈) | /analyze:analyze-error | 서버 로그 조회 + 코드 역추적 + 원인 후보 정리를 한 번에 | | "이 시간대 에러 로그만 빨리 보고 싶다" | /grafana:loki-search | 증상을 말로 적으면 어느 서버의 로그를 뒤질지 AI가 판단해 검색식을 만들고, 결과를 에러 리포트로 정리 | | "이 기능 어떻게 동작하더라?" | /analyze:analyze-feature | 여러 저장소를 가로지르는 전체 흐름도 생성 | | "이런 기능 만들어주세요" (신규 개발) | /design:design-feature | 변경 지점·영향 범위·구현 계획 설계 후 이슈 발행 | | 구현이 다 끝났을 때 | /design:result | 이슈·PR을 수집해 히스토리 아카이브 생성 | | 위키가 낡지 않았는지 점검 | /wiki:lint | 오래된 문서, 끊어진 링크, 모순된 내용 탐지 | | 흩어진 기록을 주제별로 종합 | /wiki:synthesize | 관련 문서 여러 건을 묶어 종합 가이드 생성 | 명령어 하나에는 "과거 이력을 먼저 검색하라", "결과는 이 형식으로 정리하라", "관련 부서 전달 사항은 따로 표시하라" 같은 우리 팀의 일하는 약속이 전부 들어 있습니다. 덕분에 **누가 실행해도, 어느 AI 세션이 실행해도 비슷한 절차를 따르도록** 만들 수 있습니다. 신규 합류자에게는 이 명령어 목록 자체가 온보딩 자료가 되고요.

## 일을 하면 위키가 쌓인다 — LLM 위키 이렇게 네 달을 일하고 나니, 분석실에는 다음 결과물들이 쌓였습니다. * **히스토리 문서 152건** — 설계 아카이브 49건, 작업 기록 59건, 장애 대응 35건, 구조 분석 9건 * **종합(synthesis) 문서 12건** — 흩어진 기록들을 주제별로 엮은 것. 예를 들어 '출금 일원화 종합' 문서는 관련 기록 11건을, '어드민 크롤링 로그 종합'은 21건을 인용해 한 편의 가이드로 묶었습니다 * **레퍼런스 문서 23건** — 서비스 아키텍처, 도메인 용어집, 배치 일정표, 외부 연동 규격 같은 상시 참조 자료 다시 강조하면, 이건 **누군가 야근하며 따로 쓴 문서가 아닙니다.** 운영 이슈를 진단하면 진단서가 남고, 기능을 설계하면 설계서가 남고, 장애를 수습하면 수습 기록이 남는 구조에서 자연스럽게 쌓인 결과물입니다. 3\~4년간 코드 속에만 묻혀 있던 정책과 히스토리가, 일을 한 건 처리할 때마다 한 장씩 세상 밖으로 나오고 있는 겁니다. 그리고 이 위키는 처음부터 **두 종류의 독자**를 위해 설계했습니다. **사람을 위해서는** 웹 위키로 발행됩니다. 검색이 되고, 문서끼리 링크로 연결되고, 카테고리별로 탐색할 수 있는 사내 지식 사이트의 형태로요. **AI를 위해서는** 별도의 압축 인덱스가 자동 생성됩니다. `llms.txt`라는 표준 형식인데, 쉽게 말해 'AI용 교과서 목차'입니다. AI가 분석을 시작할 때 위키 전체를 다 읽는 대신 이 목차를 보고 필요한 문서만 골라 읽을 수 있게 해줍니다. 문서 간 인용 관계까지 담은 검색용 데이터(`wiki-index.json`)도 함께 만들어지고요. 위키의 품질 관리도 AI가 합니다. `/wiki:lint`라는 점검 명령은 오래되어 낡았을 가능성이 있는 문서, 어디서도 인용되지 않는 외딴 문서, 서로 모순되는 내용을 찾아 갱신 후보를 제안합니다. **문서가 쌓이기만 하고 썩어가는 것, 사내 위키가 망하는 가장 흔한 길을 막기 위한 장치입니다.**

### 실제로 어땠나 — 사례 두 가지 ### **사례 1: 매일 아침 8시 35분의 장애.** 어느 날부터 특정 쇼핑몰(다이소몰·컬리)의 회수 데이터 배치가 매일 같은 시각에 실패하기 시작했습니다. 예전 방식이라면 담당자가 서버 로그를 뒤지고, 배치 코드를 열고, 데이터를 수집하는 파이썬 크롤러까지 내려가 보는 데 한참이 걸렸을 일입니다. 지금은 `/analyze:analyze-error`에 증상을 넣으면 AI가 로그 조회와 코드 역추적을 한 번에 수행합니다. 원인은 자바 서버가 아니라 파이썬 크롤러 쪽의 쇼핑몰 매핑 누락이었는데 — **서로 다른 언어로 된 다른 저장소 두 곳에 걸친 문제**였는데도 멀티레포 환경이라 한 세션에서 끝까지 추적이 됐습니다. 그리고 이 진단 과정 전체가 장애 문서로 남아, **다음에 비슷한 증상이 오면 AI가 이 문서부터 읽고 시작합니다.** ### **사례 2: 세 갈래로 흩어져 있던 출금 로직.** 셀러 계좌에서 돈을 회수하는 '출금' 기능이 알고 보니 서로 다른 세 저장소에 제각각 구현되어 있었습니다. 하나는 곧 폐기될 레거시 서버에, 하나는 어드민의 수기 처리에, 하나는 배치에. 수년에 걸쳐 쌓인 역사의 산물이라 전체 그림을 아는 사람이 없었죠. 이걸 AI가 세 저장소를 동시에 분석해 비교표를 만들고, 어느 쪽을 정본으로 삼아 일원화할지 설계하고, 저장소별 작업 이슈까지 발행했습니다. 사람이 했다면 분석에만 며칠이 걸렸을, 그리고 솔직히 엄두가 안 나서 계속 미뤄뒀을 종류의 일입니다.

## 그래서, 무엇이 얼마나 달라졌나 네 달 남짓한 기간이지만, 이제는 체감이 아니라 패턴으로 말할 수 있는 변화들이 생겼습니다. ### **업무 처리 시간이 평균 절반으로 줄었습니다.** 코딩이 빨라져서가 아닙니다. 코딩은 그 전부터 AI가 빨랐어요. 줄어든 건 그 앞뒤 구간입니다. 요구사항을 분석하고, 어느 서비스를 고쳐야 할지 찾고, 영향 범위를 확인하고, 작업을 쪼개고, 끝나면 결과를 정리하는 — 예전에는 전부 사람 몫이라 전체 시간의 대부분을 차지하던 일들이죠. 지금은 이 구간을 파이프라인이 받아줍니다. ### **같은 실수를 반복하지 않게 됐습니다.** AI가 히스토리 문서를 깔고 분석과 설계를 시작하기 때문인데, 실제 사례가 하나 있습니다. 지난 5월, 탈퇴 후 재가입한 셀러가 제휴 금융사 심사에서 막히는 이슈가 있었고, 그 진단 과정이 장애 문서로 남았습니다. 3주 뒤 다른 셀러에게 똑같은 일이 생겼을 때 AI는 그 문서부터 읽고 "선례와 동일한 구조"라는 진단을 바로 내놨습니다. 6월의 장애 문서에는 실제로 "선례 그대로 유효"라는 문장이 남아 있어요. 신규 설계를 할 때도 과거 설계·장애 기록과 대조하며 시작하니, 기존 정책과 충돌하는 설계나 놓치는 사이드이펙트가 눈에 띄게 줄고 있습니다. ### **팀의 일하는 방식이 하나로 모였습니다.** 예전에는 각자 자기 방식대로 분석하고, 각자의 개인 문서에 계획을 적었습니다. 지금은 세 명이 같은 워크스페이스에서 같은 커맨드로 일합니다. 누가 시작한 일이든 이슈와 문서만 보고 다른 사람이 이어받을 수 있고, 한 사람의 분석 결과가 위키에 쌓여 다음 사람의 출발점이 됩니다. 한 명이 자리를 비워도 업무 맥락이 그 사람과 함께 사라지지 않는다는 것 — 이게 셋이서 내는 시너지의 실체입니다. ### **백엔드1팀만의 도구를 넘어서고 있습니다.** 작업 이슈를 발행하고 코드를 고치는 건 백엔드1팀이지만, '읽고 분석하는' 용도라면 이 워크스페이스는 누구에게나 유용합니다. 실제로 지금은 다른 팀에서도 이 프로젝트를 분석용으로 활용하고 있습니다. 올라 서비스의 동작이 궁금할 때 담당 개발자를 찾아가 묻는 대신, 이 워크스페이스를 열고 AI에게 바로 물어보는 거죠. 위키에도 '프론트팀을 위한 백엔드 가이드'처럼 처음부터 다른 팀 독자를 겨냥해 쓴 문서가 생기기 시작했고요. 만든 팀보다 쓰는 팀이 많아지는 것, 도구가 인프라가 되어가고 있다는 신호라고 생각합니다. ### **그리고, 일이 증명 가능해졌습니다.** 1편에서 "비용만큼의 퍼포먼스를 어떻게 증명할 건가?"라는 질문에 답하지 못했다고 했죠. 지금은 모든 업무가 이슈와 히스토리 문서와 활동 로그로 남습니다. 어떤 요청이 언제 들어와서 어떻게 분석됐고, 무엇이 바뀌었고, 결과가 어땠는지까지 전부요. 그때 그 질문을 다시 받는다면, 이제는 보여드릴 기록이 있습니다.

## 세 가지 문제는 어떻게 됐나 1편의 세 가지 문제로 돌아가서, 솔직하게 중간 결산을 해보면. ### **인원 부족** 사람이 늘어난 건 아닙니다. 다만 한 사람이 처리할 수 있는 일의 폭이 달라졌습니다. 서비스 이해도가 낮아도 AI 분석으로 원인 파악이 가능해졌고, 여러 저장소에 걸친 작업을 병렬로 진행할 수 있게 됐으니까요. "한 명 빠지면 무너지는 구조"에서 "시스템이 받쳐주는 구조"로 무게중심이 옮겨가는 중입니다. ### **온보딩 부족** 신규 합류자가 이제 빈손으로 시작하지 않습니다. 서비스 전체 구조를 AI가 정리해주는 온보딩 명령어가 있고, 모르는 게 생기면 위키와 AI에게 물어볼 수 있습니다. 사수의 시간을 뺏지 않고도 서비스를 파악할 수 있는 경로가 처음으로 생긴 겁니다. ### **히스토리 문서 부재** 2026년 7월 초 기준 152건. 숫자보다 중요한 건 방향입니다. 문서가 '시간 나면 쓰는 것'에서 '일하면 남는 것'으로 바뀌었다는 것. 이 구조가 유지되는 한 격차는 계속 메워집니다. 물론 다 해결됐다고 말하면 거짓말입니다. 쌓이는 문서의 품질을 계속 관리해야 하고, AI의 분석 결과는 어디까지나 초안이라 사람의 검증을 거쳐야 하며, 팀원 모두가 이 방식에 같은 깊이로 익숙해지는 데도 시간이 필요합니다. 위키를 사내에 더 보기 좋게 발행하는 일도 남아 있고요. 이 워크플로우 자체가 아직 '현재 진행형'입니다.

## 마치며 돌아보면 가장 큰 변화는 **도구가 아니라 관점**이었습니다. AI가 빨라지기를 기다리는 동안에는 아무것도 바뀌지 않았습니다. AI가 일할 수 있는 환경, 전체 코드를 볼 수 있는 작업 공간, 표준화된 업무 매뉴얼, 읽고 쓸 수 있는 위키를 만들기 시작하면서부터 모든 게 바뀌었습니다. 그리고 그 환경이 만들어내는 가장 값진 산출물은 코드가 아니라, 그동안 사람들의 머릿속에만 있다가 퇴사와 함께 사라지곤 했던 **우리 서비스의 기억**이었습니다. 여섯 명이 하던 일을 세 명이 하게 됐을 때, 우리에게 필요했던 건 세 명이 여섯 명처럼 일하는 법이 아니라 일하는 방식을 다시 설계하는 용기였던 것 같습니다. ***“백엔드1팀의 실험은 계속됩니다. 이 글 역시 그 분석 워크스페이스 안에서, AI와 함께 작성되었습니다.”*** > write. 백엔드1팀 김영완, 선혁준, 김승태
### 올라핀테크 팀의 이전 이야기👇 * [E2E 테스트 구조 설계와 VRT 적용기: 배포에 자신감을 더한 올라핀테크의 실험](https://allrafintech.co.kr/blog/137 "E2E 테스트 구조 설계와 VRT 적용기: 배포에 자신감을 더한 올라핀테크의 실험") * [감춰진 UI를 ‘보이게’ 만든 스토리 — 올라핀테크 프론트개발팀의 스토리북 도입기](https://allrafintech.co.kr/blog/126 "감춰진 UI를 ‘보이게’ 만든 스토리 — 올라핀테크 프론트개발팀의 스토리북 도입기") * [프로모션 혜택 (쿠폰, 포인트 무료)이 정말 전 환에 도움이 될까? — 올라핀테크 마케팅팀](https://allrafintech.co.kr/blog/136 "프로모션 혜택 (쿠폰, 포인트 무료)이 정말 전 환에 도움이 될까? — 올라핀테크 마케팅팀") * [유저가 원하는 말 한마디 찾기 — 올라핀테크 프로덕트디자인팀](https://allrafintech.co.kr/blog/135 "유저가 원하는 말 한마디 찾기 — 올라핀테크 프로덕트디자인팀") * [데이터독을 떠나 월 1,500달러를 아끼기까지: Grafana 기반 자체 모니터링 스택 구축기](https://allrafintech.co.kr/blog/134 "데이터독을 떠나 월 1,500달러를 아끼기까지: Grafana 기반 자체 모니터링 스택 구축기")