Most Engineers Use AI. Few Engineer With It.
Most software engineers I know use AI in some form now. Maybe it is for debugging, boilerplate,...
개요 #
이제 거의 모든 개발자가 어떤 식으로든 AI를 쓴다. 디버깅, 보일러플레이트, 테스트, 문서, SQL, 셸 명령어, 빠른 코드 리뷰까지. 회의적이던 사람조차 막히는 스택 트레이스를 한 번쯤 챗봇에 붙여넣어 봤을 것이다.
그래서 흥미로운 질문은 "개발자들이 AI를 쓰는가?"가 아니다. 더 나은 질문은 "AI가 그들이 엔지니어링하는 방식을 바꿨는가?"다. 이 둘은 같은 말이 아니다. AI를 쓰는 건 쉽다. AI로 엔지니어링하는 건 훨씬 어렵다.
어려운 건 코드 생성이 아니었다 #
원문 저자는 실제 저장소 작업에 AI를 붙이면서 이걸 깨달았다. 잘못된 변경은 단순히 "출력이 나쁜" 수준에서 끝나지 않는다. 구조를 깨고, 테스트를 망치고, 네이밍을 흐트러뜨리고, 나중의 유지보수성까지 갉아먹는다.
코드 생성 자체는 쉬웠다. 두루뭉술한 프롬프트만으로도 많은 양의 코드가 빠르게 나왔다. 첫인상은 깔끔해 보일 때도 있었다. 하지만 쓸 만한 결과는 지루한 엔지니어링 작업을 미리 끝냈을 때만 나왔다. 요구사항을 정의하고, 범위를 좁히고, 제약을 설명하고, 변경을 어떻게 검증할지 정하는 일 말이다.
진짜 어려운 건 AI에게 코드를 써달라고 부탁하는 게 아니었다. 프롬프트에 모든 걸 쏟아붓지 않으면서 충분한 맥락만 주는 일, 작업을 충분히 작게 쪼개는 일, 구현 전에 트레이드오프를 먼저 묻는 일, 깔끔한 포맷에 현혹되지 않고 출력을 검토하는 일이 어려웠다. 무엇보다 그 해법이 정말 이 시스템에 속하는지 따지는 일이 어려웠다.
그러면서 AI 보조 개발을 보는 시각이 바뀌었다. 프롬프팅은 진짜 기술이 아니었다. 일을 다듬는 것이 진짜 기술이었다.
AI는 출력을 빠르게 할 뿐, 검증을 강하게 하지 않는다 #
작은 작업에 AI를 쓰는 건 전혀 잘못이 아니다. 디버깅 방향, 네이밍, 보일러플레이트, 테스트 아이디어, 문서 초안, 낯선 코드 탐색에 쓰면 마찰이 줄어든다.
위험은 빠른 출력을 더 나은 엔지니어링으로 착각할 때 시작된다. AI는 깔끔해 보이는 함수, 잘 정돈된 파일, 자신만만한 설명, 그럴듯한 테스트 케이스를 빠르게 만든다. 하지만 그 변경이 당신의 제품과 아키텍처, 제약, 장기 유지보수 비용에 맞는지는 알아서 판단하지 못한다. 그건 여전히 엔지니어의 몫이다.
문제의 핵심은 AI가 나쁜 코드를 낼 수 있다는 게 아니다. 개발자는 이미 사람이 쓴 나쁜 코드, 라이브러리, 튜토리얼, 스택오버플로 답변, 그리고 지친 자기 머리에서 나온 코드를 늘 상대해 왔다. 더 큰 문제는 AI가 검증의 질은 그대로 둔 채 출력 속도만 끌어올린다는 점이다.
코드 생성이 빨라질수록 모호한 요구사항은 더 비싸진다. 허술한 리뷰는 더 위험해지고, 빠진 테스트는 더 아프며, 엉성한 아키텍처는 복사하기 쉽고 되돌리기는 어려워진다. AI는 엔지니어링을 자동으로 개선하지 않는다. 이미 존재하는 엔지니어링 루프를 증폭할 뿐이다.
두 번 생각하고, 한 번 코딩하라 #
AI는 문제를 온전히 이해하기 전에 코드를 만들기 쉽게 한다. 작업이 명확할 땐 유용하지만, 작업이 모호할 땐 위험하다.
요구사항이 불분명해도 AI는 뭔가를 만들어낸다. 아키텍처가 엉망이어도 AI는 그 엉망을 그대로 복사한다. 엔지니어가 출력을 제대로 검토하지 못하면 속도는 그대로 리스크가 된다.
그래서 "AI가 엔지니어를 대체한다"는 말은 이 대화에서 가장 쓸모없는 버전이라고 본다. 더 나은 질문은 이거다. "코드 생성이 싸지면, 엔지니어링의 어떤 부분이 더 중요해지는가?" 답은 구현 전에 명확하게 생각하는 능력이다.
AI는 오래된 조언을 덜 중요하게 만드는 게 아니라 더 중요하게 만든다. 두 번 생각하고, 한 번 코딩하라. AI에게 만들어달라고 하기 전에 문제를 정의하고, 답을 받아들이기 전에 트레이드오프를 확인하고, 변경을 머지하기 전에 동작을 검증하라. 엔지니어링의 가치는 코드를 쓰는 것에서 올바른 변경을 다듬는 쪽으로 옮겨가고 있다.
AI로 엔지니어링한다는 것 #
원문 저자에게 AI로 엔지니어링한다는 건 AI를 마법의 답 상자가 아니라 구조가 필요한 협업자로 대하는 일이다.
작업은 구현 전에 시작된다. 요구사항을 적고, 범위를 좁히고, 쓸 만한 맥락을 주고, 리스크를 묻고, 코드보다 계획을 먼저 끌어낸다. 구현 후엔 책임이 다시 엔지니어에게 돌아온다. diff를 검토하고, 검증을 돌리고, 이 변경이 시스템에 속하는지 판단한다.
쓸 만한 AI 보조 루프는 단순할 수 있다.
요구사항 → 빈틈 → 계획 → 작은 변경 → 리뷰 → 검증 → 기록
화려한 버전의 AI 개발은 아니다. 하지만 진짜 엔지니어링에 더 가깝다. 진짜 엔지니어링은 코드를 찍어내는 게 아니라 신뢰할 수 있는 변경을 만들어내는 일이기 때문이다.
진짜 변화 #
소프트웨어 엔지니어링의 다음 변화는 누가 가장 많은 코드를 뽑아내느냐가 아니다. 그 이점은 이미 싸지고 있다. 더 어려운 이점은 무엇을 만들어야 하는지, 그것이 시스템에 어떻게 들어맞는지, 그리고 그게 제대로 동작하는지 검증하는 방법을 아는 것이다.
Photo by ThisIsEngineering on Pexels
여기서 AI 보조 엔지니어링이 흥미로워진다. AI가 엔지니어링 판단을 대체해서가 아니라, 그 판단을 건너뛰기 어렵게 만들기 때문이다.
대부분의 굵직한 엔지니어링 도구는 팀이 그 주변의 워크플로를 바꾼 뒤에야 가치가 생겼다. Git은 협업을 바꿨고, 클라우드는 인프라를, CI/CD는 배포를 바꿨다. AI는 그 변화들보다 더 넓고 어수선하며 빠르게 움직이니 똑같은 길을 따른다고 단정하긴 어렵다. 그래도 교훈은 익숙하다. 도구는 중요하다. 도구를 둘러싼 워크플로는 더 중요하다.
가장 큰 이득을 보는 엔지니어는 AI를 가장 많이 쓰는 사람이 아닐 것이다. 더 나은 루프를 설계하는 사람, 즉 더 명확한 명세, 더 작은 변경, 더 강한 리뷰, 더 나은 테스트, 더 신중한 결정을 만드는 사람일 것이다.
그렇다. 이제 대부분의 개발자가 AI를 쓴다. 하지만 AI로 엔지니어링하기 시작한 사람은 아직 소수다. 이 시기에 가장 뛰어난 엔지니어는 프롬프트를 가장 빨리 쓰는 사람이 아니라, 구현을 서두르기 전에 문제를 천천히 들여다볼 줄 아는 사람일지도 모른다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.