AI(LLM) Agent를 더 잘 다루기 위한 고민
AI를 활용하면서 생산성이 높아졌다는 것은 분명히 체감한다. 과거에는 며칠씩 걸리던 작업을 이제는 몇 시간 만에 끝내기도 한다.
그런데 한편으로는 의문이 든다.
과연 나는 AI를 잘 활용하고 있는 것일까? 단순히 코드를 더 빠르게 생산하는 것을 넘어, 문제를 해결하는 능력 자체도 좋아지고 있는 것일까?
최근 AI Agent를 활용하면서 느낀 몇 가지 고민과 나름대로의 접근 방식을 정리해 보았다.
1. Brain Compiler — 우리는 사고 과정을 포기하고 있는가?
과거에는 프로그램 소스를 작성하기 전에 항상 어떻게 만들 것인지 먼저 생각했다.
단순한 Todo App 하나를 만들더라도 그 안에는 수많은 사고 과정이 필요하다.
- 사용자는 어떤 시나리오로 기능을 사용하는가?
- HTML 마크업과 컴포넌트 구조는 어떻게 설계할 것인가?
- CSS와 UI 상태는 어떻게 관리할 것인가?
- 사용자 이벤트는 어떻게 처리할 것인가?
- 데이터 구조와 상태 변경 로직은 어떻게 정의할 것인가?
- 예외 상황과 사이드 이펙트는 어떻게 다룰 것인가?
숙련된 개발자라면 이러한 사고 과정이 코드 수준에서 순식간에 스쳐 지나간다.
나는 이러한 과정을 Brain Compiler라고 표현하고 싶다.
머릿속의 추상적인 요구사항을 구체적인 설계와 실행 가능한 코드로 변환하는 일종의 컴파일 과정이다.
그런데 AI를 사용하면서 이 과정에 변화가 생겼다.
이제는 '사용자가 Todo를 생성하고 완료 처리할 수 있도록 만들어 줘' 정도의 유저 시나리오만 전달해도 어떻게든 돌아가는 결과물이 나온다.
문제는 그다음이다.
코드는 돌아가지만 왜 그렇게 돌아가는지 모른다. 어디를 수정했을 때 무엇이 망가질지도 보장하기 어렵다.
AI가 생성한 코드는 존재하지만, 그 코드를 만들기 위한 설계 의도와 판단 근거는 남아 있지 않은 경우가 많다.
결국 코드만 남고 스펙은 사라지는 상황이다. 시간이 지나면 개발자는 코드로부터 원래의 의도를 역산출해야 한다.
나는 이러한 현상을 Reasoning Abandonment, 즉 사고 과정의 포기(No Brain Compiler)라고 정의하고 싶다.
물론 AI에게 사고를 위임하는 것 자체가 문제는 아니다.
진짜 문제는 사고를 위임하는 과정에서 우리가 반드시 통제해야 할 설계 의사결정까지 함께 포기하는 것이다.
AI가 어떻게 구현했는지 모든 코드 라인을 이해할 필요는 없을 것이다. 하지만 적어도 왜 그러한 구조가 선택되었고, 어떤 제약과 가정을 바탕으로 만들어졌는지는 설명할 수 있어야 하지 않을까?
결국 중요한 질문은 이것이다.
Brain Compiler를 AI에게 위임하더라도, 사람이 반드시 소유해야 하는 의사결정은 무엇인가?
2. Human Readable & AI Readable — 사람과 AI 모두 이해할 수 있는가?
AI에게 일을 시키다 보면 수많은 Markdown 문서와 텍스트 파일이 생성된다.
계획서, 스펙 문서, 구현 가이드, 작업 로그, 테스트 결과 등등.
처음에는 이러한 산출물이 많을수록 AI가 체계적으로 일하고 있다고 생각했다.
그런데 어느 순간부터 감당하기 어려워진다.
문서가 너무 많아 무엇을 읽어야 하는지 모르겠고, AI가 만들어 놓은 결과물을 이해하는 데 오히려 더 많은 시간이 들어간다. 결국 상당수의 문서는 제대로 읽지도 못하고 버리게 된다.
그렇다면 AI를 마이크로 매니징하면서 모든 과정을 하나하나 이해하는 것이 정답일까?
그것도 의문이다.
AI가 생산성을 높여 주기 위해 존재하는데, 사람이 모든 디테일을 직접 검토하고 관리한다면 오히려 AI의 생산성을 사람이 제한하는 상황이 된다.
여기서 추상화 수준(Abstraction Level)이라는 개념을 다시 생각하게 되었다.
예를 들어 AI에게 어떤 기능을 구현해 달라고 요청한다고 가정해 보자.
'사용자가 Todo를 생성하고 수정하고 삭제할 수 있도록 만들어 줘.'
이는 상당히 추상화된 요구사항이다.
반대로 데이터 타입, 컴포넌트 구조, 함수 시그니처, 이벤트 처리 방식까지 하나하나 명령한다면 상당히 구체화된 요구사항이 된다.
전자는 AI의 자율성이 높지만 결과의 불확실성이 크다. 후자는 통제력이 높지만 사람이 개입해야 하는 비용이 커진다.
그렇다면 정답은 무엇일까?
나는 사람에게 적합한 추상화 수준에서 요구사항을 정의하고, 구체화 과정은 AI에게 위임하는 것이라고 생각한다.
여기서 또 하나 중요한 것은 결과물을 표현하는 방식이다.
AI가 생성한 결과물이 반드시 사람이 읽기 좋은 형태일 필요는 없다. 반대로 사람이 이해하기 좋은 표현이 AI가 작업하기에 가장 적합한 형태일 필요도 없다.
즉, Human Readable과 AI Readable은 서로 다른 문제다.
최근 흥미롭게 바라보는 사례는 Figma Make다.
사용자는 Chat UI에서 자연어로 요구사항을 전달한다. AI는 이를 바탕으로 React 코드와 시각적인 UI 결과물을 만든다.
여기서 각 인터페이스의 역할이 명확하다.
- Chat UI: 사람이 의도를 전달하는 인터페이스
- React Code: AI가 구현하고 수정할 수 있는 실행 가능한 산출물
- Visual UI / Figma: 사람이 결과물을 직관적으로 이해하고 검증하는 인터페이스
사람은 모든 React 코드를 읽지 않더라도 결과물이 의도대로 만들어졌는지 확인할 수 있다.
이 구조가 흥미로운 이유는 AI의 생산성과 사람의 이해 가능성을 동시에 확보하려는 접근이기 때문이다.
물론 시각적인 결과물만으로 모든 것을 검증할 수는 없다. 데이터 정합성, 예외 처리, 성능, 보안 같은 비기능적 요구사항은 별도의 검증 수단이 필요하다.
그럼에도 중요한 힌트가 있다.
AI Only Readable한 방식으로만 일하다 보면, 결국 사람은 AI가 쏟아내는 방대한 결과물에 잠식당할 수밖에 없다.
따라서 AI에게 일을 잘 시키는 것만큼, 사람이 결과물을 쉽게 이해하고 검증할 수 있도록 만드는 것도 중요하다.
3. Declarative AI — 선언형 프로그래밍처럼 AI와 협업할 수 없을까?
프로그래밍 세계에는 선언형 프로그래밍(Declarative Programming)이라는 개념이 있다.
명령형 프로그래밍은 어떻게(How) 수행할 것인지를 단계별로 기술한다.
반면 선언형 프로그래밍은 무엇(What)을 원하는지 표현하고, 구체적인 수행 과정은 하위 시스템에 위임한다.
예를 들어 SQL을 사용하면서 데이터베이스 엔진이 내부적으로 어떠한 실행 계획을 세우고, 어떤 순서로 데이터를 탐색하는지 매번 직접 구현하지는 않는다.
우리는 원하는 데이터의 조건을 선언한다. 데이터베이스 엔진은 내부적으로 실행 계획을 수립하고 결과를 반환한다.
나는 AI Agent와 협업하는 방식도 이와 유사해야 한다고 생각한다.
사람은 원하는 입력과 최종 결과의 형태를 정의한다.
AI는 그 결과를 만들기 위한 계획, 탐색, 구현 등의 구체적인 과정을 수행한다.
그리고 사람은 AI가 만든 결과물을 이해하기 쉬운 Viewer를 통해 검증한다.
이때 AI의 내부 실행 과정은 일종의 블랙박스로 취급할 수 있다.
하지만 블랙박스로 둔다는 것이 아무런 통제도 하지 않는다는 뜻은 아니다.
SQL의 실행 계획을 일일이 작성하지 않더라도 데이터베이스에는 제약조건, 트랜잭션, 스키마, 실행 정책 등이 존재한다.
AI Agent에도 마찬가지로 이러한 통제 장치가 필요하다.
나는 이를 Harness Engineering의 역할이라고 생각한다.
AI에게 작업 방법의 자유도를 주되, 그 자유도가 일정한 품질과 제약조건 안에서 발휘되도록 만드는 것이다.
결국 내가 생각하는 접근 원칙은 네 가지다.
1. 입력을 선언할 것
사람은 문제, 목표, 제약조건, 성공 기준을 정의한다.
구현의 세부 절차보다는 무엇을 달성해야 하는지 명확히 전달한다.
2. 최종 결과를 쉽게 볼 수 있도록 만들 것
결과물을 수많은 텍스트 파일로만 남기지 않는다.
UI라면 실제 동작하는 화면, 데이터 분석이라면 대시보드, 비즈니스 로직이라면 테스트 결과처럼 사람이 직관적으로 판단할 수 있는 형태로 표현한다.
3. AI가 수행하는 중간 과정은 적절히 블랙박스 처리할 것
모든 내부 사고 과정과 실행 단계를 사람이 따라갈 필요는 없다.
다만 중요한 설계 결정, 가정, 변경 사항, 실패 원인은 추적할 수 있어야 한다.
4. 대신 AI에게 적절한 Harness를 구축할 것
AI의 결과를 무조건 신뢰하지 않는다.
테스트, 평가 기준, 타입 시스템, 정적 분석, 제약조건, 실행 로그 등을 통해 잘못된 결과가 그대로 전달되지 않도록 한다.
이 네 가지 원칙을 적용하면 사람이 모든 과정을 마이크로 매니징하지 않더라도, AI의 자율성과 결과물에 대한 통제력을 함께 확보할 수 있지 않을까 생각한다.
결국 내가 추구하는 것은 AI의 작업 과정을 통제하는 것이 아니라, AI가 만들어 내는 결과의 품질을 통제하는 것이다.
4. Big Problem — 정말 해결할 가치가 있는 문제인가?
마지막으로 최근 가장 중요하게 생각하는 고민이다.
AI Agent를 활용하다 보면 새로운 기술 자체에 몰입하기 쉽다.
새로운 프레임워크가 등장하면 사용해 보고 싶고, 새로운 프로토콜이나 아키텍처가 나오면 직접 구현해 보고 싶어진다.
그런데 문득 이런 의문이 든다.
이 기술을 도입해서 해결하려는 문제가 정말 중요한 문제인가?
단순히 기술적으로 흥미로운 문제를 해결하는 것과 실제로 가치 있는 문제를 해결하는 것은 다르다.
아키텍처가 아무리 우아하고 Agent가 복잡한 작업을 자율적으로 수행하더라도, 그것이 실질적인 문제 해결로 이어지지 않는다면 과연 좋은 결과라고 할 수 있을까?
그래서 최근에는 접근 방식을 바꾸려고 한다.
기술을 먼저 선택하고 적용할 문제를 찾는 것이 아니라, 내가 실제로 겪고 있는 문제를 정의하고 AI가 그 문제를 얼마나 개선할 수 있는지 직접 검증하는 것이다.
최근 실험: AI를 활용한 투자 의사결정 고도화
요즘 집중하고 있는 문제 중 하나는 AI LLM을 활용해서 투자 의사결정의 품질을 높이는 것이다.
투자를 하다 보면 수많은 정보와 변수를 고려해야 한다.
예를 들어 특정 기업의 주가가 상승할 것이라는 가설을 세웠다고 하자.
그 가설 뒤에는 여러 인과관계가 존재한다.
시장 수요가 증가하면 기업의 매출이 증가할 수 있고, 공급이 제한된다면 제품 가격이 상승할 수 있다. 이는 다시 영업이익과 기업가치에 영향을 미칠 수 있다.
하지만 이러한 가설을 지속적으로 추적하고 검증하기는 쉽지 않다.
정보는 계속 바뀌고, 처음 세웠던 투자 가설이 여전히 유효한지 판단하려면 반복적인 리서치가 필요하다.
그래서 간단한 트래커를 만들었다.
구조는 다음과 같다.
- 사람이 투자 가설을 정의한다.
- 투자 가설을 여러 인과관계로 나누고 그래프로 표현한다.
- 각 사건의 발생 가능성에 대한 확률을 부여한다.
- AI가 주기적으로 관련 데이터를 리서치한다.
- 새로운 근거를 바탕으로 기존 가설과 확률을 재검토한다.
- 사람은 변화한 정보를 바탕으로 최종 투자 의사결정을 내린다.
여기서 내가 원하는 것은 AI가 대신 주식을 사고파는 것이 아니다.
내가 세운 가설이 여전히 타당한지, 어떤 새로운 정보가 기존 판단을 바꾸어야 하는지 지속적으로 검증하는 시스템이다.
이 방식이 의미 있다고 생각하는 이유는 앞에서 이야기한 원칙과 연결되기 때문이다.
사람은 투자 가설과 판단 기준을 선언한다.
AI는 자료 수집, 정보 분석, 가설 검증 등 반복적인 작업을 수행한다.
결과물은 인과 그래프와 트래커를 통해 사람이 이해하기 쉬운 형태로 표현한다.
그리고 AI가 잘못된 정보나 근거 없는 판단을 생성하지 않도록 출처 검증, 확률 변경 이력, 평가 기준 같은 Harness를 구축한다.
물론 이러한 시스템을 만들었다고 해서 실제 투자 성과가 좋아진다는 보장은 없다.
그 가치는 별도로 검증해야 한다.
예를 들어 기존 방식보다 가설 검증에 필요한 시간이 줄어들었는지, 중요한 정보를 놓치는 빈도가 감소했는지, 투자 판단의 일관성이 개선되었는지 등을 측정할 수 있을 것이다.
중요한 것은 AI Agent를 얼마나 복잡하게 만들었느냐가 아니다.
실제로 내가 겪고 있던 문제를 얼마나 개선했느냐가 중요하다.
5. 결국 내가 고민하는 것
지금까지의 고민을 종합하면 결국 세 가지 질문으로 귀결된다.
첫째, 무엇을 AI에게 위임하고 무엇을 사람이 책임져야 하는가?
AI가 코드를 생성하는 능력은 계속 좋아질 것이다. 하지만 문제 정의, 판단 기준, 설계 의도까지 무조건 AI에게 맡기는 것이 올바른 방향인지는 고민이 필요하다.
둘째, 어떻게 하면 AI의 생산성을 제한하지 않으면서 결과물을 이해하고 통제할 수 있는가?
모든 과정을 검토하는 마이크로 매니징보다는 적절한 추상화, 선언형 인터페이스, 결과물 Viewer, Harness Engineering이 중요하다고 생각한다.
셋째, AI를 활용해서 정말 가치 있는 문제를 해결하고 있는가?
코드를 더 빨리 만드는 것 자체가 최종 목표는 아니다. 개발 속도의 개선이 제품의 품질, 의사결정의 정확성, 비즈니스 성과로 이어지는지를 검증해야 한다.
AI Agent의 성능이 좋아질수록 사람이 직접 수행해야 하는 작업은 줄어들 수 있다.
그렇다면 사람에게 남는 역할은 무엇일까?
나는 좋은 문제를 정의하고, 적절한 추상화 수준에서 요구사항을 선언하고, 결과물을 검증하며, 최종 의사결정에 책임지는 것이라고 생각한다.
결국 AI를 잘 다룬다는 것은 프롬프트를 잘 작성하거나 최신 프레임워크를 능숙하게 사용하는 것만을 의미하지 않는다.
사람의 판단력과 AI의 실행 능력을 어떻게 결합해야 더 큰 문제를 해결할 수 있는지 설계하는 능력.
현재 내가 생각하는 AI Agent Engineering의 본질은 여기에 가깝다.