▲

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

 (github.com/samrolken)
8P by GN⁺ 2달전 | ★ favorite | 댓글 2개
  • 애플리케이션 로직이 전혀 없는 웹 서버를 구축해, 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 라이선스로 공개
▲
aer0700 1달전  [-]

컴퓨팅이 어디까지 빠르고 저렴해 질지가 문제 겠네요.
평균적인 서버가 지금 보다 10만배 빨라지는, 그런데도 운영비용이나 설치비용은 그대로인 미래라면, 저것도 맞는 방법일듯 합니다.
컴퓨팅이 저렴해지면서 기계어 대신에 c로 넘어가고, c대신 node js나 python으로 넘어갔듯, 앞으로는 llm으로 넘어갈지도요.
많은 것이 바뀔테고, 나름 재밌을 듯 합니다. 여러 기회가 생길 거고요.

답변달기
▲
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로 활용할 수 있을 것 같음

답변달기