목록으로
업무 생산성 개선을 위한 AI 활용
AI 없이는 만들 수 없었던 앱 — 1인 개발자가 AI와 함께 3개월 만에 영어 읽기 앱 'Breeze'를 출시하기까지
코드는 AI 코딩 에이전트가, 진행 관리·QA·검토는 AI 어시스턴트가 맡고, 계획과 최종 승인은 제가 직접 하며 혼자서 iOS/iPad 영어 읽기 앱을 앱스토어에 출시한 경험입니다.
🤖 활용 AI 도구
Cursor(클라우드 에이전트), Grok Bot(AI 어시스턴트)
■ 어떤 상황에서 AI를 썼나요
저는 삼육대 컴퓨터공학과에 다니면서 프리랜서 iOS 개발자로 일하는 27살 고상범입니다. 영어 원서를 자주 읽는 사람은 모르는 단어를 하나하나 찾아 정리하는 게 번거로워서 결국 대충 넘기며 읽게 되고, 영어가 어려운 학생은 모르는 단어가 너무 많아 글을 읽기조차 힘듭니다. 이 문제를 풀고 싶어서 영어 책과 글을 읽기 위한 iOS/iPad 앱 'Breeze'를 만들기로 했습니다.
Breeze는 단어를 탭하면 문맥에 맞는 뜻을, 문장을 길게 누르면 문장 의미를 보여 줍니다. RSS 기사, EPUB, 스캔한 PDF(OCR)까지 어떤 글이든 가져올 수 있고, 모은 단어는 플래시카드로 공부합니다. 읽던 위치와 손글씨 필기는 기기 간에 동기화되고, '짧게 살펴보기'를 누르면 AI가 한국어 요약을 만들어 줍니다. 저도 수능 영어 PDF를 넣어 직접 쓰고 있습니다.
문제는 이 모든 것을 저 혼자 만들어야 했다는 점입니다. 솔직히 AI가 없었다면 '시간이 더 걸렸을' 정도가 아니라, 아예 만들 수 없었을 거라고 생각합니다.
■ 어떤 AI를 어떻게 썼나요
저는 AI를 역할별로 나눠 '팀'처럼 썼습니다.
- Cursor 클라우드 에이전트: 코드 작성, 디버깅, 테스트, CI 오류 수정, PR(코드 변경 요청) 생성까지 맡았습니다.
- Grok Bot(AI 어시스턴트): 진행 상황 관리, QA 정리, 머지 전 검토, 빌드 모니터링을 맡았습니다. 앱스토어 스크린샷도 웹앱 화면을 캡처해 템플릿과 합성한 뒤 App Store Connect에 올리는 데까지 처리했습니다.
AI가 계획을 제안하면, 어떤 계획으로 갈지는 제가 결정합니다.
■ 결과가 어떻게 달라졌나요
약 3개월 만에 Breeze를 만들어 앱스토어에 올렸습니다. 특히 실제 기기 없이도 버그 원인을 찾는 방식이 크게 달라졌습니다. 손글씨 동기화 문제 때, AI가 두 기기를 시뮬레이션해 문제를 재현하고 로그와 DB를 확인한 결과, '펜을 뗀 뒤 3초 후 업로드' 타이머가 화면에 손가락이 계속 닿아 있거나 앱이 백그라운드로 가면 실행되지 않아 필기가 아예 올라가지 않았다는 근본 원인을 찾아냈습니다.
물론 AI가 틀린 적도 있습니다. 당겨서 새로고침을 하면 하단 바가 사라지는 문제에서 AI는 처음에 "코드 변경은 없다"고 했지만, 저는 예전엔 없던 일이라고 주장해 비교 기준을 바꿔 다시 조사하게 했습니다. 예전 버전 1.9.3을 다시 설치해 보니 같은 증상이 나와, 앱 코드 문제가 아니라는 것까지 좁힐 수 있었습니다. 이때 AI는 스크린샷을 덮어씌우는 복잡한 우회책을 제안했지만 깔끔하지 않다고 판단해 거절했고, 대신 당겨서 새로고침 기능을 없애고 자동 새로고침으로 바꾼 뒤 조사 내용을 이슈로 기록했습니다.
어시스턴트 자신이 잘못 보고한 일도 있었습니다. '짧게 살펴보기'가 AI 기능이 아니라고 하거나, TestFlight 빌드 번호를 294라고 했는데 실제로는 Xcode Cloud가 번호를 다시 매겨 299였던 경우입니다. 둘 다 제가 직접 확인해서 바로잡았습니다.
■ 나만의 방식과 개선 포인트
1) '일론 모드': 모든 코드 작업에 '첫 원리로 생각하기 → 요구사항 의심하기 → 먼저 삭제하기 → 그다음 단순화 → 자동화는 마지막'을 적용합니다. 하단 바 문제를 우회책 대신 기능 삭제로 푼 것도 이 원칙 덕분입니다.
2) 큰 리팩터링은 반드시 계획서를 먼저 받고, 제가 승인한 뒤에만 진행합니다.
3) 머지 전에는 항상 테스트 결과와 스크린샷을 직접 보고, 기능 머지는 제 OK가 있어야 합니다.
4) 디자인은 참고 화면 하나를 템플릿으로 고정하고, 한 번에 하나씩만 바꾸며 단계별 목업으로 확인합니다.
5) 버그는 AI가 실기기 없이 재현하고 로그로 근본 원인을 찾게 하고, 실제 기기 확인은 마지막에 한 번만 합니다.
■ 다른 사람도 따라 할 수 있을까요
네, 충분히 가능하다고 생각합니다. 핵심은 AI를 '만능 개발자' 하나로 쓰지 않고 코드 담당과 관리·검토 담당으로 나누는 것, 그리고 계획과 최종 결정은 사람이 쥐고 있는 것입니다. "AI가 맞다고 해도 내가 확인한다"는 원칙 하나만 지켜도 혼자서 꽤 큰 일을 해낼 수 있습니다.
■ 윤리·책임: 이렇게 지켰어요
- 사람의 승인: AI는 계획을 제안할 뿐이고, 큰 변경과 기능 머지는 제가 승인해야만 반영됩니다.
- 검증: AI의 "문제없다", "이 번호다" 같은 말도 그대로 믿지 않고 이전 버전 재설치, 로그, 실제 빌드 기록으로 직접 확인했습니다. 잘못된 정보가 그대로 남지 않도록, 확인된 내용은 이슈로 기록했습니다.
- 출처 표시: 이 글에 나온 사례는 모두 제가 직접 겪은 일이며, 사용한 AI 도구는 위에 모두 밝혔습니다.
저는 삼육대 컴퓨터공학과에 다니면서 프리랜서 iOS 개발자로 일하는 27살 고상범입니다. 영어 원서를 자주 읽는 사람은 모르는 단어를 하나하나 찾아 정리하는 게 번거로워서 결국 대충 넘기며 읽게 되고, 영어가 어려운 학생은 모르는 단어가 너무 많아 글을 읽기조차 힘듭니다. 이 문제를 풀고 싶어서 영어 책과 글을 읽기 위한 iOS/iPad 앱 'Breeze'를 만들기로 했습니다.
Breeze는 단어를 탭하면 문맥에 맞는 뜻을, 문장을 길게 누르면 문장 의미를 보여 줍니다. RSS 기사, EPUB, 스캔한 PDF(OCR)까지 어떤 글이든 가져올 수 있고, 모은 단어는 플래시카드로 공부합니다. 읽던 위치와 손글씨 필기는 기기 간에 동기화되고, '짧게 살펴보기'를 누르면 AI가 한국어 요약을 만들어 줍니다. 저도 수능 영어 PDF를 넣어 직접 쓰고 있습니다.
문제는 이 모든 것을 저 혼자 만들어야 했다는 점입니다. 솔직히 AI가 없었다면 '시간이 더 걸렸을' 정도가 아니라, 아예 만들 수 없었을 거라고 생각합니다.
■ 어떤 AI를 어떻게 썼나요
저는 AI를 역할별로 나눠 '팀'처럼 썼습니다.
- Cursor 클라우드 에이전트: 코드 작성, 디버깅, 테스트, CI 오류 수정, PR(코드 변경 요청) 생성까지 맡았습니다.
- Grok Bot(AI 어시스턴트): 진행 상황 관리, QA 정리, 머지 전 검토, 빌드 모니터링을 맡았습니다. 앱스토어 스크린샷도 웹앱 화면을 캡처해 템플릿과 합성한 뒤 App Store Connect에 올리는 데까지 처리했습니다.
AI가 계획을 제안하면, 어떤 계획으로 갈지는 제가 결정합니다.
■ 결과가 어떻게 달라졌나요
약 3개월 만에 Breeze를 만들어 앱스토어에 올렸습니다. 특히 실제 기기 없이도 버그 원인을 찾는 방식이 크게 달라졌습니다. 손글씨 동기화 문제 때, AI가 두 기기를 시뮬레이션해 문제를 재현하고 로그와 DB를 확인한 결과, '펜을 뗀 뒤 3초 후 업로드' 타이머가 화면에 손가락이 계속 닿아 있거나 앱이 백그라운드로 가면 실행되지 않아 필기가 아예 올라가지 않았다는 근본 원인을 찾아냈습니다.
물론 AI가 틀린 적도 있습니다. 당겨서 새로고침을 하면 하단 바가 사라지는 문제에서 AI는 처음에 "코드 변경은 없다"고 했지만, 저는 예전엔 없던 일이라고 주장해 비교 기준을 바꿔 다시 조사하게 했습니다. 예전 버전 1.9.3을 다시 설치해 보니 같은 증상이 나와, 앱 코드 문제가 아니라는 것까지 좁힐 수 있었습니다. 이때 AI는 스크린샷을 덮어씌우는 복잡한 우회책을 제안했지만 깔끔하지 않다고 판단해 거절했고, 대신 당겨서 새로고침 기능을 없애고 자동 새로고침으로 바꾼 뒤 조사 내용을 이슈로 기록했습니다.
어시스턴트 자신이 잘못 보고한 일도 있었습니다. '짧게 살펴보기'가 AI 기능이 아니라고 하거나, TestFlight 빌드 번호를 294라고 했는데 실제로는 Xcode Cloud가 번호를 다시 매겨 299였던 경우입니다. 둘 다 제가 직접 확인해서 바로잡았습니다.
■ 나만의 방식과 개선 포인트
1) '일론 모드': 모든 코드 작업에 '첫 원리로 생각하기 → 요구사항 의심하기 → 먼저 삭제하기 → 그다음 단순화 → 자동화는 마지막'을 적용합니다. 하단 바 문제를 우회책 대신 기능 삭제로 푼 것도 이 원칙 덕분입니다.
2) 큰 리팩터링은 반드시 계획서를 먼저 받고, 제가 승인한 뒤에만 진행합니다.
3) 머지 전에는 항상 테스트 결과와 스크린샷을 직접 보고, 기능 머지는 제 OK가 있어야 합니다.
4) 디자인은 참고 화면 하나를 템플릿으로 고정하고, 한 번에 하나씩만 바꾸며 단계별 목업으로 확인합니다.
5) 버그는 AI가 실기기 없이 재현하고 로그로 근본 원인을 찾게 하고, 실제 기기 확인은 마지막에 한 번만 합니다.
■ 다른 사람도 따라 할 수 있을까요
네, 충분히 가능하다고 생각합니다. 핵심은 AI를 '만능 개발자' 하나로 쓰지 않고 코드 담당과 관리·검토 담당으로 나누는 것, 그리고 계획과 최종 결정은 사람이 쥐고 있는 것입니다. "AI가 맞다고 해도 내가 확인한다"는 원칙 하나만 지켜도 혼자서 꽤 큰 일을 해낼 수 있습니다.
■ 윤리·책임: 이렇게 지켰어요
- 사람의 승인: AI는 계획을 제안할 뿐이고, 큰 변경과 기능 머지는 제가 승인해야만 반영됩니다.
- 검증: AI의 "문제없다", "이 번호다" 같은 말도 그대로 믿지 않고 이전 버전 재설치, 로그, 실제 빌드 기록으로 직접 확인했습니다. 잘못된 정보가 그대로 남지 않도록, 확인된 내용은 이슈로 기록했습니다.
- 출처 표시: 이 글에 나온 사례는 모두 제가 직접 겪은 일이며, 사용한 AI 도구는 위에 모두 밝혔습니다.
