8월 28일 금요일
에이전트 시스템의 다음 병목은 모델의 기억량이 아니라 현재 상태를 읽고, 실패를 측정하고, 권한 안에서 행동하게 만드는 구조다.
에이전트의 기억을 늘리기보다 실패 경로를 없애라
코딩 에이전트의 신뢰성은 과거 대화를 얼마나 많이 보존하느냐보다 현재 코드와 검증 루프를 얼마나 정확히 따르느냐에 달려 있다.

코딩 에이전트의 품질을 높일 때 지속 메모리보다 코드와 검증 시스템을 우선해야 하는 이유는 무엇인가?
코딩 에이전트에게 지속 메모리를 붙이면 새 세션의 설명 비용은 줄어들 수 있다. 그러나 코드가 계속 바뀌는 프로젝트에서는 메모리가 현재 상태와 나란히 존재하는 두 번째 진실 공급원이 된다. 자동으로 저장된 계획, 일시적인 디버깅 상태, 이미 해결된 문제, 실험 당시의 설정이 다음 실행에 다시 주입되면 에이전트는 저장소를 다시 확인하기보다 과거의 결론을 믿을 수 있다. 이 관점에서 핵심 설계 질문은 무엇을 더 기억시킬지가 아니라 어떤 실패가 구조적으로 발생하지 않게 할지다. 현재 코드를 ground truth로 두고, 프로젝트의 목적과 불변 원칙처럼 오래 유지될 맥락만 짧은 AGENTS.md 또는 CLAUDE.md에 남기며, 나머지는 도구 탐색과 실행 결과가 확인하게 하는 구성이 더 검증 가능하다.
- 01
메모리는 쓰이기보다 쌓였다
발표자가 감사한 메인 clone에는 메모리 45개가 있었지만, 355개가 넘는 세션 중 개별 메모리 파일을 읽은 세션은 19개뿐이었다. 반대로 80개 세션은 메모리를 쓰거나 수정했고 45개 중 26개는 한 번도 읽히지 않았다. 이 수치는 메모리가 실제 행동을 개선하는 지식층이라기보다 세션이 남긴 부산물일 수 있음을 보여준다. 특히 이미 AGENTS.md에 있는 규칙, 해결된 문제, 출시되지 않은 계획, 벤치마크 설정이 섞이면 정보량이 늘어도 현재 작업에 대한 신뢰도는 높아지지 않는다.
- 02
가장 좋은 방어는 금지문이 아니다
실수를 줄이는 우선순위는 실패 범주를 아키텍처와 자료구조로 제거하고, 그다음 lint·테스트·CI로 남은 회귀를 잡고, 마지막으로 skill과 사람의 검토를 두는 순서다. tRPC와 Convex처럼 계층 사이의 type safety를 제공하는 구조는 프론트엔드와 백엔드가 서로 다른 계약을 말하는 오류를 애초에 어렵게 만든다. 에이전트에게 다시 하지 말라고 적는 것은 보조책일 뿐이며, 시스템이 잘못된 상태를 표현하기 어렵게 만드는 편이 더 강한 제약이다.
- 03
프로젝트의 방향과 절차를 분리한다
코딩 에이전트에 필요한 영속적 맥락은 인간의 절차를 장황하게 기록하는 것이 아니라 프로젝트의 가치와 방향을 명시하는 데 가깝다. 오픈소스, 성능, 원격 사용성 같은 목표는 에이전트의 선택을 정렬할 수 있지만, 특정 PR 번호나 일시적인 계획은 빠르게 낡는다. 저장소를 bash 도구로 탐색하게 하고 필요한 출력만 컨텍스트에 넣으면, 에이전트는 현재 파일·로그·테스트 결과를 근거로 판단할 수 있다. 다만 이 방식도 자동으로 옳아지는 것은 아니다. 복잡한 그래프나 메모리 계층이 실제 산출물을 개선하는지는 평가로 입증해야 한다.
따라서 코딩 에이전트의 운영 체크리스트는 메모리 파일 수가 아니라 현재 코드와의 일치, 실패를 잡는 CI·테스트의 범위, 도구 호출의 관측 가능성으로 구성해야 한다. 메모리를 완전히 부정하는 결론도 아니다. 코드에 직접 추적 경로가 없는 개인 대화 맥락에는 검색 가능한 기록이 유용할 수 있지만, 코드 작업에서는 과거의 추론이 현재 실행 결과를 이겨서는 안 된다. 지속 기억을 도입한다면 읽힘과 개선 효과를 측정하고, 낡은 상태를 폐기할 규칙까지 함께 설계해야 한다.
물리 세계에서는 토큰보다 구조가 먼저다
고해상도·다중 스케일·희소 데이터라는 조건이 Transformer의 범용성을 시험하며, Neural Operator는 데이터와 물리 제약을 함께 다루는 경로를 제시한다.
언어 모델의 Transformer 구조를 물리 시뮬레이션에 그대로 적용하기 어려운 이유는 무엇인가?
물리 시뮬레이션의 입력은 단순한 긴 문장이 아니다. 공간과 시간의 여러 축에서 고해상도 상태를 표현해야 하고, 멀리 떨어진 지점의 상호작용과 미세한 규모의 효과가 함께 결과를 바꾼다. 각 축에 격자점을 촘촘히 두면 문맥 길이는 수백억에서 1조 개까지 커질 수 있어 모든 토큰 쌍의 attention을 계산하는 Transformer의 이차 복잡도와 메모리 부담이 곧 병목이 된다. 게다가 실제 물리 데이터는 언어 데이터보다 적다. 반대로 자연법칙은 강한 잠재 구조를 제공하므로, 좋은 모델은 더 많은 토큰을 소비하는 대신 그 구조를 계산 그래프 안에 넣어야 한다.
- 01
PINN만으로는 장기 동역학이 불안정하다
Physics-Informed Neural Network는 편미분방정식의 잔차를 손실에 넣어 법칙을 만족하는 해를 찾는다. 하지만 시간 의존 문제와 난류에서는 작은 미세 규모 효과가 장기 결과를 크게 바꾸고, 처음부터 모든 시간의 방정식을 최적화하는 손실 지형이 어려워진다. 따라서 물리 제약을 넣었다는 사실만으로 모든 문제의 수렴이나 장기 정확도가 보장되지는 않는다. 실용적인 구성은 여러 방정식 인스턴스의 해를 데이터로 학습한 뒤, 보존 법칙과 PDE 제약을 함께 사용해 일반화를 안내하는 방식이다.
- 02
함수 공간과 Fourier 공간의 역할
Neural Operator는 고정된 크기의 벡터를 매핑하는 대신 입력 함수와 출력 함수 사이의 사상을 학습한다. 그래서 추론 때 해상도를 바꿀 여지가 있고, Fourier Neural Operator는 전역 상호작용을 준선형 복잡도로 다루면서 비선형 층과 잔차 연결로 표현력을 보완한다. 단순한 Fourier 절단만으로는 고주파 세부를 보장할 수 없으므로, 높은 해상도에서 PDE나 보존 법칙을 손실로 추가해야 한다. 다만 강제 제약은 계산적으로 어렵고 가중치 조정이 필요해, 초해상도 결과도 물리적 유일해라고 과장해서는 안 된다.
- 03
검증 가능한 속도가 목표다
ForecastNet 사례는 공개 재분석 데이터 약 5만 개로 학습한 날씨 모델이 전통적 슈퍼컴퓨터 계산에 가까운 정확도를 보이면서 수만 배 빠른 추론과 소비자용 GPU 한 장 실행을 지향할 수 있음을 보여준다. 하지만 날씨 예측은 혼돈계이므로 장기 예측을 하나의 확정 궤적으로 읽으면 안 되고, 여러 초기 조건의 앙상블과 평균·분포로 해석해야 한다. 물리 시스템에 들어갈 AI는 빠른 예측만이 아니라 유한 정밀도와 섭동에 대한 안정성까지 별도로 점검해야 한다.
물리 분야에서 구조적 inductive bias는 성능을 꾸미는 옵션이 아니라 계산량과 데이터 부족을 동시에 다루는 방법이다. 그렇다고 Neural Operator가 Transformer의 보편적 대체재라는 뜻은 아니다. 어떤 해상도와 시간 범위에서 어떤 물리량을 예측하는지, 법칙 손실의 가중치가 어떻게 정해졌는지, 장기 롤아웃과 섭동에서 오차가 어떻게 누적되는지를 함께 공개해야 기술 선택을 검증할 수 있다.
현장에서 바로 읽히는 세 가지 구현 신호
격리·마이그레이션·에이전트 도구 설계는 서로 다른 문제지만, 운영 비용을 코드와 인터페이스의 경계에서 줄인다는 공통점을 가진다.

- 01GeekNews
사이트별 데이터베이스 격리
Poke 사례는 사용자가 만든 사이트마다 Turso 데이터베이스를 따로 두어 쿼리·트래픽·취약점의 영향 범위를 분리하고, 유휴 사이트의 비용도 낮추는 설계를 소개한다. 기능을 추가하는 것보다 장애와 보안의 blast radius를 데이터 경계로 줄이는 선택이 핵심이다.
- 02
t3chfeed대량 발사는 토목·제조 시스템이다
루이지애나의 Starship 우주항 구상은 연간 수천 회 발사를 로켓 모델 하나의 문제가 아니라 해안 입지, 가스 공급, 비행 궤적, 접근로, 습지 복원, 용접·튜브 성형 인력의 결합으로 본다. 첫 진척이 발사대가 아니라 접근로와 침식 대응일 수 있다는 점이 인프라의 실제 병목을 드러낸다.
- 03
aiDotEngineer에이전트 도구의 한 턴 비용
Sourcegraph의 CodeScaleBench 사례는 수백 개 작업과 수천 개 실행 trace로 에이전트가 어디서 실패하는지 측정하려는 접근을 보여준다. 도구가 결국 복구되더라도 start line 대신 read line을 호출한 한 번의 오해는 토큰·시간·실행 턴을 소비하므로, 설명과 파라미터 이름도 제품 성능의 일부가 된다.
다음 확인 지점은 기억의 범위와 쓰기 권한이다
에이전트 기능이 실제 시스템으로 들어갈수록 무엇을 기억하는가와 무엇을 변경할 수 있는가를 분리해 관찰해야 한다.
- 1
Claude Code까지 메모리가 실제로 확장되는가
Claude 메모리 2.0은 Chat과 Co-work 사이의 주제별 공유를 제공하지만, 발표 시점에는 Co-work와 Claude Code 사이 동기화가 없고 공유 메모리는 클라우드 실행에만 적용된다. 후속 발표에서 Code 연동이 추가되는지, 로컬 작업과 클라우드 작업의 메모리 경계가 어떻게 정의되는지, 민감 주제 기본 제외와 사용자 편집·삭제가 그대로 유지되는지를 확인해야 한다.
- 2
분석 에이전트가 CRM 쓰기로 넘어갈 때
Exa 사례는 API·MCP·스킬로 내부 데이터를 읽고 요약하는 단계에서 더 깊은 통합으로 이동하고 있다. 다음 신호는 Salesforce의 quoting·approval·CRM 변경이 실제 workflow에 들어갈 때다. 읽기 질의와 달리 쓰기는 영업 기회와 승인 상태를 바꾸므로, 호출자별 권한, 변경안 검토, source of truth 정렬, 실행 로그가 함께 공개되는지 봐야 한다.
아직 못 읽은 북마크
북마크를 고르는 중…