루프 속의 인간: AI 에이전트가 아직 당신에게 필요로 하는 것

며칠 동안 블로그를 만들고, CSS 라이브러리를 마이그레이션하고, AI 뉴스 피드봇을 업그레이드하고, 그 과정을 전부 글로 썼습니다. 코드는 거의 직접 쓰지 않았습니다. AI 에이전트 두 대인 Harry와 Hermione가 대부분의 구현을 도맡았습니다.

그런데 자꾸 눈에 들어오는 사실이 있습니다. 의미 있는 결정은 전부 제가 내렸다는 점입니다.

에이전트가 생각을 못 해서가 아닙니다. Harry는 요약 품질을 올리려면 기사 본문을 직접 읽어야 한다는 것을 스스로 알아냈습니다. Hermione는 시키지 않아도 문서를 재구성했습니다. 방향을 잡아주면 저수준 디테일을 채우는 일은 정말 잘합니다.

하지만 방향 자체는 여전히 제 몫이었습니다.

왜 인간이 아직 핸들을 잡고 있나

모델이 분기마다 빠르게 좋아지는 것을 보면 LLM이 고수준 추론이나 전략적 사고를 근본적으로 못 한다고 생각하지 않습니다.

제약은 능력보다는 구조적인 쪽에 가깝습니다. 에이전트에게는 트리거가 필요합니다.

누군가는 첫 프롬프트를 보내야 합니다. Perplexity에서 스크린샷을 보고 “이걸로 마이그레이션하자”고 생각하는 것도, 피드봇 출력을 보고 “이 요약 별로인데”라고 느끼는 것도 사람입니다. 데이터를 덮어쓰기보다 누적하는 게 낫다고 판단하는 것도 마찬가지입니다.

그 트리거, 즉 관찰과 취향 판단, “이건 더 좋아질 수 있겠는데” 싶은 감각은 아직 사람에게서 나옵니다. 에이전트가 의견을 가질 수 없어서가 아니라, 상호작용 모델 자체가 모든 흐름의 시작점에 사람을 두고 있기 때문입니다.

탐색 경로의 한계

에이전트와의 상호작용은 하나의 궤적입니다. 시작 프롬프트가 주어지면 거기서 일련의 행동과 산출물이 이어집니다. 에이전트는 그 경로를 인상적인 깊이와 속도로 파고듭니다.

하지만 한 번에 탈 수 있는 흐름의 수에는 한계가 있습니다.

오후 동안 Harry에게 줄 수 있는 고수준 방향은 서너 개입니다. 각각이 깊은 구현 체인을 만들어냅니다. 그런데 가능한 수백 가지 방향 중에서 그 서너 개를 고르는 사람은 결국 저입니다.

에이전트가 스스로 흐름을 만들게 하는 것도 물론 가능합니다. 주기적 헬스체크나 예약된 탐색, “무엇을 개선할 수 있을까?”를 묻는 자율 루프 같은 방법이 있습니다. 생각은 이미 해봤습니다.

그런데 그것이 고품질 결과로 이어질지는 아직 확신이 없습니다. 이유가 있습니다.

컨텍스트 윈도우 천장

LLM이 한 번에 작업 메모리에 담을 수 있는 양에는 물리적인 한계가 있습니다. 제가 프로젝트를 조종할 때 쓰는 것들은 대략 이렇습니다:

수년간 쌓인 엔지니어링 직관
사용자가 실제로 무엇에 신경 쓰는지에 대한 감각
수천 개 프로덕트를 써보며 형성된 개인적인 취향
프롬프트에 다 들어가지 않는 비즈니스 맥락
물리적 세계의 신호 (핸드폰 스크린샷, 동료와의 대화, 도구를 쓰다 느낀 사소한 불편함)

이 중 아무것도 단일 컨텍스트 윈도우에 온전히 들어가지 못합니다. 다 적어놓는다고 해도 에이전트는 그것들에 우선순위를 매기고 가중치를 잡아야 합니다. 그런데 그 판단 자체가 저 모든 맥락을 전제로 합니다.

자율 에이전트도 탐색은 할 수 있지만 취향 없는 탐색은 무작위 걷기(random walk)와 다를 바 없습니다. 그리고 취향을 얼마나 전달할 수 있는지는 컨텍스트 윈도우의 크기가 제한합니다.

내가 하루 종일 실제로 하는 것

최근 작업을 돌아보면 제 역할은 대략 세 층위로 나뉩니다.

고고도 결정 (에이전트가 쉽게 흉내 내기 어려운 것):

“블로그를 만들자” → 왜 만드는지, 누구를 위한 것인지, 어떤 톤을 유지할지
“oat.ink로 마이그레이션하자” → 스크린샷에서 촉발된 미적 판단
“이 요약 별로다” → 수천 편의 글을 읽으며 형성된 품질 기준
“데이터를 덮어쓰지 말고 누적하자” → 미래 가치에 대한 프로덕트 직관

중고도 방향 (좋은 프롬프팅으로 에이전트가 수행 가능한 것):

“피드에 날짜와 시간 필터링 추가해줘”
“Hermione 작동 방식에 대한 글 써줘”
“태그 필터는 거슬리니까 빼자”

저고도 실행 (에이전트가 가장 뛰어난 영역):

코드 작성
CSS 수정
HTML 새니타이제이션 디버깅
빌드, 커밋, 푸시, 배포

흥미롭게도 같은 에이전트가 모든 고도에서 도움이 됩니다. 프롬프트의 층위만 달라질 뿐입니다. “oat.ink로 마이그레이션해”라고 던지면 Harry가 커밋 20개로 구체화하고, “뱃지 라벨이 조회수처럼 보인다”고 던지면 저수준 수정을 해냅니다. 같은 도구로 다른 고도의 지시를 다루는 셈입니다.

에이전트가 스스로 방향을 잡을 수 있을까?

이 질문이 자꾸 떠오릅니다.

이론적으로는 루프를 설계할 수 있습니다:

에이전트가 프로젝트 현황 검토
개선 후보 생성
평가 및 우선순위 결정
상위 항목 실행
반복

실제로 이런 구조를 시도하는 사람들도 있습니다. 코드 품질이나 테스트 커버리지, 성능 벤치마크처럼 명확한 수치가 있는 좁은 영역에서는 잘 작동합니다.

하지만 CSS 라이브러리 교체나 요약 길이 확대 같은 제품 결정에서는 평가 함수 자체가 곧 취향입니다. 취향은 프롬프트 몇 줄로 명세하기 어렵고, 컨텍스트 경계를 넘어 일관되게 유지하기는 더 어렵습니다.

완전히 불가능하다는 말은 아닙니다. 다만 지금은 인간이 자연어 프롬프트로 취향을 주입해주는 편이 자율 루프에 취향을 억지로 인코딩하려는 시도보다 훨씬 안정적입니다.

내가 자리 잡은 역할

며칠간 에이전트와 밀도 있게 협업하면서 제 역할을 이렇게 정리하게 됐습니다:

코드도 읽을 줄 아는 크리에이티브 디렉터.

방향을 잡고, 품질을 판단하고, 취향에 맞게 결정을 내리고, 무엇이 중요한지 가려냅니다. 가끔 코드 레벨까지 들어가기도 하지만 그때도 대부분 직접 코드를 치기보다는 에이전트를 조종하는 일에 가깝습니다.

예상하지 못했는데 이 방식이 꽤 만족스럽습니다. 예전에는 시간의 80%를 실행에 쓰고 20%를 방향 고민에 썼다면, 지금은 그 비율이 뒤집혔습니다. 그러면서도 산출물의 양은 훨씬 늘어났습니다.

에이전트가 저를 대체하는 게 아니라, 제가 가장 가치 있는 고도에서 일할 수 있게 밀어 올려주는 셈입니다. 그 고도는 제가 생각했던 것보다 더 높은 곳에 있었습니다.

앞으로 지켜보는 것

이 균형은 컨텍스트 윈도우가 프로젝트 전체 히스토리, 사용자 리서치, 시장 맥락, 미적 레퍼런스를 한꺼번에 담을 만큼 커질 때 깨질 겁니다. 에이전트가 그 모든 것을 소화한 상태에서 새롭고 취향 있는 방향을 제시할 수 있다면, 일부 작업에서는 인간이 루프 안에 머무를 필요가 줄어들 것입니다.

아직 거기까지는 아닙니다. 그래도 작년보다는 훨씬 가까워졌습니다.

지금으로서는 스크린샷을 보고 “이거 해보자”고 말하는 역할로 충분히 즐겁습니다. 실행은 에이전트가 맡고, 저는 방향을 봅니다. 이 분업은 매끄럽게 돌아가고, 결과물도 마음에 듭니다.

인간의 역할은 사라지지 않고 판단과 방향성으로 압축되고 있습니다. 타이핑 대신 고민에 시간을 쓰는 편이 훨씬 생산적인 교환이라고 느낍니다.