프롬프트 엔지니어링은 이미 레거시다
지난 2년간 개발자들이 공들인 스킬이 있다. 더 정교한 프롬프트를 쓰는 것. 역할을 정의하고, 출력 형식을 명시하고, "단계적으로 생각해"라는 마법의 문구를 넣었다. 프롬프트 라이브러리가 팔렸고, 프롬프트 강의가 생겼다. 하지만 솔직히 말하면, 아무리 정교한 프롬프트도 소프트웨어 개발이라는 워크플로우를 하나의 텍스트 인풋으로 압축할 수는 없다.
dev.to의 'Workflow Engineering Is Version 2'가 정확히 이 지점을 짚는다. 프롬프트 엔지니어링의 구조는 Prompt → AI → Response다. AI가 뭔가를 뱉으면 프로세스가 멈춘다. 테스트가 실패하면? 다시 프롬프트. 배포가 깨지면? 또 프롬프트. 결국 사람이 워크플로우 엔진이 된다.
시스템으로 생각한다는 것
워크플로우 엔지니어링의 구조는 다르다. Goal → Plan → Execute → Test → Evaluate → Improve → Repeat. AI가 단순히 답을 생성하는 게 아니라 프로세스를 통과한다. API 하나를 만든다고 치면, 워크플로우는 요구사항 분석부터 아키텍처 설계, 코드 생성, 유닛 테스트 실행, 실패 분석, 코드 수정, 보안 스캔, 문서화, 배포 설정까지 정해진 조건에 도달할 때까지 루프를 돈다.
이 관점에서 보면, DevOps 엔지니어들은 이미 워크플로우 엔지니어링을 하고 있었다. CI/CD 파이프라인이 정확히 이 구조다. 코드가 푸시되면 빌드, 테스트, 보안 스캔, 패키징, 배포, 모니터링이 순서대로 흐른다. 스테이지 하나가 실패하면 파이프라인이 멈춘다. 여기에 AI 에이전트를 얹는 건 원리의 확장이지 패러다임의 교체가 아니다.
팀 리드가 실제로 설계해야 할 것
그렇다면 팀 리드의 역할은 무엇인가. 더 좋은 프롬프트를 팀원에게 가르치는 게 아니다. AI가 움직이는 루프 자체를 설계하는 것이다.
루프 설계에는 세 가지 요소가 핵심이다.
첫째, 피드백 루프. 좋은 워크플로우는 첫 번째 아웃풋이 정답이라고 가정하지 않는다. 코드를 생성하고, 테스트를 돌리고, 실패를 읽고, 원인을 분석하고, 코드를 수정하고, 다시 테스트한다. 실패가 다음 스텝의 인풋이 되는 구조다. 이게 빠진 AI 워크플로우는 그냥 비싼 자동완성이다.
둘째, 도구 바인딩. LLM 단독으로는 텍스트만 생성한다. 터미널, Git, API, 모니터링 시스템, 테스트 프레임워크를 연결해야 AI가 실제로 행동하는 주체가 된다. 쿠버네티스 에이전트가 파드를 inspect하고, 로그를 읽고, 디플로이먼트 변경사항을 비교해 근본 원인을 제시하는 시나리오가 가능해지는 건 이 도구 바인딩 덕분이다.
셋째, 컨테이너 격리. 에이전트가 개발자 로컬 머신을 자유롭게 수정하도록 두면 안 된다. 에이전트가 코드를 생성하면 격리된 컨테이너 환경에서 의존성 설치, 테스트 실행, 애플리케이션 구동 후 환경을 폐기하는 사이클이 워크플로우의 실행 경계가 되어야 한다.
더 많이 만드는 것이 더 잘 만드는 것이 아니다
여기서 두 번째 문제가 등장한다. AI 워크플로우가 강력해질수록, 팀은 더 많이 만들 수 있게 된다. 그리고 이게 함정이다.
jakub.kr의 '덜한 것이 더 낫다'는 이 지점을 정면으로 겨냥한다. AI는 무언가를 추가하기를 그 어느 때보다 쉽게 만들었다. 에이전트를 멈추지 않고 돌리면 수백만 줄의 코드를 만들 수 있다. 하지만 그 결과가 좋을 것이라는 보장은 없다.
맥OS 우클릭 컨텍스트 메뉴 사례가 인상적이다. 입장 애니메이션, 퇴장 애니메이션, hover 배경색 전환 애니메이션까지 모두 넣으면 시각적으로는 풍부해 보인다. 하지만 이 메뉴를 하루 200번 연다고 계산하면, 애니메이션 길이 300ms 기준으로 하루 약 1분, 연간 6시간 이상을 기다리는 데 쓰게 된다. AI는 이 애니메이션을 구현할 수 있다. 하지만 구현하지 말아야 한다는 판단은 AI가 내려주지 않는다.
팀 리드의 설계 판단력: 제거의 기술
이 두 관점이 만나는 지점이 바로 팀 리드가 실제로 행사해야 할 역량이다. 워크플로우를 설계하는 것과, 그 워크플로우가 무엇을 만들어야 하고 무엇을 만들지 말아야 하는지를 판단하는 것.
실용적으로 번역하면 이렇다. 팀이 /codebase-standards 같은 스킬을 만들어두고 에이전트 리뷰 명령과 함께 쓰는 방식—이해와 판단 기준을 팀원과 에이전트 모두가 참조할 수 있는 형태로 인코딩하는 것—이 워크플로우 엔지니어링의 구체적 실천이다. 단순히 에이전트에게 리뷰를 맡기는 게 아니라, 팀이 정의한 기준을 에이전트의 판단 기준으로 주입하는 것이다.
코드 리뷰 관점도 바뀐다. 누구나 코드를 대량으로 만들 수 있는 시대에, 코드의 양은 더 이상 엔지니어의 성과 지표가 아니다. 가장 적은 코드로 목적을 달성하는 PR이 더 높은 평가를 받아야 한다. AI가 추가한 각 줄이 실제로 결과를 더 낫게 만드는지 비판적으로 따질 수 있는 능력이 코드 작성 능력보다 더 희소하고 더 가치 있는 역량이 된다.
전망: 설계자로서의 팀 리드
프롬프트 엔지니어링 시대에 팀 리드는 좋은 프롬프트 작성법을 팀에 전파했다. 워크플로우 엔지니어링 시대에 팀 리드는 루프를 설계하고, 도구 바인딩을 결정하고, 피드백 경계를 정의하고, 무엇을 만들지 않을지를 팀 전체의 기준으로 만드는 사람이어야 한다.
AI 도구가 강력해질수록 역설적으로 이해, 판단, 취향(taste)의 가치가 커진다. 실행은 에이전트가 맡아도, 무엇을 실행할지, 어디서 멈출지, 어떤 루프를 설계할지는 여전히 팀 리드의 몫이다. 워크플로우 엔지니어링은 기술 트렌드의 이름이 아니라, AI-First 팀에서 팀 리드가 존재해야 하는 이유의 재정의다.