모든 줄을 읽을 필요는 없습니다.

발행: (2026년 1월 14일 오전 03:03 GMT+9)
9 min read
원문: Dev.to

Source: Dev.to

매일이 당신의 첫 번째 날입니다.

잠시 당신의 생각을 빌려서 사고 실험을 해보겠습니다.

새로운 직장에서 코드베이스에 기여하려고 할 때, 변경을 푸시하기 전에 존재하는 모든 코드를 읽어볼까요? 아니면 변경하려는 모듈의 모든 코드를 읽어볼까요? 혹은 수정하려는 함수의 모든 코드를 읽어볼까요?

필요한 정확도의 정도는 작업에 따라 달라지겠지만, 대부분의 경우 프로젝트에 존재하는 모든 코드를 읽을 여유는 없습니다.

그렇다면, 그 코드가 현존 최고의 소프트웨어 엔지니어가 작성했다고 하면 어떨까요? 마음이 놓이시나요? 아니면 전부 인턴이 작성했거나 AI가 생성한 코드라면요?

아마 지금 제 의도를 파악하고 계실 겁니다… 우리 모두 끔찍한 레거시 코드베이스, 인턴 코드, 그리고 잊고 싶은 것들을 본 적이 있죠. 하지만 그것이 세상의 끝은 아닙니다, 왜냐하면…

레거시 코드가 세상을 움직인다

레거시 코드는 좋은 문제다. 이는 회사가 충분히 오래 살아남아 시간이 지나면서 부서진 코드를 축적했다는 의미이며, 이를 마이그레이션하거나 수정하는 작업을 맡게 된다면 여전히 추출할 가치가 있다.

우리는 많은 은행과 포춘 500대 기업에서 메인프레임 위에서 실행되는 COBOL 이야기를 모두 들어봤다. 그들의 최종적인 몰락을 추측할 수는 있겠지만, 그들의 매출 규모는 부인할 수 없다.

The Self‑Driving Car Problem

완전 자율 주행 차가 당신의 운전만큼 안전하다고 확신한다면, 그 차를 타고 다니게 하시겠습니까? 만약 그 차가 10배, 혹은 100배 더 안전하다면 어떨까요?

대조적으로, 도로 위의 모든 다른 차를 평균 운전자보다 25 % 더 안전하다고 입증된 자율 주행 차로 교체한다면, 그런 상황에서 운전하는 것을 받아들이시겠습니까?

대부분의 사람들은 자신이 행동을 통해 영향을 미칠 수 있는 위험에 대해 통제력을 과대평가하는 편향을 가지고 있습니다. 따라서 많은 사람들이 자율 주행 차량이 자신만큼—혹은 그보다—안전하다는 합리적인 설득에도 불구하고, 그 차에 타는 것을 거부할 것입니다.

그렇다면… 질문은, 여러분이 LLM에게 코딩을 맡기겠느냐는 것입니다.

LLM 코드는 당신이 쓰지 않은 코드일 뿐

그것이 첫 번째 실제 제안으로 이어집니다. LLM에 대해 아직 고민 중이라면 직접 시도해 보세요:

  1. 최신 코딩 모델에게 코드베이스 내에서 독립적인 작업을 부여합니다.
  2. 모델과 함께 계획을 세우고 요구사항을 명확히 합니다.
  3. 첫 번째 버전을 생성하면 코딩 표준과 테스트 요구사항을 설명하고, 스스로 리뷰하도록 요청합니다.
  4. 풀 리퀘스트를 열게 하고 직접 확인해 보세요. 인턴, 주니어 엔지니어, 혹은 동료가 작성했어도 화가 나시겠습니까?

요구사항에 대해 대화하고 표준을 설명해야 하므로 다소 기계적으로 느껴질 수 있지만, 나중에 자동화도 가능합니다.

저는 코드 생성에 회의적이었지만, 촉박한 마감 때문에 Claude Sonnet 4.5를 띄워 몇 번의 야근을 해야 했습니다. 백로그가 사라졌습니다. 결과물을 검토하면서, 주니어나 중급 엔지니어가 Claude의 코드와 같은 PR을 작성해도 크게 실망하지 않을 것이라는 사실을 깨달았습니다. 밤 9시에 제가 할 수 있는 것에 비해 나쁜 시도가 아니었고, 프로젝트는 다시 궤도에 올랐습니다. 저는 전향적인 사용자가 되었습니다.

실제 질문들

그 실험 후에 당신은 궁금할 수 있습니다:

  • 출력이 당신 것이나 내 것만큼 좋을 수 있을까요? 아마도, 반복하고 피드백을 모을 무한한 시간이 있다면 가능할 겁니다.
  • 새로운 도구들을 사용해 품질을 크게 떨어뜨리지 않으면서 훨씬 빠르게 진행할 수 있을까요? 저는 그렇다고 생각합니다—단지 모든 줄을 읽을 필요가 없을 뿐이죠.

당신은 스스로 어려운 질문들을 스스로에게 물어야 할 것입니다. 예를 들어, 레거시 코드를 다룰 때마다 전체 솔루션을 매번 마이그레이션을 위해 다시 작성해야 할까요? 그것은 종종 시간 낭비가 될 것입니다. 새로운 도구는 우리가 출력물을 검증하는 방식에 있어 더 창의적이 될 것을 요구합니다.

근본적으로, 어느 시점에서는 누가 코드를 작성했는지는 중요하지 않습니다; 중요한 것은 코드가 동작한다는 것입니다. 어떻게 동작한다는 것을 알 수 있을까요? 그것은 또 다른 포스트의 주제로, 그곳에서 레거시 코드에 대한 제 경험을 더 공유하겠습니다.

다가올 내용

LLM을 활용한 코딩의 도전에 대한 즐거운 소개가 되었기를 바랍니다. 앞으로 몇 주 동안 기대하실 수 있는 내용은 다음과 같습니다:

  • 코드를 읽기 전에 문제를 발견하기
  • 코드를 더 빠르게 읽고 더 많은 문제를 포착하기
  • 동작을 검증하는 테스트 작성하기
  • 피드백 루프를 자동화하여 LLM이 스스로를 검토하도록 하기
  • 자신을 병목 현상에서 제거하기

다음 주에 더 많은 내용으로 뵙겠습니다.

~ Ben

Back to Blog

관련 글

더 보기 »