우아콘 2024를 다녀와서

얼마전에 진행한 우아콘 2024를 다녀왔습니다. 저번 NHN도 컨퍼런스를 삼성역 그랜드 인터컨티넨탈 파르나스에서 하더니, 우아한형제들도 동일한 위치에서 하더라구요. 덕분에 위치가 익숙해 좀 편히 다녀왔습니다. 

 원래는 저희 회사에서 이런 컨퍼런스 등을 보내주지 않다가 얼마전부터 정책이 바뀌었다고 전해들었습니다(정책이 좀 더 일찍 바뀌었다면 드로이드나이츠에 다녀올 수 있었을 텐데...). 그래서 바로 기분 좋게 우아콘을 신청하게 되었고, 주변에서는 저만 당첨이 되어 다녀왔네요.

입구 사진을 찍어봤는데, NHN은 조금 웅장한 느낌이었다면 우아콘은 아기자기한 느낌이 들어 좋았던 것 같습니다. 친밀감이 든달까요.

 

 

---

 처음 들었던 세션은 당연하게도 오프닝 노트인데요. 사실 아침에 피곤해서 오프닝 노트를 건너뛸까 고민도 했지만, 오프닝 노트에는 우아한 형제들이 우아콘을 개최하는 목적과 회사에 대한 내용들이 담겨 있기 때문에 호기심이 조금 동하기도 해서 끝내 들으러 갔습니다.

 오프닝 노트에서 가장 기억에 남는 내용은 '만들어다오 만들어다오 하다가 나온게 만다오'(이 문장 덕분에 만다오가 뭔지는 기억에 안남지만 만다오라는 프로덕트가 있다는 건 확실히 기억에 남았습니다) 라는 문장과 Buds(Baemin User Design System)입니다.

 만다오는 설명이 길지 않았지만, Buds에 대한 설명은 꽤 길었는데요. 기존에는 배민에서 사용하려고 작업한 프로덕트였는데, 우아한 형제들의 그룹사인 딜리버리 히어로 내 계열사들 중 몇몇 기업들과 의견이 맞아 제공중인 프로덕트라고 합니다. 글로벌을 강조하는 것으로 보아 우아한 형제들에서 유의미하게 해외에 수출하는 프로덕트인 것으로 보입니다. 아마 이게 제대로 되면 배민은 이제 메인 서비스가 배달의 민족이 아니게 될 수도 있지 않을까...

 

 그 다음은 복잡한 비즈니스에서 중복 개발을 줄이기 위한 Module Federation Platform 구축을 듣게 되었습니다. 솔직히 이 세션에 대해서는 많이 기억나는 편은 아닙니다. 아무래도 제가 프론트엔드도 안해본데다 MF라는 프레임워크(?)도 사용해본 적이 없어서 일 것 같습니다.

 기억에 남는 건 Module이라는 것을 배포할 수 있는 최소 단위라고 하는데 이 모듈을 각각 개발하고 런타임시에 다시 합쳐 remote에서 최종적으로 수행한다는 것입니다. 안드로이드의 멀티모듈이 이와 비슷한 방식을 지니고 있지 않나 라는 생각을 해 봤습니다(물론 설명을 들어보니 내부 구조는 명백하게 다르긴 합니다).

 이러한 MF를 1.0과 2.0를 비교하면서 얼마나 발전했는지를 설명해줬고, 그 이후에도 남아 있는 문제점들을 설명해주었는데 아직 오래되지 않은 기술인 것 같았습니다. 그럼에도 불구하고 그것을 적용하고 기술 자체의 결함(정확히는 프로젝트에 fit하지 않아 커스텀해야하는 부분들)을 해결하기 위해 새로운 여러가지를 도입한다는 것이 멋지게 다가왔습니다. (저런 자세는 있어줘야 개발자라고 할 수 있죠... 개인적인 의견입니다.)

 결국은 슬슬 멀티모듈을 도입할 시기가 왔다는 것을 느끼게 되었습니다. 빌드 시간이나 효율은 개발 리소스를 줄이는 일이지만 앱의 성능이나 UX에 대한 이슈는 아닌지라 순위가 좀 밀린 감이 있는데, 트렌드가 점점 마이크로한 형태로 가는 걸 보니 확실히 중요하지 않나...(사실 중요한 것은 알고 있습니다만, 회사 프로젝트를 한 번에 갈아엎기도 어렵고 개인 프로젝트는 굳이 멀티모듈을 쓸 정도로 크지 않으니...)

 

 그 다음은 제가 우아콘을 신청하게 된 계기인 XML에서 Compose로 전환하기 세션이었는데요. 기대가 컸습니다. 과연 우아한 형제들에서는 어떤식으로 XML에서 Compose로 코드를 전환하고 있을까. 그래도 저랑은 다르게 엄청 멋지고 화려하게 바꾸는 건 아닐까하면서 한 수 배울 준비를 하고 세션에 들어갔습니다.

디자인 시스템을 보여주기 위한 예제 앱

 세션의 시작이 Compose의 장단점으로 시작되면서 사실 걱정했습니다. 제가 이 세션에서 얻어가고 싶었던 건 Compose의 이론적인 부분이 아니라 과연 나보다 더 뛰어난 개발자들은 Compose로 전환하면서 어떤 문제를 겪었을지, 혹은 어떻게 전환 작업을 거쳤는지에 대해서 배워가려는 것이 컸으니까요.

 다행히 이 세션인 제 생각에 맞게 장단점의 설명이 끝난 후 전환 시 고려해야할 점과 Compose로 전환하면서 개발자분들이 겪은 사례들에 대한 설명으로 넘어갔습니다. 발표가 완벽하게 매끄럽지는 않았지만, 그 안의 내용은 필기하고 싶은 내용들이 많았습니다. 저도 겪어봤던 AutoTextSize와 관련해 어떤 방식으로 제작했고, 어떤 문제가 있었는지에 대한 설명도 있었고 아직 제가 알지 못하는 가로 스크롤의 높이에 대한 이슈도 확인할 수 있었습니다. 

 세션을 들으면서 하나 머리를 치고 갔던 부분은, 발표자분께서 개발을 하다가 항상 뭔가가 막히면 그 컴포넌트(ex: Text)를 눌러 내부 필드나 메소드를 확인한 후 의심가는 부분부터 테스트해가며 개발을 진행했다고 했는데 요즘 저는 Compose를 작업할 때 모르는 부분이 생기면 일단 ChatGPT한테 달려가서 그 부분에 대해 설명받곤 했는데 어느 순간부터 태도가 잘못되어 있었구나 하는 생각이 떠올랐습니다.

 사실 참 많이 들어왔던 이야기고 개발 방식이었는데, 어느 순간 편한길만 찾아가는 중이었다는 걸 깨닫게 되어 반성의 시간을 조금 가져보았습니다(그래도 안바뀌고 ChatGPT한테 달려가겠지만). 개발자로서 실격이네요. 확실히 개발에 대한 흥미가 많이 떨어졌다는 것을 느끼는 시간이었습니다.

 

 점심을 먹고 나니 조금 졸렸었는데, 마침 제가 관심있어하던 세션이 이번에 처음 진행하는 멘토링 세션이더라구요.

멘토링 세션은 기존 세션 과 다르게 강연자(멘토)분들이 앞에서 발표를 하지만, 청자(멘티)가 모두 같은 방향을 보는 것이 아닌 멘토를 둘러싸는 형태로 좌석이 구성되어 있어 토론의 분위기를 만들어주었습니다. 세션은 먼저 참여하는 사람들이 보낸 사전 질문에 대한 응답을 진행하고 본격적으로 중앙으로 와서 자유롭게 질의응답을 진행하는 형태였습니다.

 사전 질문이 좀 많았던 모양인지(시간이 좀 짧기도 했습니다) 생각보다 중앙에서 토론을 진행하는 시간이 짧긴 했습니다. 이 세션에서는 사람들이 좀 더 심도있는 개발적인 이야기를 할까 생각하고 들어갔었는데, 취준생이나 주니어 분들이 많아(저도 마찬가지지만) 취업에 대한 고민이나 멘토가 생각하는 이상적인 개발자, 안드로이드 전망 등의 질문이 주를 이루었습니다. 물론 유익한 시간이었습니다만, 회사에 보고할 내용은 아니었던지라(이직하냐는 소리 듣기 좋을 것 같습니다) 난처하긴 했습니다. 그런다고 다른 세션이 저에게 엄청 유익한 것도 아니었지만.

 그래도 멘토분들이 사용하는 아키텍처에 대한 질문이 있었는데, 그 때의 질문과 대답이 조금 의미가 컸던 것 같습니다. 멘토의 팀의 경우 MVVM + MVP를 섞은 팀 만의 아키텍처를 사용한다고 얘기했었던 것 같은데(뭔가 기억이 흐릿해서 정확하지 않을 수 있습니다), 중요한 것은 프로젝트에서 일관된 아키텍처를 최대한 오래 유지하고 모든 사람들이 동의하는 것이라고 했습니다. 그래서 어떤 아키텍처를 쓰느냐는 합의가 중요하다고 합니다.

 멘토 두 분 중 다른 한 분은 안드로이드가 요새 권장 아키텍처를 소개하는 등, 구글에서 제시하는 가이드라인이 많으니 그대로 따라가는 것이 제일 좋지 않을까라는 의견도 주셨습니다. 저도 이 의견에 동의해서 끄덕거리면서 들었습니다.

 그리고 또 안드로이드 개발에서 중점을 두는 포인트가 무엇이냐는 질문에 유저 경험(UX)가 가장 중요하다고 말했는데요. 이 부분을 얘기하면서 기존 다른 개발자분이 문제가 발생하면 throw를 던져버리는 경우가 있었다고 합니다. 그런 경우 크래시가 발생해 어디든 로그가 남으니 찾고 수정하기 용이해서 개발적인 퀄리티가 올라가기는 좋지만 사용자의 입장에서는 앱이 갑자기 뻗는 현상이 발생하는 것이기 때문에 UX가 좋지 않아 사용자가 줄어들 수 있게 되니 throw를 내지 않는다고 합니다.

 이 내용에 대해서는 제가 좀 느낀 부분이 있는게, 저는 그래도 개발을 위해서는 throw가 어느 정도 있어야 한다고 생각했던 편(그렇다고 앱이 픽픽 죽어도 된다는 의미는 아니었습니다. 심각한 부분이라면 앱이 크래시가 나는 것을 감수하는게 좋지 않나 라고 생각했던 정도입니다.)인데 회사에서도 이와 같은 내용을 설명했었고, 배민의 세션에서도 같은 이야기를 듣고 나니 예외는 없이 두는 편이 좋은게 맞겠다는 생각을 했습니다. 제가 개발자다 보니 크래시가 자주 나지 않으면 발생하더라도 크게 신경을 안쓰다보니 더 그렇게 생각했던 것도 같네요.

 

 마지막으로 들었던 세션은 디자인 시스템 문서를 생동감있게 만들기였는데요(그 뒤 세션은 아쉽게도 못들었습니다).

사실 이 세션도 디자인 시스템에 관한 내용일거라 생각해 웹 세션이었지만 들어가게 되었는데요. 정확하게는 우아한 플레이그라운드라는 프로덕트에 관한 내용이었습니다. 우아한 플레이그라운드는 웹 프론트엔드 개발자분들을 위해 만들었다고 하는데요. 신규입사자 분들이 스토리북이나 가이드를 확인해서는 컴포넌트들을 명확하게 이해하기 어려운 경우가 많아 결국 코드로 확인해야 하는 문제를 해결하기 위함이라고 합니다. 왼쪽에서 코드를 작성하면 오른쪽에서 실시간으로 UI가 보이며 배민에서 만든 디자인 시스템 컴포넌트를 쉽게 UI로 확인할 수 있다고 하네요.

 자세한 내용은 말해도 되는 지 몰라 생략하겠지만, 새로운 프로젝트를 열지 않고 여러 컴포넌트들을 조합해볼 수 있는 실시간 IDE같은 느낌으로 되게 괜찮겠다는 생각을 했습니다. 물론 프로덕트를 제작하는데 드는 리소스 자체가 만만치않고 웹에 특화된 느낌이라 안드로이드 개발자인 제가 실행해볼 일은 없겠지만, 제가 웹 개발자였다면 개인 프로젝트 느낌으로 한 번 비슷한 걸 만들어봤을 것 같다는 생각을 해봤습니다.

---

 총 네가지 세션을 듣게 되었는데, 되게 고마운 시간이었다고 생각합니다. 프론트 부분은 제가 지식이 떨어져 많은 이해를 하지는 못했지만 되게 신선했고(웹 개발자가 아니라서 더 그럴지도 모르겠습니다), 안드로이드도 얻어간 것이 꽤 많은 그런 컨퍼런스 였습니다.

 그럼에도 사실 이번에 조금 아쉬웠던 점은 안드로이드 개발자를 위한 세션은 XML을 Compose로 전환하기 1개이고 나머지는 멘토링 세션에 2개가 배치된 것이 전부 였다는 것입니다. 물론 배민은 안드로이드 개발자가 많지 않기도 한 걸로 알고 있고 주류가 앱이긴 하지만, 웹으로 대부분을 작업한다고 했으니 이해는 가는 부분이지만...

 안드로이드 시장이 성장하는 것과 별개로 점점 안드로이드 개발 자체의 밸류는 조금 떨어지는게 아닐까 하는 걱정이 들긴 합니다. 하지만 이미 선택한 진로, 포기하기엔 아깝고 돌아가기엔 안드로이드가 나름 재밌는 상태라 열심히 하는 것이 제 선택이겠네요.