들어가며
2024년부터 2026년까지, 3년 연속 마운틴뷰의 Google I/O 현장에 다녀온 흐름을 중심으로 제가 생각하는 엔지니어링의 방향에 대해서 정리해 보려고 합니다. 세션 요약이 아니라, 그 사이의 고민을요. 요약은 이제 AI가 저보다 잘하니까요.
이 글에는 지난 3년 동안 한 명의 모바일 엔지니어가 “AI 시대에 나는, 그리고 팀은 어디로 가야 하는가”를 붙들고 해마다 바꿔 온 질문들과, 지금까지 찾은 답을 남기려고 합니다.
질문은 해마다 하나씩 생겼습니다.
- 2024년 AI로 무엇을 만들 수 있을까?
- 2025년 어떻게 내 것으로 만들고, 어떻게 지휘할 것인가?
- 2026년 개인은 빨라졌는데, 팀은 왜 그대로인가?
완성된 정답은 아닙니다. 다만 3년 동안 현장에서 부딪치며 다듬어 온, 지금 시점의 제 답입니다.
2019년의 자부심, 2024년의 상실감
제가 I/O에 처음 간 건 코로나 전인 2019년이었습니다. 행사는 사흘 동안 열렸고, 전 세계에서 수만 명의 개발자가 모였습니다. 부스는 Android, Kotlin, Jetpack의 새 기술로 가득했고, 밤에는 바비큐와 맥주를 나눠 먹었습니다. “내가 만드는 모바일 앱이 세상을 바꾼다”는 확신이 있던 해였습니다.
코로나를 지나 딱 5년 만인 2024년에 다시 마운틴뷰를 찾았습니다. 현장은 완전히 달라져 있었습니다. 행사는 이틀로 줄었고, 참가자도 북미 중심이었습니다. 무엇보다 무대 위에는 Android나 모바일 신기능 대신 Gemini 이야기만 가득했습니다. 키노트에서 ‘AI’라는 단어가 몇 번 나오는지 세는 게 밈이 되던 바로 그해입니다.
그 무대를 보며 거대한 파도 앞에 선 듯한 질문 하나가 떠올랐습니다.
“내가 10년 동안 쌓아 온 모바일 전문성은 이제 어디로 가는가?”
기술의 중심축이 통째로 옮겨가는 순간, 시니어 엔지니어라면 한 번은 마주치는 질문입니다. 솔직히 말하면 그때 제 감정은 기대보다 상실감에 가까웠습니다. 모바일이 무대 중심에서 밀려나고 있다는 아쉬움과 막연한 두려움이었습니다.
Q1. AI로 무엇을 만들 수 있을까 (2024)
물음표를 안고 I/O 다음 날 열린 GDG 커뮤니티 밋업에 갔습니다. 비슷한 고민을 안고 온 전 세계 개발자들의 Q&A가 이어지던 중, 한 스피커의 답이 인상깊었습니다.
“AI는 모바일의 자리를 빼앗는 경쟁자가 아닙니다. 모든 플랫폼의 가장 밑단에 스며들 새로운 인프라이자 엔진입니다. 여러분의 역할은 AI와 싸우는 게 아니라, 내 제품과 코드에 AI를 어떻게 녹여낼지 고민하는 것입니다.”
그 말을 듣고 나니 현장의 기술들이 다르게 보이기 시작했습니다. 큰 기대 없이 들어간 Project Starline 부스가 대표적이었습니다. 카메라 센서와 AI 컴퓨터 비전이 결합되니, 화면 너머에 진짜 사람이 앉아 있는 것 같은 3D 화상 회의가 되었습니다.
AI는 브라우저 챗봇 창에 갇힌 기술이 아니었습니다. 플랫폼과 하드웨어를 만날 때 비로소 상상하지 못한 사용자 경험이 만들어진다는 걸 피부로 느꼈습니다. 그렇게 2024년은 위기감이 아니라 첫 번째 질문을 남겼습니다.
Q1. What can I build with AI?
내 제품과 플랫폼에 AI를 결합해 어떤 새로운 가치를 만들 것인가?
웹 화면에 챗봇 API를 붙이는 수준을 넘어, 모바일 엔지니어가 이 엔진으로 무엇을 만들 수 있을지. 이 질문을 가지고 한국으로 돌아왔습니다.
그해 내가 한 것은? 프롬프트를 잘 쓰는 법
돌아와서 가장 먼저 붙든 건 프롬프트였습니다. AI로 무언가를 만들려면 먼저 AI를 잘 다뤄야 한다고 생각했고, 그 시절 AI를 잘 다룬다는 건 곧 프롬프트를 잘 쓴다는 뜻이었습니다. 어떻게 물어야 원하는 결과가 나오는지, 맥락을 어떻게 넣어야 하는지를 매일 붙잡고 있었습니다.
돌이켜 보면 그 고민은 2년 뒤면 누구나 갖춘 기본 소양이 될 기술이었습니다. 그래도 그 시기를 거쳤기에 “도구를 잘 쓰는 것”에서 “어떻게 내 것으로 만들고 지휘할 것인가”로 질문을 옮길 수 있었습니다.
Q2. 어떻게 내 것으로 만들고, 어떻게 지휘할 것인가 (2025)
2025년 I/O는 회사 지원 없이 제 연차와 제 돈으로 갔습니다. 환율이 1달러에 1,400원을 넘나들던 때였습니다. 가장 먼저 든 생각은 이것이었습니다. “다 생중계되는 시대에 굳이 수백만 원을 들여 갈 가치가 있나?”
그래도 갔습니다. 모니터로 보는 키노트는 화려한 AI 차력쇼일 뿐이었고, 제가 알고 싶었던 건 그다음이었습니다. 저 기술을 어떻게 내 실무 아키텍처와 프로덕트에 가져올 것인가. 그 답은 현장 사람들에게 직접 물어보지 않고는 얻을 수 없다고 생각했습니다.
요약본에는 ‘내가 어떻게 생각하는지’가 없다
2025년 키노트 현장은 묘했습니다. 예전에는 다들 노트북을 두드리며 받아 적기 바빴는데, 이날은 대부분 팔짱을 끼고 듣기만 했습니다. 발표가 끝나자마자 링크드인과 X에는 AI가 정리하고 시각화까지 끝낸 요약본이 수십 개씩 올라왔습니다.
이번에도 궁금한 생각이 들었습니다. AI가 요약도 나보다 잘하고 글도 더 조리 있게 쓰는데, 나는 왜 아직 공부하고 글을 쓰는가. 현장에서 부딪쳐 보고 나서야 답이 보였습니다. AI가 못 하는 건 ‘내가 어떻게 생각하는지’를 전하는 일입니다. 직접 발로 뛰며 몸으로 겪은 경험과 그 위에 쌓인 나만의 판단이었습니다. 이 글을 쓰는 이유이기도 합니다.
모델을 고르는 사람에서, 에이전트를 지휘하는 사람으로
당시 개발자들은 모이기만 하면 “요즘 코딩할 때 Claude 써, GPT 써, Gemini 써?”를 물었습니다. 현장에서 만난 동료들과 이런 이야기를 나눴습니다. “내년이면 모델 이름이 아니라 ‘어느 에이전트가 일을 잘해?’를 묻고 있을 거다.” “미래의 개발자는 코드를 치는 사람이 아니라, 스타크래프트처럼 여러 에이전트를 다루며 자기 영역을 빌드업하는 사람일 거다.”
그렇게 두 번째 질문을 안고 돌아왔습니다.
Q2. How to embody & orchestrate
저 압도적인 기술을 구경만 할 게 아니라, 어떻게 내 것으로 체화하고 내 프로덕트 안에서 에이전트들을 지휘할 것인가?
그해 내가 한 것은? 일을 쪼개서 맡기는 법
2025년은 AI에게 일을 어떻게 맡겨야 하는지를 본격적으로 고민한 해였습니다. 2024년의 질문이 “어떻게 잘 물을까”였다면, 2025년의 질문은 “일을 어떻게 쪼개서 시켜야 AI와 에이전트가 일을 잘할까”였습니다. 프롬프트 한 줄을 다듬는 일에서, 일 자체를 설계하는 일로 관심이 옮겨간 겁니다.
특히 스킬을 직접 만들어 쓸 수 있다는 점에 푹 빠졌습니다. 내가 일하는 방식을 스킬로 만들어 두면 에이전트가 그대로 이어받아 일합니다. 도구를 쓰는 사람에서 도구를 직접 제작하는 사람이 된 것 같아서 너무 재밌었습니다.
그런데 일을 잘게 쪼개 맡길수록 돌아오는 결과물도 많아졌습니다. 자연스럽게 다음 질문이 따라왔습니다. “이 코드를 누가, 어떻게 검증하고 책임질 것인가?” 2026년 현장에 품고 간 질문은 여기서 나왔습니다.
Q3. 개인은 빨라졌는데, 팀은 왜 그대로인가 (2026)
2026년에는 회사의 지원을 받아 3년 연속 마운틴뷰에 다녀왔습니다. 온라인에는 “더 강력해진 Gemini와 차세대 에이전트” 같은 뻔한 3줄 요약 기사만 가득했지만, 쇼어라인 앰피시어터는 2층 지정석과 뒤편 잔디밭까지 개발자로 꽉 차 있었습니다. 그리고 잔디밭과 부스에서 나눈 대화의 주제는 완전히 바뀌어 있었습니다.
2024년과 2025년의 관심사는 ‘개인 최적화’였습니다. 무슨 도구를 쓰는지, 프롬프트를 어떻게 쓰는지. 2026년에 만난 엔지니어들은 하나같이 다른 이야기를 했습니다.
“이제 팀원 모두 각자 AI 쓰는 건 다 적응했어. 그런데 팀 전체의 출시 속도는 왜 그대로일까?”
개인이 코드를 빠르게 찍어내기 시작하자, 오히려 팀 프로세스에서 전에 없던 병목이 터져 나오고 있었습니다. 크게 세 가지였습니다.
병목 ① 코드 리뷰
AI 덕분에 코드 작성 속도는 5배, 10배 빨라졌습니다. 하지만 코드를 읽고 맥락을 파악하고 검증하는 사람의 속도는 10년 전과 같습니다. 큰 PR이 쌓이고, 리뷰어는 지치고, 승인이 밀리면서 배포 파이프라인이 막히는 역설이 생깁니다. AI가 10초 만에 짠 코드를 사람이 30분 동안 읽는 구조가 계속 갈 수 있을까요?
병목 ② 테스트와 품질 검증
코드를 만드는 비용은 0에 가까워지는데, 그 코드를 검증하고 장애를 책임지는 비용은 여전히 사람의 몫입니다. 그래서 현장에서 기회가 될 때마다 집요하게 물었습니다. “AI로 코드가 쏟아지는데, 테스트와 QA는 어떻게 하고 있나요?”
대답은 만나는 사람마다 달랐습니다.
- “테스트 에이전트 파이프라인을 붙여서 실험 중이에요.”
- “장애나면 결국 사람이 책임져요. 개발자가 직접 돌려보지 않은 코드는 머지 못 하게 막아요.”
- “솔직히 답을 못 찾아서 매주 팀 규칙을 바꾸며 헤매는 중이에요.”
병목 ③ 개발만 빨라져서는 제품이 안 나온다
구현을 반나절 만에 끝내도, 기획의 요구사항 정의와 디자인 싱크, 의사결정은 예전 속도 그대로입니다. 제품이 나오는 속도는 가장 빠른 단계(개발)가 아니라 가장 느린 단계(협업과 조율)가 정합니다. 개발자 혼자 도구를 잘 쓰는 것만으로는 한계가 분명했습니다. 비개발 직군과 AI를 매개로 어떻게 협업 방식을 맞출 것인가가 다음 숙제였습니다.
실리콘밸리도 답이 없었다
세 가지 병목을 두고 대화하며 얻은 가장 큰 수확은 기술적인 테크닉이 아니었습니다. “나만 막막한 게 아니었구나”라는 안도감이었습니다.
한국에 있을 때는 막연한 두려움이 있었습니다. 미국 빅테크는 이미 완벽한 AI 개발 시스템을 갖춰 두고 날아가고 있을 테니, 나만 이 병목 앞에서 쩔쩔매고 있는 건 아닐까. 그런데 현장의 엔지니어들도 똑같이 리뷰와 품질, 협업 앞에서 머리를 싸매고 있었습니다.
완벽한 은총알을 가진 팀은 어디에도 없었습니다. 정답이 정해진 시험을 치는 게 아니라, 모두가 각자의 자리에서 답을 만들어 가는 시기였습니다. 그걸 확인하자 불안은 사라지고 “그렇다면 우리 팀도 우리 방식으로 당당하게 부딪쳐 보자”는 용기가 생겼습니다.
경쟁력은 개인의 프롬프트에서 팀의 파이프라인으로 옮겨갔다
2026년 현장이 준 엔지니어링의 결론은 선명했습니다.
- 프롬프트 스킬은 기본 소양이 됐다. 혼자 AI로 코드를 빨리 짜는 건 더 이상 차별점이 아닙니다. 2024년의 제가 가장 공들였던 바로 그 기술이 2년 만에 기본값이 된 겁니다.
- 진짜 경쟁력은 팀 시스템 설계다. 쏟아지는 코드 속에서 품질과 안정성을 지키는 구조, 리뷰 병목을 풀고 비개발 직군과 속도를 맞추는 방식입니다.
- 엔지니어의 역할이 넓어진다. 코드를 치는 작성자(Writer)를 넘어, 팀의 신뢰성 파이프라인을 지휘하는 오케스트레이터로.
2025년에 품고 갔던 “어떻게 지휘할 것인가”라는 질문은 이렇게 더 큰 단위로 돌아왔습니다. 지휘해야 할 대상은 에이전트 몇 개가 아니라 팀 전체의 흐름이었습니다.
지금까지 찾은 나의 답
답 1. 우리 팀이 온전히 이해하고 책임질 수 있는 방식으로
빅테크조차 표준 매뉴얼 없이 각자 실험하고 있다면, 남의 화려한 방식을 성급하게 쫓아가며 불안해할 이유가 없습니다. 우리 팀이 온전히 이해할 수 있고, 장애가 나도 처음부터 끝까지 책임질 수 있는 방식인가. 그 속도로 차근차근 소화하기로 했습니다.
답 2. 고객을 테스터로 삼지 않는다
AI 코딩이 흔해지면서 묘한 유혹이 번지고 있습니다. “어차피 금방 고치니까 일단 배포하고, 터지면 핫픽스 치면 되지.” 하지만 실제 고객을 마주하는 프로덕트, 특히 모바일 앱에서 이건 위험한 생각입니다.
고객은 한 번의 결제 오류, 한 번의 크래시만으로도 서비스를 떠납니다. 버그를 10분 만에 고쳤다고 고객이 겪은 나쁜 경험이 사라지지는 않습니다. 구현 속도가 아무리 빨라져도 품질과 안정성은 엔지니어가 끝까지 지켜야 할 마지노선입니다. 고객을 우리 불완전한 코드의 테스터로 만들지 않는다. 저는 이 원칙에 대해서는 타협하지 않기로 했습니다.
답 3. 개발자는 문제를 기술로 해결하는 사람이다
이 답에는 2026년 데미스 하사비스 대담이 큰 힌트가 됐습니다. 진짜 AGI의 기준을 묻는 질문에 그는 ‘아인슈타인 테스트’를 제시했습니다. 학습 데이터를 1901년까지만 주었을 때, 1905년의 아인슈타인처럼 세상에 없던 이론을 스스로 만들어 낼 수 있는가. 시험을 만점 받는 건 기존 데이터를 재조합하는 보간(interpolation)일 뿐이라는 것이죠.
같은 대담에서 그는 밤마다 코딩 에이전트로 게임 프로토타입을 만든다고 했습니다. 예전엔 팀이 6개월을 매달려야 했을 작업을 이제는 몇 시간 만에 끝낸다면서요. 그에게 코딩 에이전트는 개발자를 대체하는 적이 아니라 생각을 빠르게 형체로 만드는 도구였습니다.
두 이야기를 합치니 제 생각도 단순해졌습니다. 반복적인 코드와 보일러플레이트는 AI에게 맡길 수 있습니다. 하지만 이 기능이 왜 필요한지 문제를 정의하고, 어떤 구조로 안정적으로 만들지 결정하는 건 여전히 개발자의 몫입니다. 바뀐 건 도구와 방식이지, 문제를 기술로 푸는 사람이라는 본질은 그대로입니다.
Direction over Velocity
대담에서 사회자가 이렇게 물었습니다. 매주 새 기술이 쏟아지는 지금, AI 파도에 뛰어드는 빌더들에게 해주고 싶은 경고는 무엇인가. 하사비스의 답은 이랬습니다.
“너무 빠른 속도는 깊은 성찰을 방해합니다. 잘못된 방향으로 시속 100마일로 달리는 것은, 가만히 서서 올바른 방향을 고민하는 것보다 훨씬 나쁩니다.”
방향이 틀렸다면 AI로 코드를 빨리 짜는 건 기술 부채를 시속 100마일로 찍어내는 일일 뿐입니다.
앞으로도 새 기술 앞에서 두 가지 질문을 나침반으로 삼으려 합니다.
- 저 기술은 세상의 어떤 문제를 해결하려고 나왔는가?
- 우리 서비스는 고객의 어떤 문제를 풀기 위해 존재하는가?
마치며: 멈춰 선 것과 묻지 않는 것은 다르다
하사비스의 말에 저는 한 줄을 덧붙여 보고자 합니다. 멈춰 서는 것이 문제가 아니라, 멈춰 선 채 아무것도 묻지 않는 것이 문제라고요.
3년이 지난 지금도 “AI가 밥그릇을 뺏어간다”는 말을 듣습니다. 저도 그 질문에서 출발했기에 그 마음을 가볍게 여기지 않습니다. 2024년 쇼어라인 앰피시어터에 앉아 있던 제가 정확히 그 마음이었으니까요. 다만 저에게 불안은 출발점이었지 답이 아니었습니다. 그 질문을 붙들고 해마다 현장에 갔고, 질문은 “무엇을 만들까”에서 “어떻게 지휘할까”로, 다시 “팀은 어떻게 함께 빨라질까”로 바뀌어 왔습니다.
하지만 같은 질문이라도 3년 동안 붙들고 씨름한 사람과, 그 자리에 그대로 서 있던 사람의 질문은 더 이상 같지 않습니다. 저는 답을 다 찾았다고 말하지 않습니다. 다만 찾아가고 있다고는 말할 수 있습니다.
그 자리에 서 있어도 괜찮습니다. 함께 가지 않아도 됩니다. 다만 그 불안이, 앞에서 길을 내려는 사람들의 시도를 깎아내리거나 발목을 잡는 이유가 되지는 않았으면 합니다.
이 시기의 답은 누군가 대신 정리해 주지 않습니다. 실리콘밸리에도 없었습니다. 저는 앞으로도 먼저 방향을 잡고 부딪쳐 보는 쪽에 서려고 합니다.