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