운영 시스템
-
정책과 사양을 나눈 뒤 무엇이 덜 되돌아왔나 — Called Up 문서 체계 적용기
Called Up의 결정론적 커리어, 국적 UX, 문구 규칙, 수익화 공정성, 웹과 iOS 배포 경계를 일곱 개념으로 나눠 기록합니다. 속도를 수치로 주장하는 대신, 변경과 리뷰와 QA가 어느 층으로 되돌아왔는지 살펴봅니다.
-
작업이 끊겨도 처음부터 다시 하지 않는 법 — 에이전트 인계와 재개의 구조
Called Up과 Project Whisper의 실제 작업을 바탕으로, 긴 에이전트 작업을 중단 뒤에도 안전하게 재개하는 인계 문서의 구조를 정리합니다.
-
에이전트 팀의 작업 큐는 왜 작아야 하나 — 컨텍스트와 비용을 같이 관리하는 법
AI 에이전트 팀이 빨라질수록 작업을 더 많이 넣고 싶어져요. 하지만 큐가 커지면 컨텍스트, 검토 비용, 완료 기준이 함께 흐려집니다. KoalStudio가 작업 큐를 작게 유지하는 이유와 운영 기준을 정리합니다.
-
프로젝트가 늘어날수록 기억을 섞지 않는 법 — 지식존과 정본의 경계
좋은 기억은 모든 것을 한곳에 쌓는 일이 아니에요. AsterDuck의 역사적 도메인과 현재 WineDuck, Called Up, Project Whisper를 분리해 운영하며 정리한 지식존과 도메인 우선 검색 규칙을 소개해요.
-
에이전트가 셋이면 대답도 셋이어야 할까 — 다중 에이전트 팀의 말하기 규칙
KoalStudio의 공동 작업면에서 요청자·담당 에이전트·검토자·관찰자의 발언권을 어떻게 나눴는지 정리해요.
-
셀러를 관리한다는 것 — WineDuck 심층 리포트
와인 셀러를 '관리한다'는 건 보관, 흐름, 분포, 의사결정 네 차원의 운영이에요. WineDuck이 그 네 차원을 어떻게 모델링하고, 외부 AI 스킬로 어디까지 위임하는지 깊게 풀어봅니다.
-
마지막 게이트는 사람이에요 — 에이전트 산출물의 QA를 PO가 어디서 잡나
에이전트가 빠르게 일을 처리할수록 마지막 검증의 위치가 중요해져요. 결과/과정/외부 영향의 세 축으로 산출물을 검증하고, 게이트를 어디에 둘지 네 기준으로 정리합니다.
-
에이전트 팀의 evaluation — 시스템이 살아있다고 말할 수 있는 기준
1인 PO와 에이전트 팀을 1년 굴리면서 만든 측정 지표를 정리합니다. '에이전트가 일을 잘하는가'가 아니라 '시스템이 무너지지 않고 있는가'를 보는 다섯 개의 차원.
-
주말에 서비스 하나 완성 — PO 1명과 에이전트 팀의 사케덕 48시간
기획서부터 PRD 배포까지 48시간. PO 1명과 에이전트 팀이 사케 테이스팅 서비스를 만든 과정을 시간순으로 정리합니다.
-
PO 1명이 기획팀이 되는 법 — 에이전트 팀으로 기획 프로세스를 자동화한 이야기
PO가 매일 하는 일을 해부하고, 그중 무엇을 에이전트에게 넘길 수 있는지 고민한 과정을 정리합니다.
-
서비스를 설계할 때, '정책'과 '사양'을 구분하지 못하면 생기는 일
시스템, 정책, 비즈니스 로직, 서비스, 인터페이스, UI 로직, 사양. 이 개념들이 왜 따로 존재하는지, 구분하지 않으면 실무에서 어떤 일이 생기는지를 정리합니다.
-
AI가 앱을 만들어준다고요? 진짜 문제는 그 다음이에요 — 개인화 소프트웨어의 공급망
소프트웨어를 만드는 건 AI가 해줘요. 하지만 굴리는 건 다른 문제예요. PaSelf와 BaaS라는 두 개념으로, 개인화 소프트웨어의 공급망 구조를 정리합니다.
-
그 얘기 했던 것 같은데… — 결과를 남기는 협업 구조
결과가 흩어져서 협업이 느려지는 팀을 위해, '결과함→지식 저장소→공식 문서' 3단 구조로 기록을 자산으로 만드는 방법.
-
회의 0번, 일 34개를 끝내는 법 — 사람<>에이전트 협업 프로세스 구축하기
KoalStudio는 사람 1명과 AI 팀원 6명으로 일해요. 회의 없이 하루 만에 34개 작업을 마감할 수 있었던 건, AI가 똑똑해서가 아니라 운영 규칙을 먼저 만들었기 때문이에요.