무엇을 판매하려는 것이 아닙니다. 그저 제가 느린 방식으로 몇 달을 배우기 전에 누군가 저에게 말해줬으면 좋았을 내용들을 공유하려는 것입니다. 사람들이 게시하고 있는 설정 방식은 실제로 유효하며 실행할 가치가 있습니다: 저렴한 VPS를 사용하고, Claude Code를 설치하고, 보안을 강화하며(Tailscale과 방화벽을 사용하고 인바운드 차단), tmux에서 실행하고, 휴대폰으로 SSH 접속을 하는 방식입니다. 그 부분은 오후 한나절이면 끝납니다. 하지만 그 이후에 발생하는 문제들을 제가 겪은 순서대로 말씀드리겠습니다.

첫째, 휴대폰의 터미널은 형편없습니다. 붙여넣기도 안 되고, 이미지도 안 보이며, 텍스트는 너무 작고, 손가락 실수로 한 번 잘못 누르면 세션이 종료됩니다. 저에게 효과적이었던 방법은 더 나은 터미널을 찾는 것이 아니라, 터미널을 벗어나는 것이었습니다. 휴대폰에서 실제로 하는 작업은 diff(차이점)를 읽고 '예' 또는 '아니오'를 말하는 것이므로, 저는 이를 위한 실제 인터페이스를 구축했고, 진정으로 쉘(shell)이 필요할 때만 터미널을 남겨두었습니다. 이 인터페이스는 시간이 지나며 발전했습니다. 처음에는 Termius였고, 그다음에는 데스크톱과 휴대폰에서 작동하는 반응형 웹 앱이었으며, 그다음에는 알림 기능이 있는 네이티브 모바일 앱이 되었습니다. 각 단계는 그 주에 저를 느리게 만들었던 문제를 해결하는 과정이었으며, 이것이 바로 제 작업 방식에 맞게 최적화된 이유이기도 합니다.

둘째, 세션이 끊기면 작업 위치를 잃어버립니다. tmux는 연결 끊김에는 살아남지만, 재부팅이나 로그인 만료에는 살아남지 못합니다. 가장 중요한 부분은 이것입니다: 세션이 다시 돌아왔을 때, 단순히 같은 폴더에 있는 새로운 세션이 아니라 히스토리가 포함된 실제 세션을 재개해야 합니다. 세션에 이름을 붙이고, 재개 ID(resume id)를 유지하며, 자동으로 복구되도록 하세요.

셋째, 휴대폰으로는 제대로 된 리뷰를 할 수 없기 때문에, 그냥 무조건 승인하거나 아니면 작업을 멈추게 됩니다. 둘 다 나쁜 상황입니다. 저는 채팅창이 아닌 리뷰 인터페이스를 구축했습니다: diff를 보고, 생성된 결과물의 스크린샷을 확인하고, 두 번의 탭으로 승인하며, 실제로 제 확인이 필요한 경우에만 저를 찾아오도록 만들었습니다.

넷째, 잘못된 설정 하나로 돈을 낭비하게 됩니다. 여기 어떤 분은 제한 설정을 놓쳐 4,700달러를 썼다고 고백했습니다; 저 또한 제 예산의 상당 부분을 무한 루프(runaway loop)로 인해 날렸습니다. 아무것도 무인(unattended)으로 실행하기 전에 엄격한 지출 한도(hard spend caps)와 루프 종료 스위치(loop kill switch)를 설정하십시오. 루프가 에이전트(agents)를 트리거할 수 있는 순간, 당신이 자는 동안에도 비용을 지출할 수 있습니다.

다섯째, 하나의 세션이 열 개가 되면 혼돈이 찾아옵니다. 어떤 것이 어떤 것인지, 어떤 계정인지, 어떤 모델인지 알 수 없게 됩니다. 터미널의 더미(pile)로 취급하지 말고, 콘솔(console)을 갖춘 함대(fleet)처럼 관리하십시오.

비용에 따라 모델을 경로 지정(Route)하십시오: 단순 작업(grunt work)을 위해서는 저렴하고 빠른 모델을, 까다로운 검토(hard reviews)를 위해서는 가장 뛰어난 모델을 사용하십시오. 에이전트(agents)는 당신이 검토할 수 있는 양보다 더 많은 결과물을 만들어내며, 이제 당신이 병목 현상(bottleneck)이 됩니다. 에이전트와 메인 브랜치(main branch) 사이에 당신이 아닌 자동화된 게이트(automated gate)를 두십시오. 이는 지루한 변경 사항을 걸러내고 인간의 개입이 필요한 사항만 에스컬레이션(escalate)합니다. 에이전트 하나를 실행하는 것은 결코 어려운 부분이 아니었습니다. 실제로 중요한 작업은 그 에이전트 함대(fleet)를 둘러싼 프로세스입니다. 무언가 고장 나고 몇 시간 동안 조용히 모든 것을 차단할 수 있습니다. 대부분의 고장은 오래된 락파일(lockfile)이나 환경 불일치(env mismatch) 같은 쓰레기 같은 문제이므로, 당신이 알 필요도 없이 자동으로 복구(auto-heal)되도록 하십시오. 실제 회귀(regressions) 문제는 파이프라인을 막아두는 것이 아니라, 원인이 된 변경 사항에 표시(pinned)하여 다시 돌려보내야 합니다. 저는 한때 멍청한 관리자(janitor)가 자신이 일으킨 고장을 100번 넘게 "수정"하려 했던 적이 있습니다. 그런 시스템을 만들지 마십시오. 사람들은 지금 이 다음 단계를 "루프에서 그래프로(loops to graphs)"라고 부르고 있습니다. 이름은 계속 바뀌겠지만, 그 본질은 변하지 않을 것입니다. 명확한 테스트 통과 기준이 있는 루프는 괜찮습니다. 통과(green)할 때까지 실행되고 멈추기 때문입니다. 문제는 하나의 에이전트가 전체 작업을 단일 컨텍스트(single context)에 담고 있을 때 발생합니다. 이 경우 에이전트가 어느 부분에서 막혀 있는지 볼 수 없고, 각 부분에 서로 다른 게이트나 모델을 적용할 수 없으며, 세션이 종료되었을 때 깔끔하게 재개할 수도 없습니다. 각 단계(stages)를 파이프라인(pipeline)으로 추출하여 이름이 지정된 단계(named steps), 실제 상태(real state)를 갖추고 각 단계마다 개별적인 게이트를 두면 이 문제는 해결됩니다. 저의 해결책은 멈춰버린 에이전트가 실제로 무엇을 하고 있는지 볼 수 없었던 데서 시작되었습니다. 그 과정 어딘가에서 작업이 조용히 변합니다. 당신은 더 이상 실제로 코딩을 하는 것이 아니라, 코딩을 하는 기계를 만드는 것이며, 코드를 작성하는 것에서 제약 조건(constraints)을 설정하고 지표(metrics)를 관찰하는 것으로 이동하게 됩니다. 이는 다른 종류의 어려움이며, 작은 팀을 운영하는 것에 더 가깝습니다. 어떤 날은 예전 방식이 그립기도 합니다. 하지만 대부분의 날에는 이것이 제 시간을 가장 가치 있게 쓰는 방법입니다. 이번 주에 모두가 1단계에 머물러 있습니다. 저를 사로잡은 것은 그 다음 단계였으며, 이는 제가 지난 몇 년간 무언가를 만들며 느꼈던 가장 큰 즐거움이었습니다. 다른 분들은 어떤 결론에 도달했는지 궁금하군요. submitted by /u/mrtrly [link] [comments]