코드 품질이 아직 중요하냐는 질문에, 「그때그때 달라요」 말고 답하기

AI가 코드를 대신 짜 주는 요즘, 개발자들 사이에서 자주 나오는 얘기가 있어요. 코드 품질, 아직 중요해요? 어차피 다시 짜면 되는데 깔끔한 코드가 무슨 소용이냐는 쪽이 있고, 그렇게 쌓인 코드가 결국 발목을 잡는다는 쪽이 있죠.

시니어 엔지니어한테 물으면 답은 거의 정해져 있어요. Max Kanat-Alexander도 발표를 이 얘기로 시작해요.

Every senior engineer's favorite answer to every question, which is it depends. Now, that's not a very helpful answer though, frankly, because what does it depend on?

시니어 엔지니어라면 뭘 물어도 좋아하는 답이 있죠. "그때그때 달라요." 솔직히 별 도움은 안 돼요. 대체 뭐에 따라 달라진다는 건데요?

맥스는 지금 Capital One에서 일하고, 『Code Simplicity』라는 책을 쓴 사람이에요. 10월 21일 AI Engineer 채널에 올라온 「Does Code Quality Still Matter? It Depends on This」가 바로 그 "뭐"를 정리한 발표예요. 16분짜리라 원본도 한번 보시길 권하고, 여기서는 발표 순서대로 따라가 볼게요.

품질 도구는 정확성을 위해 있는 게 아니래요

맥스는 소프트웨어로 하려는 일이 전부 두 가지에 달렸다고 봐요. 시스템을 이해하는 것, 그리고 이해한 대로 해내는 것. 디버거도, 관측성 도구도, eval도, 심지어 테스트도 이 두 가지 때문에 있다고요.

Everything we have ever done in the field of code quality is exclusively and only for these two things. It's not for anything else.

코드 품질을 위해 우리가 해 온 일은 전부 이 두 가지 때문이에요. 다른 이유는 없어요.

정확성 때문이 아니라는 말까지 굳이 덧붙여요. 그럼 엔지니어는 뭘 이해해야 할까요. 맥스가 꼽는 건 둘이에요. 시스템이 실제로 어떻게 움직이는지(문서에 적힌 동작 말고 진짜 동작), 그리고 그걸 틀리지 않고 안전하게 바꾸는 법.

Hello World를 찍는 프로그램이면 설명할 게 없어요. "Hello World를 찍어요." "Hi World로 바꿔 주세요." "네." 끝이죠. 그런데 맥스가 띄운 Chromium 코드베이스 지도는 얘기가 달라요. 구성 요소끼리 맞물리는 경우의 수가 사실상 끝이 없어서, 전체가 어떻게 움직이는지는 말로 설명할 수가 없대요. 대신 URL 파서처럼 구성 요소 하나가 뭘 하는지는 설명할 수 있고요.

같은 Hello World를 두 가지로 나란히 보여 주기도 해요. 왼쪽은 평범한 코드, 오른쪽은 어셈블리 명령을 늘어놓은 코드예요. 결과는 똑같아요. 하지만 왼쪽은 보자마자 Hello World인 줄 알겠는데, 오른쪽은 그냥 명령이 줄지어 있을 뿐이에요. 그런 코드가 수백만 줄이면 읽기가 훨씬 어려워지겠죠.

그동안 가독성이니 테스트 용이성이니 하는 말로 불러 온 것도, 결국 중요했던 건 이해할 수 있는 구조였다는 게 맥스의 얘기예요.

바꿀 때마다 위험이 두 개 따라와요

구조가 제일 티 나는 건 시스템을 바꿀 때예요. 맥스는 무엇을 바꾸든 두 가지 위험이 따라온다고 해요.

첫째, 지금 바꾸다가 문제가 생기는 것. 여기서 문제는 버그만이 아니에요. 일정이 늘어지는 것, 사용자가 원한 대로 동작하지 않는 것, 예산을 넘기는 것까지 다 들어가요. 둘째, 다음 변경을 더 어렵게 만드는 것. 시스템을 더 알아보기 힘들게 만들어서 다음에 사고가 날 확률을 키우는 거예요.

I can reduce every postmortem I have ever read for any incident to these two factors in one way or another.

제가 읽어 본 장애 회고는 하나도 빠짐없이 결국 이 두 가지로 정리돼요.

무서운 건 두 번째가 첫 번째를 키운다는 점이에요. 알아보기 힘든 정도가 조금씩 느는 게 아니라 눈덩이처럼 불어난대요. 그러다 보면 뭘 바꾸든 사고가 나는 때가 와요. 맥스는 1억~5억 줄짜리 메인프레임 코드베이스를 예로 들어요.

flowchart LR
  U["이해하기 어려운 시스템"] -->|바꾼다| P1["① 지금 문제가 생긴다"]
  U -->|바꾼다| P2["② 더 이해하기 어려워진다"]
  P2 -->|불어난다| U

미래 모델 얘기는 하지 않았어요

여기서 흔히 나오는 반론이 있죠. 복잡한 건 사람한테나 문제고, 모델이 좋아지면 다 알아서 이해하지 않겠냐는 것. 맥스는 그럴 수도 있다고 인정하고 넘어가요. 대신 모델이 지금 이미 하고 있는 일로 화제를 돌려요. 일회용 소프트웨어를 만들고 있다는 거예요.

OS 기본 계산기가 마음에 안 들면 내 계산기를 만들어요. 아이들 파티를 준비하려고 그 파티 하나만을 위한 프로그램을 짜고, 끝나면 버려요. 맥스는 이런 소프트웨어가 다른 소프트웨어보다 "10만 배"는 흔해질 거래요(숫자는 그냥 강조로 들으면 돼요). 이런 데서는 코드 품질이 중요하지 않아요. 품질로 막으려던 위험, 시간이 갈수록 불어나는 위험이 애초에 없으니까요.

일회용인지 오래 쓸 소프트웨어인지는 네 가지로 가려요.

넷 다 낮으면 일회용, 넷 다 높으면 오래 쓰는 소프트웨어예요. 그 사이 어디쯤이냐에 따라 공을 얼마나 들일지, 맥스 표현으로는 엄밀함(rigor)을 얼마나 들일지가 달라지고요. 그러면서 오래 해 본 사람이면 다 아는 얘기라며 한마디 덧붙여요. 애매하면 오래 쓰는 쪽으로, 네 가지가 생각보다 높다고 보라고요.

맥스가 다시 한번 못 박는 것도 있어요. 오래 쓰는 소프트웨어를 만드는 일은 없어지지 않는다는 것. 요즘 소셜 미디어에서 제일 많이 보는 착각이 이거래요. 오히려 AI 코딩 도구 덕분에 오래 쓸 소프트웨어를 만들기도 쉬워지니, 그 양은 더 늘어날 거라고 봐요. 제일 중요한 건 여전히 오래 쓰는 시스템이고, 개수로 제일 많아지는 게 일회용일 뿐이에요.

일회용을 일부러 만들 수도 있어요

저희한테는 이 대목이 제일 새로웠어요. 소프트웨어를 일부러 더 일회용으로 만들 수 있다는 거예요.

먼저 환경을 떼어 내요. 내 데이터에만 닿고 고객 데이터나 개인정보는 없는 환경에만 올리게 하는 거죠. 거기에 다른 운영 시스템이 API를 부르지 못하게 막으면, 그 환경에 올라간 건 다 일회용이 돼요. 투박해도 오래 버텨 온 원래 시스템을 남겨 두는 것도 방법이에요. 누가 바이브 코딩으로 자기 화면을 만들어 쓰다가 그게 망가지면(맥스는 "망가질 거예요"라고 아예 단정해요) 원래 시스템으로 돌아가면 되니까요. 마지막은 범위를 좁히는 거예요. 이 사람 한 명을 위한 계산기, 이 파티 하나를 위한 일정표처럼요.

flowchart LR
  O["다른 운영 시스템"] -- 호출 금지 --x ISO
  subgraph ISO["격리 환경 · 내 데이터만"]
    V["직접 만든 화면"]
  end
  User["사용자"] --> V
  User -->|망가지면| B["원래 시스템<br/>투박하지만 오래 버틴"]

맥스는 이걸 소프트웨어 공학의 새 분야라고 불러요. 오래 쓰는 시스템을 더 엄밀하게 만드는 게 아니라, 더 많은 걸 마음 놓고 버릴 수 있게 만드는 분야요.

진짜 하고 싶은 말은 엄밀함을 싸게 만들라는 거였어요

그런데 일회용으로 시작한 게 오래 쓰는 물건이 되기도 하죠. 맥스도 그 판단을 늘 맞힐 수는 없다고 해요. 그래서 제일 신경 써야 할 건 엄밀함에 드는 비용을 낮추는 일이래요. 그 비용이 싸면 지금 어디쯤인지 덜 걱정해도 되고, 판단이 틀렸을 때 방향을 바꾸기도 쉬우니까요.

남은 5분 동안 그 방법을 네 가지 꼽아요.

mindmap
  root((엄밀함을 싸게))
    표준화
      경우의 수를 줄인다
    알아서 도는 도구
      오탐 적고 빠르게
    쉬운 테스트
      인메모리 가짜 서비스
    규칙은 처음부터 엄격하게
      전부 최대로 켠다

표준화는 "위에서 하라고 해서" 하는 게 아니라 신경 쓸 경우의 수를 줄이려고 하는 거예요. 시스템에 PHP가 없으면 PHP 린터도, PHP 관행도, PHP 보안 구멍도 신경 쓸 필요가 없어요. 프레임워크를 하나로 맞추고 RPC 프로토콜을 통일하는 것도 같은 이유고요. 에이전트한테 도구를 다 만들게 할 수는 있지만, 그러면 매번 새로 만들어야 해요.

다음은 알아서 도는 도구예요. 개발자가 일부러 돌리지 않아도, 어떻게 도는지 몰라도 그냥 돌아가는 도구요. 대신 믿을 수 있어야 해요. 오탐이 적고 빨라야 하죠. 공짜나 다름없고 빠르면 일회용 소프트웨어에도 그냥 켜 두면 된대요.

테스트는 "어떻게 하면 테스트를 더 잘할까"가 아니라 "어떻게 하면 아무도 테스트를 고민하지 않아도 될까"를 물어요. 테스트를 잘 몰라도 모든 테스트가 빠르고, 돌릴 때마다 결과가 같게 만드는 거예요. 맥스가 테스트 담당자로서 오래 바란 건 팀마다 자기 서비스의 인메모리 가짜 버전을 내놓는 거였는데, 이제는 코딩 에이전트가 그걸 만들 수 있대요. 다만 누군가 하기로 정하고 다 같이 쓸 수 있게 열어 둬야 하고요.

마지막은 규칙을 처음부터 엄격하게 켜는 거예요. 린트 규칙을 전부 최대로 올리고 어떤 것도 타협하지 않아요. 표준화처럼 이것도 따질 거리를 확 줄여 준대요. 린터가 가끔 틀려도 오탐이 드물고 큰일이 나지 않으면 괜찮고요. 백만 줄짜리 코드베이스에 린터를 뒤늦게 켜 본 사람한테 물어보라고 해요. 10만 줄을 고쳐야 했다는 답이 돌아올 거라고요.

그리고 처음 질문으로 돌아가요. 이제 "그때그때 달라요" 말고 답할 수 있다면서요.

세 번째 질문은 맥스가 마지막에 새로 던진 거예요. 발표 제목이 묻는 건 앞의 두 질문인데, 정작 하고 싶었던 말은 세 번째였던 것 같아요.

읽으면서 걸렸던 것들

16분짜리 발표라 아쉬운 데도 있었어요.

우선 근거가 주로 맥스의 경험이에요. 장애 회고가 전부 두 위험으로 정리된다는 말도, 일회용 소프트웨어가 10만 배 흔해진다는 말도 데이터로 보여 주지는 않아요. 오래 일한 사람이 보고 겪은 거죠. 틀렸다는 얘기가 아니라, 그 정도 무게로 들으면 된다는 거예요.

네 가지 기준을 어떻게 재는지도 나오지 않아요. 의존하는 사람이 몇 명부터 많은 건지, 갈아엎는 비용이 얼마부터 큰 건지는 각자 판단해야 해요. 그래서 네 가지 기준은 정답을 알려 준다기보다 스스로 물어볼 거리를 던져 주는 정도예요.

일회용으로 시작한 소프트웨어가 언제부터 오래 쓰는 소프트웨어가 되는지도 고민이 남아요. 혼자 쓰려고 만든 도구가 팀에 공유되고, 어느새 다른 사람의 업무에 필요한 도구가 될 수도 있으니까요. 처음에는 버려도 상관없었지만, 어느 순간부터는 쉽게 버릴 수 없는 시스템이 되는 거죠.

맥스가 엄밀함을 싸게 만드는 일을 강조한 것도 이런 상황 때문인 것 같아요. 처음의 판단이 틀릴 수 있다는 걸 전제로, 나중에 방향을 바꾸는 비용을 줄이자는 거예요.

정작 그 방법은 발표에서 가장 짧게 다뤄져요. 맥스는 이 주제만으로도 10시간은 이야기할 수 있다고 했지만, 이번에는 네 가지 방법을 훑고 지나갔어요. 실무에서 어떻게 적용할지는 각자 고민해 봐야 할 부분이에요.

저희가 비슷한 데서 겪은 일

엄밀함을 싸게 만드는 쪽으로는 저희도 몇 번 글을 썼어요. 문서로만 적어 둔 폴더 구조 규칙을 검사로 바꾼 이야기는 폴더 구조 규칙을 문서가 아니라 코드로 지키기로 했어요에, 타입 검사와 린트를 다 통과한 회귀를 테스트로 잡은 이야기는 React Compiler를 켜고 나서 — 회귀 4건을 잡은 기록에 있어요.

둘 다 사람이 신경 써서 지키던 걸 알아서 도는 검사로 옮긴 이야기예요. 앞의 글은 문서로 정한 규칙이 안 지켜져서, 뒤의 글은 렌더가 순수하다는 전제를 아무도 확인한 적이 없어서 시작됐어요.

당시에는 어떻게 하면 같은 문제를 반복하지 않을까 고민하면서 만든 것들이었어요. 그런데 이번 발표를 보고 나니, 결국 품질을 지키는 데 드는 노력을 줄이는 일이기도 했다는 생각이 들었어요.

AI 덕분에 코드를 만드는 건 점점 쉬워지고 있어요. 하지만 그 코드가 쌓이고, 다른 사람이 사용하고, 계속 바꿔야 하는 시스템이 되면 여전히 품질을 신경 써야 해요.

그래서 이제는 코드 품질이 중요하냐는 질문보다, 필요한 품질을 얼마나 적은 노력으로 유지할 수 있느냐는 질문이 더 중요하게 느껴져요.