▲

8년의 갈망, 3개월의 완성 - AI가 바꾼 사이드 프로젝트의 공식

 (lalitm.com)
8P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • 오랫동안 부족했던 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 협업 개발 경험의 축적임

함께 보면 좋은 글 β

▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • 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 문서를 보면, 이건 설계 단계에서의 문제 정의 부족으로 보임

  • 나도 이 글의 결론에 전적으로 공감함
    AI 코딩의 현실을 과장 없이 솔직하게 보여주는 좋은 사례임

답변달기