▲

Claude 코드로 Mac 앱 만들기

 (indragie.com)
9P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • Claude Code로 2만 줄 이상의 macOS 앱 전체 코드를 거의 모두 생성하여 출시, 직접 작성한 코드는 1,000줄 미만임
  • AI 코딩 에이전트의 등장과 함께, 기존 IDE가 아닌 프롬프트 중심의 개발 경험을 하게 됨
  • Swift와 SwiftUI 코드 생성은 다소 한계가 있으나, 프라이밍, 컨텍스트 엔지니어링, 피드백 루프 설계로 품질을 높일 수 있음
  • 자동화, 배포, 문서화, 테스트까지 대부분 Claude가 처리, 반복적 수동 작업과 시간 소모를 획기적으로 줄임
  • 미래의 IDE는 코드 에디터 대신, 에이전트 활용과 컨텍스트 관리가 중심이 되는 새로운 UX로 진화할 것임

Claude Code만으로 macOS 앱을 출시한 경험

프로젝트 개요

  • 최근 Context라는 macOS 네이티브 앱을 출시함. MCP 서버 디버깅을 위한 개발자 도구임
  • 이 앱은 거의 100% Claude Code로 만들어졌음. 약 2만 줄 중 직접 작성한 코드는 1,000줄도 되지 않음
  • Claude로 소프트웨어를 만드는 데는 여전히 개발자의 실력과 반복 작업, 프롬프트 작성 역량이 필요함
  • 이번 글은 Claude Code를 이용해 앱을 만드는 전 과정, 도구 선택, 장단점, 고품질 코드 생성을 위한 방법 등을 상세하게 설명함

1. Copilot에서 Claude Code로, 그리고 개발 환경의 변화

  • 처음 사용한 AI 코딩 도구는 GitHub Copilot이었으며, 단순 자동완성만으로도 개발 효율이 크게 증가함을 체감함
  • 이후 Cursor의 에이전트 모드, Windsurf 등 코드 기반에 컨텍스트를 수집하고, 빌드·테스트 반복까지 자동화하는 에이전트형 툴이 쏟아짐
  • Claude Code는 기존 에디터(예: VS Code)와 달리 터미널 전용, 프롬프트 입력 중심의 순수 에이전트 환경을 추구함
  • 기존 IDE 기능 대부분이 빠진 채, 프롬프트 박스 하나와 결과만 보여주는 단순한 UX임
  • 코딩 에이전트가 기존 IDE를 보조하는 것이 아니라, 아예 IDE를 대체하는 시도를 함
  • 사용자 인터페이스 및 사용 경험이 기존 도구와 달라서 UX에 대해 회의적이었으나, 새로운 접근방식에 매력을 느껴 사용해보기로 함

2. 사이드 프로젝트를 다시 시작하다

  • 직장 생활을 병행하는 많은 개발자와 마찬가지로, 미완성된 사이드 프로젝트가 쌓여만 감
  • 프로토타입은 금방 만들지만, 마지막 20% 완성 단계에서 시간과 에너지가 부족해 실제 출시까지 이어지지 못함
  • MCP 서버를 테스트하는 경험에서, 네이티브 앱이 필요하다는 생각에 직접 앱을 만들기로 결정함
  • 이 과정에서 Claude Code를 본격적으로 활용하기 시작했고, AI 에이전트가 실제로 얼마나 큰 도움을 주는지 체감함

3. Claude Code의 뛰어난 코드 생성 능력

  • 최신 Sonnet 4, Opus 4 모델을 사용하는 Claude Code는 진짜로 좋은 코드를 빠르게 만들어냄
  • 프로젝트 맥락을 읽고, 코드 스타일을 파악하고, 관련 문서·스펙을 읽어 기능을 구현하며, 테스트 코드도 자동 작성함
  • 빌드, 테스트 반복, 콘솔 로그·스크린샷 분석, 버그 고치기까지 거의 자동화됨
  • 실제로 개발자가 코드를 작성하는 시간의 극히 일부만으로 고퀄리티 결과물을 생성함
  • 신입 사원이 아무런 맥락 없이 프로젝트에 투입되어도, 몇 분 만에 기능을 완성하는 수준을 구현함

4. Swift와 SwiftUI 지원의 실제 품질

  • Swift 6.1, macOS 15.5, 최신 SwiftUI를 활용
  • Claude는 Swift 5.5까지는 대부분 잘 다루지만, 동시성 등 최근 변화에는 취약함
  • 현대 API와 레거시 API, Objective-C와 SwiftUI를 혼용해 실수하는 경우도 있음
  • SwiftUI 코드의 경우 초안은 다소 미완성·투박하지만, 반복적으로 지시하면 충분히 잘 다듬어짐
  • UI 코드가 복잡할 때 컴파일러 에러(타입 추론 실패 등)가 발생하는데, Claude는 이를 자동으로 더 작은 함수로 리팩터링할 수 있음
  • CLAUDE.md 파일에 지침을 명시하면, Claude의 코드 품질을 한 단계 더 끌어올릴 수 있음
    • 예: SwiftUI 우선 사용, Apple Human Interface Guideline 준수, 최신 macOS 및 Swift6 기능 적극 활용 등
  • 추가적으로 agent-rules 리포지터리의 가이드라인을 활용하면 더욱 품질 높은 코드 생성이 가능함

5. "더 예쁘게 만들어줘" 라고 요청 가능

  • Claude에게 "더 아름답게/우아하게/사용성 좋게 만들어줘" 등 간단한 프롬프트만으로 UI 디자인을 개선할 수 있음
  • UI 버그나 개선점은 스크린샷을 Claude에 붙여넣어 반복적으로 피드백을 주면 즉시 반영됨
  • 보다 체계적으로는, 먼저 "어떻게 하면 UI가 더 아름다워질지 제안해줘"라고 요청한 뒤, 그 중 원하는 변경만 골라 적용시키는 식도 가능함

6. 컨텍스트 엔지니어링의 중요성 중요성

  • 최근 AI 모델은 불완전한 프롬프트, 문법적 오류가 있어도 상당히 잘 이해함
  • 진짜 중요한 것은, 제한된 컨텍스트 윈도우(200k 토큰) 내에서 최대한 필요한 정보만 배치하는 것
  • Claude는 대화의 맥락이 가득 차면 자동 요약(compaction) 후 컨텍스트를 재설정하는데, 이 과정에서 디테일 누락 또는 품질 저하 현상 같은 정보 일부 손실 위험이 있음
  • 따라서, 제한된 맥락 내에서 최대한 높은 품질 값을 도출하는 'context engineering' 이 AI 에이전트 사용의 핵심 과제임

7. 에이전트 프라이밍

  • 이 compaction 과정에서 중요한 맥락이 누락될 수 있으니, 필요한 경우 수동으로 요약하게 하거나, 추가 정보를 프라이밍(미리 읽히기)하는 것이 효과적임
  • CLAUDE.md 외에도 직접 특정 소스코드, 스펙 문서 등을 미리 읽히고 요약하도록 프롬프트를 작성하면 출력 품질이 향상됨
  • 새로운 라이브러리나 최신 API 등 Claude의 지식 cutoff 이후 등장한 내용도 특정 도구(Context7, llm.codes 등)로 문서를 변환해 Claude가 이해하기 쉽게 만들 수 있음
  • 프라이밍은, "이 소스파일·문서·스펙을 모두 읽고 요약해봐"처럼 지시해 Claude가 먼저 맥락을 완전히 이해하도록 만드는 과정임

8. 에이전트는 명확한 명세(Spec)가 필요함

  • Claude에 기능 구현을 시킬 때, 반드시 구체적이고 상세한 스펙을 입력해야 원하는 결과를 얻을 수 있음
  • 흔히 시연에서 보여주는 "한 문장 프롬프트로 앱 만들기"는 사실상 프로토타입 수준만 가능
  • 스펙이 정교하지 않아도, 음성 입력이나 타이핑 등 편한 방식으로 설명하면 됨

9. "Ultrathink and Make a Plan"

  • Claude가 무작정 구현에 돌입하면 출력 품질이 저하되므로, 'think' 'ultrathink' 등 확장적 사고 모드로 우선 계획을 세우도록 요청하는 전략이 효과적임
  • 단계별로 구현 전 계획 검토와 피드백 후 작업하게 하면 품질이 올라감
  • Anthropic의 Claude Code: Best practices for agentic coding 문서를 필독 자료로 권장

10. 피드백 루프 구축

  • Claude Code의 진정한 강점은 독립적으로 피드백 루프를 구동할 수 있을 때 극대화됨
  • 즉, Claude가 직접 코드를 수정하고(변경), 빌드하고(테스트), 실패 원인을 분석해서(컨텍스트 수집), 다시 반복하는 자동화 사이클을 만드는 것이 핵심임
  • 이런 루프를 잘 설계할수록, Claude가 더 자율적으로 고품질 코드를 완성할 수 있음
  • 1. Build (빌드)
    • Claude는 앱을 빌드(컴파일)하는 과정을 스스로 수행해야 함
    • Swift 패키지의 경우 swift build 명령으로 쉽게 빌드 가능, Claude가 이를 자연스럽게 처리함
    • 그러나 macOS 앱 타깃(예: Xcode 프로젝트)의 경우, 어떤 xcodebuild 명령을 써야 하는지 Claude가 종종 헷갈려 함
    • 이 문제를 해결하기 위해 XcodeBuildMCP라는 툴을 사용, Claude가 앱 빌드 및 실행을 좀 더 쉽게 하도록 단순화된 인터페이스 제공
  • 2. Test (테스트)
    • Claude는 코드를 빌드한 뒤, 자동으로 테스트를 실행하고 그 결과를 분석할 수 있어야 함
    • Swift 패키지는 swift test로 자연스럽게 테스트를 수행, Claude도 이 과정을 잘 처리함
    • 아직 앱 전체 테스트나 UI 테스트를 Claude가 직접 돌리는 것은 실험하지 않았으나, 이 역시 XcodeBuildMCP와 같은 툴이 필요할 것으로 예상
    • 테스트의 결과(성공/실패 로그)를 바탕으로 코드 수정 루프를 이어감
  • 3. Fix Bugs (버그 수정)
    • Claude는 디버깅을 위해 로그를 추가하는 방식으로 문제를 추적할 수 있음
    • 다만 Claude가 직접 앱을 조작해서 로그를 발생시키는 것은 불가능
    • 사용자가 앱을 수동으로 조작한 뒤, 콘솔에서 로그를 복사해 Claude에 붙여넣는 과정이 필요함
    • 이 방식도 실질적으로 잘 작동하지만, 유닛 테스트나 UI 테스트를 미리 충분히 작성하지 않으면 완전한 자동 버그 수정은 어려움
    • 웹 앱의 경우 playwright-mcp 같은 브라우저 자동화 솔루션이 있으나, 네이티브 앱은 아직 확실한 대안이 부족함
  • 4. Fix UX Issues (UX 이슈 수정)
    • UI/UX 이슈 개선에는 스크린샷을 Claude에 직접 붙여넣어 반복 피드백을 줄 수 있음
    • Peekaboo 같은 도구로 스크린샷 자동화도 가능하지만, 일단 앱을 원하는 상태로 수동 조작해야 스크린샷을 찍을 수 있다는 점은 한계
    • 즉, UX 관련 자동화도 사용자 개입이 여전히 필요함

11. Claude Code는 코드 작성하는 이상의 일을 함

  • Claude Code는 범용 대형언어모델(LLM)을 기반으로 동작하기 때문에, 코드 작성 외에도 다양한 비개발 업무에 활용 가능함
  • 예를 들어, 앱 내 카피 문구 편집, 릴리즈 플랜 수립, 기능 개선 방향 제안 등 개발 외적인 작업도 Claude에 자연스럽게 요청할 수 있음
  • 특히 유용했던 점 중 하나는, 실제 데이터가 없는 초기 단계에서 Mock 데이터를 자동으로 만들어주는 기능임
    • Context 앱 개발 당시, Swift용 MCP 클라이언트 라이브러리를 아직 완성하지 않은 상황에서도 UI 프로토타입 작업을 진행하고 싶었음
    • 원래라면 현실적으로 보이는 모크 데이터를 직접 만들어내는 작업은 매우 번거롭고 시간이 많이 소요되어, 사실상 시도하지 않았을 것임
    • 그러나 Claude는 몇 초 만에 매우 그럴듯한 Mock 데이터를 자동 생성, 실제와 거의 구분이 어려울 정도의 UI 상태를 만들어줌
    • 실제로 UI를 친구들에게 공유할 때도, 이 Mock 데이터를 기반으로 한 스크린샷을 사용했으며, 실 서비스와 동일한 수준의 인상을 줄 수 있었음
    • MCP 서버의 경우, 당시에는 공식 스펙의 일부 기능만 구현된 상태가 많아 실제 데이터를 얻기 어려운 상황이었음
    • 그럼에도 불구하고, Claude가 생성한 Mock 데이터를 통해 전체 UI 흐름과 기능 동작을 검증할 수 있었음

12. 고품질 자동화 구현이 (거의) 무료가 된 시대

  • 소프트웨어 출시의 마지막 20%에서 가장 고통스러운 부분 중 하나는, 앱 릴리스 과정의 자동화임
  • 특히 macOS 앱의 경우, 코드 서명, 노타리제이션, 패키징(DMG 생성) 등 복잡한 배포 절차가 많아 수작업이나 불안정한 스크립트로 인해 출시가 지연되는 일이 많았음
  • 기존에는 fastlane 등 자동화 도구를 억지로 세팅하거나, 최소한의 Python 스크립트를 직접 작성해 처리했음
  • 이번 프로젝트에서는 몇 시간의 반복 프롬프트와 디버깅만으로, Claude가 완전한 릴리스 자동화 스크립트를 생성함
  • 이 스크립트가 담당하는 주요 업무:
    • 환경 세팅 체크: 필요한 도구들이 제대로 설치되어 있는지 점검
    • 변경 로그 자동 생성: git 커밋에서 변경 이력을 추출, 수기로 작성한 항목과 합쳐 HTML 릴리즈 노트 생성
    • 앱 빌드 및 패키징: 앱 빌드 → 코드서명 → 노타리제이션 → DMG 패키징까지 전 과정 자동화
    • Sparkle 업데이트 피드(appcast) 생성: 기존 사용자에게 자동 업데이트 전달
    • 릴리스 태그 및 배포: 깃허브에 태그 추가 및 릴리스 게시
    • Sentry 심볼 업로드: 크래시 리포트 분석을 위한 디버그 심볼 자동 업로드
  • 스크립트 완성 후, "CLI 출력을 더 아름답게 만들어줘"라는 한 줄 프롬프트만으로 CLI UI 개선까지 구현
  • 최종 결과는 약 2,000줄에 달하는 Python 코드로, 수작업이었다면 필수 기능만 구현하고 끝냈겠지만 Claude 덕분에 고품질로 마무리
  • 이 자동화 스크립트 덕분에 릴리스마다 매번 수십 분의 반복 작업을 절약할 수 있게 됨
  • 자연어로 스펙을 설명하고, 실행 중 발견된 오류만 Claude에게 피드백해 수정하게 하면 대부분의 작업이 완료됨

13. 미래 IDE는 완전히 달라질 것

  • 이번 프로젝트를 진행하면서 실제로 처음부터 끝까지 사용한 툴은 Claude Code와 GitHub Desktop(diff 보기 용) 두 가지뿐이었음
  • 전통적인 IDE의 핵심 기능인 파일 트리, 코드 에디터, 확장 기능, 플러그인 등은 거의 필요하지 않았음
  • 드물게 Xcode를 열어 직접 코드를 고친 적은 있지만, Xcode 특유의 기능(예: SwiftUI Previews, View Debugger 등)도 거의 사용하지 않음
  • 지금이야말로 AI 코딩 에이전트의 역량이 가장 낮은 시점이기 때문에, 앞으로 IDE는 완전히 새로운 형태로 진화할 것으로 예감함
  • Copilot, Cursor, Windsurf 등은 모두 VS Code에서 출발해 기능을 추가한 방식이지만, VS Code 자체는 20년 전 JetBrains IDE와 거의 차이가 없음
  • Warp와 같은 프로젝트는 터미널을 현대적으로 바꿔 에이전트 개발 환경으로 전환하려 하지만, 터미널 중심 UX 역시 미래의 궁극적 해답은 아닐 것이라고 평가함
  • 미래 IDE의 핵심은, 개발자가 에이전트 컨텍스트를 효과적으로 준비(priming)하고, 피드백 루프를 설계·관리할 수 있게 해주는 것에 있음
  • 즉, 코드 에디터가 중심이 아니라, 에이전트 활용과 컨텍스트 관리 중심의 UX로 크게 변화할 것이라는 전망임

14. 다시 사이드 프로젝트를 출시할 수 있게 됨

  • 이번 여정에서 가장 인상 깊었던 점은 멋진 앱을 만들었다는 사실보다, 다시 직접 사이드 프로젝트를 실제 출시할 수 있게 된 점임
  • 마치 매일 5시간의 추가 시간을 얻은 느낌, 그리고 그 대가는 한 달에 $200에 불과함
  • Claude Code와 같은 AI 코딩 에이전트 덕분에, 오랫동안 미뤄왔던 아이디어를 현실로 옮길 수 있는 동력과 자신감을 다시 얻게 됨
▲
GN⁺ 6시간전  [-]
Hacker News 의견

  • 2년 전만 해도 나는 진짜 뛰어난 Python 엔지니어였다고 자신했는데, 이제는 네이티브 모바일 앱, Slack과 통신하는 데스크톱 앱, Go로 작성한 API, React 기반의 전체 웹 앱까지 며칠 또는 몇 시간 만에 만들 수 있게 된 상태임
    마치 슈퍼파워를 얻은 기분이고, 생산성·속도·창의성이 샘솟는 느낌이지만, 한편으로 기묘한 슬픔도 느껴짐
    내 직업, 내 열정, 내가 오랜 시간 공들여 익히고 희생까지 했던 모든 일들이 이제 기계에 의해 대부분 대체되고 있음
    이런 툴을 만드는 회사들은 아직 출발점일 뿐임
    다음 세대 엔지니어에겐 어떤 의미가 있을지, 이 흐름이 어디까지 이어질지 궁금함
    혹시 나와 같은 감정 느끼는지 궁금함

    • 여러 플랫폼에서 네이티브, 모바일, Go, React 등 다양한 툴을 효율적으로 다루게 된 건 파이썬 엔지니어로서의 소프트웨어 개발 경험 덕분임
      LLM이 대체하는 영역은 각 플랫폼에 특화된 사소한 내용(트리비아)을 외울 필요가 없다는 점임
      나는 Go에서 for 루프 문법을 외우지 못해도, 바로 유용한 Go 코드를 작성 가능함
      여전히 루프, Go의 개념, 구조적 프로그래밍, 컴파일러, 빌드 및 테스트 스크립트 등 기본 원리를 이해해야 한다는 점은 변함없음
      프로그래밍에 배경지식이 없는 사람에겐 이 부분이 크게 부족함
      LLM은 내 오랜 경력에서 축적한 모호한 지식을 다양한 언어와 플랫폼에 곧바로 적용가능하게 해 주는 증폭기이자 가속기라고 느끼는 중임
      이전에는 Python, JavaScript, SQL만으로 모든 문제를 해결했던 이유가 새 언어·플랫폼의 사소한 차이들을 다시 익히기가 부담스러웠기 때문임
      이제는 Go, Bash, AppleScript, jq, ffmpeg 등도 기꺼이 사용하고, Swift 프로젝트도 고려 중임

    • 비전공자들이 LLM을 써서 뭔가 만드는 걸 본 적 있는데, 대개 훨씬 느리거나 거의 실패임
      기술 스킬이 결국 필수는 아닐 수 있지만, 명확한 의사전달 능력이 반드시 필요함
      HTML을 이해하는 수준만 되어도 텍스트를 깔끔하게 꽂아 넣어 LLM이 더 명확하게 이해하게 만들 수 있음
      여전히 기술적 배경이 장점이라고 생각함

    • 산업혁명 이전 수공업 노동자들도 비슷한 감정을 느꼈으리라고 생각함
      하지만 그들 대부분이 교육도 제대로 받지 못했고, 자녀 중 1~2명은 사소한 병으로 10살 이전에 죽었으며, 전기·수도·실내배관·냉장고 없이 살았다는 점을 감안해야 함
      직접 손으로 도구를 만드는 건 낭만적이지만(마치 파이썬 코드를 수작업하는 것처럼) 시대가 발전할수록 더 추상적인 층위에서 살아가는 게 오히려 조상들에게도 이득이라고 생각함
      누구도 자신이 직접 Python 코드를 짜는 걸 막지 않으며, 흑연세공처럼 취미로 즐기는 사람이 분명 생길 거라 생각함

    • 내가 일궈온 직업·열정·기술을 이제 기계가 대신한다는 생각에 동의하기 어렵다는 입장임
      기계는 경험이나 예지, 반성, 계획능력이나 창의성 없이 그저 지시를 따르는 존재임
      사람만이 아이디어·창의성·목표·공감능력을 갖고, 좋은 아이디어로 다른 사람을 설득하거나 상황에 맞게 맥락을 고려할 수 있음
      프로그래밍이라는 직업이 사라진다기보다는, 훨씬 높은 추상화 단계로 이동 중이라고 생각함
      과거에는 비트와 바이트, 어셈블리 한 줄 안 알아도 개발자가 될 수 있었고, 어셈블리가 필수이던 시절도 있었음
      이제는 프로그래밍 언어 자체를 몰라도, 영어와 요구사항만 잘 알면 프로그램이 만들어지는 시대임
      그래도 메모리 구조, 어셈블리, 저수준 개념을 아는 사람들은 여전히 뒤에서 무슨 일이 일어나는지 더 잘 이해하고, 필요하면 더 "잘" 할 수 있음
      그렇다고 상위 추상화 계층이 쓸모없어 지거나 사라진다고는 생각하지 않음

    • 나도 똑같이 느끼고 있음
      20년 넘게 소프트웨어를 프로로 개발했고, 정말 이 일이 즐거웠음
      지금은 Claude Code를 100% 활용하며 생산성이 분명히 올랐지만, 예전의 프로세스가 예술처럼 느껴졌던 반면 지금은 산업화된 대량생산 느낌임
      새 현실에서 소프트웨어에 깊이 빠져들 수 있었던 나만의 무언가를 다시 찾고 싶고, 그 재미가 많이 줄어든 건 확실함

  • 글이 매우 잘 쓰여 있고 읽는 것만으로도 즐거움임
    미래의 IDE는 지금과 전혀 다를 것임
    나 역시 Cursor로 시작해서, VS Code 강화형 IDE를 쓰다 결국 Claude Code로 넘어감
    그러다 보니 터미널의 중요성이 커져서 iTerm에서 Ghostty(빠르고 가볍고 최신임), Tmux, Tmuxinator, NeoVim으로 워크플로우를 넘어감
    cat 또는 bat 명령으로 파일을 확인하고, 간혹 텍스트 편집만 하며, 대부분의 무거운 작업은 Claude Code가 맡음
    NeoVim이나 Emacs에서 명세와 프롬프트만 작성하는 식이고, 이런 워크플로우가 너무 마음에 듦
    코드 생성뿐 아니라 zsh, neovim, ghostty 등 config 파일 수정할 때도 Claude Code로 태스크를 테스크를 할당해서 바꿈
    설정 파일 리팩토링까지 몇 분이면 끝임
    코드베이스 질문, 코드 리팩토링, 코드 문서화, 커밋 메시지 생성 등도 전부 맡겨서 Pure awesomeness임

    • 마지막에 코드베이스 질문, 리팩터링, 코드 문서화, 의미 있는 커밋까지 한다는 이야기가 나왔는데, 나도 CC로 훌륭한 커밋 메시지를 만들어서 Conventional Commits 정보와 예시를 CLAUDE.md 파일에 넣어둔 경험이 있음

    • CC가 .zshrc 같은 개인 설정 파일을 자동 백업해준 다음 변경하냐고 궁금함

  • Terminal + Claude Code + 프로젝트 폴더
    정말 이것만 있으면 충분하다는 걸 이제야 알게 됨
    풀 IDE 세팅이 번거로워서 원래도 안 즐겼고, OS 별로 크로스컴파일하려면 QT 설정도 복잡했는데, 항상 에디터와 터미널 조합이 가장 논리적이라고 생각했음
    여기에 Claude Code가 열린 또 하나의 터미널 창으로 요청 처리 도와주니, 개발자에서 프로젝트 리더로 '레벨업' 한 느낌임
    직원 관리 스트레스도 없음
    지금은 예전부터 해보려던 모든 사이드 프로젝트를 3월 Claude가 떴을 때부터 몇 달 만에 완성함

  • 1, 2년 전에 떠올린 게 있는데, LLM은 숙련 개발자에게는 뛰어난 어시스턴트, 숙련 개발자를 대체하려 하면 엉망, 그리고 미숙련 개발자에겐 위험한 어시스턴트라는 생각이었음
    직접 경험하면 대체로 이 생각이 들어맞음
    지금은 미숙련 개발자에게 LLM이 좋은 멘토가 될 수도 있다고는 생각하지만, 현실에서는 주로 코드의 동작 이유를 이해하지 못한 채 무작위로 수정하다가 그럭저럭 작동할 때까지 시도만 반복하는 경우가 더 많아 보임
    결국 그런 상황에서 LLM은 위험한 어시스턴트라는 초기 생각이 더 굳어진 상태임
    이럴 때는 미묘한 버그나 문제들이 눈치채이지도 않게 코드에 잠복하고, 알아차려도 그 원인을 이해하지 못하는 경우가 다반사임

  • LLM 어시스턴트 덕분에 사이드 프로젝트의 마지막 20% 완성도가 확 줄었다는 결론이 특히 인상적임
    내게 이 여정에서 가장 흥미로운 점은 새로운 앱보다, 코딩에 대한 갈증을 해소하고 깔끔한 사이드 프로젝트를 다시 완성도 높게 배포할 수 있게 된 현재임
    마치 하루에 5시간이 추가로 생긴 느낌이고, 한 달에 200달러면 충분함

  • 나는 작은 유틸리티를 만들 때 주로 활용하는데, 정말 환상적으로 잘 작동함
    launchctl/launchd 태스크 상태(실행/언로드/실패 등)를 OrbStack 메뉴 아이콘처럼 보여주는 유틸리티를 Claude로 몇 시간만에 원하는 모습으로 구현함

    • 나도 스스로 즐길 용도로 iOS 앱과 Wordpress 플러그인을 만들어서 정말 만족했음
      앞으로 더 많은 사람들이 이렇게 할 것 같은데, 다들 github에 코드를 공유해야 하지 않을까 궁금함

  • 2008년부터 Mac용 소프트웨어를 만들어 온 사람이라면 Claude가 어디서 잘못 나갔는지 빠르게 알아채고 바로잡을 수 있었을 거라고 생각함

    • Claude Code 같은 도구는 기존의 스킬과 경험을 증폭시키는 역할임
      결코 전문성을 대체하지 못함

    • 결국 글 마지막에 이 작업이 한 달에 200불이 든다는 사실이 드러나는데, 난 주 취미에 꼭 필요한 Autodesk에도 50불 쓰기 아깝게 느껴질 정도임
      이런 AI 회사들은 수익도 안 나고 투자자가 수익을 찾기 시작하면 비용 급등하거나 서비스 품질 저하가 불가피할 거라 생각함
      이 모델들이 무단으로 학습한 코드를 제공해서 소송에 져버린다면 Claude의 Swift 생성력도 즉시 하락할 것임
      과연 Disney가 AI 소송에서 질 거라 기대해야 하는지 의문임
      솔직히 내 코멘트가 의미는 없지만 AI 피로감이 정말 심각함
      지금 시점에 HN이나 여타 테크 포럼에서도 이런 포스트는 금지하는 게 맞다고 봄
      구글이나 StackOverflow로 쉽게 코드 짰다는 얘기를 누가 올리면 다들 시시하다고 빈정거릴 게 뻔한데, 이런 포스트도 결국 똑같다고 생각함
      AI로 취미나 직업을 "무임승차"한다는 얘기는 신물남

  • 나만의 맞춤형 툴을 Windsurf 같은 도구와 CLI 툴로 만드는 게 예전보다 훨씬 손쉬워졌음
    정말 흥미로운 시기임

  • 곧 누군가 LLM을 이용해서 MacOS 자체를 복제할 시대가 올 것 같은 예감임

  • 몇 주 전 LLM 툴링을 써서 retro68과 c++로 system 6(클래식 맥) 앱에서 6DOF 와이어프레임 렌더러를 부팅시키는 데 성공함

답변달기