2026-10-01-TIL: Claude Code 세션 여러 개로 보낸 하루, 그리고 Jev

게시 2026/10/01 업데이트 2026/10/01

By August

조회 17 분 읽는 시간

오늘은 하루 종일 Claude Code를 켜 두고 지냈다. 저녁에 세어 보니 여덟 개 저장소에서 열 개 넘는 세션이 돌았다. 한 세션에서 블로그 글을 다듬는 동안 다른 세션은 CI 결과를 기다리고, 또 다른 세션은 사이드 프로젝트의 다음 단계를 진행하는 식이었다. 작업 단위마다 커밋하도록 해 두어서, 하루가 커밋 로그만으로 대략 복원된다.

오늘 한 작업

블로그: 실험 노트 스타일과 글 다듬기

오전에는 다른 개발자 블로그 두 곳의 글쓰기 방식을 분석했다. 문체는 내 것을 유지하되, 직접 검증한 실험 노트 느낌은 가져오고 싶었다. 가져올 점만 골라 스타일 가이드에 추가했다. 결론에는 핵심 코드 줄을 짚고 전제 조건을 밝히도록 했고, 실험 노트용 가벼운 검증 형식도 넣었다. 락 종류 글과 격리 수준 글로 파일럿을 돌려 봤다.

저녁에는 홈 첫 페이지 글들을 집중적으로 손봤다.

개념 설명 글에는 RFC, Javadoc, 공식 문서 같은 공신력 있는 출처를 붙였다.
기술 블로그 리뷰 글은 원문이 말한 것과 내 해석을 분리했다.
글로만 설명하던 흐름에 Mermaid 다이어그램을 추가했다. TLS 핸드셰이크 비교나 느린 업스트림 하나가 Tomcat 스레드를 다 잡아먹는 과정 같은 것들이다.
처음 나오는 용어에 짧은 설명을 달고, 관련 글로 내부 링크를 걸고, 긴 문장을 나눴다.

소개 페이지도 정리했다. 이력서와 포트폴리오는 GitHub 옆 버튼으로 줄이고, 섹션 헤더를 통일했다. Capability Map에서 접혀 있던 근거 목록도 펼쳤다. 지역 창업 지원사업 1라운드를 통과해서 관련 글 두 편을 새로 쓰기도 했다.

sys-drill: 완성도 마무리와 CI 정리

시스템 설계 훈련 플랫폼인 sys-drill에서 커밋이 가장 많이 나왔다. 커뮤니티 토론 스레드와 온보딩까지 끝내서 계획했던 기능 단위가 모두 닫혔다. 이어서 벤치마킹 문서에 남아 있던 항목을 처리했다. 개념 문서 끝의 확인 문제, 알림 피드, 관리자 성공 지표 패널 같은 것들이다.

깨진 CI를 복구하면서 워커 백오프 버그도 잡았다. 처음에는 예외가 난 뒤 백오프를 하도록 고쳤고, 이어서 상한이 있는 지수 백오프로 바꿨다. 상한은 60초에서 10초로 줄였다. Dependabot PR도 정리했다. 쓸 수 없는 PR은 닫고 나머지는 브랜치에서 CI 판정을 받은 뒤 머지했다.

iterview: 이력서 근거와 테마

면접 준비 도구인 iterview에서는 “다음 단계 진행해줘”만 반복했는데도 하루치 기능이 쌓였다.

이력서 주장마다 근거를 따로 저장하는 구조를 만들었다.
면접 기록 리뷰 화면을 사실 위주로 다시 짰다.
이력서 문서 편집기를 공통 컴포넌트로 재구성했다.
global.css를 걷어 내고 디자인 토큰만으로 시스템, 라이트, 다크 테마를 지원하게 했다.

그 밖의 저장소

monticker: APM이 붙어 있는지 물어본 게 시작이었다. Pinpoint를 쓰기로 결정하고 그 결정을 기록했다. 그런데 에이전트 설정이 실제로는 에이전트에 전달되지 않고 있어서 그것까지 고쳤다.
parity-pay: 모델 체킹 결과를 주변 문서에 녹여 넣었다.
career-hub: 지원 서류와 메일 회신을 정리했다. GitHub 저장소 중 설명이 비어 있던 것들에 영문 description을 채웠다. 로컬에만 있던 실험 저장소 몇 개도 원격에 올렸다.

느낀 점

세션을 여러 개 띄우니 내 역할이 코드를 쓰는 사람보다 큐를 관리하는 사람에 가까워졌다. 한쪽에 “다음 단계 진행해줘”를 던져 두고 다른 쪽 결과를 검토하는 식이다. 대신 맥락을 쥐고 있는 건 결국 나라서, 어느 세션이 무엇을 기다리는지 놓치면 같은 일을 두 번 시키게 된다.

블로그 작업에서는 에이전트에게 맡기기 좋은 일이 “새로 쓰기”보다 “다시 읽고 고치기”라는 것을 다시 느꼈다. 출처 확인, 용어 풀이, 긴 문장 분리는 기준만 분명하면 반복 작업에 가깝다. 사람이 하면 지루해서 대충 넘기게 되는 일이기도 하다. 다만 원문과 내 해석을 가르는 판단은 직접 읽고 확인해야 했다.

돌아보면 아직은 AI를 꽤 단순하게 쓰고 있다. 오늘 보낸 요청의 상당수가 “다음 단계 진행해줘”였다. 무엇을 할지는 에이전트가 정하고, 나는 결과를 보고 다음을 누르는 식이다. 이렇게 해도 결과물은 나오지만, 매번 같은 지시를 다시 하고, 다 됐는지는 결과를 직접 열어 봐야 안다.

AI를 더 잘 쓰려면

오늘 작업을 기준으로 바꿔 볼 만한 것들을 정리해 봤다.

요청에 완료 기준을 넣는다

“다음 단계 진행해줘” 대신 무엇이 되면 끝인지를 같이 준다. 예를 들어 “알림 피드를 구현하고, 백엔드 테스트와 프론트 빌드가 통과하면 커밋하고 멈춰” 같은 식이다. 에이전트가 스스로 검증하고 멈출 지점을 알면, 결과를 확인하는 일이 “열어 보기”에서 “테스트 결과 읽기”로 줄어든다. 큰 작업은 바로 시키기보다 plan 모드로 계획부터 받아서 검토하는 편이 낫다.

반복하는 지시는 파일로 옮긴다

오늘만 해도 “작업 단위마다 커밋해줘”, “공신력 있는 출처를 붙여줘”, “AI가 쓴 티 안 나게”를 여러 세션에서 반복했다. 이런 말은 대화에 남기지 말고 파일로 옮겨야 한다.

CLAUDE.md / AGENTS.md: 저장소마다 항상 지켜야 할 규칙을 둔다. 세션이 바뀌어도 매번 읽힌다.
스킬(커스텀 명령): 블로그에는 이미 new-post, post-lint, build-check가 있다. 오늘 한 “출처 붙이고 용어 풀고 문장 나누기”도 기준을 정리해서 스킬 하나로 만들면, 다음부터는 글 이름만 넘기면 된다.
메모리: 사람에 대한 선호처럼 저장소를 가리지 않는 규칙은 메모리에 남긴다.

지켜야 하는 규칙은 훅으로 강제한다

부탁한 규칙은 에이전트가 가끔 잊는다. 반드시 지켜야 하는 건 훅으로 걸어 두는 게 확실하다. 파일을 고친 뒤 린트를 돌리거나, 커밋 전에 front matter 검사 스크립트를 돌리는 식이다. 블로그는 husky pre-commit으로 일부를 하고 있지만, Claude Code 훅을 쓰면 커밋 시점까지 기다리지 않고 파일을 고칠 때마다 바로 피드백을 줄 수 있다.

병렬 세션은 격리하고 목표를 하나로 둔다

세션 여러 개가 같은 작업 디렉터리를 건드리면 서로의 변경이 섞인다. 같은 저장소에서 동시에 돌릴 때는 worktree로 나누고, 세션마다 목표를 하나만 준다. 오늘처럼 한 세션이 아침부터 밤까지 CI 복구, PR 정리, 기능 추가를 오가면 컨텍스트가 길어져 요약이 반복되고 앞의 맥락이 흐려진다.

CLI를 꼭 써야 할까

결론부터 말하면 대화형 작업에는 CLI가 필수는 아니다. 데스크톱 앱도 같은 Claude Code 엔진을 쓴다. 병렬 세션, worktree, 미리보기 브라우저까지 GUI로 다룰 수 있어서 오늘 한 일은 전부 앱으로 충분했다.

CLI가 확실히 나은 지점은 사람이 없는 자동화다.

헤드리스 실행: claude -p "..."로 프롬프트 하나를 실행하고 결과만 받을 수 있다. 쉘 스크립트, cron, Git 훅에 그대로 넣을 수 있다.
파이프 조합: git diff | claude -p "이 변경의 리뷰 포인트만 뽑아줘"처럼 다른 명령의 출력을 바로 넘긴다. --output-format json으로 받으면 다음 스크립트가 결과를 파싱할 수 있다.
CI 연동: GitHub Actions에 붙이면 PR이 올라올 때 리뷰를 달거나, 주간 링크 체크 결과를 요약해 이슈로 남기는 식의 작업을 사람 없이 돌릴 수 있다.
설정 명령: 훅이나 권한 같은 일부 설정 명령은 터미널의 대화형 패널에서 다룬다.
원격 환경: SSH로 접속한 서버나 tmux 안에서도 그대로 쓸 수 있다.

그래서 당분간은 직접 대화하며 판단하는 작업은 앱에서 하고, 반복되고 판단 기준이 정해진 작업은 CLI로 스크립트화하는 쪽으로 나눠 볼 생각이다. 블로그라면 주간 외부 링크 체크 결과를 claude -p로 요약해서 고칠 목록을 만드는 것부터 해볼 만하다.

Jev라는 키워드

요즘 링크드인 피드에 Jev라는 이름이 자주 보여서 대략 찾아봤다. TypeSafe AI라는 회사가 지난달 얼리 액세스로 공개한 모델이다.

핵심은 문장을 생성하지 않는 모델이라는 점이다. 질문을 던지면 정해진 타입의 값과 확률, 신뢰도 점수를 돌려준다. 선택지 중 하나 고르기, 정해진 단계로 점수 매기기, 예/아니오 판정 같은 형태다. 회사는 이걸 카너먼의 “시스템 1(빠르고 직관적인 사고)”에 빗대 System One 모델이라고 부른다.

에이전트 구조로 보면 LLM을 대체하는 게 아니라, 에이전트 루프 중간의 작은 결정들을 맡는 층이다. 의도 분류, 어떤 모델로 보낼지 라우팅, 입력 필터링, 툴 호출을 허용할지 판단하는 일 같은 것들이다. 이런 결정까지 매번 큰 LLM에 물어보면 느리고 비싸니, 출력 형태가 정해진 판단은 가볍고 빠른 모델에 넘기자는 발상이다.

다만 회사가 내세우는 “40~200배 빠르고 최대 400배 싸다”는 수치는 자체 작업으로 측정한 것이다. 아키텍처나 기술 문서도 아직 공개되지 않았다. 일단은 “LLM 앞단에 붙는 타입 지정 결정 레이어” 정도로 이해해 두면 될 것 같다.

참고:

다음에 확인할 것

여러 세션을 돌릴 때 각 세션이 무엇을 기다리는지 한눈에 보는 방법
블로그 글 다듬기 기준을 스킬로 만들고, front matter 검사를 Claude Code 훅으로 걸기
주간 링크 체크 결과를 claude -p로 요약하는 스크립트
Jev 같은 결정 모델을 에이전트의 라우팅이나 툴 호출 판단에 붙이면 비용이 실제로 얼마나 줄어드는지

TIL, 2026-TIL