치킨치의 세상 톺아보기

LLM 에이전트를 만들다 보면 한 번쯤 기억 을 흉내내는 단계에 도달한다. 그리고 거의 항상 같은 실수를 한 번씩 한다.컨텍스트 윈도우를 기억 시스템으로 쓰는 것.토큰 한도가 100k → 200k → 1M 으로 늘어나는 동안, "이제 컨텍스트가 충분히 크니 기억은 그냥 다 쌓아 두면 되겠지" 라는 유혹이 강해진다. 실제로 잠깐은 그럴듯하게 굴러간다. 그 단계에서 멈추면 6 개월 뒤에 느린·비싼·산만한 에이전트가 남는다.이 글은 기억 을 컨텍스트 윈도우와 분리해서 설계해야 하는 이유와, 내가 정착시킨 4 층 구조를 정리한 노트다.1. 컨텍스트 윈도우는 레지스터 에 가깝다CPU 비유로 정리하면 직관이 분명해진다.레지스터 — 이번 명령 직접 처리. 빠르지만 작고 휘발성.L1/L2 캐시 — 최근 자주 쓴 것. ..

LLM 에이전트를 한 번이라도 운영해 본 사람이 가장 먼저 부딪히는 벽이 있다.코드는 통과하는데 결과가 흔들린다.같은 입력에 어제는 잘 답하고, 오늘은 엉뚱하게 답한다. 모델을 한 단계 업그레이드했더니 10 개 케이스가 좋아지고 다른 7 개가 망가진다.유닛 테스트는 이 종류의 문제를 못 잡는다. 그래서 따로 사는 분야가 평가 (evals) 다.이 글은 evals 를 이번 1 년 직접 깔아 본 입장에서 정리한 노트다.1. evals 는 테스트 가 아니라 계량기 다먼저 마인드셋부터 갈라야 한다. 유닛 테스트와 evals 는 다른 종족이다.유닛 테스트 — 결과가 이항(pass/fail). 코드를 배포해도 되느냐의 게이트.evals — 결과가 분포(score, win-rate, regression delta)...

LLM 으로 코드를 쓴다는 말의 의미 가 2025 년과 2026 년 사이에 한 번 바뀌었다. 더 이상 "에디터에 자동완성이 똑똑해졌다" 수준이 아니다. 작업의 단위 자체가 바뀐다. 한 줄이 아니라 한 PR 을, 한 함수가 아니라 한 기능 전체를, 에이전트에게 위임 하기 시작했다. 이 글은 그 변화를 내 일상 워크플로 기준으로 정리한 노트다.1. 변한 것 — 한 줄에서 한 PR 로작년까지 LLM 은 현재 커서 위치 주변 에서 일했다. 다음 줄, 다음 토큰, 다음 함수. 사람이 큰 그림을 잡고 LLM 이 부분 을 채웠다.2026 년의 차이는 단순하다. 에이전트가 레포 전체 를 컨텍스트로 다루고, 사람의 한 줄짜리 요청 으로 여러 파일 수정 + 테스트 추가 + 빌드 검증 까지 한 번에 끝낸다. 사람이 부분을 ..