NASA의 10가지 코딩 표준이 AI가 만든 쓰레기 코드(slop)의 해결책이 될까?
Is NASA’s 10-rule coding standard actually the answer to AI slop?
핵심 요약
AI가 생성한 코드의 가독성과 유지보수 문제를 해결하기 위해 NASA의 엄격한 코딩 표준을 도입하자는 제안.
- 코드 품질 논쟁 — AI가 생성한 코드가 작동은 하지만 가독성이 떨어져 유지보수가 어렵다는 문제 제기.
- NASA 코딩 표준 — 함수 길이 제한, 어설션 사용 등 안전 중심의 10가지 규칙을 AI 코드에 적용하자는 아이디어.
- AI 작성 의혹 — 본문의 문체와 구조가 AI가 쓴 것 같다는 커뮤니티의 냉소적인 반응.
- 실질적 해결책 — 코드 규칙 강제보다는 어설션 밀도와 함수 계약(contract) 명시가 더 중요하다는 의견.
저는 AI 엔지니어로 일하면서 주로 LLM 파이프라인 같은 것들을 구축합니다. 그런데 최근 들어 이 모델들이 만들어내는 코드의 품질 때문에 정말 불안함을 느끼고 있습니다.
코드가 고장 나서가 아닙니다. 그랬다면 오히려 다루기 쉬웠겠죠. 문제는 코드가 작동은 하는데, 완전히 읽을 수 없다는 겁니다.
예를 들어 Claude나 GPT에게 데이터 파이프라인을 만들어달라고 하면 500줄짜리 코드를 주는데, 어설션은 하나도 없고, process_data()라는 함수가 11가지 일을 다 하고 있고, 어디에도 에러 핸들링이 없습니다. 테스트할 때는 잘 돌아가죠. 배포도 합니다. 그러고 나서 2달 뒤에 디버깅을 해야 하면, 사실상 고고학을 하는 셈이 됩니다.
어쨌든, 지난주에 관련 자료를 찾아보다가 예전 논문을 하나 발견했습니다. Gerard Holzmann이 2006년에 쓴 NASA의 'Power of Ten'입니다. 안전이 중요한 C 코드, 그러니까 우주선 관련 코드를 위해 작성된 것이죠. 그런데 이게 여전히 얼마나 관련성이 있는지 계속 생각하게 되더군요.
기억에 남는 규칙들은 이렇습니다:
- 함수는 약 60줄을 넘지 말 것 (한 페이지, 하나의 목적)
- 함수당 최소 2개의 어설션(assertion) 사용
- 반환 값을 항상 확인할 것 — AI는 이걸 계속 건너뜁니다
- 첫날부터 컴파일러 경고 제로
- 재귀 금지, 제한된 루프만 사용
전체 철학은 기본적으로 이렇습니다: 코드는 단순히 기능적인 것을 넘어 기계적으로 검증 가능해야 한다. 도구나 밤 11시에 피곤한 사람이 봐도 안전하다는 것을 증명할 수 있어야 한다는 거죠.
글쎄요, 저는 이게 정확히 AI가 생성한 코드에 필요한 것이라고 느낍니다. 우리는 코드가 작성되는 방식을 완전히 바꿨지만, 그것을 검토하는 방식은 제대로 업데이트하지 않았거든요.
물론 규칙 중 일부는 C 언어에 특화되어 있어 파이썬이나 현대적인 스택에 직접 적용하기 어렵습니다. 동적 메모리 할당 금지 같은 규칙은 ML 작업을 한다면 사실상 불가능하죠. 하지만 그 정신은 유효합니다.
제 개인적인 생각은 이렇습니다: 만약 AI가 코드를 썼는데 당신이 그것을 검증할 수 없다면, 당신은 실제로 그 코드를 소유한 게 아닙니다. 그냥 호스팅하면서 잘 되길 바라고 있는 것뿐이죠.
혹시 직장에서 LLM이 생성한 코드에 대해 더 엄격한 코딩 표준을 실제로 적용해 본 분 계신가요? 그게 차이를 만들었는지, 아니면 경영진이 그냥 속도를 늦추는 것으로만 보는지 궁금합니다.
