# 8년의 갈망, 3개월의 완성 - AI가 바꾼 사이드 프로젝트의 공식 > Clean Markdown view of GeekNews topic #28239. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28239](https://news.hada.io/topic?id=28239) - GeekNews Markdown: [https://news.hada.io/topic/28239.md](https://news.hada.io/topic/28239.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-06T09:44:05+09:00 - Updated: 2026-04-06T09:44:05+09:00 - Original source: [lalitm.com](https://lalitm.com/post/building-syntaqlite-ai/) - Points: 27 - Comments: 1 ## Summary 8년간 만들고 싶었던 **SQLite 개발 도구**를 AI로 3개월 만에 완성한 실전 기록입니다. 처음에는 AI에게 설계까지 맡기는 바이브 코딩으로 갔다가 스파게티 코드가 되어 **Rust로 전면 재작성**한 경험이 솔직하게 담겨 있습니다. 결국 AI를 "자동완성 강화 도구"로 제한하고 설계·검토는 직접 주도하면서 린팅·테스트 자동화 같은 **검증용 스캐폴딩을 먼저 깔았을 때** 성과가 나왔다고요. 바로 위 Bram Cohen의 글과 함께 읽으면 같은 결론에 다른 경로로 도착하는 게 보입니다. ## Topic Body - 오랫동안 부족했던 **SQLite용 고품질 개발 도구**를 AI의 도움으로 단기간에 완성 - **공식 문법 명세 부재와 복잡한 C 코드베이스**로 인해 파서 구축이 가장 큰 난관이었음 - **Claude Code 등 AI 코딩 에이전트**를 활용해 초기 구현을 빠르게 진행했으나, 스파게티 코드 문제로 **Rust 기반 재작성**을 단행 - AI는 **코드 생성·리팩터링·학습 보조·UX 개선**에 큰 효율을 보였지만, **설계 지연·코드 단절·의존성 중독** 같은 부작용도 발생 - 결론적으로 AI는 **구현 속도를 높이는 도구**일 뿐, **설계와 소프트웨어의 방향성은 인간이 책임져야 함** --- ### SQLite 개발 도구를 AI로 구축한 3개월의 기록 - **SQLite용 고품질 개발 도구**를 오랫동안 원했으나, 기존 오픈소스 도구들은 신뢰성·속도·유연성 면에서 부족했음 - PerfettoSQL 유지보수 중 포매터, 린터, 에디터 확장 등 기능 수요가 있었지만 적합한 도구가 없었음 - 개인 프로젝트로 새 도구를 만들고자 했으나, 난이도와 반복 작업의 부담으로 수년간 미뤄짐 ### 프로젝트의 난점 - SQLite는 **공식 문법 명세나 안정된 파서 API가 없음** - 내부적으로 파스 트리를 생성하지 않아, 소스코드에서 직접 파서 로직을 추출해야 했음 - 400개 이상의 문법 규칙을 일일이 매핑해야 하며, 테스트 작성과 디버깅이 매우 반복적이고 피로한 작업 - SQLite의 C 코드베이스는 **복잡하고 밀도가 높아** 이해가 어려움 - 가상 테이블 API와 구현을 파악하는 데만 며칠이 소요될 정도로 구조가 난해함 ### AI와 함께한 개발 과정 - 2025년 말부터 **Claude Code** 등 AI 코딩 에이전트를 본격 활용 - 초기에는 AI에게 대부분의 설계·구현을 위임해 “vibe-coding” 방식으로 진행 - 결과물은 동작했지만 **코드베이스가 스파게티 형태**로 복잡해 유지 불가능한 수준이 됨 - 이후 전체를 **Rust로 재작성**하며 구조를 재정립 - C 대신 Rust를 사용해 상위 구성요소(검증기, 언어 서버 등) 개발 용이 - AI를 “자동완성 강화 도구”로 제한하고, 설계·검토·테스트를 직접 주도 - 린팅·검증·테스트 자동화 등 **AI 산출물 검증용 스캐폴딩** 구축 ### AI가 가능하게 한 것들 - ## 관성 극복 - AI가 **구체적 문제 단위로 작업을 쪼개** 시작을 쉽게 만들어줌 - “SQLite 파싱을 이해해야 한다” 대신 “AI가 제안한 접근을 검토한다”로 전환되어 실행 속도 향상 - ## 코드 생성 및 리팩터링 속도 - 명확한 요구사항이 있을 때 AI는 **표준적이고 일관된 코드**를 빠르게 작성 - 비표준적 설계(파서 구조 등)에서는 오히려 방해가 되어 직접 작성 필요 - 대규모 코드 생성 후 **지속적 리팩터링**이 필수이며, 이를 통해 품질 유지 - ## 학습 보조자 역할 - AI가 **Wadler-Lindig 포매팅 알고리듬** 등 새로운 개념을 실시간으로 설명 - Rust, VS Code 확장 등 익숙하지 않은 영역에서도 빠른 진입 가능 - 프로젝트 맥락을 잃었을 때 “이 컴포넌트 설명해줘” 같은 질의로 **즉시 맥락 복원** - ## 완성도 향상 - 에디터 확장, Python 바인딩, WASM 플레이그라운드, 문서 사이트 등 **부가 기능 개발 비용을 낮춤** - 구현 부담이 줄어 **UX 개선**에 집중 가능, 오류 메시지·CLI 설계 등 사용자 경험 강화 ### AI 사용의 부작용 - ## 중독성 - “한 번 더 프롬프트”를 반복하는 **슬롯머신형 보상 구조** - 피로할수록 프롬프트 품질이 떨어지고, 결과가 나빠져 악순환 발생 - ## 코드베이스와의 단절 - AI가 생성한 코드가 많아질수록 **세부 구조에 대한 감각 상실** - 맥락을 잃으면 AI와의 대화도 길어지고 비효율적이 됨 - 해결책으로, 생성 직후 코드를 직접 읽고 “내가 다르게 썼을 부분”을 점검하는 습관 도입 - ## 설계 지연과 부식 - 리팩터링이 쉬워 **핵심 설계 결정을 미루는 경향** 발생 - 테스트가 많아도 **근본적 설계 오류를 가리기 어려움**, 결국 전체 재작성 필요 - ## 시간 감각 부재 - AI는 코드의 **시간적 맥락이나 진화 과정**을 이해하지 못함 - 과거 실수를 반복하거나, 이미 해결된 문제를 다시 탐색하는 비효율 발생 - 문서화로 보완 가능하지만, **설계 의도까지 완전하게 기록하기는 어려움** ### AI 활용의 상대성 - **깊이 이해한 영역**에서는 AI가 탁월, 빠른 검토와 반복 가능 - 예: 파서 규칙 생성은 명확한 정답이 있어 효율적 - **부분적으로 아는 영역**에서는 학습 도구로 유용하지만 지속적 주의 필요 - 예: 포매터 알고리듬 학습 - **무엇을 만들지 모르는 단계**에서는 오히려 해로움 - 예: 아키텍처 설계 단계에서 비생산적 루프 발생 - **검증 가능한 문제**(컴파일·테스트 통과)는 AI가 강하지만, **디자인·API 품질**처럼 정답이 없는 문제에서는 취약 ### 결론 - 8년간 구상했던 SQLite 도구를 **3개월 만에 실현**할 수 있었던 것은 AI 덕분 - 그러나 과정은 단순한 성공담이 아니라, **AI 의존의 한계와 대가**를 동반 - AI는 **구현의 배속 장치**이지만, **설계의 대체물은 아님** - 기술적 질문에는 정확히 답하지만, **역사·취향·사용자 감각**은 결여 - 진정한 교훈은, AI를 통해 더 빠르게 벽에 부딪히더라도 **인간이 설계의 방향과 ‘소프트웨어의 영혼’을 책임져야 한다는 점**임 - 앞으로 필요한 것은 **실제 사용자와 유지보수를 견디는 수준의 프로젝트 사례 공유** - 단순한 실험이 아닌, **현실적·지속 가능한 AI 협업 개발 경험**의 축적임 ## Comments ### Comment 54718 - Author: neo - Created: 2026-04-06T09:44:05+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47648828) - AI 코딩에 대한 **균형 잡힌 시각**을 보니 신선함을 느낌 대부분의 진지한 개발자라면 공감할 경험임 — 처음엔 AI가 코드를 잘 짜주는 것에 놀라지만, 나중에 보면 코드베이스가 **스파게티 코드**로 엉망이 되어 있음 일부는 코드 리뷰도 안 하고 “이제 수동 코딩은 끝났다”고 떠들고, 또 다른 일부는 “AI 코딩은 쓸모없다”고 단정함 하지만 현실은 그 중간 어딘가에 있음. AI는 큰 **생산성 가속기**가 될 수 있지만, 올바르게 워크플로우에 녹이고 사람이 계속 관여해야 함 - 나도 지난 3개월 동안 **Claude**를 메인 코딩 인터페이스로 써왔음 처음엔 프로토타입이었지만 금세 실제 서비스로 발전했음. 이후 리팩토링하면서 쓸모없는 코드들을 걷어내느라 고생했음 그래도 그 빠른 프로토타입 덕분에 지금의 제품이 존재함. Claude는 마치 **전기톱**처럼 코드 정리에 유용했음 최근엔 pre-commit 훅으로 타입체커를 추가하고 90개의 에러를 2시간 만에 수정했음. AI 코딩은 놀랍지만, **프로덕션 코드**에서는 여전히 사람의 리뷰와 판단이 필수적임 - 이 글이 특히 좋았던 이유는 **균형 잡힌 관점** 때문임 다만 이 사례가 개인의 **그린필드 프로젝트**라서 일반적인 팀 개발에 바로 적용하기는 어려움 그래도 프로토타입을 ‘버릴 전제’로 만든다면 스파게티 코드도 괜찮다고 생각함. 문제는 저자가 그걸 진짜 제품으로 발전시킬 수 있다고 착각한 것임. 하지만 그 실패 덕분에 더 나은 설계를 배웠을 것이라 봄 - 사실 이런 양극단의 반응은 **AI 코딩을 처음 겪는 모든 사람의 단계**라고 생각함 처음엔 놀라고, 나중엔 실망하고, 결국 균형을 찾게 됨. 마치 **AI 버전의 쿠블러-로스 모델**처럼 보임 - 반대로 나는 **코드 품질 집착**이 AI 시대의 맹점이라고 봄 물론 품질은 중요하지만, 이제는 코드 품질 자체가 덜 중요해지고 있음 개인용 앱처럼 유지보수 필요 없는 코드가 늘어나고, AI의 설계 능력도 빠르게 향상 중임 결국 “AI 코딩의 진실”은 계속 변하고 있으며, 이 흐름은 멈추지 않을 것임 - 이런 현실적인 글이 드문 이유는 두 가지라고 생각함 첫째, 대부분의 개발자는 조용히 **2~50%의 생산성 향상**을 누리며 굳이 떠들지 않음 둘째, 진짜 AI 코딩은 **지루하고 비주얼이 안 나옴**. 결국 LLM은 ‘보일러플레이트를 안 외워도 되는 도구’일 뿐, 코딩의 본질은 그대로임 - 나도 AI 테스트 생성에서 같은 문제를 겪었음 테스트가 많아지면 안심되지만, 실제로는 **엣지 케이스**를 다루지 못함 특히 테스트 없는 레거시 코드를 리팩토링할 때 AI가 만든 테스트는 동작만 확인할 뿐, **행동의 일관성**은 보장하지 않음 React 앱에서 이런 문제가 심했음. 그래서 **BDD + 명세 기반 개발**을 AI와 결합하는 방식을 고민 중임 - 좋은 테스트를 짜는 건 실제 코딩보다 **10배 어렵다**고 느낌 단위 테스트는 창의적인 mock 설계가, 통합 테스트는 데이터 조작이, e2e 테스트는 **셀렉터 안정성**이 핵심임 이런 창의적 판단은 AI가 아직 따라오기 어려움 - 커버리지 수치에 속지 말아야 함 97% 커버리지여도 논리적 입력 공간엔 구멍이 많았음. 최근엔 **equivalence partitioning** 같은 고전 기법을 AI 에이전트로 자동화해 60개 모델에 적용했음 - **TLA+** 로 시스템 동작을 명세화하고, 코드와 스펙을 연결하는 접근을 추천함 순수 함수를 최대한 분리해 입력-출력 매핑을 완전하게 테스트하는 게 핵심임 - 장기적으로 AI의 진짜 가치는 **이해력 증폭 도구**로서의 역할이라 생각함 예를 들어 복잡한 C 코드의 규칙을 분석해 구조를 문서화하는 식임 이런 **지식 추출**이 가능해지면, API 문서나 규칙 맵핑, 버그 분석, 아키텍처 최적화까지 자동화할 수 있음 결국 코드를 생성하는 것보다 **맥락을 구조화하는 능력**이 더 중요해질 것임 - 사람마다 AI를 쓰는 방식이 극명히 갈림 ① 요구사항만 던지고 전체 앱을 생성하게 하는 **전지적 오라클형** ② IDE 안에서 한 줄씩 검토하며 쓰는 **보조 도구형** 지속 가능한 서비스를 만들려면 ② 쪽이 훨씬 현실적임 - “**아키텍처는 로컬한 조각들이 상호작용할 때 생긴다**”는 말이 인상 깊었음 AI는 로컬 실행엔 강하지만, **모호한 설계 단계**엔 약함 사실 이건 인간 개발자도 마찬가지임. 설계는 정답이 없는 트레이드오프의 연속이기 때문임 - 나도 AI와 긴 대화를 통해 설계 결론에 도달한 적이 있음 특히 ClickHouse SQL 설계에서 큰 도움을 받았음 AI가 제안한 **템플릿 기반 SQL 포함 방식** 덕분에 중복을 줄이고 성능도 개선했음 이런 접근은 기존에 있었을지도 모르지만, AI 없이는 찾기 어려웠을 것임 - 이 글이 믿음이 가는 이유는 **250시간의 실제 노력**이 들어갔기 때문임 이런 규모의 프로젝트가 진짜 **AI 보조 시스템 프로그래밍**의 현실적 모델이라 생각함 - “AI 코딩은 슬롯머신 같다”는 표현이 너무 공감됨 나도 회사에서 **무제한 AI 에이전트 접근권**을 받았는데, “한 번만 더 프롬프트” 하다 보면 어느새 12시간이 지나 있음. **몰입 중독성**이 강함 - 지금이 아마 **AI 코딩이 가장 어려운 시기**일 것임 6개월 전엔 상상도 못한 일들이 이제 가능해졌음 여러 언어로 프로젝트를 진행 중인데, AI가 코드를 너무 빨리 만들어서 이제는 **리뷰 속도**가 병목이 됨 어느 정도 테스트가 통과하면 “이 정도면 충분한가?”라는 고민이 생김 나는 프롬프트에 **SOLID 원칙, 결합도, 응집도** 같은 품질 속성을 명시함 AI에게 리팩토링 아이디어를 묻고, 괜찮으면 “좋아, 실행해”라고 하면 됨 결국 중요한 건 **프롬프트 설계의 예술**임 하지만 머지않아 AI가 이런 품질 가드레일을 기본으로 수행하게 될 것이라 봄 - 왜 여러 언어로 프로젝트를 하냐는 질문도 있었음 언어 자체가 성능의 병목은 아니지만, 새로운 언어 실험이 학습에 도움이 됨 - **Fred Brooks의 “하나는 버려라” 철학**이 떠오름 AI는 그 첫 번째 버전(throwaway)을 빠르게 만드는 데 최적임 바로 프로덕션 품질을 기대하는 건 **어리석은 접근**임 빠르게 만들어보고 배우고, 그다음 리팩토링하는 게 정석임 피로할 때는 프롬프트가 모호해지고 결과도 나빠진다는 점도 공감됨 - 다만 Brooks는 나중에 **점진적 개선(iterative refinement)** 쪽으로 입장을 바꿨다는 점도 흥미로움 - **SQLite**의 SQL 파서가 lemon으로 생성되지 않았다는 점이 놀라웠음 pikchr를 Go로 포팅할 때는 lemon을 먼저 옮겼는데, SQLite는 파서 트리조차 만들지 않음 [lemon 문서](https://sqlite.org/lemon.html)를 보면, 이건 설계 단계에서의 **문제 정의 부족**으로 보임 - 나도 이 글의 결론에 전적으로 공감함 AI 코딩의 현실을 **과장 없이 솔직하게** 보여주는 좋은 사례임