[AI-Native AFINIT] 한 명의 PM이 더 큰 임팩트를 만드는 방식: 재현 가능한 AI 워크플로우의 힘

왜 AI Sidekick Workflow를 정리하게 되었나

지난 글에서는 FPJR 런칭 이후 AI를 활용해 실시간 모니터링 체계를 만든 경험을 공유했습니다. 목표는 명확했습니다.

“문제를 하루 뒤에 발견하는 것이 아니라, 30분 안에 발견하고 2시간 안에 대응할 수 있는 구조를 만들자.”

이번에는 모니터링 하나가 아니라, PM의 반복 업무 전반을 AI Sidekick 기반 workflow로 정리한 경험을 공유하려고 합니다.

PM 업무는 겉으로는 기획과 의사결정처럼 보이지만, 완성도 높은 프로덕트 피쳐를 딜리버리 하기 위해서는 실제로 아래의 작업이 반복됩니다.

• 요구사항 작성 전 데이터 확인

• SQL 기반 impact analysis

• Slack 논의 내용 정리

• Jira requirement와 Aceeptance Critera (AC) 작성

• 정책 변경 조건 검증

• UAT용 SQL 쿼리 생성

• A/B test 결과 재검증

• Slack/Jira를 통한 결과 공유

이 작업들은 반복적이지만 중요합니다. 데이터 확인이 부정확하면 requirement가 흔들리고, UAT 쿼리가 틀리면 배포 판단이 틀어지고, Slack 논의 맥락을 놓치면 구현 방향이 달라집니다.

그래서 목표를 "AI로 빠르게 초안을 만든다"가 아니라, "반복되는 PM 업무를 재현 가능한 AI-Native workflow로 만든다"로 잡았습니다.

"반복되는 PM 업무를 재현 가능한 AI-Native workflow로 만든다"

Sidekick Repo가 하는 역할

AI Sidekick은 저희 Tech Foundation Service (TFS)팀이 Github에 각 구성원의 AI-Native 워크플로우와 AI agent 사용을 위해 만들어 놓은 Sidekick 프로젝트 폴더(repo)를 로드하는 데에서 시작합니다. 저는 Cursor에서 이 Sidekick repo를 열고, 업무별 폴더와 Skills를 AI가 읽게 합니다.

일반적인 AI 사용은 매번 맥락 설명부터 시작합니다. 테이블의 의미, Jira 배경, Slack 논의, 정책 예외, 과거 실수까지 매번 다시 설명해야 합니다.

하지만 이 Sidekick repo는 이 반복 설명을 줄입니다. 업무 맥락, 실행 절차, 검증 조건, 과거 사례가 repo 안에 남아 있고, AI는 그 파일들을 읽고 같은 방식으로 작업을 재현합니다.

여기서 중요한 구성요소는 세 가지입니다.

1. CLAUDE.md: 업무별 실행 계약

Sidekick repo 안의 CLAUDE.md는 단순 소개 문서가 아닙니다. 해당 업무에서 AI가 어떤 역할을 해야 하는지, 어떤 파일을 먼저 읽어야 하는지, 어떤 작업은 승인 없이 하면 안 되는지 정의합니다.

예를 들어 정책 변경 workflow에서는 다음 규칙이 들어갑니다.

• Slack 논의와 Jira 승인 상태를 먼저 확인한다.

• 기존 설정과 충돌 여부를 확인한다.

• production 변경 전 PM 승인 gate를 둔다.

• UAT 방법과 결과 공유까지 마무리한다.

즉, CLAUDE.md는 AI에게 업무의 operating rule을 주는 파일입니다. 같은 요청이 반복될 때 결과 품질이 크게 흔들리지 않는 이유가 여기에 있습니다.

2. TFS 팀이 만든 공용 Skills

AI Sidekick이 실제 업무에 쓸 수 있는 이유는 TFS 팀이 만든 공용 Skills (a.k.a 클로드 스킬) 들이 있기 때문입니다.

대표적으로 다음 Skils들이 PM workflow의 기반이 됩니다.

• jupyter-sql: Athena 기반 SQL 실행과 데이터 검증

• jira-connector: Jira 조회, 생성, 업데이트, comment 작성

• slack-reader: Slack thread와 논의 맥락 읽기

• slack-writer: 분석 결과와 UAT 안내를 Slack에 posting

• Google 관련 skills: Sheets, Drive, Docs 등 외부 자료 조회와 정리

PM 입장에서는 이것이 중요합니다. AI가 텍스트만 생성하는 것이 아니라, 실제 업무 도구에 접근해 데이터를 읽고, 결과를 남기고, 커뮤니케이션까지 이어갈 수 있습니다.

3. Knowledge와 artifact

한 번 해결한 업무는 문서와 artifact로 남습니다.

• 분석 SQL

• impact analysis 결과

• UAT 쿼리

• Jira 작성 포맷

• Slack posting 예시

• 실패 원인과 재발 방지 메모

이 기록이 쌓이면 다음 업무는 처음부터 다시 시작하지 않습니다. 기존 사례를 읽고, 필요한 부분만 바꿔서 더 빠르게 재현합니다.

이 구조를 저는 일종의 harness engineering으로 보고 있습니다.

LLM 자체의 성능도 중요하지만, 실제 업무에서는 모델을 둘러싼 harness가 더 중요합니다. 어떤 맥락을 읽게 할지, 어떤 tool을 쓰게 할지, 어떤 순서로 검증할지, 어디서 사람 승인을 받을지, 결과를 어디에 남길지까지 설계해야 합니다.

Sidekick repo는 이 harness를 회사 업무에 맞게 구현한 형태입니다.

AI Workflow 원칙

최근 PM 업무를 AI Sidekick으로 정리하면서 네 가지 원칙을 두었습니다.

Step 1. 요청을 구조화한다

PM 요청은 보통 자연어로 시작합니다.

"지역 언어를 보여주면 conversion이 개선될까?"
"Application expiry 정책을 명확히 해야 할 것 같다."
"이 실험 결과를 rollout해도 되는지 다시 보고 싶다."

AI Sidekick은 바로 답을 만들지 않고, 먼저 가설, 성공 지표, 필요한 데이터, 대상 Jira, 최종 산출물로 나눕니다.

Step 2. 기존 맥락을 확인한다

AI가 테이블명, 정책 조건, 승인 상태를 추측하면 안 됩니다. workflow 안에서는 기존 문서, DDL, 과거 사례, Slack thread, Jira 상태를 먼저 확인합니다.

이 단계가 있어야 AI output이 실제 업무에 사용할 수 있는 수준이 됩니다.

Step 3. 숫자로 검증한다 (중요)

PM requirement는 의견이 아니라 근거가 필요합니다.

"영향이 클 것 같다"가 아니라, 몇 명의 사용자가 영향을 받는지, 어느 funnel에서 문제가 생기는지, 어느 segment에서 uplift가 재현되는지 확인합니다.

한 Cursor Session 안에서 AI모델이 산출한 결과를 검토하고 잘못된 부분이 있으면 수정요청을 합니다. 숫자의 정확성이 곧 비즈니스의 leverage인 핀테크 도메인에서 AI기반 결정 완전 자동화가 아직은 어려운 이유입니다. 이 과정을 여러번 티키타카 해서 근거의 완성도와 Projection의 정확도를 높여갑니다.

Step 4. 실행 가능한 산출물로 ‘닫는다’

분석 결과가 로컬 파일에만 있으면 업무가 끝난 것이 아닙니다. Jira requirement, AC, UAT 쿼리, Slack 공유문까지 만들어져야 조직이 움직일 수 있습니다.

AI Sidekick workflow의 끝은 항상 delivery입니다. 본질적으로 비결정적이고, 발산하기 쉬운 AI LLM모델 결과물을 닫힌계 (Closed System)로 잘 만드는 능력이 곧 AI-Native의 중요한 역량이라고 생각합니다. 따라서, 저는 아래와 같이 저만의 Closed System으로 AI-Native PM Workflow를 만들었습니다.

실제 적용 사례: PM 업무를 하나의 실행 흐름으로 묶기

제가 AI-Native workflow를 적용한 사례는 크게 네 가지로 정리할 수 있습니다. 공통점은 단순히 AI에게 초안을 맡긴 것이 아니라, 데이터 확인, 코드/정책 맥락 확인, Jira/Slack delivery까지 하나의 흐름으로 묶었다는 점입니다.

1. 데이터 기반 Requirement 작성

가장 많이 활용한 workflow는 데이터 기반 requirement 작성입니다.

Workflow:

[Human] 가설/성공 지표 정의 -> [AI] 서비스 codebase 확인 -> [AI] SQL로 business impact 확인 
-> [Human] 결과 해석 및 방향 결정 -> [AI] Requirement/AC 초안 작성 -> [Human] 최종 리뷰 
-> [AI] Jira ticket 생성 및 Slack 메시지 posting

예를 들어 Survey 화면에서 사용자 지역에 맞는 언어를 보여주면 conversion이 개선될 것이라는 가설이 있었습니다. 이때 바로 "지역 언어 지원 필요"라고 쓰지 않고, 먼저 아래를 확인했습니다.

• 어떤 위치 정보가 가장 안정적인가? KYC 기반 pincode가 맞는가, Geo 기반 pincode가 맞는가?

• 사용자 분포상 우선 지원해야 할 언어는 무엇인가?

• fallback이 필요한 지역은 얼마나 되는가?

• 실험군은 어떻게 나누어야 결과를 판단할 수 있는가?

그 결과 요구사항은 단순 기능 요청이 아니라, AI를 활용하여 business impact 측정을 위한 SQL작성을 자동화하고, 그 projection에 기반한 언어 결정 기준, fallback 조건, A/B test group 설계, 성공 지표, 검증용 SQL query를 포함한 실행 가능한 spec으로 바꾼 결과 입니다.

또 다른 예시인, Truebalance 금융상품 Application Expiry 정책도 비슷했습니다. 처음 문제는 "만료 정책이 모호하다"였습니다. AI Sidekick은 TrueBalance의 GitHub repo를 가져와 관련 정책이 녹아 있는 코드베이스를 확인했고, Jupyter skill과 예시 SQL을 활용해 실제 사용자 노출 규모와 금융상품 신청 후 오랫동안 오퍼 만료가 되지않은 application 후보를 확인했습니다. 그 결과 수십만 명 단위의 사용자 사례와 예외 케이스를 근거로 requirement를 작성할 수 있었습니다.

이 성과는 SQL 작성 시간을 줄인 것만큼 중요합니다. PM의 직관이 AI Sidekick으로 인해 데이터로 검증되고, 데이터가 바로 requirement와 acceptance criteria (AC)로 연결되는 흐름이 생겼기 때문입니다.

2. Dynamic Rule 을 안전하게 실행

어피닛 심사시스템의 핵심자산인 Dynamic Rule 변경은 빠르게 처리하는 것보다 배포 전에 안전하게 검증하고 Stakeholder간 승인을 받는 것이 중요합니다.

Workflow:

[AI] Slack/Jira 요구사항 확인 -> [AI] 기존 정책/설정 충돌 확인 -> [AI] 변경안 작성 
-> [Human] 변경안 승인 -> [AI] 비활성 상태로 production 반영 -> [Human] 수동 enable 
-> [AI] UAT 쿼리 생성 및 Slack handoff

기존에는 Slack 논의에서 최종 요구사항을 확인하고, Jira 승인 상태를 보고, 기존 설정과 충돌 여부를 확인하고,  Dynamic rule 시스템에 입력할 조건식을 작성하고, 문법을 검증하고, production 반영 후 UAT 쿼리와 결과 공유까지 각각 따로 처리해야 했습니다.

저는 Jira ticket에 남겨진 과거 Dynamic rule 변경 로그를 Context로 정의하였고, TFS팀이 정의해놓은 여러 Skills를 활용해 또 하나의 저만의 Skills (Dynamic Rule Changer)를 만들었습니다. 그리고 이 AI workflow가 Closed System으로 작동하기 시작했습니다. 특히 두 개의 ‘Human-in-the-loop’ gate를 둔 것이 핵심입니다.

• Gate 1: AI가 변경안을 정리하고, PM이 승인한다.

• Gate 2: production 반영은 기본적으로 비활성 상태로 만들고, 최종 enable은 PM이 직접 한다.

최근 실제 사례에서는 새로운 실험 구간을 추가하면서 25:75 test/control split을 적용해야 했습니다. AI Sidekick은 이 Skills (Dynamic Rule Changer)를 활용해 조건, 실험 비율, 충돌 여부, UAT 방법을 정리했고, PM 승인 후 production 반영과 Slack handoff까지 완료했습니다.

이 workflow의 가치는 속도보다 재현성입니다. 문법 오류, 중복 설정, 실험 비율 오류, UAT 누락 같은 실수를 줄이는 체크리스트가 실행 절차 안에 포함되었습니다.

3. A/B Test 분석에서 의사결정까지 연결

A/B test는 PM이 자주 보는 데이터지만, 해석은 단순하지 않습니다.

Workflow:

[Human] 의사결정 질문 정의 -> [AI] 실험 설정 의미 확인 -> [AI] 실제 배정 결과 확인 
-> [AI] Funnel/segment 성과 분석 -> [AI] 재현성 검증 -> [Human] Rollout 판단 
-> [AI] Jira/Slack 의사결정 공유

실험 설정이 여러 시스템에 나뉘어 있으면 같은 숫자라도 의미가 다를 수 있습니다. 어떤 값은 rollout rate이고, 어떤 값은 group ratio이고, 어떤 값은 전체 open rate일 수 있습니다. 그래서 A/B test workflow에서는 설정값의 의미를 먼저 확인하고, 실제 배정 결과와 funnel 결과를 함께 봅니다.

최근 Offer List화면에서 Bank Statement 제출 UX 실험에서는 12개 사용자 segment별로 기존 winner가 이후 기간에도 재현되는지 다시 확인했습니다. 일부 segment는 기존 uplift가 유지되었지만, 일부는 방향이 바뀌었습니다.

이 결과는 rollout 판단에 중요했습니다. 한 번의 winning result만 보고 전체 rollout을 결정하지 않고, segment별 재현성과 리스크를 같이 볼 수 있었기 때문입니다.

AI Sidekick workflow가 없었다면 기간 변경, segment 재계산, 결과 정리, Jira ticket 작성이 각각 별도 작업이었을 것입니다. 지금은 분석, 재검증, 추천안, Jira 작성까지 한 흐름으로 이어집니다.

4. 운영성 작업을 비즈니스 임팩트로 연결

최근 가장 임팩트가 컸던 사례 중 하나는 서비스 가능 지역 관련 이슈였습니다.

Workflow:

[Human] 사용자 blocking 이슈 제기 -> [AI] 외부/내부 데이터로 유효성 검증 -> [AI] 실제 blocking 기준 확인 
-> [AI] 반영 파일/Jira 준비 -> [AI] Business impact 산정 -> [Human] 반영 방향 승인 
-> [AI] Slack/Jira 공유

출발점은 단순했습니다.

특정 지역 사용자들이 서비스 이용 단계에서 막히고 있는데, 이걸 해결하면 어느 정도 비즈니스 임팩트가 있을까?

겉으로는 데이터 보정 작업이었지만, 실제로는 누락된 지역 정보가 유효한지, 사용자를 막고 있는 실제 기준이 무엇인지, 리뷰 가능한 안전한 반영 파일을 어떻게 만들지, 회복 가능한 비즈니스 임팩트가 어느 정도인지 확인해야 했습니다.

AI Sidekick은 외부 기준과 내부 데이터를 비교해 유효한 항목을 분류했고, 실제 blocking 기준을 확인했으며, 리뷰 가능한 반영 파일과 Jira 기록을 만들었습니다.

결과적으로 약 96.6%의 blocked-event volume을 커버할 수 있는 update가 정리되었고, 월 약 Rs. 4.8-7.8 cr 수준의 disbursement uplift 가능성을 추정했습니다.

여기서 핵심은 데이터를 빨리 정리한 것이 아니라, 운영성 작업을 사용자 영향과 매출 영향으로 번역했다는 점입니다. PM이 조직을 움직이려면 "데이터가 누락되었습니다"보다 "이 누락을 해결하면 어느 정도 사용자와 매출을 회복할 수 있습니다"라고 말할 수 있어야 합니다.

Slack Posting은 산출물이다

Slack posting은 단순 알림이 아닙니다. workflow의 마지막 산출물입니다.

분석 결과가 로컬 파일에만 있으면 실행으로 이어지지 않습니다. Jira에만 있으면 논의 속도가 느립니다. Slack thread에 decision, 근거, next action이 정리되어야 관련자가 같은 맥락에서 움직입니다.

그래서 AI Sidekick workflow에서는 Slack posting까지 포함합니다.

• 결정 내용

• 판단 근거

• 핵심 숫자

• 담당자별 next action

• UAT 또는 follow-up 방법

PM 생산성은 개인 작업 속도만으로 결정되지 않습니다. 분석과 판단이 조직 안에서 빠르게 전달되고 실행되어야 실제 생산성이 올라갑니다.

무엇이 개선되었나

AI Sidekick workflow를 쓰면서 개선된 부분은 네 가지입니다.

1. Context loading 비용 감소

매번 AI에게 배경을 설명하는 시간이 줄었습니다. 업무 맥락과 과거 사례가 repo에 남아 있어, 다음 작업은 기존 문서를 읽고 시작합니다.

2. 검증 누락 감소

데이터 확인, 승인 상태 확인, UAT 방법 정리, Slack 공유까지 workflow에 포함됩니다. 사람이 바쁠 때 놓치기 쉬운 체크리스트가 반복 실행됩니다.

3. 산출물 품질 개선

요구사항이 더 구체적으로 되었습니다. Impact Analysis, AC, UAT 방법, Slack 공유문이 같은 맥락에서 만들어지기 때문입니다.

4. 재사용 가능한 조직 지식 축적

한 번 해결한 문제는 문서와 artifact로 남습니다. 다음 업무에서는 같은 실수를 반복하지 않고, 기존 workflow를 수정해 재사용할 수 있습니다.

정리하면, AI Sidekick의 생산성은 "한 번 빨리 처리했다"가 아니라 "다음에도 더 안전하고 빠르게 처리할 수 있는 구조를 만들었다"에서 나옵니다.

PM에게 필요한 역량 변화

AI가 있다고 PM의 역할이 줄어드는 것은 아닙니다. 오히려 PM이 오너십을 가지고 더 명확히 해야 할 일이 생깁니다.

첫째, 문제를 정확히 정의해야 합니다.
AI는 답을 빠르게 만들 수 있지만, 어떤 문제가 중요한지는 PM이 정해야 합니다. 사용자가 어디서 막히는지, 그 문제가 매출/전환/리스크 중 무엇과 연결되는지, 해결했을 때 어떤 의사결정이 가능해지는지를 먼저 정의해야 합니다.

둘째, 검증 가능한 가설을 세워야 합니다.
"좋아질 것 같다"가 아니라 "어떤 사용자군에서, 어떤 행동 변화가, 어떤 지표로 확인되면 성공이라고 볼 것인가"까지 쪼개야 합니다. AI는 이 단계에서 과거 사례, 코드베이스, 데이터 구조, 유사 실험 결과를 빠르게 끌어와 가설을 더 정확하고 구체적으로 만드는 데 도움을 줍니다.

셋째, workflow를 설계해야 합니다.
한 번의 prompt가 아니라 반복 가능한 업무 절차를 만들어야 합니다.

넷째, AI 산출물을 검증해야 합니다.
SQL 결과가 맞는지, requirement가 비즈니스 의도를 담고 있는지, 실행이 안전한지 판단해야 합니다.

AI Sidekick은 PM이 모든 작업을 손으로 하지 않아도 되게 해줍니다. 대신 PM은 문제정의, 가설수립, 의사결정 기준 설정, 최종 판단에 더 집중하게 됩니다. AI는 이 단계를 대체한다기보다, 더 빠르고 넓은 근거를 바탕으로 더 정교하게 만들 수 있게 해줍니다.

마치며

이번 경험을 통해 확인한 것은 명확합니다.

AI 활용의 성과는 단순히 Chatgpt나 Claude Opus와 같은 LLM 모델 하나로 결정되지 않습니다. 실제 업무에서는 CLAUDE.md 같은 업무 지침, TFS 팀이 만든 공용 skills, 업무별 knowledge, 실행 artifact, human approval gate가 함께 있어야 합니다.

이 구성요소들이 있어야 AI가 단순히 답변을 생성하는 수준을 넘어, PM 업무를 재현 가능한 workflow로 실행할 수 있습니다.

저에게 AI Sidekick은 초안 작성 도구라기보다 PM 업무용 harness입니다. 데이터를 확인하고, 요구사항을 쓰고, 정책 변경을 검증하고, UAT와 Slack 공유까지 이어주는 실행 구조입니다.

앞으로도 분석, 요구사항 작성, UAT, 커뮤니케이션, A/B test 운영처럼 Product Manager의 업무에서 반복되는 PM Life Cycle를 AI Sidekick workflow로 정리하고, 성과가 확인된 사례를 계속 공유해보겠습니다.

마지막으로, 이렇게 AI Sidekick repo와 여러 공용 스킬로 AI-Native 업무환경을 만들어주신 Tech Foundation Service 팀에게 감사인사를 드립니다.

감사합니다.