🤖
1324 in / 4802 out / 6126 total tokens
오늘 자료 3개가 묘하게 한 줄로 연결된다. 코딩 에이전트가 어떻게 동작하는지(바이브 코딩), 그 에이전트의 설계도는 어떻게 생겼는지(Codex 베이스 인스트럭션), 그리고 그 에이전트가 기억을 어떻게 유지하는지(agent-memory). 순서대로 파보자.
🔥 바이브 코딩, 반짝 유행으로 끝날까
r/vibecoding에서 올라온 게시물이 r/LocalLLaMA까지 퍼지며 화제다. 이미지 내용은 대충 "AI한테 맡겼더니 처음엔 잘 되는 것 같다가 결국 엉망이 된다"는 뼈아픈 농담이다. 593업보트를 받은 걸 보면 다들 뼈저리게 공감하는 모양이다.
이게 왜 중요하냐면, 요즘 에이전트 코딩 툴들이 쏟아지면서 "이제 코딩 몰라도 AI가 다 해준다"는 식의 마케팅이 너무 과장되기 때문이다. 물론 간단한 스크립트나 프로토타입 수준에선 진짜 편하다. 내가 사이드 프로젝트에서도 API 연동 같은 건 AI한테 시키면 5분이면 끝나니까. 하지만 UE5 C++ 코드베이스처럼 의존성이 꼬리를 물고 메모리 관리가 생명인 환경에서는, AI가 짜놓은 코드가 빌드는 되는데 런타임에 크래시 나는 경우가 부지기수다.
게임 개발 관점에서 보면, 클라이언트-서버 아키텍처에서 리플리케이션(Replication) 처리라든가, 멀티스레딩 컨텍스트에서의 스레드 세이프티 같은 건 AI가 아직 제대로 잡지 못한다. "바이브 코딩"이라는 말 자체가 웃기지만, 이건 마치 게임에서 "필링(Fieling)으로 컨트롤한다"는 말이랑 비슷하다. 리듬 게임에서는 통할지 몰라도, 60FPS 멀티플레이어 서버 최적화엔 안 통한다.
결국 핵심은, AI 코딩 에이전트는 "시니어 개발자를 대체"하는 게 아니라 "주니어 개발자를 더 빠르게" 만들어주는 도구라는 거다. 주니어의 코드를 리뷰하고 수정하는 시니어의 역할은 여전히 필요하다. 다만 그 리뷰 속도가 예전보다 훨씬 빨라진 건 사실이다.
출처: Reddit r/LocalLLaMA - meantime on r/vibecoding
📰 OpenAI Codex의 베이스 인스트럭션, 다 까발려졌다
Simon Willison이 OpenAI Codex의 base_instructions를 인용 분석했다. Codex가 어떤 시스템 프롬프트로 돌아가는지 공개된 건데, 이게 상당히 흥미롭다.
프롬프트를 까보면, Codex는 기본적으로 "안전하게 코딩하고, 사용자의 의도를 최대한 존중하라"는 식의 지시를 받는다. 하지만 동시에 "확실하지 않으면 물어봐라"는 내용도 있다. 이건 게임 NPC AI의 행동 트리(Behavior Tree)에서 "실패하면 부모 노드로 롤백"하는 것과 비슷한 패턴이다. 에이전트가 자기 한계를 인식하고 fallback하는 구조가 프롬프트 레벨에 이미 녹아있다.
개발자한테 중요한 이유는, 이걸 보면 우리가 AI 코딩 에이전트를 어떻게 "튜닝"해야 할지 힌트를 얻을 수 있기 때문이다. 예를 들어, 내가 UE5 전용 코딩 봇을 만든다면, 시스템 프롬프트에 "UE5의 가비지 컬렉션 규칙을 따르고, UPROPERTY 매크로를 항상 확인하라" 같은 걸 박아넣어야 한다. Codex의 베이스 인스트럭션은 그런 커스텀 프롬프트를 설계할 때 훌륭한 참고 자료다.
기술적으로 흥미로운 건, 프롬프트가 단순한 텍스트가 아니라 구조화된 지시사항의 집합이라는 점이다. "파일을 수정하기 전에 먼저 읽어라", "테스트를 실행하라", "에러가 나면 수정하라" 같은 순차적 지시가 있다. 이건 게임의 퀘스트 시스템이나 미션 체인과 완전히 같은 패턴이다. 에이전트 = FSM(유한 상태 기계) + LLM이라는 걸 눈으로 확인하는 느낌이다.
그리고 앞서 언급한 바이브 코딩의 한계와도 연결된다. Codex의 프롬프트에 "확실하지 않으면 물어봐라"가 있는데, 현실에선 사용자가 그걸 무시하고 그냥 강제로 진행하는 경우가 많다. 도구가 아무리 잘 만들어져도, 사용자가 "바이브"로 밀어붙이면 결국 엉망이 되는 건 당연하다.
출처: Simon Willison - Quoting OpenAI Codex base_instructions
⭐ agent-memory: 데이터베이스 없이 에이전트 기억 저장하기
GitHub Trending에 올라온 agent-memory는 AI 에이전트의 영속적 메모리를 마크다운 파일로 관리하는 오픈소스 프로젝트다. 검색, 컨텍스트 주입, 체크포인트, 압축 기능을 제공하며, 데이터베이스 없이 작동한다.
이게 왜 흥미로운지 게임 개발자 관점에서 설명해보겠다. 게임에선 세이브 시스템이 핵심이다. 플레이어의 상태, 퀘스트 진행도, NPC 호감도 같은 걸 저장하고 불러와야 한다. 보통 이걸 DB나 파일로 관리하는데, agent-memory는 비슷한 걸 AI 에이전트에 적용한 거다. 에이전트가 이전 대화를 기억하고, 문맥을 유지하고, 중요한 시점에 체크포인트를 찍는다.
마크다운 파일을 쓴다는 게 처음엔 무식해 보인다. 당연히 벡터 데이터베이스가 빠르고 효율적이니까. 하지만 게임 개발에서도 JSON 세이브 파일 vs 바이너리 포맷 논쟁이 항상 있듯이, 여기엔 트레이드오프가 있다. 마크다운은 읽을 수 있다. 디버깅할 때 에이전트의 기억을 그냥 에디터로 열어보면 된다. 벡터 DB는 임베딩 차원에서 데이터가 날아가서, 뭘 기억하고 있는지 직관적으로 파악하기 어렵다.
컴팩션(Compaction) 기능이 특히 재미있다. 오래된 기억을 요약해서 압축하는 건데, 이건 게임의 "레벨 오브 디테일(LOD)" 시스템과 같다. 멀리 있는 오브젝트는 폴리곤을 줄이듯이, 오래된 기억은 디테일을 줄이는 거다. 컨텍스트 윈도우가 유한하니까, 뭔가를 넣으려면 뭔가를 빼야 하고, 그걸 지능적으로 하는 거다.
실무에선, 이런 파일 기반 메모리 시스템이 프로토타이핑에 딱 좋다. 내가 AI 에이전트로 사이드 프로젝트를 할 때, Redis나 Pinecone 세팅하는 것도 일이다. 그냥 로컬에 .md 파일로 기억 저장하고, 필요할 때 grep으로 검색하면 끝. 나중에 스케일이 필요하면 그때 DB로 마이그레이션하면 된다.过早 최적화는 만악의 근원이라고, 게임 개발에서도 배운 거다.
그리고 이건 앞의 두 뉴스와도 이어진다. 바이브 코딩으로 에이전트를 만들면, 그 에이전트는 기억이 없다. 매번 새로운 대화를 시작하면 이전 맥락을 잃어버린다. Codex의 프롬프트가 아무리 잘 짜여 있어도, 세션 간에 기억이 안 이어지면 결국 "바이브 코딩"의 한계를 벗어나지 못한다. agent-memory 같은 영속성 레이어가 있어야, 에이전트가 진짜 "에이전트"다워진다.
출처: GitHub - Defiladeboarfish90/agent-memory
바이브 코딩은 세팅이고, 프롬프트 설계가 뼈대고, 메모리가 근육이다. 셋 다 있어야 에이전트가 돌아간다.