Lucas F. Costa의 **“Backpressure is all you need”(2026-05-23)**는 코딩 에이전트를 더 오래, 더 안전하게 위임하기 위한 운영 원칙을 설명합니다. 글의 핵심은 단순합니다. LLM이 코드를 빠르게 생산하는 시대에는 사람이 기본 백프레셔가 되면 안 됩니다. 사람이 매번 출력물을 읽고, 실패를 찾아주고, 다시 프롬프트에 복사해 넣는 구조는 위임이 아니라 병목입니다.

원문: Backpressure is all you need

1) 두 가지 obvious한 사용법은 모두 나쁘다

Costa는 코딩 에이전트 사용법의 양극단을 비판합니다.

첫째, LLM을 방치하고 저장소가 살아남기를 바라는 방식입니다. 빠르고 신나지만, 버그·혼란스러운 변경·검토 불가능한 PR 홍수를 만듭니다. 결국 팀은 리뷰 기준을 낮추거나, 이해하지 못한 코드를 병합하게 됩니다.

둘째, 에이전트를 고급 자동완성처럼 취급하는 방식입니다. 매 단계 사람이 보고, 냄새나는 부분을 고치라고 말하고, 다시 확인합니다. 안전해 보이지만 너무 느립니다. 사람이 사소한 결정까지 계속 조종해야 한다면 실제로는 별로 위임하지 않은 것입니다.

Costa가 제안하는 제3의 길은 에이전트가 인간에게 오기 전에 더 많은 작업을 스스로 검증하게 만드는 것입니다. 목표는 인간을 루프에서 제거하는 것이 아니라, 인간이 저수준 오류 교정자가 아니라 마지막 판단자와 설계 리뷰어로 남게 하는 것입니다.

2) 백프레셔란 무엇인가

시스템 엔지니어링에서 백프레셔는 downstream 컴포넌트가 upstream 생산자에게 “지금은 더 받을 수 없다"고 신호를 보내는 메커니즘입니다. 이 신호가 없으면 생산자는 마음껏 일을 밀어 넣고, 소비자는 밀린 일을 떠안습니다. 결과는 셋 중 하나입니다.

  1. 소비자가 뒤처진다.
  2. 부하를 견디지 못하고 깨진다.
  3. 속도를 맞추려고 기준을 낮춘다.

소프트웨어 개발에서는 이미 여러 형태의 백프레셔를 사용해왔습니다.

백프레셔막아주는 것인간 리뷰 전 효과
자동 테스트깨진 동작, 회귀실패한 PR을 리뷰하지 않게 한다
타입 시스템잘못된 경계 계약, 불가능한 상태리뷰어가 diff에서 타입 불일치를 추적하지 않게 한다
린터/포매터스타일·기본 품질 이슈사소한 코멘트를 자동화한다
CI 파이프라인통합 실패, 누락된 검증준비 안 된 변경을 리뷰 큐 밖에 둔다
카나리/배포 가드레일프로덕션 회귀전체 사용자에게 퍼지기 전에 멈춘다

TypeScript의 예가 특히 직관적입니다. 컴포넌트가 함수를 기대하는데 문자열이나 객체를 넘기면, 예전에는 리뷰어가 prop 흐름을 따라가며 발견해야 했습니다. 타입 시스템은 그 책임을 기계로 옮겼습니다. 소비자의 기대를 생산자가 더 빨리 마주하게 만든 것입니다.

Costa의 문제의식은 여기서 출발합니다. 사람에게 적용해온 이 원리를, 왜 LLM이 코드를 작성하는 루프에는 충분히 넣지 않느냐는 것입니다.

3) 사람이 LLM의 기본 백프레셔가 되면 생기는 문제

현재 많은 팀의 에이전트 루프는 이렇게 생겼습니다.

  1. 사람이 프롬프트를 쓴다.
  2. 에이전트가 코드를 바꾼다.
  3. 사람이 에디터에서 결과를 읽는다.
  4. 사람이 이상한 부분을 다시 설명한다.
  5. 에이전트가 고친다.
  6. PR을 열고 CI 실패나 리뷰 코멘트를 다시 사람이 전달한다.

심지어 리뷰 봇을 붙여도, 봇의 피드백을 사람이 복사해서 코딩 에이전트에 전달한다면 인간은 두 기계 사이의 비싼 클립보드가 됩니다. 위임이 아니라 기계 간 피드백 라우팅을 사람이 수동으로 해주는 상태입니다.

따라서 다음 단계는 명확합니다.

  • 테스트가 빨리 실패해야 합니다.
  • 타입이 경계에서 밀어내야 합니다.
  • 벤치마크가 성능 회귀를 잡아야 합니다.
  • 리뷰 에이전트가 나쁜 패치를 인간 리뷰 전에 돌려보내야 합니다.
  • PR 상태 변화와 코멘트가 모델에게 직접 돌아가야 합니다.

이 장치들이 있어야 긴 unattended session이 쓸모 있을 만큼 안전해집니다.

4) 첫 단계: 반복마다 린트·테스트·검증 스크립트 실행

Costa가 처음 추가한 장치는 가장 단순한 것들입니다.

  • 린트
  • 테스트
  • 간단한 검증 스크립트
  • 커밋 메시지 체크 같은 프로젝트별 스크립트

중요한 점은 마지막에 한 번 실행하라고 말하는 것이 아니라 각 반복마다 실행하게 하는 것입니다. 에이전트는 코드를 조금 쓴 뒤 바로 체크를 돌리고, 실패하면 새 패치를 쓰기 전에 실패 원인을 분석하고 고쳐야 합니다.

실무 프롬프트 구조는 다음처럼 바꿀 수 있습니다.

이 작업은 기능 요구사항을 만족하는 것만으로 완료되지 않는다.
각 패치 이후 다음 품질 기준을 실행하라.

1. lint 통과
2. test 통과
3. 새 동작을 커버하는 테스트 존재
4. 프로젝트 검증 스크립트 통과

체크가 실패하면 다음 패치로 넘어가지 말고 실패 원인을 분석하고 수정한 뒤 다시 실행하라.
완료 선언은 모든 수용 기준과 품질 기준이 충족된 뒤에만 가능하다.

이 정도만 해도 사람은 “테스트가 깨졌네요” 같은 코멘트를 훨씬 덜 하게 됩니다.

5) 자동 테스트만으로 부족한 곳: cURL과 실제 브라우저

자동 테스트는 강력하지만 모든 문제를 잡지는 못합니다. API가 실제로 뜨는지, 브라우저에서 버튼이 예상대로 동작하는지, 로컬 의존성이 제대로 연결되는지는 별도 확인이 필요합니다.

Costa는 이 간극을 메우기 위해 에이전트에게 다음을 가르쳤습니다.

  • 프론트엔드와 백엔드를 로컬에서 실행하는 법
  • docker-compose로 의존성을 띄우는 법
  • 데이터베이스 스키마를 준비하는 법
  • cURL로 API를 때리는 법
  • Playwright MCP로 실제 브라우저를 조작하는 법
  • 로컬 실행 중 흔한 장애를 해결하는 법

다만 수동 검증은 자동 테스트보다 느리므로, 매 반복마다 돌리기보다는 구현 반복이 어느 정도 안정된 뒤 post-iteration 단계에서 최소 한 번 실행하는 식이 좋습니다.

6) 성능 민감 시스템에는 벤치마크 백프레셔가 필요하다

성능 민감한 애플리케이션에서는 테스트 통과만으로 충분하지 않습니다. 변경이 기능적으로 맞아도 latency, throughput, memory usage를 망칠 수 있기 때문입니다.

Costa가 강조하는 벤치마크 설계 조건은 실용적입니다.

  1. 한 명령으로 실행 가능해야 한다. 그래야 에이전트가 실행법을 찾다 길을 잃지 않는다.
  2. 시간 예산별 suite가 있어야 한다. 빠른 sanity check와 긴 full benchmark를 구분해야 한다.
  3. 구조화된 결과를 콘솔과 파일에 남겨야 한다. 모델이 개선·회귀·무의미한 차이를 판단할 수 있어야 한다.
  4. 판정 기준이 명확해야 한다. 어느 정도면 regression인지, noise인지, improvement인지 써 있어야 한다.

즉 벤치마크 자체도 “모델이 읽고 행동할 수 있는 인터페이스"로 만들어야 합니다.

7) 가장 효과적이었던 장치: 리뷰 에이전트

Costa가 가장 효과적이었다고 평가한 백프레셔는 리뷰 에이전트입니다. 앞선 체크들이 기능적 correctness를 많이 잡아준다면, 리뷰 에이전트는 더 주관적인 품질 문제를 잡습니다.

대표적인 품질 문제는 다음과 같습니다.

  • 읽기 어려운 코드
  • 과도한 복잡성
  • 테스트 부족
  • 느슨한 타입
  • 불필요한 cast
  • 우회적 구현
  • 변경 범위 과다

핵심은 리뷰 에이전트를 PR 끝에 한 번만 부르는 것이 아니라, 구현 반복 안에 넣는 것입니다. 그러면 코딩 에이전트는 인간 리뷰어의 취향과 품질 기준을 더 자주 마주하게 되고, 사람에게 오기 전에 스스로 품질 문제를 줄입니다.

Costa는 향후 이 리뷰 에이전트를 더 잘게 쪼개는 실험도 언급합니다.

리뷰 관점독립 에이전트로 분리했을 때의 장점
Readability이름, 흐름, 이해 가능성에 집중
Complexity과설계·중첩·불필요한 추상화 탐지
Tests누락된 케이스와 약한 assertion 탐지
Typesany, cast, 느슨한 boundary 탐지
Brevity불필요하게 긴 구현과 산만한 변경 축소

8) 구현 전에 계획도 리뷰해야 한다

구현 단계의 백프레셔만으로는 부족한 경우가 있습니다. 에이전트가 처음부터 잘못된 접근을 선택하면, 이후 반복에서 아무리 테스트와 리뷰를 돌려도 나쁜 기반 위에서만 개선하게 됩니다.

그래서 Costa는 planning phase review를 추가합니다.

  1. 코드를 쓰기 전에 가벼운 계획을 만든다.
  2. 계획은 구현 디테일보다 접근법과 아키텍처에 집중한다.
  3. 리뷰 에이전트가 근본 방향이 타당한지 검토한다.
  4. 리뷰어가 승인할 때까지 계획을 수정한다.
  5. 승인된 뒤에야 코드를 작성한다.

이 단계의 목적은 완벽한 설계 문서를 만드는 것이 아닙니다. 틀린 방향으로 빠르게 달리는 일을 막는 최소한의 방향성 검증입니다.

9) 프론트엔드 작업에는 시각적 리뷰도 실험할 만하다

Costa는 시각적 디자인 리뷰의 효과에 대해서는 조심스럽지만, 프론트엔드 작업에서는 실험 가치가 있다고 봅니다.

자동 테스트나 브라우저 클릭 검증으로도 다음 문제는 놓치기 쉽습니다.

  • 레이아웃 깨짐
  • spacing 불일치
  • 색상 대비 문제
  • 컴포넌트 정렬 오류
  • 디자인 시안과의 미묘한 차이

이를 위해 에이전트가 Playwright MCP로 스크린샷을 찍고, Figma 파일이나 Linear 티켓의 이미지와 비교하게 할 수 있습니다. 중요한 점은 “그냥 보고 판단하라"가 아니라, header → main → footer처럼 영역을 나누고, 정렬·간격·대비·일관성 같은 체크리스트를 주는 것입니다.

10) PR 모니터링: 두 번째로 효과적인 백프레셔

PR을 열었다고 작업이 끝난 것은 아닙니다. 실제 팀에서는 이후에 다음 이벤트가 발생합니다.

  • CI 실패
  • merge conflict
  • 리뷰어 코멘트
  • 다른 리뷰 봇의 지적
  • flaky test 재실패

Costa는 PR을 일정 시간 모니터링하는 skill을 만들었습니다. 이 skill은 새 코멘트, CI 상태 변화, 충돌을 감지하면 모델에게 알려서 해결하게 합니다. 이렇게 하면 PR이 열린 뒤에도 사람에게 조용히 책임이 넘어가지 않습니다.

최종 루프는 다음처럼 확장됩니다.

목표 입력
  ↓
가벼운 계획 작성
  ↓
계획 리뷰 및 승인
  ↓
구현 반복
  - 기능 기준 확인
  - lint/test/type/check 실행
  - 빠른 benchmark
  - 리뷰 에이전트 피드백
  ↓
post-iteration 검증
  - 로컬 앱 실행
  - cURL/API 검증
  - 실제 브라우저 검증
  - full benchmark
  - 전체 changeset 리뷰
  ↓
PR 생성
  ↓
PR 모니터링
  - CI
  - conflict
  - review comment

이 구조에서 인간은 각 반복의 저수준 교정자가 아니라, 마지막에 변경의 의미·설계·트레이드오프를 판단하는 사람이 됩니다.

11) 직접 적용하기 위한 최소 체크리스트

팀에 바로 적용한다면 처음부터 완성형 루프를 만들 필요는 없습니다. 다음 순서로 쌓는 편이 현실적입니다.

1단계 — 기본 품질 백프레셔

  • lint 명령을 문서화한다.
  • test 명령을 문서화한다.
  • 타입 체크 명령을 문서화한다.
  • 에이전트에게 “각 패치 후 실행"을 명시한다.
  • 실패 시 다음 변경 전 수정하도록 강제한다.

2단계 — 프로젝트 실행법을 에이전트용으로 정리

  • 로컬 의존성 실행법
  • 백엔드 실행법
  • 프론트엔드 실행법
  • DB 초기화 방법
  • 흔한 오류와 해결책
  • API smoke test용 cURL 예시

이 문서는 사람이 읽기 위한 README라기보다 에이전트가 막히지 않고 실행할 수 있는 runbook이어야 합니다.

3단계 — 리뷰 에이전트 추가

리뷰 기준을 명시합니다.

  • 변경 범위가 과하지 않은가?
  • 테스트가 새 동작을 실제로 검증하는가?
  • 타입을 느슨하게 만들지 않았는가?
  • 불필요한 추상화가 생기지 않았는가?
  • 사람이 이해할 수 있는 코드인가?

4단계 — PR 이후까지 닫힌 루프 만들기

  • PR을 열고 끝내지 않는다.
  • CI 상태를 확인한다.
  • 리뷰 코멘트를 회수한다.
  • merge conflict를 감지한다.
  • 남은 문제가 없을 때까지 모델이 다시 수정하게 한다.

12) 이 글의 진짜 메시지

이 글은 “좋은 프롬프트를 쓰자"는 글이 아닙니다. 더 정확히는 위임 가능한 시스템을 만들자는 글입니다.

프롬프트만으로는 에이전트가 너무 일찍 성공을 선언하기 쉽습니다. 반대로 사람이 모든 실패를 잡아주면 에이전트 생산성은 사람의 검토 속도에 묶입니다. Costa의 표현을 빌리면, 인간이 기계의 실수를 잡는 데 의존하는 시스템은 결국 기계가 아니라 인간에 의해 제한됩니다.

따라서 좋은 코딩 에이전트 환경의 질문은 다음으로 바뀝니다.

  • “모델이 코드를 잘 쓰는가?“에서
  • “모델이 실패를 얼마나 빨리, 자동으로, 반복적으로 마주하는가?“로.

앞으로 소프트웨어 엔지니어링의 많은 품질 관리는 사람이 더 열심히 리뷰하는 방향이 아니라, 사람에게 오기 전에 기계가 더 많이 거절하고 되돌려 보내는 방향으로 갈 가능성이 큽니다. 우리는 지난 수십 년 동안 컴파일러, 타입, 테스트, CI로 “no"를 사람에게서 기계로 옮겨왔습니다. 이제 같은 일을, 코드를 쓰는 기계 자신에게 다시 적용해야 합니다.