프런트엔드 AX 설계기 11편 — 설정도 코드처럼 부채가 쌓인다

설정을 열었더니 코드 부채 냄새가 났다

열 편에 걸쳐 권한 경계부터 검증 게이트, 자율 모드까지 AX(에이전트가 일하는 방식, Agent Experience) 체계를 쌓았다. 그러다 어느 날 설정 파일을 열었는데, 익숙한 냄새가 났다. 코드 부채의 냄새였다.

몇 달 전에 넣은 룰이 지금 워크플로와 어긋나 있었고, 같은 지시가 두 파일에 조금씩 다르게 적혀 있었고, 언젠가 쓸 것 같아 넣어둔 커맨드는 한 번도 실행된 적이 없었다. 레거시와 차세대 프로젝트를 동시에 들고 있는 나 같은 프런트엔드 개발자에게, AI 설정은 어느새 또 하나의 코드베이스가 되어 있었다. 그리고 코드베이스라면, 추가만 하는 순간부터 망가지기 시작한다.

설정에도 운영 루프가 필요하다 — 흡수(+)와 정리(−)

설정 부채는 코드 부채와 똑같이 작동한다. 한 줄로 정의하면, 지금의 워크플로와 어긋나 있는데도 남아서 콘텍스트를 갉아먹는 모든 룰·커맨드·문서다. AI 설정은 특히 잘 쌓인다. 지우는 건 무섭고(혹시 나중에 필요하면?), 추가는 쉽고(트렌드 글 하나 읽을 때마다), 효과는 당장 눈에 안 보이기 때문이다.

Anthropic이 context engineering에서 "토큰을 curation 한다"라고 말하는 것과 같은 이야기를, 나는 설정 파일 레벨에서 하고 있었다. 그래서 열 편을 지나며 내린 결론은 이거였다 — 설정에도 운영 루프가 필요하다. 새로운 걸 안으로 들이는 흡수(+)와, 낡은 걸 밖으로 덜어내는 정리(−), 두 방향으로.

흡수(+)는 다시 두 갈래다. 하나는 안에서 밖으로(inside-out) — 내가 방금 끝낸 작업에서 반복되는 패턴을 뽑아 룰로 승격시키는 /compound. 다른 하나는 밖에서 안으로(outside-in) — 바깥의 믿을 만한 출처를 훑어 내 설정 진화에 관련된 것만 끌어오는 /my-radar. 둘 다 곧장 설정으로 들어가지 않고, 가운데 있는 흡수 게이트를 통과해야 한다. 게이트가 하는 일은 채택이 아니라 판정이다: 수용(adopt) / 보류(watch) / 기각(skip).

바깥에서 안으로: /my-radar가 실제로 걸려 넘어진 곳

이번 편에서 새로 붙인 건 outside-in 쪽, /my-radar다. inside-out인 /compound가 "내 완료 작업에서 패턴을 뽑는다"면, /my-radar는 그 반대편에서 canonical 한 AI 출처들을 병렬로 fan-out 스캔해 delta만 뽑는다. 여기서 진짜 문제는 스캔이 아니라 기억이었다. 트렌드 인테이크를 자동화하면 가장 먼저 부딪히는 게 "어제 본 걸 오늘 또 들고 온다"이기 때문이다.

그래서 2-tier memory를 뒀다. seen-ledger는 이미 본 URL을 통째로 차단해 스캔을 멱등하게 만든다 — 같은 소스를 다시 훑어도 새 항목만 나온다. watch-list는 "지금은 아니지만 나중에 다시 볼 것"을 따로 적재해 다음 스캔에서 재평가한다. 이 둘이 없으면 radar는 매번 같은 소음을 증분 없이 토해낸다.

한 가지 더, cwd 이식성 함정이 있었다. 이 커맨드는 아무 프로젝트 폴더에서나 호출될 수 있는데, 상태 파일을 실행 위치(cwd) 기준으로 쓰면 엉뚱한 레포에 seen-ledger가 흩어진다. 그래서 커맨드는 항상 설정 레포 루트를 먼저 해석하고, 그 기준으로만 상대경로에 쓴다.

솔직히 밝혀두면, radar가 뽑은 adopt 후보를 대상 설정 파일 경로에 매핑해 자동 변경 제안까지 잇는 "닫힌 루프"는 아직 구현이 아니라 설계 방향이다. 측정도 n=1 수동 실행 몇 번 뿐이라 자랑할 파이프라인은 없다. 다만 자동 인테이크가 실전에서 걸려 넘어지는 지점들(멱등성·재평가·경로 해석)을 먼저 풀어뒀다는 정도가 지금 손에 쥔 것이다.

커맨드 스펙은 결국 상태·절차·가드다

outside-in 커맨드의 뼈대를 스펙으로 옮기면 이렇게 생겼다. 프롬프트 장식은 걷어내고 상태·절차·가드만 남겼다. 이 셋만 맞으면 나머지 문장은 취향이다.

# /my-radar — outside-in 트렌드 인테이크 (스펙 발췌)
목적: canonical AI 출처를 fan-out 스캔 → "내 설정에 관련된" 항목만 delta로 추출

상태(2-tier memory):
  seen-ledger.jsonl   # 이미 본 URL. 중복 완전 차단 → 스캔을 멱등하게
  watch-list.md       # "지금은 보류, 다음 스캔에서 재평가" 후보

절차:
  1. 출처 fan-out 스캔 (병렬 서브에이전트)
  2. 각 항목을 seen-ledger와 대조 → 신규만 통과   # edge: 중복 URL은 여기서 탈락
  3. 신규 항목을 delta로 분류: adopt / watch / reading / skip
  4. adopt에는 "이 파일을 이렇게 바꾸자" 제안을 붙인다 (경로 매핑)
     #  여기까지는 '제안'만 — 자동 반영은 설계 방향(미구축)
  5. watch는 watch-list.md에 적재            # edge: 다음 스캔에서 재평가

이식성 가드 (cwd gotcha):
  # 이 커맨드는 임의의 프로젝트 폴더에서 실행될 수 있다.
  # cwd가 아니라 '설정 레포 루트'를 먼저 해석하고, 그 기준으로만 write 한다.
  repo_root = resolve_config_repo_root()
  write(f"{repo_root}/my-radar/seen-ledger.jsonl", new_items)
  #     ✅ 레포 루트 기준          ❌ write("./seen-ledger.jsonl")  ← cwd로 새면 상태가 흩어짐

주석에 박아둔 세 지점 — 중복 URL 탈락, watch 재평가, cwd 해석 — 이 커맨드가 실전에서 깨지지 않는 이유의 거의 전부다.

흡수의 미덕은 속도가 아니라 판정이다

여기까지가 흡수를 어떻게 하느냐라면, 더 중요한 건 흡수를 언제 하지 않느냐였다. 초반엔 나도 좋은 글을 보면 곧장 룰로 만들었다. 게이트를 하나 더 다는 게 발전이라고 믿었으니까. 세 번의 흡수를 거치며 그 습관이 틀렸다는 걸 알았다.

첫 번째. Claude Code에 dynamic workflow라는 신기능이 나왔을 때, 이걸로 AX를 근본부터 단순화할 수 있나 진지하게 검토했다. 결론은 "아직 이르다"였다. 그런데 폐기하지 않고 watch-list에 남겼다. 흡수 게이트의 핵심은 "받는 즉시 반영"이 아니라 수용·보류·기각을 판정하는 것이고, 보류는 실패가 아니라 정상 출력이다.

두 번째. 정작 그 신기능이 값을 한 건 흡수 대상이 아니라 흡수 도구로 쓰였을 때였다. 에이전틱 코드리뷰에 관한 외부 글(Addy Osmani)을 그 dynamic workflow로 현 워크플로와 대조했더니, 채택 4건 · 기각 5건이 나왔다. 비 자명한 발견은 채택 4건이 전부 "새 게이트 0개, 기존 계약 문구를 reshape"였다는 점이다. 기각 5건은 "작성자의 서사를 그대로 되먹임"하거나 "잘못된 타이밍에 ceremony를 하나 더 얹는" 것들이었다. 흡수의 레버리지는 LLM 게이트를 추가하는 데 있지 않고, 이미 있는 계약의 문구를 다듬는 데 있었다. (이 흡수의 채택분이 7편의 변조 탐지를 비롯해 이후 편들의 실제 출처가 됐다.)

세 번째. 외부 codegraph 도구와 LLM 위키 생성기를 "우리 워크플로에 합당한가"를 팩트 기준으로 따진 뒤 도입을 보류했다. 정리(−) 루프가 무분별한 흡수를 막은 사례다.

정리하면 흡수 3건 중 2건이 보류, 1건만 채택 — 그 1건마저 새 게이트가 아니라 계약 reshape였다(내 워크플로에서의 관측치, n=3). 이 비율이 이번 편에서 하고 싶은 말의 전부다. 좋은 트렌드일수록, 받는 즉시 반영이 아니라 판정을 먼저 통과시켜야 한다.

정리(−) 방향은 흡수의 거울상이다. stale·duplicate 룰을 주기적으로 걷어내고, curation report로 "안 쓰는 룰"을 가시화하고, 발행 전 pre-flight로 중복을 잡는다. 코드에 리팩터링이 있듯, 설정엔 curation이 있다.

시리즈는 닫지만, 루프는 닫히지 않는다

설정은 코드처럼 부채가 쌓인다. 그래서 계속 추가하는 것보다, 흡수(+)와 정리(−)를 도는 운영 루프가 어느 순간부터 더 중요해진다. 흡수의 미덕은 속도가 아니라 판정이다 — 좋은 트렌드일수록 "수용·보류·기각" 중 어디인지를 먼저 묻는다.

지금 당장 할 일은 하나다. 다음 룰을 추가하기 전에, 지난달 넣은 룰 중 오늘도 실제로 쓰는 게 몇 개인지 세어보라. 그 숫자가 당신에게 정리(−) 루프가 필요한지 말해준다.

참고

• Andrej Karpathy, "Software Is Changing (Again)" (Software 3.0) — https://www.ycombinator.com/library/MW-andrej-karpathy-software-is-changing-again
• Anthropic, "Effective context engineering for AI agents" — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Addy Osmani, "Agentic Code Review" — https://addyosmani.com/blog/agentic-code-review/

본문의 흡수 채택/기각 수치는 내 워크플로에서의 관측 count(n=3)이며 일반 통계가 아니다. 신기능·도구의 동작은 2026년 상반기 기준이다.

 

2026.07.23 - [AI 엔지니어링] - 프런트엔드 AX 설계기 10편 - 단가가 아니라 실패비용으로 모델을 고른다