자동화와 도메인 지식의 인프라화
TMT요즘 계속 생각해 온 것이 하나 있습니다. 예전에 제가 알던 최고의 엔지니어들은 다양한 방식으로 자기 일을 자동화하는 데 많은 시간을 쏟았습니다. vim/emacs 자동화를 다듬고, 반복되는 코드 문제를 잡아내는 린트 규칙을 작성하고, 앱을 손으로 스모크 테스트하지 않아도 되도록 e2e 테스트 스위트를 쌓아 올리는 식이었죠. 이런 일이야말로 엔지니어가 할 수 있는 가장 레버리지 높은 활동이었습니다. 자신의 산출량을 몇 배로 불려 주었고, 그만큼 더 많은 것을 만들 수 있었기 때문입니다.
저는 이런 자동화 상당수가 지금 오히려 더 중요해졌다고 생각합니다. 이유는 여러 가지입니다.
첫째, 인프라와 개발자 경험(DevX) 자동화는 작업 속도를 높여 줍니다. 그리고 에이전트 군단을 운용하고 있다면, 그 에이전트 하나하나도 함께 빨라집니다. 자동화가 많아질수록 단위 시간당 산출량이 늘어납니다.
둘째, 일을 코드로 옮기면 효율이 좋아집니다. 에이전트가 어떤 문제를 발견할 때마다 고쳐 줄 수도 있지만, 그렇게 하면 매번 토큰을 쓰고 놓치는 경우도 생깁니다. 대신 Claude가 린트 규칙이나 CI 단계, 루틴을 작성해 두면 그 유형의 문제 전체를 영원히 자동화할 수 있습니다. 사람들이 루프(loop)를 이야기할 때 실제로 말하는 것이 바로 이것입니다. 잡무를 하나씩 처리하는 게 아니라 잡무의 유형 전체를 자동화하는 것이죠. 전혀 새로운 아이디어가 아닙니다. 엔지니어들은 오래전부터 이렇게 해 왔으니까요!
셋째, 그리고 가장 중요한 이유로, 자동화는 다른 사람들이 코드베이스에 더 쉽게 기여할 수 있게 해 줍니다. 요즘 점점 자주 보는 모습이 있습니다. Claude가 코드베이스를 대신 탐색해 주는 덕분에 엔지니어가 입사 첫날부터 코드베이스에 기여하고, 비엔지니어도 엔지니어 못지않게 효과적으로 기여하는 것입니다. 이 두 가지를 가로막는 것은 자동화가 아니라 사람들 머릿속에만 있는 도메인 지식입니다. 예전에는 적응 기간에 익혀야 했던 바로 그 지식이죠.
에이전트 덕분에 달라진 점은, 인프라로 담아낼 수 있는 도메인 지식이 더 이상 린트 규칙과 타입과 테스트로 표현할 수 있는 범위에 갇히지 않는다는 것입니다. 이제는 코드 주석, 스킬, CLAUDE.md 규칙, 메모리의 형태로 거의 모든 도메인 지식을 담아낼 수 있습니다.
제가 잘 모르는 iOS 코드베이스에 PR을 올렸는데 올바른 프레임워크를 쓰지 않았다는 이유로 리뷰어가 거절하거나, 디자이너가 새 기능을 만들었는데 올바른 아키텍처 패턴을 따르지 않았다는 이유로 거절당한다면, 그것은 자동화의 실패입니다. 모든 팀은 프롬프트를 입력하는 사람이 추가 컨텍스트를 전혀 주지 않아도 에이전트가 코드베이스에서 생산적으로 일할 수 있도록 CLAUDE.md와 REVIEW.md, 스킬, 문서를 작성해야 합니다.
말도 안 되는 소리처럼 들리지만, 동시에 엔지니어들이 늘 해 오던 일, 즉 자동화하고 도메인 지식을 인프라로 담아내는 일의 자연스러운 연장이기도 합니다. 모델이 더 똑똑해지고 하네스가 성숙해질수록 이 일은 더 쉬워집니다. 그때까지는 도메인 지식을 인프라로 바꿀 방법을 찾는 일이 모든 팀의 몫입니다. 그래야 Claude가 코드를 더 잘 작성하고, 코드 리뷰가 문제를 자동으로 잡아내고, 다음에 코드베이스를 맡을 사람이 더 쉽게 기여할 수 있습니다.
