결정론적 피드백이 더욱 필요하다고 봄. 최근 린트 오류 메시지에 문제 해결 방법까지 담는 접근을 시도했는데 효과가 놀라웠음. https://habit-hooks.com/
예를 들어 IOSP(통합·연산 분리 원칙) 를 정착시키는 데 활용 중임.
README부터 AI가 양산한 저품질 글처럼 읽히는데, 이 도구가 그런 결과물을 막아준다고 믿을 이유가 있을까?
어떤 방식을 쓰든 작성된 지침을 강제할 수단이 필요함. “JSON을 파싱하는 Python 스크립트를 작성하지 말고 jq를 써라”라고 했으면 임시 Python 스크립트를 만들면 안 되는데, 실제로는 계속 그렇게 함.
oh-my-pi의 /omfg 명령에 에이전트 응답의 잘못된 부분을 설명하면, 재발 방지용 훅을 작성해 줌. 이어서 이전 프롬프트를 다시 실행해 훅이 작동하는지 확인하고, 작동하지 않으면 훅을 수정함.
이후 모든 응답을 훅으로 검사하고, 조건에 걸리면 무엇이 잘못됐고 어떻게 바꿔야 하는지 에이전트에 피드백을 전달함.
다른 소프트웨어 시스템과 똑같이 다루면 됨. 절대 위반하면 안 되는 규칙은 정적 타입 검사나 신뢰할 수 있는 런타임 감시기로 강제해야 하며, 다른 선택지는 없음.
AI는 용도가 제한적인 CLI 도구인 jq보다 온갖 작업에 쓰이는 임시 Python 스크립트에 훨씬 익숙한 것이 당연함.
Python 스크립트를 만드는 모습이 꽤 귀엽다고 느끼지만, 적절한 전용 도구가 PATH에 있을 때도 그러는 것은 본 적이 없음. 각성제를 먹은 역대 최고로 유능한 인턴 같음. SVG를 PNG로 변환할 도구가 없으면 곧바로 Python 프로그램을 만들어 해결함.
최근에는 기억 대신 원칙을 작성하기 시작함. 에이전트가 언제나 따라야 할 사고 패턴을 정리하고, 원칙에 버전을 붙여 코드 주석에서 해당 버전을 인용하도록 했음. 원칙이 바뀌면 코드도 함께 발전하게 하려는 취지임.
친구들과 공유할 수 있도록 묶어둔 것이 https://principledriven.dev/임. 아직 발전 중이지만 지난 두 달가량 매우 유용했고, 최신 모델에서는 효과가 더 좋아짐. 에이전트의 원칙 준수 수준도 기대 이상임.
에이전트가 호출하도록 지시하는 CLI 도구를 만들었음. 도구가 몇 가지 질문에 대한 답을 받은 뒤 행동 지침을 반환하고, 필요하면 추가 질문부터 던짐. 질문은 에이전트의 현재 상태를 파악하도록 설계했으며, 도구를 바꾸면 에이전트의 작업 방식도 바뀜. 호출을 잊지 않도록 사용을 필수 절차로 만들어야 함.
원칙이나 기억보다 개방적인 질문은 정책을 전달하기 전부터 적절한 사고방식을 유도하기도 함. 에이전트는 눈앞의 작업에 매몰돼 큰 그림을 놓치곤 하는데, 질문으로 다시 큰 그림에 주의를 돌릴 수 있음. ssp(State-Space Policy) 를 인자 없이 호출하면 저장소의 특성을 읽고 상태를 추정해 질문 4~5개를 보냄. 첫 답변으로 상태를 좁혀 추가 질문을 보내고, 두 번째 답변으로 상태를 확정한 뒤 행동 지침을 할당함. 세션 로그를 남기고 이를 검토해 질문과 지침을 개선함.
흥미롭지만 곳곳의 큼직한 글씨 때문에 문서 사이트보다 마케팅 사이트처럼 보여, 실제로 어떻게 작동하는지 파악하기 어려움.
에이전트 전용 문서를 따로 두고 싶지는 않음. mattpocock/skills로 아키텍처 결정 기록(ADR) 을 생성하며, AGENTS.md에 몇 가지 참조 지침을 적어주는 설정용 스킬을 포함해 스킬만 사용함.
개발 절차는 CONTRIBUTING.md에, 코딩 규칙은 CODING_STANDARDS.md에 작성함. 여기에 README.md, 아키텍처 문서, 커밋 메시지가 있으면 에이전트가 필요한 문서를 찾아 활용하고 최신 상태로 유지하는 편임. 명세도 많이 작성해 GitHub 이슈에 넣고 있음.
나는 기본적으로 문서·테스트(TDD)·코드의 반복 과정을 사용함. IMPLEMENT-.md로 시작해 TDD 방식으로 수정하도록 요청한 뒤 반복함.
qwen3.8-flash-next가 나온 이후에는 동적 문맥 가지치기로 사실상 끝없이 진행할 수 있게 됨. 로컬 코딩에서 흥미로운 방식임.
평가 결과가 없으면 입증됐다고 볼 수 없음. 농담은 접어두고, 이런 시스템의 성능을 어떻게 평가하며 어떤 작업에 어떤 접근법이 가장 잘 맞는지 정말 궁금함.
뇌에는 관계를 문장으로 표현하지 않고도 경험을 정리하는 메커니즘이 있음. 그래프 데이터베이스에서 관계를 조회하듯, 앞뒤 맥락이나 원인·결과를 바탕으로 관련 아이디어를 빠르게 찾을 수 있음.
문서는 이런 방식으로 효율적으로 조회할 수 없으니 데이터베이스가 필요함.
취지는 이해하지만 그래프 데이터베이스를 뇌의 작동 방식과 비교하는 것은 성급해 보임. LLM과 그 기억 방식을 인간과 기억에 대응시키는 것이 적절한지도 의문임.
글의 요지는 더 직접적으로 받아들임. 완벽한 기억 구성을 찾아 헤매기보다 문서로 명확하게 소통하는 편이 더 곧은 길임.
집안 물품과 ‘기억’을 추적하는 비슷한 시스템을 만들어보니, 데이터가 늘수록 읽기·갱신·오래된 정보 관리에 토큰이 빠르게 소모됨. 작은 작업도 문서를 읽고 수정하고 취합하고 갱신하는 과정에서 토큰 비용이 크게 불어날 수 있음.
다만 홈 인프라 참조 문서를 탄탄하게 유지하는 것은 매우 효과적임. 서비스, CI/CD 구성, 호스트, 저장소, 네트워크 정보를 여러 프로젝트가 공유하는 기억으로 쓰면, 집의 인프라에서 테스트·배포·인수 테스트를 수행하는 데 큰 도움이 됨.
현재의 기억 구현이 도움이 안 된다는 데는 동의하지만, “기능의 제약을 기억하려고 3년 전 회의 영상을 다시 보지는 않고 기록을 읽는다”라는 비유에는 동의하지 않음. 기억 플러그인은 과거 대화록을 다시 읽는 것이 아니라, 회의 후 작성하는 메모에 가까운 기억 조각을 사용함.
실제 문제는 누군가 한 문장만 말해도 에이전트가 메모를 남긴 뒤 메모 5,000개를 가지고 작업하려 한다는 데 있음. 대신 중요한 것을 판별해 그것만 기록해야 하며, 그것이 바로 문서화임. 최종 상태뿐 아니라 거기에 이른 과정도 필요하다면 ADR을 쓰면 됨. 오히려 그 과정에 문서 자체보다 더 많은 정보가 담길 수 있음.
기억 조각은 대개 변경 불가능한 추가 전용 형식이고 구조도 빈약함. 많은 메모를 독립적으로 저장하기 위한 설계지만, 메모가 늘어 얻는 이점이 이 형식의 단점을 상쇄하기에는 부족함.
사람의 승인 없이 에이전트가 명세를 작성하는 것은 믿지 못함. 에이전트가 쓴 ADR 때문에 실제로 곤란해진 적이 있음.
요청하지 않은 세부 사항을 멋대로 추론하거나 있으면 좋겠다는 기능을 덧붙이고, 그것이 계속 부메랑처럼 돌아와 불필요하게 범위를 키움.
인간의 작업 과정에는 이해를 계층적으로 정제하는 과정이 있지만, 에이전트의 작업 과정은 아직 이를 수행하지 못함.
규칙을 명문화하고 폴더를 잘 구성하는 등 충분한 구조를 갖춘다면 다중 저장소·모노레포가 나아갈 방향이라고 봄. https://backnotprop.com/blog/context-monorepos/
더 나은 모델은 원래 방향에서 벗어나는 현상을 억제할 수 있음. 요즘 특히 중요한 것은 과거 맥락과 의사결정, 시제품을 모두 보존하는 것임. 모든 프로젝트와 작업 트리를 함께 두고, 참조 문서와 코드도 가까운 폴더에 배치함.
“x는 어떻게 됐지?”라고 물으면 에이전트가 답하는 데 필요한 자료가 모두 갖춰져 있음. 다음 기능을 계획할 때도 decisions 폴더의 과거 결정과 대조해 가정을 검증할 수 있음.