[AI-Native AFINIT] AI가 읽는 서비스 설계도로 조직의 업무속도를 높이는 법

1. Impact First: 개인 생산성을 넘어 조직의 실행 속도를 높이기

AI를 활용하면 개인의 업무 속도는 확실히 빨라집니다. PRD 초안을 빠르게 쓰고, SQL을 더 빨리 만들고, Slack 메시지를 더 빨리 정리할 수 있습니다. 하지만 최근 업무를 하면서 더 크게 느낀 점은, 진짜 임팩트는 개인의 속도 향상에서 끝나지 않는다는 것입니다.

이전 글들에서는 AFINIT이 어떻게 AI를 활용해 Financial Platform을 설계하고, 실시간 모니터링을 만들고, PM 개인의 반복 업무를 AI workflow로 바꿔왔는지 공유했습니다.

• AI 기반 금융 플랫폼 아키텍처와 혁신적인 금융 여정: Financial Platform의 구조와 방향성

• AI와 함께하는 FPJR 실시간 메트릭 모니터링: AI를 활용한 PM Self-served Monitoring

• 한 명의 PM이 더 큰 임팩트를 만드는 방식: Sidekick을 활용한 PM 개인 Workflow 생산성

이번 글은 그 다음 단계입니다. AI를 개인 생산성 도구로 쓰는 것을 넘어, 조직 전체가 같은 지식 기반 위에서 더 빠르게 스펙을 확인하고, 개발하고, 운영 이슈를 해결할 수 있는 구조를 만드는 이야기입니다.

조직의 업무 속도를 높이려면 AI가 반복해서 읽고 활용할 수 있는 공통 지식 기반이 필요합니다. PM, 개발자, QA, 운영팀이 같은 lifecycle, 같은 정책, 같은 evidence source를 기준으로 이야기할 수 있어야 합니다. 그래야 새로운 스펙 확인, PRD 작성, 개발 범위 산정, UAT, 운영 이슈 대응이 모두 빨라집니다.

이번에 만든 Financial Product Lifecycle Map은 그런 기반을 만들기 위한 작업이었습니다. 단순히 문서를 하나 만든 것이 아니라, AI가 읽을 수 있고 사람도 검증할 수 있는 형태로 실제 서비스의 lifecycle을 정리했습니다.

특히 True Balance의 Financial Product Lifecycle처럼 Application, Underwriting, Offer, Partner Approval, Disbursement가 여러 시스템과 상태값에 걸쳐 있는 경우에는 더 그렇습니다. PM, 개발자, Risk, 운영팀이 같은 단어를 쓰더라도 실제로 떠올리는 범위가 다를 수 있습니다.

예를 들어 "유저의 application이 만료된다"는 말 하나에도 여러 질문이 숨어 있습니다.

- 유저의 application 시점 기준인가, financial product별 만료 기준인가, offer 생성 시점 기준인가?
- underwriting이 끝난 뒤부터 며칠을 기준으로 볼 것인가?
- disbursement pending 상태도 expiry로 처리할 수 있는가?
- 사용자는 만료되었을 때 어떤 화면과 메시지를 보게 되는가?
- 감사 관점에서 어떤 evidence를 남겨야 하는가?

이 질문들이 정리되지 않으면 PRD를 빨리 써도 다시 수정됩니다. 개발 착수 후 edge case가 발견되고, QA/UAT 단계에서 정책 해석이 달라지고, 운영 이슈가 생겼을 때 원인을 다시 추적해야 합니다.

그래서 이번에는 AI를 "문서를 대신 써주는 도구"가 아니라, 조직 전체가 같은 기준 위에서 더 빠르게 스펙을 확인하고, 개발하고, 유지보수하기 위한 workflow로 사용했습니다.

2. Case: Financial Product Lifecycle Map을 일주일 안에 구조화하기

최근 만든 핵심 산출물은 Financial-Product-Lifecycle-SOP.pdf입니다. 파일명에는 내부 운영 문서 관점의 SOP가 남아 있지만, 외부적으로 설명하자면 AI가 읽을 수 있는 Financial Product Lifecycle Map에 가깝습니다. 목적은 고객의 Financial Product Journey를 Application부터 Disbursement까지 하나의 lifecycle로 정리하는 것이었습니다.

구성은 네 단계입니다.

1. Application

2. Underwriting

3. Offer & Partner Approval

4. Disbursement

각 단계별로 start/end boundary, decision point, recovery path, control point, evidence source를 정리했습니다. 단순 flow chart가 아니라, 빠른 스펙 확인, PRD 작성, UAT, 운영 이슈 분석, Audit에 재사용할 수 있는 기준 문서로 만든 것입니다.

이 작업은 이전 방식이었다면 오래 걸렸을 가능성이 높습니다. 각 단계별 owner에게 물어보고, 코드베이스를 따로 확인하고, 테이블과 상태값을 따로 정리하고, flow diagram을 수작업으로 만들고, 다시 PM의 운영 맥락으로 보정해야 했을 것입니다.

이번에도 AI Sidekick을 활용해 과정을 압축했습니다. 특히 github-ghe skill을 통해 회사 GitHub Enterprise의 실제 라이브 코드베이스를 AI가 쉽게 탐색할 수 있었던 점이 컸습니다. 문서만 보고 추정한 것이 아니라, 실제 서비스에서 사용 중인 code path, 상태값, 처리 경계를 확인하면서 service map을 만들 수 있었습니다.

이 지점이 중요합니다. 비개발자가 분리된 문서 환경에서만 작업하는 것이 아니라, AI와 함께 실제 돌아가고 있는 서비스의 코드베이스를 읽고, 그 이해를 바탕으로 스펙과 정책을 정리할 수 있게 된 것입니다. 이는 이후 AI 기반 코드 수정, 개발 계획 수립, 배포 영향 범위 확인으로 이어지기 위한 첫걸음입니다.

Workflow:

[Human] PM 암묵지/업무 질문 정의 -> [AI] GitHub Enterprise codebase와 기존 문서 탐색 
-> [AI] lifecycle stage/boundary 초안화 -> [Human] 실제 운영 맥락 보정 
-> [AI] service map/diagram/evidence source 정리 -> [Human] 최종 검증 
-> [AI] PDF 산출물 생성

여기서 중요한 점은 AI가 혼자 정답을 만든 것이 아니라는 점입니다. PM의 암묵지가 먼저 들어갔고, AI는 그 질문을 기준으로 codebase, 기존 문서, product spec, SQL artifact를 빠르게 연결했습니다.

결과적으로 PM 1명이 일주일 안에 다음을 포함한 문서를 모두 만들 수 있었습니다.

• Application -> Underwriting -> Offer & Partner Approval -> Disbursement 전체 Financial Product Lifecycle 구조

• 각 stage의 start/end boundary

• reject, recovery, fallback path

• audit reconstruction에 필요한 evidence source

• Mermaid 기반 lifecycle diagram

• Markdown 기반 service map과 PDF 산출물

이 결과물은 단순 문서가 아닙니다. 이후 Jira ticket, PRD, UAT, 운영 이슈 분석의 기준점이 됩니다. 더 나아가 AI가 스펙 확인과 개발 지원을 할 때 반복해서 참조할 수 있는 조직 지식 기반이 됩니다.

더 중요하게는, 이것이 실제 서비스 개발과 유지보수의 속도를 높이는 기반이라는 점입니다. PM이 AI와 함께 라이브 코드베이스를 읽고, 현재 정책과 구현 경계를 이해하고, 그 위에서 PRD와 Jira를 작성할 수 있으면 이후 코드 수정과 배포도 더 정확한 스펙에서 출발할 수 있습니다.

3. 무엇이 달라졌나: 조직이 같은 기준으로 더 빨리 움직인다

AI를 쓰기 전에도 PM은 문제정의를 했습니다. 다만 입력값을 모으는 데 시간이 오래 걸렸고, 그 결과가 조직 전체의 공통 기준으로 남기 어려웠습니다.

기존 방식은 대략 이랬습니다.

• 개발자에게 현재 flow를 묻는다.

• Risk/운영팀에 예외 케이스를 묻는다.

• Jira나 과거 문서를 뒤진다.

• 코드에서 상태값과 처리 위치를 찾는다.

• SQL로 실제 규모를 확인한다.

• 이 모든 내용을 다시 PRD 문장으로 정리한다.

• 다음 프로젝트에서 같은 맥락을 다시 설명한다.

AI Workflow에서는 이 과정이 더 빠르게 연결됩니다.

• GitHub Enterprise codebase에서 실제 flow와 상태값을 확인한다.

• 기존 service map과 product spec을 읽어 현재 문서화 수준을 파악한다.

• SQL artifact로 실제 영향 규모를 확인한다.

• PM의 암묵지를 바탕으로 "무엇이 진짜 문제인가"를 재정의한다.

• PRD/Jira/AC 형태로 바로 구조화한다.

• service map과 evidence source를 남겨 다음 업무의 기준점으로 재사용한다.

즉, 문제정의의 품질은 낮아지지 않았고 오히려 올라갔습니다. 더 많은 근거를 빠르게 확인한 뒤 정의하기 때문입니다. 동시에 그 결과가 AI가 다시 읽을 수 있는 service map과 artifact로 남기 때문에, 다음 스펙 확인과 개발 계획 수립도 빨라집니다.

4. Application Expiry Task - 서비스 설계도가 문제정의를 더 정확하게 만든 사례

Financial Product Lifecycle Map이 바로 효과를 낸 사례가 Application Expiry입니다.

처음 문제는 단순해 보였습니다.

Application expiry 정책이 모호하다.

하지만 lifecycle map과 codebase, SQL artifact를 함께 보니 문제는 단순히 scheduler를 하나 추가하는 것이 아니었습니다.

정확한 문제정의는 다음에 가까웠습니다.

Application, financial product, offer의 expiry 기준이 분리되어 있고, 어떤 상태를 expiry로 볼 것인지, 언제 financial product의 상태를 바꿀 것인지, 어떤 예외 상태를 별도 SLA로 처리할 것인지에 관한 기준들이 흩어져있다.

AI Workflow는 이 문제를 다음 순서로 정리했습니다.

Workflow:

[Human] 정책 모호성 문제 제기 -> [AI] lifecycle map/legacy spec/codebase 확인 
-> [AI] SQL로 사용자 노출 규모와 stale case 확인 -> [Human] expiry 정책 기준 판단 
-> [AI] Impact Analysis/AC/Jira requirement 구조화

실제 분석에서는 30일 이상 non-terminal 상태로 남아 있는 유저가 존재했고, 그 유저들은 offer list 화면이 여전히 많은 사용자에게 노출되고 있음을 확인했습니다. 또한 그들의 상태를 분류하여 상태별 유저가 왜 오래 남는지에 대한 code-level root cause hypothesis를 정리했습니다.

이 과정을 통해 requirement는 "application을 7일 뒤 만료 처리한다" 수준이 아니라 다음 항목을 포함하게 되었습니다.

• expiry 판단 기준

• auto-withdraw 대상 상태

• 제외해야 할 disbursement pending 계열 상태

• user-facing behavior

• UAT와 audit evidence

이것이 문제정의의 차이입니다. AI가 문장을 더 빨리 쓴 것이 아니라, 모호한 문제를 실행 가능한 정책 단위로 쪼개는 데 도움을 준 것입니다.

5. Underwriting Revamp: 서비스 설계도가 "리팩토링의 목적"을 바꾼 사례

Underwriting Revamp는 이 글의 메인 사례는 아니지만, 서비스 설계도와 라이브 코드베이스가 합쳐졌을 때 문제정의 자체가 어떻게 달라지는지 보여주는 사례입니다.

처음 논의는 전형적인 엔지니어링 리팩토링에 가까웠습니다.

underwriting evaluation 흐름이 복잡하니, 구조를 정리하자.

이 상태로 PRD를 썼다면 결과물은 "서비스를 더 깔끔하게 나누는 리팩토링 문서"가 됐을 겁니다. 하지만 그렇게 정의된 리팩토링은 정작 이 룰을 매일 운영해야 하는 Risk Management 팀 입장에서는 체감이 거의 없는 작업이 됩니다. 내부 코드만 예뻐질 뿐, 비개발자가 할 수 있는 일은 그대로이기 때문입니다.

AI가 github-ghe skill을 통해 실제 underwriting/rule 실행 경로를 읽고, 그 위에 lifecycle map을 겹쳐보니 문제는 두 개의 층으로 다시 정의됐습니다.

• Layer 1 — Rule Platform Foundation 리팩토링: 코드베이스의 underwriting/rule 실행 구조를 정리하되, 목적은 "개발자가 편한 구조"가 아니라 "비개발자가 룰을 안전하게 이해/검증/운영할 수 있는 기반"을 만드는 것.

• Layer 2 — Rule Manager Console: Risk Management 팀이 직접 운영하는 웹사이트. PM이 바이브 코딩으로 만들고, Layer 1이 제공하는 API/데이터/trace 위에서 동작.

핵심은 리팩토링의 성공 기준이 바뀌었다는 점입니다. 단순히 서비스를 나누는 것이 아니라, Layer 1이 다음을 제공해야 의미가 있다고 정리됐습니다.

• 어떤 rule이 어떤 step / product / category에 걸려 있는지 조회 가능

• rule이 어떤 input field를 쓰는지 추적 가능

• 특정 application이 왜 reject / pass 됐는지 trace 가능

• rule 변경 전 simulation 가능

• report / context version이 남아서 replay 가능

• maker-checker, versioning, rollback을 붙일 수 있는 구조

즉, 서비스 설계도와 라이브 코드베이스가 있었기 때문에, 이 작업은 "내부 리팩토링"이 아니라 "Risk 팀이 스스로 룰을 운영하기 위한 API/데이터/trace foundation을 만드는 일"로 재정의될 수 있었습니다. AI가 코드를 빨리 읽어준 것을 넘어, PM이 프로젝트의 문제정의와 목적을 더 빨리 명확하게 만든 것입니다.

6. AI가 실서비스 개발과 유지보수를 빠르게 만드는 방식

이번 경험에서 확인한 AI의 역할은 크게 다섯 가지입니다.

1. 라이브 코드베이스 이해 속도 향상

PM이 직접 모든 Java service, status transition, DB table을 읽는 것은 현실적으로 어렵습니다. github-ghe skill을 통해 AI가 실제 GitHub Enterprise codebase를 탐색하면, 관련 파일과 흐름, 그리고 코드에 녹아있는 정책을 빠르게 찾을 수 있습니다. PM은 그 결과가 비즈니스 맥락과 맞는지 판단합니다.

이것은 문서 작성만을 위한 탐색이 아닙니다. 실제 라이브 서비스의 구현 경계를 이해하는 과정이기 때문에, 이후 코드 수정 범위와 배포 영향도를 더 정확하게 잡는 기반이 됩니다.

2. Codebase 탐색의 기준점 제공

AI가 질문을 받을 때마다 codebase 전체를 바로 탐색하게 하면 빠르게 보이지만, 실제로는 비효율적일 때가 많습니다. 코드베이스는 너무 넓고, 같은 business concept이 여러 service, table, status, scheduler에 흩어져 있기 때문입니다.

Financial Product Lifecycle Map은 AI가 codebase로 내려가기 전에 먼저 읽는 업무 지도 역할을 합니다.

• 어떤 lifecycle stage의 문제인지 먼저 좁힌다.

• 해당 stage의 start/end boundary와 decision point를 확인한다.

• 관련 evidence source와 상태값 후보를 먼저 본다.

• 그 다음 GitHub codebase에서 필요한 service와 code path만 찾아간다.

이 방식의 기술적 이점은 명확합니다. AI의 검색 범위가 줄어들고, 불필요한 파일 탐색이 줄고, 같은 용어를 잘못 해석할 가능성이 낮아집니다. 즉, 낭비되는 많은 토큰을 방지할 수 있습니다.

또한 스펙 확인 시 "어느 코드부터 봐야 하는가"가 명확해져서, 개발 범위와 배포 영향도도 더 빨리 좁힐 수 있습니다.

즉, service map은 codebase를 대체하는 문서가 아닙니다. AI가 실제 codebase를 더 정확하게 읽기 위한 routing layer입니다.

3. PM 암묵지의 조직 지식화

PM은 업무를 하면서 많은 암묵지를 갖고 있습니다. 어떤 상태가 실제 운영에서 자주 문제 되는지, 어떤 화면이 사용자에게 중요하게 노출되는지, 어떤 팀이 어떤 용어를 다르게 쓰는지 알고 있습니다.

AI는 이 암묵지를 문서 구조로 바꾸는 데 유용합니다. 질문을 단계로 나누고, edge case를 빠뜨리지 않게 하고, service map/PRD/Jira 형태로 정리합니다. 개인 머릿속에 있던 판단 기준이 조직이 다시 읽을 수 있는 지식으로 바뀝니다.

4. 데이터 기반 검증

문제정의는 데이터로 검증되어야 합니다. 사용자 노출 규모, stale case, funnel impact, blocked event volume 같은 숫자가 붙어야 우선순위를 판단할 수 있습니다.

AI Sidekick은 Jupyter/SQL workflow를 통해 문제정의 단계에서 바로 impact를 확인할 수 있게 해줍니다.

5. 산출물의 재사용성

한 번 만든 service map은 다음 PRD의 context가 됩니다. 한 번 정리한 evidence source는 다음 audit 대응에 쓰입니다. 한 번 정의한 lifecycle boundary는 다음 Jira requirement에서 기준점이 됩니다. 그리고 GitHub Enterprise codebase와 연결되어 있으면 이 지식은 문서에서 멈추지 않고, 실제 코드 수정과 배포 계획의 출발점이 됩니다.

이 재사용성이 쌓여야 AI 생산성이 개인 작업 단축을 넘어 조직 생산성으로 확장됩니다.

AI가 실서비스 개발과 유지보수에 기여하려면 매번 새로운 프롬프트에서 시작하면 안 됩니다. 같은 service map, 같은 codebase context, 같은 evidence source 위에 계속 쌓여야 합니다. 그래야 AI가 빠르게 스펙을 확인하고, 개발 범위를 제안하고, UAT query를 만들고, 배포 후 변경된 정책 문서를 다시 업데이트할 수 있습니다.

7. 향후 계획: GitBook 기반 살아있는 PRD

저는 이번 Financial Product Lifecycle Map은 일회성 문서로 끝내고 싶지 않습니다. 제가 AFINIT에서 AI-Native 측면에서 바라보고 있는 최종적인 목표는 이 문서를 시작으로 GitBook 기반의 살아있는 Product Knowledge Base로 운영하는 것입니다.

앞으로는 codebase 변경이나 주요 정책 배포가 발생할 때마다 관련 SOP/PRD가 자동으로 업데이트 후보를 만들고, PM이 그 변경 내용을 리뷰하고 승인하는 방식으로 발전시키고자 합니다.

AI가 문서를 쓰고, PM이 비즈니스 의도와 정책 정확성을 검증하며, 최종적으로 조직이 신뢰할 수 있는 최신 PRD를 유지하는 구조입니다.

이 구조가 만들어지면 PM과 개발팀 모두 같은 지식 기반 위에서 움직일 수 있습니다.

• PM은 새로운 요구사항을 작성하기 전에 현재 정책과 lifecycle boundary를 빠르게 확인할 수 있습니다.

• 개발자는 구현 전후로 어떤 정책 문서가 영향을 받는지 확인할 수 있습니다.

• AI는 최신 PRD와 service map, 그리고 GitHub Enterprise의 실제 코드베이스를 context로 삼아 더 정확한 스펙 초안, Jira ticket, UAT query, 개발 계획을 생성할 수 있습니다.

• AI 세션은 먼저 service map으로 업무 맥락과 lifecycle 위치를 잡고, 그 다음 필요한 code path만 GitHub codebase에서 확인할 수 있습니다.

• 비개발자도 분리된 문서 환경에만 머무르지 않고, 실제 서비스 구현과 배포 흐름을 이해한 상태에서 요구사항을 정의할 수 있습니다.

• Audit이나 운영 이슈가 발생했을 때도 현재 정책, evidence source, 예외 케이스를 빠르게 추적할 수 있습니다.

결국 중요한 것은 문서를 많이 만드는 것이 아닙니다. 조직 전체가 같은 지식 기반 위에 계속 쌓아가는 것입니다.

AI-Native 조직이 되기 위해서는 개별 구성원이 AI를 잘 쓰는 것만으로는 부족합니다. 코드, 정책, 데이터, 의사결정 기록이 연결된 공통 지식 기반이 있어야 하고, 그 위에서 AI workflow가 반복 실행되어야 합니다. 이런 그림이 나와야 AI-Native가 추구하는 비즈니스 목표인 조직의 생산성 (Revenue per Employee) 극대화를 달성할 수 있을 것입니다.

그런 의미에서 Financial Product Lifecycle Map과 GitBook 기반의 살아있는 PRD 체계는 단순한 문서화 프로젝트가 아니라, AFINIT이 조직 전체로 AI-Native하게 일하기 위한 중요한 마일스톤입니다. 앞으로 GitBook 기반의 살아있는 Product Knowledge Base의 운영이 고도화되면 블로그 글로 한번 더 포스팅하겠습니다.

8. 마치며

AI-Native workflow의 진짜 임팩트는 PM 한 명이 더 빨라지는 데서 멈추지 않습니다. 일주일 안에 실제 라이브 코드베이스, 기존 정책 문서, 데이터 evidence, PM의 암묵지를 연결해 조직이 함께 읽을 수 있는 Financial Product Lifecycle Map을 만듦으로서 AI-Native 프로덕트 엔지니어링 ‘조직’으로 조직의 속도와 생산성을 증대하는 데 있습니다.

Financial Product Lifecycle Map은 AFINIT이 AI-Native하게 일하기 위한 기반 작업 중 하나입니다. 이전 글들이 AI로 개인과 팀의 생산성을 끌어올리는 사례였다면, 이번 작업은 그 생산성을 AFINIT 프로덕트 엔지니어링 조직의 공통 지식 기반으로 확장하는 시도였습니다.

마지막으로, AI-Native 이니셔티브를 계속해서 서포트 해주시고 코멘트 주시는 Peter Kim & Jack Yoon과, 저와 같은 PM도 편하게 AI-Native 인프라를 누릴 수 있게 도움주시는 Tech Foundation Service팀에게 감사인사를 전하고 싶습니다.

감사합니다.