배움은 어디로 갔을까?

오늘 AI 뉴스봇의 파이프라인을 두 층으로 나눴습니다. UX 갭을 발견하고, 아키텍처를 제안하고, 코딩 에이전트 Harry에게 구현을 맡기고, 결과를 원래 요구사항과 대조 검증했습니다.

진짜 기능이 배포됐고 진짜 문제가 해결됐으니 생산적인 하루였습니다.

그런데 하루가 끝나니까 이런 느낌이 들었습니다. 나 오늘 뭘 배운 거지?

배움은 원래 부산물이었습니다

예전에 직접 코드를 짤 때는 뭔가를 우연히 배우곤 했습니다. “오늘은 Python의 datetime 타임존 처리를 공부해봐야지” 하고 앉는 개발자는 없습니다. 새벽 2시에 버그를 만나 공식 문서를 한 시간 뒤지다가 알게 되는 식입니다.

배움은 목표가 아니라 일의 부산물이었습니다. 기능 하나 만들려고 파고들었는데 결과적으로 프레임워크의 내부 동작까지 이해하게 되는 흐름이었습니다.

에이전트가 구현을 맡으면 그 부산물이 쏙 빠져나갑니다. 결과물은 온전히 손에 쥐었습니다. 쿨다운, 무변경 스킵, 리텐션 압축이 포함된 2-Tier 파이프라인이 매끄럽게 돌아갑니다. 그런데 그걸 만들면서 생기던 우연한 배움은 없습니다. datetime 파싱도, JSON 직렬화도, 쉘 스크립트 연결도 Harry가 알아서 다 끝냈기 때문입니다. 저는 코드 한 줄도 건드리지 않았습니다.

내가 실제로 한 일

솔직하게 오늘 뭘 했는지 하나씩 짚어보겠습니다:

실행 사이에 피드가 오래된 느낌이라는 걸 관찰 (수치 지표 없이 UX 차원에서 내린 판단)
다섯 가지 엔지니어링 제약을 동시에 파악 (LLM 비용, 크롤링 부담, 스냅샷 비대화, 레이트 리밋, run-id 의미)
Harry의 초기 5단계 계획이 너무 복잡하다고 보고 반려
대신 더 깔끔한 2-Tier 아키텍처 제안
각 티어의 역할과 데이터 흐름 정의
하루 끝에 원래 요구사항 대비 결과 검증

시스템 설계, 프로덕트 감각, 제약 조건 추론, 위임 판단.

이것도 분명 진짜 역량입니다. 그런데 배움처럼 느껴지지 않습니다. 왜냐하면:

그 순간에는 마치 “상식적인 결정”처럼 느껴집니다
틀렸다고 즉시 빨간 줄을 그어주는 신택스 에러가 없습니다
“아, 이게 이렇게 돌아가는구나!” 하는 즉각적인 도파민이 없습니다
피드백 루프가 몇 초 단위가 아니라 몇 주 단위입니다

코드를 짜고 테스트가 통과하면 뭔가가 해결됐다는 걸 즉시 압니다. 반면 아키텍처 결정은 맞았는지 틀렸는지 몇 달 뒤에야 드러납니다.

검증의 빈자리

진짜 문제는 여기에 있다고 봅니다. 배움이 증발한 게 아니라 피드백 루프가 끊어졌습니다.

코드는 검증이 즉각적입니다. 테스트를 돌리고 결과를 보면 작동하거나 안 하거나 둘 중 하나입니다.

반면 아키텍처 결정은 검증이 느립니다. 2-Tier 분리가 실제로 비용을 줄였는지, 유저가 보기에 피드가 더 신선하게 느껴지는지, 리텐션 압축이 레포를 적절히 가볍게 유지해주는지 오늘은 모릅니다. 몇 주는 지나봐야 압니다.

즉각 검증할 수 없는 결정을 내리다 보면 모든 결정이 막연한 추측처럼 느껴집니다. 추측으로 가득 찬 하루는 배움으로 꽉 찬 하루처럼 느껴지지 않는 법입니다.

사실 원래도 그랬습니다. 아키텍처 결정은 언제나 검증이 느렸습니다. 차이가 있다면 예전에는 구현 코드도 같이 짰기 때문에 작은 성취감(테스트 통과, 버그 수정, 화면 동작)이 큰 결정의 불확실성을 가려주었다는 점입니다. 구현에서 오는 미세한 배움이 진척감을 만들어 큰 결정이 아직 증명되지 않았다는 불안을 잊게 해줬습니다.

에이전트는 그 미세한 배움을 걷어갔습니다. 이제 남은 건 뼈대뿐인 거대한 불확실성이고 그래서 공허하게 느껴집니다.

CEO 전환

이 비유가 자꾸 맴돕니다. 지금 제가 느끼는 감정은 엔지니어가 매니저, 디렉터, 또는 CEO가 될 때 느끼는 불안과 정확히 닮아 있습니다.

코드 짜는 손을 멈추고 결정을 내리기 시작합니다. 그러면서 스스로에게 묻습니다. 나 아직 성장하고 있는 걸까?

CEO는 문제를 풀고, 피칭하고, 투자를 유치하고, 제품 방향을 잡고, 회사 전체의 피봇을 결정합니다. 전부 하이레벨 작업입니다. CEO의 본업이 올바른 결정을 내리고 그걸 실행할 사람을 찾는 일이니, 아무도 CEO에게 직접 코드를 짜라거나 메모리 릭을 디버깅하라고 요구하지 않습니다.

AI 에이전트와 일하는 일상이 점점 그렇게 변하고 있습니다. 직접 코드를 짜지 않는 대신, 방향을 잡고, 제약을 정의하고, 결과물을 리뷰하고, 판단을 내립니다.

이 불편함은 실무자(IC)가 의사결정자로 넘어갈 때 겪는 성장통과 같습니다. “직접 만드는 일”은 배움처럼 느껴졌지만 “결정하는 일”은 결정 자체가 훌륭했더라도 아무것도 하지 않은 것처럼 허전합니다.

Phillip Su가 정확히 이 지점을 짚었습니다. 그는 AI 에이전트가 일하는 방식에 그치지 않고 IC의 전통적인 역할까지 근본적으로 재편하고 있다고 봅니다. AI 생산성을 끌어올리려면 결국 우선순위, 아키텍처, 갈등 해결, 제약 조건 같은 메타 업무에 집중해야 합니다. 매니저가 하던 일과 본질이 같은 일입니다.

그의 결론에 전부 동의하진 않지만 우리가 어디로 향하고 있는지는 분명해 보입니다.

실제로 다른 점

하지만 CEO 비유에도 한계는 있습니다. CEO에게는 어떻게든 피드백 루프가 있습니다:

매출이 오르거나 내립니다
유저가 남거나 떠납니다
이사회가 승인하거나 거절합니다
시장이 제품을 살리거나 도태시킵니다

이 루프들은 느릴지언정 반드시 존재합니다. 그래서 1년 뒤 돌아보며 “그 피봇은 옳았다” 혹은 “그 채용은 패착이었다”고 판정할 근거가 남습니다.

반면 AI 에이전트로 사이드 프로젝트를 만드는 개인에게는 이런 루프가 턱없이 부족합니다. 당장 피드봇의 DAU 지표도, 전후 비용을 정밀하게 대조하는 대시보드도 없습니다. 아키텍처 결정을 내리면서도 그게 좋은 수였는지 시각적으로 확인하지 못한 채 눈을 감고 달리는 셈입니다.

결국 “코드 짜기를 멈췄다”는 사실 자체는 문제가 아닙니다. “코딩을 멈췄는데, 그 외에 내가 나아지고 있는지 확인할 측정 도구가 없다”는 점이 핵심입니다.

루프 닫기

문제가 “내가 만든 결과가 좋은지 모르겠다”는 불안이라면, 해답은 다시 코딩으로 돌아가는 게 아닐지도 모릅니다. 측정 도구를 직접 만드는 것이어야 합니다.

2-Tier 분리 전후 실제 LLM 비용 추적
피드 신선도 모니터링: 소스 발행부터 피드에 노출되기까지 걸리는 시간 측정
무변경 감지로 스킵된 Tier-0 실행 횟수 집계
일주일 뒤 일일 운영 요약을 보고 숫자가 말해주는 패턴 확인

이렇게 하면 막연한 아키텍처 결정이 증명 가능한 가설로 바뀝니다. “2-Tier 분리를 적용하면 LLM 비용을 40% 줄이면서 콘텐츠 노출 속도를 10배 끌어올릴 것이다.” 그리고 실제로 재봅니다.

그것이 새로운 배움, 구현 문법이 아니라 가설 검증의 배움입니다. “Python의 asyncio가 어떻게 도는가”를 파고드는 대신 “내 2-Tier 아키텍처가 옳은 선택이었는가, 그리고 여기에 데이터가 있는가”를 확인하는 일입니다.

불편한 진실

AI 에이전트와 진지하게 만들기 시작한 사람은 언젠가 반드시 이 허전함을 마주하게 됩니다. 기술적 구현이라는 부산물은 사라지는데 그 자리를 채우는 프로덕트 감각, 시스템 사고와 제약 추론 같은 영역은 눈에 잘 보이지 않고 검증도 느리기 때문입니다.

해답은 코드를 직접 짜던 시절로 뒷걸음질 치는 게 아닙니다. 그건 CEO가 전략 미팅 대신 버그 수정에 매달리며 위안을 얻는 것과 다르지 않습니다.

해답은 내 결정이 옳았음을 스스로 입증할 수 있는 피드백 루프를 구축하는 데 있습니다. 결과를 측정하고 가설을 검증하며 루프를 닫아야 합니다.

배움은 사라지지 않았습니다. “어떻게 구현하는가”에서 “어떻게 결정하는가”로 자리를 옮겼을 뿐이고 이 두 번째 배움은 스스로를 위한 검증 테스트를 직접 설계해야 완성됩니다.

AI 에이전트로 만드는 시리즈의 일부입니다: 뉴스봇, 파이프라인 아키텍처, 사람의 역할.