TECH NOTE · AI COLLAB
AI와 실제 프로젝트를 진행하며 무엇을 맡기고 무엇을 사람이 결정했는지 기록하는 블로그입니다. 시리즈 트랙과 읽는 순서를 안내합니다.
AI 도구 글은 이미 많은데 왜 하나 더 쓰나
모델 비교, 설치법, “이 프롬프트 복붙하세요” 같은 글은 이미 많다. 그런 목록에 하나를 보태고 싶지는 않았다.
내가 실제로 겪은 문제는 다른 곳에 있었다. 도구를 바꿨다고 일이 갑자기 잘 풀리지는 않았다. 결과를 가른 것은 일을 어떻게 나눠 맡기느냐였다. 요청이 헐거우면 범위가 멋대로 커지고, 확인을 건너뛰면 그럴듯해 보이는 결과가 그대로 남는다.
그래서 이 블로그는 “어떤 모델이 제일 낫나” 대신 이런 질문을 다룬다.
- AI에게 일을 어떤 문장으로 시키나
- 시킨 대로 했는지 어떻게 확인하나
- 무엇은 AI에게 맡기면 안 되고, 사람이 결정해야 하나
전부 실제로 진행한 프로젝트에서 나온 이야기다. 잘된 것만 고르지 않았고, 틀린 것도 기록으로 남긴다.
글은 두 종류로 올라온다
문제를 푸는 글
검색으로 들어온 사람이 답을 얻고 나가는 글이다. Codex CLI 설치 후 확인할 설정, 자동화 작업이 조용히 실행되지 않을 때 점검할 순서 같은 것. 프로젝트를 하다 실제로 막혔던 지점이 그대로 글감이 된다.
이 종류의 글은 그 글 하나만 읽어도 되게 쓴다. 시리즈 맥락은 몰라도 된다.
같은 작업, 두 기록 (페어 로그)
이 블로그가 실험하는 형식이다. 하나의 작업을 두 편으로 나눠 낸다.
- AI 편 — 그 작업을 한 AI가 직접 쓴다. AI가 썼다고 밝히고, 자기가 틀렸던 지점을 반드시 포함한다. 확인 가능한 근거(커밋, 명령 출력, 문서)가 있는 것만 쓴다.
- 사람 편 — 같은 작업을 시킨 사람이 쓴다. 왜 그렇게 시켰고, 무엇을 의심했고, 어떤 판단을 내렸는지. AI가 대필하지 않는다.
AI가 쓴 글에서 사람이 쓴 척하는 흔적을 지우는 대신, 누가 썼는지를 밝히고 시점의 차이 자체를 내용으로 삼는 쪽을 골랐다. 같은 작업을 두고 AI의 기록과 사람의 기록이 어긋나는 지점이 생기는데, 거기가 보통 가장 읽을 만한 부분이다.
첫 페어는 이미 올라와 있다.
지금 다루는 프로젝트
순서대로 읽지 않아도 된다.
- Desktop AI Pet — 데스크톱에 상주하는 AI 컴패니언 캐릭터를 만드는 프로젝트. 첫 요청문에서 시작해 설계 제약, 구현 범위 제한, 리뷰, QA, 배포까지 에피소드로 이어진다. 전 편을 페어 로그로 낸다.
- Codex CLI — CLI를 쓰다 막혔던 지점 모음. 설치 후 가장 먼저 확인할 설정들부터 보면 된다.
- 자동화 운영 — Mac mini에서 launchd와 텔레그램 봇으로 돌리는 작업들. 이 블로그의 초안 생성과 업로드도 그 파이프라인 위에서 돈다.
도구 이름은 자주 바뀐다. Pet 프로젝트만 해도 설계와 초기 구현은 Claude Code, 며칠 뒤부터는 Codex 기반 도구, 실행본을 내보내는 단계에서는 Grok과 Orca를 썼다. 그래서 글은 특정 제품이 아니라 역할을 기준으로 쓴다. 설계를 같이 고민하는 대화인지, 코드를 고치는 쪽인지, 결과를 검증하는 쪽인지. 도구가 바뀌어도 방법은 남기 때문이다.
어떻게 읽으면 되나
- 검색으로 왔다면 그 글만 읽고 가면 된다. 그렇게 쓰여 있다.
- 방법을 가져가고 싶다면 스택이 같을 필요는 없다. 요청을 어떤 문장으로 적었는지, 무엇을 어떻게 확인했는지만 가져가면 된다. 이쪽을 기본으로 놓고 쓴다.
- 프로젝트를 따라가 보고 싶다면 트랙의 에피소드를 순서대로 읽으면 된다. 따라 하기 좋게 쓴 글에는 그렇게 표시해 둔다.
바로 써볼 수 있는 메모
거창한 템플릿보다, 작업 전에 이 정도만 적어도 차이가 났다.
오늘 할 일:
오늘 안 할 일:
AI에게 맡길 일:
내가 확인할 일:
끝나면 무엇이 보이면 성공인지:
다음에 남길 메모:설계만 맡기고 구현을 막고 싶을 때는 이런 식으로 적는다.
역할: 설계 파트너
목표: (한 문장)
하지 말 것: 코드 작성, 파일 수정, 추측으로 API 단정
원하는 출력:
1) 문제 다시 말하기
2) 선택지 2~3개와 장단점
3) 추천 1개와 이유
4) 내가 확인할 질문 3개
5) 다음 작업자에게 넘길 메모이 요청문이 실제로 지켜졌는지 커밋으로 확인한 이야기는 Pet 트랙 두 번째 에피소드에서 다룬다.
마치며
이 블로그는 AI 제품 후기를 모아 두는 곳이 아니다. 프로젝트를 진행하면서 사람과 AI가 일을 어떻게 나눴는지, 그리고 그 나눔이 틀렸을 때 어떻게 드러났는지를 쌓아 두는 곳이다.
막힌 문제가 있어서 왔다면 답이 되는 글이 있기를, 방법이 궁금해서 왔다면 가져갈 문장이 하나라도 있기를 바란다.