▲

nokode - LLM이 다 할 수 있다면 왜 코드를 작성해야 할까? (웹앱 실험)

 (github.com/samrolken)
6P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 애플리케이션 로직이 전혀 없는 웹 서버를 구축해, LLM이 모든 요청을 처리하도록 한 실험
    • 서버는 단순히 HTTP 요청을 받아 LLM에 “무엇을 해야 하는가?” 를 물어보고, 나머지는 LLM이 모두 수행
  • 서버는 database, webResponse, updateMemory 세 가지 도구만을 사용해 CRUD 기능을 수행
  • LLM이 SQL 스키마 설계, HTML·JSON 생성, 피드백 반영까지 스스로 수행하며 기본적인 연락처 관리 앱 구현
  • 응답 속도는 30~60초, 비용은 전통적 웹앱 대비 100~1000배 높고, UI 일관성과 기억력 문제 존재
  • 그럼에도 코드 없이 작동하는 완전한 CRUD 앱 구현 가능성을 보여, 코드 자체가 과도기적 개념일 수 있음을 보여줌

배경

  • “언젠가는 우리가 코드를 작성할 필요가 없게 될 것”이라는 공상적인 발상(Shower Thought) 에서 시작함
    • 미래에는 LLM이 실시간 입력을 처리하고 120fps 비디오를 출력하며, 앱도 코드도 없는 순수한 의도 기반 컴퓨팅이 가능할 것
  • 현실에서는 아직 공상과학의 영역이지만, 주말 동안 실험 삼아 “지금의 기술로는 어디까지 가능한가”를 직접 테스트하기로 함
  • 실험의 가설은 실패를 예상한 상태에서 출발했음
    • 대부분의 AI가 코드를 생성하는 방향(예: Claude Code, Cursor, Copilot 등)에 집중하는 상황에서,
      “코드 생성을 완전히 생략하면 어떨까?” 라는 다른 관점을 검증하기 위해 프로젝트를 만들어봄
  • 결과적으로 라우트, 컨트롤러, 비즈니스 로직이 전혀 없는 HTTP 서버를 만들어, 모든 요청을 LLM에게 “무엇을 해야 하는가?”라고 묻는 형태로 작동
  • 실험의 목표는 “그 미래가 실제로 얼마나 멀리 있는가”를 증명하는 것

프로젝트 개요

  • nokode는 “애플리케이션 로직이 없는 웹 서버”를 구축해, 모든 요청을 LLM이 처리하는 구조를 테스트한 실험
    • 서버는 단순히 HTTP 요청을 받아 LLM에 “무엇을 해야 하는가?” 를 물어보고, 나머지는 LLM이 모두 수행
  • 목표는 코드 생성 없이 LLM이 직접 애플리케이션 로직을 수행할 수 있는지 검증하는 것
  • 실험 대상은 연락처 관리 앱(contact manager) 으로, 기본적인 CRUD 기능(입력, 조회, 수정, 삭제)을 포함

시스템 구성

  • 백엔드는 단 3개의 도구로 구성
    • database: SQLite에서 SQL 실행, LLM이 스키마를 직접 설계
    • webResponse: HTML, JavaScript, JSON 등 적절한 형식으로 응답 생성
    • updateMemory: 사용자 피드백을 마크다운으로 저장해 다음 요청 시 참조
  • 예시로 /contacts 요청 시 HTML 페이지, /api/contacts 요청 시 JSON 응답 생성
  • 각 페이지에는 피드백 위젯이 포함되어, “버튼을 크게 해줘”, “다크 테마로 바꿔줘” 같은 요청을 즉시 반영

실험 결과

  • 기능적으로는 작동 성공
    • 폼 제출, 데이터 저장, UI 표시, API 응답 모두 정상 동작
    • LLM이 예시 없이도 적절한 데이터베이스 스키마, 안전한 SQL, REST형 API, 반응형 레이아웃, 폼 검증, 에러 처리를 생성
  • 성능 문제
    • 요청당 30~60초 소요로 기존 웹앱(10~100ms) 대비 300~6000배 느림
    • 요청당 $0.01~0.05 비용 발생으로 100~1000배 비쌈
    • UI 색상·레이아웃 불일치, 이전 상태 기억 불가, 잘못된 SQL 생성 시 즉시 오류 발생
    • “⚡ THINK QUICKLY” 같은 프롬프트 최적화 시도는 오히려 속도 저하

결론 및 시사점

  • LLM이 애플리케이션 로직을 직접 수행할 수 있는 능력은 존재
  • 문제는 속도, 비용, 일관성, 신뢰성 등 성능적 한계
  • 그러나 이러한 한계는 정성적 문제보다 정량적 개선의 영역으로,
    • 추론 속도는 매년 약 10배 향상
    • 비용은 하락 추세
    • 컨텍스트 길이 확장으로 기억력 개선 가능성
    • 오류율 감소 추세
  • 결과적으로, “AI가 코드를 작성하는 시대”보다 “AI가 직접 실행하는 시대” 가 더 가까울 수 있음
  • 현재 남은 것은 HTTP 설정, 도구 정의, DB 연결 등 인프라 수준의 코드뿐이며,
    장기적으로는 “의도와 실행만 존재하는 컴퓨팅” 으로의 전환 가능성 제시

실행 방법

  • npm install 후 .env 파일에 LLM 제공자와 API 키 설정
  • npm start 실행 후 http://localhost:3001 접속 (첫 요청 30~60초 소요)
  • prompt.md를 수정해 앱 종류나 기능을 변경 가능
    • /game, /dashboard, /api/stats 등 다양한 경로 시도 가능
    • “make this purple”, “add a search box” 등 피드백 입력으로 즉시 반영
  • 요청당 비용은 모델에 따라 $0.001~0.05 수준
  • MIT 라이선스로 공개
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 나도 비슷한 생각을 해왔음

    1. 만약 코드 생성이 완전히 자동화되어 모든 Google 검색이 실시간으로 맞춤형 페이지를 만들어낸다면, 더 이상 사람이 웹사이트를 만들 필요가 없게 되는 것 아님? 그 시점에서는 ‘웹 개발’이 코딩이 아니라 의도 설계(intent-shaping) 에 가까워질 것 같음
    2. 또, 채팅이 사용자 인터페이스의 이상형이라는 주장에는 동의하지 않음. 자연어는 유연하지만 느리고 모호하며 인지 부담이 큼. 아마도 LLM 기반 시스템은 대화와 구조화된 상호작용을 결합한 새로운 UI 모델이 필요할 것 같음

  • ChatGPT 3.5가 등장했을 때 이런 생각을 처음 했음
    언젠가 AI가 프로그램을 완전히 대체할 수 있을지도 모르지만, 진짜 핵심은 올바른 추상화(abstraction) 를 찾는 일임
    예를 들어 CVS에서 Git으로의 전환이 마이크로서비스 시대를 열었듯, 좋은 추상화는 문제를 근본적으로 바꾸는 힘이 있음
    LLM이 이런 추상화를 스스로 발견하려면 현실 세계와 오래 상호작용하며 학습해야 함

  • LLM이 직접 코드 파일을 수정할 수 있는 도구를 추가하면, 응답 속도와 일관성이 크게 향상될 것 같음
    코드가 일종의 기억 저장소(memory) 역할을 하게 되는 셈임
    LLM에 직접 HTTP 요청을 보내는 건 캐시 미스와 비슷하고, 코드 업데이트를 트리거하는 피드백 메커니즘도 유지할 수 있음

    • 이건 단순한 실험이었고, 아직 병목이 많음을 보여주려는 의도였음
      최적화 여지는 많지만, 현실적으로는 여전히 전통적인 코딩 방식이 더 효율적일 것 같음
    • 이런 구조는 마치 씨앗(seed) 을 심는 것처럼, 성장 방향과 경계를 정의하는 일임
    • 직접 만들어보면 좋겠음

  • “비결정적(non-deterministic) 동작이 가능하다면 왜 굳이 결정적이어야 하나?”라는 질문처럼 들림
    하지만 대부분의 사람은 매번 다르게 작동하는 웹앱을 원하지 않을 것 같음

    • 사실 사람들은 “웹앱” 자체를 원하는 게 아니라 문제 해결(solution) 을 원함
      결정론적 코드는 복잡한 문제를 다루기엔 한계가 있고, 인간처럼 유연한 접근이 더 적합할 수도 있음
    • 지금의 LLM은 주로 텍스트 출력에 제한되어 있고, 장기 기억도 거의 없음
      하지만 미래에는 LLM이 더 풍부한 출력과 저장 능력을 가지게 될 것임
      예를 들어 LLM이 직접 링크를 생성해 클릭하면 내부적으로 다시 질의하거나, 임시 데이터베이스를 관리하는 식으로 작동할 수 있음
    • 내 의도는 비결정적 행동이 좋다는 게 아니라, 지금과 포스트 코드(post-code) 시대 사이의 간극을 보여주려는 것임
    • 사실 오늘날의 소프트웨어도 완전히 결정적이지 않음
      자동 업데이트, A/B 테스트, UX 변경 등으로 사용자 경험이 계속 바뀜
    • 온도(temperature)를 0으로 두고 LLM이 설정을 로컬 파일에 저장하도록 하면, 결정적 앱을 만들 수도 있음

  • 흥미롭게도, 이런 접근은 별도 도구 없이 컨텍스트 윈도우만으로도 작동함
    2025년 7월에 POC를 만들어봤음

  • 이 실험은 “보일러플레이트 코드의 개념이 어떻게 변할까”를 잘 보여줌
    여러 인스턴스를 샌드박스에서 동시에 실행하고, 내부 평가로 가장 잘 수행한 결과를 제공하면 일종의 메타 강화학습(meta reinforcement learning) 이 됨
    다만 사용자의 의도를 결정적 출력으로 번역하는 게 어렵고, 반대로 전통적 앱은 유연성이 부족함
    결국 의도 해석(intent evaluation) 을 어떻게 안정적으로 구현하느냐가 핵심임

    • 하지만 내부 평가 방식에 맞춰 모델이 과적합될 위험이 있음
      좋은 평가 메서드를 만드는 일 자체가 AI 모델을 만드는 것만큼 복잡함

  • 전통적인 방식으로 요청을 처리하는 게 LLM을 직접 쓰는 것보다 비용 효율이 훨씬 높음
    대략 70억 파라미터 모델로 10토큰을 생성하는 데 100 GFLOPs 이상이 필요함
    전력 낭비가 심함

    • 하지만 인간 노동의 에너지 비용도 계산에 포함해야 하지 않을까 생각함
      엔터프라이즈 IT에서 일하다 보면 인간의 비효율도 만만치 않음
    • 산업의 방향은 항상 최적화와 일치하지 않음
      비효율조차 트렌드가 되는 게 현실임
    • 그래도 LLM으로 빠르게 프로토타입(V1) 을 만든 뒤, 제품-시장 적합성을 확인하고 나서 전통적 코드로 최적화하는 접근은 유효함

  • 그냥 LLM을 포트 443에 올려서 “너는 HTTPS 서버이자 앱 서버야”라고 시키면 될지도 모르겠음 ;)

  • 굳이 웹앱이 필요할까? 그냥 음성으로 컴퓨터와 대화하면 되지 않나?
    “작년 휴가 때 찍은 사진 보여줘, 구름은 지워줘, 친구한테 보내줘”
    “운동 타이머 설정해줘, 점핑잭은 빼줘”
    “디트로이트 스타일 테크노 비트 만들어줘”
    “오늘 밤 데이트 상대 찾아줘, 검은 머리 선호해”
    이런 식으로 모든 걸 말로 처리하는 세상을 상상해봄

    • 하지만 이런 자동화는 인간의 자율성(agency) 을 약화시킬 수 있음
      결국 이를 받아들이는 사람과 거부하는 사람으로 인류가 나뉠 것 같음
      이미 바이닐 음반의 부활 같은 현상에서 그 조짐이 보임
    • 음성 인터페이스가 모든 커뮤니케이션의 해답은 아님
      인간끼리도 종종 텍스트를 선호함
    • 나도 이번 주에 WebSpeech로 음성 입력을 받아 org-mode와 logseq 파일을 읽고 수정하는 개인 지식관리 앱을 만들어봤음
      할 일, 장보기, 일정 관리까지 다 되고, 완전히 내 필요에 맞게 커스터마이즈됨
    • 이런 미래는 공상과학에서 자주 다뤄졌음
      복잡한 작업은 음성으로 충분히 표현되지만, 단순 반복 작업은 UI가 더 효율적임
      예를 들어 “바지 사줘”라고 말했을 때 30개 결과 중 하나를 고르려면 결국 시각적 인터페이스가 필요함

  • 나도 비슷한 PoC를 GitHub에 올려둠
    초기에는 느린 ‘디자인 모델’로 앱 테마와 DB 스키마를 만들고, 이후 빠른 모델로 응답을 처리함
    PostREST를 써서 로직을 DB에 넣어봤지만, 스키마 생성 실패나 잘못된 쿼리 생성이 잦았음
    CSS 라이브러리로 UI 일관성을 유지했고, 이전 페이지를 기억하도록 함
    이런 접근은 LLM이 한 번에 완전한 앱을 만들 수 있는지를 평가하는 App Bench로 활용할 수 있을 것 같음

답변달기