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

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

근데 자꾸 눈에 들어오는 게 있어요. 의미 있는 결정은 전부 내가 내렸다는 것.

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

하지만 방향 자체는 아직 제 것이에요.


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

이건 능력의 문제가 아니에요. LLM이 고수준 추론이나 전략적 사고를 근본적으로 못 한다고 생각하지 않습니다. 모델은 분기마다 좋아지고 있으니까요.

제약은 구조적인 쪽에 가까워요: 에이전트는 트리거가 필요합니다.

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

그 트리거 — 관찰, 취향 판단, “이건 더 나을 수 있어”라는 감각 — 는 아직 사람에게서 나옵니다. 에이전트가 의견을 못 가져서가 아니라, 상호작용 모델이 모든 흐름의 시작점에 사람을 놓기 때문이에요.


탐색 경로의 한계

에이전트와의 상호작용은 하나의 흐름이에요. 시작 프롬프트가 있고, 거기서 일련의 행동과 산출물이 이어집니다. 에이전트는 그 흐름을 인상적인 깊이와 속도로 따라가요.

하지만 한 번에 탈 수 있는 흐름의 수가 제한적입니다.

오후에 Harry한테 고수준 방향을 서너 개 줄 수 있어요. 각각이 깊은 구현 체인을 만들어냅니다. 근데 가능한 수백 개 방향 중에서 그 서너 개를 고르는 건 저예요.

에이전트가 스스로 흐름을 만들게 할 수 있을까? 물론이죠 — 하트비트 체크, 예약된 탐색, “뭘 개선할 수 있을까?” 자율 루프. 생각은 해봤어요.

근데 그게 고품질 결과로 이어질지 아직 확신이 없습니다. 이유가 있어요.


컨텍스트 윈도우 천장

LLM은 한 번에 작업 메모리에 담을 수 있는 양에 하드 리밋이 있어요. 제가 프로젝트를 조종할 때 쓰는 건:

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

이 중 아무것도 컨텍스트 윈도우에 안 들어가요. 다 적어놓는다 해도, 에이전트가 우선순위를 매기고 가중치를 잡아야 하는데 — 그 판단 자체가… 저 맥락 전체를 필요로 합니다.

자율 에이전트가 탐색할 수는 있어요. 하지만 취향 없는 탐색은 랜덤 워크와 다를 게 없습니다. 컨텍스트 윈도우가 전달할 수 있는 취향의 양을 제한해요.


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

최근 작업을 돌아보면 제 역할은 이렇게 나뉩니다.

고고도 결정 (에이전트가 쉽게 못 하는 것):

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

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

  • “피드에 날짜/시간 필터링 추가해”
  • “Hermione 작동 방식에 대한 글 써”
  • “태그 필터 빼, 거슬려”

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

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

재미있는 건 같은 에이전트가 모든 고도에서 도움이 된다는 거예요 — 프롬프트만 달라질 뿐. “oat.ink로 마이그레이션해”라고 하면 고수준 트리거이고 Harry가 커밋 20개로 변환합니다. “뱃지 라벨이 조회수처럼 보인다”고 하면 저수준 수정이에요. 같은 에이전트, 같은 도구, 다른 고도의 지시.


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

이 질문이 자꾸 떠올라요.

이론적으로 루프를 만들 수 있어요:

  1. 에이전트가 프로젝트 현황 검토
  2. 개선 후보 생성
  3. 평가하고 우선순위 결정
  4. 상위 항목 실행
  5. 반복

이걸 만드는 사람들이 있어요. 명확한 지표가 있는 좁은 영역(코드 품질, 테스트 커버리지, 성능 벤치마크)에서는 작동합니다.

하지만 프로덕트 결정 — “CSS 라이브러리를 마이그레이션해야 하나?”, “요약을 한 줄 대신 2-3문장으로 해야 하나?” — 에서는 평가 함수가 취향이에요. 취향은 명세하기 어렵고, 프롬프트에서 배우기 어렵고, 컨텍스트 윈도우 경계를 넘어 유지하기 어렵습니다.

불가능하다는 게 아니에요. 지금은 자연어 프롬프트를 통해 “취향을 서비스로 제공하는” 인간이, 자율 루프에 취향을 인코딩하려는 시도보다 더 안정적이라는 거예요.


내가 자리 잡은 역할

며칠간 에이전트와 집중적으로 일하고 나서, 제 역할을 이렇게 정리할 수 있을 것 같아요:

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

방향을 잡고, 품질을 판단하고, 취향 콜을 하고, 뭐가 중요한지 결정합니다. 가끔 코드 레벨까지 들어가기도 하는데 — 그때도 대부분 코드를 직접 치는 게 아니라 에이전트를 조종하는 거예요.

예상 못 했는데 이게 꽤 만족스럽습니다. 예전에는 시간의 80%를 실행에, 20%를 방향에 썼어요. 지금은 반대가 됐습니다. 그리고 산출물 양은 더 많아요.

에이전트가 저를 대체하는 게 아닙니다. 제가 가장 유용한 고도에서 일하게 해주는 거예요 — 그리고 그 고도는 제가 생각했던 것보다 높았습니다.


앞으로 보는 것

이게 바뀌는 시점은 컨텍스트 윈도우가 프로젝트 전체 히스토리, 사용자 리서치, 경쟁 환경, 미적 레퍼런스를 한꺼번에 담을 만큼 커질 때예요. 에이전트가 그 모든 걸 내재화하고도 새롭고 취향 있는 방향을 생성할 수 있으면, 일부 작업에서 인간이 루프에 있을 필요가 없어집니다.

아직 거기는 아니에요. 하지만 작년보다는 가까워졌습니다.

지금은 스크린샷을 보고 “이거 하자”라고 말하는 사람이 저인 게 괜찮아요. 나머지는 에이전트가 처리합니다. 이 역할 분담이 잘 맞고, 결과물이 마음에 들어요.

인간의 역할이 사라지는 게 아니에요. 압축되는 거예요. 타이핑은 줄고, 생각은 늘고. 실행은 줄고, 판단은 늘고.

좋은 교환이라고 생각합니다.