최근 일상적인 코딩은 물론, 개인적인 개발에서도 AI(특히 Claude Code)를 평범하게 사용하게 되었습니다.

평소 사용법으로는 정보 수집이나 기술적인 질문·브레인스토밍(Wall-hitting)에는 Gemini를 사용하고, 실제 코드 생성에는 **Claude(커맨드 라인)**를 메인으로 활용하고 있습니다.

Claude는 정말 놀라울 정도로 편리하지만, 동시에 "가끔 깜짝 놀랄 정도로 빗나간 제안이나 구현"을 할 때도 있습니다. 그렇기 때문에 그때마다 인간 측에서 "궤도 수정"을 하는 작업이 필수적입니다.

그럼에도 불구하고, "동작하는 코드"와 "테스트 코드"를 세트로 작성해 주기 때문에 일정 수준의 "품질 보증 (Quality Assurance)"을 도모할 수 있습니다. 저처럼 "머릿속에는 설계나 코드가 떠오르지만, 그것을 필사하듯이 키보드로 끊임없이 입력하는 작업이 괴롭다 = 코드 작성이 이제는 단순한 작업일 뿐이다"라고 느끼는 사람에게는 매우 유효하고 편리합니다. 게다가, claude.md에 명확한 제약 사항이나 코딩 규약을 적어두면 적절하게 함수화 및 공통화를 수행해 주기 때문에 상당히 좋은 결과물이 완성됩니다.

다만, 실제로 AI로 코딩을 하면 할수록, 그리고 사용하면 할수록 통감하는 것은 "비엔지니어(Non-engineer)가 노코드(No-code)로 프로젝트를 탄생시킬 수 있다"는 것은 그야말로 "그림의 떡"이라는 사실입니다.

AI 이용이 어느 정도 정착된 상황에서 서두의 영상을 보고, "와, 정말 그렇구나!"라고 강하게 공감했기에 게재했습니다. 이번에 제가 쓰는 기사의 전제로서도 매우 참고가 되는 내용이라고 느꼈기 때문입니다.

결국 "비엔지니어·노코드로 앱 개발을 할 수 있다"는 것이 허상인 이유는, 영상에서도 언급되었듯이 "도메인 지식 (Domain Knowledge)"의 중요성으로 귀결됩니다. 도메인 지식이란 "인간이나 조직이 쌓아온 성과물" 그 자체입니다. AI를 어디까지나 "부하 직원"이라는 위치로 파악한다면, "노코드·비엔지니어로 개발한다"는 것은 "중요한 도메인 지식을 스스로 구축·이해하지 못한 채 부하 직원에게 통째로 떠넘기고 있는 상태"에 다름없습니다. 그렇기에 실현 불가능한 허상인 것입니다.

최근 일부 과장 광고적인 유튜버 등이 "비엔지니어·노코드"를 큰 소리로 외치며 "프로그래머 불필요론"을 주장하는 영상이 늘어나고 있습니다. 하지만 실제로 AI를 사용하여 코딩을 수행하고 있는 현장에서 본다면, "프로그래머가 불필요해지기는커녕, 프로그래머가 AI를 사용하여 프로그램을 작성하는 것이 업무가 되는" 미래밖에 보이지 않습니다.

"프로그래머가 AI를 사용하여 프로그램을 작성"하게 되면, 지금까지 "코드를 작성하는 것"에 사용했던 시간이 대폭 단축되어, 그만큼 "그 외의 작업"에 주력할 수 있게 됩니다.

이는 AWS의 등장으로 인해 일어난 변화와 매우 흡사합니다. 과거에는 전문 인프라 팀이 수동으로 수행하던 "서버 셋업이나 미들웨어 도입·튜닝"과 같은 작업이, 클라우드화에 의해 개발 엔지니어가 직접 "Terraform 등을 사용하여 인프라를 코드로 구축·관리하는" 스타일로 이행되었습니다. 이와 똑같은 일이 개발 영역에서도 일어나고 있는 것입니다.

실제 AI 도입 후의 개발 현장에서는 코드 생성 시간이 단축됨에 따라 릴리스 사이클(Release Cycle)이 빨라지고 있습니다. 그 결과, "프로그램을 작성하는 시간은 줄어들었는데, 오히려 더 바빠졌다"는 현상도 일어나고 있습니다. 역시 AI로는 좋고 나쁨을 판단하기 어려운 동작 확인이나 UX/UI의 다듬기 등 인간이 대응해야 할 영역이 늘어났기 때문입니다. "적은 인원으로 프로젝트 개발을 할 수 있게 되었다(효율화되었다)"는 반면, 엔지니어가 단기간에 멀티로 커버해야 할 범위가 넓어져 결과적으로 바빠지고 있다고 느낍니다.

반대로 말하면, AI의 장점으로서 "개인의 코딩 능력에 따른 차이"가 평탄화되어, 누가 실행하더라도 "일정한 수준의 코드 품질"을 얻을 수 있게 됩니다. 따라서 앞으로는 단순히 "코딩 능력이 높은 사람"보다, "설계나 코딩 규칙, 최적화에 정통한 사람"이나 "커뮤니케이션 능력이 높은 사람"이 AI 시대의 엔지니어로서 성장해 나갈 것이라는 인상을 받습니다.

하지만 「AI에게 코드를 통째로 맡기는 것」은 엄금해야 합니다. 제안형으로 제시하게 하고, 설계의 방향성이나 수정 사항을 「사람이 확인하면서」 진행하지 않으면, 어느샌가 예상치 못한 파괴적인 변경이 가해져 있을 수 있습니다. 그리고 나중에 연계가 맞지 않게 되었을 때, AI가 당당한 표정으로 "이렇게 되어 있으므로 수정이 필요합니다"라며 엉뚱한 대응을 하는 것——이것이야말로 "부족한(헤코이) AI 대응"의 전형입니다. 이것들을 올바르게 이해하고 적절하게 지시를 내릴 수 있는 능력이야말로 현대의 "AI 노하우"라고 할 수 있습니다.

조금 『공각기동대』 같은 이야기가 됩니다만, 그야말로 "AI에게 고스트(Ghost)는 깃들지 않는다"는 것입니다. 『공각기동대』의 제작자들이 이 AI 시대의 미래를 예측하고 있었던 것이 아닌가 싶을 정도입니다.

요컨대, AI는 어디까지나 "학습 데이터에 기반하여 처리된 정보를 확률적으로 계산하고, 수동적으로 한 글자씩 출력하고 있는 존재"에 불과합니다. 인간처럼 자연스러운 답변을 할 수 있다는 점에는 감탄하게 되지만, 바꿔 말하면 "AI는 자발적으로 사고할 수 없다 = 고스트는 깃들지 않는다"는 것입니다.

또한 구조상, AI는 "자신의 컨텍스트 (Context/Memory) 내에 정보가 존재하지 않으면 내용을 올바르게 해석할 수 없다"는 메커니즘으로 되어 있습니다. 예를 들어 claude.md 등의 정보도 채팅으로 지시를 내릴 때마다 매번 뒤에서 전송되고 있으며, 과거의 컨텍스트 정보 범위 내에서만 해석을 수행하고 있습니다. 이러한 메커니즘인 이상, 그곳에 의지(고스트)가 깃드는 일은 있을 수 없는 법입니다.

그렇기에 「AI에게 무엇을 해달라고 할지」를 교묘하게 전달하는 "AI 기술·노하우"와, 전제 조건으로서의 claude.md 기술, 그리고 그곳에 「도메인 지식 (Domain Knowledge)」을 올바르게 심어주는 작업이 필요합니다. 그렇게 함으로써 비로소 AI가 "마치 자발적으로 움직이는 듯한 정밀도"로 실행해 주는 것——이것이야말로 2026년 현재에서의 올바른 AI 사용법이라고 생각합니다.

제가 본격적으로 AI 개발로 전환하게 된 계기는 회사의 업무가 아닌 "개인 프로젝트"였습니다. 약 반년 전부터 조금씩に取り組んで(임해) 온 과정에서 얻은, AI 개발의 실천적인 노하우를 소개해 드립니다.

먼저, 2026년에 들어서 두 번째로 작성한 개인 프로젝트입니다. 일부 수동 수정을 제외하고는 거의 노코드 (No-code, Claude를 본격적으로 활용)로 구축했습니다.

다음으로, "원래 수동으로 코딩하던 기존 코드"에 대해 나중에 claude.md를 추가하여 Claude로 마무리한 프로젝트가 다음의 2가지입니다.

당초에는 "Claude 커맨드"나 "로컬 환경에서의 실행"에 대해 약간 위험하다는 인상을 가지고 있었기 때문에, 브라우저의 채팅 UI를 통해 Claude Code에게 지시를 내려 코딩하게 했습니다. 지금 생각하면 매우 비효율적인 접근 방식이었다고 생각합니다.

다만, AI의 "부족함(헤코사)"을 통감하기에는 좋은 경험이었습니다. 브라우저 채팅상에서 Sonnet 등의 모델을 사용하여 조금 규모가 큰 프로그램을 쓰게 하려고 하면, 갑자기 임기응변식의 제안이나 할루시네이션 (Hallucination, 환각/오정보)을 연발하게 됩니다.

게다가 임기응변식의 코드 생성을 거듭한 결과, 코드 전체가 스파게티화되어 AI 스스로가 몇 번을 수정해도 고칠 수 없는 "새로운 버그 제조 장치"로 변해버립니다. 쓸데없이 토큰을 소비하고 시간을 낭비하기만 하는 "몬스터"로 전락하고 마는 것입니다.

이 경험을 통해, "도중에 사람이 모든 코드를 읽어내고, 공통화되지 않은 부분을 정리하여 AI에게 설계 규칙을 다시 주지할 필요성"을 깊이 실감할 수 있었습니다. 처음부터 "Claude 커맨드를 사용하여 claude.md에 템플릿을 작성하는 것"과는 또 다른 각도에서 이해가 깊어졌기 때문에, 처음에는 일부러 브라우저 채팅을 경유하여 규모가 큰 개발을 시도해 보는 것도 AI 코딩의 특성을 이해하는 데 좋은 단계가 될지도 모릅니다.

AI에 주목하게 된 초기 계기는, "사내 문서를 RAG (Retrieval-Augmented Generation, 검색 증강 생성)화하면 작성된 채로 방치되어 있는 대량의 문서를 활용할 수 있지 않을까?"라고 제안하여 사내 RAG화 프로젝트에 참여하게 된 것이 계기였습니다. 거기서 "구체적으로 어떤 메커니즘으로 AI가 문서를 RAG화하는가"에 흥미를 느껴, 조사하며 수동으로 프로그램을 작성해 만든 것이 다음의 프로젝트입니다.

현재는 Claude를 이용한 AI 코딩을 사용하여 동작하는 형태로 완성했지만, 원래는 직접 임베딩 모델을 사용하여 벡터 좌표를 계산하고 간이적인 벡터 DB 모조품을 만들었습니다. 거기에 "근사치 검색 조건 + 추론 모델로 작성한 문서 요약"을 AI에게 전달하여 RAG화하는 메커니즘입니다.

실제로 로컬 LLM (Local LLM) 서버를 준비하여 구동해 본 결과, 나름대로 RAG (Retrieval-Augmented Generation)로서 기능하기는 했으나, 반환 포맷에 편차가 발생하는 등 과제도 보였습니다. 하지만 이 개발을 통해 "AI에게 전달하는 프롬프트 (Prompt)의 구조와 역할"에 대한 이해를 크게 넓힐 수 있었습니다.

VJA (Visual Js for AI)는 과거 Microsoft가 제공했던 "Visual Basic 6 (VB6)"의 개발 방식을 계승하여 고안한 도구입니다. 저 자신이 Windows 95 시절 처음 앱을 만들었을 때의 감동이 기억에 남아 있으며, 이 이벤트 드리븐 (Event-driven) 방식의 접근법이 "로컬 LLM 환경에 매우 잘 맞지 않을까"라고 생각한 것이 계기였습니다.

로컬 LLM은 클라우드 AI와 달리 리소스의 제약을 받습니다. 저 자신도 DDR5 메모리 64GB에 Ryzen AI가 탑재된 미니 PC를 준비하여 (Ubuntu + Vulkan + llama.cpp의 경량 구성), 로컬 LLM 서버를 구축했습니다. 20만 엔 이상을 들인 구성이지만, 그럼에도 클라우드 AI에 비하면 처리 속도가 훨씬 느리며, 단순한 비용 대비 효율만 따진다면 "Claude Code나 OpenAI를 사용하면 된다"는 결론에 도달하게 됩니다.

하지만 "AI의 내부 구조를 이해"하기 위해서는 실기 검증이 필수적이었습니다 (반쯤은 가젯(Gadget)적인 물욕도 있었습니다). 어렵게 구매한 환경을 활용하기 위해, "개인이 관리하는 데이터는 한정되어 있으므로 RAG보다는 로컬 LLM을 활용한 로컬 앱 개발 환경을 만들 수 없을까?"라고 고민하며 탄생한 것이 VJA입니다.

왜 VB6의 접근 방식이 로컬 LLM에 최적인가 하면, VB6는 "이벤트에 대해 실행 코드가 연결되는" 구조를 가지고 있어 코드 간의 의존 관계가 매우 작고, 화면 중심의 짧은 코드로 구현할 수 있기 때문입니다. "컨텍스트 (Context)가 작고 독립적인 짧은 소스 코드를 생성하는" 태스크는 로컬 LLM이 잘하는 영역과 일치합니다.

또한, Mac (Apple Silicon)이라면 탑재된 NPU/Unified Memory를 활용함으로써 저전력 및 고속으로 로컬 LLM을 구동할 수 있습니다. 이를 이용하면 "로컬 앱을 노코드 (No-code) 감각으로 만들 수 있는 환경"을 실현할 수 있다고 생각하여 개발을 진행했습니다.

기술 스택으로는 Bun.js 및 Electrobun을 채택하였고, 데이터베이스에는 SQLite3를 사용하고 있습니다. 이 구성을 베이스로 Claude (당초에는 브라우저 채팅)를 사용하여 개발 도구 자체를 구축해 나갔습니다.

로컬 LLM을 운용하면서 직면한 가장 냉혹한 현실은, "시스템 프롬프트 (System Prompt)와 사용자 프롬프트 (User Prompt)를 명확히 분리해야 한다"는 점이었습니다.

당초에는 사용자 프롬프트 측에 모든 조건을 몰아넣어 전송했었는데, 일본어로 2만 자 가까이 되면 로컬 LLM이 매번 토큰을 읽어 들여 처리 (Prefill)하는 데 엄청난 시간이 걸리게 됩니다. 대책을 조사해 보니, "정적인 프롬프트 (시스템 프롬프트)로 분리함으로써 2회차 이후의 처리가 캐시 (Cache)화된다"는 것을 알게 되어 구성을 분리했습니다.

분리를 통해 속도는 향상되었으나, 절대적인 토큰 수가 너무 많기 때문에 코드 생성 자체의 대기 시간은 극적으로 개선되지 않았습니다. 그래서 다음 시책으로, 프롬프트를 기본적으로 모두 "영어"로 변환했습니다. 영어화를 통해 토큰 효율이 극적으로 개선되었고, 최종적으로는 "1분 이내에 프로그램을 생성할 수 있는" 수준까지 고속화에 성공했습니다. 불필요한 컨텍스트를 한계까지 깎아내는 튜닝도 효과적이었습니다.

로컬 LLM의 모델 선정에 있어서도 중요한 깨달음이 있었습니다. 최근의 추론 모델 (Gemma 4, Qwen 3.5, Qwen 3.6 등)은 구세대 모델에 비해 코딩 능력이 비약적으로 향상되었습니다. 하지만 그 반면, "추론 (Reasoning)을 위한 시간"이 필요하게 되어, 오히려 추론 모드를 OFF로 하면 성능이 극단적으로 떨어지는 특성이 있습니다.

당초 llama.cpp의 브라우저 UI에서 "테트리스를 만들어줘"라고 대략적인 지시를 내렸을 때는 3분 정도 만에 동작하는 코드가 출력되었기 때문에, "Qwen 3.5 4B 정도가 VJA에 최적일 것이다"라고 생각하고 있었습니다.

하지만 VJA와 같이 약 2만 자의 정적 컨텍스트 (Static Context)를 준 상태에서 10줄 정도의 짧은 코드 생성을 지시하면, AI가 추론 (Inference)을 위해 2,000 토큰 이상을 낭비하며 실행 시간이 5분을 넘겨버리는 현상이 발생했습니다. 원인을 조사한 결과, 처리 시간의 대부분이 "프롬프트에 대한 추론 토큰 생성 시간"에 사용되고 있다는 사실이 밝혀졌습니다. 그렇다고 추론 모드를 OFF로 설정하면, 문맥을 해석하지 못해 동작하지 않는 코드가 출력되어 버립니다.

그래서 Gemini의 제안을 참고하여 Qwen 2.5 Coder 7B를 시도해 본 결과, 단 20초 정도 만에 매우 정확한 코드가 돌아오게 되었습니다.

이 경험을 통해, 코드 생성과 같은 명확한 태스크 (Task)에서는 어설프게 새로운 추론 모델을 사용하는 것보다, 2025년 세대와 같은 "추론을 거치지 않는 코드 특화형 모델 (Qwen 2.5 Coder 7B나 DeepSeek V2 Coder Lite 등)"이 훨씬 빠르고 정확하다는 것을 알게 되었습니다. "최신 모델 = 최고"가 아닐 수도 있다는 좋은 배움을 얻었습니다.

이 VJA라는 환경은 현재 M1 Mac 등에서도 쾌적하게 동작하며, AI를 사용하여 노코드 (No-code)에 가까운 감각으로 앱 개발을 할 수 있는 도구로서, Claude Code를 사용하여 약 1개월 만에 완성했습니다. 그야말로 "AI의 은혜"를 실감할 수 있는 성과물 중 하나입니다.

다음에 도전한 것이 서두에서도 언급한 아래의 두 가지 개인 프로젝트입니다.

원래 minto는 초경량 AWS Lambda 런타임 (Runtime)인 "LLRT"를 활용하여 구동하는 초경량 프레임워크로서 작성한 것이었습니다. 일단 돌아가는 것이 만들어진 단계에서 만족하여, 반쯤 보류되었던 프로젝트입니다.

머릿속에는 추가적인 구상이 있었지만, 다른 업무의 우선순위가 높아 뒤로 밀려 있었습니다. 하지만 VJA 개발 과정에서 작성한 claude.md의 노하우가 있었기에, 그 설정을 유용하여 Claude 명령어로 개발을 재개해 보기로 했습니다.

틈틈이 명령어로 지시를 내리고 출력 결과를 확인하며 진행한 결과, 과제였던 "로그인 인증 주변"이나 "저렴한 S3 Table 기능 대응", 나아가 "로컬 개발용 대체 S3/SQS 서버 기능"과 같은 실전적인 기능들을 단 2주 정도 만에 단숨에 구현할 수 있었습니다.

여기서 얻은 중요한 깨달음은, "인간이 한 번 뼈대를 쓰고 동작 환경을 갖춘 코드에 대해 Claude에게 사후에 기능을 추가하게 하는 것이, 완전히 제로(Zero)에서 생성하게 하는 것보다 코드의 정밀도나 아름다움(단순화·공통화)이 훨씬 높다"는 것입니다. 인간이 작성한 읽기 쉬운 코드의 뉘앙스를 AI가 계승해주기 때문에, VJA처럼 처음부터 만들게 한 것보다 더 깔끔한 성과물을 얻을 수 있었습니다.

마찬가지로 glint에 대해서도, 원래는 "AI가 RAG의 답변을 내놓는 메커니즘"을 이해하기 위해 시작한 실험적 코드였습니다. 이것을 minto와 동일한 수법으로 Claude에게 전달하여, 웹 앱화 및 "SQLite3를 이용한 벡터 정보 관리로의 변경" 등을 추가·개수하게 한 결과, 최종적으로 "서버 기동 + 브라우저에서 사용할 수 있는 개인용 RAG 도구"로서 완벽하게 완결 지을 수 있었습니다.

"과거에 아이디어는 있었으나 시간이 부족해 좌절되었던 프로젝트"에 대해, claude.md를 배치하고 Claude에게 이어가기나 리팩터링 (Refactoring)을 지시하는 것——이 "과거 자산의 발굴"이야말로 AI 코딩에 있어 극히 효과적인 활용 패턴이라고 느낍니다.

** (※ 이 내용은 gemini가 정리해 주었습니다)

이번에 개인 프로젝트나 일상적인 개발에서 AI (Claude Code, Gemini, 로컬 LLM 등)를 본격적으로 활용해 봄으로써, 2026년 현재의 "실전적인 AI 활용"에 대한 명확한 결론을 얻었습니다.

세간에서 떠도는 "노 엔지니어·노코드로 앱 탄생"이나 "프로그래머 불필요론"은 현장 관점에서 보면 완전히 공상에 불과합니다. AI에게는 자발적인 의지 (Ghost)가 없으며, 어디까지나 컨텍스트에 기반하여 문자를 출력하는 "수동적인 부하"에 지나지 않습니다. 도메인 지식이나 설계 사상을 갖추지 않은 인간이 통째로 맡겨버리면, 임기응변식 코드와 버그를 양산하는 괴물을 만들 뿐입니다.

2026년 현재, AI를 사용하여 개발 효율을 극대화하기 위한 포인트는 다음과 같습니다.

역할의 명확화: AI는 지시대로 코드를 작성하는 "우수한 타건 요원 (부하)". 인간은 설계, 방침 결정, 통제권을 행사하는 "지휘관 (상사)"

컨텍스트와 제약의 부여 방식: claude.md

또 시스템 프롬프트 (System Prompt)를 활용하여 도메인 지식 (Domain Knowledge)이나 공통화 규칙을 AI에게 명확하게 심어준다 -
프롬프트와 모델 선정의 최적화: 중복되는 프롬프트는 피하고, 필요에 따라 영어화 또는 경량화를 도모한다. 또한, 최신 추론 모델에만 집착하지 않고, 태스크 (Task)에 따라 Qwen2.5-Coder와 같이 추론 과정 없이도 빠르고 정확한 모델을 파악하여 구분해서 사용한다 -
기존 코드 및 과거 자산의 발굴: AI는 제로 베이스에서의 생성보다, 인간이 베이스를 만든 코드나 과거에 중단되었던 프로젝트의 확장 및 리팩터링 (Refactoring)에서 진가를 발휘한다

AWS의 등장으로 인프라 구축 작업 스타일이 변화한 것과 마찬가지로, 프로그래머의 업무도 "수동으로 코드를 입력하는 작업"에서 "AI를 제어하여 빠르게 프로덕트를 형상화하는 작업"으로 전환되었습니다.

코딩이라는 "작업"의 가치가 평준화된 지금, 엔지니어에게 요구되는 것은 "설계 능력", "도메인 지식 (Domain Knowledge)", "최적화 노하우", 그리고 "AI에게 정확한 지시를 내리고 고삐를 쥐는 커뮤니케이션 능력"입니다. AI를 올바르게 복종시키고, 자신의 손으로 프로덕트를 컨트롤해 나가는 것이야말로 다가올 시대의 최강의 효율화라고 할 수 있습니다.

ー 이상 ー