Ask HN: 이해하지 못하는 AI가 작성한 코드를 배포하는 방법은?
Ask HN: How to deal with shipping AI-written code you don't understand?
저는 은퇴했고, 진행 상황에 대해 답할 사람은 저뿐입니다. 저는 품질을 속도보다 중시하는 고집 센 사람이지만, 발전을 싫어하는 것은 아닙니다. 오늘 아침 컴파일러의 'C' 프론트엔드에 대한 예비 결과를 받았는데, 동일한 소스 코드에 대해 clang -O2 대비 최대 1,312배의 속도 향상을 확인했습니다. 체크섬이 일치하므로 올바르게 작동했음을 알지만, Hacker News에서는 제 게시물이 차단/죽은 것으로 처리되어 관심을 받지 못하고 있습니다. C++ 프론트엔드가 준비되면 다른 곳에서 발표할 예정입니다.
AI가 작성한 코드를 이해하지 못할 때는 코드를 직접 검토하고 테스트를 철저히 하며, 가능하면 AI에게 설명을 요청하는 것이 중요합니다. 또한 코드의 복잡성을 줄이고 작은 단위로 나누어 이해하기 쉽게 만드는 것도 도움이 됩니다.
저는 AI가 생성한 코드를 사용할 때 항상 코드 리뷰 프로세스를 거칩니다. 동료와 함께 코드를 검토하고, 특히 보안 및 성능 측면에서 문제가 없는지 확인합니다. 이해하지 못하는 부분은 AI에게 질문하여 설명을 듣고, 필요하면 코드를 수정합니다.
AI가 작성한 코드를 배포하는 것은 위험할 수 있습니다. 따라서 저는 AI가 생성한 코드를 프로덕션에 사용하기 전에 반드시 단위 테스트와 통합 테스트를 작성하고, 코드의 동작을 완전히 이해할 때까지 시간을 투자합니다. 이해하지 못한 코드는 배포하지 않는 것이 원칙입니다.
AI가 생성한 코드를 이해하지 못하더라도, 코드의 목적과 입력/출력, 경계 조건을 명확히 문서화하면 유지보수에 도움이 됩니다. 또한 정적 분석 도구와 린터를 사용하여 잠재적인 문제를 찾아내는 것이 좋습니다.
때로는 AI가 작성한 코드를 완전히 이해하는 것이 비현실적일 수 있습니다. 그럴 때는 코드를 블랙박스로 취급하고, 철저한 테스트와 모니터링을 통해 예상치 못한 동작을 감지하는 전략을 사용합니다. 하지만 가능하면 코드를 이해하려고 노력하는 것이 장기적으로 더 안전합니다.
HN 토론
114- ChrisMarshallNY
테스트.
아주아주 많은 테스트. 보통 LLM과 상호작용하며 테스트한다. 이제 코딩에 쓰는 시간이 줄어서 테스트에 더 많은 시간을 쓸 수 있게 됐다.
내 경험상 LLM과 함께할 때 내 코드로 할 때보다 테스트를 더 많이 한다. 코딩 오류는 찾지 못하지만 구현 오류는 찾아낸다.
덧붙이자면: 내가 작성한 정말 성숙한 코드에 LLM을 돌려봤는데, '완벽하다'고 맹세할 수 있었던 코드에서 여러 문제를 발견했다.
완벽한 사람은 없다. 신뢰하되, 검증하라.
- trezm
이걸 가지고 놀아보고 있다 https://getchronosphere.com. 거대한 덩어리 대신 일관된 여정으로 PR을 (재)구성하려고 시도한다. 지금까지는 어느 정도 도움이 되었고 계속 개선되고 있다.
- skeledrew
기술적으로 보면 그냥 역할 변화다. 이제 당신은 개발자가 아니라 프로젝트 매니저 같은 역할이다. 프로젝트 매니저의 일은 코드를 이해하는 게 아니라, 코드가 해야 할 일을 하고 하지 말아야 할 일을 하지 않도록 보장하는 것이다. 그리고 개발자 등이 막힘없이 잘 일하도록 보장하는 것이다. 새로운 역할을 받아들여라.
- 4ndrewl
이건 모든 제품 매니저가 매일 느끼는 감정이다.
LLM 프롬프터로서 제품을 출시한다면, 당신의 결과물은 소프트웨어 엔지니어의 결과물보다 제품 매니저의 결과물에 더 가깝다.
- spacedcowboy
나는 '작동하면 됐다'는 생각에 서서히 동의하게 되고 있다. 예전에도 동료들의 작업을 일일이 검토한 적은 없었다. 그저 그들이 잘 해냈을 거라고 믿었다.
그렇다고 해서 LLM을 맹목적으로 신뢰한다는 건 아니다. 내 프로젝트는 자동 벡터화 컴파일러다. 수많은 테스트를 작성하게 하고, 실제로 복잡한 프로그램들을 컴파일하게 한다. 릴리스 전에 5가지 아키텍처에서 문자 그대로 몇 시간이 걸리는 '게이트'를 실행하게 한다. 이 코드가 테스트되었다고 말하는 건... 엄청난 절제된 표현이다.
도움이 되는 것은 긴 기획 세션, 세부 사항 파고들기, 코너 케이스 파악, 테스트 케이스 설계, 즉 노력과 수고다. 일단 그게 끝나면 밤새 작업하게 두고 주요 프로덕션 기능을 완성하게 하는 게 더 쉽다.
여전히 코드를 검토하지만, 솔직히 모든 것을 검토했다고 말할 수는 없다. 복잡한 체크인에서는 가끔 뭔가를 놓친다. 체크인을 작고 한정적으로 유지하려고 하지만, '망가뜨리지 말 것' 규칙과 함께 관리하기가 쉽지 않을 때도 있다.
결국: 이 일을 약 6개월째 하고 있는데 지금까지는 잘 풀려왔다. 뭐랄까, 시간이 지나면서 동료의 특이한 습관에 익숙해지는 것과 비슷하다.
내 경험상 코드 품질은 상당히 높다고 말하겠다. 아마도 기획 단계에서 미리 쏟은 노력 덕분일지도 모르지만, 사람들이 불평하는 '슬롭'은 겪지 않는 것 같다. 사람마다 다를 수 있다.
- solatic
AI 이전의 프린시펄 엔지니어 생활과 크게 다르지 않다. 기술적으로는 여러 엔지니어가 각자 시스템에서 하는 일을 감독하지만, 모든 코드를 직접 검토하는 건 불가능하다. 인간의 코드 리뷰가 프로덕션에 배포되는 버그의 수와 심각성을 줄여주지만 없애지는 못한다는 것을 잘 안다. 머릿속에 저수준 세부 사항은 없고 고수준 세부 사항만 있다. 이 엔지니어들이 서로 발을 밟지 않고 상호작용하는 방식을 설계한다.
인간이 저수준 시스템을 이해한다고 믿는 시스템에서 고급 계산기를 믿는 시스템으로 옮긴 것이 옳았는지는 시간이 말해줄 것이다. 하지만 지금까지는 잘 작동하고 있다.
- cadamsdotcom
테스트 주도 개발과 테스트 피라미드.
에이전트가 테스트를 작성했고, 결정적으로 통과시키기 위한 작업을 시작하기 전에 테스트가 실패하는 것을 목격했다면, 큰 확신을 가질 수 있다.
자신의 작업을 검토하기도 더 쉽다. 테스트와 프로덕션 코드는 서로를 비추는 경향이 있어 훨씬 완전한 그림을 준다. 프로덕션 코드가 혼란스러운가? 잠시 그 테스트를 읽어보고 다시 돌아오라.
빌드 과정에 함께 있었고, 트랜스크립트를 보며 가끔 확인했다면 변경 사항을 이해하기도 더 쉽다. 주 작업일 필요는 없다. 두 번째 모니터에 띄워두면 자연스럽게 눈에 들어온다.
그리고 마지막으로, 테스트 주도 개발에 더해, 에이전트가 (첫 번째 테스트 주도 개발 주기 전에) 수행할 작업을 포괄하는 엔드투엔드 테스트를 먼저 구축하게 하라. 그 테스트가 초록색이 되면(테스트 주도에서 '통과 중'을 뜻하는 말) 작업이 끝난 것이고 마음대로 정리할 수 있다.
출시 전에 가지고 놀아보고, 정말 좋게 만들어라. 기술 부채를 청산하고 UI를 완벽하게 만드는 것이 이렇게 쉬운 적은 없었다.
결국 PR로 패키징할 준비가 될 것이다!
이제 에이전트를 활용하고 창의력을 발휘할 수 있다. 동료들이 당신의 작업을 리뷰하고 싶어 안달 나게 만들어라. Loom 비디오를 만들어 그들을 안내하는 것을 고려하라. 커밋 시리즈로 재구성하는 것을 고려하라. 에이전트에게는 몇 초밖에 걸리지 않고 인간에게는 이야기를 들려줄 수 있다. 어쩌면 당신의 고군분투에 따라 순서를 정하고 싶을 수도 있고, 각 커밋마다 다른 계층이 드러나게 보여주는 것이 더 나을 수도 있다 - […]
- vjerancrnjak
형식 검증. 통합된 언어를 선택하고 관련 사후 조건을 증명하라.
AI는 아직 불가능한 상태를 표현 불가능하게 만드는 코드를 작성하는 방법조차 모르므로 테스트는 도움이 되지 않는다.