▲

작동이 검증된 코드를 전달하는 것이 당신의 일이다

 (simonwillison.net)
17P by GN⁺ 18시간전 | ★ favorite | 댓글 3개
  • AI 보조 개발 환경에서 미숙한 엔지니어가 검증되지 않은 대규모 PR을 제출하는 사례가 늘고 있음
  • 개발자의 핵심 임무는 단순한 코드 작성이 아니라 작동이 입증된 코드를 제공하는 것임
  • 이를 위해 수동 테스트와 자동 테스트 두 단계를 반드시 수행해야 함
  • 코딩 에이전트 역시 자신이 만든 변경 사항을 스스로 검증하도록 설정해야 함
  • 최종적으로 책임은 인간 개발자에게 있으며, 검증 증거를 포함한 코드만이 진정한 가치가 있음

검증되지 않은 코드 제출의 문제

  • LLM 도구를 활용한 주니어 엔지니어가 거대한 미검증 PR을 제출하고 코드 리뷰에 의존하는 사례가 언급됨
    • 이는 무례하고 비효율적이며, 개발자로서의 책임 방기 행위로 지적됨
  • 소프트웨어 엔지니어의 역할은 단순한 코드 생산이 아니라 작동이 입증된 코드 제공임
    • 검증되지 않은 코드는 검토자에게 부담을 전가하는 행위로 간주됨

코드가 작동함을 입증하는 두 단계

  • 첫 번째 단계는 수동 테스트로, 직접 코드가 올바르게 동작하는 것을 확인해야 함
    • 시스템을 초기 상태로 설정하고, 변경을 적용한 뒤 결과를 검증하는 과정 필요
    • 터미널 명령어와 출력 결과를 코드 리뷰 코멘트에 첨부하거나 화면 녹화 영상으로 증명 가능
    • 정상 동작 후에는 엣지 케이스 테스트를 통해 문제점을 탐색해야 함
  • 두 번째 단계는 자동 테스트로, LLM 도구의 발전 덕분에 필수 절차로 강조됨
    • 변경 사항과 함께 자동 테스트를 포함해야 하며, 구현을 되돌리면 테스트가 실패해야 함
    • 테스트 작성은 수동 테스트와 동일한 절차를 따르며, 테스트 하네스 통합 능력이 중요함
    • 자동 테스트만으로 충분하다고 판단해 수동 테스트를 생략하는 것은 잘못된 접근으로 지적됨

코딩 에이전트의 역할과 검증

  • 2025년 LLM 분야의 주요 흐름은 코딩 에이전트의 급성장으로, Claude Code와 Codex CLI 등이 대표적임
    • 이들은 코드를 실행해 문제를 스스로 수정할 수 있음
  • 코딩 에이전트도 자신의 변경을 입증해야 하며, 수동 및 자동 테스트를 수행해야 함
    • CLI 도구의 경우 에이전트가 직접 실행하도록 학습시키거나, Click의 CLIRunner 같은 시스템으로 자동화 가능
    • CSS 변경 시에는 스크린샷 캡처로 결과를 확인하도록 설정 가능
  • 프로젝트에 기존 테스트가 있다면, 에이전트는 이를 확장하거나 패턴을 재사용함
    • 테스트 코드의 구성과 품질이 에이전트의 테스트 생성 품질에 직접적인 영향을 미침
    • 테스트 코드에 대한 미적 감각은 시니어 엔지니어를 구분하는 핵심 역량으로 언급됨

인간의 책임과 코드의 가치

  • 컴퓨터는 책임을 질 수 없으며, 인간이 그 역할을 맡아야 함
    • LLM이 대규모 패치를 생성하는 것은 더 이상 가치 있는 일이 아님
  • 진정한 가치는 작동이 입증된 코드를 제공하는 데 있음
    • PR 제출 시 반드시 코드가 올바르게 작동함을 보여주는 증거를 포함해야 함
▲
ethanhur 16시간전  [-]

매우 공감합니다. 현재 PR 방식의 코드의 책임은 메인테이너와 리뷰어들에게 전가되는 구조입니다. 리뷰하지 않은 LLM 코드를 제출하는 사람에게 disadvantage가 없습니다.

Google 코드베이스에 기여해보면 컨트리뷰터의 credit 같은 걸 측정하던데, 다른 오픈소스 / 기업도 이런 걸 도입하게 될 거 같습니다. 신뢰가 더욱 중요한 자산이 되지 않을까 싶습니다.

답변달기
▲
roxie 6시간전  [-]

오 그런 개념을 쓰는군요 구글은

답변달기
▲
GN⁺ 18시간전  [-]
Hacker News 의견들

  • 요즘 자주 보이는 우울한 일화가 있음. LLM 도구로 힘을 얻은 주니어 엔지니어가 거대한, 테스트되지 않은 PR을 동료나 오픈소스 메인테이너에게 던지고, 코드 리뷰가 나머지를 처리해줄 거라 기대하는 경우임. 더 나쁜 건 이런 행동이 주니어뿐 아니라 시니어 개발자에게서도 나온다는 점임

    • 어제와 오늘 내가 딱 그런 일을 했음. 우리 팀이 버그 리포트를 받았는데 외부 벤더 문제라고 판단했음. 그런데 벤더가 되돌려보내며 우리 쪽 문제라고 하더라. 그래서 Codex로 살펴보게 했더니 문제를 찾아 PR을 준비했음. 나는 직접 리뷰나 테스트를 하지 않고 팀에게 검증을 맡겼음. 그 과정이 팀이 LLM을 업무 도구로 활용하도록 학습시키는 데 도움이 되었음
    • 최근 이틀 동안 비개발자 팀원 두 명이 AI 에이전트에게 모바일 버그 수정법을 물어보고, 그 답변을 티켓의 주요 내용으로 올려버림. 결국 내가 그걸 다 읽고 실제 요구사항을 다시 파악해야 했음
    • “시니어” 타이틀을 달고도 주니어 같은 행동을 하는 사람이 많음. 요즘은 졸업 2년 차만 돼도 시니어로 불리니까 생기는 현상 같음
    • 규칙을 무시하거나 우회할 수 있는 개발자가 가장 위험함. 예전에 만난 10x 개발자들이 떠오름. 규칙을 무시하고 기능만 쏟아내면, 결국 다른 사람들이 뒤처리를 하게 됨
    • 코드 리뷰 중 주니어 개발자는 어디에 있는지 궁금함. 리뷰에 참여하지 않는다면, 그들의 코드 품질에 책임감을 느끼기 어려움

  • 좋은 PR 작성법은 AI 생성 코드뿐 아니라 모든 경우에 적용됨. 나는 PR 설명을 쓸 때 현재 동작 방식, 변경 이유, 변경 내용을 순서대로 정리함. 테스트 방법과 스크린샷, E2E 테스트 명령어까지 포함해 리뷰어의 부담을 줄임. 이렇게 하면 비동기 협업이나 시차가 있는 팀에도 도움이 됨

    • 리뷰를 요청하기 전에 스스로 한 번 더 검토함. 사소한 오타나 로그 제거를 미리 처리하면 리뷰어의 시간을 절약할 수 있음. Copilot 리뷰도 이런 부분은 잘 잡아줌
    • 설명을 꼼꼼히 써도 아무도 읽지 않는 경우가 많음. 그래도 계속 쓰는 이유는 내 책임감 때문임
    • AI가 도운 PR이든 아니든, 테스트 증거와 검증이 포함되어야 함
    • 예전엔 설명을 길게 썼지만, 아무도 안 읽는 걸 깨달음. 핵심만 불릿 포인트로 요약하는 게 더 효과적이었음
    • 우리 팀의 PR 템플릿에는 티켓 번호, 요청 설명, 현재 상태, 변경 후 상태, 그리고 ‘mood gif’까지 포함되어 있음

  • 엔지니어의 본질은 요구사항을 이해하고, 논리적 흐름으로 변환하며, 트레이드오프를 조율하고 결과에 책임지는 것임. 코드 생성이나 무작위 PR 제출은 이런 기본이 결여된 증상임. 코딩 에이전트는 오히려 엔지니어링의 본질을 다시 일깨워주는 계기임

    • 이 글을 보면, 1줄의 코드가 6천만 달러 손실을 낸 사례가 있음. 코드 이해 없이 AI가 만든 1만 줄짜리 PR은 잠재적 재앙임
    • 현실적으로 기업은 품질보다 마케팅과 수익성을 중시함. 고품질 제품보다 ‘프리미엄’ 라벨이 붙은 제품이 더 잘 팔림. 결국 엔지니어링보다 ‘팔리는 것’이 우선되는 구조임
    • 하지만 조직이 “AI 써서 3일 안에 기능 완성하라, 아니면 HR 면담”이라고 압박하면, 이상적인 엔지니어링 원칙을 지키기 어렵다는 게 문제임

  • 테스트는 필요하지만 충분하지 않음. 코드를 논리적으로 검증해야 함. 테스트는 특정 입력과 환경에서만 정상 동작을 입증할 뿐임

    • 나도 같은 생각임. 잘 작동하는 코드라도 여전히 형편없을 수 있음
    • “증명”보다는 “시연(demonstrate) ”이라는 표현이 더 적절함. 테스트는 특정 사례에서의 증거일 뿐임
    • 단순히 테스트만 믿지 않고, 직접 여러 방식으로 앱을 깨뜨려보려 함. 그 과정에서 더 나은 코드로 개선하게 됨
    • 대부분의 코드는 형식적으로 증명할 수 없으니, property-based testing 같은 접근이 유용할 것 같음
    • 100% 테스트 커버리지를 달성해도 코드가 견고하지 않으면 의미 없음

  • 나는 테스트를 의무로 하지 않음. 단지 코드가 실제로 작동하는 걸 보고 싶어서 함. 코드가 돌아가는 걸 보고 흥분되지 않는다면, 이 직업은 맞지 않음

  • LLM 덕분에 주니어가 거대한 PR을 던진다는 이야기를 들었는데, 우리 조직에서는 그런 일은 아직 없음

    • 거대한 PR은 아니지만, 개발자가 이해하지 못한 LLM 생성 코드는 자주 봄
    • 우리 조직에서도 그런 사례가 있음. 문제는 다음과 같음
      • 에이전트가 이전 피드백을 되돌림
      • 코드베이스 표준을 따르지 않음
      • 기존 솔루션을 재발명함
      • PR 피드백에 에이전트 출력으로 응답함
      • 10~20줄 수정이면 될 걸 5만 줄 PR로 제출함
      • 테스트 부족, 에러 처리 미흡
    • 예전부터 낮은 품질의 PR을 제출하던 사람들이 LLM 덕분에 단지 더 빨리 제출할 뿐임
    • WireGuard Android PR #82, #80을 보면, AI가 복붙한 답변이 그대로 남아 있음. “files changed” 탭을 보면 혼란스러움
    • 친구가 11명짜리 스타트업에서 일하는데, CTO가 새벽 3시에 1만 줄짜리 코드를 main에 바로 푸시함. 탐색 단계에선 괜찮지만, 안정화 단계에선 끔찍한 리스크임

  • “코드를 증명된 상태로 전달하는 게 일이다”라는 말에 동의하지 않음. 진짜 일은 비즈니스 문제 해결임. 물론 대부분의 경우 그게 코드로 이어지지만, 구분은 중요함

    • 하지만 코드의 정확성을 증명하는 건 비즈니스 문제 해결의 일부임. 별개의 일이 아님
    • 요구사항을 만족하지 않는 코드를 전달해서 비즈니스 문제를 해결할 수는 없음
    • 문제를 해결하되, 새로운 문제를 만들지 않는 게 중요함. 그래서 보안성과 안정성이 필요함
    • 아직 경력이 짧아서 그런지, 검증되지 않은 코드로 어떻게 문제를 해결한다는 건지 이해가 안 됨
    • 결국 모든 직업은 문제 해결이 목적임. 다만 우리는 컴퓨터를 통해 그걸 하는 것뿐임

  • 예전 직장에서 일본의 고품질 하드웨어 제조사에서 일했는데, QA 부서가 버그를 발견하면 제품 출시가 중단됐음. 그래서 각 개발 부서가 자체 QC 팀을 만들어 사전 테스트를 강화했음. 결과적으로 소프트웨어가 매우 철저히 검증되었음

    • “get dinged”가 무슨 뜻인지 궁금함. 이런 구조는 오히려 변경을 두려워하게 만들 수도 있음

  • 요즘은 일의 본질이 티켓을 닫는 것으로 변했음. 코드 품질은 통계에 잡히지 않으니 중요하지 않게 됨. 나는 이런 시스템에 참여하지 않음. 이제는 장인정신이 사라지고, 모두가 값싼 합판과 본드를 원함

    • LLM을 전면 도입하고 모두가 쓰길 기대하는 순간, 소프트웨어 엔지니어링은 더 이상 진지한 공학이 아님
    • 그런 태도를 비판하는 사람에게 “그럼 당신은 정부 보조금으로 사는가?”라고 묻는 이들도 있음

  • “증명된 코드”의 의미가 문제임. LLM이 만든 테스트를 붙여서 거대한 PR을 제출하는 경우도 있음. 나도 개인 프로젝트에서는 vibe coding을 하지만, 팀 단위로 그렇게 하는 건 나쁜 습관임. 엔지니어를 고용하는 이유는 그들의 전문성을 사기 위함임

    • 그래서 나는 수동 테스트를 강조함. 스크린샷이나 동영상으로 실제 동작을 보여주는 것만으로도 큰 신뢰를 줄 수 있음
답변달기