AI가 코드를 써도, 아무도 시스템을 모른다

글을 쓰다 보면 리팩터링과 재작성을 거치며 자신의 이해를 끊임없이 재구성하게 되고, 결국 그것을 내면화하게 된다. 내면화하면 (결정적인 다운타임 동안) 그것에 대해 추론할 수 있는 능력과 그것을 전달할 수 있는 능력을 얻게 된다. 소통할 수 있는 팀 전체가 함께 문제를 해결할 수 있다. 한 사람의 비전에서 제품 화이트보딩, 엔지니어링 인프라, UX와 UI의 예술성까지 아우르면서.

불과 4년 전만 해도 세상이 이렇게 돌아갔다는 걸 우리가 완전히 잊어버렸다는 게 이해가 안 간다.

직업적으로 보면 이게 그렇게 극적이라고 느껴지진 않는다. 주로 내가 꾸준히 대규모로 코드를 출시해온 산업들이 리뷰를 제1원칙으로 삼기 때문이다. 즉, 테스트되지 않고 리뷰되지 않은 코드는 출시되지 않는다. 안전 필수/실시간 요구사항과 인증 사양이 그렇게 하라고 하니까.

그리고 리뷰할 AI 코드가 있다는 건 예전에 리뷰하던 다른 어떤 코드와도 다르지 않다. 그래서 리뷰 도구 역시 필요에 따라 더 많은 AI를 구슬프게 적용함으로써 이득을 본다. 하지만 모든 AI는 인간이 리뷰한다.

그래서 큰 영향은 아니다. 우리는 100% 인간이 리뷰하지 않은 코드는 출시하지 않는다. 그게 감당이 안 된다면, 당신이 잘못하고 있는 거다. AI를 써서 코드를 다시 읽을 수 있게 만들어라.

그리고 AI를 다시 상자에 넣어라. 개발자들에게 구독에 대한 100% 전일제 API 접근 권한을 주지 말고, 실제 하드웨어를 줘서 100% 로컬로 돌리게 하라.

따라서 로컬 AI가 최고의 AI다, 여러분. 로컬에서 돌릴 수 있는 것보다 더 많이 쓰지 않는 것이 AI 코드를 제대로 유지보수 가능하게 유지하는 훌륭한 방법이다.

업계는 머지않아 스스로 이것을 증명할 것이다. AI를 안전하게 보관하기 위해 상자에 넣을 수 없다면, 어차피 당신이 잘못하고 있는 것이고, 수십 년 전에 미래 대비 툴링에 대해 이미 습관으로 익혔어야 했다. (참고: AI로 하는 모든 일을 로깅하지 않는다고? 큰 실패다.)

물론 Big Metal AI™의 절대적으로 취하게 만드는 중독성은 많은 소비자를 깊고 깊은 신문맹의 구덩이에 빠뜨릴 것이다. 하지만 '좋은' AI 코드는 사실 그냥 좋은 코드일 뿐이다.

매일 본다. 문제는 코드가 우리가 하는 일에 잘못된 추상화라는 점이다. LLM은 코딩을 해결했지만, 시스템, 협업, 시스템 유지보수는 해결하지 못했다.

편집: 신경을 건드린 것 같아서 말하자면, 나는 이걸 해결하기 위한 프로젝트를 진행 중이다: https://www.archme.io 올바른 추상화에 대한 내 생각이 궁금하면.

AI는 장기적으로 소프트웨어 엔지니어링을 더 중요하게 만들 것이다. 요구사항 수집, 사용자 피드백, 테스트, 제품 비전. 이것들이 이제 핵심 차별화 요소다.

정말 좋은 요구사항 세트를 얻고, 모든 테스트 케이스를 작성한 다음, 한 방에 해결해줄 AI에게 던져주면 완벽하다.

AI는 프로그래머를 위한 게 아니다. 그들은 항상 불평할 것이고, 시간과 자원이 주어지면 물론 더 나은 원자적 코드를 만들어낼 수 있다. AI는 비즈니스 분석가, 아키텍트, 제품 관리자를 한 사람 안에 결합한 사람을 위한 것이다. 코딩 능력은 있지만 전체 소프트웨어 엔지니어링 라이프사이클에서 제한적인 역할이라고 판단한 사람 말이다. 올바른 태도와 물론 어느 정도의 AI에 대한 마이크로 관리(인간 프로그래머에게도 해야 했던 것)를 통해 훨씬 적은 커뮤니케이션 마찰과 팀워크를 유지할 사람이 적은 상태로 같은 또는 비슷한 결과를 달성하고, 프로그래밍 철학과 더 이상 명예롭거나 독특하지 않은 공예의 다른 선언문을 논의하기보다는 발견한 문제를 해결하는 데 더 가까이 다가갈 수 있다. 그리고 그것이 AI를 잘못된 사람에게 사용하게 했을 때의 핵심 불만 지점이다.

공감이 된다. 7월 말에 회사를 옮겼다. 처음 4주 동안 AI는 나에게 자유로움을 주었다. 더 이상 수만 줄의 레거시 코드베이스를 이해할 필요가 없었다. 온보딩이 이렇게 쉬운 적이 없었다. 그냥 Claude에게 물어보면 여기서 무슨 일이 어떻게 일어나는지 알려줬다.

하지만 2개월이 지나자 역효과가 나기 시작했다. 나는 여전히 아무것도 모른다. 시스템 설계와 핵심 구성 요소에 대한 이해는 좀 있지만, 내부적으로 특정 일이 어떻게 처리되는지는 전혀 모른다. AI가 나 대신 코드를 읽고 나 대신 코드를 써줬고, 나는 그것을 내 이해로 착각했다.

지난주에는 AI 사용을 제한하고, 여기서 무슨 일이 벌어지는지 조금이라도 알기 위해 스스로 읽고 코딩하는 연습을 하도록 강제했다(정말 힘들다).

지금 이 순간에도 일을 잘못하는 방법은 백만 가지가 있다.

하지만 일을 올바르게 하는 방법도 몇 가지, 아마 백만 가지보다는 적을 것이다.

이것을 잘못하는 방법에 대한 일화가 하나 있다.

AI 코딩 방법론에서 어떤 선을 넘으면 헤일메리(미식축구 용어)가 되는 지점이 있다는 걸 발견했다.

헤일메리는 엔드존으로 공을 던지고 누군가 잡기를 그냥 기도하는 것이다. 거의 항상 경기 막판에 나온다.

AI 코드와 함께하는 이 순간은 일관된 계획을 세울 수 없어서 그냥 에이전트에게 "잘 만들어줘"라고 말하는 상황을 보여준다. 예전에는 이런 결과가 형편없었지만, 이제 에이전트는 정말 유능해서 결과가 좋을 수도 있다.

하지만 바로 그 순간이 뒤로 물러설 신호다. 당신의 이해와 너무 동떨어진 해결책을 받아들이는 순간, 당신은 물속에 잠긴 것이다. 헤일메리는 더 큰 경기 계획의 일부가 아니다. 경기의 마지막 플레이다. 그 뒤에는 아무것도 없다.

따라서 코딩 중에 그 순간에 도달하면, 코드뿐만 아니라 높은 수준에서 그것이 작동하는 방식조차 이해하는 것을 그만두겠다는 신호를 보내는 것이다. 이후에도 이 코드로 계속 작업할 거라면, 뒤로 물러나 AI와 함께 문제에 대한 이해를 더 얻어라.