🤖
1285 in / 3801 out / 5086 total tokens
🔥 핫 토픽
Vibe Coding과 Agentic Engineering의 경계가 흐려지고 있다
https://simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering/
Simon Willison이 최근 올린 글이 화제다. "Vibe coding"과 "Agentic Engineering"이 생각보다 가까워지고 있다는 내용이다. Vibe coding은 Andrej Karpathy가 만든 용어로, AI에게 자연어로 대충 원하는 걸 설명하면 코드를 짜주는 방식이다. 반면 Agentic Engineering은 AI 에이전트를 설계하고 구축하는 더 엔지니어링적인 접근이다.
Willison의 핵심 주장은 이렇다. 처음에는 이 두 가지가 명확히 다른 거라고 생각했다. Vibe coding은 "코딩을 모르는 사람도 AI로 뭔가 만들 수 있다"는 민주화에 가깝고, Agentic Engineering은 "엔지니어가 AI 시스템을 제대로 설계하는 것"이다. 그런데 실제로 현장에서 일하다 보니 이 둘이 점점 겹친다는 거다.
왜 이게 중요하냐? 게임 개발에서도 같은 현상이 일어나고 있다. 언리얼 엔진에서 블루프린트로 대충 로직 짜던 초보자가, 어느 순간 AI 어시스턴트를 통해 프로젝트 전체 구조를 잡기 시작한다. "바이브"로 시작했지만 결과물은 엔지니어링 수준이다. 이게 Willison이 말하는 "경계의 붕괴"다.
특히 흥미로운 건 Willison이 자기 프로젝트에서 겪은 경험이다. 그는 LLM으로 코드 생성할 때 체계적으로 테스트를 작성하고, 프로덕션 환경을 고려하고, 보안을 신경 쓴다. 이건 Vibe coding이 아니라 제대로 된 엔지니어링이다. 하지만 동시에 그는 AI와 "대화"하면서 코드를 쓴다. 두 패러다임이 한 작업 안에 공존하는 거다.
UE5 C++ 개발자 입장에서 공감되는 부분이 많다. 나도 Gemini나 Claude랑 코드 리뷰하면서 "이 함수 너무 무거운데 분리해줘"라고 말하면 (이건 바이브 코딩이다), AI가 제안하는 리팩토링 방안을 검토하고 아키텍처 결정을 내린다 (이건 엔지니어링이다). 두 활동이 분리 안 된다.
Willison은 이 현상을 "Vibe coding이 진화하고 있다"기보다는 "좋은 엔지니어링 실천이 AI 시대에 어떻게 변형되는지"로 봐야 한다고 주장한다. 그리고 나는 동의한다. 중요한 건 도구가 아니라 프로세스다. AI를 쓴다고 해서 테스트를 안 하거나 아키텍처를 무시하면 안 된다. 오히려 AI 시대에 더 중요해진다.
이게 왜 중요한가: 게임 개발을 포함한 모든 소프트웨어 개발에서 "AI가 코딩해준다"는 낙관론과 "AI가 코딩을 대체한다"는 위기론 사이에서, 실제 현장에서는 이 두 가지가 섞인 새로운 실천이 만들어지고 있다. 우리는 이걸 이름 붙이고 이해해야 한다.
⭐ 오픈소스
echome — 당신만의 AI 미러를 만들 수 있는 개인 AI 엔진
https://github.com/Lourdhu02/echome
GitHub 트렌딩에 떠올른 프로젝트인데, 꽤 흥미롭다. "고충실도 개인 AI 미러 엔진"이라고 소개한다. 핵심은 당신의 성격, 목소리, 행동을 학습해서 "당신 같은 AI"를 만드는 거다.
기술 스택을 보면 이렇다. 먼저 Adaptive Personality Testing에 IRT(항목 반응 이론)와 CAT(컴퓨터 적응 검사)를 사용한다. IRT는 시험에서 많이 쓰는 이론인데, 쉽게 말해 "이 사람의 능력이 어느 수준인지"를 문제 난이도와 함께 추정하는 방법이다. CAT은 이를 실시간으로 적용해서, 사람이 푼 이전 답변에 따라 다음 질문의 난이도를 조절하는 거다. 게임으로 치면 플레이어 실력에 맞춰 난이도 자동 조절하는 거랑 비슷하다.
로컬 Voice Cloning에는 XTTSv2를 쓴다. XTTSv2는 Coqui에서 만든 TTS(텍스트 음성 변환) 모델인데, 3초짜리 음성 샘플만 있으면 그 사람 목소리를 복제할 수 있다. 이것도 로컬에서 돈다. 클라우드 안 거쳐서 프라이버시가 보존된다.
그리고 LangGraph 기반으로 자율 에이전트를 구성했다. LangGraph는 LangChain의 확장인데, 상태 기계(state machine) 기반으로 에이전트 워크플로우를 짤 수 있게 해준다. UE5의 Behavior Tree나 State Machine이랑 개념이 비슷하다. 상태 전이를 정의하고, 조건에 따라 다음 행동을 결정하는 거.
아키텍처를 보면 FastAPI 위에 올라가 있다. Python 기반이고, API 서버로 구성되어 있어서 다른 애플리케이션이랑 연동하기 쉽다. 게임 서버 개발자 입장에서 보면, 이건 클라이언트-서버 구조의 미니 백엔드다. 게임 내 NPC AI를 외부 서비스로 분리하는 트렌드랑 맞닿아 있다.
이게 왜 중요한가: "디지털 트윈"이란 개념이 인체·성격까지 확장되고 있다. 게임에서 플레이어를 닮은 NPC를 만들 수 있다면? 혹은 플레이어의 행동 패턴을 학습해서 게임 난이도를 개인화할 수 있다면? echome은 그런 가능성의 기술적 기반을 보여준다. 특히 로컬에서 다 돈다는 게 중요하다. 개인정보를 클라우드에 안 보내고도 개인화 AI를 만들 수 있다.
앞서 언급한 Willison의 글이 "에이전트 엔지니어링의 중요성"을 강조했다면, echome은 그 에이전트 엔지니어링을 실제로 구현한 사례다. 성격 테스트, 음성 복제, 자율 행동을 하나의 시스템으로 통합한 거. 물론 아직 초기 프로젝트라 프로덕션급은 아니다. 하지만 방향성은 시사하는 바가 크다.
나도 사이드 프로젝트로 비슷한 거 해보고 싶다. 언리얼 메타휴먼에 연동해서, 플레이어 목소리로 대사 치는 NPC를 만들면 재밌겠다. 물론 법적·윤리적 문제는 별개다. 성동결(deepfake) 문제, 동의 없는 목소리 복제 등등. 기술은 가능하지만 써도 되는지는 다른 문제다.
💭 연결고리
두 뉴스를 나란히 놓으면 한 가지 패턴이 보인다. **"에이전트"**라는 키워드다.
Willison은 "Vibe coding에서 Agentic Engineering으로" 전환을 이야기했다. echome은 "자율 에이전트"를 실제로 구현했다. 둘 다 2025년 현재 AI 개발의 화두가 "에이전트"라는 걸 보여준다.
게임 개발에서도 같은 흐름이 있다. 예전에는 NPC AI라고 하면 행동 트리나 유한 상태 기계(FSM)를 의미했다. 규칙 기반, 결정론적. 이제는 LLM 기반 에이전트로 NPC가 "자율적으로" 행동하는 시대가 오고 있다. 언리얼 5.4에서 ML Deformer가 들어간 것도, AI 데이터 기반 애니메이션이 가능해진 것도 같은 맥락이다.
개발자로서 준비해야 할 것은 명확하다. 에이전트를 설계하고, 평가하고, 제어하는 능력. 코드를 짜는 것도 중요하지만, AI 시스템의 행동을 예측 가능하게 만들고 안전장치를 거는 게 더 중요해진다. 게임 서버 아키텍처에서 "무엇이든 될 수 있는" 시스템보다 "예측 가능하게 실패하는" 시스템이 낫다는 원칙이, AI 에이전트에도 그대로 적용된다.
오늘의 한줄: Vibe coding은 죽었다. 살아남은 건 에이전트를 엔지니어링하는 능력이다. echome처럼 로컬에서 돌아가는 개인화 AI가 그 다음 전장이다.