발표자: Johan Lajili (Joan), Poolside AI
컨퍼런스: AI.Engineer
길이: ~10분
계층 1: 영상 전체 핵심 주장 요약
AI 코딩 에이전트에 대한 사람마다 극단적으로 다른 경험의 근본 원인은 "피드백 루프(feedback loop)"에 있다. 에이전트는 실제로 앱을 보지 못한 채 — 눈을 가린 채(blindfolded) — 작동하며, 자신이 구현한 것이 정말 동작하는지 검증할 수단이 없다. Poolside는 이 문제를 해결하기 위해 에이전트 스스로 앱을 테스트할 수 있는 CLI 도구 "Spoolside"를 만들었다. 이를 통해 얻은 핵심 교훈은 엔지니어의 역할이 바뀐다는 것 — 직접 코드를 짜는 것에서 AI가 잘 작동할 수 있도록 환경을 만들어주는 "AIX 엔지니어"로의 전환이 필요하다.
계층 2: 섹션별 상세 내용
[00:00–00:37] 소개 — Poolside AI
- Johan Lajili는 Poolside AI 소속. Poolside는 자체 파운데이션 모델(LM)과 코딩 에이전트를 처음부터 만드는 소수의 회사 중 하나.
[00:37–01:45] 문제 제기 — AI에 대한 두 갈래 경험
Reddit·Twitter에서 극명하게 갈리는 반응:
- 열광파: "코드를 전혀 직접 안 짜도 된다. AI가 다 해준다."
- 회의파: "프로덕션 앱에 써봤는데 쓰레기만 뱉는다."
이 괴리를 설명하는 흔한 오답 두 가지:
- "열광파는 AI 회사 홍보꾼이다" — 음모론
- "회의파는 레거시(brownfield) 앱을 쓰고 있어서다, 에이전트는 그린필드에서만 동작한다" — 표면적 설명
[01:45–02:40] 진짜 차이: 그린필드 vs 브라운필드
흔한 설명(레거시 코드 문제)은 완전히 틀리지는 않지만 본질이 아니다. 실제로 레거시 코드베이스에서도 AI를 성공적으로 사용한 사례를 Johan은 직접 경험했다.
진짜 차이는 에이전트의 직관(intuition)이 맞느냐 틀리냐:
- 그린필드: 에이전트의 직관이 정확함 → 표준적인 패턴대로 코드를 짜면 실제로 동작
- 브라운필드: 에이전트의 직관이 틀릴 가능성이 높음 → 미사용 코드, 예상 밖 의존성, 보지 못한 코드 구조가 도처에 존재
[02:40–04:00] 핵심 문제 — "눈 가린 에이전트(Blindfolded Agent)"
에이전트가 "인증 플로우 구현 완료, 모두 정상 동작합니다"라고 말할 때 실제 의미:
"내가 가진 능력의 범위에서, 당신이 나에게 준 정보를 바탕으로 판단했을 때, 아마도 동작할 것 같습니다."
에이전트는 실제로 앱을 실행하고 확인하지 않는 한 진짜로 동작하는지 알 수 없다. 이것이 사용자를 두 종류로 나누는 지점:
| 유형 | 반응 |
|---|---|
| AI 수용파 | "동작 안 하네? 로그 확인하고 다시 해봐" |
| AI 회의파 | "AI는 거짓말쟁이다, 못 믿겠다" → 포기 |
[04:00–07:30] 해결책 — Spoolside CLI (피드백 루프 구축)
Poolside가 내부적으로 만든 CLI 도구 "Spoolside":
Spoolside가 제공하는 기능:
- 스크린샷 캡처: 앱 현재 화면 저장 (일반 웹앱은 기존 도구로 가능하지만, Poolside 앱은 VS Code 익스텐션이라 별도 처리 필요)
- 토큰 압축 스냅샷: 웹 페이지 현재 상태를 토큰 효율적으로 표현
- 로그 추출: 백엔드·프론트엔드 등 다양한 서비스 로그 실시간 접근
- 서비스 재시작: 문제 발생 시 관련 서비스를 리셋
- 고수준 명령 실행: "이 메뉴로 이동해", "에이전트에게 메시지 보내", "이미지 업로드" 등 UX 레벨 작업
왜 중요한가: 에이전트가 버그 수정 전에 먼저 버그를 직접 재현할 수 있게 된다.
"버그를 재현하기 전까지는 네 코드를 믿지 않겠다."
이것이 신뢰(trust)의 첫 번째 단계. 이게 없으면:
- 에이전트가 직관적으로 수정했더라도 사람이 직접 확인해야 함
- 밤새 에이전트를 혼자 돌릴 수 없음 → 자동화 불가
[07:30–07:40] 핵심 메시지 — 엔지니어의 새 역할: AIX 엔지니어
Spoolside는 공개 오픈소스가 아니다. 중요한 것은 각자가 자신만의 도구를 만드는 것.
엔지니어의 역할 변화:
기존 Product Engineer
→ "나는 코드를 짠다"
신규 AIX Engineer
→ "나는 AI가 코드를 잘 짤 수 있게 만든다"
무엇을 만들어야 하는가:
- AI가 앱을 테스트할 수 있는 도구 (CLI, MCP, skill)
- 코드베이스를 AI가 쉽게 이해하도록 정리
- AI가 참고할 지식베이스(knowledge base) 강화
[07:40–09:41] Q&A — 자동화 테스트 vs 휴먼 테스트
Q: 자동화된 테스트 스위트를 쓰지 않는 이유?
자동화 테스트의 한계:
- 너무 경직되어 있어(rigid) 예상 외 상황에 취약
- 시간이 지날수록 유지보수 비용이 커짐
선호하는 방식: 사람이 앱을 테스트하는 방식을 그대로 흉내내는 도구.
AI에게 문제를 스스로 발견하게 만드는 법:
- 직접 "버튼이 왼쪽으로 치우쳐 있어"라고 말하지 말고 → AI가 스스로 발견하도록 환경 조성
- 로그를 돌아보고 AI에게 "이상한 점 있어? 안티패턴 발견해"라고 물어보는 재귀적 루프(retro loop)
sleep(15)남발처럼 반복적인 나쁜 패턴을 AI에게 발견시키는 스모크 테스트
도메인별 커스텀 도구 필요:
- Unity 게임 → AI에게 3D 월드를 ASCII로 표현
- 권한 시스템이 복잡한 앱 → 다양한 로그인 상태를 AI가 자동 전환
계층 3: 핵심 개념/용어 설명
| 용어 | 설명 |
|---|---|
| Blindfolded Agent (눈 가린 에이전트) | 에이전트가 실제 앱 상태를 볼 수 없어, 자신이 만든 것이 동작하는지 모른 채 "아마 될 것 같다"고만 말하는 상태 |
| Feedback Loop (피드백 루프) | 에이전트가 작업 결과를 실제로 실행·확인하고 오류를 수정하는 순환 과정. 이것이 있어야 AI 신뢰 가능 |
| Spoolside | Poolside 내부 CLI 도구. 에이전트가 VS Code 익스텐션인 자사 앱과 상호작용(스크린샷, 로그, 명령 실행)할 수 있게 해줌 |
| AIX Engineer | AI를 직접 부리기 전에 AI가 잘 작동할 환경을 먼저 구축하는 엔지니어. "마스크를 먼저 자신에게" 비유 |
| Greenfield | 새로 시작하는 프로젝트. 에이전트의 직관과 실제 코드 구조가 일치 → AI 성과 높음 |
| Brownfield | 기존 레거시 코드베이스. 예상 밖 패턴, 죽은 코드, 미탐색 영역이 많아 에이전트 직관이 빗나감 |
| Retro Loop (회고 루프) | 작업 완료 후 로그를 AI에게 보여주며 "이상한 패턴 있어?"를 반복 물어보는 디버깅 루프 |
| Token Compressed Snapshot | 웹 페이지나 앱 상태를 컨텍스트 토큰을 최소화하며 표현하는 방식 |
계층 4: 실행 포인트 & 시사점
즉시 적용 가능한 것
-
에이전트가 버그를 재현하게 만들어라
- "이 버그 고쳐줘" 대신 "이 버그를 먼저 재현해서 나한테 보여줘, 그 다음에 고쳐"
- 재현 성공 전까지 코드 변경을 신뢰하지 말 것
-
AI를 위한 자체 테스트 도구를 CLI/MCP로 만들어라
- 내 앱에 맞는 로그 추출, 상태 스냅샷, 재시작 명령을 묶은 도구
- 형태는 CLI, MCP 서버, 스킬 중 편한 것 선택
-
AI에게 문제를 직접 지적하지 말고 발견하게 만들어라
- "버튼이 왼쪽에 있어" 대신 → AI가 스스로 볼 수 있는 환경 제공
- 매번 말해주는 것을 자동화 포인트로 변환
-
회고 루프를 주기적으로 실행하라
- 로그를 AI에게 보여주고 "안티패턴이나 이상한 점 발견해" 반복
sleep()남발, 반복 코드, 미사용 변수 등을 AI가 먼저 발견하도록
-
"마스크 먼저 착용" 원칙 적용
- AI에게 기능 개발을 맡기기 전에, AI가 자립적으로 검증할 수 있는 환경을 먼저 만들어라
- 단기적으로 느려도 멀티 에이전트·야간 자동화로 이어지는 투자
시사점 (큰 그림)
- "Product Engineer → AIX Engineer" 전환은 선택이 아니다: AI 에이전트 멀티플라이어 시대에는 에이전트가 잘 동작할 조건을 만드는 것이 직접 코딩보다 레버리지가 크다.
- 에이전트 신뢰는 증명을 통해서만 쌓인다: 에이전트 주장을 믿어주는 것이 아니라, 에이전트가 실제로 검증할 수 있는 환경을 만드는 것이 핵심.
- 도메인 특화 도구가 경쟁력: 범용 AI 도구만으론 충분하지 않다. 내 제품·팀 상황에 맞는 에이전트 피드백 루프 인프라가 실질적 AI 활용 수준을 결정한다.
Source: AI.Engineer Conference, Johan Lajili (Poolside AI)
Processed: 2026-07-09