1. 현재 마주한 한계점
Spec Kit과 SDD가 등장한 뒤 반년 정도가 지났다.
그동안 Spec Kit을 재구성해 Skill로 만들고, 이를 OpenCode에서 사용해왔다.
잘 사용해왔지만, 반년 사이 기술이 엄청 발전해버렸다.
그동안 AI를 사용하며 마주한 한계점과 극복 방향성을 글로 정리해보려 한다.
가. 일관성 상실
처음에는 한 개의 에이전트로 모든 작업을 처리하는 방식으로 진행했었다.
계획부터 구현, 수정까지 자연스럽게 작업을 수행했지만, 작업이 길어질수록 한계가 분명해졌다.
Context Window가 가득 차고 compaction이 발생할 때마다 성능이 크게 떨어졌고, 앞선 작업의 맥락도 자주 놓쳤다.
그래서 이후에는 compaction이 발생할 때마다 새로운 세션을 만들어 작업을 이어가는 방식으로 대응했었다.
나. 리뷰 역설
한동안은 AI가 코드를 생성하고, 내가 이를 검토하는 방식으로 개발을 진행했다.
문제는 읽어야 할 코드의 양이 너무 빠르게 늘어난다는 점이었다.
인간 개발자의 검토 속도는 제한적일 수밖에 없기 때문에 결국 병목이 발생했고, AI의 높은 생산성을 제대로 활용하지 못하는 문제가 생겼다.
테스트 가능한 최소한의 기능 단위로 나눠 개발하면서 개발자가 검토하기 쉽도록 노력하기도 했지만, 그런 방식에도 분명한 한계가 있었다.
다. 자기 평가의 편향
결국 AI가 생성한 코드는 개발자가 아니라, AI가 직접 검토해야 한다는 결론에 도달했다.
다만 지금까지는 하나의 에이전트만 사용해 작업해왔기 때문에, 코드를 생성하는 에이전트와 이를 검증하는 에이전트가 같을 수밖에 없었다.
문제는 생성한 코드를 스스로 검토하게 하면 기대만큼의 효과가 나오지 않는다는 점이다.
자신이 어떤 사고 과정과 논리를 거쳐 결과를 만들었는지 이미 알고 있기 때문에, 심각한 결함이 있어도 이를 합리화하거나 쉽게 넘어가는 경향이 있었다.
때문에 리뷰를 할때는 새로운 세션을 만들어서 분리된 환경에서 진행했다.
2. OpenClaw 등장
OpenClaw가 등장하면서 AI 에이전트의 다음 단계를 꽤 선명하게 보여줬다.
단순히 검색을 잘하는 수준을 넘어, 실제로 일을 맡길 수 있는 비서형 에이전트가 어떤 모습이어야 하는지를 제시했다.
일단 훨씬 Proactive하게 동작한다.
개인 서버에서 백그라운드로 돌아가기 때문에, 사용자가 계속 붙어서 대화하지 않아도 작업이 이어진다.
질문에만 반응하는 것이 아니라, 스스로 판단해 필요한 작업을 먼저 제안하고 시도하는 적극성도 보인다.
하나의 방법이 실패하더라도 쉽게 포기하지 않고, 어떻게든 다른 방법을 찾아내려 한다.
이런 점이 ‘진짜 에이전트’라고 느껴졌다.
개인 서버를 사용하기 때문에 전용 저장공간을 할당받는다.
기억과 작업물을 저장할 수 있게 되었고, 이는 곧 개인화된 에이전트로 이어졌다.
새로운 세션에서도 중요한 맥락을 이어가고, 사용할수록 점점 더 사용자에게 최적화되었다.
또 메신저를 통해 상호작용하는 방식은 묘하게 편했다.
웹페이지가 아니라 메신저를 사용하니 느낌이 달랐다.
큰차이는 아니지만 더 편했다.
Agent가 먼저 메시지를 보내오기도 하고, 언제 어디서든 최소한의 터치로 작업을 지시할 수 있었다.
OpenClaw에는 아직 취약점도 많고, 최적화 문제도 있다.
때문에 OpenClaw를 사용하진 않을 것 같다.
하지만 OpenClaw는 아니더라도, 결국은 OpenClaw와 비슷한 성격의 AI 에이전트를 사용하게 될 것 같다는 생각이 강하게 든다.
3. Harness Engineering?
Spec-kit을 재구성해서 skill로 만들어 사용했다.
이 경험이 꽤나 인상적이었다.
프롬프트와 쉘 스크립트로 반복되는 워크플로우를 명문화하고 재사용할 수 있었다.
자신만의 워크플로우를 스킬과 보조 스크립트로 구성하는 것이 중요해질 거라고 생각했다.
최근에는 이런 흐름을 Harness Engineering이라고 부르는 것 같다.
AI의 산출물이 일정한 품질 안에서 통제될 수 있도록, 절차와 환경을 미리 정의한다.
이제는 프롬프트를 머리 아프게 쥐어짜서 AI에게 일을 시키는 방식만으로는 부족하다.
개발자는 하네스를 만들고, 하네스는 AI를 제어하며, AI는 그 안에서 일을 수행한다.
이쪽 분야에서 가장 앞서 있는 Anthropic은 “생성과 평가를 분리해 품질 피드백 루프를 만들라”고 말했다.
이는 GAN(Generative Adversarial Network)의 원리를 응용한 방식으로도 볼 수 있는데, 생성자와 검수자가 서로 견제하는 구조를 통해 더 나은 결과물을 만들 수 있었다고 한다.
또한 생성자와 검수자의 컨텍스트가 분리되기 때문에, 더 객관적인 평가가 가능하다는 점도 중요하다.
물리적으로 분리된 컨텍스트 윈도우는 불필요한 TMI를 줄여주고, 전체적인 일관성을 유지하는 데에도 유리했다.
4. 느낀점
가. Agent가 이제 리뷰도 한다.
AI가 생성한 코드를 이제 AI가 리뷰한다.
아니, 이제는 그렇게 해야 한다.
유명 오픈소스 프로젝트만 봐도 PR이 산처럼 쌓여 있다.
만성적인 노동력 부족에 시달리고 있다.
나. 소스코드? 테스트코드!
검증 가능성이 핵심이다.
정상 상태란 무엇인가?
정상 상태를 어떻게 정의할 것인가.
정상 상태를 명확하게 정의할 수만 있다면 인간이 모든 것을 직접 검토할 필요가 없다.
인간은 정상 상태를 정의하는 것에만 집중하면 된다.
기능, 안정성, 보안 등의 정상 상태를 정의해야 한다.
그런면에서 어쩌면 소스코드보다 테스트코드가 더 중요해진 것 같다.
다. 언제 어디서든 상호작용할 수 있어야 한다.
알바할 때도 일을 시키고 싶다.
토큰이 남는 것이 너무 아깝다.
라. 변하지 않는 건 Skill
모델은 계속해서 발전한다.
툴도 계속해서 변화한다.
새로운 모델과 툴은 너무 빠른 속도로 등장하고, 변화의 흐름 역시 따라가기 벅찰 정도로 빠르다.
그렇다면 특정 모델과 도구에 종속되지 않으면서도 역량을 쌓아올릴 수 있는 방법은 무엇일까.
자체 개발일까.
Plugin일까.
Skill일까.
현시점 개인이 Model과 Tool을 자체 개발하기 어렵다.
반면 Skill과 같은 프롬프트 자산은 비교적 오래 남고, 쉽게 무너지지 않는다.
개인은 Model이나 Tool 자체보다 Skill에 더 집중해야 할 것 같다.
자신에게 맞는 Skill을 계속 쌓아가고, 그때그때 업그레이드해나가는 것이 더 현실적인 방향에 가깝다.
마. 적정기술
토큰 비용이 장난없다.
그래서 어떻게든 아낄 수 있는 방법을 고민해야 한다.
무조건 최고 성능만 지향하기보다, 투입 가능한 예산 수준을 함께 고려해 그에 맞는 적절한 수준의 AI 에이전트 시스템을 설계해야 할 것 같다.
바. Team이다!
Context의 일관성과 검증의 객관성 같은 측면만 보더라도, Context Window를 분리했을 때 얻을 수 있는 장점이 많다.
앞으로는 서로 견제하고 보완할 수 있는 Agent Team을 구성하는 일이 계속 중요해질 것이다.
최소한 계획, 생성, 검증을 분리하는 구조는 사실상 필수다.
어떻게 Agent 조직을 구성하고 교육할 것인지가 개발자의 핵심 능력 중 하나가 될지도?
사. 보안은?
Claude Code와 관련된 유명 GitHub repo들을 보면, 보안 솔루션까지 함께 갖추고 있는 경우가 많다.
자체적으로 스캐너를 만들어 문제를 사전에 탐지하고 예방하려는 시도도 자주 보인다.
여러 유명 repo들에서 손민수해야겠다.
아. 재귀적 자기 개선이 온다.
사이클을 반복할수록 고도화되는 시스템이다.
찰스 다윈의 자연 선택설이 떠오른다.
환경에 적합한 유리한 형질을 가진 개체가 살아남고 번식하면서 진화하듯, AI 에이전트 역시 사용자의 패턴에 맞춰 계속 진화하는 방향으로 가게 될 것 같다.
지금은 개발자가 직접 하네스를 만들고 다듬고 있지만, 조금만 시간이 지나도 그마저 귀찮게 느껴질 가능성이 크다.
개발자들은 그런 존재니깐.
“사용하면 자연스럽게 발전하는 AI Agent” 무섭기도 하고…. 암튼 Skill을 수가 많아질수록, 하네스가 복잡해질수록 더욱더 필요하게 될 것 같다.
- 2026년 04월 22일
이제 이걸 Compound Engeering이라고 하더라.
관련된 플러그인이 있으니 참고하자.
자. 지금 필요한 도구
지금 필요한 것은 단순히 더 좋은 모델이 아니다.
- 팀을 관리하는 도구
- 스킬을 관리하는 도구
- 스스로 개선하는 도구
일단 위 도구들부터 찾아보자.
5. 주목할 만한 도구
6. 참고 자료
