최근 저는 만만찮은 Ghostty 기능(방해되지 않는 macOS 자동 업데이트)을 출시했는데, 이 기능은 대부분 AI와 함께 개발되었습니다.

저는 AI와 에이전틱 코딩 도구를 어떻게 활용하는지에 대한 만만찮은 사례를 공유해 달라는 요청을 자주 받는데, 이번이야말로 범위가 명확하고 만만찮으며 실제로 출시된 기능을 통해 제 작업 과정을 단계별로 소개할 절호의 기회라고 느꼈습니다.¹.

이 글에서는 이 기능을 출시하기까지 진행했던 모든 에이전틱 코딩 세션을 편집 없이 전부 공유합니다. 그와 함께 제 과정과 판단에 대한 추가적인 맥락도 덧붙일 겁니다. 그리고 궁금해하실 분들을 위해 토큰 비용도 함께 공개하겠습니다.

중요: 사람이 직접 작성한 코드도 많습니다. 저는 거의 항상 AI가 작업을 마친 뒤 직접 들어가 한동안 반복적으로 다듬습니다. 매번 반복해서 말하지 않기 위해 여기서 한 번만 밝힙니다. 따라서 AI가 만든 결과물과 최종 코드 사이에 차이가 보일 수도 있습니다. 이는 의도된 것이며, 저는 유능한 AI 활용자는 자신의 분야에 정통한 전문가로서 AI를 대체재가 아닌 조력자로 활용한다고 믿습니다.

기능 소개

이 글에서 다루는 완성된 기능은 macOS용 방해되지 않는 업데이트 알림 기능입니다. 이 기능은 창을 새로 띄우거나 포커스를 빼앗는 식으로 작업을 방해하지 않고 터미널 창 안에서 업데이트 상태를 보여줍니다.

이 기능이 나오게 된 배경을 설명해 보겠습니다(곧 보시겠지만 말장난입니다). 주목도가 높은 OpenAI 키노트 도중 Ghostty 업데이트 알림이 데모를 무례하게 가로막았습니다:

그런 일이 다시는 일어나지 않도록 하고 싶었습니다.² 제가 택한 방법은 업데이트 알림을 방해되지 않게 만드는 것이었습니다. 창을 팝업으로 띄우는 대신, 앱 어딘가에 사용자를 방해하지 않는 작고 비모달(non-modal) GUI 요소를 표시하는 방식입니다.

AI 이전의 계획

그래서 바로 AI 도구를 꺼냈습니다. 절대 아닙니다. 저는 먼저 이 기능이 어떻게 동작하면 좋을지 대략적인 계획을 세우는 것부터 시작했습니다. Ghostty는 매우 널리 쓰이는 macOS 업데이트 프레임워크인 Sparkle을 사용합니다. 문서를 뒤져보니 Obj-C 프로토콜을 통한 커스텀 UI를 지원한다는 것을 알았습니다. 처음부터 다시 구현해야 할 것이 많지만, 가능한 일이었습니다.

좋아, 백엔드에 대해서는 대략 감이 잡혔습니다. 프론트엔드는 사실 잘 모르겠더군요(제 전문 분야도 아니고요). 타이틀 바에 작은 버튼을 넣으면 좋겠다는 아주 막연한 아이디어만 있었고, macOS가 titlebar accessory controllers를 통해 타이틀 바에 커스텀 UI를 넣는 것을 지원한다는 정도는 알고 있었지만, 그 이상으로 어떻게 보이고 동작해야 할지에 대한 감은 별로 없었습니다.

하지만 시작하기엔 충분했습니다. AI는 프로토타이핑을 아주 잘하니까, 무엇을 모르는지 아는 것만으로도 시작할 만한 가치가 있습니다. 전체적인 그림에 대해서는 충분히 감을 잡고 있었습니다.

첫 번째 세션: UI 프로토타이핑

다음은 제가 진행한 첫 번째 에이전틱 코딩 세션이며, 시작 프롬프트는 이랬습니다:

SPUUserDriver를 커스터마이징해서 커스텀하고 방해되지 않는 업데이트 알림과 설치를 가능하게 하고 싶습니다. 먼저 필요한 커스텀 UI를 계획하는 것부터 시작합시다. UI 작업에만 집중합시다. SPUUserDriver에 필요한 다양한 상태를 보여줄 수 있는 SwiftUI 뷰를 만들기 위한 계획을 세워 주세요. 이 UI가 표시되기에 가장 좋은 곳은 macOS 윈도우 타이틀 바의 오른쪽 상단이라고 생각합니다. 그곳에 배치할 계획을 세워 주세요. oracle에 자문해 보세요.

자주 받는 질문: “oracle이 뭐예요?” 이는 Amp 전용 읽기 전용 서브에이전트로, 더 느리고 비용이 높지만 일반적으로 사고하는 데 더 뛰어난 모델을 사용합니다. 저는 모든 계획을 세울 때 oracle에 자문합니다.

우선 UI부터 프로토타입하기로 했습니다.

여기서 저는 에이전트에게 전체 기능을 만들라고 시키지 않았다는 점을 주목해 주세요. 이유는 몇 가지 있습니다. 무엇보다도 저는 아직 UI/UX가 어떠해야 할지조차 모르기 때문에, 다른 변경 사항과 함께 AI가 그걸 일관되게 해내길 기대할 수 없습니다. 둘째, 더 작은 단위의 작업이 검토하고 이해하고 반복하기가 더 쉽습니다.

또 하나 주목할 점은 제가 코드를 작성하지 말고 계획만 세우라고 요청했다는 것입니다. 요청 자체가 다소 모호하기 때문에, 에이전트가 대량의 작업(그리고 대량의 토큰)을 소모하기 전에 계획을 먼저 검토하는 것이 중요합니다.

팁: 에이전트와 함께 상호작용하며 포괄적인 계획을 세우는 것은 만만찮은 작업에서는 매우 중요한 첫 단계입니다. 저는 보통 에이전트를 통해 그 계획을 spec.md 같은 파일로 저장해 두고, 이후 세션에서 “Consult the @spec.md and work on some task”라고 말할 수 있도록 합니다.

에이전트는 그럭저럭 동의할 만한 계획을 내놓았고, 저는 그대로 구현을 진행하도록 했습니다. 그 이후 제가 반복하며 나눈 나머지 대화도 보실 수 있습니다.

에이전트가 만든 UI는 방향성 면에서 아주 좋았습니다. 다듬어야 할 부분(간격, 색상 등)이 엄청나게 많았지만, 그 UI를 보니 제가 무엇을 원하는지 알 수 있는 영감의 불씨를 얻을 수 있었습니다.

팁: 저는 영감을 얻기 위해 AI를 아주 자주 활용합니다. 이번 경우에는 에이전트가 만든 UI 코드 중 상당 부분(전부는 아닙니다)을 유지했지만, 종종 에이전트에 프롬프트를 던진 뒤 그 결과물을 전부 버리고 제가 직접(수동으로!) 다시 만들기도 합니다. 창작에서 ‘0에서 1을 만드는’ 단계가 매우 어렵고 시간이 많이 걸리는데, AI는 제 뮤즈로서 탁월합니다.

벽에 부딪히다

채팅 11부터 14를 보면 우리가 슬롭(slop) 구간에 진입했음을 알 수 있습니다. 에이전트가 만든 코드에 치명적인 버그가 있었는데, 이를 전혀 고치지 못했습니다. 그리고 저 역시 어떻게 고쳐야 할지 전혀 몰랐습니다.

저는 버그를 고치기 위해 종종 이렇게 몇 번 마지막 시도를 해보곤 합니다. 에이전트가 알아낸다면 저는 그것을 공부해서 스스로 배울 수 있습니다. 못 알아내더라도 제게 드는 비용은 거의 없습니다. 에이전트가 고쳐냈는데 제가 이해하지 못하면 되돌립니다. 이해하지 못하는 코드는 출시하지 않습니다. 에이전트가 실패하는 동안 저는 다른 탭에서 이슈를 검색하며 스스로 해결 방법을 찾으려고 노력합니다.

이 시점이 되면 한 발 물러서서 에이전트가 한 일을 검토하고 제 나름의 계획을 세워야 한다는 걸 알게 됩니다. 스스로 공부하고 비판적으로 사고해야 할 때입니다. AI는 더 이상 해결책이 아니라 부담이 됩니다.

정리 세션

이후 몇 번의 세션에서는 에이전트가 코드를 정리하도록 이끌었습니다.

두 번째 세션에서는 제가 더 적절하다고 판단한 위치로 몇몇 메서드를 옮기는 데 집중했습니다:

@macos/Sources/Features/Update/UpdateAccessoryView.swift의 pill background, foreground, badge 함수들을 @macos/Sources/Features/Update/UpdateViewModel.swift로 옮기고 더 범용적으로 만들어 주세요(background, foreground, badge)

세 번째 세션에서는 코드에 문서를 추가했습니다:

@UpdateBadge.swift의 문서를 업데이트해 주세요

팁: 문서를 추가하는 것은 매우 중요한 단계입니다. 코드에 대한 자신의 이해를 다시 확인하는 데 도움이 될 뿐만 아니라, 나중에 이 코드를 읽고 수정할 에이전트를 교육하는 데도 도움이 되기 때문입니다. 자연어 설명과 코드 자체가 함께 있을 때 에이전트가 훨씬 더 잘 동작한다는 것을 알게 되었습니다.

네 번째 세션에서는 뷰 모델을 앱 전역 위치로 옮겼습니다. 원래 작업에서는 윈도우 스코프에 넣어두었지만 업데이트 정보는 앱 스코프에 해당하기 때문입니다.

업데이트 정보가 앱 전역이므로 update view model 데이터를 AppDelegate로 옮겨 주세요.

이 과정 전반에 걸쳐 저는 틈틈이 직접 들어가 사소한 수동 수정을 하기도 했습니다.

정리 단계는 정말 중요합니다. 효과적으로 정리하려면 코드를 꽤 잘 이해하고 있어야 하므로, AI가 작성한 코드를 맹목적으로 수용하지 않게 됩니다. 그리고 더 잘 정리되고 문서화된 코드는 이후 에이전틱 세션이 더 나은 성능을 내도록 돕습니다.

저는 가끔 이를 농담 반 진담 반으로 “anti-slop 세션”이라고 부릅니다.

“그 버그”와 마주하기

이제 초기 세션에서 발견한 그 버그로 다시 돌아갈 차례입니다. 저는 다시 몇 번의 세션을 들여 에이전트가 이 문제를 해결하도록 시도했습니다. 처음에는 모호하게 시작해서 제가 접근할 방법을 점점 더 구체적으로 제시했습니다.

먼저, 모호하게 요청한 세션입니다:

표준 네이티브 탭에서는 update accessory view가 보이지 않습니다. 윈도우 타이틀 바에 계속 표시되어야 합니다.

실패. 그다음에는 좀 더 구체적으로 요청했습니다:

@macos/Sources/Features/Terminal/Window Styles/TerminalTabsTitlebarTahoe.swift의 tab bar 제약 조건을 업데이트해서 tab bar의 오른쪽 끝이 update accessory view의 왼쪽 끝에 정렬되도록 해야 합니다. 그래야 계속 보이게 됩니다.

실패. 이번에는 다른 구체적인 접근법을 시도했습니다:

@macos/Sources/Features/Terminal/Window Styles/TitlebarTabsTahoeTerminalWindow.swift를 변경해서 tab bar를 bottom accessory view가 아니라 top accessory view로 만들면 어떨까요? 그러면 탭이 타이틀 바 안으로 들어가게 할 수 있을 것 같습니다.

실패. 마지막 시도입니다:

@macos/Sources/Features/Terminal/Window Styles/TitlebarTabsTahoeTerminalWindow.swift의 “right accessory view”와 레이아웃이 @macos/Sources/Features/Terminal/Window Styles/TerminalWindow.swift에 설정된 update accessory view와 충돌하고 있습니다. tab bar가 항상 update notice 왼쪽에 표시되도록 제약할 수 있을까요?

실패.

이 모든 시간 동안 저 역시 직접 리서치하고 사람의 힘으로 이 문제를 해결하려고 노력했습니다. 더 구체적인 프롬프트들은 그 과정에서 배운 것들을 바탕으로 한 것입니다. 하지만 전반적으로 분명히 잘 풀리지 않았습니다.

혼자서는 해결할 수 없을 것 같아 방향을 틀기로 했습니다. 문제가 되는 타이틀 바 스타일에서는 업데이트 알림을 타이틀 바 대신 윈도우의 오른쪽 하단 모서리에 콘텐츠 뷰 위에 오버레이 형태로 표시하기로 했습니다.

어차피 Ghostty에는 타이틀 바를 완전히 숨기는 설정이 있어서 이 방식은 어쨌든 지원해야 합니다. 그래서 나중에 타이틀 바 스타일링 문제를 해결하더라도 이 다른 모드는 여전히 지원해야 합니다.

다음 세션에서는 아주 구체적인 프롬프트로 이 계획을 진행했습니다:

@macos/Sources/Features/Update 시스템을 확장해서 @macos/Sources/Features/Terminal/TerminalView.swift에서도 오버레이 방식을 지원하도록 해 주세요. 업데이트 알림은 윈도우 하단에 표시되어야 합니다. 텍스트 위에 오버레이되어야 합니다(그래서 터미널 뷰의 크기를 바꾸지 않습니다). 그 외의 모든 클릭 동작은 accessory view와 동일해야 합니다.

에이전트는 이 작업을 정말 잘 해냈습니다. 이후 제가 직접 다듬는 작업을 많이 했습니다(이리저리 옮기고 이름 바꾸기 등) 하지만 핵심 작업은 탄탄했습니다.

다음은 이 세션 직후 기능의 모습으로, 특정 타이틀 바 스타일이거나 타이틀 바가 숨겨진 경우 업데이트 알림이 윈도우 오른쪽 하단 모서리에 어떻게 표시되는지 보여주는 영상입니다:

백엔드 시작하기

UI는 충분히 괜찮은 상태가 되었습니다. 나중에 다듬고 싶은 지점들을 여러 개 적어두었지만, 제 계획에 차질을 줄 만한 미지의 요소가 있는지 확인하기 위해 주로 백엔드 작업으로 넘어가고 싶었습니다.

저는 미완성 함수들과 여러 TODO 주석으로 이루어진 스캐폴드 파일을 직접 만들었습니다. 그리고 그 작업을 완성하도록 하는 세션을 시작했습니다:

@macos/Sources/Features/Update/UpdateDriver.swift를 완성해 주세요. 기능을 이해하는 데 필요하다면 Sparkle 문서를 읽어보세요. https://sparkle-project.org/documentation/api-reference/Protocols.html

팁: AI는 빈칸 채우기나 “나머지 부엉이 그리기”에 아주 뛰어납니다. 설명적인 함수 이름, 파라미터, todo 주석 등으로 스캐폴딩을 만들어 두는 이번 패턴은 제가 정말 자주 쓰는 방식이며 매우 잘 동작합니다.

사실 에이전트는 여기서 정말 못했습니다 그래서 결국 이 코드를 전부 버렸습니다. 에이전트가 만든 코드는 동작은 했지만, 명백히 잘못된 접근 방식이었습니다. 여러 관심사를 뒤섞어 놓았고 드라이버에 상태를 저장하는 방식도 분명히 잘못되어 있었습니다.

에이전트가 한 일을 살펴보다가 뷰 모델이 최적이 아닌 방식으로 구조화되어 있었기 때문이라는 걸 깨달았습니다. 그래서 AI(그리고 제가 직접 작성하기로 한다면 사람을 위해서도)가 더 잘 작업할 수 있는 더 나은 틀을 제공하기 위해 정리 모드로 전환했습니다.

다시 대대적인 정리

경험상 UI 프론트엔드와 비즈니스 로직 백엔드의 깔끔함은 그 사이에 있는 뷰 모델의 품질에 좌우되는 경우가 많습니다. 그래서 저는 시간을 들여 뷰 모델을 직접 재구성했습니다. 옵셔널이 잔뜩 들어간 struct 대신 태그드 유니온(tagged union)으로 바꾸고, 일부 타입의 이름을 바꾸고 이것저것 옮기는 작업이었습니다.

경험상 중간에 이 정도의 수작업을 해두면 이후 세션에서 프론트엔드와 백엔드 모두 에이전트가 성공할 수 있는 발판이 된다는 것을 알고 있었습니다. 이를 마친 뒤 저는 연이은 정리 세션을 계속 진행했습니다.

재구성을 마친 뒤 가장 먼저 한 일은 다시 한번 에이전트에게 나머지를 완성해 달라고 요청한 것이었습니다. 이번에는 제가 변경한 내용을 살펴보고 의존하는 코드를 새로운 스타일에 맞게 업데이트하며 기존 것을 제거하도록 했습니다:

@macos/Sources/Features/Update/UpdateViewModel.swift를 업데이트해서 새로운 UpdateState만 사용하도록 해 주세요. state2를 state로 이름을 바꾸세요(기존 state는 제거).

그다음에는 추가적인 데드 코드를 제거해 달라고 요청했습니다:

UpdateUIActions는 제거해도 될 것 같습니다. UpdateState에 콜백이 생기면서 더 이상 사용되지 않으니까요.

그다음에는 제가 이것저것 정리하다가 빌드를 망가뜨렸습니다. 회의에 들어가야 해서 제가 바쁜 동안 에이전트에게 고치도록 맡겼습니다:

빌드를 실행하고 에러를 고쳐 주세요

팁: “여러 가지를 망가뜨렸는데, 제 엉망진창을 고쳐 주세요.” 이것도 제가 에이전트를 자주 활용하는 사례 중 하나입니다. 일반적으로는 앞서 말한 빈칸 채우기 패턴에 속한다고 할 수 있습니다.

나중에 몇몇 뷰를 다시 리팩터링하기 시작했습니다:

@macos/Sources/Features/Update/UpdatePopoverView.swift의 각 case를 타입이 지정된 값을 파라미터로 받는 전용 fileprivate Swift 뷰로 만들어서 guard를 제거할 수 있도록 해 주세요.

추가 정리:

@macos/Sources/Features/Update/UpdateViewModel.swift에 있는 iconName을 옵셔널로 바꾸고, 빈 값이면 nil을 반환하도록 해 주세요. 사용처도 업데이트해 주세요.

시뮬레이션

첫 번째 UI 세션에서 저는 실제 업데이트 확인 없이도 UI가 동작하는 모습을 볼 수 있도록 에이전트에게 데모 코드를 만들게 했습니다. 하지만 업데이트 흐름에는 여러 시나리오가 있는데, 지금까지는 행복한 경로(happy path)만 테스트했습니다.

다음 세션에서는 시뮬레이션 코드를 전용 파일로 추출하고 에이전트에게 더 많은 시나리오를 만들어 달라고 요청했습니다:

@macos/Sources/App/macOS/AppDelegate.swift에 있는 update 시뮬레이션 코드를 @macos/Sources/Features/Update 안의 전용 파일로 추출해 주세요. 다양한 데모를 쉽게 시도해 볼 수 있도록 여러 시뮬레이션 시나리오(happy path, not found, errors 등)가 포함되어야 합니다.

팁: 에이전트는 테스트와 시뮬레이션을 생성하는 데 탁월합니다. 여기서 에이전트가 생성한 시뮬레이션 코드는 솔직히 꽤 지저분하지만 동작은 하고 릴리스 바이너리에 포함되지 않으므로 품질은 저에게 중요하지 않습니다. 세션에서 보실 수 있는 기본적인 정리 이상으로는 손도 대지 않았습니다.

그 후 여러 시뮬레이션을 실행해 보고 UX 개선점들을 다수 찾았습니다.

• “No Update Found” 상태 정리
• 에러 확인 시 상태 초기화
• 권한 요청 상태의 문구 및 스타일 변경

마지막 단계

이 시점에서 동작하는 백엔드와 프론트엔드가 있었고, 이제 둘을 연결해야 했습니다.

다음 세션에서는 에이전트에게 이렇게 요청했습니다:

https://github.com/sparkle-project/Sparkle/blob/2.x/Sparkle/SPUStandardUpdaterController.m과 동일하지만 우리 updater 타입에 맞는 UpdateController 클래스를 만들어 주세요.

이 작업은 약간의 주고받기와 수동 다듬기가 필요했지만 결국 완성되었습니다.

그다음 사소한 개선을 했습니다:

appcast가 있는 update available 상태에 대해 https://sparkle-project.org/documentation/api-reference/Classes/SUAppcastItem.html을 참고해서 설정되어 있다면 다른 관련 메타데이터도 표시해 주세요. 예를 들어 크기에 대한 content length 같은 것요.

그 밖에 더 할 일은?

에이전트에게 보낸 마지막 프롬프트는 항상 제가 놓치고 있는 것이 또 없는지 물어보는 것입니다. 코드를 제가 직접 작성했는지 여부와 관계없이 항상 이렇게 합니다.

@macos/Sources/Features/Update 기능과 관련해 추가로 개선할 수 있는 부분이 보이나요? 코드는 작성하지 마세요. oracle에 자문해 보세요. 유닛 테스트를 더 추가할 수 있는 코드 부분도 고려해 주세요.

이를 통해 몇 가지 실제 문제점이 드러났고, 저는 에이전트에게 그대로 구현해 달라고 했습니다. 특정 작업을 일일이 지정하기보다는 에이전트에게 “좋아, 그냥 다 해줘”라고 말하는 편이 더 쉽다고 생각합니다. 나중에 선택적 커밋으로 쉽게 정리할 수 있으니까요.

이 세션에서 재미있는 점은 에이전트가 정말 엉뚱한 방향으로 깊게 빠져들기 시작해서 제가 직접 나서서 멈췄다는 것입니다:

그만, 그만, 그만. main actor 관련 작업 전부 되돌려 주세요.

더 나은 방법이 있는데도 에이전트가 다소 서툴게 처리한 부분도 발견했습니다:

에러 메시지의 경우, 잘라내는 대신 SwiftUI 표준 방식으로 처리할 수 있지 않나요? 전체 메시지를 볼 수 있는 추가 UI 요소를 넣어야 할 것 같습니다.

비용과 시간

이 작업은 총 16개의 개별 세션으로 이루어졌으며 Amp에서 토큰 비용으로 총 $15.98이 들었습니다.³ 이게 일반적으로 비싼지 싼지 따져보진 않겠지만, 개인적으로는 이 기능을 작업한 두 달력일 동안 커피숍에서 그보다 더 많은 돈을 썼다고 말씀드릴 수 있습니다.

이 기능에 들인 총 “실제 소요 시간”은 대략 8시간 정도로 추산합니다. 하루에 컴퓨터 앞에 있는 시간은 4시간 정도에 불과하고 첫 커밋과 마지막 커밋 사이에는 3일이 걸렸습니다. 게다가 그 시간 전부를 이 기능에만 쓰지도 않았습니다. 예를 들어 저는 이 기능을 작업하던 날들의 “컴퓨터 작업” 시간 동안 Ghostty 업데이트를 출시하기도 했고, ThePrimeagen에 한 시간 동안 게스트로 출연했으며, Zoo의 연례 전체 회의에서 게스트 발표도 했습니다. 모든 것은 제가 “컴퓨터 작업”에 쓸 수 있는 시간 안에 일어났습니다.⁴ 그래서 8시간이라는 추산은 넉넉하게 잡은 것이라고 생각합니다.

인터넷에서는 AI가 더 빨리 일할 수 있게 하는지에 대해 많은 논쟁이 있습니다. 이번 경우 저는 모든 걸 혼자 했다면 지금보다 더 늦게 출시했을 거라고 생각합니다. 특히 사소한 SwiftUI 스타일링을 반복하는 작업은 개인적으로 매우 지루하고 시간이 많이 걸리는데 AI는 그걸 아주 잘하기 때문입니다.

개인적으로 빠르다/느리다 논쟁은 제가 가장 좋아하는 점을 놓치고 있다고 생각합니다. 바로 제가 자리를 비워 다른 일을 하는 동안에도 AI가 저를 대신해 일할 수 있다는 점입니다. 다음은 가족 아침 식사를 준비하는 동안 진행한 정리 세션 중 하나를 찍은 사진입니다:

이에 대해 “요리하면서 코딩하고 싶지 않다”거나 “지금 이 순간에 더 집중하라”는 식의 온갖 폄하가 있습니다. 그렇게 살고 싶다면 그렇게 하면 됩니다. 제 경우, 이 특정한 예시에서는 제가 집에서 가장 먼저 일어나고 다른 가족이 아직 잠들어 있는 동안 아침 식사를 준비합니다. 깨어 있는 모든 순간 이렇게 하는 것은 아닙니다.

결국 하고 싶은 말은, 이 방식이 저에게는 잘 맞는다는 것입니다. 저는 정말로 여러분을 설득하려는 것이 아닙니다. 저는 어떤 AI 회사와도 금전적 관계가 없습니다. 다만 AI 도구를 활용해 많은 성공을 거두고 그에 대해 이야기하는 것을 좋아하는 사람으로서, 사람들이 늘 사례를 공유해 달라고 요청하기에 지금 그렇게 하고 있는 것입니다.

맺음말

이 기능은 아름답고 훌륭하게 동작한다고 생각하며, 최종 수동 검토를 마친 뒤 병합했습니다.⁵ tip 릴리스를 사용하는 Ghostty 사용자라면 지금 바로 이용할 수 있습니다. 태그된 릴리스를 사용하는 Ghostty 사용자라면 이 기능은 Ghostty 1.3에서 만나보실 수 있습니다.

저는 에이전틱 코딩 세션을 공개적으로 공유하는 것의 중요성을 목소리 높여 옹호해 왔는데⁶, 그 이유 중 하나는 이것이 다른 사람들에게 이 도구를 효과적으로 사용하는 방법을 교육하는 엄청나게 강력한 방법이기 때문입니다. 이 글이 그 점을 보여주는 데 도움이 되길 바랍니다.