RicoCheese기술 뉴스와 기록
← 목록으로
뉴스2026-09-1117

내 에이전트는 지치지 않는다, 나는 지친다 — 새티스파이싱이라는 멈춤 신호

지치지 않는 코딩 에이전트에게 일을 넘긴 뒤, 작업을 끝낼 시점을 정해주던 인간의 한계가 사라졌다. 허버트 사이먼의 새티스파이싱 개념을 빌려 '멈춤 표지판'을 계획 단계에 직접 심는 방법을 정리한 글이다.

#ai#productivity#programming#discuss#llm
My Agents Never Get Tired. I Do: On Satisficing

개요 #

화요일 아침, 프롬프트 하나를 승인하고 차를 우리러 갔다. 머그를 들고 돌아왔을 때 작업 블록은 이미 끝나 있었다. 테스트까지 붙었고, 요청한 것보다 훨씬 꼼꼼했다. 그 자리에 서서 글쓴이는 깨달았다. 그 꼼꼼함이 이 블록에 필요한지 자기가 판단한 적이 없다는 것을.

캘리포니아 법원에서 카운티 법정 운영을 맡고 있는 Earl Grey(Lara Cordero)는 2025년 7월부터 AI로 개발을 시작해 공개 저장소 62개를 쌓았다. 해커톤 3회 우승, 챌린지 2회 우승, 공공부문 AI 강연 2회. 코드를 쓰는 에이전트 Kiro는 지치지 않고, 그것을 리뷰하는 Claude도 지치지 않는다. 지치는 쪽은 사람이고, 그럼에도 계속 일한다.

이 글은 해결책을 발표하는 글이 아니다. 글쓴이 본인이 "아직 그 안에 있다"고 못 박는다. 다만 속도 이야기는 넘치는데 어떻게 끝낼지, 무엇을 시작할 가치가 있는지 정하는 이야기는 잘 보이지 않는다는 문제 제기다.

버릴 폴더라고 태그해놓고 프로덕션 수준으로 만들었다 #

발단은 이전 글에서 다룬 Porch Light의 Block Zero다. Porch Light는 캘리포니아 벤투라시의 공개 회의 안건을 읽어주는 시빅 테크 도구고, Block Zero는 단 하나의 질문에 답하려고 만든 단계였다. 이 스택이 배포는 되는가. 그날 아침 글쓴이는 폴더에 [THROWAWAY] 태그를 붙이고 2시간을 예산으로 잡았다.

결과는 하루짜리 빌드였다. 삭제 예정으로 표시된 폴더 안에 벤더링된 로깅 모듈을 지키는 바이트 동일성 테스트, 정확한 의존성 고정, 드리프트 감지가 붙은 동기화 스크립트가 들어섰다. Kiro가 제안했고, Claude는 리뷰하면서 반대하지 않았고, 글쓴이가 승인했다. 하나하나는 전부 방어 가능한 결정이었다.

빠진 건 이유였다. 그 태그를 들여다본 사람이 아무도 없었다는 것 말고는. 과설계하지 않겠다고 다짐하고 들어간 빌드에서 과설계가 나왔다. 댓글에서 Mikhail이 짚은 대목이 핵심이다. 함정을 안다고 해서 면역이 생기지는 않는다. 체크리스트에 모두가 아는 항목이 굳이 적혀 있는 이유와 같다.

내가 멈추는 이유가, 에이전트가 멈추지 않는 이유다 #

답의 실마리는 엉뚱하게도 스포츠 기사에서 나왔다.

NFL 선수 크리스 볼랜드는 뇌 손상 우려로 24세에 은퇴했다. The Athletic에 기고한 에세이에서 그는 은퇴 이후 10년, 그리고 추진력과 만족감을 동시에 갖는 일의 어려움을 이야기한다. 거기서 글쓴이가 마주친 단어가 새티스파이싱(satisficing) 이다. 볼랜드의 표현으로는 기준을 낮추는 게 아니라, 수확 체감이 시작되는 지점에 세워둔 정지 표지판이다.

이 단어는 허버트 사이먼이 satisfy와 suffice를 합쳐 만들었다. 사이먼은 제한된 합리성(bounded rationality)으로 1978년 노벨 경제학상을 받았다. 사람은 결정 기계가 아니라는 것, 시간과 정보와 주의력이 유한하기 때문에 모든 정보를 받아들여 최적해를 뽑아내지 못한다는 것이다(Simon, 1955).

그 한계 안에서 살아가는 전략은 세 단계다.

  1. 무엇이 충분히 좋은지 기준을 정한다.
  2. 그 기준을 처음 넘긴 것을 택한다.
  3. 다음으로 넘어간다.

일을 하는 건 3번이다. 낭비의 대부분은 첫 번째 합격점보다 아주 조금 나은 답을 찾아 헤매는 데서 발생한다.

헤드셋을 쓰고 작업 중인 사람 Photo by Tima Miroshnichenko on Pexels

사이먼은 환경이 문제 공간(problem space)을 통해 결정을 형성한다고도 했다(Simon, 1956). 문제에서 해답까지 가려면 건너야 하는 땅이 있는데, 어떤 땅은 단순해서 노력이 곧바로 보상으로 이어진다. 힘을 키우려면 웨이트를 하면 된다. 반면 복잡한 땅에서는 노력만으로 보상이 오지 않는다. 더 갈아넣을수록 더 나은 결과가 아니라 우유부단과 과부하가 쌓인다.

Block Zero를 다시 보게 만든 대목은 여기다. 새티스파이싱은 결핍에 대한 적응이다. 우리가 멈추는 건 시간이 떨어지기 때문이고, 애초에 그 본능은 거기서 나왔다.

에이전트에게는 그런 결핍이 없다. Kiro는 무언가 자기를 멈춰 세울 때까지 버릴 폴더를 계속 단단하게 만들고, 거기서 추가되는 것들은 국소적으로는 전부 맞는 판단이다. 자정에도 피곤하지 않고, 프로젝트에 형태가 있다거나 그 형태에 끝이 있다는 감각이 없다. 작업을 멈추게 하던 제약은 사람 쪽에 있었고, 글쓴이는 그 제약을 공유하지 않는 존재에게 작업을 넘겼다.

빌드만의 문제도 아니다. Claude가 아키텍처와 문서 초안을 잡고, ChatGPT가 기술 선택에 의견을 내고, Gemini가 비주얼을 만들고, Kiro가 코드를 쓴다. 모든 단계가 빨라졌는데, 여기에는 무언가를 시작할 가치가 있는지 판단하는 단계도 포함된다. 그 단계에는 테스트 스위트도, 체크포인트도, 결정을 대조해볼 diff도 없다. 머그를 들고 서 있던 자리가 바로 그 단계였다.

그래서 정지 표지판은 이제 손으로 직접 세워야 한다. 이것이 새로 생긴 일인지, 원래 하고 있었지만 하고 있다는 자각이 없던 일인지 — 글쓴이는 새로 생긴 일 쪽에 무게를 둔다.

정지 표지판은 의지가 아니라 계획서에 넣는다 #

규모가 둘이니 장치도 둘이다.

블록 단위: 엄격도 예산(rigor budget). 이전 글에서 이 표현을 쓰긴 했지만 어떻게 만드는지는 몰랐다. 댓글 두 개가 형태를 잡아줬다.

Suzanne Chartier는 작업이 탐색용인지, 임시인지, 프로덕션행인지에 따라 엄격도 단계를 정의하는 스티어링 문서를 제안했다. 어느 단계를 적용할지는 사람이 결정한다. anassBld는 자기 팀이 스파이크 작업에 강제하는 규칙을 설명했다. Phase 0에서는 추상화 제로. 평평한 스크립트 하나, 자격증명 직접 확인, 호출 한 번, 출력 검증, 결과 출력, 종료. 아키텍처는 실제 환경에서 실행이 증명된 다음에.

지금 돌리는 방식은 둘을 합친 것이다. 프롬프트를 내보내기 전에 모든 블록에 티어를 부여하고, 기준은 질문 하나다. 블록이 통과한 뒤 이 코드는 어떻게 되는가. 폐기하면 스파이크 티어, 유지하고 그 위에 쌓으면 워킹 티어, 사용자가 만지면 풀 티어.

실제로 강제력을 갖게 만든 건 티어를 노력 수준이 아니라 금지 목록으로 적은 것이다. "스파이크 수준의 엄격도"는 아무도 검증할 수 없는 느낌이다. "테스트 파일 금지, 의존성 고정 금지, 동기화 스크립트 금지, 이 폴더 밖 리팩터링 금지"는 diff에 대조할 수 있는 목록이고, 에이전트도 대조할 수 있다. 티어는 스티어링 문서에만 두지 않고 프롬프트 안에도 넣는다. 1년째 모든 프롬프트에 들어가 있는 "다른 코드를 리팩터링하지 말 것" 줄 옆에.

어떤 티어에서도 미룰 수 없는 항목도 있다. 아웃바운드 레이트 리미팅 — 스크래핑 루프는 첫 실행부터 누군가의 시청 서버를 때린다. 로그에 절대 들어가서는 안 되는 값 — Porch Light에서는 모델의 사고 과정을 stdout에 찍는 프레임워크 기본값 때문에 실제 유출이 발생했다. 모든 fetch에 try/catch. 비용과 루프 상한. 이것들은 코드 품질 문제가 아니라, 어떤 체크포인트도 잡아내기 전에 저장소 밖에서 벌어지는 피해다.

프로젝트 단위: 첫날에 쓰는 마무리 블록. 이건 다른 데서 본 적이 없다고 글쓴이는 말한다. 따르던 규칙이 실패하고 있었기 때문에 만들었다.

기존 규칙은 "재미가 사라지면 프로젝트를 선반에 올린다"였다. 문제는 장치 없는 규칙이 그냥 포기하는 것과 구분되지 않는다는 점이다. 그래서 Porch Light의 빌드 플랜에는 Block 1보다 먼저 쓰인 Block 7이 있다. 수상자 발표 다음 날 무슨 일이 벌어질지를 그 순간이 아니라 미리 정해둔 것이다. 월 지출 상한을 넘기면 스스로 휴면 상태로 들어가고, 미래의 자신에게 남기는 인수인계 노트에는 이 도구가 하는 일, 스텁으로 남긴 것과 그 이유, 다시 집어들 만한 조건이 담긴다. 그리고 수상하지 못한 경우까지 포함한 정직한 기록 한 줄.

선반에 올리는 일을 포기가 아니라 완료된 단계로 바꾸는 건 이 장치다. 다만 Block 7은 아직 실행되지 않았다. 글쓴이의 표현으로는 "10월에 다시 물어봐 달라".

더 많이 만드는 게 맞을 때도 있다, 기준은 반대편에 누가 있는가 #

Block Zero가 하루를 잡아먹은 경험은 다음 질문으로 이어졌고, 이번엔 빌드 전체에 대고 물었다. 안건 열다섯 건을 읽는 데 이 파이프라인은 과설계 아닌가. 실행 락, 재시도 레이어, 지출 상한, 정직한 빈 상태 처리 — 작은 도시 하나를 위해.

답은 아니오였고, 이유는 코드와 무관했다. 공개 회의 안건을 감시하는 도구는 이미 존재한다. 로비스트와 대관 담당 팀에게 팔리고, 안건 감시가 업무인 사람들 기준으로 가격이 매겨져 있다. 주차장을 잃을지도 모르는 주민에게는 아무것도 없다. 불안정한 시빅 버전은 결국 그 엔터프라이즈 가격이 옳았다는 것, 이건 원래 어려운 일이고 보통 사람은 기대하면 안 된다는 것을 증명한다. 안정적인 버전은 그 반대를 증명한다.

그러니 안정성 작업은 장식이 아니라 주장 자체였다. 코드가 어떤 느낌인지 물어서는 여기까지 올 수 없다. 반대편에 누가 있는지, 그리고 허술한 버전이 그 사람에 대해 무엇을 증명하게 되는지 물어야 도달한다.

남은 질문 #

두 장치 모두 작업을 멈춘다. 하지만 어느 쪽도 작업량이 얼마여야 하는지는 정해주지 않고, 글쓴이가 막혀 있는 지점도 거기다. 에이전트는 지치지 않으므로 지치는 몫은 전부 사람에게 오고, 무엇을 떠안을지는 오롯이 본인 문제가 된다.

글이 끝나는 자리에는 해답 대신 질문이 놓여 있다. 다음에 무엇을 시작할 것이며 그 정직한 이유는 무엇인가. 아직 잘 굴러가는 것을 멈출 적기는 언제인가. 이 속도는 한 시즌인가 습관인가, 그 차이가 중요하긴 한가. 답이 속도를 늦추는 것인지 재조직하는 것인지 — 둘은 같은 선택이 아니다.

글쓴이는 다른 사람들의 답을 묻는다. 생산성 답변 말고 진짜 답. 무엇을 잘라냈고, 그 대가는 무엇이었고, 그만둘 때가 됐다고 알려준 신호는 무엇이었는지.

참고 문헌 #


이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.

댓글GitHub Discussions