바이브 코딩으로 꿈에 그리던 macOS 프레젠테이션 앱을 만들었다

LLM의 지난 1년간 발전 흐름은 2023년 12월, 2024년 12월, 2025년 12월에 글로 정리한 바 있다. 2025년 6월 AI Engineer World's Fair에서는 자전거 타는 펠리컨으로 살펴보는 LLM의 지난 6개월을 발표하기도 했다. 이번에는 다루는 기간을 3개월로 줄였는데, 이 분야가 얼마나 빠르게 가속하고 있는지를 단적으로 보여주는 변화다. 2025년 11월의 변곡점을 감안하면 충분히 적절한 선택이었다.

(이 가속을 몸소 보여주기 위해 Gemini 3 스웨터를 입고 발표에 나섰다. 불과 몇 주 전에 받은 옷인데, Gemini 3.1이 나오면서 이미 구식이 되어버렸다.)

발표를 할 때마다 최소한 하나의 기믹(gimmick)은 꼭 넣으려고 한다. 스탠퍼드에서 배운 STAR 모멘트 원칙, 즉 청중이 오래 기억할 만한 무언가(Something They'll Always Remember)를 심어야 발표가 돋보인다는 생각을 늘 염두에 두기 때문이다.

이번 발표에는 기믹을 두 개 준비했다. 전반부는 코딩 에이전트(coding agent)를 활용한 카카포(Kākāpō) 번식 시즌 데이터 분석을 중심으로 구성했고(덕분에 내 머그컵을 자랑할 기회도 생겼다), 이어서 자전거 타는 펠리컨 신작들을 간략히 소개한 뒤, 마지막에 반전을 공개했다. 발표 전날 밤 약 45분 만에 바이브 코딩으로 만든 macOS 앱으로 처음부터 끝까지 프레젠테이션을 진행했다는 사실이었다.

Present.app

앱 이름은 Present다. 머릿속에 처음 떠오른 이름을 그대로 붙였다. Swift와 SwiftUI로 만들었으며, 용량은 355KB, 압축 시 76KB에 불과하다. Swift 앱은 정말 가볍다!

만드는 데 시간이 얼마 걸리지 않았지만, 이 앱에 담긴 기능들은 수년간 원하던 것들이었다.

평소 발표할 때는 주로 Keynote를 쓰지만, 가끔은 웹 페이지를 순서대로 넘기는 방식을 택하기도 한다. 브라우저 창에 페이지마다 탭을 열어두고, 발표하면서 탭을 하나씩 클릭하는 방식이다.

이 방식은 꽤 잘 통하지만, 치명적인 약점이 하나 있다. 브라우저가 죽으면 슬라이드 덱 전체가 날아간다는 것이다!

URL은 항상 노트 파일에 따로 저장해두기 때문에, 필요하면 그걸 보고 직접 다시 열 수 있긴 하다. 하지만 발표 중에 그런 상황이 닥치는 건 상상하기도 싫다.

이것이 처음 입력한 프롬프트다:

Build a SwiftUI app for giving presentations where every slide is a URL. The app starts as a window with a webview on the right and a UI on the left for adding, removing and reordering the sequence of URLs. Then you click Play in a menu and the app goes full screen and the left and right keys switch between URLs

이 프롬프트에 대해 먼저 계획이 나왔고, 그 계획을 구현하는 대화 내용은 여기서 확인할 수 있다.

Present에서 발표 자료는 URL의 순서 목록으로 구성되며, 사이드바 UI에서 URL을 추가·삭제·순서 변경할 수 있다. 편집 기능은 이것이 전부다.

메뉴에서 "Play"를 선택하거나 Cmd+Shift+P를 누르면 전체 화면 모드로 전환된다. 좌우 방향키로 슬라이드를 넘기고, 필요에 따라 글꼴 크기를 조절하거나 페이지를 스크롤할 수 있다. 발표가 끝나면 Escape 키를 누르면 된다.

Present의 핵심 기능 중 하나는 변경 사항이 생길 때마다 URL을 자동 저장한다는 점이다. 앱이 갑자기 종료되더라도 다시 실행하면 발표 상태를 그대로 복원할 수 있다.

발표 자료를 .txt 파일(URL을 줄바꿈으로 구분한 단순한 형식)로 저장하고 나중에 불러올 수도 있다.

스마트폰으로 원격 제어

기본 앱이 워낙 빠르게 완성되어, 좀 더 욕심을 내보기로 했다.

발표를 원격으로 제어할 수 있다면 꽤 멋지지 않을까...

그래서 이런 프롬프트를 입력했다:

Add a web server which listens on 0.0.0.0:9123 - the web server serves a single mobile-friendly page with prominent left and right buttons - clicking those buttons switches the slide left and right - there is also a button to start presentation mode or stop depending on the mode it is in.

노트북과 스마트폰 모두에 Tailscale을 설치해 두었기 때문에, Wi-Fi 네트워크가 두 기기 간 접근을 막는 상황을 걱정할 필요가 없다. 어디서든 스마트폰에서 http://100.122.231.116:9123/에 직접 접속해 노트북의 발표를 제어할 수 있다.

몇 차례 프롬프트를 더 주고받은 끝에 최종 인터페이스가 완성됐다. 화면은 이렇다:

상단에 슬라이드 인디케이터가 있고, 이전·다음 버튼과 큼직한 "Start" 버튼, 그리고 글꼴 크기 조절 버튼이 배치되어 있다.

가장 복잡한 기능은 시작 버튼 옆의 얇은 막대다. 터치를 지원하는 스크롤바로, 손가락을 위아래로 밀면 화면에 보이는 웹 페이지가 그에 맞게 스크롤된다.

조작감이 상당히 투박하긴 하지만, 주요 콘텐츠가 스크롤 아래에 숨어 있을 때 꺼내 볼 수 있을 정도로는 충분히 동작한다.

코드를 통해 배우다

코드를 직접 들여다봐야겠다는 생각이 들었을 때는 이미 GitHub에 코드를 올린 뒤였다. ("이 앱은 바이브 코딩으로 만들었습니다 [...] 제 컴퓨터에서는 잘 됩니다만, 그 이상은 보장 못 합니다!"라는 큼직한 면책 문구와 함께.)

이 기회를 활용해 최근 자주 쓰는 패턴 하나를 문서로 정리했다. 모델에게 전체 코드베이스를 선형으로 순서대로 훑어달라고 요청하는 방법이다. 사용한 프롬프트를 포함해, 진행 중인 에이전틱 엔지니어링 패턴 가이드의 선형 코드 워크스루 패턴으로 정리해두었다.

결과로 나온 워크스루 문서는 실제로 꽤 유용하다. Claude Code가 원격 제어 기능의 웹 서버를 라이브러리 없이 소켓 프로그래밍으로 직접 구현했다는 사실을 뒤늦게 알게 됐다! 라우팅에 사용된 최소한의 HTTP 파서는 다음과 같다:

    private func route(_ raw: String) -> String {
        let firstLine = raw.components(separatedBy: "\r\n").first ?? ""
        let parts = firstLine.split(separator: " ")
        let path = parts.count >= 2 ? String(parts[1]) : "/"

        switch path {
        case "/next":
            state?.goToNext()
            return jsonResponse("ok")
        case "/prev":
            state?.goToPrevious()
            return jsonResponse("ok")

이런 식으로 상태 변경에 GET 요청을 쓰면 CSRF 취약점이 생기긴 한다. 이 앱의 용도를 생각하면 크게 신경 쓸 일은 아니지만.

가능성의 지평을 넓히며

요즘은 이런 바이브 코딩 이야기가 넘쳐난다. 그럼에도 이번 경험을 공유할 만한 이유가 몇 가지 있다:

• 내가 모르는 언어인 Swift는 이번 작업에 최적의 선택이었다. 웹 콘텐츠를 임베드하고 네트워크로 제어할 수 있는 전체 화면 앱이 필요했는데, Swift는 그에 필요한 모든 것을 갖추고 있었다.
• 막상 코드를 살펴보니 단순하고 명쾌했다. 필요한 것만 딱 구현되어 있었고, 그 이상은 없었다.
• 이 앱은 실제 문제를 해결해줬다. 웹 페이지 시퀀스로 발표하는 깔끔한 방법을 늘 원했는데, 이제 그게 생겼다.
• Xcode를 단 한 번도 열지 않았다!

그렇다고 네이티브 Mac 개발자가 쓸모없어졌다는 뜻은 아니다. 이 결과물을 내기 위해 내가 쌓아온 기술적 지식(Xcode 등을 이미 설치해 둔 것도 포함해서)을 상당히 활용했고, 진짜 Swift 개발자라면 같은 시간에 훨씬 완성도 높은 앱을 만들 수 있었을 것이다.

이번 경험은 소프트웨어 엔지니어링 경험이 있는 사람들이 흥미로운 방향으로 자신의 가능성을 넓힐 수 있다는 것을 잘 보여준다. 이제 Swift가 더 이상 두렵지 않다! 다음에 작고 개인적인 macOS 앱이 필요할 때, 지금 가진 도구들로 충분히 만들 수 있다는 걸 안다.

이 블로그의 장문 아티클만 보고 계신 분들을 위해: /atom/everything/을 구독하면 모든 글을 받아볼 수 있고, 다른 구독 옵션도 확인해보세요.