배움은 어디로 갔을까?

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

생산적인 하루였어요. 진짜 기능이 배포됐고. 진짜 문제가 해결됐고.

근데 하루가 끝나니까 이런 느낌이 들었어요: 나 오늘 뭘 배운 거지?

배움은 원래 부산물이었어요

예전에 직접 코드를 짤 때는 뭔가를 우연히 배우곤 했어요. “오늘은 Python의 datetime 타임존 처리를 공부해야지” 하고 앉는 사람은 없잖아요. 새벽 2시에 버그 만나서 문서 한 시간 뒤지다가 알게 되는 거예요.

배움은 목표가 아니었어요. 일의 부산물이었어요. 기능 하나 만들려고 했는데, 결과적으로 프레임워크를 이해하게 되는 거죠.

에이전트가 구현을 맡으면, 그 부산물이 사라져요. 결과물은 그대로 나왔어요 — 쿨다운, 무변경 스킵, 리텐션 압축이 포함된 2-Tier 파이프라인. 근데 그걸 만들면서 생기던 우연한 배움? 없어요. Harry가 datetime 파싱도 하고, JSON 직렬화도 하고, 셸 스크립트 연결도 다 했으니까요. 저는 하나도 안 건드렸어요.

내가 실제로 한 일

솔직하게 오늘 뭘 했는지 정리해볼게요:

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

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

이게 진짜 스킬이에요. 근데 배움처럼 느껴지지 않아요. 왜냐하면:

그 순간에는 “당연한 것”처럼 느껴져요
틀렸다고 알려주는 신택스 에러가 없어요
“아, 이렇게 되는 거구나!” 하는 도파민이 없어요
피드백 루프가 몇 초가 아니라 몇 주예요

코드 짜고 테스트가 통과하면 뭔가 됐다는 걸 알아요. 아키텍처 결정은 맞았는지 몇 달 뒤에야 알 수 있어요.

검증의 빈자리

진짜 문제는 이거라고 생각해요. 배움이 사라진 게 아니라, 피드백 루프가 끊어진 거예요.

코드는 검증이 즉각적이에요. 테스트 돌려요. 결과 봐요. 되거나 안 되거나.

아키텍처 결정은 검증이 느려요. 2-Tier 분리가 실제로 비용을 줄였나? 유저한테 피드가 더 신선하게 느껴지나? 리텐션 압축이 레포를 가볍게 유지하고 있나? 오늘은 몰라요. 몇 주 뒤에야 알 수 있어요.

즉시 검증할 수 없는 결정을 내리면, 모든 결정이 추측처럼 느껴져요. 추측으로 가득한 하루는 배움으로 가득한 하루처럼 느껴지지 않아요.

근데 사실 이건 원래 그랬어요. 아키텍처 결정은 항상 검증이 느렸어요. 차이점은 예전에는 구현 코드도 같이 짜니까 작은 성취감 (테스트 통과, 버그 수정, 기능 동작)이 충분해서 큰 결정의 불확실성을 가렸다는 거예요. 구현에서 오는 작은 배움이 진행감을 만들어서, 큰 결정이 아직 증명 안 됐다는 사실을 숨겨줬어요.

에이전트가 작은 배움을 없앴어요. 이제 남은 건 큰 불확실성뿐이에요. 그래서 공허하게 느껴지는 거예요.

CEO 전환

이 비유가 자꾸 떠올라요: 내가 느끼는 게 엔지니어가 매니저, 디렉터, CEO가 될 때 느끼는 것과 똑같지 않을까.

코드 짜는 걸 멈춰요. 결정을 내리기 시작해요. 그리고 궁금해져요: 나 아직 성장하고 있는 건가?

CEO는 문제를 해결하고, 피칭하고, 투자 유치하고, 프로덕트 방향을 잡고, 전체 방향을 피봇해요. 전부 하이레벨이에요. CEO한테 코드 짜라거나 메모리 릭 디버깅하라고 기대하지 않잖아요. CEO의 일은 맞는 결정을 내리고 실행할 수 있는 사람을 구하는 거예요.

AI 에이전트랑 일하는 게 점점 그런 느낌이에요. 코드를 짜고 있지 않아요. 방향을 잡고, 제약을 정의하고, 결과물을 리뷰하고, 판단을 내리고 있어요.

이 불편함은 모든 개인 기여자(IC)가 의사결정자로 전환할 때 느끼는 불편함과 같아요. “만드는 것”은 배움처럼 느껴졌어요. “결정하는 것”은… 아무것도 아닌 것처럼 느껴져요. 결정이 좋았더라도.

Phillip Su가 정확히 이걸 지적했어요 — AI 에이전트는 일하는 방식을 바꾸는 게 아니라 IC 역할 자체를 없애버린다고. AI 생산성을 최대화하려면 메타 일에 집중해야 해요: 우선순위, 아키텍처, 갈등 해결, 제약. 매니저가 하는 일과 같아요. Su의 결론은 명확해요: “IC의 영광스러운 날들은 끝났다.”

완전히 동의하지는 않아요. 하지만 방법이 있다고 생각해요.

실제로 다른 점

근데 CEO 비유도 한계가 있어요. CEO한테는 피드백 루프가 있거든요:

매출이 오르거나 내려요
유저가 남거나 떠나요
이사회가 승인하거나 거절해요
시장이 검증하거나 죽여요

이 루프들은 느리지만 존재해요. CEO는 1년 뒤에 돌아보고 “그 피봇은 맞았다” 또는 “그 채용은 실수였다”라고 말할 수 있어요.

AI 에이전트로 사이드 프로젝트를 만드는 사람한테는 이 루프가 거의 없어요. 피드봇의 DAU 지표가 없어요. 전후 비교하는 비용 대시보드가 없어요. 아키텍처 결정을 내리면서 동시에 그게 좋은지 나쁜지 보지 못하고 있어요.

그러니까 문제는 “코드 짜기를 멈춘 것”만이 아니에요. “코드 짜기를 멈췄는데 그 외에 내가 나아지고 있는지 알 방법도 없다”는 거예요.

루프 닫기

문제가 “내가 만든 게 좋은지 모르겠다”라면, 답은 코드를 다시 짜는 게 아닐 수도 있어요. 측정을 만드는 것일 수도 있어요.

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

모호한 아키텍처 결정을 증명 가능한 가설로 바꾸는 거예요. “2-Tier 분리가 LLM 비용을 40% 줄이면서 콘텐츠가 10배 빨리 뜨게 할 것이다.” 그리고 측정하는 거예요.

그게 배움이에요: 구현이 아니라 검증. “Python의 asyncio가 어떻게 동작하는지”가 아니라 “내 2-Tier 아키텍처가 맞는 결정이었는지, 그리고 여기 데이터가 있다”는 거예요.

불편한 진실

AI 에이전트로 뭔가를 만들기 시작한 사람은 결국 다 이 느낌을 만날 거라고 생각해요. 기술적 배움이라는 부산물이 사라지고, 그 자리를 채우는 것 — 프로덕트 감각, 시스템 사고, 제약 추론 — 은 보기 어렵고 검증이 느려요.

답은 코드를 다시 직접 짜는 게 아니에요. 그건 CEO가 전략 미팅보다 버그 수정이 더 생산적인 것 같다고 우기는 것과 같아요.

답은 내 결정이 좋았다는 걸 증명할 수 있는 피드백 루프를 만드는 거예요. 결과를 측정하고. 가설을 검증하고. 루프를 닫는 거예요.

배움이 사라진 게 아니에요. 이동한 거예요. “어떻게 구현하는가”에서 “어떻게 결정하는가”로 — 그리고 두 번째는 자기만의 테스트 스위트를 만들어야 해요.

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