본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 22. 18:52

연구에서 배포된 앱까지: 비기술적 창업자가 Claude Code로 보안 웹 앱을 구축할 수 있을까?

요약

AI 코딩 에이전트의 효용성을 연구와 실습을 통해 분석합니다. Claude Code를 활용하여 비기술적 창업자가 보안 웹 앱을 구축하고 배포하는 과정을 다루며, 에이전트의 속도, 복잡성 대응 능력, 보안 측면의 성능을 검토합니다.

핵심 포인트

  • AI 코딩 에이전트의 개발 가속화 효과는 맥락에 따라 다름
  • Claude Code를 이용한 비기술자의 웹 앱 구축 가능성 탐구
  • 코딩 에이전트의 능력 격차는 해소되었으나 보안 격차는 여전히 존재
  • 대규모 기존 코드베이스에서의 에이전트 활용 시 주의점

이 글을 읽는 방법: 파트 1은 AI 코딩 에이전트가 실제로 사람들을 더 빠르고, 유능하며, 안전하게 만드는지에 대한 문헌 검토(literature review)입니다. 파트 2는 해당 연구를 바탕으로 코딩 지식 없이도 Claude Code를 사용하여 직접 배포 가능한 웹 앱을 구축하는 실습 가이드입니다.

PART 1 — 연구 (The Research)

서론 (Introduction)

2021년, GitHub는 소프트웨어 개발을 영원히 바꾼 Copilot이라는 AI 도구를 출시했습니다 (Lakshmanan). 프로그래머들은 더 이상 도움을 구하거나 코드를 복사하기 위해 인터넷을 뒤질 필요가 없게 되었습니다. 코드베이스에 연결된 AI 어시스턴트가 즉시 답을 찾아줄 수 있기 때문입니다. 그 직후 더 나은 생성형 지능(generative intelligence)이 등장했고, 소프트웨어는 더욱 자동화되었습니다. 도구들은 한 번에 하나의 파일만 약간의 숙련도로 편집할 수 있었던 OpenAI의 Codex 기반 플러그인 수준에서, 수많은 파일에 걸쳐 더 어려운 문제를 해결할 수 있는 강력한 모델을 탑재한 데스크톱 애플리케이션인 Cursor로 업그레이드되었습니다. 오늘날 커맨드 라인(command line)은 에이전트형 어시스턴트(agentic assistants)에 대한 접근을 허용하며, 자연어만으로 몇 분 만에 전체 프로토타입을 생성할 수 있습니다.

코딩 에이전트(coding agents)의 급격한 능력 향상은 빠른 도입으로 이어졌으나, 이들이 유용한 범위나 맥락에 대해 심도 있게 숙고할 시간은 충분하지 않았습니다. 특히, 본 기사는 다음과 같은 질문을 던집니다. AI 코딩 에이전트가 실제로 개발을 가속화하는가, 아니면 그 이득이 전적으로 맥락에 따라 달라지는가, 그리고 프로토타이핑(prototyping)이 일반적인 트레이드오프(tradeoffs)가 사라지는 특수한 사례인가? 이러한 주제들에 대한 통찰을 통해, 우리는 숙련된 개발자들의 우려 사항에 답하고, 에이전트형 코딩 어시스턴트(agentic coding assistants)가 크고 복잡한 코드베이스(codebases)에서도 실제로 유용한지 탐구하고자 합니다. 또한, Anthropic 구독 여부에 따라 터미널, 데스크톱 앱, IDE 및 브라우저를 통해 다운로드하여 사용할 수 있는 Claude Code를 심층적으로 살펴보고, 비기술적 창업자들이 언어만으로 안전한 웹 앱을 구축하고 배포하기 위해 이 도구를 어떻게 활용할 수 있는지 안내할 것입니다(Anthropic). 가이드의 지침을 따르고자 하는 독자들은 코딩 에이전트, 즉 Claude Code에 접근할 수 있다고 가정합니다.

문헌 검토 (Literature Review)

Claude Code 및 Codex와 같은 코딩 에이전트는 소프트웨어 개발자들에게 신기한 도구에서 표준으로 자리 잡았으나, 이들의 효과에 대한 연구는 발전 속도를 따라잡지 못했습니다. 초기 연구들은 이러한 도구들이 단순한 맨바닥 작업(from-scratch work)은 가속화하지만, 대규모의 기존 코드베이스에서는 숙련된 개발자의 속도를 늦춘다는 것을 보여주었습니다. 본 검토에서는 코딩 에이전트를 인간 개발자와 비교하여 측정한 세 가지 영역 — 속도, 복잡한 코드에 대한 능력, 그리고 보안 — 을 탐구하며, 이전의 연구 결과들이 최근의 증거들과 어떻게 부합하는지 질문합니다. 한때 에이전트를 고급 프로그래밍에 사용할 수 없게 만들었던 능력의 격차(capability gap)는 대부분 해소되었으나, 보안 격차(security gap)는 여전히 존재합니다. 이러한 불일치는 오늘날 누군가가 이 도구들을 사용하여 무언가를 구축할 때 고려해야 할 핵심 요소가 되어야 합니다.

영역 1 — 속도 및 맥락 (Speed & Context)

사용자들은 코딩 에이전트(coding agents)가 소프트웨어 개발을 가속화한다고 지속적으로 표현해 왔지만, 연구 결과는 맥락에 따라 엇갈린 양상을 보입니다. Microsoft, GitHub, MIT가 수행한 실험에 따르면 생성형 AI (Generative AI)는 쉬운 작업에서 여전히 유익한 것으로 확인되었으며, "실험군이... [javascript로 http 서버 연결하기]를 55.8% 더 빠르게 완료했다"는 결과가 나왔습니다 (Peng et al.). 그러나 숙련된 개발자들은 역사적으로 에이전트의 영향을 덜 받아왔습니다. 2023년 Microsoft, GitHub, MIT의 동일한 연구는 속도 향상이 시니어 엔지니어가 아닌 "프로그래밍 경험이 적은 개발자, 연령대가 높은 프로그래머, 그리고 하루에 더 많은 시간 동안 프로그래밍하는 사람들"에게 가장 크게 느껴졌다고 결론지었습니다 (Peng et al.). 2년 후에도 이러한 전례는 유지되었고 증명되었습니다. Model Evaluation and Threat Research (METR)는 대규모의 기존 코드베이스(codebases)에서 숙련된 개발자들에게 코딩 에이전트가 주는 인지와 실질적 이득 사이의 눈에 띄는 격차를 상세히 다룬 2025년 논문을 발표했습니다 (Becker et al., "Measuring"). 특히, "개발자들이 AI를 허용하면 완료 시간이 24% 단축될 것이라고 예측했음에도 불구하고... 실제로 AI를 허용하면 완료 시간이 19% 증가한다"는 점이 주목할 만합니다 (Becker et al., "Measuring"). 에이전트는 숙련된 프로그래머를 가속화하는 것이 아니라 오히려 속도를 늦추는 촉매제가 되었음에도 불구하고, 개발자들은 여전히 "AI를 허용함으로써 완료 시간이 20% 단축되었다"고 느꼈습니다 (Becker et al., "Measuring"). 속도 향상에 대한 전문가 코더들의 추정치와 현실 사이의 불일치는 매우 심각합니다. 타당한 설명은 그들이 더 빨라지기는 했지만, AI를 사용하는 동안 그들이 원하는 결과물(desired outcome)이 변했다는 것입니다. 대규모 코드베이스에는 개선할 수 있는 제품이 있는 반면, 새로운 프로젝트는 구현해야 할 아이디어만 있을 뿐입니다. 숙련된 아키텍트(architects)는 어떻게 최적화를 찾아내는지 알고 있으며, 이를 달성하기 위해 작업 정의(task definition)를 변경할 수 있습니다. 그들이 작업하는 거대한 저장소(repositories)는 개선을 위한 엄청난 기회를 제공합니다.

반면에, 초보 개발자들은 최적화(optimizations)를 빈번하게 인식하지 못하므로 종종 원래의 목표에만 머무르는 경향이 있습니다. 그들이 작업하는 작은 저장소(repositories)는 개선을 위한 기회를 거의 제공하지 않습니다. 소프트웨어 개발자가 에이전트형 코딩 어시스턴트(agentic coding assistant)를 갖추게 되면 그들의 특성은 더욱 확대됩니다. 즉, 시니어 프로그래머는 더 많은 개선 사항을 식별하고 더 빠르게 반복(iterate)하는 반면, 주니어 개발자들은 초기 제품을 더 빠르게 구축합니다. 양측 모두 AI로부터 긍정적인 영향을 받지만, 그 방식은 다릅니다. 사실, 이는 METR의 실패한 2026년 실험으로부터 도출될 수 있는데, 그들은 "개발자들이 AI 없이 작업하고 싶지 않기 때문에 연구 참여를 거부하는 현상이 유의미하게 증가하는 것을 관찰했으며, 이는 AI 지원 속도 향상(speedup) 추정치를 하향 편향시킬 가능성이 높다"라고 언급했습니다 (Becker et al., "We Are Changing"). 재미있게도, 해당 연구는 여전히 "18%의 속도 향상"을 발견했으며, 이는 에이전트형 도구를 활용하는 숙련된 코더들에게 엄청난 속도 우위가 있음을 시사합니다 (Becker et al., "We Are Changing").

도메인 2 — 복잡한 코드에 대한 능력 (Capability on Complex Code)

AI 도입이 확대됨에 따라 작성된 코드 라인 수는 매년 증가하고 있지만, 새로운 출력물의 기능성과 유지보수 가능성(maintainability)은 여전히 의문으로 남아 있습니다. AI 코드 보조 분야의 저명한 연구 기관인 GitClear는 기업용 리포지토리(repository)에서 "2020년 1월부터 2024년 12월 사이에 작성된 2억 1,100만 줄의 변경된 코드 라인"을 추적하였으며, 그 결과 라인 추가는 연간 9.2% 증가한 반면 라인 이동(line moves)은 연간 49.9% 감소했음을 발견했습니다 (Harding). 에이전트형 도구(Agentic tools)는 개발자들이 코드를 리팩터링(refactor)하기보다는 보충하는 방향으로 움직이도록 영향을 미쳤으나, 이전의 도구들은 생성을 통해 실제적인 과제를 해결하는 데 어려움을 겪었습니다. 이는 2024년 OpenAI의 연구에서도 강조되었습니다. 해당 연구에서는 에이전트들에게 "코드 리포지토리와 이슈 설명이 포함된 500개의 샘플을 제공하고... 패치(patch)를 생성하도록 도전" 과제를 주었으며, 이는 "인간 주석가(human annotators)에 의해 문제가 없는 것으로 검증"되었습니다. 그러나 프런티어 모델(frontier model)의 정확도는 33.2%에 불과했습니다 (Chowdhury et al.). 하지만 시간이 흐르면서 인공지능의 프로그래밍 능력도 함께 발전했습니다. 2026년 기준 가장 성능이 뛰어난 코딩 에이전트들은 수년 전의 동일한 샘플에 대해 80% 이상의 높은 점수를 기록하고 있지만, 여전히 생성(generation)에 크게 의존하고 있습니다 (Vals AI). 기존의 어려운 문제들을 해결하는 것이 AI에게는 사소한 일이 되었지만, 바로 그 점 때문에 미래의 문제가 발생할 수도 있습니다. 앞서 언급한 GitClear의 보고서에서 풍부한 코드 추가는 주요 주제였습니다. 보고서에 따르면 "개발자의 에너지가 주로 새로운 기능을 개발하는 데 쓰이는 대신, 향후 몇 년 동안 '결함 수정(defect remediation)'이 개발자의 주요 일상적 책임이 될 수 있다"고 합니다 (Harding). AI 어시스턴트는 단순하거나 복잡한 코드베이스 모두에서 단기적인 생존 가능성을 보장하지만, 장기적인 영향은 미묘합니다. 프로그래머는 지속적으로 새로운 솔루션을 생성하거나, 혹은 유지보수의 역할을 떠맡게 될 수도 있습니다.

도메인 3 — 보안, 걸림돌이 되었던 격차 (Security, the Gap that Held)

생성형 AI (Generative AI)는 역량이 크게 향상되어 구현 시간을 단축하고 복잡한 프로젝트에서 그 유용성을 수십 배 입증해 왔지만, 보안은 뒤처져 있습니다. 2021년 GitHub Copilot의 등장과 함께 코딩 에이전트 (coding agents)가 도입되었을 때, 보안은 즉각적으로 눈에 띄는 우려 사항으로 지목되었습니다. 뉴욕 및 캘거리 대학교 연구진은 "Copilot이 완성해야 할 89가지 서로 다른 시나리오에서 1,689개의 프로그램을 생성한 결과... 약 40%가 취약했다" (Pearce et al.)는 사실을 발견했습니다. 5년이 지난 지금, AI가 대부분의 시니어 개발자보다 더 능숙해졌음에도 불구하고, 취약점은 동일하거나 더 높은 비율로 생성되고 있습니다. Cloud Security Alliance AI Safety Initiative (CSA)의 최근 연구에 따르면, 실험 과정에서 "AI가 생성한 샘플의 45%가 보안 테스트를 통과하지 못했다" (Cloud Security Alliance)는 것이 증명되었습니다. AI가 생성하는 코드의 양이 기하급수적으로 증가함에 따라, 보안 결함이 있는 저장소 (repositories)의 수도 함께 증가하고 있습니다. CSA가 공개 코드베이스를 스캔한 결과, "2026년 1월에는 6개의 CVE (common vulnerabilities and exposures, 공통 보안 취약점 및 노출)가 AI 생성 코드에 기인했습니다. 2월에는 15개, 2026년 3월에는 35개로 나타나 두 달 만에 거의 6배 증가했다" (Cloud Security Alliance)는 사실이 밝혀졌습니다. 이는 모든 개발자에게 엄청난 위험을 초래합니다. 경험이 부족한 프로그래머는 아무것도 모르는 고객을 위해 제품의 취약점을 만들고 있으며, 시니어 프로그래머는 기업의 코드베이스에 익스플로잇 (exploits, 공격 코드)을 심어 넣고 있습니다. 모든 당사자는 회사를 파멸시킬 수 있는 민감한 데이터를 유출할 합리적인 위험을 안고 있습니다. 이것이 명백한 문제임에도 불구하고, 왜 인공지능 기업들은 해결책을 내놓지 못했을까요? 아마도 더 강력한 에이전트 도구 (agentic tools)를 만드는 방식 자체가 보안 결핍의 원인일 가능성이 높습니다. 구체적으로, 에이전트들은 "GitHub에서 사용 가능한 오픈 소스 코드를 통해 학습되며... 오픈 소스 저장소에서 특정 버그가 더 눈에 잘 띄는 경우, 해당 버그들이 더 자주 재현될 것이다" (Pearce et al.)라는 점 때문입니다.

결론 (Conclusion)

수년에 걸쳐 AI 지원 개발 (AI-assisted development)의 속도와 기능성은 어떤 개발자라도 피할 수 없을 만큼 매우 가치 있는 것이 되었습니다. 하지만 급격히 발전하는 능력으로부터 얻는 즉각적인 이점만이 전부는 아닙니다. 프로토타이핑 (prototyping)과 반복 (iterating)이 그 어느 때보다 쉬워진 반면, 유지보수 (maintenance)와 보안 (security)이 병목 현상 (bottleneck)이 되었습니다. 개발자의 역할은 근본적으로 실행 (execution)에서 수리 (repair)로 전환되었습니다. 코딩 에이전트 (coding agents)는 인간이 검증해야 하는 문제를 해결하기 위해 코드를 보완합니다. 올바르게 활용된다면 소프트웨어 개발에 장벽은 없습니다. 경험에 관계없이 애플리케이션을 생성하거나 편집하는 일을 몇 분 만에 완료할 수 있습니다.

PART 2 — 구축 (The Build)

가이드 (Instructional Guide): 비기술적 창업자가 코드를 직접 작성하지 않고 Claude Code를 사용하여 작동하는 웹 앱 MVP (React + Supabase + Vercel)를 어떻게 구축하고 배포할 수 있을까요?

연구를 살펴본 후 두 가지 사실이 명확해졌습니다. 작동하는 프로토타입을 만드는 데 더 이상 코딩 방법을 알 필요는 없지만, 코딩 에이전트가 그 프로토타입을 스스로 안전하게 지켜주지는 않는다는 점입니다. Claude Code와 같은 에이전트 도구 (agentic tool)를 사용하면 이제 비기술적 창업자가 언어만으로 실제 웹 앱을 구축하고 배포할 수 있지만, 에이전트의 속도가 보안이나 범위 (scope)까지 확장되지는 않습니다. 따라서 인간에게 남겨진 작업은 무엇을 구축할지 결정하고, 구축된 내용을 검증하는 것입니다. 이 가이드는 앱 정의, React, Supabase, Vercel을 통한 Claude Code의 생성, 그리고 라이브 서비스 전 취약점 (vulnerabilities) 점검에 이르기까지 창업자를 위한 전 과정을 안내합니다. 이 과정을 마치면 직접 배포한 작동하는 웹 앱과 이를 다시 수행할 수 있는 반복 가능한 방법을 갖게 될 것입니다.

시작하기 전에 (Before You Start)

성공 기준 (Success Criteria)

성공 기준은 _최소한의 상태를 유지하는 것 (staying minimal)_입니다. 불필요한 기능이나 제품에 시간과 비용을 낭비하지 말고, 초기 프로토타입에 필요한 것만 구축하십시오.

  • Viable (실행 가능한): 핵심 문제만을 해결하며, 그 외의 것은 다루지 않습니다.
  • Working (작동하는): 핵심 경로 (critical paths)가 기능해야 합니다. 즉, 사용자가 가입하고, 핵심 동작을 수행하며, 데이터가 지속적으로 유지(persist)되어야 합니다.
  • Secure (보안이 유지되는): 기본적인 보안 파이프라인 (security pipeline)을 통과해야 합니다. 노출된 키가 없어야 하며, 실제 인증 (authentication)이 이루어지고, 데이터베이스 규칙 (database rules)이 잠겨 있어야 합니다.

Two side-by-side pyramid diagrams contrasting a layered product build with a 'true MVP' slice, illustrating the lean-startup MVP concept.

그림 1. MVP의 린 스타트업 (lean-startup) 정의: 실행 가능하고, 작동하며, 보안이 유지되는 것, 그 이상은 필요하지 않습니다.

설정할 도구들

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0