커버리지는 코드 지표를 넘어 커리어 지표가 됐습니다

AI 요약

글쓴이는 테스트 1,558개가 모두 통과했는데도 인증 검사가 실행되지 않은 채 도구를 출시한 경험으로 이야기를 시작합니다. import가 조용히 실패해 테스트 결과는 초록색으로 남았지만, 인증되지 않은 요청이 데이터를 읽는 경로가 배포됐습니다. 실제 컨테이너에서 실행한 Docker 테스트가 문제를 잡았습니다. 이 경험은 테스트 수나 커버리지 숫자만으로 실제 동작을 보증할 수 없다는 점을 보여줍니다.

AI가 코드를 많이 쓰는 시대의 검증

글쓴이는 AI 에이전트가 타이핑을 상당 부분 맡으면서 코드가 빠르게 만들어지고, 겉보기에 그럴듯한 코드를 작성하는 일도 저렴해졌다고 말합니다. 자신이 만든 결과물에서 더 중요하게 여기는 부분은 코드 자체보다 주장이 실제 환경에서도 맞는지 보여주는 증거입니다. 테스트는 예전처럼 제품 출시를 돕는 위생 관리가 아니라, 결과를 확인하고 설명하는 작업으로 바뀌고 있습니다.

글쓴이가 다른 사람에게 프로젝트를 보여줄 때 내세우는 증거는 세 가지입니다. 첫째, 테스트 수와 실행 환경입니다. 에이전트 제어 평면(agent control plane)의 v0.1.0에는 테스트 925개가 포함됐고, 로컬 커버리지는 93%, CI 커버리지는 95.45%였습니다. 두 수치가 다른 사실도 감추지 않고 보고합니다. 둘째, 실제 데이터를 대상으로 한 필드 테스트(field test) 보고서입니다. 계획 도구 하나는 실제 목표 170개를 0.49달러에 테스트했습니다. 셋째, 버그와 실패 사례, 아직 지원하지 못하는 기능을 기록한 실패 목록입니다.

실패 기록을 공개하는 이유

처음에는 약점을 먼저 공개하기가 꺼려졌지만, 몇 차례 출시한 뒤 독자들이 실패 목록을 유심히 본다는 사실을 알게 됐습니다. 무엇이 안 되는지 공개하면 나머지 성능 주장도 광고가 아니라 검토 가능한 설명으로 보이기 때문입니다. 글쓴이는 필드 테스트, 테스트 결과, 보안 감사 보고서를 공개 저장소에 날짜와 함께 올렸습니다. 한 독자는 출시 전에 무엇을 기대하는지 적고, 공개된 자료와 실제 결과를 대조해 출시 설명과 증거가 어긋나는 지점을 기록했습니다. 엔진의 동작은 대체로 맞았지만, 글쓴이가 설명한 내용 일부는 틀렸습니다. 처음에는 당황했지만, 증거가 공개돼 있었기에 지금까지 받은 리뷰 가운데 가장 엄격한 검증을 받을 수 있었다고 돌아봅니다.

초록색 테스트 결과도 검증해야 합니다

두 모델이 풀 리퀘스트를 검토하는 엔진을 만들 때는 결과 숫자를 신뢰하기 전에 버그 13개를 고쳤습니다. 그중 하나는 조인(join) 과정에서 데이터 행이 2,333개에서 359개로 조용히 줄어드는 문제였습니다. 테스트 1,558개가 통과한 뒤 인증 검사가 실행되지 않은 사례도 같은 교훈을 줬습니다. 많은 테스트와 초록색 결과는 안전하다는 보증이 아니라, 어떤 코드와 데이터를 대상으로 실행했는지 확인하는 대화의 출발점입니다.

커버리지 수치를 성과로 내세우면 숫자를 늘리는 일이 목표가 될 수 있습니다. 글쓴이의 저장소에는 본문이 pass 한 줄뿐이라 실패할 수 없는 테스트가 들어 있었습니다. 또 테스트 하네스(harness)는 파일 65개 가운데 57개에서 실행할 단언(assertion)을 하나도 찾지 못했는데도 0/0을 성공으로 표시했습니다. 코드 리뷰가 두 문제를 잡았지만 지표는 놓쳤습니다. AI를 사용하면 테스트를 대량 생성해 숫자를 부풀리는 비용도 낮아집니다.

커리어를 보여주는 것은 증거 기록

글쓴이가 현재 제안하는 기준은 커버리지 자체가 아니라 증거의 흐름(evidence trail)입니다. 테스트 수는 눈에 띄는 첫 숫자일 뿐입니다. 실제 동작을 시험한 보고서, 좋지 않은 결과도 포함한 기록, 남은 실패 목록, 제삼자가 직접 확인할 수 있는 자료가 함께 있어야 주장을 믿을 수 있습니다. AI가 코드를 더 많이 작성할수록 엔지니어의 역량은 코드의 모양보다 결과를 검증하고 설명하는 능력으로 드러난다는 생각입니다.

다만 증거를 만드는 데는 비용이 듭니다. 필드 테스트에 기능 개발보다 더 오래 걸리는 경우도 있고, 일정과 범위를 직접 조절하는 오픈소스 작업 밖에서도 이런 방식을 적용할 수 있을지는 확신하지 못합니다. 채용 과정도 공개된 실패 보고서보다 현장에서 퍼즐을 푸는 능력을 더 많이 평가합니다. 팀 단위로 일할 때 증거 기록을 작성자, 리뷰어 중 누가 맡을지도 열린 질문으로 남깁니다. 글쓴이는 저장소의 별점, 테스트, 커밋 기록, README 가운데 무엇이 신뢰를 만드는지, AI가 대부분의 코드를 작성하게 될 때 엔지니어가 자신의 실력을 무엇으로 증명할지 묻습니다.

원문: dev.to / 번역·요약: Trawling