Claude Code와 티키타카하며 일하는 법, 한 세션으로 블로그를 만든 하루

복잡한 일일수록 AI 세션을 여러 개 띄우고 싶어지지만 저는 대부분 Claude Code 대화 하나에서 리서치하고 묻고 고르며 진행합니다. 이 블로그도 그렇게 만들었습니다. 설정, 도메인 연결, 글 두 편 게시까지 하루 동안 한 대화에서 끝냈습니다.

앞 글 AI 에이전트 여러 개를 한 브랜치에서 돌리면 코드가 꼬이는 이유에서 여러 세션을 쓸 때의 함정을 정리했다면, 이번에는 한 세션으로 일하는 방식을 실제 기록으로 정리합니다.

한 세션 티키타카는 무엇이 다른가요?

리서치부터 점검까지 한 대화 안에서 하니 맥락을 다시 모을 필요가 없고 서로의 작업을 덮어쓸 일도 없습니다. AI가 앞에서 읽은 문서, 제가 고른 선택, 중간에 바꾼 규칙이 모두 같은 대화에 남아 있어서 다음 단계가 그 위에서 바로 이어집니다.

Anthropic은 자사 멀티 에이전트 시스템을 설명하면서 여러 에이전트를 쓰면 일반 채팅보다 토큰을 약 15배 쓴다고 밝혔습니다. 또 맥락을 많이 공유해야 하는 일과 대부분의 코딩 작업은 나눠서 얻는 이득이 작다고 적었습니다. Claude Code 문서도 새 에이전트는 맥락을 처음부터 다시 모으느라 지금 세션에서 하는 것보다 느릴 수 있다고 설명합니다.

실제로 하루를 어떻게 보냈나요?

AI가 조사하고 제안하면 제가 고르고 AI가 실행하면 제가 화면으로 확인하는 일을 계속 주고받았습니다. 그날 한 일을 순서대로 적으면 이렇습니다.

단계	그날 실제로 한 일
리서치	구글 검색 센트럴 문서 8개를 읽게 하고 블로그 글 쓰는 스킬에 구글 블로그 형식(제목 길이, 검색 설명, 이미지 크기)을 추가했습니다.
설정	블로그 제목과 설명은 후보를 받아 제가 고르고 시간대와 이미지 최적화는 AI가 바로 바꿨습니다.
도메인	CNAME 두 개를 넣었는데 Blogger가 "권한을 확인할 수 없습니다"를 두 번 띄웠습니다. DNS 조회로 레코드가 이미 보이는 걸 확인하고 몇 분 기다렸다 다시 저장해 연결했습니다.
첫 글 기획	주제 후보 네 개 중 하나를 제가 골랐고 AI는 제목과 구성안을 보여 준 뒤 멈췄습니다. 승인한 다음에야 쓰기 시작했습니다.
끼어들기	쓰는 도중에 "사진은 카메라 조건과 자연광으로"라고 끼어들었고 AI는 그 규칙을 이미지 지침에 넣은 뒤 이어서 진행했습니다.
사실 확인	기사 여섯 개 원문 확인은 보조 에이전트에게 맡기고 결과만 받았습니다. 직접 계산한 표가 국회예산정책처 추산과 맞는지 그 결과로 대조했습니다.
실수와 규칙	첫 글이 원하던 주소 대신 blog-post.html로 올라갔습니다. "게시 전에 새로고침해서 주소 확인"을 스킬에 적었고 두 번째 글은 원하는 주소로 올라갔습니다.

잘된 건 결정이 쌓인다는 점이었습니다. 오전에 정한 블로그 설명이 오후 글의 검색 설명 말투가 됐고 첫 글에서 생긴 실수가 두 번째 글의 확인 절차가 됐습니다. 세션을 나눴다면 매번 다시 설명해야 했을 내용입니다.

막힌 곳도 있었습니다. Blogger 이미지 업로드 창은 일반 파일 선택창이 아니라서 AI가 몇 번 방법을 바꿔야 했습니다. 표 디자인을 고쳤을 때는 PC 화면만 보고 끝날 뻔했는데, 휴대폰 너비로 다시 열어 보게 하니 셋째 칸이 잘린 게 보였습니다. 한 세션이라도 결과를 직접 확인하는 단계는 빼면 안 된다는 걸 여기서 배웠습니다.

한 세션 작업을 받쳐 주는 기능은 무엇인가요?

계획부터 보게 하는 계획 모드, 중간에 끼어들고 되돌리는 키, 그리고 맥락을 비우는 명령 세 가지면 충분합니다. 모두 Claude Code 공식 문서에 나오는 기능입니다.

상황	쓰는 것
먼저 계획만 보고 싶을 때	계획 모드. Shift+Tab을 눌러 상태 표시줄에 plan mode가 뜨게 하거나 claude --permission-mode plan으로 시작합니다. 파일을 읽고 계획을 내놓되 승인 전에는 고치지 않습니다.
요구사항이 흐릿할 때	"스펙을 쓸 수 있을 때까지 나를 인터뷰해 줘"라고 요청합니다. 문서는 스펙이 나오면 새 세션에서 구현하라고 권합니다.
끝났다는 말을 믿기 어려울 때	테스트, 빌드, 스크린샷처럼 통과와 실패가 갈리는 기준을 주고 실행한 명령과 결과를 증거로 보여 달라고 합니다.
방향이 틀어졌을 때	Esc로 멈추고 지시를 덧붙입니다. 이미 한 작업으로 돌아가려면 /rewind나 빈 입력창에서 Esc 두 번으로 되돌리기 메뉴를 엽니다.
두 번 고쳐도 안 될 때	세 번째 수정 대신 /clear로 비우고 더 나은 요청을 새로 씁니다. 문서가 직접 권하는 규칙입니다.
대화가 길어졌을 때	/compact 뒤에 남길 내용을 적어 요약합니다. 주제가 바뀌면 /clear로 새로 시작합니다.
조사량이 많을 때	"보조 에이전트로 조사해 줘"라고 맡기면 조사 과정은 빠지고 결과만 대화에 남습니다.

# 계획부터 보고 시작
claude --permission-mode plan

# 길어진 대화를 초점 있게 줄이기
/compact 정한 블로그 규칙과 남은 할 일만 남겨 줘

# 다음 날 이어서
claude --continue

티키타카가 잘 되는 요청법은 무엇인가요?

멈출 지점을 미리 정하고 고르는 일은 사람이 하고 끝났다는 말 대신 증거를 받는 것입니다. 그날 대화에서 효과가 컸던 요청을 정리하면 세 가지입니다.

첫째, 멈출 곳을 말합니다. "기획안을 보여 주고 멈춰"라고 하면 AI가 제목 후보와 구성을 먼저 내놓습니다. 여기서 방향을 고치는 비용은 거의 없지만 다 쓴 글을 고치는 비용은 큽니다.

둘째, 고르는 일은 사람이 합니다. 블로그 제목, 글 주제, 공개 여부처럼 취향이 갈리는 일은 AI가 후보만 내고 제가 정했습니다. 도메인 개인정보 보호처럼 돈이 드는 일은 결제 화면 앞에서 멈추고 물었습니다. 반대로 시간대 설정이나 검사 스크립트처럼 정답이 있는 일은 묻지 않고 하게 두었습니다.

셋째, 증거를 받습니다. "올렸어요" 대신 로그인하지 않은 상태로 연 화면, 실제 주소, 검사 결과를 보여 달라고 했습니다. 첫 글의 주소 문제도 이 확인 단계에서 바로 드러났습니다.

언제 여러 세션으로 넘어가나요?

서로 다른 폴더를 건드리고 중간에 결과를 주고받을 필요가 없는 일이 둘 이상일 때만 넘어갑니다. 그 경우에도 세션마다 git worktree로 폴더를 나눕니다.

이런 일이면	이렇게
설계, 리팩터, 글쓰기처럼 앞의 결정이 뒤에 계속 쓰이는 일	한 세션
자료 조사가 많은 일	한 세션 + 조사만 보조 에이전트
API 수정과 화면 수정처럼 파일이 겹치지 않는 독립 작업	여러 세션, 세션마다 worktree
같은 파일을 여럿이 고쳐야 하는 일	한 세션으로 순서대로

여러 세션을 같은 폴더에서 돌리면 어떤 일이 생기는지는 앞 글에 재현 결과와 함께 정리해 두었습니다.

요약

• 맥락이 이어지는 일은 Claude Code 대화 하나에서 리서치, 기획, 승인, 실행, 점검을 주고받으며 하는 편이 빠르고 안전했습니다.
• 계획 모드(Shift+Tab), Esc와 /rewind, 두 번 고쳐도 안 되면 /clear가 한 세션 작업의 기본 도구입니다.
• 멈출 지점을 정하고 고르는 일은 사람이 하고 결과는 증거로 받습니다.
• 실수는 그 자리에서 규칙으로 남기면 다음 작업부터 반복되지 않습니다.