AI를 한 명처럼 쓰지 마세요 — Claude(손)·Codex(눈)로 역할을 나눈 1인 개발 워크플로우

혼자 개발하다 보면 AI 한 명에게 전부 맡기고 싶어져요. 기획도 시키고, 구현도 시키고, 검토까지 같은 대화창에서 끝내는 거죠. 빠르긴 한데, 이렇게 쓰면 위태로운 순간이 생겨요. 만든 사람과 검토하는 사람이 같으면, 자기 코드의 빈틈을 자기가 못 봅니다. 그래서 저는 AI를 한 명처럼 쓰지 않고, 역할을 둘로 나눠 쓰고 있어요.

손과 눈을 나눈 이유

제 워크플로우는 이렇게 정리돼요.

• Claude = 손. 스크립트 초안, 파싱 로직, UI 같은 걸 빠르게 만들어요. 일단 돌아가는 걸 만드는 속도가 좋아요.
• Codex = 눈. 만들어진 코드를 보안·예외처리·검증 관점에서 적대적으로 되짚어 줍니다. "이거 이렇게 깨질 수 있다"를 찾는 역할이에요.

같은 AI라도 "빠르게 만들어"라는 맥락과 "이거 어디서 깨지나 찾아"라는 맥락은 전혀 다른 작업이에요. 한 대화에서 둘을 섞으면, 방금 자기가 짠 코드를 옹호하는 쪽으로 흐르기 쉽거든요. 만드는 자리와 검토하는 자리를 물리적으로 떼어 놓으니, 검토가 훨씬 날카로워졌어요.

무엇을 만들지는 사람이 먼저 정합니다

여기서 제일 중요한 원칙이 있어요. 무엇을 만들지, 어떤 구조로 갈지는 제가 먼저 정한다는 점이에요. AI에게 "알아서 좋은 걸로 만들어 줘"라고 던지지 않아요.

아키텍처, 데이터 소스 선택, 어떤 값을 하드코딩하지 않을지 같은 판단은 사람이 합니다. AI는 그 결정을 빠르게 구현하고(손), 그 결과를 되짚어 줄 뿐이에요(눈). 이 경계를 지키니 자동화가 제 손을 벗어나 폭주하지 않고, 끝까지 제가 이해하는 코드로 남았어요.

오늘 실제로 이렇게 굴러갔어요

오늘 한 작업이 마침 좋은 예시였어요. "잘하는 1인 개발자들의 글에서 무엇이 반응을 얻는지" 벤치마크 데이터를 모으려던 작업이에요.

처음엔 트위터(X)의 공개 syndication API로 글을 긁으려 했는데, 공용 IP에서 여러 계정을 연달아 호출하니 HTTP 429 (Too Many Requests), IP 단위 레이트리밋에 막혔어요. 여기서 "막힌 길을 억지로 뚫을지, 더 열린 길로 갈아탈지"를 판단한 건 사람인 저였어요. 결론은 인증 없이 공개 엔드포인트가 열려 있고 engagement도 전부 공개되는 Bluesky AT Protocol로 갈아타는 거였고요.

• 판단(사람): "429를 뚫지 말고 Bluesky를 1차 소스로 바꾸자."
• 구현(Claude): AT Protocol 공개 API 호출 코드, 핸들 자동 검색, 원글만 거르는 파싱을 빠르게 작성.
• 검증(Codex): 예외처리와 결과 검증을 적대적으로 점검.

이렇게 결과적으로 Bluesky에서 5개 계정, 158개 글과 각 글의 좋아요·리포스트·답글을 실측으로 모았어요.

HTTP 200이 곧 "데이터 있음"은 아니에요

검증 단계에서 꼭 챙기는 게 하나 있어요. 응답 코드가 200이라고 해서 원하는 데이터가 들어 있다는 뜻은 아니라는 것. API가 정상 응답을 주면서도 빈 배열을 돌려주거나, 파싱이 어긋나 0건이 담길 수 있거든요. 코드 입장에선 "성공"인데 실제로는 아무것도 없는 상태죠.

이런 게이트는 만든 사람(손)이 챙기기 어려워요. "내가 짰으니 됐겠지" 하고 넘어가기 쉽거든요. 그래서 검토하는 눈(Codex)의 자리에서 "정말 데이터가 있는지"를 따로 확인하게 했어요.

정리하면

AI를 만능 한 명으로 쓰면 빠르지만, 빠름이 곧 옳음은 아니에요. 빠른 손(Claude)과 의심하는 눈(Codex)을 나누고, 무엇을 만들지는 사람이 먼저 정하는 것 — 이 단순한 분업이 1인 개발에서 코드를 제 손에 남기는 방법이었어요.

저는 생활 속 작은 문제를 작은 도구로 푸는 1인 AI 회사 라이프케어로그를 혼자 만들고 있어요. 이렇게 막히고 되짚은 과정을 계속 기록해 둘게요.

여러분은 AI에게 구현과 검토를 한 번에 맡기는 편인가요, 아니면 자리를 나눠 두는 편인가요? 어떻게 쓰시는지 궁금해요.