바이브 코딩은 작동하는 것처럼 보이는 애플리케이션을 만들 수 있는 사람의 범위를 바꿔 놓았다. 프롬프트 하나로 화면을 생성하고, API를 연결하고, 그럴듯한 워크플로를 구성할 수 있어 기존 엔지니어링 팀이 첫 설계 검토를 마치기도 전에 결과물을 만들어 낸다.
이러한 속도는 새로운 채용 및 제공 문제를 만든다. 이제 데모는 소프트웨어가 우수하다는 강력한 증거가 아니다. 고용주는 점점 더 어려운 질문을 하게 될 것이다. 입력이 뒤섞이고, 종속성이 실패하고, 사용자가 작업을 반복하고, 기반 모델이 변경될 때 이 AI 구축 시스템이 올바르게 동작할 수 있는가?
그 답은 시각적 완성도보다는 엄격한 소프트웨어 검증에 가까운 품질 기준에서 나올 것이다. 두각을 나타내는 사람들은 AI 코딩 도구가 무엇을 만들어 냈는지만 보여 주지 않는다. 어떻게 테스트했는지, 무엇을 안전하게 수행할 수 없는지, 변경 사항이 다른 기능을 망가뜨리지 않았다는 것을 어떻게 확인했는지를 보여 줄 것이다.
벤치마크는 증거이지 리더보드 점수가 아니다
오픈 소스 코딩 에이전트 벤치마크는 유용한 출발점을 제공하지만, 서로 다른 능력을 측정한다. SWE-bench는 실제 GitHub 이슈와 저장소 스냅샷을 사용하므로 유지 보수 작업과 관련성이 높다. Terminal-Bench는 명령줄 상호 작용을 테스트한다. SlopCodeBench와 ProgramBench를 포함한 다른 나열된 벤치마크는 생성된 코드와 에이전트 동작의 서로 다른 측면을 대상으로 한다.
이러한 벤치마크는 도구를 비교하거나 기준선을 설정하는 데 도움이 될 수 있지만, 고용주는 단일 점수를 프로덕션 준비 상태의 증거로 간주하는 데 신중해야 한다. 저장소 이슈를 해결하는 모델도 안전하지 않은 권한 부여 로직을 생성할 수 있다. 터미널 작업을 완료하는 에이전트도 긴 워크플로 전체에서 상태를 유지하지 못할 수 있다. 완성도 높은 웹 애플리케이션도 정상 경로 데모는 통과하면서 재시도나 중복 결제를 잘못 처리할 수 있다.
따라서 신뢰할 수 있는 포트폴리오나 내부 검토에는 작업별 평가 세트가 포함되어야 한다. 이 세트에는 대표적인 버그 보고서, 일반적인 사용자 여정, 잘못된 형식의 입력, 권한 경계, 종속성 실패, 이전에 수정된 회귀 문제가 포함될 수 있다. 각 사례에는 단지 보기 좋은 스크린샷이 아니라 명시적인 예상 결과가 있어야 한다.
AI로 구축한 소프트웨어를 위한 최소 테스트 팩
소규모 애플리케이션이라면 정교한 연구실 없이도 유용한 품질 팩을 구성할 수 있다.
- 인수 테스트: 성공 및 실패 결과를 포함해 가장 중요한 워크플로에서 사용자가 볼 수 있는 동작을 검증한다.
- 단위 및 통합 테스트: 비즈니스 규칙을 격리된 상태에서 확인하고 데이터베이스, API, 큐, 인증이 의도한 대로 함께 작동하는지 검증한다.
- 부정 테스트: 누락되었거나 잘못된 형식이거나 지나치게 크거나 중복되었거나 권한이 없는 입력을 전송한다. AI 생성 코드는 프롬프트에 제시된 경로에서 가장 강해 보이는 경우가 많으므로, 요청되지 않은 경로가 중요하다.
- 회귀 테스트: 발견된 모든 결함을 영구적인 테스트로 전환한다. 수정 후 데모가 정상이라고 해서 충분하지 않다. 다음에 생성되는 변경 사항에서 같은 실패가 다시 나타날 수 있기 때문이다.
- 보안 점검: 접근 제어, 비밀 정보 처리, 인젝션 방어, 종속성 취약점, 신뢰할 수 없는 콘텐츠가 도구 호출이나 권한 있는 작업에 영향을 미칠 수 있는지를 테스트한다.
- 운영 점검: 타임아웃, 재시도, 멱등성, 로깅, 알림, 종속성을 사용할 수 없을 때의 안전한 동작을 검증한다.
이는 Stack Overflow가 에이전트형 소프트웨어 개발 수명 주기에 관한 설명에서 제시한 QA 엔지니어링 관점과 가깝다. 중요한 변화는 문화적이다. 품질 보증은 AI가 코드를 작성한 뒤 수행하는 최종 검사가 아니다. 품질 보증은 빠른 생성을 충분히 안전하게 사용할 수 있도록 만드는 구조다.
출력뿐 아니라 오케스트레이션을 테스트하라
소프트웨어에 AI 에이전트가 포함되면 일반적인 애플리케이션 테스트만으로는 충분하지 않지만 반드시 필요하다. 시스템은 모델이 요청을 잘못 이해해서 실패할 수도 있지만, 주변 오케스트레이션이 컨텍스트를 잃거나, 도구를 두 번 호출하거나, 잘못된 구조화 출력을 받아들이거나, 아예 종료되지 않아서 실패할 수도 있다.
다이제스트에서 권장한 배포 전 회귀 영역은 실용적인 체크리스트다. 컨텍스트 손실, 도구 멱등성, 프롬프트 인젝션, 구조화 출력, 비종료, 검색 결과 기반성, 상태 재수화가 그것이다. 이는 테스트 가능한 엔지니어링 속성이다.
예를 들어 동일한 요청을 두 번 실행하고 두 번째 시도가 중복 주문을 생성하지 않는지 확인하는 테스트를 만들 수 있다. 또 다른 테스트에서는 워크플로 중간에 에이전트를 중단하고 재시작한 뒤, 되돌릴 수 없는 작업을 반복하는 대신 유효한 상태에서 재개하는지 검증할 수 있다. 검색 테스트에서는 시스템이 승인된 출처 집합의 정보만 인용하거나 반환하도록 요구할 수 있다. 구조화 출력 테스트에서는 잘못된 응답을 제공하고 애플리케이션이 이를 유효한 데이터로 조용히 처리하는 대신 안전하게 거부하는지 확인할 수 있다.
장시간 실행되는 시스템과 다중 에이전트 시스템에는 특히 명확한 실패 기록이 필요하다. 긴 상호 작용 체인에서 어느 에이전트가 어느 시점에 실패를 일으켰는지 식별하기 어려울 수 있기 때문에, 연구자들은 자동화된 실패 원인 귀속을 연구하고 있다. 실무적으로 팀은 개인정보 보호를 고려한 감사 추적에 도구 호출, 입력, 출력, 모델 버전, 타임스탬프, 상태 전환, 최종 결정을 보존해야 한다. 이러한 증거가 없으면 빨간색 테스트는 무언가 실패했다는 사실만 알려 줄 뿐, 어디서부터 수정을 시작해야 하는지는 알려 주지 않는다.
재현성은 경력상의 강점이 될 것이다
AI 생성 코드는 가변적이다. 다시 실행하면 다른 구현이 나올 수 있고, 모델 업데이트로 동작이 바뀔 수 있으며, 제공업체 장애로 라우팅이나 지연 시간이 달라질 수 있다. 따라서 고용주는 평가를 반복 가능하게 만들 수 있는 지원자를 높이 평가할 것이다.
이는 가능한 경우 모델 스냅샷을 고정하고, 프롬프트와 구성을 기록하고, 플랫폼에서 허용할 때 무작위성을 제어하고, 결과가 달라지는 작업에 대해 여러 번의 시도를 실행한다는 뜻이다. 다이제스트는 고정된 스냅샷, 가능한 경우 낮거나 0인 temperature, 신뢰도 범위가 설정된 CI/CD 게이트를 유용한 보호 장치로 구체적으로 제시한다.
실용적인 보고서는 최소한 세 가지 결과를 구분해야 한다:
- 통과율: 성공한 사례가 얼마나 많은가.
- 일관성: 반복 실행에서 동일한 사례가 얼마나 자주 성공하는가.
- 심각도: 실패가 외관상의 문제인지, 불편을 초래하는지, 데이터를 손상시키는지, 보안과 관련되는지, 또는 안전하지 않은 외부 작업을 일으킬 수 있는지 여부.
위험도가 낮은 형식 검사 20개 중 19개를 통과한 시스템이, 20개 사례 중 18개를 통과했지만 인증 경계를 절대 넘지 않는 시스템보다 반드시 더 나은 것은 아니다. 품질 기준은 실패의 결과에 따라 그 가중치를 달리해야 한다.
사람의 검토는 모든 줄이 아니라 위험을 대상으로 해야 한다
더 나은 자동화의 목적은 사람이 AI가 생성한 모든 토큰을 다시 읽도록 강요하는 것이 아니다. 테스트만으로 완전히 판단할 수 없는 결정에 사람의 주의를 집중시키는 것이다.
검토자는 인증 및 권한 부여, 데이터 보존, 재정적 또는 계약상의 작업, 개인정보 보호, 마이그레이션, 오류 복구, 타사 권한, 그리고 시스템 자체의 평가 하니스에 영향을 미치는 변경 사항에 집중해야 한다. 에이전트의 경우에는 어떤 도구를 호출할 수 있는지, 각 도구가 어떤 데이터에 접근할 수 있는지, 되돌릴 수 없는 작업 전에 승인이 필요한지도 검토해야 한다.
가시적인 diff, 승인 워크플로, 보관된 대화, 감사 로그는 협업형 AI 코딩에 관한 Slack Code의 설명에서 강조된 기능으로, 더 넓은 기대를 가리킨다. 소프트웨어가 어떻게 만들어졌는지에 대한 이력이 중요해질 것이다. 검토자는 요청을 이해하고, 생성된 변경 사항을 검사하며, 테스트 근거를 확인하고, 누가 배포를 승인했는지 파악할 수 있어야 한다.
그 기록은 그 자체를 위한 관료주의가 아니다. 이는 인상적인 데모와 다른 사람이 유지 관리할 수 있는 통제된 변경을 구별할 수 있게 해 준다.
포트폴리오나 면접에 포함할 내용
지원자에게 가장 강력한 시연은 품질에 대한 설명이 의도적으로 잘 드러나는 작은 시스템이다. 저장소, 설정 방법, 아키텍처 메모, 테스트 명령, 대표 테스트 사례, 알려진 제한 사항, 짧은 실패 보고서를 포함하라. 발견한 버그 한두 개를 회귀 테스트로 전환한 사례를 보여 주라. 어떤 모델이나 코딩 에이전트를 사용했는지는 설명하되, 그 도구를 엔지니어링 결정의 작성자인 것처럼 제시하지는 말라.
애플리케이션이 에이전트를 사용한다면 도구 권한, 상태 모델, 재시도 정책, 종료 조건, 사람의 승인 지점을 문서화하라. 검색 증강을 사용한다면 출처를 어떻게 선택하는지, 근거가 없을 때 어떤 일이 일어나는지 보여 주라. 외부 서비스를 호출한다면 타임아웃과 중복 요청 동작을 시연하라.
한 번 성공적으로 녹화되었다는 사실만으로 신뢰성을 주장하지 말라. 검증 가능한 주장은 다음과 비슷하다. “이 12개 시나리오를 30회 녹화하여 실행한 결과, 시스템은 28회에서 승인 기준을 충족했다. 두 번의 실패는 모호한 날짜 입력과 관련되었으며, 두 사례 모두 문서화되어 있다.” 숫자 자체보다 방법, 경계, 그리고 아직 테스트되지 않은 부분에 대한 정직함이 더 중요하다.
빠름에 대한 새로운 정의
AI는 첫 번째 버전을 만드는 비용을 낮춘다. 그렇다고 그 버전이 신뢰할 만한지 아는 데 드는 비용까지 없애 주지는 않는다. 실제로 생성 속도가 빨라지면 배포 사이에 검토되지 않은 변경 사항이 더 많이 쌓일 수 있으므로 평가가 더 중요해질 수 있다.
바이브 코딩 이후의 전문가는 다음 순환 과정으로 평가받게 될 것이다. 동작을 정의하고, 코드를 생성하거나 수정하고, 현실적인 사례와 적대적 사례를 테스트하고, 위험도가 높은 결정을 검사하고, 실패를 기록하고, 근거를 잃지 않으면서 시스템을 개선하는 과정이다. 벤치마크는 역량을 비교하는 데 도움이 될 수 있다. QA 관행은 그 역량이 신뢰할 수 있는 소프트웨어가 되는지를 결정한다.
따라서 품질 기준은 “AI로 앱을 만들 수 있는가?”가 아니다. “앱이 무엇을 하는지 입증하고, 앱이 더 이상 그렇게 작동하지 않을 때 이를 감지하며, 실패가 사고로 이어지지 않도록 한계를 설계할 수 있는가?”이다.
