AI와 일할 때 뇌가 타버리는 이유, git 기반 우선순위 큐로 해결하다
How I Fight AI Brain Fry
Claude Code나 Codex로 작업하다 보면 수십 개의 스레드를 오가며 컨텍스트를 머릿속에 유지하느라 뇌가 과부하된다. 저자는 이 문제를 순서와 컨텍스트 두 가지로 나누고, 모든 티켓을 마크다운 파일로 git에 저장하는 우선순위 큐를 만들었다. 에이전트가 주기적으로 보드를 처리하고, 사람의 판단이 필요한 항목만 '오너 인박스'로 모아 준다. 한 번에 하나씩 열고 결정한 뒤 닫는 방식으로 집중을 되찾았다.
그 종료가 바로 핵심 비결이다. 티켓은 내 기억 속에 기억해야 할 대상으로 계속 매달려 있지 않는다. 컨텍스트도 함께 닫힌다.
HN 토론
207- eterm
나는 너무 많은 일을 동시에 처리하기보다는, 비록 '유휴' 상태라도 예전보다 훨씬 생산적이라는 사실을 받아들이는 법을 배웠다. 휴식을 취하고 재충전하며 성찰할 시간을 갖는 것이 중요하다.
그래서 나는 한 번에 최대 2~3개의 일로 제한하고, 그 모두가 오래 걸리는 세션이라면 어쩔 수 없지, 곧 다시 깊이 빠져들 거라는 걸 안다.
하지만 '딱 하나만 더 세션을 시작'하고 싶은 유혹이 크다. 특히 프로파일링을 개선하고 성능을 향상시키는 같은 일 말이다. 그건 엄청 생산적으로 느껴지지만, 종종 '유휴' 상태를 느끼지 않으려는 것에 불과하다.
- sollewitt
이건 문제의 일부만 해결한다. 나머지 절반은 이렇다: 좋아, 채팅 3개를 동시에 진행 중인데, 어느 순간 1만 줄이 넘는 CL 3개를 리뷰해야 하고, 게다가 동료들이 리뷰해 달라고 요청한 코드까지 있다는 걸 깨닫는다.
내가 해온 모든 리뷰에서 과적합되고 취약한 해결책, 통합되지 않고 덧붙여진 것들을 발견했기 때문에 코드 리뷰를 포기할 수 없다. 하지만 그게 나의 진짜 병목이고, 세 개를 동시에 하는 것은 하나보다 훨씬 나쁘다. 내 맥락과 이해가 희석되고 다소 혼란스러워지기 때문이다.
코드를 착지시키는 데 걸리는 시간을 측정하고 싶고, 하나에 직렬로 진행하는 것이 여러 개를 병렬로 진행하는 것보다 빠를 것 같다. 병렬은 더 빨라 보이지만 코드 리뷰가 더 오래 걸린다.
- docheinestages
애초에 왜 여러 스레드를 병렬로 시작하는가? 대기가 문제라면 그 하나의 작업을 여러 단계로 나눠야 할지도 모른다. 그렇게 하면 더 낮은 품질의 결과물만 더 많이 나올 뿐이다. 인간의 사고 능력은 변한 게 없다. 한 가지에 집중해서 끝내라.
- hetspookjee
나도 이런 형식을 시도해 봤지만 세션이 제공할 수 있는 풍부한 맥락이 빠져서 나에게는 맞지 않았다. 특히 다이어그램이나 HTML 파일에서 가능한 다른 멋진 서식이 부족했다. 잠시 Linear를 중간 브로커로 써 보기도 했지만 금방 터져 나갔고 탐색하기 너무 번거로워졌으며 빠르게 동기화가 깨졌다. 토큰 오버헤드도 비쌌다.
현재 내가 맡기는 일은 하나 이상의 에이전트 스레드를 프로젝트에 묶어 작업하게 하고, eleventy를 많이 활용해 마크다운 파일로 렌더링하는 아주 토큰이 가벼운 스킬을 펼쳐 놓는 것이다. 그런 다음 thisbit.ai(내가 만들고 아직 개발 중이다)와 결합해 기사의 모든 부분에 댓글을 달거나 음성으로 설명하면 에이전트가 거기서부터 다시 이어받는다.
또한 codex나 Claude code는 Gemini(Argon 4)의 멋진 TUI 렌더링에 전혀 가까이 가지 못한다.
- silcoon
문제는 맥락 전환이라고 생각한다. "AI 덕분에 세 가지 다른 작업을 동시에 할 수 있어"라는 말은 정말 힘을 실어주는 것처럼 보이지만, 실제로는 몇 분마다 사고 과정이 끊긴다면 한 가지 작업에 깊이 집중하는 것은 불가능하다.
화면 앞에서 유휴 상태에 있을 때마다, 에이전트가 주의를 필요로 하는 알림을 보내기 전 54초를 채울 다른 일이나 방해 요소를 찾아야 한다는 느낌이 든다. 이건 건강하지도 않고 인간의 뇌가 작동하는 방식도 아니다.
길고 방해받지 않는 깊은 집중 세션이야말로 지금까지 인간이 최고의 작업을 해낼 수 있게 해준 것이다.
- gb2d_hn
모두가 이 새로운 문제 세계에 대한 각자의 해결책을 만드는 것을 보는 게 흥미롭다. 내 해결책은 마크다운 노트에 더 집중하는 것이었다. https://app.etherpk.com 를 확장해서 모든 작업(순수 마크다운)을 위키링크(또는 여러 개) 아래 칸반 보드에서 볼 수 있게 했다. MCP 서버가 노트 그래프와 상호작용하는 방법을 안다. 작업에 대한 참조를 복사해서 에이전트에게 넘기면 에이전트가 거기서부터 작업 아래 블록들과 함께 작업한다. 기본적으로 에이전트에게 이미지, excalidraw 그림 등 정말 풍부한 맥락을 미리 줄 수 있고 에이전트가 진행하면서 작업을 업데이트할 수 있다는 뜻이다. 모든 것이 칸반 보드에 있으면 작업에서 벗어나 정말로 내 주의가 필요한 일을 하고 다시 돌아오기가 더 쉽다. 이것을 herdr와 함께 구성하니 매우 생산적이었다. 여전히 뇌가 타는 것을 지켜봐야 하지만 도움이 된다. 이 아이디어를 잘 팔고 있는지는 모르겠지만, 저자가 제안하는 것과 비슷한 여러 시스템을 실험한 후 뭔가를 발견한 것 같은 느낌이 든다. 나는 이것을 제품으로 만들기 위해 노력 중이다. 온보딩은 좀 더 간소화해야 하지만 로컬 그래프에는 무료로 사용할 수 있다.
- AnotherGoodName
나는 이제 tmux에서 에이전트와 함께 제공되는 앱으로 옮겨갔다.
주로 진행 중인 작업 흐름을 한눈에 보고, 각각 자체 세션인 작업과 하위 작업의 트리(에이전트 세션의 분기 트리를 가질 수 있다)를 가질 수 있기 때문이다. 이 앱들은 tmux 세션으로 원격 접속할 수도 있어서 워크플로우가 바뀌는 것이라기보다는 표현 방식이 바뀌는 정도다. 멀티미디어 입력/출력도 좋다.
아직 완벽하지는 않지만 미래의 개발 환경이 점점 더 작업 관리에 초점을 맞출 것이라는 것은 꽤 분명하다. 어떤 작업이 진행 중인가? 그 작업들은 서로 어떻게 관련되어 있는가? 무엇이 당신의 주의를 필요로 하는가?
- plasticchris
대화형 협업 텍스트 편집이 나왔을 때를 기억하는가?
미래는 이것이겠지만, 대화형 협업 에이전트 세션이 될 것이고, pi durable 같은 것들은 이미 그 방향으로 나아가고 있다.