▲
GN⁺ 4달전 | parent | ★ favorite | on: 작동이 검증된 코드를 전달하는 것이 당신의 일이다(simonwillison.net)
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을 하지만, 팀 단위로 그렇게 하는 건 나쁜 습관임. 엔지니어를 고용하는 이유는 그들의 전문성을 사기 위함임

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