왜 HN에서 이 글이 퍼졌나

2026년 3월 7일 기준 Hacker News 스레드는 "AI 코드 품질" 논쟁을 감상이 아니라 계측 가능한 실패로 바꿨다는 점 때문에 주목을 받았다. 원문인 Your LLM Doesn't Write Correct Code. It Writes Plausible Code. 는 LLM이 생성한 Rust 기반 SQLite 재구현을 원본 SQLite와 직접 비교했다. 100-row primary-key lookup에서 SQLite는 0.09 ms, 재구현은 1,815.43 ms로 20,171x 느렸다.

중요한 점은 이 프로젝트가 겉으로는 망가져 보이지 않았다는 사실이다. 코드는 컴파일됐고, 테스트를 통과했고, file format compatibility도 주장했다. 즉 "동작해 보인다"는 신호만으로는 충분하지 않다. 작은 확인에서는 맞는 답을 주더라도, production에서 필요한 성능과 알고리즘 invariant를 깨고 있을 수 있다는 것이 글의 핵심이다.

실패 지점은 어디였나

기술적 진단은 꽤 구체적이다. SQLite에서 INTEGER PRIMARY KEY 는 내부 rowid 의 alias로 취급되므로 WHERE id = 5 같은 조회는 직접적인 B-tree search를 타야 한다. Katana Quant는 해당 Rust 재구현의 planner가 rowid, _rowid_, oid 같은 literal 이름만 인식했다고 지적했다. 그 결과 named primary key lookup이 기대한 logarithmic path 대신 full table scan으로 떨어졌다.

글은 여기에 더해 schema reload, 재컴파일, page copy, batch transaction 밖에서의 비싼 sync 같은 비용이 누적됐다고 설명한다. 각각 따로 보면 치명적이지 않아 보이는 선택이 합쳐지면서, 그럴듯한 재구현이 실제 사용자가 기대하는 데이터베이스 동작을 놓치는 결과가 나온 것이다.

HN 토론이 보탠 맥락

HN 댓글은 이 문제를 데이터베이스 바깥으로 확장했다. 여러 사용자는 frontier coding model이 특히 specification이 느슨하거나 처음 보는 문제에서 취약하다고 지적했다. 이는 원문의 핵심 권고와 맞닿아 있다. 생성 전에 acceptance criteria를 먼저 정의하라는 것이다. 실제로는 latency budget, algorithmic expectation, correctness check, regression test, verifier tooling을 먼저 적어야 한다는 뜻이다.

coding agent를 도입하는 팀에게 남는 교훈도 같다. 프롬프트 문구보다 verification design이 더 중요하다. 개발자가 query planner가 왜 full scan이 아니라 B-tree seek를 골라야 하는지 설명하지 못한다면, 모델의 자신감 있는 출력이 그 차이를 메워주지 않는다. HN에서 이 글이 퍼진 이유는 명확하다. 관심이 "멋지게 생성되느냐"에서 "명시적 테스트를 통과하는가"로 옮겨가고 있기 때문이다.

원문: Your LLM Doesn't Write Correct Code. It Writes Plausible Code.

#acceptance-criteria

HN 화제: LLM 코딩은 프롬프트보다 acceptance criteria가 먼저라는 경고