프로모션 대화의 문법이 바뀌었다
요즘 Staff+ 프로모션 검토 자리에서 오가는 질문이 달라졌다. "얼마나 많은 티켓을 닫았나요?"가 아니라 "에이전트를 돌렸을 때 시스템이 더 깔끔해졌나요, 아니면 더 시끄러워졌나요?"가 핵심 질문이 됐다. dev.to에 올라온 한 시니어 엔지니어의 글은 이 변화를 날카롭게 짚는다. AI 에이전트를 잘 쓰는 것과 AI 에이전트를 잘 다스리는 것은 전혀 다른 역량이고, 후자가 Staff+ 기준의 새로운 축이 되고 있다는 것이다.
'에이전트 플루언시'는 프롬프트 실력이 아니다
흔히 오해하는 부분이 있다. 에이전트 플루언시를 프롬프트 엔지니어링 능력으로 등치시키는 것이다. 실제로는 세 가지 역량의 조합이다.
첫째, 컨텍스트 엔지니어링. 에이전트에게 코드베이스 전체를 던지는 사람과, 해당 태스크에 필요한 레포 슬라이스·런북·이전 결정 기록만 정밀하게 주입하는 사람의 산출물 품질은 하늘과 땅 차이다. 제네릭한 출력이 나온다면 대부분 컨텍스트가 제네릭하기 때문이다.
둘째, 검증 루프 설계. 에이전트 PR이 사람 눈에 닿기 전에 정책 체크, 컨트랙트 테스트, 비용 추정, 보안 스캔이 자동으로 돌아야 한다. 이 게이트를 설계하지 않으면 리뷰어는 에이전트가 만든 노이즈를 매일 걸러내는 사람으로 전락한다.
셋째, 부채 감지. 에이전트는 즉각적인 태스크에 최적화된다. "6개월 후 다음 사람이 뭘 되돌려야 하는가"는 에이전트가 스스로 묻지 않는 질문이다. 그 질문을 매번 던지는 것이 스태프 엔지니어의 몫이다.
에이전트 하네스도 같은 함정에 빠진다
흥미롭게도 이 '검증 루프' 문제는 에이전트 시스템 설계 차원에서도 동일한 함정으로 나타난다. dev.to에 공개된 AI 에이전트 하네스 감사 프로토콜 아티클은 Tsinghua 논문을 인용하며 충격적인 수치를 제시한다. 동일 모델 기반의 검증기(verifier)를 코딩 에이전트 위에 얹으면 태스크 성공률이 오히려 8.4%p 하락하고, 멀티 캔디데이트 샘플링은 5.6%p 하락한다는 것이다.
이유는 구조적이다. 검증기와 제안자가 같은 모델이면, 도어(doer)가 자신 있게 틀렸을 때 검증기도 같은 확신으로 틀린 출력을 승인한다. 같은 훈련 분포, 같은 블라인드 스팟을 공유하기 때문이다. 체크가 에러를 잡는 게 아니라 에러를 승인하는 것이다. 이는 팀 내 검증 루프 설계에도 그대로 적용된다. 에이전트를 믿는 사람이 에이전트 산출물을 검토하면 같은 맹점이 반복된다. 외부 시그널—다른 모델, 다른 사람, 자동화된 정책 체크—이 반드시 개입해야 한다.
VS Code 1.119가 보내는 신호
도구도 이 방향으로 빠르게 정렬되고 있다. 마이크로소프트가 배포한 VS Code 1.119는 AI 에이전트의 브라우저 직접 제어, OpenTelemetry 기반 세션 추적, 할 일 목록 관리를 경량 백그라운드 에이전트에 위임하는 토큰 최적화 구조를 담았다. 여기서 주목할 것은 브라우저 탭 공유 기능의 설계 방식이다. 에이전트가 탭 공유를 요청하고 사람이 승인하거나 거부한다. 자동화를 높이면서도 제어권을 사람에게 유지시키는 구조다. 에이전트 플루언시를 지원하는 인프라가 IDE 레벨에서 구체화되고 있다는 신호다.
팀 리빌딩에 주는 실질적 함의
이 흐름은 채용 기준을 어떻게 바꾸는가. 몇 가지를 직접적으로 짚겠다.
인터뷰 설계를 바꿔야 한다. 시스템 디자인 화이트보드만으로는 에이전트 플루언시를 측정할 수 없다. "에이전트에게 이 태스크를 넘기기 위해 어떤 컨텍스트를 어떻게 구조화하겠는가", "에이전트 산출물이 틀렸다는 것을 어떻게 빠르게 감지하겠는가"가 새로운 인터뷰 질문이 되어야 한다.
온보딩 설계가 달라져야 한다. 신규 입사자에게 코드베이스 파악을 먼저 시키는 것은 여전히 맞다. 하지만 그 다음 단계로, 해당 코드베이스에서 에이전트를 어떻게 좁게 쓰는지, 어디에 가드레일이 필요한지를 함께 설계하도록 만드는 과정이 필요하다.
역할 정의도 다시 써야 한다. 시니어와 스태프의 차이가 "코드를 더 많이 짜는가"에서 "에이전트가 만든 변경이 조직을 더 빠르고 조용하게 만드는가를 책임지는가"로 이동하고 있다. 이 차이를 JD에 명시하지 않으면 엉뚱한 역량을 가진 사람을 뽑게 된다.
낙관하되, 냉정하게
이 변화가 모든 팀에게 즉시 적용 가능한 이야기는 아니다. 에이전트를 제대로 다스리려면 코드베이스의 히스토리와 아키텍처 결정의 맥락을 깊이 이해하는 사람이 전제다. 에이전트 플루언시는 도메인 지식과 시스템 감각을 대체하지 않는다. 그 위에 쌓이는 메타 역량이다.
그러나 방향은 분명하다. 에이전트를 마법으로 대하는 사람은 시니어에서 멈추고, 에이전트를 예측 불가능하지만 강력한 인턴으로 다루는 사람이 Staff+를 정의하게 될 것이다. 팀 리빌딩을 준비하고 있다면, 지금 채용 기준과 온보딩 설계에 이 질문을 먼저 집어넣어야 한다. 그 설계를 미루는 비용이 생각보다 빠르게 쌓이고 있다.