발표자 소개
가비아에서 8년째 서비스 기획/PM으로 일하고 있습니다. 13만 고객사가 쓰는 협업 플랫폼 하이웍스의 메신저·드라이브·일정·모바일 앱 등 핵심 솔루션을 기획하고 운영해 왔습니다. 2025년 MCP 기반 AI 에이전트 PoC로 AI 서비스 기획을 시작했고, 2026년 AI전략개발팀에 합류해 사내 AI 실험실과 고객사 관리자용 하이웍스 AI 관리 콘솔을 기획했습니다.
회사 밖에서는 점심 메뉴 지도 앱 '밥지도'를 혼자 만들고 운영합니다. 커뮤니케이션 디자인 전공을 살려 기획과 디자인은 직접 하고, 구현은 AI 코딩 에이전트에게 맡겨 iOS App Store에 공개했습니다. 코드를 직접 쓰지 않는 대신, AI가 낸 결과를 무엇을 근거로 받아들일지 정하는 일을 가장 많이 고민해 왔습니다.
세션 정보
AI 에이전트가 ‘완료’라고 할 때 무엇을 믿어야 할까 — GitHub PR 리뷰까지 에이전트에게 맡긴 기획자의 점검표 4가지
AI 코딩 에이전트에게 PR 검토와 병합, 운영 확인까지 맡기면, 사람은 무엇을 근거로 ‘완료’를 받아들여야 할까요?
저는 코드를 직접 쓰지 않는 8년차 서비스 기획자입니다. 전국 1,600곳이 넘는 한식뷔페·구내식당을 지도에 올리고, 매일 달라지는 점심 메뉴를 날짜와 함께 보여주는 앱 '밥지도'를 만들었습니다. 기획과 디자인은 제가 하고, 개발·배포·운영은 AI 코딩 에이전트(Claude Code, Codex)가 맡아 70일 만에 iOS App Store에 공개했습니다.
처음에는 에이전트가 올린 GitHub PR과 Actions 결과를 제가 직접 확인했습니다. 하지만 작업 속도를 사람이 따라갈 수 없게 되면서, 지금은 그 확인까지 에이전트에게 맡기고 있습니다. 개발자에게는 무모해 보일 수 있는 선택입니다. 그래서 제 일은 코드를 읽는 것에서, 무엇을 ‘완료’의 근거로 삼을지 정하는 것으로 바뀌었습니다.
이 세션에서는 그 기준을 만든 실제 사건 네 가지를, 각 사건에서 얻은 점검 항목과 함께 소개합니다.
- 완료 조건 — 특정 외부 수집 경로에 기대는 부분을 걷어 낸 깔끔해 보이는 변경이, 영업 중인 식당 5곳을 메뉴 수집 대상에서 빼 버렸습니다. 그 뒤로 성공 기준을 '작업이 끝났는가'가 아니라 '사용자가 오늘 메뉴를 볼 수 있는가'로 정했습니다.
- 확인 근거 — GitHub Actions 품질 검사도, 서비스가 정상 응답하는지 보는 운영 점검도 모두 통과했는데 앱에는 갱신되지 않은 메뉴가 나가고 있었습니다. 그 뒤로 '응답했다'와 '최신 메뉴가 나갔다'를 따로 확인하도록 검사를 바꿨습니다.
- 판단 권한 — GitHub Actions 무료 사용량을 지키려고, 사용량을 확인할 수 없으면 작업을 멈추는 예산 장치를 두었습니다. 그런데 에이전트가 미리 등록하지 않고 돌린 1분짜리 실험 하나 때문에 이 장치가 그날 첫 메뉴 공개와 백업까지 멈췄습니다. 그 뒤로 에이전트가 스스로 해도 되는 일과 실행 전에 등록해야 하는 일을 나눴습니다.
- 인계 기록 — 이전 대화를 기억하지 못하는 새 세션의 에이전트가, 이미 바로잡은 판단을 다시 사실처럼 인용한 일이 있었습니다. 정정 내용을 저장소에 기록하고, 그 정정 기록이 문서에서 지워지면 테스트가 실패하게 만들었습니다.
사건마다 제가 내린 판단과 에이전트가 진단·구현한 부분을 나누고, 각 장치가 확인해 주는 것과 확인해 주지 못하는 것도 함께 짚습니다.
AI 에이전트에게 코드 작성을 넘어 리뷰·배포·운영 확인까지 맡기고 있거나 맡기려는 개발자와 PM께, 다음 작업을 맡길 때 그대로 옮겨 쓸 수 있는 점검표 네 가지(완료 조건·확인 근거·판단 권한·인계 기록)를 드립니다.
세션 시간과 장소는 추후 안내합니다.