금융권 차세대 프로젝트를 하던 시절, 금요일 오후 5시에 배포 버튼을 누르는 건 자살 행위나 다름없었습니다.
하지만 고객사는 늘 "오늘 안 되면 주말에 나와서 하라"고 으름장을 놓죠.
그렇게 쫓기듯 배포한 코드는 반드시 새벽 3시에 제 핸드폰을 울리게 만듭니다.
로그를 까보면 원인은 늘 허무합니다.
user_id가 None으로 들어왔는데 체크를 안 했거나, DB 커넥션이 끊겼을 때 재시도 로직이 없거나.
"코드는 자산이 아니라 부채(Liability)입니다."
저는 이 말을 입에 달고 삽니다.
코드를 짠다는 건, 잠재적인 버그를 시스템에 심는 행위와 같습니다.
그래서 저는 후배들에게 지독할 정도로 방어적 코딩과 단위 테스트(Unit Test)를 강요합니다.
하지만 압니다. 테스트 코드 짜는 거, 지루하고 힘들다는 거.
비즈니스 로직 짜기도 바쁜데 Mock 객체 만들고 Dependency Injection 설정하다 보면 야근 확정이니까요.
그래서 주니어들이 대충 챗GPT한테 "테스트 짜줘"라고 시킵니다.
결과는 뻔합니다.
겉보기엔 그럴듯한데 실행해보면 ImportError 나고, 엣지 케이스(Edge Case)는 다 빼먹은 '가짜 테스트'가 나옵니다.
이건 RDD(이력서 주도 개발)를 위한 보여주기식 코드일 뿐, 운영 환경에서는 아무짝에도 쓸모가 없습니다.
그런데 최근 KeelTest라는 물건을 보고 조금 놀랐습니다.
단순히 LLM에게 프롬프트 날려서 코드 뱉어내는 수준이 아닙니다.
이 녀석은 정적 분석(Deep Static Analysis)을 먼저 수행합니다.
코드의 AST(추상 구문 트리)를 뜯어서 제어 흐름과 변수 경계를 파악합니다.
가장 소름 돋았던 건 '소스 코드의 버그'를 테스트 생성 중에 찾아낸다는 점입니다.
예를 들어봅시다.
send_notification 함수를 짰는데, user_id가 없을 때 로깅을 누락하는 실수를 했다고 칩시다.
보통의 AI는 그냥 그 버그가 있는 상태 그대로 테스트를 짜서 통과시켜 버립니다.
하지만 이 도구는 "여기 로직이 이상한데요? 실패하는 테스트를 만들었습니다"라고 역으로 찌릅니다.
이게 진짜 테스트죠.
테스트의 목적은 '통과'가 아니라 '발견'이니까요.
KeelTest는 스스로 짠 테스트를 샌드박스에서 돌려봅니다.
그리고 실패하면 Self-Healing(자가 치유) 기능을 통해 테스트 코드를 수정합니다.
만약 그래도 실패한다? 그건 여러분의 비즈니스 로직이 틀렸다는 뜻입니다.
실제로 벤치마크 결과를 보면 흥미롭습니다.
Staff Engineer 레벨을 10점으로 뒀을 때, Claude Sonnet 4.5가 5.5점, GPT-4가 2.5점인데 반해 이 녀석은 8.5점을 받았습니다.
이유는 단순합니다.
단순 텍스트 생성이 아니라, Agentic AI 방식으로 실제 실행(Execution) 검증을 거치기 때문입니다.
의존성 매핑(Smart Dependency Mapping)도 수준급입니다.
DB나 외부 API 호출을 기가 막히게 식별해서 자동으로 Mocking 처리합니다.
Ruff 같은 린터(Linter) 규격까지 맞춰주니, 팀장급 코드 리뷰어로서도 딱히 지적할 게 줄어듭니다.
물론, 도구를 맹신하면 안 됩니다.
하지만 인간이 놓치기 쉬운 Cyclomatic Complexity(순환 복잡도) 높은 구간을 기계가 검증해준다면?
그건 써야 합니다. 생존을 위해서요.
제발 "테스트 짤 시간 없다"는 핑계는 대지 마세요.
장애 터져서 경위서 쓸 시간은 있고, 테스트 짤 시간은 없다는 건 말이 안 됩니다.
운영 서버는 여러분의 코드를 테스트해주는 곳이 아닙니다.
VS Code 확장 프로그램 하나 깔아서 배포 전에 버그 2개만 잡아내도, 여러분의 주말은 지켜집니다.
무료 티어로 월 7크레딧 정도 준다니, 속는 셈 치고 가장 복잡한 함수 하나에 돌려보세요.
여러분의 코드가 얼마나 허술했는지 뼈저리게 느끼게 될 겁니다.
