# 작동이 검증된 코드를 전달하는 것이 당신의 일이다 > Clean Markdown view of GeekNews topic #25179. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25179](https://news.hada.io/topic?id=25179) - GeekNews Markdown: [https://news.hada.io/topic/25179.md](https://news.hada.io/topic/25179.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-19T09:41:52+09:00 - Updated: 2025-12-19T09:41:52+09:00 - Original source: [simonwillison.net](https://simonwillison.net/2025/Dec/18/code-proven-to-work/) - Points: 31 - Comments: 4 ## Summary AI 보조 개발 환경이 확산되면서 **검증되지 않은 대규모 PR**을 제출하는 사례가 늘고 있습니다. 그러나 개발자의 본질적 임무는 코드를 많이 작성하는 것이 아니라 **작동이 입증된 코드**를 제공하는 일입니다. 이를 위해 수동 테스트와 자동 테스트를 모두 수행해야 하며, 코딩 에이전트 역시 자신이 만든 변경을 스스로 검증하도록 설정해야 합니다. 최종적인 책임은 인간 개발자에게 있으며, 검증 증거를 포함한 코드만이 진정한 품질을 갖습니다. ## Topic Body - **AI 보조 개발 환경**에서 미숙한 엔지니어가 **검증되지 않은 대규모 PR**을 제출하는 사례가 늘고 있음 - 개발자의 핵심 임무는 단순한 코드 작성이 아니라 **작동이 입증된 코드**를 제공하는 것임 - 이를 위해 **수동 테스트**와 **자동 테스트** 두 단계를 반드시 수행해야 함 - **코딩 에이전트** 역시 자신이 만든 변경 사항을 스스로 검증하도록 설정해야 함 - 최종적으로 **책임은 인간 개발자에게 있으며**, 검증 증거를 포함한 코드만이 진정한 가치가 있음 --- ### 검증되지 않은 코드 제출의 문제 - LLM 도구를 활용한 주니어 엔지니어가 **거대한 미검증 PR**을 제출하고 코드 리뷰에 의존하는 사례가 언급됨 - 이는 **무례하고 비효율적이며**, 개발자로서의 책임 방기 행위로 지적됨 - 소프트웨어 엔지니어의 역할은 단순한 코드 생산이 아니라 **작동이 입증된 코드 제공**임 - 검증되지 않은 코드는 검토자에게 부담을 전가하는 행위로 간주됨 ### 코드가 작동함을 입증하는 두 단계 - 첫 번째 단계는 **수동 테스트**로, 직접 코드가 올바르게 동작하는 것을 확인해야 함 - 시스템을 초기 상태로 설정하고, 변경을 적용한 뒤 결과를 검증하는 과정 필요 - 터미널 명령어와 출력 결과를 코드 리뷰 코멘트에 첨부하거나 **화면 녹화 영상**으로 증명 가능 - 정상 동작 후에는 **엣지 케이스 테스트**를 통해 문제점을 탐색해야 함 - 두 번째 단계는 **자동 테스트**로, LLM 도구의 발전 덕분에 필수 절차로 강조됨 - 변경 사항과 함께 자동 테스트를 포함해야 하며, 구현을 되돌리면 테스트가 실패해야 함 - 테스트 작성은 수동 테스트와 동일한 절차를 따르며, **테스트 하네스 통합 능력**이 중요함 - 자동 테스트만으로 충분하다고 판단해 수동 테스트를 생략하는 것은 잘못된 접근으로 지적됨 ### 코딩 에이전트의 역할과 검증 - 2025년 LLM 분야의 주요 흐름은 **코딩 에이전트의 급성장**으로, Claude Code와 Codex CLI 등이 대표적임 - 이들은 코드를 실행해 문제를 스스로 수정할 수 있음 - 코딩 에이전트도 **자신의 변경을 입증**해야 하며, 수동 및 자동 테스트를 수행해야 함 - CLI 도구의 경우 에이전트가 직접 실행하도록 학습시키거나, Click의 **CLIRunner** 같은 시스템으로 자동화 가능 - CSS 변경 시에는 **스크린샷 캡처**로 결과를 확인하도록 설정 가능 - 프로젝트에 기존 테스트가 있다면, 에이전트는 이를 확장하거나 패턴을 재사용함 - **테스트 코드의 구성과 품질**이 에이전트의 테스트 생성 품질에 직접적인 영향을 미침 - **테스트 코드에 대한 미적 감각**은 시니어 엔지니어를 구분하는 핵심 역량으로 언급됨 ### 인간의 책임과 코드의 가치 - **컴퓨터는 책임을 질 수 없으며**, 인간이 그 역할을 맡아야 함 - LLM이 대규모 패치를 생성하는 것은 더 이상 가치 있는 일이 아님 - 진정한 가치는 **작동이 입증된 코드**를 제공하는 데 있음 - PR 제출 시 반드시 코드가 올바르게 작동함을 보여주는 **증거를 포함**해야 함 ## Comments ### Comment 47997 - Author: ethanhur - Created: 2025-12-19T12:02:08+09:00 - Points: 5 매우 공감합니다. 현재 PR 방식의 코드의 책임은 메인테이너와 리뷰어들에게 전가되는 구조입니다. 리뷰하지 않은 LLM 코드를 제출하는 사람에게 disadvantage가 없습니다. Google 코드베이스에 기여해보면 컨트리뷰터의 credit 같은 걸 측정하던데, 다른 오픈소스 / 기업도 이런 걸 도입하게 될 거 같습니다. 신뢰가 더욱 중요한 자산이 되지 않을까 싶습니다. ### Comment 48020 - Author: roxie - Created: 2025-12-19T21:44:55+09:00 - Points: 1 - Parent comment: 47997 - Depth: 1 오 그런 개념을 쓰는군요 구글은 ### Comment 48124 - Author: tested - Created: 2025-12-22T13:34:54+09:00 - Points: 1 > [바이브 엔지니어링](https://news.hada.io/topic?id=23521) ### Comment 47982 - Author: neo - Created: 2025-12-19T09:41:52+09:00 - Points: 2 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46313297) - 요즘 자주 보이는 **우울한 일화**가 있음. LLM 도구로 힘을 얻은 주니어 엔지니어가 거대한, 테스트되지 않은 PR을 동료나 오픈소스 메인테이너에게 던지고, 코드 리뷰가 나머지를 처리해줄 거라 기대하는 경우임. 더 나쁜 건 이런 행동이 주니어뿐 아니라 시니어 개발자에게서도 나온다는 점임 - 어제와 오늘 내가 딱 그런 일을 했음. 우리 팀이 버그 리포트를 받았는데 외부 벤더 문제라고 판단했음. 그런데 벤더가 되돌려보내며 우리 쪽 문제라고 하더라. 그래서 Codex로 살펴보게 했더니 문제를 찾아 PR을 준비했음. 나는 직접 리뷰나 테스트를 하지 않고 팀에게 검증을 맡겼음. 그 과정이 팀이 LLM을 **업무 도구로 활용**하도록 학습시키는 데 도움이 되었음 - 최근 이틀 동안 **비개발자 팀원** 두 명이 AI 에이전트에게 모바일 버그 수정법을 물어보고, 그 답변을 티켓의 주요 내용으로 올려버림. 결국 내가 그걸 다 읽고 실제 요구사항을 다시 파악해야 했음 - “시니어” 타이틀을 달고도 주니어 같은 행동을 하는 사람이 많음. 요즘은 졸업 2년 차만 돼도 시니어로 불리니까 생기는 현상 같음 - 규칙을 무시하거나 우회할 수 있는 개발자가 가장 위험함. 예전에 만난 **10x 개발자**들이 떠오름. 규칙을 무시하고 기능만 쏟아내면, 결국 다른 사람들이 뒤처리를 하게 됨 - 코드 리뷰 중 주니어 개발자는 어디에 있는지 궁금함. 리뷰에 참여하지 않는다면, 그들의 코드 품질에 책임감을 느끼기 어려움 - 좋은 PR 작성법은 AI 생성 코드뿐 아니라 모든 경우에 적용됨. 나는 PR 설명을 쓸 때 현재 동작 방식, 변경 이유, 변경 내용을 순서대로 정리함. 테스트 방법과 스크린샷, **E2E 테스트 명령어**까지 포함해 리뷰어의 부담을 줄임. 이렇게 하면 비동기 협업이나 시차가 있는 팀에도 도움이 됨 - 리뷰를 요청하기 전에 스스로 한 번 더 검토함. 사소한 오타나 로그 제거를 미리 처리하면 리뷰어의 시간을 절약할 수 있음. Copilot 리뷰도 이런 부분은 잘 잡아줌 - 설명을 꼼꼼히 써도 아무도 읽지 않는 경우가 많음. 그래도 계속 쓰는 이유는 내 **책임감** 때문임 - AI가 도운 PR이든 아니든, 테스트 증거와 검증이 포함되어야 함 - 예전엔 설명을 길게 썼지만, 아무도 안 읽는 걸 깨달음. 핵심만 **불릿 포인트**로 요약하는 게 더 효과적이었음 - 우리 팀의 PR 템플릿에는 티켓 번호, 요청 설명, 현재 상태, 변경 후 상태, 그리고 ‘mood gif’까지 포함되어 있음 - 엔지니어의 본질은 요구사항을 이해하고, 논리적 흐름으로 변환하며, **트레이드오프를 조율**하고 결과에 책임지는 것임. 코드 생성이나 무작위 PR 제출은 이런 기본이 결여된 증상임. 코딩 에이전트는 오히려 엔지니어링의 본질을 다시 일깨워주는 계기임 - [이 글](https://read.engineerscodex.com/p/how-one-line-of-code-caused-a-60)을 보면, 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](https://github.com/WireGuard/wireguard-android/pull/82), [#80](https://github.com/WireGuard/wireguard-android/pull/80)을 보면, AI가 복붙한 답변이 그대로 남아 있음. “files changed” 탭을 보면 혼란스러움 - 친구가 11명짜리 스타트업에서 일하는데, CTO가 새벽 3시에 1만 줄짜리 코드를 main에 바로 푸시함. 탐색 단계에선 괜찮지만, 안정화 단계에선 **끔찍한 리스크**임 - “코드를 증명된 상태로 전달하는 게 일이다”라는 말에 동의하지 않음. 진짜 일은 **비즈니스 문제 해결**임. 물론 대부분의 경우 그게 코드로 이어지지만, 구분은 중요함 - 하지만 코드의 정확성을 증명하는 건 비즈니스 문제 해결의 일부임. 별개의 일이 아님 - 요구사항을 만족하지 않는 코드를 전달해서 비즈니스 문제를 해결할 수는 없음 - 문제를 해결하되, 새로운 문제를 만들지 않는 게 중요함. 그래서 **보안성과 안정성**이 필요함 - 아직 경력이 짧아서 그런지, 검증되지 않은 코드로 어떻게 문제를 해결한다는 건지 이해가 안 됨 - 결국 모든 직업은 문제 해결이 목적임. 다만 우리는 컴퓨터를 통해 그걸 하는 것뿐임 - 예전 직장에서 일본의 **고품질 하드웨어 제조사**에서 일했는데, QA 부서가 버그를 발견하면 제품 출시가 중단됐음. 그래서 각 개발 부서가 자체 QC 팀을 만들어 사전 테스트를 강화했음. 결과적으로 소프트웨어가 매우 철저히 검증되었음 - “get dinged”가 무슨 뜻인지 궁금함. 이런 구조는 오히려 변경을 두려워하게 만들 수도 있음 - 요즘은 일의 본질이 **티켓을 닫는 것**으로 변했음. 코드 품질은 통계에 잡히지 않으니 중요하지 않게 됨. 나는 이런 시스템에 참여하지 않음. 이제는 장인정신이 사라지고, 모두가 값싼 합판과 본드를 원함 - LLM을 전면 도입하고 모두가 쓰길 기대하는 순간, 소프트웨어 엔지니어링은 더 이상 진지한 공학이 아님 - 그런 태도를 비판하는 사람에게 “그럼 당신은 정부 보조금으로 사는가?”라고 묻는 이들도 있음 - “증명된 코드”의 의미가 문제임. LLM이 만든 테스트를 붙여서 거대한 PR을 제출하는 경우도 있음. 나도 개인 프로젝트에서는 **vibe coding**을 하지만, 팀 단위로 그렇게 하는 건 나쁜 습관임. 엔지니어를 고용하는 이유는 그들의 전문성을 사기 위함임 - 그래서 나는 **수동 테스트**를 강조함. 스크린샷이나 동영상으로 실제 동작을 보여주는 것만으로도 큰 신뢰를 줄 수 있음