# 이동원 (Dongwon Lee) — 포트폴리오 전문 핀테크·결제 8년+, EV충전 플랫폼 PO. 경력 16년차. 전략·데이터·운영을 잇고, 필요한 도구는 AI로 직접 만드는 빌더형 PO. - 현재: 스칼라데이터 플랫폼팀 총괄 PO - 연락: webn77@gmail.com - GitHub: https://github.com/webn77 - LinkedIn: https://www.linkedin.com/in/%EB%8F%99%EC%9B%90-%EC%9D%B4-31456348 - 갱신: 2026-08-10 - 원본 데이터: https://2dw.pages.dev/data/projects.json · https://2dw.pages.dev/data/projects-detail.json · https://2dw.pages.dev/data/ai-tech.json ## 경력 - **스칼라데이터** (2024 – 현재) — 플랫폼팀 총괄 PO - **컬리페이** (2022 – 2024) — 컬리캐시 & 상품권 PO - **코나아이** (2018 – 2022) — 백오피스기획 팀장 - **펜타브리드 · 메가존** (2012 – 2018) — 서비스 기획·운영 PM - **코엑스 · 더스토리 인스퍼레이션 · 럼퍼스** (2009 – 2012) — 웹·커머스 기획 ## 학력 - 명지대학교 기록정보과학전문대학원 — AI정보과학전공 석사 과정 재학 - 명지대학교 — 소프트웨어공학과 학사 졸업 ## 전문 분야 프로덕트 오너십, 핀테크·결제, 선불전자지급수단, EV충전 플랫폼, 지역화폐, 데이터 기반 의사결정, AI 자동화, RAG, LLM 백오피스, 백오피스·어드민 설계, 정산, B2G 공공 프로젝트 ## 실무 프로젝트 (29건) ### [S1] 모두의충전 고객 세그먼트 재설계로 EV 충전 매출 20% 성장 - 소속: 스칼라데이터 · 기간: 2024.05 – 2025.12 · 도메인: EV충전 플랫폼 - 역할: 총괄 PO · 디자이너 2명 · 개발 5명 - 요약: 충전 결제 데이터를 기반으로 고객 행동을 5개 세그먼트로 분류하고, 가격 정책과 퍼널 운영 전략을 재설계해 매출 성장으로 연결했습니다. - 개요: 모두의충전에서 이용량이 많은 고객이 곧 수익 고객이라는 가정을 데이터로 뒤집고, 타겟 기준을 바꿔 타임특가 전략을 재설계했습니다. 적립 비용은 줄이고, 충전 결제 매출 60억 이상 — 전년 대비 20% 성장. - 많이 쓰는 고객이 곧 수익 고객은 아니었습니다 - 고액 충전자들이 반드시 수익 고객은 아니었습니다 - '많이 쓰는 고객'이 아니라, 마진이 높은 충전기를 반복 이용하는 고객에 집중했습니다 - 적립은 줄이고, 유입 효율이 높은 혜택에 집중했습니다 - 적립을 줄였는데 결제는 늘었고, 손익이 흑자로 돌아섰습니다 - 할인은 첫 방문을 만들지만, 재방문을 만드는 건 동선입니다 - 성과 유형: 매출성장, 비용·효율 - 태그: 데이터분석, 세그먼트, 타임특가, 그로스 ### [S2] 스프린트 도입으로 장애를 80% 줄인 운영 체계 개선 - 소속: 스칼라데이터 · 기간: 2024.05 – 2024.06 · 도메인: EV충전 플랫폼 - 역할: 총괄 PO · 디자이너 2명 · 개발 5명 · 마케팅 3명 - 요약: 기능 배포와 장애 대응이 뒤섞인 운영 방식을 2주 스프린트와 4주 배포 체계로 전환해, 예측 가능한 개발·운영 구조를 만들었습니다. - 개요: 운영 불안을 구조 문제로 정의하고, 배포·협업 체계를 재설계해 장애를 월 5건 이상에서 1건 이하로 줄인 프로젝트입니다. - 시스템은 돌아가고 있었지만, 팀은 점점 지쳐가고 있었습니다 - 문제의식은 있었지만, 실행 기준이 없었습니다 - 투명한 운영은 복잡한 관리가 아니라, 예측 가능한 상태를 만드는 일이었습니다 - 문제마다 맞는 장치를 연결해 운영 방식을 재설계했습니다 - 운영 안정화는 장애와 CS, 그리고 협업 방식까지 바꿨습니다 - 완벽한 프로세스보다 먼저 지켜지는 약속이 더 중요합니다 - 성과 유형: 조직·프로세스 - 태그: 조직, 스프린트, 협업, 배포안정성 ### [S3] 모두의충전 어드민 플랫폼 재설계로 개발 기간 절반 단축 - 소속: 스칼라데이터 · 기간: 2024.07 – 2024.09 · 도메인: 백오피스·어드민 - 역할: 총괄 PO · 개발 2명 - 요약: 기능 추가마다 의존성이 꼬이던 레거시 어드민을 역할 기반 권한과 모듈 구조로 재설계해, 확장 가능한 내부 운영 플랫폼으로 개선했습니다. - 개요: 모두의충전 기존 어드민의 구조적 한계를 인정하고, 개발자들이 이미 만들어 쓰던 비공식 버전을 공식화해 신규 어드민을 구축한 프로젝트입니다. - 공식 시스템보다 비공식 도구가 더 많이 쓰이고 있었습니다 - 팀이 필요한 것은 이미 만들어져 있었습니다 - 이미 실무에서 검증된 흐름을 공식 체계로 전환했습니다 - 모듈화와 권한 체계, 두 가지에 집중했습니다 - 신규 기능 개발 기간이 절반으로 줄었습니다 - 기술 부채를 가장 잘 아는 건 매일 그 시스템을 쓰는 사람입니다 - 성과 유형: 비용·효율 - 태그: 어드민, 백오피스, 기술부채, 모듈화 ### [S4] 모두의충전 포인트 정책 재설계로 부채 2억 절감과 재방문 개선 - 소속: 스칼라데이터 · 기간: 2024.10 – 2024.12 · 도메인: 포인트·멤버십 - 역할: 총괄 PO · 디자이너 1명 · 개발 2명 - 요약: 소멸되지 않는 포인트가 재무 부채로 쌓이던 구조를 유효기간 이원화와 소멸 전환 사이클로 개선해 비용 절감과 재방문을 함께 만들었습니다. - 개요: 포인트 유효기간이 없던 구조에서 미사용 포인트는 부채로 쌓이고, 고객은 포인트의 존재 자체를 잊고 있었습니다. 이원화 정책과 알림톡 리텐션 고리를 설계해 포인트 부채 2억 원을 줄이고, 포인트 내역 페이지 재방문을 기존 대비 2배로 끌어올렸습니다. - 무제한 포인트가 오히려 이탈을 만들고 있었습니다 - 포인트가 '잊혀지는' 이유를 찾았습니다 - 단순하게 시작하는 것이 핵심이었습니다 - 알림을 리텐션 고리로 설계했습니다 - 부채가 줄고, 고객이 돌아왔습니다 - 제약은 트리거가 됩니다 - 성과 유형: 비용·효율 - 태그: 포인트, Lock-in, 리텐션, 알림톡 ### [S9] BMW 브랜드 전용 EV 충전 앱 기획·완성 - 소속: 스칼라데이터 · 기간: 2024.10 – 2025.02 · 도메인: EV충전 플랫폼 - 역할: 제작 PM · 서비스 기획 · 디자이너 2명 · 개발 3명 - 요약: BMW 브랜드 기준과 국내 충전 인프라 연동 요구를 함께 반영하며, B2B 파트너사와 내부 개발 제약을 조율해 폐쇄형 전용 앱을 완성했습니다. - 개요: BMW 브랜드에 맞는 충전 경험과 앱 이미지를 다시 설계해, 전용 앱다운 완성도를 높인 프로젝트입니다. - BMW 고객이 사용하는 앱이지만, 경험은 BMW답지 않았습니다 - 문제는 기능 몇 가지가 아니라, 앱의 역할 자체가 브랜드 기대에 맞지 않았다는 점이었습니다 - 앱을 단순한 충전 도구가 아니라, BMW 고객을 위한 전용 경험으로 다시 정의했습니다 - 충전 경험과 브랜드 경험이 앱 안에서 자연스럽게 이어지도록 구조를 바꿨습니다 - 브랜드 경험과 핵심 흐름을 함께 정비해, BMW 측 높은 만족도로 오픈했습니다 - 프리미엄 브랜드 앱은 기능보다 먼저, 어떤 경험을 전달해야 하는지부터 정의해야 합니다 - 성과 유형: 0→1 구축 - 태그: 파트너십, B2B, 프리미엄브랜드, 폐쇄형앱 ### [S5] 모두의충전 전기차 구독서비스 0→1 런칭 - 소속: 스칼라데이터 · 기간: 2025.01 – 2025.03 · 도메인: 구독·모빌리티 - 역할: 총괄 PO · 정책 및 플로우 설계 · 디자이너 2명 · 개발 2명 - 요약: 전기 중고차 구독 시장이 비어 있다고 판단해 0→1로 진입했습니다. 비대면 계약·인수·반납 프로세스를 직접 설계해 60대 운영, 월 1억 수익 모델을 만들었습니다. - 개요: 충전 단건 수익에서 벗어나 전기 중고차 구독이라는 신사업을 0에서 만들었습니다. 예상과 다른 고객층이 왔지만, 그것을 오히려 성장 경로로 삼아 60대 운영·월 1억 수익 구조를 만든 프로젝트입니다. - 전기 중고차 구독 시장은 비어 있었습니다 - 예상한 고객이 오지 않았습니다 - 예상과 달랐지만, 온 고객이 오히려 더 잘 맞는 고객이었습니다 - 비대면 전 과정을 앱 안에서 처리했습니다 - 0에서 월 1억 수익 구조를 만들었습니다 - 먼저 시작하고, 실제 수요를 따라가야 합니다 - 성과 유형: 0→1 구축, 수익화 - 태그: 구독, 신사업, 0→1 ### [S10] 전국 3,000대 환경부 공공급속충전기 프로그램 통합·UI 리뉴얼 - 소속: 스칼라데이터 · 기간: 2025.03 – 2025.12 · 도메인: B2G·공공 - 역할: 프로젝트 PM · 서비스 기획 · 개발 3명 · 디자이너 1명 - 요약: 제조사 4곳·9개 모델로 분산된 충전기 프로그램을 단일 소스로 통합하고, 30대 선행 설치 후 국가 B2G 감리를 통과했습니다. - 개요: 전국 8천여 대 중 최근 5년 내 설치된 3,000대를 대상으로, 제조사별로 갈라져 있던 충전기 프로그램을 단일 소스로 통합했습니다. 화면 하나 고치는 것도 공지 하나 내보내는 것도 경로가 제각각이던 구조를, 무공해차 누리집을 통해 한 번에 배포할 수 있는 체계로 바꿨습니다. - 기능 하나를 바꾸려면 같은 작업을 여러 번 반복해야 했습니다 - 기술보다 어려운 건 합의였고, 운영자 관점은 또 달랐습니다 - 합의의 기준을 회의실이 아니라 현장과 데이터로 옮겼습니다 - 구조를 통합하고, 충전 흐름을 더 직관적으로 개선했습니다 - 선행 설치를 안정적으로 마무리하고, 후속 통합 유지보수 사업의 기반을 만들었습니다 - 현장에 답이 있었고, 그 답을 반영할 구조가 필요했습니다 - 성과 유형: 비용·효율 - 태그: 공공, 표준화, B2G, 단일소스 ### [S12] 개발팀 없이, AI로 법인용 EV충전카드 신사업을 PO 혼자 완성 - 소속: 스칼라데이터 · 기간: 2026.07 – 2026.07 · 도메인: EV충전 플랫폼 - 역할: PO — 기획·프론트엔드·QA 단독 수행 · 디자이너·프론트엔드 없음 · 백엔드 1명(API 개발) - 요약: 법인 EV충전 카드관리라는 신사업을, 시장 데이터 분석부터 화면설계(51개 화면)·프로토타입·프론트엔드 개발·QA에 사업소개서(16p)까지 AI를 활용해 PO 혼자 완성해 정식 오픈했습니다. 백엔드 API는 화면 단위로 규격을 정의해 내부 개발자에게 요청했고, 개발된 API를 받아 연동했습니다. - 개요: 법인 전기차 충전카드 관리 서비스 모두페이Biz를 인터랙티브 화면설계서·클릭형 프로토타입·프론트엔드 개발·QA에 사업소개서까지, 전 과정을 AI를 활용해 직접 진행해 정식 오픈한 프로젝트입니다. 백엔드 API는 제가 화면 단위로 규격을 정의해 요청하고 내부 개발자가 개발해 제공했으며, 화면·이슈·API·테스트를 1:1로 추적하는 문서 체계를 직접 만들었습니다. - 계정 하나에 충전카드 한 장, 법인은 차량별로 관리할 방법이 없었습니다 - 기존 모두의충전을 들여다보니, 법인 회원이라는 개념 자체가 없었습니다 - 법인 계정 아래 여러 장의 카드를 묶는 구조로 다시 설계했습니다 - 시장조사·PRD부터 기획서·프로토타입·디자인·개발·검증까지, 공정 순서대로 진행했습니다 - 설계부터 개발·사업소개서까지 직접 완성해 정식 오픈했습니다 - 내부용 도구는 화려함이 아니라, AI로 얼마나 빨리 검증하느냐가 경쟁력입니다 - 성과 유형: 0→1 구축 - 태그: B2B, 전기차충전카드, API규격, AI개발 ### [S6] 모두의충전 현대·KT 멤버십 포인트 전환으로 누적 1억 달성 - 소속: 스칼라데이터 · 기간: 2025.05 – 2025.06 · 도메인: 포인트·멤버십 - 역할: 총괄 PO · 서비스 기획 30% · 디자이너 1명 · 개발 2명 - 요약: 현대블루멤버스·KT 멤버십 포인트를 자사 플랫폼으로 전환하는 API 연동과 파트너십을 주도해, 새로운 충전 결제 전환 흐름을 만들었습니다. - 개요: 모두의충전 앱에서 새 제휴사를 별도 경로로 만들지 않고 고객이 매달 하던 포인트 전환 습관 안에 넣어, 6개월 만에 누적 전환금 1억을 만든 프로젝트입니다. - 제휴사를 각각 연결하는 방식이 당연해 보였지만, 고객 경험은 그렇지 않았습니다 - 답은 새로운 기능보다, 이미 반복되고 있는 고객 습관 안에 있었습니다 - 새 행동을 만들지 않고, 이미 하던 행동 안에 넣었습니다 - 한 번의 탭으로 두 포인트를 함께 전환하는 구조를 만들었습니다 - 고객 행동을 줄이자, 전환금이 실제로 커졌습니다 - 제휴사가 늘 때는 새 경로를 만들지 말고, 하던 행동 안에 넣어야 합니다 - 성과 유형: 수익화 - 태그: 포인트통합, 파트너십, CI인증 ### [S7] 모두의충전 검색 개선으로 충전소 선택률 5배 - 소속: 스칼라데이터 · 기간: 2025.07 – 2025.08 · 도메인: EV충전 플랫폼 - 역할: 총괄 PO · 디자이너 1명 · 개발 2명 - 요약: 검색 이후 90%가 이탈하던 구간을 퍼널로 확인하고, 고객이 실제로 쓰는 장소 키워드와 거리 기반 정렬로 검색을 다시 설계해 선택률을 5배 높였습니다. - 개요: 모두의충전 앱에서 검색을 한 고객의 90%가 충전소를 고르지 못하고 이탈하고 있었습니다. 고객이 실제로 쓰는 검색어와 거리 기준에 맞춰 검색을 다시 설계해 선택률을 5배 높인 프로젝트입니다. - 검색을 한 고객의 90%가 충전소를 고르지 못하고 나갔습니다 - 고객이 찾는 방식과 모두의충전이 보여주는 방식이 달랐습니다 - 시스템이 정한 방식이 아니라, 고객이 찾는 방식에 맞췄습니다 - 검색 로직을 고객 탐색 패턴에 맞게 재설계했습니다 - 검색이 선택으로 이어졌습니다 - 고객은 시스템의 언어가 아니라 자기 언어로 찾습니다 - 성과 유형: 전환 개선 - 태그: UX, 검색, 퍼널, Mixpanel ### [S8] 미납 인지·지급 경로 재설계로 미납 잔액 절반 이하로 - 소속: 스칼라데이터 · 기간: 2025.01 – 2025.12 · 도메인: 지급결제 - 역할: 총괄 PO · 디자이너 1명 · 개발 2명 - 요약: 결제 실패를 고객이 알 방법이 없어 쌓이던 미납을, 인지 경로와 지급 방법을 단계별로 바꿔 잔액 2,000만 원대에서 900만 원대로 낮추고 증가 구조를 감소 구조로 되돌렸습니다. - 개요: 결제가 실패해도 고객이 알 방법이 거의 없어 미납이 쌓이고 있었습니다. 알림 채널을 늘리는 데서 그치지 않고 미납 상태별로 인지 경로를 나누고, 마지막에는 입금 자체를 쉽게 만들어 잔액을 2,000만 원대에서 900만 원대로 되돌린 프로젝트입니다. - 고객이 미납을 알 방법이 거의 없었습니다 - 알림을 늘렸지만 효과는 크지 않았습니다 - 미납 상태에 따라 인지 경로가 다르다는 걸 확인했습니다 - 인지 경로와 지급 방법을 단계별로 바꿔나갔습니다 - 늘어나던 미납이 줄어드는 구조로 바뀌었습니다 - 미납은 안 내는 게 아니라, 모르거나 내기 어려워서 남습니다 - 성과 유형: 비용·효율 - 태그: 미납관리, 알림톡, SMS, 세그먼트, 운영자동화 ### [K1] 온보딩 50% 단축, PO 협업 체계 0→1 구축 - 소속: 컬리페이 · 기간: 2022.05 – 2022.07 · 도메인: 지급결제 - 역할: PO · 서비스기획 · 기획 2 · 개발 3 - 요약: 빠르게 성장하는 조직에서 PM 역할과 프로세스가 명확하지 않아 협업 혼선이 반복됐습니다. 협업 체계와 온보딩 문서를 처음부터 설계해 팀 운영 기반을 만들었습니다. - 개요: 팀 규모가 3배로 커지는 과정에서 협업 기준을 구조로 만들고, 온보딩 기간을 50% 단축한 프로젝트 - 팀은 커지고 있었지만, 일하는 방식은 제각각이었습니다 - 문제는 사람이 아니라, 기준이 없다는 점이었습니다 - 사람이 아니라 구조를 바꾸는 방식으로 접근했습니다 - 보고, 회의, 온보딩 전반에 반복 가능한 기준을 만들었습니다 - 온보딩 기간은 절반으로 줄었고, 팀이 커져도 운영은 흔들리지 않았습니다 - 빠르게 성장하는 조직일수록, 기준은 나중이 아니라 먼저 필요합니다 - 성과 유형: 조직·프로세스 - 태그: 조직, 프로세스, 협업 ### [K2] 이탈률 25% 줄인 간편결제 인앱 인증 설계 - 소속: 컬리페이 · 기간: 2022.08 – 2022.09 · 도메인: 지급결제 - 역할: PO · 서비스기획 · 기획 1 · 개발 1 · 외부 솔루션 - 요약: 결제 중 외부 인증 앱으로 넘어가는 구간에서 이탈이 집중됐습니다. 인앱 인증 구조를 설계해 이탈 구간을 줄이고, 대형 이벤트 상황에서도 안정적으로 운영했습니다. - 개요: 회원인증·카드등록·계좌등록 흐름 전반을 설계하고, 인앱 인증 구조로 이탈을 줄여 결제 전환율을 높인 프로젝트 - 간편결제를 도입하려면, 먼저 등록 흐름부터 매끄러워야 했습니다 - 문제는 인증 하나가 아니라, 등록 흐름 전체가 결제 맥락에 맞지 않는다는 점이었습니다 - 기능 연동보다, 등록 경험을 먼저 설계했습니다 - 회원인증부터 카드·계좌 등록까지, 등록 흐름 전반을 가이드했습니다 - 등록 이탈은 줄고, 결제 전환은 높아졌습니다 - 간편결제의 성패는 기능 도입보다, 등록 흐름을 얼마나 매끄럽게 설계하느냐에 달려 있습니다 - 성과 유형: 전환 개선 - 태그: 간편결제, 인증, UX ### [K3] 금감원 심사 통과, 선불전자지급수단 라이선스 취득 - 소속: 컬리페이 · 기간: 2022.09 – 2022.12 · 도메인: 선불충전·전자금융 - 역할: 컬리캐시 PO · 라이선스 및 정책 설계 - 요약: 컬리캐시를 법적 선불전자지급수단으로 운영하기 위해 금감원 인허가가 필요했습니다. 실무 심사 시연과 컴플라이언스 설계를 직접 수행해 라이선스 취득에 기여했습니다. - 개요: 컬리캐시를 결제 수단으로 쓸 수 있도록 선불전자지급수단 라이선스를 취득하고, 포인트·캐시 정책과 핵심 프로세스 설계까지 완료해 선불금 플랫폼의 기반을 만든 프로젝트 - 기능보다 먼저, 선불금을 가능하게 하는 구조가 필요했습니다 - 라이선스 취득과 함께, 포인트와 캐시의 경계를 어떻게 설계할지도 중요했습니다 - 재원이 다르고, 고객이 인식하는 방식도 다르기 때문에 지갑을 분리했습니다 - 인허가와 서비스 설계를 병행하며, 선불금 운영에 필요한 핵심 프로세스를 이 시점에 모두 준비했습니다 - 라이선스 취득에 그치지 않고, 컬리 선불금 플랫폼의 운영 기반까지 함께 만들었습니다 - 금융 서비스는 비슷해 보여도, 경계를 먼저 분명히 해야 혼란이 줄어듭니다 - 성과 유형: 규제·인증 - 태그: 규제, 인허가, 핀테크 ### [K4] 모바일상품권 B2B·B2C 동시 런칭, 성장 기반 구축 - 소속: 컬리페이 · 기간: 2023.05 – 2023.12 · 도메인: 상품권·커머스 - 역할: 컬리캐시 & 상품권 PO · 서비스 기획 전담 · 개발 2명 · 디자이너 1명 · 브랜드 디자이너 1명 · 기획자 1명(백오피스) - 요약: 컬리캐시 유통 채널 확장을 위해 모바일상품권 서비스를 처음 설계했습니다. B2B 발급 인프라와 B2C 구매 플로우를 동시에 구축해 상품권 사업의 성장 기반을 만들었습니다. - 개요: 상품권 인프라를 직접 내재화해, B2B·B2C를 아우르는 선물 경험과 임직원 복지 시장 첫 런칭까지 만든 프로젝트 - 선불전자지급수단 라이선스는 확보했지만, 이를 더 많은 고객이 실제로 사용하게 만들 확장 수단은 없었습니다 - 외부 솔루션으로는 B2B와 B2C에 같은 경험을 주기 어려웠습니다 - 같은 선물 경험을 만들려면, 인프라부터 직접 가져와야 했습니다 - 상품권 번호 엔진부터 선물 전달 플로우까지 직접 설계했습니다 - 첫 런칭은 작게 시작했지만, 이후 확장의 기반이 됐습니다 - B2B와 B2C에 같은 경험을 주려면, 속도보다 구조가 먼저입니다 - 성과 유형: 0→1 구축 - 태그: 0→1, 상품권, B2B ### [K6] 온·오프라인을 연결한 컬리 실물상품권 0→1 구축 - 소속: 컬리페이 · 기간: 2024.01 – 2024.05 · 도메인: 상품권·커머스 - 역할: 컬리캐시 & 상품권 PO · 서비스 기획 전담 · 개발 2명 · 디자이너 1명 · 브랜드 디자이너 1명 · 기획자 1명(백오피스) - 요약: 디지털 상품권의 오프라인 선물 경험 한계를 보완하기 위해 실물상품권 서비스를 기획했습니다. 모바일·실물 잔액 통합 구조와 QR 기반 오프라인 플로우를 설계했습니다. - 개요: 모바일상품권 인프라 위에 실물 카드 선물 경험을 확장하기 위해 런칭을 추진하고, 오프라인 배송 품질의 한계를 실데이터로 확인한 프로젝트 - 선물 경험은 모바일보다 실물이 더 강할 수 있다고 봤습니다 - 실물 상품권은 공정마다 원가가 쌓이는 구조였습니다 - 마진이 아니라 CAC 관점으로 보니 판단이 달라졌습니다 - 원가 산정부터 물류 연동까지, 처음 다루는 오프라인 공정을 직접 설계했습니다 - 런칭은 완료했지만, 오프라인 경험의 한계를 분명하게 확인했습니다 - 실물 서비스는 마지막 접점까지 함께 설계해야 합니다 - 성과 유형: 0→1 구축 - 태그: 실물상품권, O2O, 오프라인 ### [K5] 1년 만에 판매량 5.7배, 컬리캐시 1억 달성 - 소속: 컬리페이 · 기간: 2024.01 – 2024.05 · 도메인: 상품권·커머스 - 역할: 컬리캐시 & 상품권 PO · 데이터 분석 및 운영 전략 · 개발 2명 · 디자이너 1명 · 브랜드 디자이너 1명 · 기획자 1명(백오피스) - 요약: 단기 이벤트로는 팔리지 않았습니다. 고객이 반드시 들르는 마이페이지에 상품권을 고정으로 노출하고 상품권 카테고리를 새로 만들어, 장보기 전 충전이라는 습관을 만들었습니다. - 개요: 출시 후 거의 팔리지 않던 상품권을, 단기 이벤트 대신 고객이 원래 다니는 동선 위에 고정 노출하고 구매 습관까지 만들어 1년 만에 판매량 5.7배로 키운 프로젝트 - 출시는 했는데, 거의 팔리지 않았습니다 - 단기 이벤트를 계속 돌렸지만, 끝나면 제자리였습니다 - 노출을 늘리는 대신, 고객이 원래 다니는 길을 봤습니다 - 고객 동선 위에 고정으로 놓고, 새로운 동선을 만들었습니다 - 외부 홍보 없이도 1년 만에 판매량 5.7배를 만들었습니다 - 노출을 늘리는 게 아니라, 고객이 이미 다니는 길 위에 놓아야 합니다 - 성과 유형: 매출성장 - 태그: 그로스, 데이터분석, 할인정책 ### [C1] 운영 인력 그대로, 앱 10개→30개 확장한 CMS 설계 - 소속: 코나아이 · 기간: 2018.03 – 2018.05 · 도메인: 백오피스·어드민 - 역할: 백오피스 기획 · 기획 1 · 개발 2 - 요약: 지역화폐 앱이 늘어날수록 개별 운영 부담이 커지는 구조였습니다. 공통 CMS를 표준화해 동일 인력으로 3배 많은 앱을 안정적으로 운영하는 체계를 만들었습니다. - 개요: 지역화폐 앱이 10개에서 30개로 확대되는 상황에서, 인력 추가 없이 3배 규모를 소화할 수 있도록 CMS 운영 구조를 표준화하고 재설계한 프로젝트 - 앱마다 규격이 달라, 운영자가 지금 무엇을 편집하는지 직관적으로 알기 어려웠습니다 - 앱이 늘어날수록 운영 비용이 그대로 따라 늘어나는 구조였습니다 - 앱 수가 늘어나도 운영 방식은 늘어나지 않도록, 공통 규칙으로 묶어야 했습니다 - 표준화, 일괄 처리, 실수 방지 장치를 함께 설계했습니다 - 앱은 3배로 늘었지만, 운영 인력은 그대로 유지됐습니다 - 규모가 커질 것이 분명하다면, 인력보다 먼저 시스템을 바꿔야 합니다 - 성과 유형: 비용·효율 - 태그: CMS, 운영효율, 내부시스템 ### [C2] 기명·무기명 통합 선불충전금 체계 구축 - 소속: 코나아이 · 기간: 2018.06 – 2018.07 · 도메인: 선불충전·전자금융 - 역할: 백오피스 기획 · 기획 1 · 개발 2 - 요약: 기명·무기명 충전금이 별도 구조로 운영되며 상품 확장에 한계가 있었습니다. 단일 구조로 통합 설계해 다양한 카드 기반 상품으로 확장할 수 있는 기반을 만들었습니다. - 개요: 기존 회원 중심 선불충전금 구조를 재설계해, 기명·무기명 카드를 단일 시스템에서 처리할 수 있게 만든 프로젝트 - 기존 구조로는 무기명 선불카드 상품을 만들 수 없었습니다 - 기명과 무기명을 따로 만들면, 운영 비용도 두 배가 되는 구조였습니다 - 기명과 무기명을 다른 시스템이 아니라, 충전금 귀속 주체가 다른 하나의 구조로 봤습니다 - 선불충전금 로직을 카드 단위까지 확장하고, 운영 도구도 함께 설계했습니다 - 무기명 카드 상품 출시를 가능하게 했고, 이후 카드 기반 상품 확장의 기반이 됐습니다 - 인프라는 지금 요청된 기능보다, 그 위에 올라올 다음 비즈니스를 보고 설계해야 합니다 - 성과 유형: 규제·인증 - 태그: 선불충전금, 핀테크, 내부시스템 ### [C3] 수동 운영을 셀프로 전환한 B2B 복지포인트 포털 구축 - 소속: 코나아이 · 기간: 2018.08 – 2018.10 · 도메인: 포인트·멤버십 - 역할: 백오피스 기획 · 기획 1 · 디자인 1 · 개발 2 - 요약: 파트너사 복지포인트 운영 요청마다 내부 대응이 필요한 구조였습니다. 파트너가 직접 설정할 수 있는 포털을 설계해 운영 부담 없이 관계사를 확산할 수 있도록 만들었습니다. - 개요: 기업 및 자회사를 대상으로 사원증 연동 복지포인트 서비스와 B2B 통합 관리 포털을 신규 구축한 프로젝트 - 복지 서비스를 운영하고 싶어도, 운영할 수 있는 도구가 없었습니다 - B2B의 핵심은 기업 담당자가 독립적으로 운영할 수 있느냐였습니다 - 운영팀이 아니라 기업 담당자가 직접 굴릴 수 있는 구조를 먼저 만들기로 했습니다 - 파트너 포털부터 사원증 카드 제작까지, 운영 구조 전반을 직접 설계했습니다 - 수동 관리를 셀프 운영 구조로 전환하고, 전사 및 외부 기업 도입까지 이어졌습니다 - B2B 서비스에서는 Admin UX와 자동화 수준이 곧 경쟁력입니다 - 성과 유형: 비용·효율 - 태그: B2B, 복지포인트, 파트너포털 ### [C4] 가맹점 모바일 쿠폰·정산 백오피스 0→1 구축 - 소속: 코나아이 · 기간: 2018.11 – 2018.12 · 도메인: 백오피스·어드민 - 역할: 백오피스 기획 · 기획 1 · 디자인 1 · 개발 2 - 요약: 가맹점에 디지털 쿠폰 혜택을 제공하기 위해 발급부터 정산까지 새로 설계했습니다. 시스템은 완성했지만 실제 채택으로 이어지지 않아 기능과 사용 사이의 간극을 확인했습니다. - 개요: 포인트 리워드만 있던 플랫폼에 가맹점 모바일 쿠폰 기능을 새로 구축하며, 시스템 완성과 실제 사용은 다르다는 점을 확인한 프로젝트 - 가맹점은 프로모션을 하고 싶었지만, 쓸 수 있는 도구가 없었습니다 - 가맹점마다 원하는 방식이 달라, 맞춤 개발로는 확장할 수 없었습니다 - 가맹점마다 따로 만들지 않고, 조합 가능한 모듈 구조로 바꿨습니다 - 가맹점 모바일 쿠폰 기능과 정산 구조를 함께 구축했습니다 - 시스템은 완성됐지만, 실제 사용은 기대에 미치지 못했습니다 - 기능은 만들어지는 것보다, 효과가 보일 때 비로소 사용됩니다 - 성과 유형: 0→1 구축 - 태그: 쿠폰, 가맹점, 디지털전환 ### [C5] 경기도 31개 지자체를 연결한 지역화폐 플랫폼 설계 - 소속: 코나아이 · 기간: 2019.01 – 2019.04 · 도메인: 선불충전·전자금융 - 역할: 백오피스 기획 · 기획 2 · 디자인 2 · 개발 5 - 요약: 지자체마다 다른 정책과 운영 규칙을 하나의 플랫폼에서 처리해야 했습니다. 멀티테넌시 구조로 설계해 현재까지 핵심 구조가 유지되는 지역화폐 플랫폼 기반을 만들었습니다. - 개요: 31개 지자체의 서로 다른 정책을 하나의 플랫폼에서 운영할 수 있도록 다중 포인트 시스템을 설계해, 현재까지 코나아이 지역화폐 서비스의 핵심 구조로 유지되고 있는 플랫폼을 기획한 프로젝트 - 31개 지자체의 서로 다른 정책을 하나의 플랫폼에 담아야 했습니다 - 지자체별로 따로 대응하면, 운영 비용도 지자체 수만큼 늘어나는 구조였습니다 - 정책을 코드에 고정하지 않고, 운영에서 바꿀 수 있는 구조로 전환했습니다 - 다중 포인트를 카드 단위로 설계하고, 우선순위를 설정할 수 있는 구조로 만들었습니다 - 국내 최대 규모 지역화폐 플랫폼이 안착했고, 설계 구조는 지금까지 유지되고 있습니다 - 정책이 자주 바뀌는 플랫폼일수록, 운영자가 직접 바꿀 수 있는 구조가 중요합니다 - 성과 유형: 0→1 구축 - 태그: B2G, 지역화폐, 멀티테넌시 ### [C6] 전사 데이터 저장소·통계 시스템 0→1 구축, 4개 부서 셀프 조회 전환 - 소속: 코나아이 · 기간: 2019.05 – 2019.08 · 도메인: 백오피스·어드민 - 역할: 백오피스 기획 · 기획 1 · 개발 2 - 요약: 데이터가 필요할 때마다 개발팀에 요청하던 구조로 의사결정이 느려졌습니다. 부서별 셀프 조회 통계 시스템을 구축해 반복적인 데이터 요청을 없앴습니다. - 개요: 회원 가입부터 카드 배송, 결제 트랜잭션까지의 사용자 여정을 수치화해 전사가 셀프로 조회할 수 있는 통합 데이터 분석 시스템을 기획한 프로젝트 - 결제 볼륨은 빠르게 커지는데, 데이터를 직접 볼 수 있는 곳은 없었습니다 - 운영 DB에서 바로 뽑는 방식은 빠르지만, 결제 안정성을 해칠 수 있었습니다 - 운영 DB를 건드리지 않고, 통계 전용 저장소를 따로 만드는 방향으로 정리했습니다 - 부서 인터뷰로 필요한 데이터를 먼저 정의하고, 셀프 조회 가능한 구조로 설계했습니다 - 개발팀 데이터 요청은 사라졌고, 4개 부서가 셀프 조회로 전환됐습니다 - 사람들이 진짜 원한 것은 예쁜 차트보다 직접 꺼내 볼 수 있는 데이터였습니다 - 성과 유형: 0→1 구축, 비용·효율 - 태그: 데이터분석, 내부도구, 운영효율 ### [C7] 개발 없이 신규 제휴 세팅 가능한 리워드 시스템 구축 - 소속: 코나아이 · 기간: 2019.08 – 2019.11 · 도메인: 포인트·멤버십 - 역할: 백오피스 기획 · 기획 1 · 디자인 1 · 개발 2 - 요약: 제휴사가 추가될 때마다 개발이 필요한 구조라 확장이 어려웠습니다. 어드민에서 정책을 직접 설정하는 구조를 설계해 인천 이음 오픈을 시작으로 제휴 확산 기반을 만들었습니다. - 개요: 외부 제휴사 포인트를 플랫폼 내 결제 잔액으로 전환할 수 있도록 정책을 수립하고, 신규 제휴처가 늘어나도 개발 없이 대응할 수 있는 통합 관리 구조를 만든 프로젝트 - 제휴 요청은 들어오는데, 건별 개발로는 확장할 수 없었습니다 - 제휴처 하나만 봐도 정책 항목이 많아, 표준화 없이는 확장이 어려웠습니다 - 제휴 정책을 코드에 고정하지 않고, 운영에서 설정할 수 있는 구조로 바꿨습니다 - 정책 설정부터 정산 리포트까지, 제휴 운영 전반을 직접 설계했습니다 - 인천 이음 오픈에 성공했고, 이후 제휴 확장을 위한 기반을 만들었습니다 - 제휴 비즈니스는 기능보다 먼저, 유연한 정책 설정 구조가 있어야 확장됩니다 - 성과 유형: 비용·효율 - 태그: 제휴, 마일리지, 파트너십 ### [C8] 결제 자동 적립 연동 스탬프 서비스 구축 - 소속: 코나아이 · 기간: 2020.01 – 2020.02 · 도메인: 포인트·멤버십 - 역할: 백오피스 기획 팀장 · 기획 1 · 개발 2 - 요약: 가맹점 재방문을 유도하기 위해 결제와 스탬프 적립을 자동 연동하는 서비스를 기획했습니다. C4와 마찬가지로 가맹점 채택의 어려움을 다시 확인한 프로젝트였습니다. - 개요: 지역화폐 결제 데이터와 실시간 연동해 자동으로 스탬프가 적립되는 서비스를 구축했지만, 기능 제공만으로는 고객 행동이 바뀌지 않는다는 점을 확인한 프로젝트 - 쿠폰과 포인트만으로는 재방문 고객을 만들기 어려웠습니다 - 기존 스탬프 서비스는 많았지만, 소상공인이 계속 쓰기 어려운 구조였습니다 - 결제가 일어나는 순간 자동으로 적립되도록 설계했습니다 - 결제 연동 자동 적립 로직부터 가맹점 관리 사이트까지 함께 설계했습니다 - 서비스는 안정적으로 런칭됐지만, 고객 사용률은 기대에 못 미쳤습니다 - 기능을 만드는 것과, 고객이 실제로 쓰게 만드는 것은 다른 문제입니다 - 성과 유형: 0→1 구축 - 태그: 스탬프, 리텐션, 가맹점 ### [C9] 5개 이상 지자체로 확산된 지류상품권 시스템 구축 - 소속: 코나아이 · 기간: 2020.05 – 2020.11 · 도메인: B2G·공공 - 역할: 백오피스 기획 팀장 · 기획 1 · 디자인 1 · 개발 3 - 요약: 디지털 전환이 어려운 지역의 실물 상품권 수요에 대응했습니다. 발급부터 재고·정산 관리까지 처음 설계해 5개 이상 지자체로 확산되는 표준 인프라를 만들었습니다. - 개요: 레퍼런스도 전담자도 없는 상황에서, 지류상품권 유통 전 과정을 제로베이스로 정립하고 번호 단위 이력 추적 시스템을 구축해 코나아이 지류상품권 표준 인프라를 만든 프로젝트 - 지류상품권 시스템을 만들어야 했지만, 사내에 아는 사람이 아무도 없었습니다 - 프로세스가 없는 상태에서는 시스템부터 만들 수 없었습니다 - 책상이 아니라 현장에서 먼저 확인하고, 번호 단위 검증을 원칙으로 세웠습니다 - 운영 프로세스를 먼저 정립하고, 그 위에 보안과 추적 구조를 얹었습니다 - 초기부터 안정적으로 운영됐고, 이후 지류상품권 확산의 표준 인프라가 됐습니다 - 현장 시스템은 현장에서부터 설계해야 합니다 - 성과 유형: 0→1 구축 - 태그: 실물상품권, 재고관리, 0→1 ### [C10] 200만 건 VOC 최소화로 완수한 재난지원금 시스템 - 소속: 코나아이 · 기간: 2021.01 – 2021.03 · 도메인: B2G·공공 - 역할: 백오피스 기획 팀장 · 기획 2 · 개발 3 · 디자인 1 - 요약: 짧은 기간 안에 대규모 지급을 처리해야 하는 공공 프로젝트였습니다. 이중 승인 구조와 예외 케이스를 사전에 정의해 오류와 민원을 최소화하며 완수했습니다. - 개요: 경기도 재난지원금 지급을 위해 200만 건 이상의 신청 트래픽을 수용하고, 예외 케이스를 사전에 정의해 대규모 지급을 안정적으로 운영한 공공 프로젝트 - 200만 건이 넘는 재난지원금 지급을 안정적으로 처리해야 했고, 오지급은 최대한 막아야 하는 상황이었습니다 - 코나아이 내부에는 이 정도 규모의 공공 지원금 지급을 처리한 경험이 없었습니다 - 문제가 생긴 뒤 수습하는 것보다 처음부터 오지급이 발생하지 않도록 구조를 만드는 것이 먼저였습니다 - 지자체 담당자, 개발팀, 사업팀과 협업하며 운영자가 실수할 수 있는 지점을 하나씩 줄여 나갔습니다 - 200만 건이 넘는 재난지원금 지급 업무를 큰 혼선 없이 안정적으로 완수했습니다 - 2중, 3중 검증은 느린 방식이 아니라, 가장 빠르고 안전한 운영 방식이었습니다 - 성과 유형: 비용·효율 - 태그: 공공, 대규모, 예외처리 ### [C11] 등록 50%·정산 60% 줄인 가맹점 정산 통합 - 소속: 코나아이 · 기간: 2021.02 – 2021.04 · 도메인: 지급결제 - 역할: 백오피스 기획 팀장 · 기획 1 · 개발 2 - 요약: 매입사마다 별도로 가맹점을 등록하고 정산하는 구조로 운영 부담이 컸습니다. 다중 매입사를 1회 통합 등록·처리하는 구조로 재설계해 운영 효율을 높였습니다. - 개요: 다중 매입사 환경에서 파편화된 가맹점 데이터를 통합하고, 정산과 운영을 하나의 기준으로 관리할 수 있게 만든 프로젝트 - 같은 가맹점이 시스템 안에 2개, 많게는 3개의 레코드로 나뉘어 존재하고 있었습니다 - 매입사별로 관리하는 구조에서는, 문제가 반복될 수밖에 없었습니다 - 매입사가 아니라, 가맹점을 기준으로 묶어야 했습니다 - 가맹점 통합 기준과 정산 구조를 함께 설계했습니다 - 가맹점 등록 시간은 줄고, 정산과 운영은 훨씬 단순해졌습니다 - 데이터가 흩어지는 문제는 운영의 문제가 아니라, 관리 기준의 문제입니다 - 성과 유형: 비용·효율 - 태그: 정산, 다중매입사, 표준화 ### [C12] 초기 설계 그대로 쓰던 백오피스를 다시 기획한 차세대 프로젝트 - 소속: 코나아이 · 기간: 2021.05 – 2021.12 · 도메인: 백오피스·어드민 - 역할: 차세대 백오피스 내부 PM · PM 1명 · 기획자 3명(외주) - 요약: 사업 초기에 만든 백오피스에 기능만 계속 붙으면서, 승인 절차도 화면 템플릿도 없이 손대기 어려운 시스템이 돼 있었습니다. 운영과 개발의 효율을 올리기 위해 내부 PM으로 재설계를 주도해 구현의 기준을 만들었습니다. - 개요: 사업 초기에 만든 백오피스에 기능만 계속 붙어 복잡해진 상태를, CMS·정산·복지·상품권·데이터까지 4년간 직접 설계해 온 경험을 바탕으로 다중 매입사와 늘어난 거래량을 전제로 다시 기획한 프로젝트 - 초기 설계에 없던 요구가 계속 붙으면서, 손대기 어려운 시스템이 됐습니다 - 기능을 더 붙이는 방식으로는 따라갈 수 없었습니다 - 요청 목록이 아니라, 실제 업무 흐름부터 다시 봤습니다 - 운영과 개발, 양쪽의 효율을 기준으로 다시 설계했습니다 - 개발 착수 직전까지, 기획서 6종으로 나눠 설계를 끝냈습니다 - 4년간 붙여 온 것을 처음부터 다시 기획해 본 시간이었습니다 - 성과 유형: 조직·프로세스 - 태그: 차세대, 백오피스, 전사리뉴얼 ## 직접 만든 AI 도구 (23종) ### [AT-24] ModuFlow — Claude·Codex 어디서나 동일하게 쓰는 플러그인형 AI 업무관리 도구 - 분류: 이슈 기반 하네스 · 상태: 운영중 - 설명: 직접 다 만들지 않고 검증된 도구를 조합했습니다. 스펙 정리는 GitHub Spec Kit, 실행·검증은 오픈소스 Superpowers를 그대로 쓰고, 목표·실행·완료 전 과정은 깃(Git) 파일로 남겨 세션이 끊겨도 이어갈 수 있게 만들었습니다. 플러그인 구조로 만들어서 Claude·Codex 양쪽에 설치 한 번이면 똑같이 동작합니다. - 태그: Git-native, 플러그인, Spec Kit, Superpowers, Claude·Codex ### [AT-23] AI 에이전트를 위험한 업무에 써도 되는지 — 기업이 빠르게 검증하는 PoC 가드레일 - 분류: 바이브코딩 · 상태: 운영중 - 설명: 환불·결제 같은 고위험 업무에 AI를 안전하게 쓰는 가드레일 엔진입니다. AI는 할 일만 고르고(Tool Calling), 실행 허용은 사람이 정한 규칙이 금액·권한에 따라 자동 승인·검토·차단합니다. LangGraph·RAG·MCP로 구현하고 검증 데이터(골든셋 30건)로 정확도를 수치 검증했으며, 일부만 바꾸면 금융·의료 등 다른 분야에도 적용됩니다. - 태그: LangGraph, RAG, MCP, Tool Calling, RAGAS, risk_gate, Python ### [AT-19] POKit — AI 작업을 이슈 단위로 관리하는 PO 운영 도구 - 분류: 이슈 기반 하네스 · 상태: 운영중 - 설명: AI가 만드는 작업을 채팅 기록에 흘려보내지 않고, 이슈 카드 → 스프린트 → 검증 게이트 → 세션 인계로 관리하는 Issue-Driven OSS. v1 Linear 연동 한계 → v2 로컬 자립으로 전환. Codex·Claude 런타임 지원(Antigravity 호환 준비중). - 태그: OSS, AI Harness, Codex, Claude, Node.js ### [AT-21] 품질 관리 & 검증 게이트 — AI의 "완료"를 믿지 않는다 - 분류: 이슈 기반 하네스 · 상태: 운영중 - 설명: AI는 똑똑해도 빠뜨림이 구조적으로 생긴다. 그래서 ①만든 AI가 자기 일을 통과시키지 못하게 작업과 검증을 다른 에이전트로 나누고, ②완료를 7가지 각도(품질 7계층)로 검증하도록 표준화했다. 은행 송금처럼 — 말이 아니라 검증이 끝을 정한다. - 태그: AI Harness, 품질관리, 검증 게이트, doctor, 표준화 ### [AT-8] 병렬 서브에이전트 — 이슈 단위로 goal을 두고 워커를 배분해 동시 실행 - 분류: 이슈 기반 하네스 · 상태: 운영중 - 설명: Spec-Driven(기능 명세 우선)으로 시작했지만, AI를 병렬로 활용하려면 기능 하나를 여러 이슈로 나누고 이슈마다 역할별 워커를 배정해 동시에 처리하는 Issue-Driven으로 전환해야 했습니다. 이슈에 goal(완료 기준)을 선언하면 역할별 워커들이 각자 담당 결과물을 제출하고, 지휘자(main_session)가 통합·완료 검증을 담당합니다. Claude Swarm 칩·Codex Thread 등 각 도구의 병렬 기능을 직접 활용하며, 멀티세션 구조로 런타임이 바뀌어도 이어집니다. - 태그: Subagents, Parallel, Issue-Driven, Model Routing, Git Worktree ### [AT-17] LLM이 운영자처럼 내부통제하는 백오피스 — 터미널 운영 CLI까지 직접 제작 - 분류: 바이브코딩 · 상태: 실험중 - 설명: LLM이 백오피스를 더 쉽게 만들고, 자연어로 운영하고, 내부통제까지 맡게 한 실험입니다. 자연어 조회·실시간 감시·개인정보 보호·역할별 권한 차등·터미널 운영이 운영자와 똑같은 하나의 권한 검사를 통과합니다. - 태그: NestJS, Next.js, Prisma, RBAC, CLI, MCP, Monorepo ### [AT-15] AI 기반 A/B 테스트 자동화 - 분류: 이슈 기반 하네스 · 상태: 운영중 - 설명: 설계 대안을 병렬로 실행하고 결과를 자동 분석해 최적안을 선택하는 의사결정 시스템 - 태그: Claude API, Shell ### [AT-14] 백로그 자동화 & 스프린트 실행 시스템 - 분류: 이슈 기반 하네스 · 상태: 운영중 - 설명: RICE 점수 기반 우선순위 자동 책정 → 스프린트 활성화 → 기획·구현·배포까지 AI가 단독 완주하는 애자일 파이프라인 - 태그: Claude API, Shell, Python ### [AT-2] 세션·채널 연속성 — 매번 다시 설명하지 않는 AI 작업 기억 - 분류: 개인 AI OS · 상태: 운영중 - 설명: 세션이 끊기거나 기기가 바뀌어도 "어디까지 했지"를 다시 설명할 필요가 없습니다. 진행 중인 작업·다음 액션·맥락을 파일 하나(checkpoint.json)에 모으고, Git으로 데스크탑·모바일·텔레그램 봇이 같은 상태를 바라봅니다. 세션이 시작되면 이 파일을 한 번 읽는 것으로 곧바로 이어집니다. AI를 '매번 처음부터 설명하는 도구'가 아니라 '맥락을 이어받는 동료'로 만든 사례입니다. - 태그: Claude API, Shell, Git ### [AT-20] 스킬 운영 — 많이 써보고 핵심만 남겨 워크플로우로 묶기 - 분류: 개인 AI OS · 상태: 운영중 - 설명: AI 작업을 스킬로 표준화하며 외부 스킬까지 수십 개를 써봤지만 '많다고 좋은 게 아니다' — 정말 쓰는 것만 남기고, 가져온 외부 스킬은 내 환경에 맞게 고치고, 개별 호출 대신 spec 워크플로우로 묶었습니다. 도구 과부하 연구와도 같은 결론입니다. - 태그: Skill Ops, Workflow, Claude Code, Eval·최적화, Python/Shell ### [AT-16] Episodic 회고 메모리 — 같은 실수를 반복하지 않는 자기 개선 시스템 - 분류: 이슈 기반 하네스 · 상태: 운영중 - 설명: Shinn et al.(2023) Reflexion 방법론을 1인 AI OS 운영에 적용. 회고 항목을 자동 분류해 다음 세션 컨텍스트(checkpoint.json)와 영구 규칙 메모리(feedback memory 105건)로 적재 — 같은 실수가 반복되지 않는 구조. (작업 컨텍스트는 Context Engineering / 누적 위키 지식은 장기 기억 위키) - 태그: Claude API, Shell, Memory ### [AT-6] 장기 기억 위키 — 같은 문제를 두 번 풀지 않는 지식 누적 - 분류: 개인 AI OS · 상태: 운영중 - 설명: AI와 일하며 얻은 결정·노하우·반복 패턴을 옵시디언에 마크다운으로 쌓는 장기 기억입니다. 글마다 분류·요약 같은 메타데이터를 붙이고 관련 문서끼리 링크로 엮어, 다음에 비슷한 문제를 만나면 키워드 한 번으로 과거 결정을 찾아 재활용합니다. 한 번 정리한 지식을 매번 다시 설명하지 않게 만드는 사례입니다. - 태그: Claude API, Obsidian, Markdown, Git ### [AT-11] 디자이너 없이, 미리 만든 디자인 규칙으로 일관된 산출물을 자동 생성 - 분류: 생산성 자동화 · 상태: 운영중 - 설명: 색·폰트·간격 같은 디자인 규칙과 자주 쓰는 컴포넌트(버튼·카드·표)를 design.md 한 곳에 정리해두고 재사용합니다. 매번 새로 디자인하지 않아도 기획 한 줄이면 톤이 통일된 웹페이지·문서·대시보드가 나오고, 디자이너 없이 계약서·견적서·포트폴리오까지 같은 품질로 만듭니다. - 태그: Claude API, HTML/CSS, Shell ### [AT-10] 흩어진 시스템 현황을 한 화면에 — 직접 만든 1인 운영 대시보드 - 분류: 바이브코딩 · 상태: 운영중 - 설명: AI 자동화와 직접 만든 도구가 늘면서 현황 파악 자체가 일이 됐습니다. 시스템 상태·진행 작업·지식 문서·세션 기록을 매시간 자동으로 한곳에 모아, 한 화면에서 30초에 파악하도록 직접 만든 대시보드입니다. 사람이 보는 화면과 AI가 읽는 데이터가 같은 소스라 따로 관리할 필요가 없습니다. - 태그: Claude API, n8n, HTML, Python ### [AT-9] 데이터 수집·분석 자동화 — 퍼널로 CAC·LTV와 병목까지 진단 - 분류: 생산성 자동화 · 상태: 운영중 - 설명: 모두의충전·황금거위(앱테크)·차량구독 3개 서비스 데이터를 매일 자동 수집합니다(Google Ads·Facebook API·Supabase 연동 등). 유입→설치→가입→결제 퍼널을 구성해 CAC·LTV와 매체 효율을 계산하고, 어느 단계에서 병목이 생기는지 찾아 UI 개선으로 연결합니다. 수집·가공·배포는 플레이북으로 자동화하고, 팀은 Slack에서 핵심 지표를 셀프 조회합니다. - 태그: HTML, JavaScript, Chart.js ### [AT-7] 서비스 지표·전사 KPI 통합 관리 자동화 - 분류: 생산성 자동화 · 상태: 운영중 - 설명: GA4·Ads·Mixpanel·Datadog·내부 DB를 Google Sheets로 통합 저장 후 이상치·결측치 전처리를 거쳐 Claude Code가 기간별 지표를 분석. 서비스 지표부터 전사 KPI까지 주간 리뷰용 리포트가 자동 발송되어 PO가 매번 데이터를 끌어모으지 않아도 됩니다. - 태그: GA4, Mixpanel, Google Sheets, Claude Code, Python ### [AT-4] AI·EV·경제 뉴스 일일 브리핑 자동화 — 요약을 넘어 인사이트까지 - 분류: 생산성 자동화 · 상태: 운영중 - 설명: AI·EV·경제 뉴스를 26개 출처에서 매일 자동 수집·요약하고, 단순 요약을 넘어 '오늘 무엇에 주목해야 하나'를 인사이트로 정리합니다. 흩어진 뉴스를 매일 같은 구조로 받아, 정보 수집은 자동화하고 판단에 집중하는 일일 브리핑 파이프라인. - 태그: n8n, Claude API, Python ### [AT-18] AI 운영 모니터 — 비용·속도 측정과 문제 자동 진단 - 분류: 개인 AI OS · 상태: 운영중 - 설명: AI로 작업할 때 비용(사용량)·응답 속도·효율이 실제로 어떤지 자동으로 측정합니다. 기준을 넘으면 무엇이 문제인지(세션이 너무 길다·효율이 낮다 등)를 스스로 진단하고, 어떻게 고치면 무엇이 좋아지는지까지 알려줍니다. '느린 것 같다'는 감이 아니라 숫자로 AI 운영을 관리한 사례입니다. - 태그: Python, Dashboard, Observability, Token Analytics, LLMOps ### [AT-5] 긴 포트폴리오를 읽지 않아도 — 질문하면 경력을 찾아 답하는 AI 챗봇 - 분류: 바이브코딩 · 상태: 운영중 - 설명: 채용담당자가 긴 포트폴리오를 직접 뒤지지 않아도 경력과 프로젝트를 자연어로 바로 탐색하는 검색형 챗봇입니다. 질문하면 미리 정리해둔 포트폴리오 문서를 찾아 답하고(검색 후 정리, RAG 방식), 로컬 임베딩 + 무료 LLM 조합으로 API 비용 0원, 서버·접속 주소 자동 복구로 무중단 운영합니다. 포트폴리오를 읽는 문서에서 질문하는 도구로 전환. - 태그: RAG, Groq, Chroma, FastAPI ### [AT-13] AI Evals — 스킬 회귀 방지 시스템 - 분류: 개인 AI OS · 상태: 운영중 - 설명: 스킬이 30개를 넘으며 "어제 되던 게 오늘 안 되는" 문제가 잦아졌습니다. 스킬마다 "이 입력엔 이 기능이 떠야 한다"는 기준을 정해두고, 고칠 때마다 자동 검사해 미리 막습니다. - 태그: Claude API, Python, Shell ### [AT-3] 멀티모델 & 토큰 최적화 설계 - 분류: 개인 AI OS · 상태: 운영중 - 설명: Haiku·Sonnet·Opus·Codex 역할 분리로 비용과 설계 품질을 함께 잡는 멀티모델 파이프라인 - 태그: Claude API, Gemini API, Python, Shell ### [AT-1] 하네스 설계 기반 AI 자동화(Hook) - 분류: 개인 AI OS · 상태: 운영중 - 설명: AI 실행 규칙을 지시가 아닌 이중 통제 구조(실행 권한 + 자동 감시)로 강제하는 환경 설계 - 태그: Claude API, Shell, Python ### [AT-22] EV 손익 계산기 — 전기차 살까 말까를 데이터로 답하다 - 분류: 바이브코딩 · 상태: 운영중 - 설명: 전기차 vs 내연차 손익분기점(TCO)을 계산하는 모바일 웹앱. 명지대 대학원 과제로 React+Supabase 풀스택·DB 설계·회원 인증·배포까지 단독 완주. - 태그: React, Supabase, TypeScript, Chart.js, PWA