AI Leadership
AI NEWS
AI Native Lab
구독
Claude Code로 맥 앱 2개 만들고 알게 된 것
작성자
- 팀제이커브팀
성공 여부
성공
주제
- 자동화
Claude Code로 맥 앱 2개 만들고 알게 된 것
코딩을 할 줄 몰라도 앱을 만들 수 있는 시대가 왔다고 하면, 아직은 조금 과장처럼 들릴 수도 있습니다.
저도 얼마 전까지만 해도 비슷하게 생각했습니다. 아이디어는 있어도 개발은 개발자의 영역이라고 생각했거든요. 그런데 최근 Claude Code와 Codex를 활용하면서 생각이 조금 바뀌었습니다.
이번 주에는 실제로 맥 앱 2개를 만들었습니다. 하나는 제가 하루 동안 어떤 앱에 시간을 쓰고 있는지 추적하는 앱이었고, 다른 하나는 집에서 늘 불편했던 오디오 출력을 해결하기 위한 앱이었습니다.
물론 완벽하지는 않았습니다. UI도 부족했고, 중간중간 오류도 많았죠. 하지만 중요한 건 결과물이 아니었습니다.
"필요한 게 있으면 직접 만들어본다."
이 생각이 처음으로 현실적인 선택지가 됐다는 점이 더 흥미로웠습니다.
그리고 그 과정에서 Codex에 Fable 구조를 적용해보는 실험도 함께 진행했습니다. 모델 자체보다 일을 처리하는 방식과 구조가 더 중요하다는 점도 다시 한번 확인할 수 있었고요.
이번 글에서는 Claude Code로 맥 앱 2개를 만들었던 경험과, Codex 실험을 통해 얻은 인사이트를 공유해보려고 합니다. 그리고 이를 계기로 시작한 작은 목표 하나도 소개하려고 합니다.
'내가 필요한 맥 앱 20개 직접 만들기.'
AI Native 시대에는 어쩌면 이것이 새로운 생산성의 시작일지도 모르겠습니다.
생각보다 쉽게 맥 앱을 만들 수 있었다
최근 AI 코딩 도구 이야기가 정말 많이 나옵니다. Claude Code, Codex, Cursor 등 새로운 도구가 계속 등장하고 있죠. 그런데 막상 써보지 않으면 체감하기 어려운 부분이 있습니다.
정말 앱 하나를 만들 수 있을 정도로 좋아졌을까?
이번 주에 직접 실험해봤습니다.
결과부터 말하면, 생각보다 훨씬 가능성이 있었습니다.
물론 제가 갑자기 개발자가 된 건 아닙니다. Swift를 깊게 이해하는 것도 아니고, macOS 앱 개발 경험이 많은 것도 아닙니다. 대신 필요한 기능을 설명하고, Claude Code가 작성한 코드를 검토하고, 문제가 생기면 다시 수정하는 과정을 반복했습니다.
그 과정에서 느낀 건 AI 시대의 개발은 예전과 조금 다르다는 점이었습니다.
예전에는 아이디어가 생기면 개발 리소스를 먼저 생각했습니다. 만들 수 있을까? 얼마나 걸릴까? 누가 개발할까? 같은 고민이 먼저 나왔죠.
그런데 지금은 조금 다릅니다.
일단 만들어보고 판단할 수 있습니다.
실제로 이번 주에는 단순한 토이 프로젝트 수준이 아니라 제가 실제로 사용하고 있는 맥 앱 2개를 만들었습니다. 하나는 작업 시간을 추적하는 앱이고, 다른 하나는 오디오 출력을 앱별로 분리하는 앱입니다.
완성도는 상용 서비스와 비교할 수 없겠지만, 적어도 제가 겪고 있는 문제를 해결하기에는 충분했습니다.
그리고 이 경험 하나만으로도 꽤 큰 변화라고 느꼈습니다. 필요한 기능이 생겼을 때 더 이상 "누가 만들어주면 좋겠다"가 아니라, "한번 만들어볼까?"를 먼저 떠올리게 됐으니까요.
첫 번째 앱, 작업 시간 트래커
AI로 앱을 만들 수 있다는 걸 확인한 뒤 가장 먼저 만든 건 작업 시간 트래커였습니다.
사실 이유는 단순했습니다.
요즘은 Claude, ChatGPT, Codex를 오가며 일하는 시간이 많아졌는데, 정작 하루 동안 어떤 작업에 얼마나 시간을 쓰고 있는지는 잘 모르겠더라고요. 열심히 일한 것 같은데 막상 돌아보면 메신저나 브라우저에 시간을 많이 쓴 날도 있었고요.
그래서 직접 만들어보기로 했습니다.
이 앱은 현재 사용 중인 앱을 추적해서 작업 시간을 자동으로 기록합니다. 단순히 총 작업 시간만 보여주는 것이 아니라 어떤 앱에서 얼마나 시간을 보냈는지 확인할 수 있습니다.
특히 마음에 들었던 건 목표 시간을 설정하는 기능이었습니다.
예를 들어 Claude를 활용한 작업을 하루 1시간 이상 진행하겠다고 목표를 세우면 진행률이 실시간으로 표시됩니다. 게임의 퀘스트처럼 목표를 달성하는 재미도 있었고, 생각보다 동기부여가 잘 되더라고요.
또 주간·월간 단위로 데이터를 모아보면 흥미로운 패턴도 발견할 수 있습니다.
"나는 AI 도구를 많이 쓴다고 생각했는데 실제로는 카카오톡을 더 오래 보고 있었네?"
같은 사실을 숫자로 확인하게 되죠.
아직 기능적으로 부족한 부분은 많습니다. 하지만 이미 제가 매일 사용하는 앱이 됐습니다. 그리고 이 경험을 통해 다시 한번 느꼈습니다.
좋은 앱이 꼭 거대한 아이디어에서 시작되는 건 아닙니다.
오히려 매일 반복해서 겪는 작은 불편함 하나가 더 좋은 출발점이 될 수도 있습니다.
두 번째 앱, Soundwich
두 번째로 만든 앱은 조금 더 개인적인 문제에서 시작됐습니다.
집에서 작업할 때 종종 이런 상황이 있었습니다.
음악은 블루투스 스피커로 듣고 싶은데, 업무 알림이나 회의 소리는 에어팟으로 듣고 싶었습니다. 하지만 macOS는 기본적으로 모든 소리를 하나의 출력 장치로 보내기 때문에 원하는 방식으로 사용하기가 쉽지 않았죠.
물론 비슷한 기능을 제공하는 앱들도 있습니다.
하지만 설치해보면 기능이 너무 많거나, 유료이거나, 제가 원하는 방식과 조금씩 달랐습니다.
그래서 이번에는 찾는 대신 만들어보기로 했습니다.
Claude Code와 함께 기능을 설계하고 Xcode에서 수정과 테스트를 반복했습니다. 예상보다 시행착오는 많았습니다. 특히 오디오 장치를 제어하는 과정에서 생각보다 다양한 예외 상황이 발생했거든요.
그래도 결과적으로는 하루 만에 원하는 기능을 구현할 수 있었습니다.
지금은 블루투스 스피커에서는 음악이 나오고, 업무 관련 소리는 맥북 스피커나 에어팟으로 분리해서 사용할 수 있게 됐습니다. 아주 거창한 앱은 아니지만, 제가 매일 겪던 불편함을 해결하기에는 충분했습니다.
이번 앱을 만들면서 가장 인상 깊었던 건 개발 난이도가 아니라 접근 방식의 변화였습니다.
예전 같았으면 검색부터 했을 겁니다.
"이 기능 제공하는 앱 없나?"
"무료 앱 없나?"
"누가 만들어 놓은 거 없나?"
그런데 이제는 생각이 조금 달라졌습니다.
원하는 게 없다면 직접 만들어볼 수 있습니다.
물론 상용 서비스 수준의 완성도를 만드는 건 여전히 어렵습니다. 하지만 개인의 불편함을 해결하는 수준이라면 AI와 함께 생각보다 빠르게 결과물을 만들 수 있습니다.
Soundwich는 완벽한 앱은 아닙니다.
하지만 저에게는 AI Native 시대가 어떤 시대인지 가장 잘 보여주는 사례 중 하나였습니다. 소비자에 머무르지 않고, 필요한 것을 직접 만드는 사람이 될 수 있는 시대 말이죠.
Codex에 페이블을 넣어봤다
앱을 만들면서 자연스럽게 하나의 궁금증이 생겼습니다.
"결국 중요한 건 모델일까, 아니면 일하는 방식일까?"
최근 OpenAI의 Codex를 사용하면서 이 질문을 꽤 많이 하게 됐습니다. 그리고 이번에는 조금 특별한 실험도 해봤습니다.
바로 FableCodex를 적용해본 것입니다.
처음에는 단순히 프롬프트 몇 줄이 추가된 정도라고 생각했습니다. 그런데 실제로 사용해보니 조금 다르게 느껴졌습니다.
Fable 구조는 대략 이런 흐름으로 동작합니다.
•
근거 확인
•
계획 수립
•
가설 설정
•
전체 코드 테스트
•
검증 결과 확인
•
최종 적용
생각해보면 사람이 일을 잘할 때의 과정과 크게 다르지 않습니다.
문제를 파악하고, 계획을 세우고, 검증하고, 적용하는 순서를 강제로 거치게 만드는 구조인 셈이죠.
흥미로웠던 건 같은 Codex인데도 결과물이 꽤 달라졌다는 점입니다.
기존에는 바로 코드를 수정하거나 구현부터 시작하는 경우가 많았습니다. 반면 Fable 구조를 적용하니 먼저 문제를 정리하고, 어떤 방식으로 해결할지 설명한 뒤, 테스트와 검증까지 수행하는 비율이 높아졌습니다.
물론 단점도 있었습니다.
토큰이 정말 많이 사용됩니다.
생각보다 긴 추론 과정을 거치기 때문에 비용 측면에서는 부담이 있었죠. 하지만 코드 검증이나 리뷰처럼 실수를 줄이는 것이 중요한 작업에서는 충분히 가치가 있다고 느꼈습니다.
특히 직접 만든 앱을 검증할 때 효과가 좋았습니다.
새로운 기능을 추가한 뒤 "정말 문제가 없는가?"를 확인하는 과정에서 단순 코드 생성보다 훨씬 안정적인 결과를 보여줬거든요.
이번 실험을 하면서 얻은 가장 큰 배움은 하나였습니다.
좋은 결과를 만드는 건 모델이 아니라 구조일 수 있다는 것.
모델의 성능 차이도 중요하지만, 어떤 프로세스로 사고하고 검증하게 만드느냐가 결과물의 품질에 더 큰 영향을 주는 경우도 있다는 걸 확인할 수 있었습니다.
이제는 필요한 도구를 직접 만드는 시대
이번 주에 만든 앱 2개는 사실 대단한 서비스가 아닙니다.
앱스토어에 출시할 계획도 없고, 수익을 만들 생각도 없습니다. 그저 제가 실제로 불편했던 문제를 해결하기 위해 만들었을 뿐입니다.
그런데 작업을 마치고 나서 가장 크게 남은 생각은 앱 자체보다 다른 곳에 있었습니다.
예전에는 불편함이 생기면 먼저 검색했습니다.
"이 기능을 제공하는 서비스가 있을까?"
"무료로 쓸 수 있는 앱은 없을까?"
그리고 대부분은 적당한 대안을 찾거나 그냥 참고 사용했습니다.
하지만 이제는 선택지가 하나 더 생겼습니다.
직접 만들어보는 것.
그래서 개인적으로 작은 실험 하나를 시작해보려고 합니다.
'내가 필요한 맥 앱 20개 만들기.'
거창한 목표는 아닙니다.
하루에 몇 번씩 반복하는 불편함, 매번 아쉬움을 느끼는 기능, 있으면 좋겠다고 생각했던 작은 도구들을 하나씩 직접 만들어보려 합니다.
아마 실패하는 앱도 많을 겁니다. 실제로 사용하지 않게 되는 앱도 있을 것이고요.
그래도 괜찮습니다.
이번 실험을 통해 얻은 가장 큰 배움은 결과물이 아니라 가능성이었기 때문입니다.
AI Native 시대는 단순히 일을 더 빨리 하는 시대가 아닙니다.
생각한 것을 직접 만들어볼 수 있는 시대에 더 가깝습니다.
그리고 이번에 만든 두 개의 앱은 그 첫 번째 실험이었습니다.
마무리하면서
많은 사람들이 AI 모델의 성능 차이에 집중합니다. GPT가 좋다, Claude가 좋다, Codex가 좋다 같은 이야기들이죠.
물론 그것도 중요합니다.
하지만 실제로 여러 도구를 사용해보니 더 중요한 건 모델 자체보다 어떻게 일하게 만들 것인가에 가까웠습니다.
Fable 구조를 적용한 Codex 실험도 그랬고, Claude Code로 앱을 만드는 과정도 마찬가지였습니다.
좋은 구조와 좋은 문제 정의가 있다면 생각보다 훨씬 많은 것을 만들 수 있습니다.
그래서 앞으로도 저는 새로운 서비스를 찾기 전에 먼저 만들어보려고 합니다.
그리고 그 과정에서 제가 필요한 맥 앱 20개를 채워나갈 생각입니다.
몇 개나 실제로 끝까지 사용하게 될지는 모르겠습니다. 다만 한 가지는 확실합니다.
AI 덕분에 처음으로 그 목표가 현실적으로 보이기 시작했다는 것 말입니다.