1인 토이 프로젝트 개발을 오래 해왔다. 아이디어가 떠오르면 바로 만들었고, 혼자 설계하고, 혼자 구현하고, 혼자 배포했다. 문제는 “혼자”라는 단어에 있다. 혼자 만들면 그 제품에는 오롯이 내 관점만 들어간다. 내가 필요하다고 생각하는 기능, 내가 좋다고 생각한 방식에 갖히게 된다. 아무도 “그게 정말 필요해?”, “사용자가 잘 쓸 수 있어?”라고 지적하지 않는다.

결과적으로 나만 이해하는 제품이 탄생하고 아무도 쓰지 않는다.

이런 식으로 쌓여가는 토이 프로젝트가 많아졌다. AI로 생산성이 올라간 지금. 내 컴퓨터에 시체 더미가 쌓여가고 있다. AI에게 리뷰를 받아도 사실 AI는 내가 강한 어조로 말해버리면 그걸 그대로 이행한다. 그게 나쁜 방식이던 좋은 방식이던 상관없이 말이다. “AI는 우리를 편향주의 감옥에 가둔다” 라는 글을 기고했던 것 처럼 AI는 내가 별도로 지시하지 않으면 나의 관점과 나의 생각을 편협하게 가둬버린다.

팀을 만들자

bmad-method 라는 프로젝트를 봤다. AI에게 역할을 부여해서 팀처럼 일하게 만드는 전략이다. 팀에서 일하면 많은 사람들의 생각을 들어볼 수 있다. 함께 고민해서 만들면 내가 생각하지 못했던 것에 대해서 인사이트를 얻을 수 있고 더 견고한 제품을 만들 수 있게 된다. bmad 메서드를 깊이 사용하진 못했지만 솔직히 말하자면 토이 프로젝트에 적용하기엔 불필요하게 복잡하고 과했다. 설정해야 할 것이 많고, 구조가 무겁다.

내가 원하는건 단순하게 내 생각 + 보완 + 빠른 실행 + 고품질 코드 + 컨텍스트 유지 뿐이었기 때문에 이를 아주 간소화한 형태로 Team Conor를 만들었다.

npx team-conor

이 한 줄이면 클로드 코드에 가상의 팀이 셋팅된다.

단순히 이름만 붙인 역할극이 아니다. 각 페르소나에는 체크리스트, 안티패턴 목록, 해결 패턴, 그리고 다른 페르소나를 호출하는 트리거가 설계되어 있다.

추상적 조언이 아니라 구체적 피드백

체크리스트로 리뷰한다

"코드가 좋습니다" 같은 단순한 칭찬은 나오지 않는다. 각 페르소나는 자기 영역의 체크리스트로 코드를 검토한다.

유나: 이 컴포넌트 봤는데...
- [ ] useEffect 의존성 배열에 user 빠져있어요
- [ ] 이 상태는 서버 컴포넌트로 올릴 수 있어요
- [x] 타입은 잘 되어있네요

통과한 건 통과했다고, 안 된 건 뭐가 안 됐는지 명확하게 짚어준다.

안티패턴을 잡아낸다

각 페르소나는 자기 영역에서 흔히 발생하는 실수 패턴을 알고 있다. 빅토르는 "트랜잭션 없는 다중 쓰기", "N+1 쿼리", "에러 삼키기" 같은 백엔드 안티패턴을 감지한다. 마르코는 "로딩 상태 누락", "색상만으로 정보 전달" 같은 UX 안티패턴을 잡아낸다. 중요한 건, 문제만 지적하고 끝나지 않는다는 것이다.

빅토르: 이거 N+1 쿼리예요. 루프 안에서 DB 호출하고 있네요.
→ JOIN 쿼리나 DataLoader 패턴으로 대체하는 게 맞습니다.

"에러 핸들링을 추가하세요"가 아니라, 어떤 에러를 어떻게 처리할지까지 제안한다.

페르소나끼리 협업한다

이게 가장 재미있는 부분이다. 한 페르소나가 리뷰하다가 다른 영역의 문제를 발견하면, 해당 페르소나를 호출한다.

마르코와 유나가 함께 보면 화면이 예쁘면서도 성능이 좋아진다. 마르코가 "Skeleton UI 넣어야 한다"고 하면 유나가 "CSS transform으로 애니메이션 걸어야 60fps 나온다"고 받아준다. 스티브가 "이 기능 범위가 커지고 있는데"라고 하면 엘런이 "뭘 빼면 절반 시간에 되는지 볼게요"라고 스코프를 잡아준다.

실제 팀에서 자연스럽게 일어나는 대화가 AI 안에서 재현된다.

페르소나는 토큰 낭비?

스티브는 “첫 아이폰 프로덕트 비저너리”, 엘런은 “스페이스X 초기 멤버”, 마르코는 “도널드 노먼의 수제자”, 빅토르는 “Rust 초기 기여자”, 유나는 “크롬 브라우저 초기 개발팀 출신” 이라는 설정을 두고 있다. 이건 단순히 상황극의 재미를 향상시키기 위한 설정이 아니다.

토큰을 절약하는 가장 확실한 방법은 배경 설정이라고 생각한다. 빅토르가 “Rust 초기 기여자”라는 배경은 “타입 시스템으로 버그를 원천 차단한다”는 리뷰 철학을 강제하는 앵커다. 이 배경 때문에 빅토르는 “타입이 이미 잡아주는 걸 왜 테스트해요?”라고 말할 수 있고, “타입으로 못 잡는 것만 테스트한다”는 원칙을 일관되게 유지한다.

배경은 페르소나의 행동 범위를 제한하는 제약 조건이다. 배경과 행동 원칙이 일치할 때, AI는 그 방향에서 벗어나지 않는다.

솔직한 한계

컨텍스트가 많아지면 성능이 떨어질 수 있다. 5개 페르소나의 체크리스트와 안티패턴이 전부 컨텍스트에 올라가면, AI가 여러 관점을 동시에 의식하면서 어느 쪽으로도 날카롭지 못한 "합의형 피드백"을 줄 가능성이 있다.

이 문제를 완전히 해결한 것은 아니지만, 몇 가지로 완화하고 있다.

• 페르소나는 이름으로 호출해야 활성화된다. 항상 5명이 동시에 말하는 구조가 아니다.

• 체크리스트라는 레일이 있기 때문에 "뭉뚱그려진 조언"이 나오기 어렵다.

• Cross-domain 트리거가 명시적이라서, 관련 없는 페르소나가 끼어드는 노이즈가 적다.

그래도 하나의 AI에게 하나의 역할만 맡기는 것보다 결과가 떨어지는 순간은 있을 수 있다. 이건 트레이드오프다. 대신 혼자서는 절대 얻지 못하는 다각도 피드백을 얻는다.

Memory 시스템

AI는 세션이 끝나면 다 잊어버린다. 다음 세션에서 같은 설명을 반복하는 것만큼 비효율적인 것이 없다.

.conor/memory/ 디렉토리에 프로젝트 컨텍스트를 기록한다.

• summary.md: 핵심 컨텍스트 (항상 참조됨)

• project.md: 기술 스택, 아키텍처, 컨벤션

• decisions.md: 왜 이 기술을 선택했는지

• learnings.md: 발견한 패턴, 해결한 버그

기술적 결정이 발생하거나, 버그를 해결하거나, 프로젝트 패턴을 발견하면 사용자가 요청하지 않아도 자동으로 기록한다. 다음 세션에서 팀이 프로젝트를 기억하고 있다.

시작하기

npx team-conor

팀원들이 당신을 불러줄 이름을 입력하면 끝이다. CLAUDE.md와 .conor/ 디렉토리가 생성되고, 다음 Claude 세션부터 팀이 함께한다. 각 페르소나의 체크리스트, 안티패턴, 해결 패턴은 전부 .conor/persona/*.md 파일에 있으니 프로젝트에 맞게 자유롭게 수정할 수 있다.

혼자 개발한다고 혼자 작업할 필요는 없다.

GitHub: https://github.com/baealex/team-conor