종강한지 하루째 되는날! 6월 17일에, 안드로이드 개발자들의 축제인 드로이드나이츠 2025에 다녀왔습니다. 올해도 어김없이 다양한 세션과 커뮤니티 부스들이 개발자들의 눈과 귀를 사로잡았는데요. 특히 저는 카카오뱅크의 Compose 도입기, LazyColumn 성능 개선 사례, 클린 아키텍처에 대한 비판적 접근, 이력서 공개처형, 그리고 RevenueCat 부스에서의 경험이 인상 깊었습니다.
먼저, 작성에 앞서 취준생인 저는 이력서 공개처형 특별전형으로 응모를 했지만, 아쉽게도 선발되지 않았고, 이후 RevenueCat의 후원사 티켓으로 입장할 수 있었습니다. (올해 티켓은 59,000원이었습니다.) 팀플을 같이한 민준오빠랑 같이 가서 따로 또 같이 관심있는 세션을 들었답니다.
카카오뱅크는 작년부터 Jetpack Compose 도입을 위해 안드로이드 개발자 40명이 참여한 사내 스터디를 진행했고, 그 결과 전체 앱을 Compose로 재작성했다고 합니다. 총 2,000개의 UI 테스트와 240개 모듈로 관리되는 대규모 프로젝트였지만, 출시 2개월 간 크래시 없이 안정적으로 운영되었다는 점이 인상 깊었습니다.
기억에 남는 팁:
alignByBaseline
과 decorationBox
등 Compose 특유의 레이아웃 문제 해결 노하우DisposableEffect
활용송상윤 님의 세션에서는 LazyColumn의 스크롤 성능을 벤치마크 + BaselineProfile + Perfetto를 통해 개선한 실제 사례를 소개했습니다.
핵심 내용:
painterResource
는 메인스레드를 블로킹할 수 있으니 Coil
의 rememberAsyncImagePainter
로 교체Box
로 직접 구현해 성능을 3배 향상Modifier.layout {}
내에 직접 구현 → recomposition 최소화UI 성능 개선은 단순히 리팩터링이 아닌, 데이터 기반의 분석 → 실험 → 개선이 중요한 걸 다시금 느꼈습니다.
성능측정으로 처음-끝 실행시간만 해봤는데, 벤치마크나 perfetto 등의 도구를 사용해서 구체적으로 어디에서 시간이 오래걸리는지 검사? 할 수 있다는 것을 처음 알게 되어서 재미있고 흥미있게 들었습니다!
특히 compose 에서 제공해주는 api를 무조건적으로 사용할 경우 성능적으로 손해를 볼 수 있다라는 사실이 놀라웠습니다.
QnA에서 답변해주시기를, 다음과 같이 활용하면 좋다고 하셨습니다!
박상권 님의 세션은 제목부터 도발적이었지만, 핵심은 단순했습니다.
"클린 아키텍처란 관심사의 분리이며, 무조건적인 계층화가 아닌 프로젝트의 맥락에 맞는 구조를 설계해야 한다."
domain
은 순수 Kotlin 모듈로 설계 (기획자가 수도코드로도 이해 가능해야)data
는 repository pattern으로 분리presentation
은 Android ViewModelui
는 dumb view로서 ViewModel과만 소통특히 "UseCase는 단순 API 래핑이 아닌, 기획자의 로직을 구현하는 공간이어야 한다"는 말이 와닿았습니다. 따라서 기획자의 눈높이, 시선에서 생각한 방식대로 코드를 구성하고, 그외에는 다른 계층으로 넘기도록 하면 될 것 같다는 말씀이 신선했습니다.
로버트 C. 마틴의 클린아키텍쳐는 presndation -> domain <- data의 의존성 방향이며
구글의 권장 앱 아키텍쳐는 단방향으로 presentation -> domain -> data 의 흐름이다
둘을 혼동하지 말 것을 강조하셨으며, 아키텍쳐에 있어서 정답은 없으며 조직과 프로젝트에 맞는 것을 채택하면 된다고 결론 내셨습니다~
최신순 정렬
프로젝트, 수상, 활동 모두 최신순 정렬이 기본입니다.
간결하고 깔끔하게
- 부정적 단어 자제: “집요하게 파고들었습니다” → “끈질기게 해결했습니다” 등 긍정적인 표현 사용
- 문장은 두괄식, 핵심 내용을 앞에 배치
이력서와 포트폴리오는 반드시 분리
- 이력서에는 간결한 결과와 핵심만, 포트폴리오에 세부 내용과 이미지, 맥락 설명
- 프로젝트 요약은 이력서에 2~3줄 내외로 작성
기술 스택 단순 나열 지양: “Kotlin, Compose, Hilt....”
문제 → 해결 → 결과 구조
- 어떤 문제를 해결했는지 명확히 드러낼 것
- 단순 구현보다 왜, 어떻게 해결했는지에 중점
성과 수치화
- 성과 수치는 정량·정성 모두 가능
너무 많은 프로젝트? ➝ 주력 2~3개 선택
- 프로젝트 수가 많다고 좋지 않음.
→ 깊이 있는 2~3개가 더 설득력 있음
어떤 서비스였는지 설명
* “사용자 3,000명 확보한 학식 리뷰 앱” 같이, 서비스 목적과 성과를 보여줄 것
문단 구분, 볼드 활용
- 문장이 너무 붙어있지 않도록 줄 간격 확보
- 중요한 키워드는 Bold 처리
캡처 이미지 → 해상도, 설명 필수
포트폴리오에 넣을 경우
→ 이미지 설명, 역할, 맥락까지 명시
→ 흐릿하거나 의미 없는 이미지 금지
링크는 링크임을 명시
* “🔗 GitHub 링크 보기” 또는 “📎 앱 다운로드 링크” 형식 추천
단순히 사용한 기술보다 이유/선택 과정/문제 해결 사례 강조
❌ “Coil 사용”
✅ “painterResource의 Main Thread 블로킹 이슈 해결을 위해 Coil의 비동기 이미지 로더 채택”
클린 아키텍처, DI, 리팩토링 등은 실제 적용 맥락과 함께
아키텍쳐만 딸랑 x
인재상/회사 맞춤형 이력서
회사가 원하는 역량에 따라 소개 문구/프로젝트 순서 조정
“왜 우리 회사에 오고 싶은가?” → 직무 연결 필수
주관적 표현은 반드시 근거와 함께
- “협업을 즐깁니다” → 어떤 협업? 어떤 도구? 어떤 피드백?
- “사용자 중심 개발자” → 실제 UX 개선 사례 제시
항목 | 기준 |
---|---|
프로젝트 수 | 3~5개 이상 권장 |
기술 깊이 | 단순 구현이 아닌 “문제 해결 중심” |
수치화 | 정량/정성 지표 최소 1개 이상 포함 |
구조 | 최신순 / 두괄식 / 간결한 문단 |
포트폴리오 | 캡처 + 설명 + 역할 필수 |
이력서 | 지원 회사 맞춤형 / 깔끔한 구성 |
Q. 리팩토링처럼 수치를 뽑기 어려운 작업은?
👉 기여도/범위/이유로 정성적 수치화
→ 예: “전체 화면 중 40% 리팩토링”, “기존 구조의 테스트 커버리지 0% → 80% 향상”
부스 중에서도 눈에 띄었던 건 RevenueCat이었습니다.
RevenueCat은 인앱 구독/결제 기능을 빠르게 구현할 수 있도록 돕는 SaaS 플랫폼으로, 복잡한 구매 플로우를 단순화하고 분석까지 지원해주는 것이 특징입니다.
직접 부스를 방문해보니:
무엇보다 비개발자도 대시보드를 통해 쉽게 데이터 분석이 가능하다는 점이 인상 깊었어요.
내 프로젝트에서 인앱 결제를 도입하려 고민 중이라면 꼭 한 번 도입을 고려해볼 만한 서비스였습니다.
드로이드나이츠는 단순한 기술 발표의 장을 넘어, 커뮤니티와 산업 흐름을 직접 체감할 수 있는 축제입니다.
이번 경험을 통해 얻은 인사이트들을 제 개발 환경에도 녹여보고자 합니다. 특히 RevenueCat처럼 실제 서비스 운영에서 마주칠 수 있는 문제를 해결해주는 솔루션을 미리 만나볼 수 있어 유익했습니다. 앱 개발자인 만큼, 개인 앱으로 성공하는 꿈을 꾸곤 하는데요. 꼭 RevenueCat을 통해서 수익화를 실현해보고 싶습니다!!