개발자 어썸블로그

늙은 것은 나뿐이었다

2026-10-31T10:02:00+09:00

며칠 전 코엑스에서 열린 2026 정주영 창업경진대회 데모데이에 다녀왔습니다.
무료 행사인데다 장병규 의장님이 키노트를 한다길래, 바람이나 쐴 겸 절친과 다녀왔답니다.
오랜만에 젊은 창업가들의 에너지도 느끼고 좋은 이야기도 듣고 왔습니다.

키노트에서 가장 기억에 남은 것은 컴포트 존에 대한 이야기였습니다.
장병규 의장님 자신도 계속 컴포트 존을 벗어나려고 애쓰고 있고, 그렇게 할 때 또 다른 가능성이 열린다는 말.

사실 처음 듣는 이야기는 아니었습니다.
오래전 카카오의 브라이언이 NHN을 떠나면서 했던 말이 떠올랐습니다.

배는 항구에 있을 때 가장 안전하지만, 그것이 배의 존재 이유는 아니다.

저는 컴포트 존에 관한 이야기를 그때 처음 들었던 것 같습니다.
이미 잘하고 있고 편하게 머무를 수 있는 곳을 떠나서 다시 도전한다는 것.
그 말이 저에게는 꽤 큰 영향을 줬습니다.

회사에서 일이 익숙해지고 편해졌다 싶으면 또 다른 도전을 하곤 했습니다.
지금 1인 개발자로 10년 가까이 돈을 벌고 살고 있는 건 그때 했던 도전들이 거름이 된 것이 분명합니다.
편해진다는 생각이 들때마다 불편함을 기꺼기 찾아갈 용기와 에너지가 있었던 것 같습니다.

시간이 오래 흘러 다시 이 이야기를 들으면서 지금의 제 모습을 돌아보지 않을 수 없었습니다.
지난 몇 년 동안 너무 편하게 살았습니다.
컴포트 존 안에 머물러 있으면서, 밖으로 나가려는 노력은 거의 하지 않았던 것 같습니다.
이보다 더 좋은 인생이 어디 있냐는 오만한 생각을 하면서요.

어린 창업가들의 발표를 보면서 또 한 번 놀랐습니다.
다들 너무 자연스럽게 영어를 하는 겁니다.

요즘 젊은 사람들은 영어가 그냥 기본이구나.
처음부터 세계를 무대로 생각하는구나.

외국인 창업가들이 한국에서 창업하고 발표하는 모습도 인상적이었습니다.
요즘 강남역이든 코엑스 앞이든 어딜 가도 외국인들이 참 많아졌다고 느끼는데…
행사장 안에서도 그랬습니다.
말로만 듣던 글로벌 세상이 갑자기 눈앞에 툭 떨어진 것 같았습니다.

그중에서도 가장 인상적인 장면은 심사위원들의 질문 시간.
외국인 창업가에게 질문해야 하는데, 저는 당연히 통역을 쓸 줄 알았습니다.
심사위원들은 나이가 좀 있으니까.

그런데 웬걸.
너무나 유창한 영어로 질문하고 답변을 주고받는 겁니다.

젊은 사람들만 달라진 줄 알았는데 그것도 아니었네. 허허…
늙은 것은 나뿐이었구나.
어느새 옛날 기준으로 세상을 보고 있는 늙은이가 되어 있는 저를 보았습니다.

아이들 교육도, 저 자신을 발전시키는 일도 다시 생각하게 됐습니다.
편하게 바람이나 쐬러 갔다가 되려 불편해져서 돌아왔네요. (웃음)

✔️

함께 읽으면 좋은 글:

LLM 캐시는 어떻게 작동할까: 앤트로픽 S-1 보고서로 읽는 AI 인프라 효율화

2026-10-28T10:00:00+09:00

Anthropic은 S-1에서 같은 수준의 모델 성능을 제공하는 데 필요한 추론 연산을 줄이고, 운영 환경에서 연산 자원의 활용 효율도 높여 왔다고 설명한다. – 「Compute Efficiency」 요약¹

정도현 - 로보코 수석 컨설턴트

TL;DR

LLM 인프라는 같은 성능의 작업에 필요한 연산을 줄이고, 확보한 자원을 더 잘 활용하는 방향으로 발전하고 있다. Anthropic S-1의 추론 효율 설명은 이 흐름을 보여주는 근거 중 하나다.
프롬프트 캐시는 동일한 입력 앞부분을 처리하며 만든 KV 캐시를 재사용한다. 긴 문서를 다시 계산하는 일을 줄이되, 새 질문의 처리와 답변 생성은 계속 수행한다.
대규모 인프라에서는 공통 계산을 메모리 블록으로 공유하고, 캐시 위치와 부하를 고려해 요청을 분산한다. 일부 시스템은 GPU 밖의 메모리와 저장소에도 캐시를 보관한다.
캐시 효율을 높이려면 누구의 계산을 누구와 공유할지 먼저 정해야 한다. 사용자별 격리는 재사용 범위를 줄일 수 있으며, GPU 밖으로 옮긴 캐시에도 같은 권한 경계를 유지해야 한다.
캐시의 효과는 재사용 빈도, 메모리 여유, 전송 비용에 따라 달라진다. 재처리하는 입력 토큰이 줄어든 비율을 전체 비용 절감률로 해석해서는 안 된다.

같은 제품 설명서를 들고 상담원을 찾아간다고 생각해 보자. 첫날에는 설명서를 처음부터 읽어야 한다. 다음 날 다른 질문을 했는데, 상담원이 그 설명서를 또 처음부터 읽는다면 어떨까. 질문에 답하는 시간보다 같은 자료를 반복해서 읽는 시간이 더 길어질 수 있다.

LLM은 Silver Bullet 일까?

2026-10-28T15:33:08+09:00

대략 2년 만에 글을 쓰기 위해 키보드를 타이핑해 본다. 그동안 주로 연말에 작성하는 회고록이나 지식을 전달하기 위한 정보성 및 트러블 슈팅 경험을 위해 글을 작성해 왔다. 하지만, LLM(이하 AI로 명칭 하겠다.)의 발전으로 인해 지식 전달을 위한 글은 stack overflow의 감소된 트래픽처럼 사람들이 많이 찾지 않고 있기에 TIL Repository에 정제되지 않은 상태로 업데이트하거나, 개인 Notion에만 정리를 하게 된 것 같다. 글을 쓰는 것도 운동처럼 관성인 것 같다. 한 번 놓게 되면, 글을 쓰기 위해 다시 시간을 내어 자세를 잡기까지 꽤나 큰 준비가 필요하다. 필자도 이 글을 쓰기 위해 손가락 스트레칭을 2년 정도 했다 ㅋ. 요즘 너무 많은 사람들이 AI가 주는 환상으로 인해 잘못된 위기를 느끼거나, 느끼게 하는 것 같아 조금은 바로 잡고 싶은 마음에 이 글을 작성하게 되었다.

이야기에 앞서 LLM의 동작에 대해 간단하게 정리해보고자 한다. Provider에 따라 핵심 알고리즘과 Architecture는 다르겠지만 큰 맥락은 다음과 같다고 생각한다.

1. Tokenize input text
2. Convert tokens into embeddings (add positional information)
3. Process them through Transformer layers with self-attention
4. Predict a probability distribution for the next token
5. Select a token, append it, and repeat until completion
6. Detokenize tokens into output text

위의 과정을 한 줄 요약하면 다음과 같다. "LLM은 입력 토큰을 벡터로 바꾼 뒤, Transformer가 문맥을 반영해 만든 내부 표현(hidden vector)과 각 후보 토큰의 출력 벡터의 내적을 계산하여 다음 토큰의 확률을 예측한다." 즉, LLM은 학습 데이터로부터 학습한 파라미터를 바탕으로 현재 문맥에서 다음에 올 가능성이 높은 토큰을 예측한다. 기억하자. LLM은 다음 토큰을 예측하는 것이 핵심이다. 이 내용을 토대로 다음의 주제들에 대한 필자의 견해를 풀어가 보려고 한다.

"우린 다 필요 없어"

LinkedIn이나 Youtube에 올라오는 AI 관련 글, 영상들을 보면 서로가 서로를 필요 없다고 하고 있다. 개발자들은 디자이너와 PM이 필요 없다 하고, 디자이너는 개발자와 PM이 필요 없고, PM은 개발자와 디자이너가 필요 없다고 한다. AI Agent를 통해 다른 영역까지 Leverage 할 수 있게 되어 발생하는 현상이라고 생각한다. (다른 업계는 어떻게 생각할지 모르겠다. 필자는 백엔드 엔지니어이기 때문에 이 글에서는 IT업계에 한정해서 이야기하려고 한다.) 필자는 이런 이야기를 하는 사람들을 보면 그들은 애매한 전문가 포지션에서만 일을 했기 때문에 저런 말들을 한다고 생각한다. AI로 인해 IT업계의 인력이 감축될 수 있다는 것에는 동의한다. 다만, 방향을 잘못짚었다고 생각한다. 우리는 여전히 각 필드의 전문가들이 필요하다. 하지만 코로나 영향으로 많은 영역에서 디지털 전환이 시작됐고, IT 업계로 수많은 인력이 쏠리기 시작했다. 회사는 애매한 전문가들도 필요에 의해 그들이 갖고 있는 역량보다 높은 금액을 지불하고 채용하게 됐다고 생각한다. 개발자를 예로 들면, 요구 사항을 코드로 잘 작성하기만 하면 전문가로 모셔왔다. 이로 인해 수많은 부트캠프들이 생겼고, 비슷한 수준의 개발자들이 양산되기 시작했다. 조금 공격적으로 표현하자면 필자는 이런 사람들을 개발자라고 생각하지 않는다. 요구 사항을 컴퓨터가 실행할 수 있는 기능으로 번역해 주는 Code Translator일 뿐이다. 이 정도의 전문성을 갖고 있는 사람들은 AI가 대체하게 될 것이다. 추론의 방향이 명확하기 때문이다. IT 업계에서 Software Engineer 포지션으로 계속 일하고 싶다면, 코드는 수단일 뿐이라는 것을 이해해야 한다. 엔터프라이즈 급의 서비스를 지탱하고 있는 분산 환경의 Backend System을 PM이나 디자이너에게 AI를 쥐어주고 운영하라고 하면 그들이 할 수 있을까? 반대로, 서비스의 10x 성장을 위한 Branding, Marketing, Design, VOC Operation에 대한 전략 수립과 실행을 Engineer에게 AI를 쥐어주고 해내라고 한다면 폭발적인 결과를 낼 수 있을까? 한두 달 운영하면서 바이럴로 한탕해 먹고 튀는 도파민 용 서비스를 제공하는 게 목적이 아니라면 물음표를 던지고 싶다.

필자는 현재 시기를 지식 산업에서 "진짜" 필요한 사람이 누구인지를 필터링하는 시기라고 생각한다. 우리가 풀어가야 할 문제가 너무나도 많기에 애매한 전문가도 우리는 전문가로 대우해 주었다. 하지만 AI로 인해 애매한 전문가는 이제 필요 없어졌다. 우리는 각 영역의 진짜 전문가만 필요하게 됐다고 생각한다. 아이러니한 상황이다. AI로 인해 모두가 전문가가 될 수 있고, 정보의 빈부격차가 해소될 것이라고 하지만 필자가 생각하는 미래는 정보의 빈부격차가 더 심해질 것이고, 전문가의 수는 더욱 적어질 것이라고 생각한다. 엄밀히 말하면, 정보의 빈부격차보다는 지능의 빈부격차라고 생각한다. 여기서 필자가 이야기하는 전문가는 한 분야를 오랫동안 갈고닦은 사람을 칭하는 것이 아니다. 어떠한 지식을 얼마나 능동적으로 빠르고 깊이 있게 학습하고, 현재 상황에 필요한 solution을 AI와 함께 도출해 내는 사람을 전문가라고 말하고 싶다. 기술의 발전으로 정보를 얻을 수 있는 과정은 정말 싸졌지만, 반대로 그 정보를 학습하고, 이해하고 사용하는 비용은 비싸졌다. 많은 사람들이 바보가 되고 있기 때문이다. 그렇기에 필자는 말하고 싶다. 지식산업에서 살아남고 싶다면 더욱 전문가가 되어야 한다고. 애매한 전문가는 이제 필요 없을 것이다. AI는 전문가에게 쥐어주는 증폭기일 뿐이다. 모든 걸 알잘딱깔센으로 처리 해주는 도구가 아니다.

"There is no Silver Bullet"

소프트웨어 공학은 AI 시대 이전에도 추상화되는 방향으로 발전했다. 사실 소프트웨어 공학뿐만 아니라 모든 공학은 성숙해질수록 추상화 단계가 올라간다. 자율주행도 같은 맥락이다. 우리는 더 이상 운전하는 법을 몰라도 자동차를 이용하여 목적지까지 갈 수 있게 됐다. 사람은 그저 출발지와 목적지, 경로를 선택하면 된다. 사용자는 운전에 대해 더 이상 학습하지 않아도 되지만, 교통 공학자들은 이런 환경에서 어떻게 하면 더 효율적으로 도로를 설계하는 게 좋을지 고민해야 한다. 소프트웨어도 마찬가지이다. 코드를 구현하는 일들은 이제 추상화되겠지만, 그 코드가 실행되는 전체적인 시스템을 디자인해야 하고, AI가 이해하기 쉽도록 더 좋은 구조로 코드가 설계되어야 한다. 우리는 AI 덕분에 더 본질적인 고민을 할 수 있는 시대가 되었다. 이 고민 또한 AI가 추론해 주겠지만 앞서 이야기한 Code Translator와 다르게 이 과정은 추론의 방향이 명확하지 않다. 여러 추론들의 결과들이 나올 수 있고, 우리는 현재 상황과 미래를 고려하여 선택해야 한다. 선택을 하기 위해서는 기존보다 더 많은 지식을 요구하게 될 수 있다. 중요한 것은 이러한 방향은 기존의 발전 방향과 크게 다르지 않다는 것이다.

우리는 어떤 기술이 나올 때마다 Silver Bullet은 없다는 것을 명심해야 한다. 기존에도 그랬고, LLM도 마찬가지이다. LLM은 절대 소프트웨어 공학의 Silver Bullet이 아니다. Context Window라는 명확한 한계가 존재하고, 이로 인해 할루시네이션이 발생하는 문제가 있다. 모든 결과는 추론이기 때문에 비결정적인 문제를 안고 있다. 같은 input을 넣어도 같은 output이 나오지 않기 때문에 소프트웨어 공학의 근간이라고 할 수 있는 함수라는 개념을 만족시키지 못한다.

"AI Slop"

Youtube나 LinkedIn을 보다 보면 "토스", "쿠팡" 출신의 PO가 퇴사 후 AI Agent 팀을 만들어 토스의 스쿼드 팀을 만들었다는 영상이나 글들이 종종 올라오곤 한다. 그들의 행보를 보고 있노라면 솔직히 말해 안쓰러울 때가 있다. 그들은 대부분 AI를 Leverage 하여 좋은 서비스를 출시해서 승부하려는 사람들이 아닌 AI를 잘 모르는 사람들을 현혹하여 강의를 팔고 있거나, 인플루언서를 꿈꾸는 사람들이다. 필자는 아직까지 그들이 어떤 서비스를 만들고 있고, 어떤 유의미한 결과를 도출하고 있는지 모르겠다. AI를 활용하여 릴스 공장을 만드는 것..? 그 이상 그 이하도 아니라고 생각한다. 좋은 서비스는 AI 딸깍으로 나오는 것이 아니다. 그리고 그들은 서비스를 만드는 것만 이야기한다. 하지만 서비스를 만드는 것보다 서비스를 성공적으로 운영하는 것이 서비스의 성공을 좌지우지하는 데 더 큰 요소로 작용한다. 각 영역의 전문가들이 필요한 때이다. 물론, AI를 활용하여 서비스를 운영하면 10명이 붙어야 가능한 일을 1~2명이 처리할 수도 있다. 한두 달 운영하고 폐기할 서비스를 몇 십 개 만들어서 생활에 필요한 돈을 벌 목적이 아니라면 AI를 사용하더라도 혼자서 할 수 있는 일은 없다. Vibe Coding을 통해 수많은 App들이 출시되고 있지만, 모바일 시장의 수요는 전혀 증가하지 않았다.

AI로 인해 1인 창업의 시대가 열린 것은 확실하다. 하지만 창업 아이템이 App 서비스이고, AI 군단을 전두지휘하여 성공해 보겠다는 생각이라면 본인 결정에 AI가 주는 환상은 없었는지 검토를 해보자.

"진짜만 살아남는 시대"

블라인드 혹은 LinkedIn을 보고 있다 보면 많은 개발자, 디자이너들이 자신의 직업을 잃을까 걱정하는 글을 많이 볼 수 있다. 그와 반대로 PM, PO 직군은 이상할 정도로 자아가 비대해져 있다. 솔직하게 말하면 그들은 어떠한 분야도 제대로 파고들어 보지 않은 조율자에 불과하다. 미래의 인재는 AI Agent를 전두지휘할 수 있는 Supervisor, Operator라는 분위기 덕분에 조율자 역할을 하고 있는 PM, PO 직군의 사람들이 환상을 갖게 된 게 아닐까 싶다.

앞서 이야기했듯이 AI로 인해 애매한 전문가 포지션으로 일하는 사람들은 모두 위기인 세상이 온 것에 이견은 없다. 하지만 필자는 이야기하고 싶다. 미래의 지식산업은 단언컨대, 진짜 전문가만 살아남을 것이다. 지식의 가치는 낮아지겠지만 지능의 가치는 더욱 희소성을 갖게 될 것이다. 문제를 정확하게 정의하고, 여러 Solution들 중 감수할 수 있는 trade off가 뭔지 고민할 수 있고, 선택한 Solution에 대해 정확히 이해하고 있고, 어떤 방법을 통해 검증할 것 인지를 명확하게 정의할 수 있는 전문가는 앞으로도 필요한 사람일 것이다. 문제는 Engineering의 이슈일 수도, Marketing의 이슈일 수도, 서비스의 방향성의 이슈일 수도 있다. 어떠한 직군이든 각 이슈를 정확하게 진단하여 문제를 해결할 수 있는 전문가들만 지식 산업에서 살아남을 것이다.

하지만 꼭 지식산업에서 살아남을 필요는 없다. ROI가 안 나올 수도 있고, 업계에서 살아남는다고 행복한 삶은 아닐 수 있다. 다만, 가짜들이 떠드는 말들로 불안해하지는 말자. 각자의 가치관과 비전으로 정진하면 된다. "빈 수레가 요란하다"라는 말을 명심하자. 지금이야말로 누군가의 달콤한 말에 현혹되지말고, 각자의 길을 스스로 결정할 때이다.

Blog: [메모] adb install vs android install 차이점 분석 및 비교

2026-11-01T18:00:00+09:00

Android CLI의 android install은 단순한 adb install의 래퍼(Wrapper)가 아닙니다. 소스 빌드 연동 기능과 함께, 변경된 바이트만 전송하는 증분 설치(Delta Install)를 기본값으로 사용합니다.

두 도구의 내부 동작 차이를 분석하고, 로컬 에뮬레이터와 네트워크 대역폭 제한 환경에서 설치 속도를 비교했습니다.

본 글은 Gemini를 사용하여 초안을 작성한 후 검수하였습니다.

본 글에서 사용된 도구 버전 및 환경(2026년 10월 31일 기준)은 다음과 같습니다.

Android CLI: 1.1.16717390
Android Debug Bridge (adb): 1.0.41 (platform-tools 37.0.1-15733141)
Android Gradle Plugin (AGP): 9.5.0
Kotlin: 2.4.21
Target Device: Android Virtual Device (Pixel 9a, API 37, arm64-v8a)

1. 핵심 차이점 한눈에 보기

비교 항목	adb install	android install
도구 성격	Low-level 범용 기기 통신 도구 (`platform-tools`)	High-level Android 개발자/에이전트 워크플로 CLI
입력 형태	로컬 APK 파일 경로만 지원	로컬 APK 경로뿐만 아니라 빌드 참조 ([system://][path]?[target]) 지원
빌드 연동	불가 (사전에 빌드 완료된 APK 필요)	소스 빌드와 배포를 한 번에 연동 가능 (– )
증분 설치 (Delta)	`--fastdeploy` 옵션 필요 (별도 agent)	`--use-delta-install` 기본 활성화 (default: true)
전송 최적화	Streaming Install 지원 (`--streaming`)	변경된 delta 패치 파일만 기기로 전송 (Zero-copy 활용)
다중 APK 지원	install-multiple, install-multi-package 분리	–apks=a.apk,b.apk 로 단순화
실행 연계	설치만 수행	설치만 수행 (`android run` 시 설치 후 launch까지 연동)

(1) 소스 빌드 참조(Build Reference) 지원

adb install은 오직 디스크에 존재하는 .apk 파일만을 대상으로 동작합니다. 반면 android install은 Android CLI 1.1부터 빌드 참조 문법을 직접 인식합니다.

# 로컬 APK 파일 설치
android install --apks=app/build/outputs/apk/debug/app-debug.apk

# Gradle 프로젝트 빌드 후 설치까지 한 번에 수행
android install :app
android install ~/MyProject?:app@debug -- --offline

빌드 타깃을 지정하면 CLI가 프로젝트 구조를 분석해 빌드를 실행하고, 생성된 APK를 찾아 기기에 바로 설치합니다.

(2) 기본 Delta Install (증분 패치) 지원

android install은 증분 설치 옵션(--use-delta-install)을 기본값(true)으로 사용합니다.

기기에 이전 버전의 앱이 이미 설치되어 있다면, APK 전체를 보내지 않고 로컬 APK와 기기 설치본의 차이(Delta)만 계산해 패치 파일(.seq)을 전송합니다.

기기의 임시 디렉터리(/data/local/tmp)에 배포 에이전트(installer.jar)를 올려 커널의 Zero-copy 시스템 콜로 패치를 적용한 뒤 Package Manager에 반영합니다.

2. 벤치마크 환경 구성

두 도구의 설치 소요 시간과 Delta Install의 데이터 전송 절감량을 확인하기 위해 아래 시나리오별로 테스트를 진행했습니다.

테스트 시나리오

APK 내 특정 영역만 변경되는 상황을 시뮬레이션하기 위해 4종류의 APK 변형(Variant)을 생성했습니다.

fresh: 앱을 완전히 삭제(uninstall)한 상태에서 최초 설치
same: 동일한 APK를 덮어쓰기 재설치
code: Kotlin 코드 상수만 변경 (classes*.dex만 변경)
res: 문자열 리소스만 변경 (resources.arsc만 변경)
asset: 에셋 파일 1개만 변경 (assets/marker.txt만 변경)

또한 APK 크기에 따른 전송 대역폭 영향을 보기 위해 두 가지 크기로 측정했습니다.

기본 Compose 앱: 약 11~12MB
대용량 리소스 포함 앱: 약 52MB (비압축 40MB 더미 페이로드 포함)

3. 결과 비교

1) 로컬 에뮬레이터 환경

로컬 에뮬레이터는 호스트 메모리 버퍼를 통해 데이터를 전달하므로 네트워크 전송 병목이 없습니다. 5회 반복 측정 후 중앙값 기준입니다.

① 기본 Compose 앱 (약 11~12MB)

시나리오	adb install -r	android install (기본 delta)	android install (delta OFF)
fresh	0.26s	1.17s	1.13s
same	0.32s	1.01s	1.03s
code	0.32s	1.01s	1.07s
res	0.36s	1.04s	1.05s
asset	0.33s	1.06s	1.03s

② 52MB 앱 (대용량 에셋 포함)

시나리오	adb install -r	android install (기본 delta)	android install (delta OFF)
fresh	0.46s	1.50s	1.22s
same	0.57s	1.54s	1.30s
code	0.52s	1.47s	1.24s
res	0.48s	1.42s	1.28s
asset	0.52s	1.38s	1.28s

결과 분석

로컬 에뮬레이터에서는 adb install -r이 더 빠릅니다.

Android CLI 자체를 기동하는 데 약 0.45초의 기본 오버헤드가 발생합니다.
전송 지연이 없는 환경에서는 50MB 전체를 전송하더라도 0.5초 안에 끝나므로, 차이점(Delta)을 계산하고 기기에서 패치 에이전트를 구동하는 시간이 전송 절약 시간보다 더 깁니다.

2) 실기기 / Wi-Fi 디버깅 환경 (5 MB/s 대역폭 제한)

실제 개발 환경에서는 Wi-Fi 페어링 무선 디버깅이나 USB 2.0 케이블 연결처럼 전송 대역폭이 제한되는 환경이 많습니다. 이를 재현하기 위해 에뮬레이터 포트 앞에 5 MB/s 전송 속도 제한 프록시를 두고 재측정했습니다.

※ 배수 비교는 adb install -r 대비 android install의 소요 시간 기준이며, 절감율은 전체 APK 크기 대비 실제 전송된 패치 크기 기준입니다.

① 52MB 앱 (대역폭 5 MB/s)

시나리오	adb install -r	android install (Delta ON)	절감율 / 전송량
fresh	10.41s	11.63s	전체 전송 (51.80 MB)
same	10.44s	1.52s (adb 대비 약 6.8배 빠름)	554 KB 전송 (98.9% 절감)
code	10.44s	1.45s (adb 대비 약 7.2배 빠름)	584 KB 전송 (98.9% 절감)
res	10.53s	1.68s (adb 대비 약 6.3배 빠름)	1.46 MB 전송 (97.2% 절감)
asset	10.52s	1.63s (adb 대비 약 6.4배 빠름)	1.46 MB 전송 (97.2% 절감)

② 11~12MB 기본 앱 (대역폭 5 MB/s)

시나리오	adb install -r	android install (Delta ON)	절감율 / 전송량
fresh	2.30s	3.48s	전체 전송 (11.33 MB)
same	2.31s	1.28s (adb 대비 약 1.8배 빠름)	89 KB 전송 (99.2% 절감)
code	2.32s	1.29s (adb 대비 약 1.8배 빠름)	140 KB 전송 (98.8% 절감)
res	2.40s	1.54s (adb 대비 약 1.6배 빠름)	1.02 MB 전송 (91.4% 절감)
asset	2.40s	1.49s (adb 대비 약 1.6배 빠름)	1.02 MB 전송 (91.4% 절감)

결과 분석

전송 속도가 제한되는 네트워크나 USB 환경에서는 android install이 훨씬 빠릅니다.

adb install -r은 변경된 내용이 적더라도 52MB 전체를 스트리밍 전송하므로 매번 10초 이상(10.44s~10.53s) 걸립니다.
반면 android install은 584KB 패치 파일만 전송(전송량 98.9% 절감)하므로 전송 시간을 0.1초대로 줄여 전체 설치를 1.45초(약 7.2배 빠름)에 마칩니다.

4. “adb –fastdeploy”와의 차이

adb install에도 --fastdeploy 옵션이 있지만, 아래 경고를 출력하며 일반 전체 설치로 전환될 수도 있습니다.

Fast Deploy is only compatible with devices of API version 24 or higher, ignoring.

반면 android install의 Delta Install은 Android Studio 배포 시스템(Deployer)의 기술을 CLI에 적용해 최신 OS에서도 정상적으로 패치 설치를 수행합니다.

5. 요약 및 상황별 추천

android install을 써야 하는 경우
- 실기기 디버깅(특히 Wi-Fi 무선 디버깅): 코드나 리소스 일부만 수정하고 재설치할 때 전송 시간이 대폭 줄어듭니다.
- 대용량 프로젝트: APK 크기가 클수록 Delta 패치 전송의 절약 효과가 큽니다.
- 빌드와 배포 연동: :app 같은 타깃 참조를 넘겨 빌드와 설치를 명령어 하나로 실행할 때 적합합니다.
adb install을 써야 하는 경우
- 로컬 에뮬레이터 반복 테스트: 전송 병목이 없어 CLI 기동 오버헤드가 없는 adb가 0.2초대로 가장 빠릅니다.
- 가벼운 CI/CD 파이프라인: 별도의 Android CLI 스택 없이 platform-tools만 설치된 환경에서 배포할 때 유리합니다.
- 세부 설치 옵션 제어: --instant, --abi, 다중 패키지 원자적 설치 등 저수준 Package Manager 옵션이 필요할 때 사용합니다.

Blog: [요약] The latest in Android dev tools (Android Dev Summit '26)

2026-10-31T21:00:00+09:00

기존 안드로이드 CLI 도구는 사용자 대화형 입력(Interactive Prompt)을 요구해 AI 에이전트가 자동으로 처리하기 어려웠습니다.

Android Dev Summit 2026의 “The latest in Android dev tools” 세션에서는 터미널, 데스크톱 에이전트 앱, Android Studio에서 AI 에이전트가 직접 제어할 수 있는 새로운 안드로이드 도구 체인을 발표했습니다.

본 글은 Gemini를 사용하여 초안을 작성한 후 검수하였습니다.

개요: AI 코딩 에이전트 시대의 안드로이드 개발 도구

핵심 구성 요소

Android CLI: 터미널 스크립트, CI, 에이전트 앱, Android Studio 전체를 관통하는 단일 엔트리 포인트 도구
Agent Applications: Google Antigravity, Claude Code, OpenAI Codex 등과의 딥 인테그레이션(공식 플러그인 & Sidecar)
Android Studio Rabbit 2/3: ACP(Agent Client Protocol) 기반 BYOA(Bring Your Own Agent) 및 AI Change Review

데모 전반에는 40개 모듈로 구성된 대규모 오픈소스 오디오/비디오 팟캐스트 앱인 Pocket Casts가 사용되었습니다.

1. Android CLI

Android CLI는 AI 에이전트가 안드로이드 도구를 실행할 때 생기는 파싱 오류와 불필요한 대기를 없애도록 만들었습니다.

예측 가능한 명령어 체계 (Predictable commands)
JSON 등 기계가 읽기 쉬운 구조화된 출력 (Structured outputs)
추가 입력 프롬프트 없이 즉시 끝나는 비대화형 실행 (Zero interactive prompts)

주요 신규 명령어 (`android --ads`)

명령어	주요 기능 및 특징
signals	Crashlytics의 크래시 목록 및 현장 텔레메트리 데이터를 조회
device	연결된 기기/에뮬레이터 미러링(device hub) 및 원격 물리 기기 대여(Reservation) 관리
profiler	앱, 게임, 디바이스의 시스템 트레이스(Perfetto) 및 힙 덤프 수집
build	Gradle 등의 빌드 아티팩트를 CLI에서 직접 빌드
preview	Android Studio나 실제 기기 없이 터미널에서 Jetpack Compose @Preview를 PNG 및 JSON 컴포넌트 트리로 렌더링
install	변경된 바이트만 전송하는 델타 푸시(Delta push) 배포 (기존 ADB 대비 대폭 시간 절약)
input	복잡한 좌표 계산 대신 시맨틱 UI 요소를 대상으로 제스처 및 키 이벤트 전송
analyze	AAB/APK의 R8 설정, 난독화 비율, DEX 크기 및 리소스 분석
docs	공식 안드로이드 지식 베이스(KB)에서 최신 가이드 문서를 온디맨드로 로컬 검색 및 fetch
auth	안드로이드 CLI 도구용 Google 서비스 인증 로그인/로그아웃

2. 터미널 환경의 에이전트 자동화 데모 (Claude Code)

(1) 프로덕션 크래시 재현 및 핫픽스

Firebase Crashlytics에 보고된 실제 크래시를 에이전트가 탐색, 재현, 코드 수정, 배포 및 검증까지 단 1분 42초 만에 수정했습니다.

데모

크래시 탐색: android signals 명령어로 지난 30일간 사용자 발생 수가 가장 높은 크래시를 조회
- 원인: 비밀번호 재설정(“I forgot my password”) 버튼을 연속 두 번 탭하면 네비게이션이 중복 실행되어 IllegalArgumentException이 발생
  
  IllegalArgumentException: Navigation action … cannot be found from the current destination
기기에서 재현: android layout으로 버튼 좌표를 확인한 뒤 android input tap으로 버튼을 두 번 탭해 실제 기기에서 크래시 발생
코드 수정: 중복 화면 이동을 막도록 SignInFragment.kt와 PromoCodeFragment.kt의 네비게이션 로직에 currentDestination 확인 가드를 추가
고속 재배포: android build로 빌드한 뒤 android install을 실행해 전체 84MB APK 대신 3.84MB 델타 패치만 기기로 전송
검증: 기기에서 다시 더블 탭을 실행해 크래시 로그가 남지 않고(0 lines) 화면이 정상 유지됨을 확인

사용된 Android CLI commands

android signals crashes list --firebase-app ... --sort-by=users --timeframe=30d
- 최근 30일간 사용자 수 기준 상위 크래시 이슈 랭킹 조회
android signals crashes describe <issue> --timeframe=30d
- 해당 크래시의 상세 스택 트레이스 및 디바이스/안드로이드 OS 버전별 분포 확인
android layout --device=... --flat
- 수정 전/후 비밀번호 재설정 버튼의 좌표를 파악하기 위한 UI 레이아웃 트리 조회
android input tap --device=... "id:btnSignIn"
- 구버전 로그인 화면으로 진입하기 위한 시맨틱 탭 전송 (2회 실행)
android build "gradle://?:app:assembleDebugProd"
- 수정된 코드의 빌드 산출물 생성
android install --device=...
- 초기 수정 전 빌드 설치, 핫픽스 빌드 델타 패치 주입 (84MB 중 3.84MB만 전송)
  (참고: CLI가 지원하지 않는 화면 회전 고정, 딥링크 호출, 백키 입력, 더블탭 등 일부 작업에는 adb를 보조로 사용)

(2) APK 최적화: R8 Configuration Analyzer

Release Bundle이 너무 크다는 요청에 대해 에이전트가 ProGuard/R8 룰을 분석하고 불필요한 keep 룰을 제거했습니다.

데모

원인 파악: Protocol Buffers keep 룰이 지나치게 포괄적이어서 불필요한 클래스까지 난독화 대상에서 제외되고 있었습니다.
- 수정 전 : -keep class * extends com.google.protobuf.GeneratedMessageLite { *; }
- 수정 후 : -keepclassmembers class * extends com.google.protobuf.GeneratedMessageLite { ; }
클래스 전체를 유지하지 않고, 실제 사용하는 필드 멤버와 Retrofit 반환 타입으로 호출되는 API 메시지만 유지(keep)하도록 수정

개선 결과:

비압축 DEX 크기: 19,485,804 B → 18,957,388 B (-528 KB, -2.7%)
APK 압축 크기: 42,311,672 B → 42,147,832 B (-164 KB)
Keep된 메서드 수: 17,940개 → 11,757개 (-6,183개 제거, -34%)
Keep된 필드 수: 7,944개 → 7,209개 (-735개 감소)
Keep된 클래스 수: 2,342개 → 2,268개 (-74개 감소)
DEX 난독화 비율: 92.72% → 93.06% (+0.34%p)

사용된 Android CLI commands

android analyze ./before/app-release.apk
- 수정 전 베이스라인 APK의 DEX 크기, R8 설정 및 난독화 비율(Obfuscation ratio) 측정
android analyze ./after/app-release.apk
- 룰 수정 후 생성된 APK의 수치를 동일하게 추출하여 개선 지표 비교
  (참고: CLI에 Configuration Analyzer 출력 파싱 명령어가 없어 상위 룰 랭킹에는 보조 스크립트 활용)

(3) 앱 시작 시간(Startup Time) 최적화: Baseline Profile & Profiler

앱 시작 성능 개선 요청 시 에이전트가 공식 문서를 읽고 프로파일러를 통한 측정을 수행했습니다.

데모

원인 분석: 출시 버전 프로토타입 APK의 baseline.prof가 약 8KB에 불과하며, 포함된 6,690개 룰 중 Pocket Casts 자체 코드 룰이 0개(전체 프로필 로드 룰 중에서도 단 66개)여서 시작 코드가 JIT/인터프리터로 구동되고 있음을 확인
최적화 수행: 공식 문서를 읽어 무루팅 환경(Android 14+)에서 베이스라인 프로필을 수집 및 생성하는 절차를 확인하고, 콜드 스타트 프로필 룰(Pocket Casts 룰 2,621개 포함)을 갱신

사용된 Android CLI commands

android profiler systemtrace start --launch --duration=8
- 앱 콜드 런치(Cold start) 시점의 시스템 트레이스를 Perfetto 형식(*.pftrace)으로 수집 (수집된 트레이스는 ui.perfetto.dev에서 분석)
android docs fetch kb://android/topic/performance/baselineprofiles/manually-create-measure
- Android 14+ 기기에서 루팅 없이 Baseline Profile을 수동 생성하고 측정하는 최신 공식 기술 가이드라인 로컬 fetch 및 학습

개선 수치 (Pixel 6 Pro 기준):

Main-thread CPU 시간: 297.7ms → 244.7ms (-17.8%)
Total app CPU 시간: 809.3ms → 600.4ms (-25.8%)
JIT thread CPU 시간: 56.3ms → 15.6ms (-72.2%)
Time to initial display (TTID): 463.2ms → 383.4ms (-17.2% 단축)

3. Linux 데스크탑에서 Android 앱 네이티브 실행 (실험적 프로토타입)

별도의 무거운 에뮬레이터나 중첩 가상화(Nested Virtualization) 없이, Linux 데스크톱 상에서 Android x86 APK를 단일 네이티브 프로세스로 직접 실행하는 새로운 기술이 공개되었습니다.

초경량 구조: 단일 프로세스로 실행되며 stdout/stdin으로 로그가 직접 출력됨
클라우드 에이전트 환경 최적화: 중첩 가상화를 지원하지 않는 클라우드 VM이나 CI 컨테이너에서도 에이전트가 앱을 직접 실행하고 테스트 가능
높은 완성도:
- 순수 Compose 앱 실행
- 네트워크 통신이 포함된 Google 레퍼런스 앱 실행
- 네이티브 .so 라이브러리 변환 계층을 통해 C++ 라이브러리와 오디오 출력이 포함된 실제 Pocket Casts 앱 구동
- 데스크톱 변환 계층을 통한 OpenGL ES 1 네이티브 게임 앱 렌더링

4. AI 에이전트를 위한 공식 Android 플러그인

Google Antigravity, Claude Code, OpenAI Codex를 위한 공식 Android 플러그인이 배포되었습니다.

플러그인을 활성화하면 Android CLI 뿐만 아니라, 공식 최신 지식/가이드가 포함된 Android Skills가 주입되어 모델의 오래된 학습 데이터 대신 항상 최신 아키텍처 표준을 따릅니다.

Google Antigravity

(1) Android Compose Preview

AI 에이전트에게 기존 View 코드를 Compose로 변환하고 대화면(폴더블·태블릿)에 맞게 최적화하도록 요청하면, 에이전트가 @Preview 어노테이션을 작성하고 Sidecar 패널에 프리뷰 화면을 즉시 렌더링합니다.

전체 앱 컴파일 및 기기 배포를 반복하지 않고, Sidecar 창에서 프리뷰 렌더링을 즉시 갱신
대화면에서 1열 스크롤 대신 헤더와 에피소드 목록을 좌우로 나누는 듀얼 창(Dual-pane) 레이아웃을 제안

(2) Android Device Hub

Antigravity 내에서 가상 기기(AVD) 및 물리 기기를 통합 관리하고 화면을 직접 미러링할 수 있습니다.

Pixel 10 Pro Fold 등 실제 연결된 기기 목록과 가상 기기(AI Glasses, Medium Phone, Small Phone 등)를 Sidecar 패널에서 통합 관리
미러링된 기기 화면을 보며 실시간 터치와 제스처로 상호작용 가능

화면 분할(Split Screen) 전환 시 앱이 싱글 페인(Single-pane)과 듀얼 페인(Dual-pane) 사이를 적응형(Adaptive)으로 올바르게 전환하는지 실시간 검증

Android CLI 연동에 따른 에이전트 효율성 벤치마크

Claude Opus를 대상으로 6개 사용자 Journeys 및 6개 디바이스에서 메모리 누수를 찾고 수정하는 과제를 Android CLI 사용 여부에 따라 A/B 테스트한 결과입니다.

작업 완료 속도: 1.9배 향상 (88분 → 46분, 42분 단축)
토큰 사용량: 1.3배 절감 (4.6M 토큰 → 3.5M 토큰)
Compose Preview: 전통적인 컴파일/실행 반복 대비 반복 시간 77% 단축
Analyze 명령어: 다중 왕복 검사를 단일 구조화 명령어로 대체하여 출력 토큰 5.5배 절감
Semantic Input: 화면 좌표 추정 환각(Hallucination)을 없애 작업 실행 속도 25% 향상

5. Android Studio와 AI 에이전트의 진화

(1) Bring Your Own Agent (BYOA) via Agent Client Protocol (ACP)

Android Studio는 내장 Gemini 외에도, 개발자와 팀이 이미 사용 및 구독 중인 외부 에이전트를 IDE로 가져올 수 있는 BYOA 기능을 도입했습니다.

경로: Settings > Tools > AI > Agents
Agent Client Protocol (ACP) 기반으로 다양한 에이전트 연결 지원:
- Built-in Agent v2.0
- Google Antigravity
- Claude Agent (Claude Code / Anthropic API 연동)
- OpenAI Codex
- JetBrains Junie
- ACP Agent Marketplace
기존 개인 구독이나 기업용 계정을 그대로 활용 가능

연결된 에이전트(예: Claude Opus 5.5)는 Android Studio의 모든 도구 체인(파일 수정, 정적 분석, 빌드, Gradle 싱크, Compose 프리뷰 렌더링, 기기 배포, 공식 문서 조회)에 직접 접근할 수 있습니다.

(2) AI Change Review

대량의 코드를 검토할 때 버그를 사전에 잡을 수 있도록 지원하는 코드 리뷰 기능입니다. 로컬 변경점뿐만 아니라 PR도 분석합니다.

15개 파일, 800줄의 PR 변경점을 분석해 잠재적 버그를 사전에 감지
데모에서 발견된 실제 이슈:
- 북마크 스와이프 행 컴포저블(SwipeRow.kt)에서 LaunchedEffect 키가 람다 객체로 설정되어 있어, 행이 Recomposition될 때마다 풀 스와이프 동작이 중복 실행되는 버그
- 삭제 다이얼로그가 뜬 상태에서 북마크 삭제 확인 다이얼로그가 계속 중복 노출되는 문제
해결책 제시 및 일괄 반영: 원인을 설명하고 rememberUpdatedState를 적용한 코드 diff를 제공합니다. 체크박스로 선택한 이슈를 버튼 한 번으로 일괄 수정(Fix all selected issues) 가능
주제별 워크스루(Walkthrough): PR 내 변경 사항을 기능 단위로 묶어 코드 변경 내역을 확인하고 승인 가능

(3) Android Studio Rabbit 릴리스 현황

기술 뉴스 #305 : 2026-11-01

2026-11-01T14:46:18+09:00

웹개발 관련

The Future of CSS ✨ : 브라우저 업체들이 협력해 브라우저 간 새로운 기능 도입을 원활하게 하는 Interop 프로젝트에서 2027년에 원하는 기능을 투표받고 있다. Josh Comeau가 자신이 투표한 10가지 기능을 정리했다. 함수 기능을 지원하는 CSS Function, 다양한 모서리를 지원하는 corner-shape, 테두리를 원하는 대로 그릴 수 있는 border-shape, 앵커 위치 지정 API 레벨 2, 상속 값을 계산에 사용할 수 있는 inherit()를 소개한다. 스크롤 트리거 애니메이션, 반응형 디자인에서 요소의 순서를 조정할 수 있는 reading-flow와 reading-order도 다룬다. auto 같은 키워드 값 사이에서 애니메이션을 적용할 수 있는 interpolate-size와 calc-size(), 그리드 갭 꾸미기 기능, 스크롤 상태 컨테이너 쿼리 기능도 소개한다.(영어)
Introducing tsrs: a Port of TypeScript to Rust : Cloudflare와 VoidZero가 Max Schwenk와 함께 TypeScript 컴파일러를 Rust로 포팅한 tsrs를 개발하고 있다. 언어의 설계와 방향은 TypeScript 팀이 주도할 수 있도록 긴밀하게 협력하고 있고 tsrs는 개발자들이 기다리는 시간을 줄이는 것을 목표로 하고 있고 초기 벤치마크 결과는 TypeScript 7.0보다 최대 8배 빠르고 메모리는 70% 더 적게 사용한다.(영어)
Deploy with Void : VoidZero를 인수한 Cloudflare에서 Cloudflare 배포를 Vite 워크플로와 통합한 Void Platform, Void SDK, Void CLI를 오픈소스로 공개했다.(영어)

그 밖의 개발 관련

How the Claude Code team does code review : Anthropic에서 코드 변경 사항이 많아지면서 개선하고 있는 코드리뷰 방식을 설명한 글이다. 코드 리뷰의 주요 목적은 배포 전에 문제를 찾아내는 것인데, 사람의 검토 자원은 희소하므로 대부분을 자동화한다. 사람의 검토는 최소한으로 하면서도 롤백이나 사고 없이 병합되는 것을 목표로 한다. 모든 Pull Request에 AI 코드리뷰를 사용하고 여러 에이전트가 검토해서 실제로 문제라고 동의한 경우에만 해당 내용을 게시하고 이에 AI가 대응하게 하고 별도의 보안검토까지 끝나면 변경 등급에 따라 1명 내지 2명의 사람이 리뷰하도록 하고 있고 버그가 발생하거나 리뷰를 작성자가 대응하는 방식을 검토해서 리뷰를 계속 개선하고 있다. 사람은 diff를 읽기보다는 기계가 잘하지 못하는 의사 결정에 집중하고, 문제가 생겼을 때는 직접 해결한다.(영어)
- Local and Distributed Large LLM Inference with MLX and RDMA on Mac Studio : Apple silicon에서 오픈소스 배열 프레임워크인 MLX를 사용해서 Meta의 오픈 웨이트 모델인 Muse Spark Open을 실행하는 방법을 설명한다. 512GB Mac Studio 단일 머신에서 오픈 웨이트 모델의 성능을 측정했다. 한 대에 담을 수 없는 Muse Spark Open은 2대를 연결해 Thunderbolt 5 기반 RDMA로 통신하고, 텐서 병렬화로 추론 속도를 높인다. 이러한 개선을 통해 Mac Studio 4대의 클러스터로 초당 36개의 토큰을 생성할 수 있게 되었다.(영어)
We gave AI agents a mobile dev environment : Shopify에서 모바일 개발을 병렬로 처리할 수 있는 에이전트 기반 워크플로우를 구축했지만 로컬 컴퓨팅 자원의 제한을 해결하기 위해 작업을 위임할 수 있는 Remote Dev를 제공하게 되었다. 이는 백엔드와 웹은 River라는 Slack의 AI 에이전트로 일하던 방식을 모바일에도 적용한 것이다. 모바일의 특성을 고려해서 스크린샷을 보는 것 외에도 시뮬레이터와 WebSocket으로 연결해서 실시간으로 조작할 수 있다.(영어)
ID-JAG, Explained: The New OAuth Grant for Cross-App Access : AI 에이전트나 SaaS 앱에서 사용자가 권한을 허용하는 과정을 계속 반복하는 문제를 해결하기 위해 새로 만든 OAuth 권한 부여 명세가 ID-JAG(Identity Assertion JWT Authorization Grant)다. AI 에이전트가 앱에 연결할 때 사용자 주도 OAuth로 매번 동의를 요청하면 사용자는 피로해져 나중에는 자동으로 동의하게 된다. 중앙에서 통제하기도 어렵고, 기존 인증은 여러 앱에 접근하는 에이전트에 맞게 설계되어 있지 않다. ID-JAG는 사용자의 동의 대신 기업 정책에 따라 접근 권한을 결정하는 방식으로 바꾼다.(영어)
Beyond API Compatibility: Building a Tool to Measure the Blast Radius of Library Changes : Netflix에서 API나 라이브러리의 호환성을 깨뜨리는 변경 사항을 사전에 알 수 있게 저장소 전반의 심볼 정의와 참조를 색인화한 Quasar를 만들었다. Quasar를 통해 공개 API에서 무엇이 바뀌었고 변경된 심볼을 사용하는 저장소가 어디인지를 파악할 수 있다. 각 저장소의 CI에서 SCIP를 사용해 언어별로 식별자의 관계를 인코딩하고 라이브러리 버전과 API 정의를 Quasar에 전송한다. Quasar에서 이 정보를 바탕으로 해당 API를 사용하는 곳을 파악할 수 있다.(영어)
GitHub Universe 2026: Evolving every layer of the stack : GitHub Universe 컨퍼런스에서 에이전트를 사용할 수 있는 GitHub Copilot 앱, 작업에 필요한 내용을 분석한 뒤 하나 이상의 모델을 선택해서 작업하는 Copilot Fusion, 병렬 세션으로 작업할 수 있는 Copilot project를 발표했다. 기기나 도구를 바꿔도 세션을 이어갈 수 있는 Session continuity, 저장소에서 AI 기반 워크플로우를 만들 수 있는 Copilot automations, AI로 코드 리뷰를 하는 Copilot code review도 공개했다.(영어)

AI 관련

Introducing Gemini 4 Carbon : Google에서 사이버 보안 역량과 장기 과제 수행 능력을 갖춘 최고 성능 모델인 Gemini 4 Carbon을 발표했다.(영어)
GPT-6.1 Terra 소개 : OpenAI가 빠르고 효율적인 모델인 GPT-6.1 Terra를 발표했다. GPT-5.6 Terra보다 크게 발전했고 비용도 50% 낮아졌다.(영어)
Introducing Muse Spark Open, The Most Capable US Open‑Weight Model to Date : Meta가 미국에서 공개된 오픈 웨이트 모델 중 가장 뛰어난 Muse Spark Open의 가중치를 공개했다. Muse Spark Open은 816B 파라미터에 42B 활성 파라미터와 1M 컨텍스트 윈도우를 갖춘 멀티모달 모델로, 장기간에 걸친 작업에서 탁월한 성능을 보여준다. 또한 Muse Spark Open은 최신 MLX 프레임워크로 Apple M5 Ultra Mac Studio 2대에서 실행되는 최초의 모델이다.(영어)
MiniMax M3.1 Flash: Redefining Agent Performance and Cost : Space Bunny라는 익명의 모델로 알려진 MiniMax의 M3.1 Flash가 공개되었다. M3.1 Flash는 온라인 추론 속도를 거의 3배 높이고 비용은 70% 싸졌다.(영어)
Introducing Kimi K3.1 Pro : Moonshot에서 가장 성능이 뛰어난 3T급 오픈 웨이트 모델인 Kimi K3.1 Pro와 속도가 2~3배 빠른 Kimi K3.1 Pro Highspeed를 출시했고 모델 가중치는 11월 4일에 발표할 예정이다. Kimi K3.1 Pro는 K3를 후처리 학습한 모델로, 이 과정에 훨씬 더 많은 자원을 투입해 성능을 높였다. 벤치마크 전반에서 가장 강력한 독점 모델들과 대등하거나 근접한 성능을 보여주었다.(영어)
DeepSeek-V4.1-Flash-1017 : DeepSeek-V4.1-Flash의 마이너 업데이트 버전으로 기존보다 성능이 상당히 향상되었다.(영어)
Mistral Large 4 (Le Chonk) is now open weight : 10월 초에 공개되었던 1조 개의 파라미터를 가진 멀티모달 모델인 Mistral Large 4(Le Chonk)의 가중치가 공개되었다.(영어)
Dessa - the Conversation Model trained only on speech : Block에서 음성만으로 학습시킨 음성 모델 Dessa를 만들었다. 녹음 파일을 들어보면 사람처럼 자연스럽게 대화하고 리액션하는 걸 볼 수 있다. 음성만으로 학습시켜서 텍스트보다 수백 배 적은 단어로 언어를 익혔다. 덕분에 NVIDIA GB200 NVL72 한 대로 학습할 수 있었고, MacBook Pro M4 Max에서 로컬로 실행할 수 있다.(영어)
Genie 4: A new generation of world simulation : Google이 새로운 월드 모델 Genie 4를 발표했다. Genie 4는 기존보다 훨씬 뛰어난 사실감으로 시뮬레이션을 한층 발전시켰고, 멀티모달 기능으로 오디오와 대화까지 담긴 세계를 동시에 생성할 수 있다.(영어)
Introducing Claude Duet : Anthropic이 능동적으로 일하는 에이전트인 Claude Duet을 리서치 프리뷰로 공개했다. iOS, Android 앱으로 사용할 수 있고 현재는 대기 신청을 하고 승인 받아야 사용할 수 있다.(영어)
We’re renaming our Max plans : Anthropic이 Claude Max 5x 플랜을 Max로 Max 20x 플랜을 Ultra로 이름을 변경했다.(영어)

인프라 관련

Ontology-Driven Observability: Building an End-to-End Knowledge Graph at Netflix Scale : Netflix는 장애의 원인을 찾을 때 Metrics, Events, Logs, Traces를 살펴보며 서로 간의 관계를 재구성하는 데 대부분의 시간을 썼다. 각 시스템은 자신의 정보만 알고 있으므로 온톨로지를 구축해 지식 그래프를 만들고 그래프 데이터베이스에 저장했다. 이제 쿼리로 한 번에 조회할 수 있다. 이는 이전에 사람이 하던 작업이지만 지식 그래프로 빠르게 할 수 있게 되었고 이를 통해 자동 근본 원인을 분석할 수 있게 되고 이를 통해 자동 복구도 할 수 있게 된다.(영어)
Rebuilding LinkedIn's Tracking Infrastructure: Scaling, Migrating, and Hardening a High-Volume Event Pipeline : LinkedIn에서 사용자의 상호작용 이벤트를 수집 추적하는 시스템은 하루 수천억건의 이벤트를 처리하고 있다. 이 시스템의 기술도 낙후되고 성능 개선을 위해서 병렬로 재구축을 했다. 새 시스템에서는 공유 컨텍스트를 사용해 이벤트를 재사용함으로써 네트워크 수신량을 1/10로 줄였다. 트래픽은 점진적으로 전환하면서 이벤트의 10%를 대조해보면서 전환했고 비용 이슈상 의도적으로 100%를 이중으로 전송하지는 않았다. 비교 절차와 롤백 방법을 검증한 뒤 대용량 이벤트를 먼저 전환해서 마이그레이션에 대한 정보를 얻을 수 있었다. protocol-buffer를 Apache Avro로 전환하고 zstd 압축을 사용해서 성능을 크게 높이고 실 데이터에서 병목 구간을 최적화했다.(영어)
Timestral: Mistral's time-series foundation models : Mistral에서 시계열 파운데이션 모델인 Timestral을 발표했다. 다른 시계열 모델보다 적은 2억 900만 개의 파라미터로 여러 시계열 분야의 벤치마크에서 1위를 차지했다.(영어)
언제 고장 났다고 말할 수 있을까? : 서비스가 정상인가를 판단하기 위해 FTA(Fault Tree Analysis)를 적용해서 메트릭이 아니라 무엇을 실패라고 부를지를 정의하고 그 실패가 발생할 수 있는 원인을 트리로 만들어서 SLI로 정리한다.(영어)
Inside Prometheus: Meta’s Journey to a Gigawatt-Scale Supercluster : Meta가 오하이오주 뉴올버니에 구축한 기가와트급 슈퍼클러스터 데이터센터 Prometheus의 내부를 소개했다. Prometheus의 1단계 구축은 이미 완료했고 GPU 100만개 규모로 확장하려고 준비하고 있다.(영어)

보안 및 장애

OpenCode Security Breach Exposes Third-Party API Keys of its Console Users : 코딩 에이전트 OpenCode의 Console 사용자 중 1.4%가 영향을 받은 보안 침해 사고가 발생했다. 이번 공격은 대규모 모델 증류 공격과 관련이 있고 워크스페이스에 저장된 서드파티 API가 노출되었을 수 있으므로 Anthropic, OpenAI, Google과 협력 중이라고 밝혔다. 사용자에게는 알림이 나갔으며, 알림을 받은 사용자에게 해당 키를 폐기하고 무단 사용 내역이 있는지 살펴보라고 권하고 있다.(영어)
PHP2Shell : PHP에서 메모리 부족으로 인한 손상(CVE-2026-109618)과 요청 사이에 전역 상태가 남아 있는 문제(CVE-2026-109619)로 원격 코드 실행(RCE)이 가능한 취약점이 발견되었다. WordPress, Drupal 등 PHP를 사용하는 서비스도 모두 영향 받으므로 패치 버전으로 즉시 업데이트해야 한다.(영어)
Node2Shell Brotli vuln (CVE-2026-111497) evolves to HTTP2Shell, as libraries and apps using HTTP are affected. : Brotli 압축 디코더에서 범위를 벗어난 쓰기 취약점이 발견되어 CVSS 점수 9.2를 받았으며, 치명적인 취약점으로 판정되었다. 이 취약점은 Node.js에서 발견되어 CVE-2026-111497로 분류되고 Node2Shell이라고 불렸다. 하지만 Brotli의 취약점이어서 Node.js뿐 아니라 Bun, Envoy, Istio, curl에도 영향을 준 것으로 밝혀졌다. OpenAI가 올해 2월 이 취약점을 발견해 Brotli에서 수정되었지만, 보안 문제로 인식되지 않아 지금까지 보안 릴리스가 나오지 않았다.(영어)
eMudhra Intermediate CA Compromise : 인도의 인증기관(CA, Certificate Authority)인 eMudhra의 중간 CA 인증서 8개의 프라이빗 키가 유출되었다. 이 인증서는 루트 인증서로 이어지기 때문에 Firefox, Chrome, Microsoft, Apple이 10월 17일부터 22일 사이에 이 인증서를 차단했다. eMudhra가 2025년 4월 중간 인증서를 생성하던 중 약한 키로 잘못 만들어서 누구나 해당 키를 복구할 수 있었다.(영어)
LiteLLM PyPI Package and Docker Images Compromised to Steal Cloud and AI Credentials : AI 게이트웨이인 LiteLLM 1.107.0에 자격 증명을 탈취하는 악성 코드가 포함되어 배포되었다. 이번 사고에는 LiteLLM 컨테이너 이미지에도 동일한 악성 코드가 포함되었고 이미지는 정상 저장소인 BerriAI/litellm이 아니라 Berri-AI/litellm에서 배포된 것으로 기록되었다. 이 악성 버전은 10월 21일 11:39:51 UTC에 게시되고 11:46:30 UTC에 악성 코드 경보가 발생했고 13:23 UTC까지 공개되어 있었다. Socket의 조사에 따르면 공격자는 이보다 빠른 10월 10일에 LiteLLM 저장소에서 공격을 위한 2개의 커밋을 통해 워크플로우를 실행한 것을 발견했다.(영어)
Tailscale SSH Flaws Could Let Hackers Gain Root Access Across Servers From One Compromised Device : Tailscale SSH 기능의 결함으로 공격자가 기기 한 대에 침투하면 다른 서버의 루트 권한까지 얻을 수 있는 취약점이 발견되었다.(영어)
Binance Hack: $6.3B Drained on 9 Chains, $2.7B Frozen : 지난 29일 Binance의 DevOps 엔지니어 노트북이 침해되었다. 공격자는 4시간 동안 Binance의 자체 출금 시스템에서 9개 체인에 걸쳐 핫월렛 17개에서 63억 달러(약 8조 원)를 탈취했다. 이 중 27억 달러는 동결되었고, 공격자는 여전히 31억 달러를 보유하고 있으며 대부분 ETH와 BTC다.(영어)
1Password for Agents: Secure AI Password Manager : 에이전트가 1Password에게 비밀번호 입력을 요청하면 1Password에서 승인 후 자동 입력하도록 해 에이전트가 직접 비밀번호를 보지 않아도 되게 하는 기능이 발표되었다. 현재는 대기 명단에 등록한 후 승인받아야 사용할 수 있다.(영어)

볼만한 링크

AI Isn't Replacing SREs. It's Deskilling Them. : “AI가 장애 대응의 95%를 맡게 되면 정작 중요한 5%를 처리하는 능력이 떨어질까?”라는 질문으로 시작하는 글이다. 장애에 대응하면서 기본적인 직관과 숙련도를 쌓아야 하는데, AI 자동화로 사람이 새로운 장애만 다루게 되면 그런 장애에 대응할 능력마저 점점 잃게 된다. 역량이 떨어질수록 AI에 더 의존하게 되어 악순환에 빠진다. 이를 위해 의도적인 비효율을 만들어야 하고 AI로 SRE의 역량을 끌어올려야 한다.(영어)
It's still OK to enjoy programming : 코드를 손으로 작성하는 방식의 경제성이 완전히 달라져서 인터넷에서 그 슬픔이 퍼져나가고 있다. 하지만 여전히 주말에 프로그래밍을 재밌게 하고 있고 직접 코드를 작성하면서 다른 주제로 빠져서 공부를 하기도 한다. 이제는 이런 일을 하면 안 되는 것 같은 분위기이지만, 계속 즐겨도 괜찮고 경제적인 정당성을 갖출 필요도 없다.(영어)
Anthropic, 상장 신청서(S-1) 전문 읽기 : Anthropic의 상장 신청서 S-1을 정리한 글이다. Nasdaq 티커는 ANT가 될 것이고 매출이 1년 만에 14배가 되어 26년 상반기 매출이 162억 9천만 달러였고 2분기에는 처음으로 영업이익을 냈다. 연간 10만 달러 이상 쓰는 고객은 11,900곳 이상이 되었고 순매출유지율은 약 900%다. 컴퓨팅 약정 비용은 조 단위로 보인다. 창업자 7명의 Class F 주식은 주식 수가 아무리 늘어도 총 의결권의 50.1%를 갖게 된다.(한국어)
Octoverse: Commits, pushes, reach new highs in 2026 as developers build with agents : GitHub이 매년 공개하는 Octoverse 보고서가 공개되었다. 지난 12개월 동안 푸시가 179억 번 발생해 2024년과 2025년을 합친 것보다 많았고, 커밋과 풀 리퀘스트도 2년 전보다 3배 이상 늘었다. 6월 이후 전체 커밋의 55%가 새로운 저장소에서 발생했고, 오픈소스 기여도 25억 건으로 작년의 2배를 넘어섰다. GitHub은 이제 2억 2,500만 명이 이용 중이다. 에이전트와 함께 작업한 풀 리퀘스트의 비율은 3월 17%에서 9월 40% 이상으로 늘었다. 가장 많이 사용하는 언어는 여전히 TypeScript, Python, JavaScript 순이다.(영어)
Introducing Geist Serif : Vercel에서 만든 개발자를 위한 고정폭 폰트 Geist 패밀리에 Geist Serif가 추가되었다.(영어)

IT 업계 뉴스

Meta ordered to pay $25 billion penalty in New Mexico Cambridge Analytica case : 10년전 케임브리지 애널리티카 스캔들에서 시작된 개인정보 보호 사건과 관련해서 미국 뉴멕시코 법원이 Meta에 250억 달러의 벌금을 부과했다. 배심원단은 Meta가 사용자 데이터를 수집하고 보호하는 방식을 안전한 것처럼 설명했지만 그렇지 않았고 혐오와 허위 정보에 대한 관리도 잘못 홍보했다고 벌금을 부과했다.(영어)
CSS-Tricks has a new owner! : 2022년 DigitalOcean이 CSS-Tricks를 사고 방치하고 있었는데 CSS-Tricks에서 12년간 글을 쓰고 편집해온 Geoff Graham이 다시 인수해서 독립적으로 운영할 수 있게 되었다. CSS-Tricks를 본업으로 운영하면서 광고, 스폰서십, 멤버십, 교육 콘텐츠로 유지비를 마련할 계획이라고 밝혔다.(영어)
Microsoft offers quarter of global workforce voluntary buyouts : Microsoft가 전 세계 직원의 27%인 6만 명에게 자발적 퇴직 보상을 제안했다.(영어)
DoorDash to Acquire Instacart to Help Local Stores Win : 배달 서비스인 DoorDash가 식료품 배달 서비스인 Instacart를 인수했다. Instacart의 22일 종가보다 26% 높은 주당 65달러로 평가해 약 170억 달러에 인수하기로 했다. 총 거래 대금의 최소 75%는 현금으로 지급될 예정이다.(영어)

프로젝트

tsc-ts : Vercel이 만든 TypeScript 컴파일러(TypeScript-Go, tsgo)의 실험적 TypeScript 포트.
scriptc : TypeScript와 JavaScript를 네이티브 실행 파일이나 WebAssembly로 컴파일하는 컴파일러.
Surflane : 플랫폼 개발을 위한 디자인 시스템.
Artemis : AI가 안드로이드 폰을 사용하거나 테스트 자동화를 할 수 있게 하는 Google의 프로젝트.
DeepInfer : DeepSeek이 내부에서 사용하던 추론 프레임워크를 공개했다. DeepInfer는 DeepSeek-V4.1-Flash 모델을 지원하고 최적화, 병렬화 등을 지원한다.
fx0 : Vercel에서 만든 libfx 기반의 디자인 에이전트.
Pele : Mermaid 다이어그램을 SVG로 만들어주는 라이브러리.
Nordwand Mono : 코딩용 네오그로테스트 폰트
Herdr UI : Herdr 데몬을 위한 클라이언트
agent-desktop : AI 에이전트가 컴퓨터를 사용할 수 있게 해주는 CLI 및 라이브러리로 Vercel이 만들었다.
Anthropic Sandbox Runtime (srt) : Anthropic이 OS 수준에서 임의의 프로세스에 파일 시스템과 네트워크를 제한하는 경량 샌드박스를 공개했다.(영어)

버전 업데이트

DuckDB v2.0.0 LTS "Cinnamon Teal" : 데이터베이스 시스템, 릴리스 공지
DocumentDB v1.0 : MongoDB 호환 오픈소스 데이터베이스, 릴리스 공지
Dagger v1.0 Beta : CI/CD Pipeline as Code, 릴리스 공지
Electron v45.0.0 : 크로스 플랫폼 데스크톱 애플리케이션 플랫폼, 릴리스 공지
OpenCode v2.0 : 코딩 에이전트, 릴리스 공지
Linux Kernel v7.3 : 리눅스 커널, 릴리스 공지
Node.js v26.13.0 'Lithium'(LTS) : 자바스크립트 런타임, 릴리스 공지
- 26.x가 LTS 단계에 들어갔다.
Node.js v27.0.0-alpha.0.0.0 (Alpha) : 자바스크립트 런타임, 릴리스 공지
Nx v24.0.0 : 모노레포 빌드 시스템, 릴리스 공지
React Native v0.88.0 : React를 이용한 모바일 앱 개발 프레임워크, 릴리스 공지
Expo SDK v58.0.0 : React로 네이티브 앱을 만드는 플랫폼 SDK, 릴리스 공지
Biome v2.6.0 : 프론트엔드 툴체인, 릴리스 공지
React Native Skia v3.8 : React Native용 Skia, 릴리스 공지
FastAPI v0.162.0 : Python 웹 프레임워크, 릴리스 공지
Grafana v13.3 : 메트릭 대시보드, 릴리스 공지
Ghostty v1.4.0 : 터미널 에뮬레이터, 릴리스 공지
Kafka v4.4.0 : 분산 이벤트 스트리밍 플랫폼, 릴리스 공지
GitButler v0.23.0 : Git 클라이언트, 릴리스 공지
Volcano v1.16.0 : 클라우드 네이티브 배치 스케줄링 시스템, 릴리스 공지

엔딩 이후의 DLC: 토론토에서 당근(Karrot)을 다시 소개하며

2026-11-01T09:00:00+09:00

토론토 할로윈 파티에서 당근(Karrot)을 설명하다 느낀 것. 13년 전 카카오 신입 시절처럼 다시 시작하지만, 이번엔 선배의 자리에서 캐나다에 Karrot을 알리고 싶어요.

Riftlancer: Privacy Policy

2026-10-31T09:00:00+09:00

Riftlancer does not collect anything. The game has no network permission, so it cannot send data anywhere: no account, no sign-in, no analytics, no crash reporting, no ads. Your high scores, stage grades, chosen ship and settings are stored on your device only, and removing the app removes them. We receive nothing about you or your play, and there is nothing for us to delete, sell or share.

Contact: lab.ashon.dev@gmail.com

Riftlancer는 아무것도 수집하지 않습니다. 이 게임에는 네트워크 권한이 없어서 데이터를 어딘가로 보낼 수 없습니다. 계정 없음, 로그인 없음, 분석 없음, 크래시 리포트 없음, 광고 없음. 최고 점수, 스테이지 등급, 고른 함선과 설정은 기기에만 저장되며 앱을 지우면 함께 사라집니다. 저희는 당신이나 당신의 플레이에 대해 아무것도 받지 않으며, 삭제할 것도, 판매할 것도, 공유할 것도 없습니다.

[SE-0553] Task Identity

2026-11-01T21:19:12+09:00

안녕하세요. 그린입니다
이번 포스팅에서는 SE-0553 — Task Identity에 대해 정리해보겠습니다

Intro

Proposal: SE-0553

Authors: Joakim Hassila, Konrad 'ktoso' Malawski

Review Manager: Joe Groff

Status: Accepted

Implementation: swiftlang/swift#89237

Summary of Changes

현재 실행 중인 Task에 대한 저렴하고, 안정적이고, 프로세스 내에서 유일한 식별자를 추가해요. Task.currentID와 Task, UnsafeCurrentTask의 인스턴스 접근자가 불투명한 Task.ID를 반환하는데, 비용이 thread-local 읽기와 비슷한 수준이라 트레이싱이나 구조화된 로깅 같은 상시 계측을 hot path에서도 쓸 수 있게 해줍니다.

이 식별자는 관찰 결과와 태스크별 상태를 태스크에 귀속시키기 위한 것이고, 제어 흐름을 컨트롤하기 위한 게 아닙니다

Motivation

Swift Concurrency는 현재 태스크를 들여다보는 withUnsafeCurrentTask, Task.currentPriority, Task.name 같은 API를 제공해요.

대부분의 앱 코드에는 충분하지만, 매 이벤트마다 실행되는 상시 계측 경로를 위해 설계된 API는 아니에요.

트레이싱이나 구조화된 로깅 라이브러리가 모든 이벤트에 "어느 태스크에서 발생했는지"를 붙이려면, 이 귀속 비용이 사실상 프리, 즉 수 나노초 수준이어야 해요.

사용자의 hot path에서 이벤트마다 실행되기 때문이에요. 지금 가장 가까운 방법은 withUnsafeCurrentTask에 숫자 식별을 뽑는 unsafeBitCast나 해시 가능한 값을 얻는 hashValue를 조합하는 건데, 제안서가 Apple Silicon(M 시리즈)에서 표준 라이브러리 opt 빌드로 측정한 바로는 런타임 진입점은 몇 나노초지만 이 방식은 약 15배 더 들어요.

벤치마크 설정과 방식별 수치는 pitch 스레드에 있어요.

클로저 형태의 API가 비싼 이유는 런타임 호출이 느려서가 아니에요.

제네릭 withUnsafeCurrentTask 진입점에서 클로저의 existential boxing, 동적 스택 할당, witness table 간접 참조, 타입 메타데이터 조회가 쌓이기 때문이에요.

참고로 이 제네릭 클로저 경로를 우회하는 자체 span 라이브러리는 같은 하드웨어에서 span 시작/종료 한 쌍을 약 25ns에 끝낼 수 있어서, 프로덕션에서도 계측을 켜둘 만하다고 해요.

저렴한 태스크 식별은 이걸 가능하게 하는 구성 요소 중 하나입니다.

런타임은 이미 필요한 식별자를 유지하고 있으니, 안정적인 API로 노출하면 계측 라이브러리가 내부 런타임 진입점에 기대지 않고도 이 성능에 도달할 수 있어요.

이런 요구는 트레이싱에만 국한되지 않아요.

실시간/지연에 민감한 시스템 — 트레이딩 인프라, 오디오 파이프라인, 게임 엔진처럼 프로덕션 계측이 기본으로 켜져 있어야 하고 프로파일에서 사실상 보이지 않아야 하는 곳
프로파일러와 개발자 도구 — 관찰 대상 프로그램에 측정 가능한 비용을 주지 않고 샘플이나 이벤트를 태스크에 귀속시키려는 경우
lock-free 자료구조 — 태스크별 상태를 키로 관리하는데, 런타임이 해제된 태스크의 힙 주소를 재사용할 수 있어서 포인터 동일성은 위험한 경우
커스텀 executor — 태스크별 회계처럼 태스크 식별자로 인덱싱한 side table이 필요한 경우
구조화된 로깅 — 모든 로그 줄에 원본 태스크 식별자를 메타데이터로 실어서, 여러 태스크가 한 스레드를 공유해도 나중에 태스크별 흐름을 복원할 수 있게 하는 경우

이 모든 경우의 요구는 같아요.

현재 태스크에 대한 안정적이고, 비교 가능하고, 해시 가능한 식별자를 한 자릿수 나노초 범위에서 얻는 것이에요.

Proposed Solution

Swift 런타임이 이미 유지하고 있는 프로세스 내 유일한 태스크 식별자를 Task의 공개 API로 노출해요.

// Constrained to Task<Never, Never> so callers can write `Task.currentID`
// without specifying generic arguments — matches the shape of Task.sleep.
extension Task where Success == Never, Failure == Never {
  /// The identifier of the currently executing task, or `nil` if no Swift
  /// `Task` is currently running on this thread.
  public static var currentID: Task.ID? { get }
}

결과 타입으로는 새 불투명 값 타입이 도입돼요.

최상위에 선언하고 Task의 typealias로 노출해서, Task.ID가 Task의 제네릭 인자에 따라 갈라지는 타입 가족이 아니라 하나의 표준 타입이 되게 했어요.

@frozen
public struct TaskID: Sendable, Hashable {
  public var rawValue: UInt64 { get }
}

extension Task {
  public typealias ID = TaskID
}

rawValue는 64비트 정수 표현이 필요한 곳, 즉 바이너리 와이어 포맷, 공유 메모리 영역, 비 Swift 소비자와의 브리지에서 직렬화를 위해 쓰는 문서화된 탈출구입니다.

이 타입에는 의도적으로 공개 이니셜라이저가 없어요.

이유는 Alternatives Considered에서 다뤄요.

같은 식별자를 들고 있는 Task 참조나 UnsafeCurrentTask에서도 읽을 수 있어요.

extension Task {
  public var id: Task.ID { get }
}

extension UnsafeCurrentTask {
  public var id: Task.ID { get }
}

Task.ID / task.id라는 이름은 Swift의 Identifiable 프로토콜 관례와 일부러 맞춘 거에요.

표준 라이브러리에서 식별자를 가진 타입에 대해 사용자가 이미 기대하는 이름과 같아져요.

hot path 계측은 이런 모습이 돼요.

@inline(__always)
func emit(_ event: Event) {
  let id = Task.currentID  // a few nanoseconds, no allocations
  buffer.append(event, taskID: id)
}

Detailed Design

Intended use and pitfalls

위 사용 사례들은 같은 모양이에요.

일이 일어나는 곳에서 식별자를 기록하고, 나중에 로그, 트레이스, 프로파일러 샘플, side table에서 찾아본다는 거죠. Task.ID는 관찰 결과와 태스크별 상태를 태스크에 귀속시키는 키이지, 어느 태스크가 실행 중인지에 따라 제어 흐름을 바꾸는 방법이 아니에요.

태스크 식별자로 분기하는 코드는 스레드 식별자로 분기하는 코드와 같은 의심을 받아야 해요.

특히 다음을 주의해야 해요.

태스크 구조는 계약이 아니에요. 어떤 API가 호출자가 준 클로저를 호출 태스크에서 돌리는지 자식 태스크에서 돌리는지는, 그 API가 문서화하지 않았다면 구현 세부사항이에요. 문서화 없이 Task.currentID를 알려진 task.id와 비교하면, 릴리스 사이에 바뀔 수 있는 구현의 우연을 관찰하는 셈이에요.
취소는 컨텍스트 안에서 관찰되지만, 식별자는 그렇지 않아요. 태스크 취소 방패(SE-0504) 안에서는, 바깥 스코프에서 취소된 태스크의 Task.isCancelled는 false를 보고하지만 그 태스크의 핸들에 대한 task.isCancelled는 true를 보고해요. Task.ID는 두 관찰이 같은 태스크에 대한 것임을 확인해줄 수 있어요. 그건 식별자가 제 역할을 하는 것이지, 의지하거나 우회해야 할 모순이 아니에요.
식별자는 핸들이 아니에요. Task.ID로는 태스크를 취소하거나 await하거나 접근할 수 없고, 부모/자식, 그룹, executor 관계도 담고 있지 않아요. 자식 태스크로 일을 따라가야 하는 값은 식별자 키 side table이 아니라 태스크 로컬(SE-0311)을 통해 자동으로 상속돼요.
side table은 소유자가 정리해야 해요. 식별자는 재사용되지 않으므로 오래된 항목이 이후 태스크에 의해 회수되지 않아요. Task.ID를 키로 쓰는 테이블(예: 커스텀 executor의 태스크별 회계)은 소유자가 항목을 비우지 않으면 끝없이 커져요.

태스크 식별은 이미 디버거, Instruments, swift-inspect, 또는 UnsafeCurrentTask의 포인터 동일성으로도 관찰할 수 있어요.

이 제안은 그걸 필요한 계측에 맞게 저렴하고 안정적으로 만들 뿐이고, 런타임 동작으로 가는 우회 채널로 쓰는 건 권장하지 않아요.

Task.ID

Task.ID는 런타임이 만든 64비트 부호 없는 정수를 감싼 불투명 값 타입이에요.

기반 정수는 직렬화를 위해 rawValue로 꺼낼 수 있고, 공개 이니셜라이저는 없어요.

@frozen
public struct TaskID: Sendable, Hashable {
  public var rawValue: UInt64 { get }
}

extension Task {
  public typealias ID = TaskID
}

이 구조체를 Task 안에 중첩하지 않고 최상위에 선언한 이유가 있어요.

Task는 Success, Failure에 대해 제네릭이라, 직접 중첩한 Task.ID는 Task<Success, Failure>.ID, 즉 인스턴스화마다 별개의 타입이 되어버려요.

단일 표준 식별자 타입에는 맞지 않는 모델이죠.

typealias는 사용자에게는 Task.ID 표기를 주면서 기반 타입은 하나로 유지해줘요.

이 구조의 결과로 Task.ID와 기반 TaskID는 같은 타입으로 해석되고 호출 지점에서 둘 다 쓸 수 있어요. Task.ID가 표준이고 문서화된 표기라서 이쪽을 선호해야 하고, TaskID는 Swift의 이름 해석이 제네릭 enclosing 타입 안에 비제네릭 타입을 공개적으로 중첩하는 걸 지원하지 않기 때문에 존재하는 비매개변수 기반 타입이에요.

이 타입은 두 가지 사용 형태를 위한 거예요.

프로세스 내 소비자는 태스크 식별자로 키를 잡은 딕셔너리, 살아 있는 태스크의 집합, 모듈 경계를 넘어 식별자를 나르는 타입 있는 API 파라미터처럼 Task.ID를 직접 다루고 기반 정수를 건드릴 일이 없어요.

와이어 포맷과 다른 언어 소비자는 rawValue를 꺼내 안정적인 64비트 정수를 전송해요.

API는 두 경우 모두 편하도록 만들어졌어요.

rawValue는 래퍼에서 나오는 유일하게 지원되는 탈출구예요.

와이어 포맷 작성자는 생산자 쪽에서 rawValue를 내보내고, 소비자 쪽에서는 그 값을 불투명한 정수로 취급해요.

소비자는 보통 로그를 남기거나, 키로 쓰거나, 다른 데이터와 조인하기 위해 Task.ID 인스턴스를 복원할 필요가 없어요.

직렬화된 값은 관찰 결과(로그, 트레이스, 다른 데이터와의 조인)를 내보내기 위한 것이지, 다른 프로세스에서 태스크 동일성을 단언하기 위한 게 아니에요.

다른 프로세스에서 그 값은 64비트 정수라는 것 외에는 의미 보장이 없어요. MemoryLayout<Task.ID>.size는 @frozen으로 고정된 컴파일 타임 상수 8이에요.

Codable, Encodable, Decodable 채택은 제안하지 않아요.

문서화된 직렬화 경로는 호출자가 쓰는 스키마에 rawValue를 직접 인코딩하는 거예요. 채택을 넣으면 스키마 설계가 정해야 할 인코딩 표현을 표준 라이브러리가 대신 고르게 되거나, rawValue가 이미 제공하는 걸 중복하게 돼요. 사용 사례가 생기면 별도 제안에서 고려할 수 있어요.

식별자는 다음 의미를 보장해요.

프로세스 내 유일: 같은 프로세스에서 살아 있는 두 태스크는 항상 서로 다른 식별자를 가져요.
재사용되지 않음: 한 번 부여된 식별자는 원래 태스크가 소멸된 뒤에도 다른 태스크에 다시 부여되지 않아요. 오래 사는 side table의 키로 안전하게 만드는 속성이고, 포인터 동일성이 주는 것보다 강한 보장이에요.
태스크 수명 동안 안정: 태스크 생성 시점에 정해지고 바뀌지 않아요.
프로세스 간에는 안정적이지 않음: 식별자는 프로세스 로컬이라, 프로세스 간에 의미가 있을 거라 기대하며 저장하거나 전송하면 안 돼요.

런타임은 현재 식별자를 단조 증가로 할당하지만, 이건 구현 속성이지 계약의 일부가 아니에요.

Task.ID는 Comparable을 채택하지 않아요.

rawValue는 직렬화를 위해 노출된 것이지 순서 추론을 위한 게 아니에요.

위 보장이 유지되는 한, 미래 런타임은 카운터를 샤딩하거나, 시작 시점 nonce를 섞거나, 할당 방식을 바꿔도 소스를 깨지 않아요.

카운터 공간 고갈(한 프로세스에서 2⁶⁴번의 식별자 할당)은 명세된 동작이 아니에요.

64비트 공간은 현실적인 프로세스 수명 안에서 도달할 수 없을 만큼 커서(초당 10억 번 태스크를 할당해도 한 바퀴 도는 데 약 584년), 제안은 특정 결과를 강제하지 않아요.

Task.currentID

extension Task where Success == Never, Failure == Never {
  public static var currentID: Task.ID? { get }
}

이 제약은 오늘날 Task.sleep 같은 static 멤버가 선언되는 방식을 따라요.

static 접근자는 Success, Failure에 의존하지 않으므로, 표준 Task<Never, Never> 네임스페이스에 묶으면 호출자가 제네릭 인자를 지정하지 않고도 Task.currentID라고 쓸 수 있어요.

이 스레드에서 현재 실행 중인 태스크의 식별자를 반환하고, 현재 실행 중인 Swift Task가 없으면 nil을 반환해요(예: 동시성 런타임 밖에서 시작한 동기 컨텍스트에서 호출한 경우).

이 접근자가 성능이 가장 중요한 진입점이에요.

설계 목표는 thread-local 읽기에 견줄 만한 한 자릿수 나노초이고, 할당은 없어요.

Instance accessors

extension Task {
  public var id: Task.ID { get }
}

extension UnsafeCurrentTask {
  public var id: Task.ID { get }
}

Task.id는 태스크가 끝난 뒤에도 항상 안전하게 호출할 수 있어요.

식별자는 태스크 생성 시점에 고정되어 이후 바뀌지 않으므로 동기화가 필요 없어요.

UnsafeCurrentTask.id는 UnsafeCurrentTask의 다른 모든 프로퍼티와 같은 안전 계약을 가져요.

unsafe 태스크 참조는 태스크를 살려두지 않으므로, 해제된 태스크에서 읽는 건 정의되지 않은 동작이에요.

다만 반환값이 trivial 값 타입이라, withUnsafeCurrentTask 클로저 안에서 식별자를 읽어두면 클로저가 끝난 뒤에도 그 값을 계속 쓸 수 있어요.

Performance contract

런타임은 이미 모든 태스크에 대해 64비트 식별자를 유지하고 있어서, 구현은 그 필드를 호출자가 믿을 수 있는 비용으로 안정적인 API를 통해 노출하는 문제예요.

이 제안이 구현에 요구하는 계약은 아래와 같아요.

Task.currentID의 평상시 비용은 최신 Apple Silicon에서 한 자릿수 나노초이고, 다른 최신 64비트 하드웨어에서도 비슷해야 해요. thread-local 읽기보다 비싸면 안 돼요.
할당이 없고, 일반 경로에서 동적 디스패치도 없으며, 기반 런타임 읽기가 이미 요구하는 것 이상의 동기화도 없어요.
Task와 UnsafeCurrentTask의 인스턴스 접근자도 같은 비용 특성을 제공해요.
Task.ID의 합성된 Equatable, Hashable 연산은 구체 타입 호출 지점에서 UInt64 대응 연산과 같은 명령어 시퀀스로 컴파일돼요.

구체적인 인라이닝 전략, ABI 심볼 모양, back-deployment 하한은 구현 리뷰에서 다룰 문제입니다.

Task.ID는 레이아웃을 고정하기 위해 @frozen이에요.

이건 인라이닝 힌트가 아니라 API 계약의 일부예요.

rawValue 접근자와 MemoryLayout<Task.ID>.size == 8 보장이 둘 다 여기에 의존해요.

64비트 폭도 rawValue를 통해 계약의 일부예요.

다만 그 비트의 내부 해석(예: (generation, slot) 쌍으로 나누거나 프로세스 시작 nonce를 섞는 것)은, 프로세스 내 유일하고 재사용되지 않는다는 의미 보장이 유지되는 한 구현이 자유롭게 정할 수 있어요.

Interaction with task names

Task.name(SE-0469)은 태스크 생성 시점에 부여하는 사람이 읽는 레이블이에요.

이 제안의 식별자는 그와 상호 보완적이에요. 작고, 저렴하고, 항상 존재하고, 프로세스 내에서 유일하죠.

계측 시스템은 식별자를 조인 키(로그, 테이블, side 자료구조)로 쓰고, 사람이 보도록 렌더링할 때만 이름을 만들어 쓰기를 기대해요.

OS 스레드가 숫자 tid와 선택적인 pthread 이름을 둘 다 갖는 것과 같아요.

Future Directions

Comparable 채택

Task.ID 항목에서 말했듯이 순서는 API 계약의 일부가 아니라서 Comparable을 채택하지 않아요. 사용 사례가 생기면 별도 제안에서 고려할 수 있어요.

프로세스 간 상관관계

프로세스나 호스트 경계를 넘는 분산 트레이싱에는 이 제안의 식별자로는 의도적으로 충분하지 않아요.

프로세스 로컬이기 때문이에요.

프로세스 간 상관관계는 자체적으로 전역 유일 식별자를 만드는 swift-distributed-tracing 같은 라이브러리의 영역으로 남아요.

Conclusion

그동안 태스크를 식별하려면 withUnsafeCurrentTask를 거쳐야 해서 상시 계측에는 비용이 너무 컸고, 포인터를 키로 쓰면 주소 재사용 때문에 위험했어요.

Task.currentID는 런타임이 이미 갖고 있는 "재사용되지 않는 64비트 식별자"를 thread-local 읽기 수준의 비용으로 꺼내 쓰게 해주는 작은 API예요.

다만 식별자는 제어 흐름용이 아니라 관찰과 귀속을 위한 키라는 점을 제안서가 분명히 강조하고 있는 것도 인상적이었습니다

References

swift-evolution/proposals/0553-task-identity.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

Blog: [메모] adb install vs android install 차이점 분석 및 비교

2026-11-01T18:00:00+09:00

두 도구의 내부 동작 차이를 분석하고, 로컬 에뮬레이터와 네트워크 대역폭 제한 환경에서 설치 속도를 비교했습니다.

본 글은 Gemini를 사용하여 초안을 작성한 후 검수하였습니다.

본 글에서 사용된 도구 버전 및 환경(2026년 10월 31일 기준)은 다음과 같습니다.

Android CLI: 1.1.16717390
Android Debug Bridge (adb): 1.0.41 (platform-tools 37.0.1-15733141)
Android Gradle Plugin (AGP): 9.5.0
Kotlin: 2.4.21
Target Device: Android Virtual Device (Pixel 9a, API 37, arm64-v8a)

1. 핵심 차이점 한눈에 보기

비교 항목	adb install	android install
도구 성격	Low-level 범용 기기 통신 도구 (`platform-tools`)	High-level Android 개발자/에이전트 워크플로 CLI
입력 형태	로컬 APK 파일 경로만 지원	로컬 APK 경로뿐만 아니라 빌드 참조 ([system://][path]?[target]) 지원
빌드 연동	불가 (사전에 빌드 완료된 APK 필요)	소스 빌드와 배포를 한 번에 연동 가능 (– )
증분 설치 (Delta)	`--fastdeploy` 옵션 필요 (별도 agent)	`--use-delta-install` 기본 활성화 (default: true)
전송 최적화	Streaming Install 지원 (`--streaming`)	변경된 delta 패치 파일만 기기로 전송 (Zero-copy 활용)
다중 APK 지원	install-multiple, install-multi-package 분리	–apks=a.apk,b.apk 로 단순화
실행 연계	설치만 수행	설치만 수행 (`android run` 시 설치 후 launch까지 연동)

(1) 소스 빌드 참조(Build Reference) 지원

# 로컬 APK 파일 설치
android install --apks=app/build/outputs/apk/debug/app-debug.apk

# Gradle 프로젝트 빌드 후 설치까지 한 번에 수행
android install :app
android install ~/MyProject?:app@debug -- --offline

빌드 타깃을 지정하면 CLI가 프로젝트 구조를 분석해 빌드를 실행하고, 생성된 APK를 찾아 기기에 바로 설치합니다.

(2) 기본 Delta Install (증분 패치) 지원

android install은 증분 설치 옵션(--use-delta-install)을 기본값(true)으로 사용합니다.

기기에 이전 버전의 앱이 이미 설치되어 있다면, APK 전체를 보내지 않고 로컬 APK와 기기 설치본의 차이(Delta)만 계산해 패치 파일(.seq)을 전송합니다.

기기의 임시 디렉터리(/data/local/tmp)에 배포 에이전트(installer.jar)를 올려 커널의 Zero-copy 시스템 콜로 패치를 적용한 뒤 Package Manager에 반영합니다.

2. 벤치마크 환경 구성

두 도구의 설치 소요 시간과 Delta Install의 데이터 전송 절감량을 확인하기 위해 아래 시나리오별로 테스트를 진행했습니다.

테스트 시나리오

APK 내 특정 영역만 변경되는 상황을 시뮬레이션하기 위해 4종류의 APK 변형(Variant)을 생성했습니다.

fresh: 앱을 완전히 삭제(uninstall)한 상태에서 최초 설치
same: 동일한 APK를 덮어쓰기 재설치
code: Kotlin 코드 상수만 변경 (classes*.dex만 변경)
res: 문자열 리소스만 변경 (resources.arsc만 변경)
asset: 에셋 파일 1개만 변경 (assets/marker.txt만 변경)

또한 APK 크기에 따른 전송 대역폭 영향을 보기 위해 두 가지 크기로 측정했습니다.

기본 Compose 앱: 약 11~12MB
대용량 리소스 포함 앱: 약 52MB (비압축 40MB 더미 페이로드 포함)

3. 결과 비교

1) 로컬 에뮬레이터 환경

로컬 에뮬레이터는 호스트 메모리 버퍼를 통해 데이터를 전달하므로 네트워크 전송 병목이 없습니다. 5회 반복 측정 후 중앙값 기준입니다.

① 기본 Compose 앱 (약 11~12MB)

시나리오	adb install -r	android install (기본 delta)	android install (delta OFF)
fresh	0.26s	1.17s	1.13s
same	0.32s	1.01s	1.03s
code	0.32s	1.01s	1.07s
res	0.36s	1.04s	1.05s
asset	0.33s	1.06s	1.03s

② 52MB 앱 (대용량 에셋 포함)

시나리오	adb install -r	android install (기본 delta)	android install (delta OFF)
fresh	0.46s	1.50s	1.22s
same	0.57s	1.54s	1.30s
code	0.52s	1.47s	1.24s
res	0.48s	1.42s	1.28s
asset	0.52s	1.38s	1.28s

결과 분석

로컬 에뮬레이터에서는 adb install -r이 더 빠릅니다.

Android CLI 자체를 기동하는 데 약 0.45초의 기본 오버헤드가 발생합니다.
전송 지연이 없는 환경에서는 50MB 전체를 전송하더라도 0.5초 안에 끝나므로, 차이점(Delta)을 계산하고 기기에서 패치 에이전트를 구동하는 시간이 전송 절약 시간보다 더 깁니다.

2) 실기기 / Wi-Fi 디버깅 환경 (5 MB/s 대역폭 제한)

※ 배수 비교는 adb install -r 대비 android install의 소요 시간 기준이며, 절감율은 전체 APK 크기 대비 실제 전송된 패치 크기 기준입니다.

① 52MB 앱 (대역폭 5 MB/s)

시나리오	adb install -r	android install (Delta ON)	절감율 / 전송량
fresh	10.41s	11.63s	전체 전송 (51.80 MB)
same	10.44s	1.52s (adb 대비 약 6.8배 빠름)	554 KB 전송 (98.9% 절감)
code	10.44s	1.45s (adb 대비 약 7.2배 빠름)	584 KB 전송 (98.9% 절감)
res	10.53s	1.68s (adb 대비 약 6.3배 빠름)	1.46 MB 전송 (97.2% 절감)
asset	10.52s	1.63s (adb 대비 약 6.4배 빠름)	1.46 MB 전송 (97.2% 절감)

② 11~12MB 기본 앱 (대역폭 5 MB/s)

시나리오	adb install -r	android install (Delta ON)	절감율 / 전송량
fresh	2.30s	3.48s	전체 전송 (11.33 MB)
same	2.31s	1.28s (adb 대비 약 1.8배 빠름)	89 KB 전송 (99.2% 절감)
code	2.32s	1.29s (adb 대비 약 1.8배 빠름)	140 KB 전송 (98.8% 절감)
res	2.40s	1.54s (adb 대비 약 1.6배 빠름)	1.02 MB 전송 (91.4% 절감)
asset	2.40s	1.49s (adb 대비 약 1.6배 빠름)	1.02 MB 전송 (91.4% 절감)

결과 분석

전송 속도가 제한되는 네트워크나 USB 환경에서는 android install이 훨씬 빠릅니다.

adb install -r은 변경된 내용이 적더라도 52MB 전체를 스트리밍 전송하므로 매번 10초 이상(10.44s~10.53s) 걸립니다.
반면 android install은 584KB 패치 파일만 전송(전송량 98.9% 절감)하므로 전송 시간을 0.1초대로 줄여 전체 설치를 1.45초(약 7.2배 빠름)에 마칩니다.

4. “adb –fastdeploy”와의 차이

adb install에도 --fastdeploy 옵션이 있지만, 아래 경고를 출력하며 일반 전체 설치로 전환될 수도 있습니다.

Fast Deploy is only compatible with devices of API version 24 or higher, ignoring.

반면 android install의 Delta Install은 Android Studio 배포 시스템(Deployer)의 기술을 CLI에 적용해 최신 OS에서도 정상적으로 패치 설치를 수행합니다.

5. 요약 및 상황별 추천

android install을 써야 하는 경우
- 실기기 디버깅(특히 Wi-Fi 무선 디버깅): 코드나 리소스 일부만 수정하고 재설치할 때 전송 시간이 대폭 줄어듭니다.
- 대용량 프로젝트: APK 크기가 클수록 Delta 패치 전송의 절약 효과가 큽니다.
- 빌드와 배포 연동: :app 같은 타깃 참조를 넘겨 빌드와 설치를 명령어 하나로 실행할 때 적합합니다.
adb install을 써야 하는 경우
- 로컬 에뮬레이터 반복 테스트: 전송 병목이 없어 CLI 기동 오버헤드가 없는 adb가 0.2초대로 가장 빠릅니다.
- 가벼운 CI/CD 파이프라인: 별도의 Android CLI 스택 없이 platform-tools만 설치된 환경에서 배포할 때 유리합니다.
- 세부 설치 옵션 제어: --instant, --abi, 다중 패키지 원자적 설치 등 저수준 Package Manager 옵션이 필요할 때 사용합니다.

Blog: [요약] The latest in Android dev tools (Android Dev Summit '26)

2026-10-31T21:00:00+09:00

기존 안드로이드 CLI 도구는 사용자 대화형 입력(Interactive Prompt)을 요구해 AI 에이전트가 자동으로 처리하기 어려웠습니다.

본 글은 Gemini를 사용하여 초안을 작성한 후 검수하였습니다.

개요: AI 코딩 에이전트 시대의 안드로이드 개발 도구

핵심 구성 요소

Android CLI: 터미널 스크립트, CI, 에이전트 앱, Android Studio 전체를 관통하는 단일 엔트리 포인트 도구
Agent Applications: Google Antigravity, Claude Code, OpenAI Codex 등과의 딥 인테그레이션(공식 플러그인 & Sidecar)
Android Studio Rabbit 2/3: ACP(Agent Client Protocol) 기반 BYOA(Bring Your Own Agent) 및 AI Change Review

데모 전반에는 40개 모듈로 구성된 대규모 오픈소스 오디오/비디오 팟캐스트 앱인 Pocket Casts가 사용되었습니다.

1. Android CLI

Android CLI는 AI 에이전트가 안드로이드 도구를 실행할 때 생기는 파싱 오류와 불필요한 대기를 없애도록 만들었습니다.

예측 가능한 명령어 체계 (Predictable commands)
JSON 등 기계가 읽기 쉬운 구조화된 출력 (Structured outputs)
추가 입력 프롬프트 없이 즉시 끝나는 비대화형 실행 (Zero interactive prompts)

주요 신규 명령어 (`android --ads`)

명령어	주요 기능 및 특징
signals	Crashlytics의 크래시 목록 및 현장 텔레메트리 데이터를 조회
device	연결된 기기/에뮬레이터 미러링(device hub) 및 원격 물리 기기 대여(Reservation) 관리
profiler	앱, 게임, 디바이스의 시스템 트레이스(Perfetto) 및 힙 덤프 수집
build	Gradle 등의 빌드 아티팩트를 CLI에서 직접 빌드
preview	Android Studio나 실제 기기 없이 터미널에서 Jetpack Compose @Preview를 PNG 및 JSON 컴포넌트 트리로 렌더링
install	변경된 바이트만 전송하는 델타 푸시(Delta push) 배포 (기존 ADB 대비 대폭 시간 절약)
input	복잡한 좌표 계산 대신 시맨틱 UI 요소를 대상으로 제스처 및 키 이벤트 전송
analyze	AAB/APK의 R8 설정, 난독화 비율, DEX 크기 및 리소스 분석
docs	공식 안드로이드 지식 베이스(KB)에서 최신 가이드 문서를 온디맨드로 로컬 검색 및 fetch
auth	안드로이드 CLI 도구용 Google 서비스 인증 로그인/로그아웃

2. 터미널 환경의 에이전트 자동화 데모 (Claude Code)

(1) 프로덕션 크래시 재현 및 핫픽스

Firebase Crashlytics에 보고된 실제 크래시를 에이전트가 탐색, 재현, 코드 수정, 배포 및 검증까지 단 1분 42초 만에 수정했습니다.

데모

크래시 탐색: android signals 명령어로 지난 30일간 사용자 발생 수가 가장 높은 크래시를 조회
- 원인: 비밀번호 재설정(“I forgot my password”) 버튼을 연속 두 번 탭하면 네비게이션이 중복 실행되어 IllegalArgumentException이 발생
  
  IllegalArgumentException: Navigation action … cannot be found from the current destination
기기에서 재현: android layout으로 버튼 좌표를 확인한 뒤 android input tap으로 버튼을 두 번 탭해 실제 기기에서 크래시 발생
코드 수정: 중복 화면 이동을 막도록 SignInFragment.kt와 PromoCodeFragment.kt의 네비게이션 로직에 currentDestination 확인 가드를 추가
고속 재배포: android build로 빌드한 뒤 android install을 실행해 전체 84MB APK 대신 3.84MB 델타 패치만 기기로 전송
검증: 기기에서 다시 더블 탭을 실행해 크래시 로그가 남지 않고(0 lines) 화면이 정상 유지됨을 확인

사용된 Android CLI commands

android signals crashes list --firebase-app ... --sort-by=users --timeframe=30d
- 최근 30일간 사용자 수 기준 상위 크래시 이슈 랭킹 조회
android signals crashes describe <issue> --timeframe=30d
- 해당 크래시의 상세 스택 트레이스 및 디바이스/안드로이드 OS 버전별 분포 확인
android layout --device=... --flat
- 수정 전/후 비밀번호 재설정 버튼의 좌표를 파악하기 위한 UI 레이아웃 트리 조회
android input tap --device=... "id:btnSignIn"
- 구버전 로그인 화면으로 진입하기 위한 시맨틱 탭 전송 (2회 실행)
android build "gradle://?:app:assembleDebugProd"
- 수정된 코드의 빌드 산출물 생성
android install --device=...
- 초기 수정 전 빌드 설치, 핫픽스 빌드 델타 패치 주입 (84MB 중 3.84MB만 전송)
  (참고: CLI가 지원하지 않는 화면 회전 고정, 딥링크 호출, 백키 입력, 더블탭 등 일부 작업에는 adb를 보조로 사용)

(2) APK 최적화: R8 Configuration Analyzer

Release Bundle이 너무 크다는 요청에 대해 에이전트가 ProGuard/R8 룰을 분석하고 불필요한 keep 룰을 제거했습니다.

데모

원인 파악: Protocol Buffers keep 룰이 지나치게 포괄적이어서 불필요한 클래스까지 난독화 대상에서 제외되고 있었습니다.
- 수정 전 : -keep class * extends com.google.protobuf.GeneratedMessageLite { *; }
- 수정 후 : -keepclassmembers class * extends com.google.protobuf.GeneratedMessageLite { ; }
클래스 전체를 유지하지 않고, 실제 사용하는 필드 멤버와 Retrofit 반환 타입으로 호출되는 API 메시지만 유지(keep)하도록 수정

개선 결과:

비압축 DEX 크기: 19,485,804 B → 18,957,388 B (-528 KB, -2.7%)
APK 압축 크기: 42,311,672 B → 42,147,832 B (-164 KB)
Keep된 메서드 수: 17,940개 → 11,757개 (-6,183개 제거, -34%)
Keep된 필드 수: 7,944개 → 7,209개 (-735개 감소)
Keep된 클래스 수: 2,342개 → 2,268개 (-74개 감소)
DEX 난독화 비율: 92.72% → 93.06% (+0.34%p)

사용된 Android CLI commands

android analyze ./before/app-release.apk
- 수정 전 베이스라인 APK의 DEX 크기, R8 설정 및 난독화 비율(Obfuscation ratio) 측정
android analyze ./after/app-release.apk
- 룰 수정 후 생성된 APK의 수치를 동일하게 추출하여 개선 지표 비교
  (참고: CLI에 Configuration Analyzer 출력 파싱 명령어가 없어 상위 룰 랭킹에는 보조 스크립트 활용)

(3) 앱 시작 시간(Startup Time) 최적화: Baseline Profile & Profiler

앱 시작 성능 개선 요청 시 에이전트가 공식 문서를 읽고 프로파일러를 통한 측정을 수행했습니다.

데모

원인 분석: 출시 버전 프로토타입 APK의 baseline.prof가 약 8KB에 불과하며, 포함된 6,690개 룰 중 Pocket Casts 자체 코드 룰이 0개(전체 프로필 로드 룰 중에서도 단 66개)여서 시작 코드가 JIT/인터프리터로 구동되고 있음을 확인
최적화 수행: 공식 문서를 읽어 무루팅 환경(Android 14+)에서 베이스라인 프로필을 수집 및 생성하는 절차를 확인하고, 콜드 스타트 프로필 룰(Pocket Casts 룰 2,621개 포함)을 갱신

사용된 Android CLI commands

android profiler systemtrace start --launch --duration=8
- 앱 콜드 런치(Cold start) 시점의 시스템 트레이스를 Perfetto 형식(*.pftrace)으로 수집 (수집된 트레이스는 ui.perfetto.dev에서 분석)
android docs fetch kb://android/topic/performance/baselineprofiles/manually-create-measure
- Android 14+ 기기에서 루팅 없이 Baseline Profile을 수동 생성하고 측정하는 최신 공식 기술 가이드라인 로컬 fetch 및 학습

개선 수치 (Pixel 6 Pro 기준):

Main-thread CPU 시간: 297.7ms → 244.7ms (-17.8%)
Total app CPU 시간: 809.3ms → 600.4ms (-25.8%)
JIT thread CPU 시간: 56.3ms → 15.6ms (-72.2%)
Time to initial display (TTID): 463.2ms → 383.4ms (-17.2% 단축)

3. Linux 데스크탑에서 Android 앱 네이티브 실행 (실험적 프로토타입)

초경량 구조: 단일 프로세스로 실행되며 stdout/stdin으로 로그가 직접 출력됨
클라우드 에이전트 환경 최적화: 중첩 가상화를 지원하지 않는 클라우드 VM이나 CI 컨테이너에서도 에이전트가 앱을 직접 실행하고 테스트 가능
높은 완성도:
- 순수 Compose 앱 실행
- 네트워크 통신이 포함된 Google 레퍼런스 앱 실행
- 네이티브 .so 라이브러리 변환 계층을 통해 C++ 라이브러리와 오디오 출력이 포함된 실제 Pocket Casts 앱 구동
- 데스크톱 변환 계층을 통한 OpenGL ES 1 네이티브 게임 앱 렌더링

4. AI 에이전트를 위한 공식 Android 플러그인

Google Antigravity, Claude Code, OpenAI Codex를 위한 공식 Android 플러그인이 배포되었습니다.

Google Antigravity

(1) Android Compose Preview

전체 앱 컴파일 및 기기 배포를 반복하지 않고, Sidecar 창에서 프리뷰 렌더링을 즉시 갱신
대화면에서 1열 스크롤 대신 헤더와 에피소드 목록을 좌우로 나누는 듀얼 창(Dual-pane) 레이아웃을 제안

(2) Android Device Hub

Antigravity 내에서 가상 기기(AVD) 및 물리 기기를 통합 관리하고 화면을 직접 미러링할 수 있습니다.

Pixel 10 Pro Fold 등 실제 연결된 기기 목록과 가상 기기(AI Glasses, Medium Phone, Small Phone 등)를 Sidecar 패널에서 통합 관리
미러링된 기기 화면을 보며 실시간 터치와 제스처로 상호작용 가능

화면 분할(Split Screen) 전환 시 앱이 싱글 페인(Single-pane)과 듀얼 페인(Dual-pane) 사이를 적응형(Adaptive)으로 올바르게 전환하는지 실시간 검증

Android CLI 연동에 따른 에이전트 효율성 벤치마크

Claude Opus를 대상으로 6개 사용자 Journeys 및 6개 디바이스에서 메모리 누수를 찾고 수정하는 과제를 Android CLI 사용 여부에 따라 A/B 테스트한 결과입니다.

작업 완료 속도: 1.9배 향상 (88분 → 46분, 42분 단축)
토큰 사용량: 1.3배 절감 (4.6M 토큰 → 3.5M 토큰)
Compose Preview: 전통적인 컴파일/실행 반복 대비 반복 시간 77% 단축
Analyze 명령어: 다중 왕복 검사를 단일 구조화 명령어로 대체하여 출력 토큰 5.5배 절감
Semantic Input: 화면 좌표 추정 환각(Hallucination)을 없애 작업 실행 속도 25% 향상

5. Android Studio와 AI 에이전트의 진화

(1) Bring Your Own Agent (BYOA) via Agent Client Protocol (ACP)

Android Studio는 내장 Gemini 외에도, 개발자와 팀이 이미 사용 및 구독 중인 외부 에이전트를 IDE로 가져올 수 있는 BYOA 기능을 도입했습니다.

경로: Settings > Tools > AI > Agents
Agent Client Protocol (ACP) 기반으로 다양한 에이전트 연결 지원:
- Built-in Agent v2.0
- Google Antigravity
- Claude Agent (Claude Code / Anthropic API 연동)
- OpenAI Codex
- JetBrains Junie
- ACP Agent Marketplace
기존 개인 구독이나 기업용 계정을 그대로 활용 가능

(2) AI Change Review

대량의 코드를 검토할 때 버그를 사전에 잡을 수 있도록 지원하는 코드 리뷰 기능입니다. 로컬 변경점뿐만 아니라 PR도 분석합니다.

15개 파일, 800줄의 PR 변경점을 분석해 잠재적 버그를 사전에 감지
데모에서 발견된 실제 이슈:
- 북마크 스와이프 행 컴포저블(SwipeRow.kt)에서 LaunchedEffect 키가 람다 객체로 설정되어 있어, 행이 Recomposition될 때마다 풀 스와이프 동작이 중복 실행되는 버그
- 삭제 다이얼로그가 뜬 상태에서 북마크 삭제 확인 다이얼로그가 계속 중복 노출되는 문제
해결책 제시 및 일괄 반영: 원인을 설명하고 rememberUpdatedState를 적용한 코드 diff를 제공합니다. 체크박스로 선택한 이슈를 버튼 한 번으로 일괄 수정(Fix all selected issues) 가능
주제별 워크스루(Walkthrough): PR 내 변경 사항을 기능 단위로 묶어 코드 변경 내역을 확인하고 승인 가능

(3) Android Studio Rabbit 릴리스 현황

AI가 만든 컨텐츠들이 범람하고 있다

2026-10-31T22:31:40+09:00

네이버 검색의 퀄리티에 대해 항상 지적받는 부분이 있다. 검색 결과 상위에 걸리는 블로그 결과 등이 사람이 쓴 글이 아니라 AI slop 들이 대부분이라는 것이다. 나 역시도 이 문제는 네이버 뿐만 아니라 모든 포털 사이트들이 마주한 문제라고 생각하고,그 회사의 운명을 좌지우지할 중요한 문제라고 생각한다.

개인적으로 이 문제는 SNS 가 가진 구조가 변경되지 않는 이상 해결이 거의 불가한 일이라고 생각하고 있다. AI의 생산력이 사람에 비해 매우 높기 때문에 AI가 만든 컨텐츠의 절대량이 사람이 직접 만드는 수에 비해서 훨씬 높을 뿐만 아니라, 사람이 "직접 만드는" 컨텐츠도 줄어들고 있기 때문이다.

블로그, 인스타그램, X, threads 등은 조회수가 돈으로 연결된다. 그렇기에 AI가 나오기 전에도 SNS를 전문적으로 운영하며 수익을 창출하는 사람들이 많았다. AI의 도움을 받으면 이 사람들은 파이프라인 개수를 5배, 10배로 늘릴 수 있다. 당연하게도 이렇게 N배로 파이프라인을 늘릴 때 자신의 유니크한 경험을 녹아내기는 쉽지 않을 것이다. 유니크한 경험을 하는 물리적인 시간은 AI 전이나 후나 비슷할 테니까 말이다.

취미로 SNS를 운영하는 사람들도 AI 도움을 받지 않고 글이나 컨텐츠를 만들지는 않을 것이다. 글을 쓴다는 것은, 굉장히 많은 에너지를 요한다. 그림이나 동영상은 더욱 그럴 것이다. 그래서 AI에 점점 의존을 하고 있고, AI가 만든 컨텐츠들은 딱 잡아 말할 수 없지만 약간의 어색함이 있다. 일상생활에서 잘 쓰지 않을 법한 단어들을 쓰는 것이 가장 흔한 경우다.

지금은 많은 사람들이 그 어색함을 느끼고 있다. 아직 AI 를 일반인들까지 본격적으로 활용한지 몇 년 안되었으니까 말이다. 그런데 이보다 더 긴 시간이 지나면 어떨까?

사람들의 독서량은 점점 줄어들고 있다. 아마 AI가 나온 뒤에는 더 줄어들 것이다. 이는 사람이 직접 쓴 양질의 글에 노출되는 시간이 점점 줄어든다는 얘기다. 반면 AI가 쓴 글에 노출되는 시간은 더욱 길어질 것이다. 하다 못해 SNS를 하지 않더라도 많은 사람들이 chatGPT를 사용해서 정보를 얻지 않는가? 그러면 AI가 쓴 글이 사람이 쓴 글보다 더 익숙해질 것이고, 우리가 어색하다고 느꼈던 단어들이 AI가 계속 쓴다면 어색하지 않다고 느낄 것이다. 심지어 이제 출판되는 도서들은 AI의 도움을 받을 것이니 순수하게 사람이 쓴 양질의 글에 노출되는 기회는 매우 줄어들 것이다.

그래서 그런 시대가 오면 나쁜건가? 그건 잘 모르겠다. 아직은 가치 판단이 잘 안된다. 다만 분명 두려운 지점은 있다. 내가 글을 쓰는 능력이 점점 퇴화할 것 같다는 것. 그리고 그것이 내 논리적인 사고력에도 영향을 미치지 않을까.

그래서 이 블로그는 개인적인 경험을 쓸 때는 AI를 쓰지 않으려고 한다. 논문 리뷰나 지식 등을 다룰 때는 AI 도움을 쓰겠지만, '나' 에 대해서 다룰 때는 오롯이 나의 힘으로 책임을 다할 것이다.

개발자 어썸블로그

늙은 것은 나뿐이었다

LLM 캐시는 어떻게 작동할까: 앤트로픽 S-1 보고서로 읽는 AI 인프라 효율화

정도현 - 로보코 수석 컨설턴트

TL;DR

LLM은 Silver Bullet 일까?

"우린 다 필요 없어"

"There is no Silver Bullet"

"AI Slop"

"진짜만 살아남는 시대"

Blog: [메모] adb install vs android install 차이점 분석 및 비교

1. 핵심 차이점 한눈에 보기

(1) 소스 빌드 참조(Build Reference) 지원

(2) 기본 Delta Install (증분 패치) 지원

2. 벤치마크 환경 구성

테스트 시나리오

3. 결과 비교

1) 로컬 에뮬레이터 환경

① 기본 Compose 앱 (약 11~12MB)

② 52MB 앱 (대용량 에셋 포함)

결과 분석

2) 실기기 / Wi-Fi 디버깅 환경 (5 MB/s 대역폭 제한)

① 52MB 앱 (대역폭 5 MB/s)

② 11~12MB 기본 앱 (대역폭 5 MB/s)

결과 분석

4. “adb –fastdeploy”와의 차이

5. 요약 및 상황별 추천

Blog: [요약] The latest in Android dev tools (Android Dev Summit '26)

개요: AI 코딩 에이전트 시대의 안드로이드 개발 도구

핵심 구성 요소

1. Android CLI

주요 신규 명령어 (android --ads)

2. 터미널 환경의 에이전트 자동화 데모 (Claude Code)

(1) 프로덕션 크래시 재현 및 핫픽스

데모

사용된 Android CLI commands

(2) APK 최적화: R8 Configuration Analyzer

데모

사용된 Android CLI commands

(3) 앱 시작 시간(Startup Time) 최적화: Baseline Profile & Profiler

데모

사용된 Android CLI commands

3. Linux 데스크탑에서 Android 앱 네이티브 실행 (실험적 프로토타입)

4. AI 에이전트를 위한 공식 Android 플러그인

Google Antigravity

(1) Android Compose Preview

(2) Android Device Hub

Android CLI 연동에 따른 에이전트 효율성 벤치마크

5. Android Studio와 AI 에이전트의 진화

(1) Bring Your Own Agent (BYOA) via Agent Client Protocol (ACP)

(2) AI Change Review

(3) Android Studio Rabbit 릴리스 현황

관련 링크

기술 뉴스 #305 : 2026-11-01

웹개발 관련

그 밖의 개발 관련

AI 관련

인프라 관련

보안 및 장애

볼만한 링크

IT 업계 뉴스

프로젝트

버전 업데이트

엔딩 이후의 DLC: 토론토에서 당근(Karrot)을 다시 소개하며

Riftlancer: Privacy Policy

[SE-0553] Task Identity

Intro

Summary of Changes

Motivation

Proposed Solution

Detailed Design

Intended use and pitfalls

Task.ID

Task.currentID

Instance accessors

Performance contract

Interaction with task names

Future Directions

Conclusion

References

주요 신규 명령어 (`android --ads`)

주요 신규 명령어 (`android --ads`)