2026년 7월 26일 IBM의 Zero-Defect Process는 KLOC당 0.1개의 Bug를 달성했다. 업계는 그럼에도 불구하고 이를 포기했다. IBM의 Cleanroom engineering은 업계 평균보다 100배 나은 defect rate를 달성한 뒤 사라졌다. 사라진 이유는 그것이 작동했는지와는 아무런 관련이 없었다. cleanroom-correctnesszero-defectssoftware-historyprocess
2026년 7월 25일 정말로 1만 줄을 결함 없이 검증한 사람이 있었을까? IBM은 했고, 그 방법론은 결과보다 이상하다. Cleanroom software engineering은 디버깅 대신 mathematical verification을 통해 zero-defect increment를 약속했다. 우리는 IBM의 실제 프로젝트 데이터를 살펴보아 그 주장이 성립했는지 본다. cleanroom-correctnesszero-defectsverificationcase-study
2026년 7월 24일 당신의 모듈에는 세 겹이 있다. 아마 한 겹만 썼을 것이다. Box Structure는 모듈이 무엇을 하는지, 무엇을 기억하는지, 어떻게 동작하는지를 세 개의 별개이면서 검증 가능한 겹으로 정의하도록 강제한다. Cleanroom이 어떻게 디버깅을 제거하는지 알아보자. cleanroom-correctnessbox-structurearchitecturespecification
2026년 7월 23일 IBM은 개발자가 자신의 코드를 실행하지 못하게 함으로써 KLOC당 0.1개의 결함을 가진 소프트웨어를 출시했다 IBM의 Cleanroom 엔지니어링 프로세스는 버그를 찾는 대신 미연에 방지함으로써 업계 평균보다 100배 우수한 결함률을 달성했다. 이것이 어떻게 작동했는지, 왜 거의 아무도 사용하지 않는지, 그리고 오늘 당신이 도입할 수 있는 것은 무엇인지 알아보자. cleanroom-correctnessibmzero-defectssoftware-quality
2026년 7월 22일 CI가 당신 없이 tangle할 수 있을 때까지 당신의 리터레이트 프로그램은 고장난 것이다 Literate programming은 단일 진실 공급원을 약속하지만, 수동 weave와 tangle 단계가 CI/CD 파이프라인을 망친다. Markdown 파일이 정규 소스로 남도록 추출과 문서 생성을 자동화하는 방법을 소개한다. literate-programmingci-cdweave-tangleautomation
2026년 7월 21일 코드를 먼저 LLM에 설명하자 버그율이 85% 줄었다 30일 동안 LLM에 코드를 요청하기 전에 설계 설명을 작성했다. 그 결과는 내가 rubber-ducking을 바라보는 방식을 바꿔 놓았다. literate-programmingllmcode-qualityrubber-ducking
2026년 7월 20일 테스트, 코드, 산문을 하나의 Markdown 파일에 담아 문서에 코드를 복사하는 것을 그만뒀다 Literate programming은 Markdown 파일을 single source of truth로 삼아 문서, 테스트, 구현체를 동기화 상태로 유지한다. Python 30줄로 구현하는 방법을 소개한다. literate-programmingdocumentationtestingsingle-source-of-truth
2026년 7월 19일 당신의 Claude 스레드는 이미 문서입니다. 단 12시간 뒤에 사라질 뿐이죠. LLM 대화에는 의도, 거부된 대안, 그리고 작동하는 코드가 담겨 있습니다. 이것이 바로 문서가 되어야 할 것입니다. 다음은 일회성 채팅을 내러티브를 잃지 않고 지속 가능하고 검색 가능한 문서로 전환하는 방법입니다. literate-programmingllmdocumentationai-engineering
2026년 7월 18일 텍스트 에디터는 잘못된 코드를 쓰게 한다. 트리 에디터는 그렇지 않을 것이다. 모든 컴파일러는 코드를 트리로 보지만, 에디터는 원시 텍스트를 편집하게 한다. 구조화 편집이 실제로 어떤 모습인지, 왜 보편화되지 않았는지, 그리고 도구를 바꾸지 않고 그 이점을 얻는 방법을 설명한다. literate-programmingstructured-editingastprogramming-tools
2026년 7월 17일 Donald Knuth는 프로그램을 문학처럼 읽히길 원했다. 컴파일러는 다른 생각이 있었다. Literate programming은 코드를 먼저 인간을 위해, 그 다음 기계를 위해 작성해야 한다고 약속했다. 40년이 지난 지금, 거의 아무도 그렇게 쓰지 않는다. 소프트웨어 문서화에서 가장 우아한 아이디어가 우리의 작업 방식을 바꾸지 못한 이유는 다음과 같다. literate-programmingknuthsoftware-historydocumentation
