AI 시대, iOS 개발자의 방향성

AI를 활용해 개발한 지도 어느덧 시간이 꽤 흘렀다.
정말 초창기 GPT를 사용할 때만 해도, AI로 코드를 쓰는 일은 어딘가 조심스럽고 조금은 터부처럼 느껴졌다.
지금은 분위기가 완전히 달라졌다.
Cursor, Claude Code 같은 도구가 일상으로 들어왔고, 이제는 AI를 쓰는 것 자체보다 어떻게 쓰는지가 더 중요한 질문이 됐다.

그런데 흥미로운 점이 있다.
개발자 개인의 구현 속도는 분명히 빨라졌는데, 서비스 전체의 속도는 그만큼 빨라졌다고 말하기 어렵다.
내 손으로 직접 타이핑하는 시간은 줄었지만, 무엇을 만들어야 하는지 정리하고, 나온 결과가 맞는지 검증하고, 앞단에서 결정이 정리되기를 기다리는 시간은 여전히 크게 남아 있다.

나는 이 변화가 결국 iOS 개발자의 경쟁력을 다른 곳으로 이동시키고 있다고 생각한다.
직접 코드를 빠르게 쓰는 능력보다, 유즈케이스를 잘 정의하고, 플랫폼 제약을 이해하고, AI가 만든 산출물을 검증하고, 원하는 방향으로 다시 조정하는 능력이 더 중요해지고 있다.

AI가 코드 작성의 금기를 지운 시기

처음에는 AI가 작성한 코드를 그대로 쓰는 것에 심리적인 저항이 있었다.
"이걸 내가 짠 코드라고 말해도 되나?" 같은 어색함도 있었고, 품질을 확신하기도 어려웠다.
당시에는 AI가 내놓는 결과물도 지금보다 불안정해서, 한두 번 크게 실망하면 다시 손으로 돌아가기 쉬웠다.

하지만 시간이 지나면서 기준이 바뀌었다.
이제는 AI가 코드를 만든다는 사실 자체는 특별한 일이 아니다.
오히려 반복적인 구현, 익숙한 패턴, 실험적인 프로토타이핑에서는 AI를 쓰지 않는 쪽이 더 비효율적으로 느껴질 때도 많다.

다만 금기가 사라졌다고 해서 검증 비용까지 사라진 것은 아니다.
AI가 자연스러워졌을 뿐, 결과물을 책임지는 주체는 여전히 개발자다.

마이크로 프롬프팅에서 스킬과 문서 중심 작업으로

Cursor나 Claude Code를 막 쓰기 시작했을 때는 정말 마이크로 프롬프팅의 연속이었다.
함수 하나를 바꾸려 해도 어떤 파일을 보고, 어떤 규칙을 따르고, 어떤 형태로 구현해야 하는지 매우 꼼꼼하게 적어줘야 했다.
조금만 설명이 비면 다른 방향으로 가버렸고, 결국 내가 옆에서 세세하게 조종해야 했다.

지금은 체감이 꽤 다르다.
모델 자체가 좋아지기도 했고, 팀이나 개인이 쌓아둔 SKILL, AGENTS, 문서, 예제 코드가 있으면 훨씬 안정적으로 움직인다.
예전에는 한 번의 답변을 잘 받기 위해 프롬프트를 길게 썼다면, 이제는 AI가 오래 참고할 수 있는 기준 문서를 잘 써두는 편이 더 중요해졌다.

결국 프롬프트가 일회성 지시문에서 운영 문서로 이동한 셈이다.
물론 이것도 공짜는 아니다.
기준 문서가 부실하거나 모순되어 있으면, 모델이 좋아질수록 오히려 더 그럴듯하게 틀린 방향으로 갈 수 있다.

worktree와 병렬 작업이 만든 속도와 컨텍스트 스위칭 비용

예전에는 보통 하나의 Jira 티켓을 잡고 그 일에 집중했다.
작업 중간에 관련 아티클을 찾아보거나, 구현 방식을 비교해보거나, 조금 돌아가더라도 하나의 맥락 안에서 천천히 생각할 시간이 있었다.

AI를 쓰기 시작하고 나서는 작업 단위 자체가 달라졌다.
하나의 티켓만 붙잡는 대신 worktree를 열어 여러 작업을 병렬로 진행하는 일이 점점 자연스러워졌다.
한쪽에서는 버그를 수정하고, 다른 쪽에서는 기능을 붙이고, 또 다른 쪽에서는 프로토타입을 검증하는 식이다.

확실히 처리량은 늘어난다.
문제는 N개의 작업을 동시에 들고 가기 시작하면, 병목이 구현이 아니라 컨텍스트 스위칭으로 옮겨간다는 점이다.
AI가 각 작업의 초안을 빠르게 만들어주더라도, 내가 지금 어느 브랜치에서 무엇을 검증해야 하는지 헷갈리는 순간 생산성은 금방 무너진다.

지금 개발자가 실제로 반복하는 일: 유즈케이스 작성, 산출물 검증, 프롬프트 수정

요즘 개발을 하며 반복하는 행동을 떠올려보면, 예전과 꽤 다르다.
깊게 생각해서 한 줄 한 줄 코드를 작성한다기보다, 먼저 유즈케이스를 정리하고, 플랫폼에서 중요한 제약을 떠올리고, AI가 준 산출물을 실행해보고, 마음에 들지 않으면 프롬프트나 문서를 수정해서 다시 원하는 방향으로 유도한다.

즉 구현 자체보다 "무엇을 시켜야 하는가"와 "나온 결과가 맞는가"의 비중이 훨씬 커졌다.
버튼 하나를 만들어도 단순히 화면에 보이는지가 아니라,
정말 이 흐름이 유저의 행동과 맞는지,
로딩과 에러 상태가 빠졌는지,
iOS다운 인터랙션이 살아 있는지,
접근성이나 상태 복원이 깨지지 않는지를 보게 된다.

이 변화는 생각보다 크다.
AI가 코드를 대신 써주면서 개발자가 덜 생각하게 된 것이 아니라,
오히려 어디를 생각해야 하는지가 더 상위 레벨로 올라갔다.
다만 상위 레벨 사고는 눈에 덜 보이고, 잘못하면 "대충 시키면 되겠지"라는 착각으로 쉽게 무너질 수 있다.

왜 유즈케이스가 가장 중요한 자산이 되었는가

결국 가장 중요한 것은 유즈케이스라고 느낀다.
코드는 AI가 어느 정도 대신 써줄 수 있지만, 무엇을 만들어야 하는지에 대한 문맥은 여전히 사람이 책임져야 하기 때문이다.
특히 기능 요구사항, 예외 흐름, 실패 케이스, 상태 전환 같은 정보는 제대로 정리되어 있을수록 결과물의 품질 차이가 크게 난다.

이제는 코드보다 문서가 먼저 자산처럼 느껴질 때가 많다.
잘 정리된 유즈케이스 하나가 있으면, 그 문서를 기준으로 iOS 구현도 만들고, Android 구현도 만들고, QA 체크리스트도 만들고, 심지어 디자인 시안이나 테스트 시나리오까지 파생시킬 수 있다.

반대로 유즈케이스가 모호하면 모든 단계가 흔들린다.
AI는 빈칸을 채우는 능력이 좋지만, 그 빈칸이 제품적으로 중요한 결정이라면 개발자가 대신 판단해야 한다.

iOS/Android 공용 문서가 더 강해진 이유와 크로스플랫폼의 재평가

iOS와 Android는 플랫폼이 다르지만, 유저가 겪는 핵심 유즈케이스는 대체로 비슷하다.
예전에도 그래서 크로스플랫폼의 장점 중 하나는 공용 요구사항과 공용 문서를 중심으로 팀이 움직일 수 있다는 점이라고 생각했다.

지금은 그 장점이 더 커졌다.
AI의 속도가 문서에서 구현으로 넘어가는 시간을 크게 줄여줬기 때문이다.
공용 유즈케이스 문서가 잘 정리되어 있으면, 이를 기반으로 양쪽 플랫폼이 동시에 작업을 출발할 수 있고, 각자 필요한 플랫폼별 조정만 추가하면 된다.

이 지점에서 나는 크로스플랫폼을 단순히 기술 스택의 문제로만 보지 않게 됐다.
공용 문서를 잘 운영하고, 공용 언어를 유지하고, 구현 이전의 의사결정을 정리하는 체계까지 포함해서 봐야 한다.
물론 그렇다고 플랫폼 차이가 사라지는 것은 아니다.
네비게이션 감각, 라이프사이클, 접근성, 성능 이슈처럼 마지막 품질은 여전히 플랫폼 이해도에 크게 좌우된다.

AI Native와 역할 경계 확장: Node.js, Slack bot, RN, Flutter 프로토타이핑

요즘은 AI Native라는 말도 자주 보인다.
개발자가 특정 플랫폼 안에만 머무르기보다, 문제를 해결하기 위해 필요한 수단을 더 넓게 다루는 방향이다.

실제로 나 역시 사내에서 iOS 개발 외의 작업을 종종 하게 됐다.
Node.js로 Slack bot을 만들거나, 빠른 검증이 필요할 때 React Native나 Flutter로 프로토타이핑을 하는 일이 아주 특별하게 느껴지지 않았다.
예전 같으면 학습 장벽 때문에 시작 자체를 미뤘을 작업이, 이제는 AI 덕분에 "일단 한 번 만들어보자" 수준으로 내려왔다.

이 변화는 분명 강력하다.
하지만 가장 큰 문제가 기술 난이도만은 아니다.
러닝 비용은 줄었어도, 운영 비용과 품질 유지 비용, 그리고 결국 사용하는 모델 비용은 여전히 현실적인 제약으로 남는다.

그래도 서비스 속도가 안 나는 이유: 기획과 디자인 병목

개발자의 속도가 빨라졌는데도 서비스 속도가 체감상 크게 달라지지 않는 이유는 결국 앞단에 있다.
기획이 정리되고, 디자인이 나와야 프론트엔드 구현도 안정적으로 움직일 수 있기 때문이다.
뒤에서 아무리 빨라져도, 앞에서 무엇을 만들어야 하는지가 늦게 정리되면 전체 흐름은 그대로 느릴 수밖에 없다.

나는 오히려 AI가 이 사실을 더 선명하게 보여줬다고 생각한다.
예전에는 구현이 오래 걸려서 그 자체가 가장 큰 문제처럼 보였지만,
이제 구현 시간이 줄어드니 회의 정리, 요구사항 합의, 예외 케이스 정의, 디자인 결정의 지연이 훨씬 더 크게 보인다.

결국 서비스 속도는 개발팀만의 문제가 아니다.
한 단계라도 느리면 다음 단계가 함께 느려지고, AI는 그 연결 구조 자체를 없애주지는 못한다.

회의 요약 → 기획 정리 → 유즈케이스 → Jira → AI 디자인 → 구현의 이상적 흐름

그래서 지금 더 중요해지는 것은 구현 이전의 흐름을 얼마나 잘 설계하느냐다.
이를테면 기획 회의에서 클로바노트 같은 회의 요약 도구를 사용해 발화자와 대화 내용을 정리하고,
그 내용을 바탕으로 AI와 함께 서비스 기획을 구조화하고,
정리된 문서로 유즈케이스를 작성하고,
그 결과를 Jira 티켓으로 쪼개고,
다시 Stitch 같은 AI 디자인 툴로 와이어프레임을 잡아 구현에 들어가는 방식이다.

디자인 시스템이 잘 갖춰져 있다면 이 흐름은 더 강해진다.
단순한 러프 수준이 아니라, 꽤 프로덕션에 가까운 결과물을 빠르게 확보할 수 있기 때문이다.
이미 이런 식으로 일하는 팀도 적지 않은 것 같고, 하네스와 에이전트 팀을 잘 활용하면 사실상 한 사람이 감당할 수 있는 범위도 이전보다 커졌다.

물론 이상적인 흐름이 항상 그대로 굴러가지는 않는다.
회의 요약이 잘못되면 뒤 단계 전체가 흔들리고, 문서가 부정확하면 AI는 빠르게 잘못된 방향으로 일해버린다.

결론: 앞으로 살아남는 개발자의 역량

그래서 나는 iOS 개발자의 정체성이 사라진다고 생각하지는 않는다.
오히려 플랫폼 전문성은 여전히 중요하다.
UIKit이든 SwiftUI든, 내비게이션이든, 접근성이든, 성능이든, 마지막 품질을 책임지는 감각은 쉽게 대체되지 않는다.

다만 그 전문성 위에 더 중요해지는 것이 생겼다.
회의를 잘 이해하고,
제품 언어를 개발 언어로 번역하고,
유즈케이스를 빠짐없이 정리하고,
엣지 케이스를 먼저 떠올리고,
AI가 만든 결과를 빠르게 검증하고,
마음에 들지 않으면 다시 더 나은 방향으로 수정하는 역량이다.

예전에는 "코드를 잘 쓰는 사람"이 개발자의 핵심 이미지였다면,
지금은 "문제를 잘 정의하고 결과를 끝까지 책임지는 사람"에 더 가까워지고 있는 것 같다.
AI 시대의 iOS 개발자는 더 이상 구현만 하는 사람이 아니라, 플랫폼 감각을 가진 제품 실행자에 가까워지고 있다.