느낌이 아니라 데이터로 — 백엔드 엔지니어가 장애 때 하던 그대로, 자기 로그부터 깠다.
코드를 거의 안 치게 된 백엔드 엔지니어가 "나 지금 뭘 하고 있는 거지?"라는 질문에 느낌 말고 데이터로 답해본 기록입니다. 깠더니 다 나왔습니다. 내 직무가 어디로 갔는지, 어떤 평가자가 됐는지, 어디서 새는지까지.
1. 코드를 안 치게 됐는데, 나는 뭘 하는 사람이지?
저는 전형적인 백엔드 엔지니어였습니다. API를 설계하고, 쿼리를 튜닝하고, 장애가 나면 로그부터 뒤지는. 그런데 지금은 제 손으로 코드를 치는 시간이 거의 0에 수렴합니다. 하루 종일 AI에게 일을 시키고, 결과를 보고, 다음 지시를 내립니다.
그러던 중 How to Be a 30x AI Engineer with a Taste라는 글을 읽었습니다. 요지는 셋입니다. 코드 생성은 commodity가 됐다. 남는 일은 평가다. 그 평가 능력 — 글의 표현으로는 taste, "내부 평가 함수의 품질" — 이 몸값을 가른다. 그리고 불편한 문장 하나. "taste가 더 좋은 사람보다 두 배 열심히 일해도 절반의 가치밖에 못 만든다."
진짜 불편했던 건 그다음 질문입니다. 코드를 안 치게 된 건 분명한데, 그 시간에 나는 정말 "평가"를 하고 있나? 아니면 AI 옆에서 바빠 보이기만 한 건가? 느낌으로는 답할 수 없었습니다. 잘 쓰고 있다는 감각은 있는데 증거가 없어요. 그래서 백엔드 엔지니어가 장애 앞에서 하던 그대로 했습니다. 로그부터 깠습니다.
2. 그래서 로그를 깠다
깐 로그는 세 종류입니다.
전수 분석의 굵은 숫자들:
사용자 프롬프트 6,862개, 어시스턴트 턴 162,587개
도구 호출의 60%가 Bash (58,218회) — AI가 말만 하는 게 아니라 실제로 실행
서브에이전트 위임 1,296회
하루 최대 22,441턴 (5/14, 풀타임 페어링)
하루 2만 턴쯤 되면 "가끔 쓰는 도구"라고 부르기는 어렵습니다. 상시 가동되는 생산 라인이죠. 이제 이 생산 라인에서 제가 뭘 하고 있었는지 보겠습니다.
3. 발견 ① — 내 일은 이미 "평가"였다
최근 한 달의 프롬프트 3,918개를 작업 유형으로 분류해봤습니다(다중 라벨).
검증(952건)이 구현(1,024건)에 맞먹습니다. 대부분의 개발자는 AI가 짠 코드를 "테스트 통과했네, 머지" 하고 넘어갑니다. 제 로그에선 구현 요청 하나당 거의 하나꼴로 리뷰·검증 요청이 따라붙었어요. "평가가 곧 직무"라는 30x 글의 문장은, 제가 의식한 적도 없는 작업 분포에 먼저 와 있었습니다.
"AI 운영"이라는 새 직무가 작업의 23%를 차지합니다. 스킬 파이프라인 설계, 자율 루프, 봇 운영 — AI로 일하는 단계를 지나 AI 시스템 자체를 만들고 굴리는 일입니다. 백엔드 엔지니어가 인프라를 운영하듯, 지금은 에이전트를 운영합니다.
일이 사라진 게 아니라 층위가 올라간 겁니다. 코드를 만들던 사람에서, 코드를 만드는 시스템을 평가하고 운영하는 사람으로.
코드를 만드는 사람에서, 코드를 만드는 시스템을 평가·운영하는 사람으로 — 일은 사라지지 않고 층위가 올라간다.
재밌는 디테일 하나. 제 입력의 중앙값은 39자인데, 800자가 넘는 입력도 1,989건입니다. 결정은 "ㄱㄱ", "A로 진행" 같은 초단문으로, 새 작업 위임은 사양서급 장문으로. 이 양극화가 곧 평가자의 입력 패턴입니다. 짧은 입력은 평가고, 긴 입력은 명세입니다.
어떤 평가자인지도 측정됩니다. 30x 글이 말하는 taste의 다섯 영역에 제 데이터를 얹고 자가 채점을 해봤습니다.
/insights가 서술해준 제 인터랙션 스타일은 이랬습니다.
"폭넓은 실행을 위임하되, Claude가 검증된 증거 대신 가정으로 추론하는 순간마다 단호하게 방향을 돌리는 실시간 팩트체커로 행동한다."
30x 글에 "PR보다 그 코드를 만든 프롬프트를 보고 싶다"는 말이 나오는데, 제 위임 프롬프트가 이미 그 역할을 하고 있었습니다. 코드 리뷰가 프롬프트 리뷰로 옮겨간 거죠.
뼈아픈 쪽도 있습니다. 저는 ③품질 판단에 몰빵된 엔지니어입니다. 가장 레버리지가 크다는 ①문제 선택은 데이터에 거의 안 보여요. 티켓을 잘 처리하는 능력과 어떤 티켓이 존재해야 하는지 정하는 능력은 다른 근육인데, 후자는 로그에 안 찍히는 게 아니라 정말 안 하고 있었던 겁니다. 까보기 전엔 몰랐던 빈칸입니다.
4. 발견 ② — 전환은 3월에 시작됐다
이 평가자가 언제 만들어졌는지도 로그에 있습니다. 프롬프트 히스토리 17,587개를 시간순으로 늘어놓으면 7개월의 전환 과정이 그대로 보입니다.
(어휘 수치는 해당 단어가 등장한 월별 프롬프트 수, 단순 키워드 매칭)
백엔드 API를 만들던 사람이(11월) AI 툴킷을 만들고(2월) AI 플랫폼을 운영하게 되는(3월~) 흐름이 프로젝트 이름에 그대로 찍혀 있습니다. 어휘 변화는 더 또렷합니다. "검증"은 1~2월엔 월 한 자릿수였다가 3월부터 폭증합니다. 평가자로의 전환이 언제였는지 날짜까지 데이터에 남아 있습니다. 4월보다 프롬프트가 39% 적은 5월에 하루 22,441턴 피크가 찍혔습니다. 말수는 줄고, 지시 하나가 굴리는 작업은 커진 겁니다.
성장은 회고록보다 로그에 먼저 기록돼 있었습니다.
5. 발견 ③ — 그런데 새고 있었다 ⚠️
측정의 진짜 효용은 칭찬이 아니라 빨간펜입니다. 짚고 갈 게 하나 있는데, 아래 도구 호출 숫자들은 제가 친 명령이 아니라 에이전트가 실행한 겁니다. 그래서 더 문제입니다 — 직무가 "AI 시스템 운영"이라면, 에이전트가 새는 건 곧 운영자인 제 성적표니까요.
에이전트가 새는 곳.
grep 7,933회 vs 시맨틱 검색(serena) 50회 — 159:1. 시맨틱 인덱스를 깔아주고, 전역 메모리에 "코드 fact-check는 serena 필수"라고 적어줘도, 에이전트는 익숙한 길(grep)로 갑니다. 규칙을 적어두기만 하고 강제하지 않은 운영 공백입니다.
cd 14,104회, cat 1,940회. cat은 전역 규칙으로 금지했는데도 새고 있었고, cd는 호출마다 디렉토리 상태가 사라져 매번 다시 이동하는 순수 낭비입니다. 에이전트에게 적어둔 규칙은 권고일 뿐이었습니다.
내가 새는 곳.
"다시", "그대로" 재지시 359회. 이건 제 쪽 숫자입니다. 의도가 한 번에 전달되지 않아 같은 지시를 반복한 횟수 — 제 명세의 품질이 그대로 측정됩니다.
어시스턴트 턴의 89%가 최상위 모델. 단순 파일 탐색·테스트 실행까지 가장 비싼 모델이 돌고 있었습니다. 이건 제 설정 문제입니다. 평가 깊이에 따라 모델을 배분하지 않은 거죠.
둘이 같이 새면 사고가 납니다. 훅 하나만 지워달라고 했는데 메모리 시스템 전체가 uninstall된 적이 있습니다. 에이전트의 오독에 제 평가가 한 박자 늦게 따라간 결과죠. 비가역 작업 앞에서 운영자의 확인이 늦으면 무슨 일이 생기는지 보여준 사례입니다.
발견 셋이 가리키는 방향은 하나입니다. taste는 자격증이 아니라 운영입니다. 내 평가 함수도 새고, 내가 운영하는 에이전트도 샙니다. 새는 걸 측정하지 않으면 "나 AI 잘 쓰는데?"라는 느낌만 남습니다. 어디서 토큰과 시간이 새는지는 모른 채로요.
6. 그래서 바꾸는 것들
측정이 가리킨 개선 방향 네 가지. 전부 "새 도구 도입"이 아니라 이미 쓰는 것의 손실 차단입니다.
① 검증을 사람 루프에서 시스템으로. 덱·글·진단을 내보내기 전 "주장 단위로 VERIFIED/UNVERIFIED 태깅"하는 팩트체크 패스를 매번 손으로 돌렸는데, 이걸 커스텀 스킬로 박제합니다. 제가 잘하는 걸 제가 안 해도 되게.
② 에이전트의 습관은 규칙이 아니라 시스템으로 강제. "cat 쓰지 마"라고 적어두는 대신, 훅이 자동 교정하게. grep 대신 탐색 전용 서브에이전트가 기본값이 되게. 159:1은 구조로만 뒤집히는 숫자입니다.
③ 평가 깊이에 모델을 배분. 설계·어려운 디버깅은 최상위 모델, 기계적 검증·탐색은 작은 모델로. 평가자의 일은 "어디에 비싼 평가를 쓸지" 정하는 것까지 포함입니다.
④ taste를 공개 자산으로. 30x 글의 표현을 빌리면, 포트폴리오는 "어떤 인터뷰도 재현할 수 없는 taste의 증명"입니다. 이 글 같은 사례 공유, 튜토리얼, 공개 설계 문서가 이력서의 자리를 대체합니다.
30x 글은 "taste는 늘 직무였다, 코드 안에 숨어 있었을 뿐"(의역)이라며 끝납니다. 동의합니다. 하나만 보태고 싶어요. 그 taste는 측정하기 전엔 보이지 않습니다. 제가 어떤 평가자인지, 어디가 비었는지, 어디서 새는지 — 전부 로그에 있었는데, 까보기 전엔 몰랐으니까요.
까보면서 새삼 느낀 것도 있습니다. 백엔드 엔지니어가 하던 일의 절반은 원래 평가였다는 것. 스키마 리뷰, 쿼리 플랜 읽기, 장애 원인 좁히기, 트레이드오프 정하기. 그 근육을 AI 출력 위에서 돌리는 게 제 전환의 전부였고, 시작은 제일 익숙한 일이었습니다. 로그 까기요.
🛠️ 다른 분들도 체크해보면 좋을 것 같은 부분
Claude Code 사용자라면
/insights한 줄 — 리포트가~/.claude/usage-data/에 생깁니다구현 대비 검증 비율 — 내 프롬프트에서 리뷰·검증이 얼마나 되는지 (저는 952 vs 1,024)
새는 도구 호출 — grep·cat·cd처럼 더 나은 대안이 있는 명령이 몇 번 돌았는지 (저는 159:1)
"다시" 재지시 횟수 — 명세 품질의 프록시 (저는 359회)
어휘 타임라인 —
~/.claude/history.jsonl에서 "검증" 같은 단어가 언제부터 늘었는지 보면 자기 전환 시점이 나옵니다전수 집계가 필요하면
~/.claude/projects/의 세션 JSONL — 저는 이 집계도 Claude Code에게 시켰습니다
