한 줄씩 리뷰하는 게 직접 짜는 것보다 느렸다 — 에이전트 시대엔 실무자가 아니라 C레벨로

2026-06-10 · Ascendy Engineering

TL;DR

에이전트와 일할 때, 실무자(IC)처럼이 아니라 C레벨처럼 접근해야 한다는 게 이 글의 주장(내 의견)이다.
시작은 흔한 통증이다: AI가 짠 코드를 한 줄씩 리뷰하니 직접 짜는 것보다 느렸다. “이게 효율적인가?”
정직하게: 예전엔 그 리뷰가 옳았다. 모델이 약하면 교차검증이 불가능하니까. 바뀐 건 모델이 시니어급+에 올라온 것(내 신뢰 기준은 Opus 4.7~4.8, GPT-5.5 즈음).
그래서 이제 리뷰조차 에이전트-에이전트 교차가 낫다 — 피곤한 내가 관성으로 어프루브해 문제 난 빈도가, Codex-Claude 크로스체크보다 높았으니까(내 관찰). CTO가 코드가 아니라 코드를 만드는 시스템·팀·문화를 통제하듯, 당신의 가치도 하기/리뷰하기에서 그 일을 하는 시스템을 설계하기로 옮겨간다.

소스 노트. 이 글은 운영자 인터뷰로 쓴 칼럼/오피니언이다(여러 에이전트를 동시에 굴리는 솔로 운영자의 1차 경험). 의견은 의견으로, 추측은 추측으로 적었다 — 특히 C레벨에 대한 서술은 내가 그 자리에 가본 적 없는 바깥에서의 추측이다. 관련 글: 적대적 에이전트-페어 하네스 redteam(여기서 말하는 ‘시스템’을 도구화한 것), 두 AI가 같은 답을 골랐다, 멀티 AI를 붙였더니 느려졌다.

리뷰가 직접 짜는 것보다 느렸다

처음엔 당연한 줄 알았다. AI에게 코드를 시키고, 내가 검수한다. 사람이 마지막 문을 지킨다 — 옳은 그림처럼 보였다.

그런데 어느 순간 멈칫했다. Claude가 짠 코드를 한 줄씩 리뷰하는 데 드는 시간이, 내가 그냥 직접 짜는 시간보다 더 걸렸다. 그럼 이게 효율적인 게 맞나? 아마 지금 많은 개발자가 똑같은 의문 앞에 서 있을 것이다. “AI 쓰면 빨라진다더니, 왜 나는 검수에 더 시달리지?”

그런데 — 예전엔 그 리뷰가 옳았다

여기서 정직해야 한다. 내가 한 줄씩 리뷰한 데는 이유가 있었다. 코딩 에이전트 모델이 그만큼 못 미더웠기 때문이다. 모델이 약하면 교차검증 자체가 불가능하다 — 약한 모델이 약한 모델을 검증해봐야 둘 다 같은 구덩이에 빠질 뿐이다. 그 시절엔 사람이 한 줄씩 보는 게 유일하게 신뢰할 수 있는 게이트였다. 리뷰는 비효율이 아니라 필요였다.

그러니 “AI 코드를 검수하지 마라”가 이 글의 요지가 아니다. 바뀐 건 나의 자세가 아니라 전제다.

임계점 — 의심이 신뢰로

각 벤더의 LLM이 일정 수준을 넘어 시니어급 이상의 실력이라는 확신이 드는 순간이 왔다. 내 경우 그 신뢰는 Claude Opus 4.7~4.8, GPT-5.5 즈음에 형성됐다. (이건 벤치마크 단정이 아니라, 내가 신뢰하게 된 임계점이다.)

그 지점에서 감정이 바뀌었다. 의심에서 신뢰로, 그리고 해방감으로. 모든 줄을 내 눈으로 막아야 한다는 강박을 내려놓을 수 있게 된 것이다.

리뷰조차, 사람보다 에이전트끼리가 낫다

여기서 불편한 사실을 하나 인정해야 한다. 이제는 리뷰조차 에이전트가 나보다 낫다.

물론 에이전트도 실수한다. 하지만 그 실수는 교차 모델로 극복된다. 그리고 결정적으로 — 인간-에이전트 교차보다 에이전트-에이전트 교차가 낫다. 근거는 내 경험이다. 피곤하거나 집중이 흐트러진 내가 잘못된 코드를 놓치고 관성적으로 “어프루브”를 눌러 문제가 난 빈도가, Codex와 Claude가 서로를 교차 검수하다 문제가 난 빈도보다 높았다. 사람은 지치고, 모델은 매번 같은 강도로 본다.

이걸 도구로 굳힌 게 우리가 오픈소스로 공개한 redteam 하네스다 — 한 모델이 쓰고, 다른 모델이 적대적으로 친다. (이 글에서 말하는 ‘시스템’이 바로 이런 것이다.)

CTO는 코드를 보지 않는다 — 시스템을 본다

그러다 문득 이런 생각이 들었다. CTO나 팀장급이 굳이 코드를 하나하나 뜯어봐야 하나?

코드에 문제가 생기면, 높은 자리의 엔지니어는 그 코드를 직접 보지 않는다. 대신 문제가 생긴 원인을 파악해, 그런 문제가 다시 안 생길 시스템을 만든다. 이게 그냥 시니어급 엔지니어와 관리자급 엔지니어의 차이 아닐까. 그리고 그걸 조직 전체 차원으로 확장한 시야가 C레벨 아닐까.

CTO가 코드 하나하나의 에러를 보지 못하고, 그걸 직접 고칠 줄 모른다고 해서 그 사람이 실력이 없다고 말할 수는 없다. 그 포지션은 일하는 방식과 시야가 다를 뿐이다. 그래서 남들보다 연봉을 많이 받는 것이고. (덧붙이자면 — 나는 그 자리에 가본 적이 없어 추측만 할 뿐이다. 이건 바깥에서 본 그림이다.)

”그럼 통제력을 잃는 것 아닌가” — 반은 맞다

뻔한 반론이 있다. “코드를 안 보는 CTO는 결국 속아넘어가거나 통제력을 잃는다. 한 줄씩 안 보면 쓰레기가 나가도 모르잖아.”

이 말은 반은 맞고 반은 틀리다.

작은 회사, 시작하는 단계라면 — 맞다. 코드 양이 많지 않고 아직 틀을 잡는 중이니, CTO가 기술과 코드에서 어느 정도 직접 통제력을 갖는 게 옳다.
규모가 커지거나 대기업이라면 — 틀리다. 그 규모에서 CTO가 “코드를 본다”는 말은 거짓말이거나 착각이다. 만약 정말로 코드를 일일이 보고 있다면, 그건 그 CTO가 잘못 일하고 있는 것이다.

규모가 커지는 순간, 통제의 대상이 바뀐다. 코드가 아니라, 코드를 만드는 에이전트와 개발팀, 그리고 개발 문화가 통제 대상이 된다. 그리고 이게 핵심이다 — 쓰레기 코드가 나가는 건 CTO가 코드 리뷰를 안 했기 때문이 아니라, 잘못된 개발 시스템을 고치지 않았기 때문이다.

그래서 — 모든 개발자에게 필요한 자세

대부분의 개발자가 보이는 1차 반응은 “에이전트가 틀리는 걸 내가 잡아내야지”다. 자연스럽다. 하지만 더 높은 시야는 이걸 구조적으로 푼다 — 내가 매번 잡는 게 아니라, 틀려도 걸러지는 시스템을 만든다.

에이전트와의 업무량과 강도, 프로젝트 규모가 커지면서 나는 시각 자체를 바꾸게 됐다. 그리고 나는 이 자세가 지금 모든 개발자에게 필요하다고 생각한다.

에이전트를 가장 잘 부릴 수 있는 사람은, 실무자에서 임원급 관리자가 된 사람이다. 왜냐면 그들은 실전 감각이 살아있으면서, 굳이 코드 한 줄 수준을 보는 게 아니라 코드를 만드는 구조와 시스템을 보는 사람이니까.

가져갈 것

에이전트 시대의 자세는 실무자가 아니라 C레벨이다 — 코드를 잡는 사람이 아니라, 코드를 만드는 구조를 보는 사람.
단, 그 전제는 모델이 시니어급+에 올라온 것이다. 모델이 약하던 시절의 한 줄 리뷰는 옳았다. 자세를 바꾼 게 아니라 전제가 바뀐 것.
리뷰조차 에이전트-에이전트 교차가 낫다(내 관찰) — 사람은 지쳐 관성으로 어프루브하지만, 모델은 매번 같은 강도로 친다.
통제 대상이 코드에서 시스템으로 옮겨간다. 쓰레기가 나가는 건 리뷰를 안 해서가 아니라 잘못된 시스템을 안 고쳐서다. 당신의 가치는 하기/리뷰하기에서 그 일을 하는 시스템을 설계하기로 — 실무 감각을 버리는 게 아니라 재배치하는 것.

저작·인용: 이 글은 Ascendy Engineering이 작성했으며 출처 표기 시 재인용 가능합니다. 잘못된 정보를 발견하면 GitHub 이슈로 알려주세요.

Tags: ai-agent, engineering-management, ai-collaboration, developer-mindset, opinion