원시인이 되지 마라

15년 넘게 소프트웨어를 만들어왔다. 그동안 클라우드 컴퓨팅, 마이크로서비스, 컨테이너, DevOps, CI/CD가 뜨고 지는 걸 다 봤고, 업계에서 입만 열면 떠드는 "이게 모든 걸 바꾼다"는 순간들도 전부 겪었다. 대부분 소프트웨어를 만드는 방식은 바꿨어도, 엔지니어링의 본질까지 바꾼 건 아니었다.

AI는 좀 다르다. 단순히 코드를 짜서가 아니라, 가장 영향력 있는 엔지니어가 시간을 쓰는 방식 자체를 바꿔버려서다.

요즘 보면 다들 '바이브 코딩(vibe coding)'을 무슨 프롬프트 넣고, 수락하고, 배포하면 끝나는 3단계 과정인 것처럼 생각하는데, 그건 엔지니어링이 아니다. 그냥 생각을 외주 주는 거지. 진짜 위험한 건 AI가 코드를 짜준다는 사실 자체가 아니라, 어느 순간부터 질문을 멈추게 된다는 거다. 이 추상화는 왜 존재하는지? 왜 이 서비스가 이런 동작을 담당하는지? 이 구현은 어떤 가정을 깔고 있는지? 부하가 걸리면 어디서 터지는지? 6개월 뒤에 이걸 어떻게 디버깅할 건지? 다른 엔지니어가 이걸 확장해야 할 땐 어떻게 되는지?

이런 질문에 답 못 하면, 네가 시스템을 소유한 게 아니라 시스템이 너를 소유한 거다.

지난 1년 동안 내 사고방식에서 가장 크게 바뀐 건, 나 자신을 '소프트웨어 짜는 사람'이라고 생각하지 않게 됐다는 점이다. 나는 내 코드베이스의 CEO라고 생각한다. 방향을 정하고 제약을 정의한다. 아키텍처를 결정하고 문제를 잘게 쪼갠다. 어떤 AI 에이전트가 뭘 할지 정하고, 결과물을 검토하고, 구린 건 쳐내고, 괜찮은 건 합치면서 시스템이 내가 의도한 대로 돌아갈 때까지 반복한다. 타이핑은 이제 별로 중요하지 않다. 결정이 전부다.

"AI가 엔지니어를 대체한다"는 말이 헛소리인 이유도 이거다. 코딩은 원래 희소 자원이 아니었다. 진짜 귀한 건 '좋은 엔지니어링적 판단'이었다. 모호한 문제를 분해하고, 트레이드오프를 따지고, 2차적인 파급 효과를 이해하고, '정답'인 솔루션이 실제 비즈니스에선 왜 잘못된 선택인지 알아채는 능력. AI는 이런 능력들을 없애지 않았다. 오히려 그 중요성을 더 키웠을 뿐이다. AI를 든 뛰어난 엔지니어는 훨씬 더 강력해지지만, 평범한 엔지니어는 그저 기술 부채만 더 빨리 쌓을 뿐이다.

요즘 나는 에이전트 시스템을 만드는 데 시간을 거의 다 쓴다. 근데 제일 잘 돌아가는 시스템들은 LLM한테 마법의 프롬프트 하나 던져준다고 나오는 게 아니다. 철저히 엔지니어링의 영역이다. 작업을 전문 에이전트들로 쪼개고, 얘네끼리 어떻게 소통할지 설계하고, 검토 루프를 만들고, 검증 단계를 넣고, 피드백 메커니즘을 구축하고, 언제 에이전트가 자율적으로 움직이고 언제 사람이 개입할지 결정하는 것. 이게 바로 더 높은 추상화 단계에서의 소프트웨어 엔지니어링이다.

컴퓨팅의 모든 큰 변화는 항상 그 아래 계층을 추상화해왔다. 어셈블리가 C가 됐고, C가 프레임워크가 됐고, 프레임워크가 클라우드 플랫폼이 됐다. 이제는 구현 그 자체가 추상화되고 있다. 살아남는 엔지니어는 옛날 추상화에 매달리는 놈들이 아니라, 한 단계 위로 올라가는 놈들이다.

그러니까 지금 AI를 쓰고 있다면, 방 안에서 제일 타자 빠른 놈이 되려고 하지 마라. 원시인처럼 굴지 말고 엔지니어가 돼라. 아키텍트처럼 생각하고, 코드베이스의 CEO처럼 운영해라. AI 네이티브 세상에서 네 가치는 네가 얼마나 많은 코드를 짰느냐가 아니라, 그 코드 뒤에 담긴 결정의 질로 증명되는 거니까.