AI Brain Fry 이겨내기: git 기반 우선순위 큐로 에이전트 작업 관리

How I Fight AI Brain Fry

Nov 8, 2026•kyunez•View Original

TL;DR Highlight

티켓을 git에 두고 결정만 한 곳에서 처리했더니 20개 스레드 혼란이 줄었다

Who Should Read

Claude Code·Codex 탭을 여러 개 띄워 두고 컨텍스트 전환 때문에 지쳐 버린 개발자

Core Mechanics

문제는 순서와 컨텍스트
- 저자는 터미널 에이전트 작업이 20개 스레드로 불어나 집중이 무너지는 것을 겪었다.
- 원인을 순서(sequencing)와 컨텍스트 두 가지로 보고 우선순위 큐처럼 일을 정리했다.
큐는 git 안에 둔다
- 티켓은 코드 옆 저장소의 마크다운 파일이고 보드 상태는 커밋된 스냅샷이다.
- 중요한 건 채팅창이나 머릿속에 두지 않아서 세션이 죽어도 큐는 남는다.
에이전트는 사이클로 보드를 돈다
- 새 티켓을 조사하고, 사람이 안전하다고 태그한 티켓을 빌드하고, 테스트와 브라우저 확인을 하고, 이미 배포된 것을 검증한다.
- 민감한 코드는 브랜치에서 빌드한 뒤 먼저 묻고, 프로덕션 배포는 절대 하지 않는다.
판단이 필요한 건 owner inbox로
스크립트가 보드 전체를 읽어 내 판단을 기다리는 항목만 우선순위 순으로 뽑아 준다.
- 변경 리뷰, 질문 답변, 트레이드오프 결정이 여기에 들어온다.
리뷰는 Claude artifact 한 페이지로
- 사이클마다 git에서 페이지를 다시 만들어 보드 전체와 티켓별 리뷰 페이지를 보여 준다.
- 판정은 git의 카드에 기록되고 페이지는 뷰어일 뿐이다.
항목을 닫는 게 핵심이다
- 항목 하나를 골라 컨텍스트를 로드하고 결정이나 요청을 한 뒤 큐에 되돌려 닫는다.
- 컨텍스트도 같이 닫혀서 다음 항목에 집중할 수 있다.

Community Reactions

병렬은 빠르게 느껴질 뿐이라는 의견
- 10k줄 넘는 변경 3개를 리뷰해야 하면 이해가 흐려져서 리뷰가 병목이 된다는 댓글이 있었다.
- 한 가지씩 직렬로 하는 게 더 빠를 것 같아 시간을 재 보려 한다는 의견이다.
동시 작업을 2~4개로 제한한다는 경험
- 한 번에 2~3개로 제한한다는 경험이 있었다.
- cmux 탭 그룹을 우선순위로 정렬해 3~4개까지만 돌린다는 경험도 있었다.
git 대신 GitHub issues를 쓰면 되지 않느냐는 반론
- 이슈를 만들면 에이전트가 집어 작업하고 상태나 PR을 갱신하며 needs more info 라벨을 붙이면 된다는 의견이다.
- 더 나은 UI와 칸반을 공짜로 얻는다는 주장이다.
Claude에게 지금 뭘 봐야 하는지 물어본다는 경험
- 하루 한 번 길을 잃었다고 말하고 주의가 필요한 것을 정리시키면 대개 돌아온다는 경험담이다.
핸드오프를 완벽히 해도 반복 횟수는 모른다는 의견
- 정보를 완벽히 보여 줘도 몇 번 반복될지 몰라 같은 문제가 생긴다는 의견이다.
- 기본 작업을 제대로 설계하고 복잡도를 낮추는 게 낫다고 했다.

How to Apply

지금 진행 중인 일을 큐 파일로 옮기기
- 오늘 저장소에 tickets/ 폴더를 만들고 열려 있는 에이전트 작업마다 마크다운 파일 하나를 만들어라.
- 각 파일에 상태(대기·진행·내 판단 필요)와 다음에 필요한 결정을 한 줄로 적어라.
내 판단 대기 목록 스크립트 만들기
- 티켓 상태가 내 판단 필요인 파일만 모아 우선순위순으로 출력하는 스크립트를 짜라.
- 에이전트가 막히면 질문을 티켓에 적고 상태를 바꾸게 지시하라.
항목 하나씩 열고 닫는 규칙 정하기
- 한 항목을 열면 결정이나 요청을 마치고 티켓에 판정을 커밋한 뒤 닫아라.
- 배포 권한은 에이전트에게 주지 말고 직접 쥐어라.

Try It

복사해서 바로 해보기

# Claude Code에 붙여넣기 (저자 방법의 간이 버전: git 기반 티켓 큐)

이 저장소에 tickets/ 폴더를 만들고 다음 규칙으로 운영해 줘.
- 티켓은 마크다운 파일 하나이고 상단에 status: queued | building | needs-owner | done 를 적는다.
- 내 판단이 필요한 건 status를 needs-owner로 바꾸고 '결정할 것'을 한 줄로 적는다.
- 프로덕션 배포는 절대 하지 말고, 민감한 코드는 브랜치에서 작업한 뒤 먼저 물어봐.

지금 진행 중인 작업은 {{현재 작업 목록}}이야. 이걸 티켓으로 만들어 줘. 그리고 needs-owner 티켓만 우선순위순으로 요약해 줘.

이어서 해 볼 것: 한 항목씩 처리하고 판정을 티켓에 기록하게 한 뒤 다음 항목을 보여 달라고 해 봐.

Terminology

Brain Fry여러 AI 스레드를 오가다 머리가 과부하로 멈추는 상태다. 탭을 20개 열어 둔 브라우저처럼 머릿속 메모리가 꽉 찬 느낌이다.

Claude artifactClaude가 만들어 주는 독립된 한 페이지 결과물이다. 저자는 이걸 보드 현황과 리뷰를 보는 화면으로 쓴다.

owner inbox에이전트가 못 하는 결정만 모아 두는 받은편지함이다. 사람의 판단을 기다리는 항목만 보이는 대기열이다.

컨텍스트 전환작업 A에서 B로 넘어가며 머릿속 맥락을 갈아끼우는 비용이다. 요리하다 전화 받고 레시피 순서를 잊는 것과 비슷하다.

Related Resources

AI Brain Fry 이겨내기: git 기반 우선순위 큐로 에이전트 작업 관리

How I Fight AI Brain Fry

Nov 8, 2026•kyunez•View Original

TL;DR Highlight

티켓을 git에 두고 결정만 한 곳에서 처리했더니 20개 스레드 혼란이 줄었다

Who Should Read

Claude Code·Codex 탭을 여러 개 띄워 두고 컨텍스트 전환 때문에 지쳐 버린 개발자

Core Mechanics

문제는 순서와 컨텍스트
- 저자는 터미널 에이전트 작업이 20개 스레드로 불어나 집중이 무너지는 것을 겪었다.
- 원인을 순서(sequencing)와 컨텍스트 두 가지로 보고 우선순위 큐처럼 일을 정리했다.
큐는 git 안에 둔다
- 티켓은 코드 옆 저장소의 마크다운 파일이고 보드 상태는 커밋된 스냅샷이다.
- 중요한 건 채팅창이나 머릿속에 두지 않아서 세션이 죽어도 큐는 남는다.
에이전트는 사이클로 보드를 돈다
- 새 티켓을 조사하고, 사람이 안전하다고 태그한 티켓을 빌드하고, 테스트와 브라우저 확인을 하고, 이미 배포된 것을 검증한다.
- 민감한 코드는 브랜치에서 빌드한 뒤 먼저 묻고, 프로덕션 배포는 절대 하지 않는다.
판단이 필요한 건 owner inbox로
스크립트가 보드 전체를 읽어 내 판단을 기다리는 항목만 우선순위 순으로 뽑아 준다.
- 변경 리뷰, 질문 답변, 트레이드오프 결정이 여기에 들어온다.
리뷰는 Claude artifact 한 페이지로
- 사이클마다 git에서 페이지를 다시 만들어 보드 전체와 티켓별 리뷰 페이지를 보여 준다.
- 판정은 git의 카드에 기록되고 페이지는 뷰어일 뿐이다.
항목을 닫는 게 핵심이다
- 항목 하나를 골라 컨텍스트를 로드하고 결정이나 요청을 한 뒤 큐에 되돌려 닫는다.
- 컨텍스트도 같이 닫혀서 다음 항목에 집중할 수 있다.

Community Reactions

병렬은 빠르게 느껴질 뿐이라는 의견
- 10k줄 넘는 변경 3개를 리뷰해야 하면 이해가 흐려져서 리뷰가 병목이 된다는 댓글이 있었다.
- 한 가지씩 직렬로 하는 게 더 빠를 것 같아 시간을 재 보려 한다는 의견이다.
동시 작업을 2~4개로 제한한다는 경험
- 한 번에 2~3개로 제한한다는 경험이 있었다.
- cmux 탭 그룹을 우선순위로 정렬해 3~4개까지만 돌린다는 경험도 있었다.
git 대신 GitHub issues를 쓰면 되지 않느냐는 반론
- 이슈를 만들면 에이전트가 집어 작업하고 상태나 PR을 갱신하며 needs more info 라벨을 붙이면 된다는 의견이다.
- 더 나은 UI와 칸반을 공짜로 얻는다는 주장이다.
Claude에게 지금 뭘 봐야 하는지 물어본다는 경험
- 하루 한 번 길을 잃었다고 말하고 주의가 필요한 것을 정리시키면 대개 돌아온다는 경험담이다.
핸드오프를 완벽히 해도 반복 횟수는 모른다는 의견
- 정보를 완벽히 보여 줘도 몇 번 반복될지 몰라 같은 문제가 생긴다는 의견이다.
- 기본 작업을 제대로 설계하고 복잡도를 낮추는 게 낫다고 했다.

How to Apply

지금 진행 중인 일을 큐 파일로 옮기기
- 오늘 저장소에 tickets/ 폴더를 만들고 열려 있는 에이전트 작업마다 마크다운 파일 하나를 만들어라.
- 각 파일에 상태(대기·진행·내 판단 필요)와 다음에 필요한 결정을 한 줄로 적어라.
내 판단 대기 목록 스크립트 만들기
- 티켓 상태가 내 판단 필요인 파일만 모아 우선순위순으로 출력하는 스크립트를 짜라.
- 에이전트가 막히면 질문을 티켓에 적고 상태를 바꾸게 지시하라.
항목 하나씩 열고 닫는 규칙 정하기
- 한 항목을 열면 결정이나 요청을 마치고 티켓에 판정을 커밋한 뒤 닫아라.
- 배포 권한은 에이전트에게 주지 말고 직접 쥐어라.

Try It

복사해서 바로 해보기

# Claude Code에 붙여넣기 (저자 방법의 간이 버전: git 기반 티켓 큐)

이 저장소에 tickets/ 폴더를 만들고 다음 규칙으로 운영해 줘.
- 티켓은 마크다운 파일 하나이고 상단에 status: queued | building | needs-owner | done 를 적는다.
- 내 판단이 필요한 건 status를 needs-owner로 바꾸고 '결정할 것'을 한 줄로 적는다.
- 프로덕션 배포는 절대 하지 말고, 민감한 코드는 브랜치에서 작업한 뒤 먼저 물어봐.

지금 진행 중인 작업은 {{현재 작업 목록}}이야. 이걸 티켓으로 만들어 줘. 그리고 needs-owner 티켓만 우선순위순으로 요약해 줘.

이어서 해 볼 것: 한 항목씩 처리하고 판정을 티켓에 기록하게 한 뒤 다음 항목을 보여 달라고 해 봐.

Terminology

Brain Fry여러 AI 스레드를 오가다 머리가 과부하로 멈추는 상태다. 탭을 20개 열어 둔 브라우저처럼 머릿속 메모리가 꽉 찬 느낌이다.

Claude artifactClaude가 만들어 주는 독립된 한 페이지 결과물이다. 저자는 이걸 보드 현황과 리뷰를 보는 화면으로 쓴다.

owner inbox에이전트가 못 하는 결정만 모아 두는 받은편지함이다. 사람의 판단을 기다리는 항목만 보이는 대기열이다.

컨텍스트 전환작업 A에서 B로 넘어가며 머릿속 맥락을 갈아끼우는 비용이다. 요리하다 전화 받고 레시피 순서를 잊는 것과 비슷하다.

AI Brain Fry 이겨내기: git 기반 우선순위 큐로 에이전트 작업 관리

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

관련 논문

Related Resources

AI Brain Fry 이겨내기: git 기반 우선순위 큐로 에이전트 작업 관리

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

관련 논문

Related Resources