에이전트(Agents) 작업을 위한 최소 기능 테스트 스위트 (Minimum Viable Test Suite)

"테스트가 더 필요합니다"라는 조언은 "더 건강하게 먹어야 합니다"라는 조언이 옳은 방식과 거의 비슷하게 옳습니다. 기술적으로는 사실이지만, 무한히 미룰 수 있으며, 누군가가 이를 구체화하기 전까지는 실행 가능한 조언이 아닙니다.

에이전트(Agents)를 도입하는 팀들은 이와 약간 다른 형태로 동일한 조언을 듣는 경향이 있습니다: "에이전트가 실제 코드에서 작업하도록 허용하기 전에 테스트 커버리지(Test coverage)가 높아야 합니다." 이 또한 거의 같은 방식으로 옳습니다. 틀린 말은 아닙니다. 다만 질문의 핵심이 아닐 뿐입니다. 진짜 질문은 이것입니다: 최소한의 투자로 에이전트의 신뢰성을 극대화하기 위해, 어떤 테스트를, 어디에, 어떤 순서로 배치해야 하는가?

대부분의 팀은 자신들이 필요하다고 생각하는 수준의 커버리지를 전혀 갖추지 못하고 있습니다. 또한 대부분의 팀은 자신들이 필요하다고 생각하는 만큼의 커버리지를 필요로 하지도 않습니다. 중요한 접점(Seams)에 전략적으로 배치하는 커버리지라는 중간 지점은, 실제로 구축할 수 있을 만큼 작으면서도 실제로 도움이 될 만큼은 충분히 큽니다.

"더 많은 테스트"가 잘못된 프레임인 이유

테스트 커버리지(Test coverage)는 흐름(Flow)이 아니라 축적(Stock)입니다. 전체 백분율은 얼마나 많은 코드가 실행되는지를 알려줄 뿐, 그 테스트가 당신이 신경 쓰는 실패를 잡아낼 수 있는지에 대해서는 거의 아무것도 알려주지 않습니다. 약한 단언(Weak assertions, 예: "함수가 예외를 던지지 않고 반환됨")으로 구성된 90% 커버리지의 코드베이스는, 강력한 단언(Strong assertions, 예: "이러한 입력값이 주어졌을 때, 함수가 이러한 부수 효과(Side effects)와 함께 올바른 값을 반환함")으로 구성된 40% 커버리지의 코드베이스보다 덜 안전합니다.

에이전트(Agents)는 이러한 차이를 증폭시킵니다. 에이전트는 강력한 테스트를 통과하는 코드만큼이나 약한 테스트를 통과하는 코드도 쉽게 배포할 수 있습니다. 약한 테스트는 인간이 작성한 작업에 대해서도 잘못된 확신(False confidence)을 주고 있었습니다. 에이전트는 단지 그 작업을 더 빠르게 수행할 뿐이며, 따라서 잘못된 확신이 더 빠르게 복리로 쌓이게 됩니다.

효과적인 프레임은 "더 많은 테스트"가 아니라 "에이전트가 틀렸을 때 실패할 테스트"입니다. 커버리지는 그러한 테스트를 보유함으로써 발생하는 부수 효과입니다. 커버리지를 직접적으로 쫓는 것은 동작을 검증하지 않고 코드 라인만 실행하는 코드를 만들어낼 뿐입니다.

중요한 접점 (The seams that matter)

코드베이스의 어떤 부분은 다른 부분보다 테스트할 때 더 높은 레버리지(leverage)를 가집니다. 레버리지가 높은 접점(seams)은 세 가지 속성을 가집니다. 첫째, 시스템의 한 부분이 다른 부분과 만나는 _경계(boundaries)_이며, 둘째, 시스템의 나머지 부분이 의존하는 _비즈니스 규칙(business rules)_을 인코딩하고, 셋째, 검사(inspection)만으로는 감지하기 어려운 방식으로 실패한다는 점입니다.

API 계약(API contracts)이 전형적인 예시입니다. 서비스와 이를 호출하는 호출자(callers) 사이의 경계입니다. 만약 계약이 조용히 변경된다면(응답 형태가 바뀌거나, 필드가 선택 사항이 되거나, 에러 코드가 변경되는 경우), 모든 호출자가 미묘한 방식으로 망가질 수 있습니다. 에이전트(Agents)는 핸들러를 "정리"하는 과정에서 특히 이런 종류의 변경을 일으킬 가능성이 높습니다. 계약 테스트(Contract test)는 이를 PR(Pull Request) 단계에서 잡아냅니다. 테스트가 없다면, 다른 누군가의 장애 상황에서 이를 발견하게 될 것입니다.

데이터 계층 경계(Data layer boundaries)가 두 번째 부류입니다. 코드가 데이터베이스, 메시지 큐, 또는 외부 서비스와 만나는 접점입니다. 이 접점에서 에이전트가 유발하는 대부분의 버그는

그 이유는 두 가지입니다. 첫째, 내부 코드는 다음 계층의 코드가 잡아낼 수 있는 방식으로 실패하기 때문입니다. 잘못된 출력을 생성하는 포맷팅 헬퍼 (formatting helper)는 렌더링된 페이지를 잘못 보이게 만들며, 이는 시각적 테스트 (visual test)나 E2E 테스트 (e2e test), 또는 사용자가 잡아냅니다. 둘째, 내부 코드는 자주 변경되고 빈번하게 리팩터링 (refactored)되기 때문에, 이 계층의 테스트는 발견된 버그당 유지보수 부담이 더 높습니다. ROI (투자 대비 효율)는 분명히 존재하지만 더 낮습니다.

시사점은 다음과 같습니다. 모든 것을 테스트하려고 시도하며 시작하지 마십시오. 접점 (seams)을 테스트하는 것부터 시작하십시오. 에이전트가 계약 (contract)이 여전히 유효함을 증명하지 않고서는 경계면 (boundary)에서 변경 사항을 배포할 수 없는 상태를 만드십시오. 내부 코드는 패턴이 안정화되고, 테스트 작성 비용이 다음 주에 삭제될 함수가 아닌 오래 지속될 함수에 걸쳐 분할 상환될 수 있을 만큼 성숙했을 때 테스트할 수 있습니다.

이는 사람이 작성한 코드에 유효한 "진행하면서 테스트하라 (test as you go)"라는 조언을 의도적으로 뒤집은 것입니다. 에이전트의 경우 처리량 (throughput)이 충분히 높기 때문에, "진행하면서" 하는 방식은 살아남지 못할 코드에 대한 수많은 테스트를 양산하게 됩니다. 중요한 곳에는 테스트를 앞당겨 배치(front-load)하고, 중요하지 않은 곳에는 테스트를 뒤로 미루십시오 (back-load).

가장 먼저 작성해야 할 세 가지 테스트

만약 테스트가 거의 없는 코드베이스에서 시작하여 이번 주에 최소 기능 세트 (minimum viable set)를 추가하고 싶다면, 가장 먼저 작성해야 할 세 가지는 다음과 같습니다:

가장 많이 호출되는 API 엔드포인트 (API endpoint)에 대한 계약 테스트 (contract test). 해피 패스 (happy path)를 실행하는 요청을 보냅니다. 필드의 타입 (types)을 포함하여 전체 응답 형태 (response shape)를 단언 (assert)하십시오. 만약 에이전트가 응답 형태를 깨뜨리는 핸들러 (handler) 변경을 생성한다면, 이 테스트는 변경 사항이 병합되기 전에 실패할 것입니다.

가장 중요한 쓰기 경로 (write path)에 대한 통합 테스트 (integration test). 회원가입 흐름, 결제, 또는 잘못된 결과가 사용자나 감사인 (auditor)에게 노출될 수 있는 지점입니다. 충분히 실제와 유사한 환경을 대상으로 엔드투엔드 (end-to-end)로 실행하십시오. 단순히 응답뿐만 아니라 결과적인 상태 (resulting state)를 단언하십시오.

생각할 수 있는 가장 까다로운 비즈니스 규칙 (business rule)에 대한 단위 테스트 (unit test)를 작성하되, 최소 세 가지 케이스를 포함하십시오: 해피 케이스 (happy case), 과거에 한 번이라도 문제를 일으켰던 엣지 케이스 (edge case), 그리고 코드 리뷰 (code review) 중에 팀원들이 항상 논쟁하는 케이스입니다. 테스트의 이름을 테스트 대상 함수 (function under test)가 아닌 규칙 그 자체의 이름으로 짓는 것이 더 유용합니다.

세 개의 테스트. 반나절의 작업. 이것들이 코드 커버리지 (coverage)를 제공하지는 않겠지만, 커버리지가 나타내야 하는 보호 기능의 불균형적인 비중을 제공할 것입니다. 나머지 테스트 스위트 (suite)는 그 지점으로부터 바깥쪽으로 확장되며 구축됩니다.

주간 의식 (The weekly ritual)

연결 부위 (seams)를 모두 커버했다면, 실천 방법은 간단합니다: 에이전트 (agent)가 반드시 잡아냈어야 할 잘못된 결과물을 내놓을 때마다, 그것을 잡아낼 수 있었던 테스트를 작성하십시오. 수정 사항이 반영되기 전에 테스트를 추가하십시오. 수정 사항은 테스트가 옳았음을 증명하고, 테스트는 회귀 (regression)를 방지합니다.

이는 사후 분석 (post-mortem) 의식에서 실행되는 루프 (loop)와 동일하지만, 그 주기가 더 짧을 뿐입니다. 에이전트의 실수는 장애 (incident)보다 규모는 작고 빈도는 더 잦지만, 교훈은 동일합니다: 일회성 버그는 테스트로 인코딩 (encoded)될 때에만 영구적인 지식이 됩니다.

이 루프를 6개월 동안 실행하는 팀은 에이전트가 코드베이스 (codebase)에서 생성하는 실제 실패 모드 (failure modes)에 맞춰 형성된 테스트 스위트를 갖게 됩니다. 그 스위트는 사전에 구축된 그 어떤 양적인 커버리지보다 더 가치 있습니다. 그것은 작성되는 것이 아니라 성장하는 것입니다.

최소 기능 테스트 스위트 (minimum viable suite)는 시작점입니다. 그것을 성장시키는 것은 규율 (discipline)입니다.