최근 꽤 규모 있는 Ghostty 기능(방해되지 않는 macOS 자동 업데이트)을 출시했습니다. 이 기능은 상당 부분 AI와 함께 개발했습니다.

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

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

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

기능 소개

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

이 기능이 만들어지게 된 배경을 설명해 보겠습니다(곧 알게 되겠지만 말장난입니다). 한 유명 OpenAI 키노트에서 데모가 Ghostty 업데이트 알림에 의해 무례하게 중단되는 일이 있었습니다:

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

AI를 쓰기 전 계획

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

좋습니다, 그래서 백엔드에 대해서는 대략적인 감이 왔습니다. 프론트엔드에 대해서는 사실 잘 몰랐습니다(제 전문 분야가 아닙니다). 타이틀바에 작은 버튼 형태로 들어가면 좋겠다는 막연한 생각만 있었고, macOS가 타이틀바 액세서리 컨트롤러를 통해 타이틀바에 커스텀 UI를 넣을 수 있다는 정도는 알고 있었지만, 그 이상으로 어떻게 보이고 동작해야 할지에 대한 감은 거의 없었습니다.

하지만 시작하기에는 충분했습니다. AI는 프로토타이핑에 매우 능하고, 무엇을 모르는지 아는 것만으로도 시작하기에 충분히 유용합니다. 전체 그림에 대한 감은 충분히 있었습니다.

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

다음은 첫 번째 에이전틱 코딩 세션이며, 시작 프롬프트는 다음과 같았습니다:

SPUUserDriver를 커스터마이징해서 커스텀하고 방해되지 않는 업데이트 알림과 설치를 활성화하고 싶습니다. 먼저 필요한 커스텀 UI를 계획하는 것부터 시작합시다. UI 작업에만 집중하겠습니다. SPUUserDriver에 필요한 여러 상태를 표시할 수 있는 SwiftUI 뷰를 만들기 위한 계획을 세워 주세요. 이 뷰들은 macOS 창 타이틀바의 오른쪽 위에 표시되는 것이 가장 좋을 것 같습니다. 그곳에 배치할 계획을 만들어 주세요. oracle에 문의하세요.

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

우선 UI 프로토타이핑부터 시작하기로 했습니다.

여기서 에이전트에게 전체 기능을 다 만들라고 시키지 않았다는 점에 주목해 주세요. 이유는 몇 가지 있습니다. 첫째이자 가장 중요한 이유는, 저조차도 UI/UX를 어떻게 만들고 싶은지 아직 모르는 상태에서 AI가 다른 변경 사항들과 함께 그걸 알아서 해내리라 기대할 수 없기 때문입니다. 둘째, 더 작은 단위의 작업이 검토하고 이해하고 반복하기가 훨씬 쉽습니다.

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

팁: 에이전트와 함께 대화형으로 종합적인 계획을 세우는 것은 만만찮은 작업을 할 때 매우 중요한 첫 단계입니다. 저는 보통 그 계획을 spec.md 같은 파일로 저장해 두고, 다음 세션에서 “@spec.md를 참고해서 어떤 작업을 진행해 줘”라고 말하곤 합니다.

에이전트가 어느 정도 납득할 만한 계획을 내놓았기에 그대로 진행해도 좋다고 했습니다. 이후 제가 어떻게 반복해 나갔는지는 대화 내용을 보시면 알 수 있습니다.

에이전트가 만든 UI는 방향성 측면에서 매우 훌륭했습니다. 간격, 색상 등 다듬어야 할 부분이 아주 많았지만, UI를 직접 보니 제가 원하는 것이 무엇인지 영감을 얻을 수 있었습니다.

팁: 저는 AI를 영감을 얻는 용도로 매우 자주 활용합니다. 이번 경우에는 에이전트가 만든 UI 코드 중 상당 부분(전부는 아닙니다)을 그대로 유지했지만, 에이전트에게 프롬프트를 던진 뒤 작업물을 전부 버리고 제가 직접(수동으로!) 다시 만드는 경우도 매우 많습니다. 저는 창작 과정에서 0에서 1을 만드는 단계가 매우 어렵고 시간이 오래 걸린다고 느끼는데, AI는 제 뮤즈(muse)로서 훌륭한 역할을 합니다.

벽에 부딪치다

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

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

이 시점에서 저는 한 걸음 물러서서 에이전트가 한 작업을 검토하고 스스로 계획을 세워야 한다는 것을 알았습니다. 스스로 공부하고 비판적으로 사고해야 할 때입니다. 더 이상 AI는 해결책이 아니라 부담이 됩니다.

정리 세션

다음 몇 개 세션에서는 에이전트에게 코드를 정리하도록 지시했습니다.

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

@macos/Sources/Features/Update/UpdateAccessoryView.swift에 있는 pill 배경, 전경, 배지 함수들을 @macos/Sources/Features/Update/UpdateViewModel.swift로 옮기고 더 범용적으로 만들어 주세요(배경, 전경, 배지)

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

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

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

네 번째 세션에서는 뷰 모델을 앱 전역 위치로 옮겼습니다. 원래 작업에서는 윈도 범위에 두었는데, 업데이트 정보는 앱 범위이기 때문입니다.

업데이트 뷰 모델 데이터를 AppDelegate로 옮겨 주세요. 업데이트 정보는 앱 전역에서 쓰일 것이기 때문입니다.

이 과정 내내 저는 틈틈이 사소한 수동 수정도 함께 했습니다.

정리 단계는 정말 중요합니다. 효과적으로 정리하려면 코드를 꽤 잘 이해하고 있어야 하므로, 이는 AI가 작성한 코드를 무비판적으로 받아들이지 않도록 강제합니다. 그 결과 더 잘 정리되고 문서화된 코드는 향후 에이전틱 세션이 더 나은 성능을 내도록 돕습니다.

저는 이 과정을 가끔 농담 삼아 “안티-슬롭(anti-slop) 세션”이라고 부르곤 합니다.

“그 버그”와 마주하다

이제 처음 세션에서 발견한 그 버그로 다시 돌아갈 차례입니다. 저는 다시 몇 차례 세션을 열어 에이전트에게 해결을 시도하게 했습니다. 처음에는 모호하게 시작해 점점 제가 접근하려는 방식을 구체적으로 제시했습니다.

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

일반적인 네이티브 탭에서는 업데이트 액세서리 뷰가 보이지 않습니다. 창의 타이틀바에 계속 보이도록 해야 합니다.

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

@macos/Sources/Features/Terminal/Window Styles/TerminalTabsTitlebarTahoe.swift의 탭 바 제약 조건을 업데이트해서 탭 바의 오른쪽 끝이 업데이트 액세서리 뷰의 왼쪽 끝에 정렬되도록 해 주세요. 그래야 계속 보이게 됩니다.

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

@macos/Sources/Features/Terminal/Window Styles/TitlebarTabsTahoeTerminalWindow.swift를 변경해서 탭 바를 하단 액세서리 뷰가 아니라 상단 액세서리 뷰로 만들면 어떨까요? 그러면 탭이 타이틀바로 들어가게 됩니다.

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

@macos/Sources/Features/Terminal/Window Styles/TitlebarTabsTahoeTerminalWindow.swift의 “right accessory view”와 레이아웃이 @macos/Sources/Features/Terminal/Window Styles/TerminalWindow.swift에 설정된 업데이트 액세서리 뷰와 충돌하고 있습니다. 탭 바가 항상 업데이트 알림 왼쪽에 나타나도록 제약 조건을 걸 수 있을까요?

실패.

이 모든 과정에서도 저는 수동으로 리서치하고 직접 고민하며 스스로 해결하려고 계속 노력했습니다. 더 구체적으로 작성한 프롬프트들은 그 과정에서 제가 배운 것들을 바탕으로 한 것입니다. 하지만 전체적으로는 분명히 잘 풀리지 않았습니다.

혼자서는 해결하기 어렵겠다고 판단해 방향을 틀기로 했습니다. 문제가 되는 타이틀바 스타일에서는 업데이트 알림을 타이틀바 대신 창의 오른쪽 하단에 콘텐츠 뷰 위에 오버레이 형태로 표시하기로 한 것입니다.

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

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

@macos/Sources/Features/Update 시스템을 확장해서 @macos/Sources/Features/Terminal/TerminalView.swift에서도 오버레이 방식을 지원하도록 해 주세요. 업데이트 알림은 창 하단에 나타나야 합니다. 텍스트 위에 떠 있어야 합니다(그래서 터미널 뷰의 크기가 바뀌지 않습니다). 그 외의 모든 클릭 동작은 액세서리 뷰와 동일하게 유지해야 합니다.

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

다음은 이 세션 직후 기능의 영상으로, 특정 타이틀바 스타일이거나 타이틀바가 숨겨진 경우 업데이트 알림이 창의 오른쪽 하단에 어떻게 나타나는지 보여줍니다:

백엔드 시작하기

UI는 충분히 괜찮은 수준이 되었습니다. 나중에 다듬고 싶은 부분들을 많이 메모해 두었지만, 혹시 제 계획에 차질을 줄 수 있는 예상치 못한 변수가 있을지 확인하기 위해 백엔드 작업으로 넘어가고 싶었습니다.

저는 미완성 함수들과 여러 TODO 주석으로 이루어진 파일을 직접 만들었습니다. 그리고 에이전트에게 그 작업을 완성해 달라고 하는 세션을 시작했습니다:

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

팁: AI는 빈칸 채우기나 나머지 그리기(draw-the-rest-of-the-owl)에 매우 능합니다. 설명적인 함수 이름, 파라미터, todo 주석 등으로 스캐폴딩을 만들어 두는 제 패턴은 제가 정말 자주 쓰는 방식이고 매우 잘 동작합니다.

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

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

다시 대대적인 정리

경험상 UI 프론트엔드와 비즈니스 로직 백엔드의 깔끔함은 그 사이에 있는 뷰 모델의 품질에 따라 좌우되는 경우가 많습니다. 그래서 저는 뷰 모델을 직접 재구성하는 데 시간을 썼습니다. 여러 옵셔널을 가진 구조체 대신 태그드 유니언(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를 볼 수 있도록 데모 코드를 만들게 했습니다. 하지만 업데이트 흐름에는 여러 시나리오가 있고, 그 시점까지 저는 해피 패스만 테스트했습니다.

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

@macos/Sources/App/macOS/AppDelegate.swift에 있는 업데이트 시뮬레이션 코드를 @macos/Sources/Features/Update 안의 전용 파일로 추출해 주세요. 해피 패스, 찾을 수 없음, 에러 등 여러 시뮬레이션 시나리오가 포함되어야 해서 다양한 데모를 쉽게 시도해 볼 수 있어야 합니다.

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

그 다음 여러 시뮬레이션을 실행해 보니 UX를 개선할 점이 많이 보였습니다.

• “업데이트를 찾을 수 없음” 상태 정리
• 에러 확인 시 상태 초기화
• 권한 요청 상태의 문구 및 스타일 변경

마지막 단계

이 시점에서 동작하는 백엔드와 프론트엔드가 모두 갖춰졌고, 이제 이들을 연결해야 했습니다.

다음 세션에서는 에이전트에게 다음 작업을 하도록 했습니다:

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

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

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

appcast가 있는 업데이트 가능 상태에 대해서는 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 1.3에서 만나보실 수 있습니다.

저는 에이전틱 코딩 세션을 공개적으로 공유하는 것이 중요하다고 공개적으로 주장해 왔습니다⁶. 그 이유 중 하나는 이것이 다른 사람들에게 이러한 도구를 효과적으로 사용하는 방법을 교육하는 매우 강력한 방법이기 때문입니다. 이 글이 그 점을 보여주는 데 도움이 되길 바랍니다.