왜 나는 여전히 코드를 읽는가
요약
LLM 시대에도 소프트웨어 엔지니어는 코드를 읽는 능력을 포기해서는 안 됩니다. 코드 리뷰와 이해는 시스템의 실제 동작 방식과 아키텍처적 결정의 신뢰성을 보장하는 핵심 과정입니다. 특히 LLM이 생성한 코드는 비결정론적일 수 있어, 디테일을 직접 확인해야 합니다.
핵심 포인트
- 코드 읽기는 시스템에 대한 깊은 지식을 유지하는 방법이다.
- LLM 출력은 비결정론적이므로, 의도대로 작동함을 보장할 수 없다.
- 엣지 케이스나 미묘한 부작용을 파악하려면 디테일(diff) 확인이 필수적이다.
- 레거시 시스템에서는 역사적 맥락 이해를 위해 코드를 읽는 것이 중요하다.
최근(지난 10개월 정도) 소프트웨어 엔지니어의 직업은 많이 변했습니다.
저에게도 그런 일이 일어났습니다. 더 이상 직접 코드를 작성하지 않습니다.
이러한 변화에 대한 많은 대화들은 소프트웨어 엔지니어링이 이제 기본적으로 설계 결정을 내리고, LLM의 출력을 검토하며, 프로덕션에 게시되는 것이 장기적인 베팅이 될 수 있도록 보장하는 것에 관한 것이라고 지적합니다.
저는 그 방향의 많은 부분에 동의합니다. 하지만 우리가 아예 코드를 읽을 필요가 없다는 인식이 커지고 있습니다.
전자레인지 오븐을 설계하는 엔지니어들을 생각해 보세요. 그들은 그것들을 손으로 만들지 않습니다. 기계가 그렇게 합니다. 하지만 그 엔지니어들은 여전히 최종 제품이 내부적으로 어떻게 만들어지는지 정확히 알고 있습니다. 왜냐하면: 생산 라인이 오작동하는 장치를 밀어내기 시작하거나, 제품이 현장에서 고장 날 때, 개입해야 하는 사람들이 바로 그들이기 때문입니다. 수정이 필요하고 개선이 기대되는데, 제품이 실제로 어떻게 만들어지는지 모른다면 그것은 불가능해집니다.
코드 생성을 LLM에 위임한다고 해서 이 현실이 바뀌는 것은 아닙니다. 저는 우리가 코드를 읽는 것을 멈출 수 있다는 생각에 동의하지 않습니다.
"컴파일러가 생성하는 어셈블리를 아무도 읽지 않는다." 맞는 말이지만, 그 이유는 결정론(determinism) 때문입니다. 컴파일러와 함께라면 소스에서 출력으로의 매핑은 결정론적이며 명시되어 있습니다. 과정이 그것을 보장하기 때문에 내부에 무엇이 있는지 알 수 있습니다. 반면 LLM과 함께라면 계획에서 코드로 가는 단계는 결정론적이지 않습니다. 같은 계획이라도 다른 코드를 생성할 수 있으며, 무엇이 나오든 당신이 의도한 것인지 아무것도 보장하지 않습니다. 내부를 알 수 있는 유일한 방법은 그것을 열어보는 것입니다.
네, 이것은 이전보다 더 많은 읽기를 의미하며, 그것이 현재 직업의 대가입니다. 제가 이만한 가치가 있다고 생각하는 이유를 알려드리겠습니다.
1. 시스템 지식은 코드에 존재한다
코드를 읽고 실제로 이해하는 것이 우리가 시스템을 잘 알기 위해 필요한 지식을 얻고 유지하는 방법입니다.
이러한 깊은 이해 없이는 어떤 아키텍처적 결정이 다른 것보다 신뢰성 있게 우월하다고 주장할 수 없습니다. 고수준 다이어그램과 문서는 단지 시스템이 어떻게 작동하도록 의도되었는지를 알려줄 뿐이며, 코드는 실제 조건에서 실제로 어떻게 동작하는지를 보여줍니다.
만약 코드 읽기를 멈춘다면, 당신은 시스템과의 친밀감을 잃게 됩니다. 그리고 시스템에 대한 친밀감을 잃으면, 당신의 아키텍처적 결정들은 단순히 요약본에 기반한 추측일 뿐입니다.
2. 디테일에 악마가 있다 (The devil is in the details)
LLM이 방금 생성한 내용이나, 코드를 작성하게 하기 전에 계획을 검토할 때 LLM이 무엇을 생성할 것인지에 대한 고수준 설명만으로는 모든 요구사항이 충족되었고 회귀(regression)가 발생하지 않았음을 확신하기에 충분하지 않습니다.
요약본은 항상 그럴듯하게 들립니다. 하지만 그것들은 미묘한 부분들, 즉 처리되지 않은 엣지 케이스(edge case), 깨진 암묵적 계약(implicit contract), 또는 세 단계 아래에서 의도치 않은 부작용을 일으키는 상태 변이(state mutation)를 포착하지 못합니다.
변경 사항이 안전하다는 것을 알기 위해서는 diff를 읽어야 합니다.
레거시 현실 대 그린필드 (Legacy reality vs. greenfield)
그래서 저는 여전히 코드를 읽고 있으며, 제가 스스로의 품질 기준을 충족하는 코드를 계속 제공하고 싶다면 장기적으로도 그렇게 할 것입니다.
이것은 특히 커밋 기록이 10년 이상 된 레거시 코드나 타사 서비스와의 통합으로 가득 찬 플랫폼에 해당합니다. 그러한 환경에서는 특이한 코드 라인들이 보통 어렵게 배운 프로덕션 경험들 때문에 존재하기 때문입니다. LLM이 스스로를 검토하거나 고수준 요약본을 생성한다고 해도, 모든 역사적 흉터(historical scar)에 대한 맥락을 가질 수는 없습니다.
새로운 프로젝트의 경우 다를 수 있으며, 저는 그것을 실험하고 있습니다. 하지만 성숙한 프로덕션 시스템에게 코드를 건너뛰는 것은 도박입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기