Ask HN: 이해하지 못하는 AI 작성 코드를 배포하는 상황에 어떻게 대처하시나요?

Hacker News 의견들 bitwizeshift: LLM에 설계를 맡기지 않고, 직접 만든 설계의 구현만 맡김. 추상화 계층과 각 구성 요소의 책임, 상호작용을 UML 수준에서 정한 뒤 빈칸을 채우게 함. 개별 구현을 전부 몰라도 시스템이 어떻게 작동하는지는 이해할 수 있음. 프롬프트와 지침을 아무리 줘도 LLM은 좋은 추상화를 만드는 데 서툴고, 요구사항이 바뀔수록 큰 리팩터링이 필요한 코드를 만들기 쉬움. 처음 몇 시간 설계하고 문서화하면 토큰도 줄이고, 이후 변경도 정해 둔 추상화 안에서 처리하기 쉬워짐. 추상화만 올바르면 개별 구현은 나중에 교체하면 됨. fasterik: 기본적인 소프트웨어 설계 원칙이라 숙련된 개발자라면 당연히 이렇게 접근할 줄 알았는데, 굳이 강조해야 한다는 게 놀라움. 어려움을 겪는 쪽이 실제 개발 과정을 못 본 주니어 위주인지, 시니어에게까지 번진 현상인지 궁금함. smashed: 코딩 능력으로 칭찬받는 Opus 5.5에서도 형편없거나 빠진 추상화를 계속 발견함. 새 요구사항마다 여기저기 덧대면 되니 모델 입장에서는 추상화가 필요하지 않고, 인간 검토자를 만족시키려고 할 때만 만드는 셈임. d1algo12: LLM은 설계에도 분명 도움이 되며, 자기 머리 외에는 최고의 아이디어 탐색 도구임. ChrisMarshallNY: 테스트를 아주 많이 함. 보통 LLM과 상호작용하며 테스트하고, 코딩 시간이 줄어든 만큼 직접 작성하던 때보다 더 많이 검증함. 코딩 자체의 오류보다는 구현이 의도와 어긋난 부분을 찾게 됨. 완벽하다고 확신했던 오래된 내 코드에서도 LLM이 여러 결함을 찾아냄. 누구도 완벽하지 않으니 신뢰하되 검증해야 함. SimianSci: 만드는 시간과 비용은 줄었지만 검증과 테스트라는 새 작업이 잔뜩 생긴 셈 아닌가? 설계 과정에서 시간과 노력을 쓰는 위치가 바뀐 것 말고 무엇을 얻었는지 궁금함. onion2k: 프로젝트의 안전장치를 별도 저장소의 재사용 가능한 지침으로 옮겨, 새 프로젝트에도 쉽게 적용하도록 함. 가능한 여러 단계의 테스트를 넣었고, 현재 검사는 여기에 정리돼 있음. 목표는 변경이 기존 기능을 망가뜨리지 않았다는 확신임. 잘못된 변경이나 형편없는 코드일 수는 있어도 배포로 시스템이 터지지는 않게 하려는 것이며, 여러 게임 프로젝트에서 꽤 잘 작동함. michaelt: 자동화 테스트를 잔뜩 추가하면 검토할 코드도 늘어남. AI가 만든 50줄짜리 수정 검...