[Conference] Google Extensions I/O Extended 2023 Seoul 참석 리뷰

안녕하세요.

오늘은 Google Extensions I/O Extended 2023 Seoul 에 참석하게되어 리뷰해보도록 하겠습니다.

 

 

이번 컨퍼런스는 2023년 7월 29일 토요일에 강남 삼성역 코엑스에서 개최하였습니다.

 

티켓 가격은 10,000원이었으며 굿즈도 주는데 이 정도면 굉장히 혜자스러운 것 같습니다.

 

 

위치는 2호선에 강남 삼성역이라 접근성이 아주 좋다고 할 수 있겠네요.

 

코엑스가 워낙 넓어서 등에 Security 씌여져있는 분에게 물어보고 찾아갔었습니다.

 

 

 

 

 

이번 행사의 타임테이블입니다. 트랙이 3개로 나눠져있네요.

 

트랙1 섹션들 보면 발표자분들이 어디서 많이 본 네임드 분들이 눈에 띕니다.

 

 

 

 

제가 도착했을때는 이미 키노트 진행 중이었습니다.

 

인도 사람인거 같은데 영어로 스피치 하셔서 대부분 못 알아들었지만 마음만큼은 제게 전달된 것은 확실했습니다.

 

 

 

 

다음은 카카오뱅크의 Pluu님의 섹션이었습니다.

 

섹션 제목은 'What's new in Android development tools'으로, 안드로이드 스튜디오의 새로운 버전인 Hedgehog와 Giraffe 버전에서 등장한 기능들에 대해서 발표해주셨습니다.

 

 

내용을 간략하게 정리하자면 다음과 같습니다.

 

1. 네트워크 인스펙터: 서버개발자의 도움 없이도 API의 파라미터를 수정한다던지, 네트워크 테스트를 진행하고 확인할 수 있습니다.
2. 다크,라이트모드 아이콘 미리보기 지원
3. 다이나믹 칼라 미리보기 지원
4. 디바이스 미러링: 개발할 때 항상 Scrcpy을 사용했었는데, ide에서 아예 지원을 해버리는 점이 인상 깊었습니다.
5. 레이아웃 인스펙터: 위 디바이스 미러링을 사용하면서도 런타임에 미러링 화면을 더블클릭하면 해당 레이아웃이 있는 코드로 보내준다고 합니다.
6. 컴포즈 라이브 프리뷰 개선
7. 컴포즈 트레이싱
8. 앱퀄리티 인사이트: 파이어베이스 Crashlytics를 이제 ide에 연결해서 사용할 수 있습니다.
9. 안드로이드 봇: Ai Assistant가 유료서비스로 등장하면서 자체적으로 ide에서도 자체적으로 추가한 것 같습니다. 정확성이 떨어진다고 설명하셨습니다.
10. 파이어베이스 테스트랩
11. 햇지호그) 컴포즈 레이아웃 인스펙터
12. 햇지호그) 컴포사

이 섹션을 듣고 바로 회사에서 스튜디오 버전을 Giraffe로 업데이트했습니다. 정말 유익한 섹션이었네요.

 

 

 

다음 섹션은 네이버웹툰 안성용님의 'Dagger Hilt로 의존성 주입하기' 였습니다.

 

 

타임테이블을 보셨으면 아시겠지만, 40분짜리 섹션을 둘로 나누어 20분 동안 모든 내용들을 전달하기에는 모자란 시간이어서 사실상 랩을 하셨습니다.

 

의존성 주입 라이브러리를 사용해보지 않았던 터라 집중해서 들었습니다.

 

초반에는 기본적인 내용들을 먼저 설명해주셔서 이해하기 쉬웠지만 점점 못 알아듣기 시작하였고 반 이상은 못 알아들었던 것 같습니다.

 

 

 

다음은 양수장님의 'Flutter에 Clean Architecture를 얹어보자' 였습니다.

 

 

플러터에 대해서 관심은 있었습니다만, 잘 모르기도 하고 그래서 귀를 열고 듣기만 하였습니다.

 

레이어를 구분하여 개발에 적용하는 내용을 말씀하셨던 것 같습니다.

 

 

 

 

다음은 박상권님의 '일 잘하는 개발자는 회사에서 어떻게 일할까?' 섹션이었습니다.

 

상권님이야 워낙 유명한걸 알고 있었지만 상권님 섹션에는 준비된 좌석도 꽉차서 계단에 앉아서 들으시는 분들도 계실 정도로 많은 분들이 보러오셨습니다.

 

 

 

상권님은 '일 잘하는 개발자는 회사에서 어떻게 일할까?' 라는 제목으로 12년차 고인물 개발자가 전하는 업무 노하우를 전하는 시간이었습니다.

 

목차를 보여주시면서 이 부분만 보고 가셔도 된다고 하시며 사진 찍을 시간까지 주셨었습니다.

 

목차는 이렇게 되어있었습니다.

 

1. 암묵지 없애기
2. 기술로만 해결하려고 하지 않는다.
3. '안된다'고 하지 않는다.
4. 최적의 피쳐 개발방향을 찾는다.
5. 모든것을 기록한다.
6. 하라는대로 하지 않는다.
7. 일정 공유
8. 혼자서 다 하려고 하지 않기
9. 인정할 줄 안다
10. 명확한 단어와 문장 사용
11. TODO / Reminder
12. 알아서 잘한다
13. 귀찮아 한다
14. 회고

 

암묵지 없애기

 

암묵지 없애기란 도메인 지식에 대해 회사를 다니는 사람끼리도 본인이 생각하는 서비스 도메인에 대한 개념이 서로 다른 경우가 많아 이러한 암묵지들을 잘 정리해서 어딘가에 문서화를 하라는 내용이었습니다.

 

서비스 흐름도, 각종 피쳐들의 진행사항, 결과 등을 말씀하셨습니다.

 

저도 회사에서 개발하는 앱의 갯수가 굉장히 많은데, 이 앱 저 앱 개발하다가 다시 전에 개발하던 앱으로 돌아왔을 때 이 앱의 피쳐들을 다시 리마인드해야 하는 일이 많았습니다.

 

업무에 바로 적용해보면서 문서화를 해야할 필요성을 느꼈습니다.

 

 

기술만으로 해결하려고 하지 않는다.

 

다음으로 '기술만으로 해결하려고 하지 않는다.' 입니다.

 

고객들의 문제를 해결하기 위한 방법을 찾을때, 기술적인 방법으로만 해결하려 하지 말라는 내용이었습니다.

 

꼭 어려운 개발이 아니어도 아주 간단하고 쉬운 방법으로 큰 문제를 해결할 수 있다는 아이디어를 생각하라고 하셨습니다.

 

예를들어, 엘레베이터가 너무 느려서 고안된 방법으로 엘레베이터 내부에 거울을 설치하거나

 

상담원과의 통화 대기시간이 너무 길어서 통화 대기음을 길게하거나 편안한 노래를 들려준다는 것들이 있습니다.

 

 

 

'안된다'고 하지 않는다.

 

이전 직장에서 사수가 항상 입에 달고 있던 말입니다.

 

정말 개발적으로 안되는 기획내용이 있다고 하더라도 '안된다'는 말 대신 대안을 제시하라는 말씀을 하셨습니다.

 

선택할 수 있는 대안을 여러개 제시하고 각 대안들에 대한 장점과 단점을 명확히 정리해서 공유하라는 것이 핵심이었습니다.

 

저도 개발을 하면서 기획자들과 이런 부분들로 회의를 하는 경우가 많은데, 좀 더 좋은 '대안'을 생각하는 쪽으로 일을 해야겠다고 생각했습니다.

 

 

최적의 피쳐 개발방향을 찾는다.

 

기획자가 기획한 해결 방법보다 더 좋은 기술적인 방식이 있다면 제안하라고 하셨습니다.

 

비개발자는 그러한 기술이 있었다는 사실조차 모를 수 있기 때문입니다.

 

코드에 집착하지 않고 고객의 문제를 해결하는데 더 좋은 구현을 고민하라고 하셨습니다.

 

 

모든것을 기록한다.

 

말로 논의한 내용들을 모두 기록해야한다.

 

나중에 해당 논의에 대해서 기억이 안날 수도 있고, 누군가가 왜 그렇게 했는지 혹은 참고가 필요할 수도 있기 때문입니다.

 

되도록이면 개인끼리의 DM을 사용하지 않고, 공개된 채널을 이용하라고 하셨습니다.

 

 

 

하라는대로 하지 않는다.

 

수동적이 아닌 능동적으로 일하고, '꼭 이렇게 해야하나?' 더 좋은 방법에 대해서 생각하라고 하셨습니다.

 

관성적으로 개발해온 업무방식이나 코드들을 더 좋은 방식으로 개선하게 된다고 하셨습니다.

 

저도 사실 이런 마음으로 기획자분들을 달랠때도 있지만 업무 스타일에 따라 잘 안될 수도 있는 부분이라고 생각했습니다.

 

 

일정 공유

 

예측가능하고, 작업이 언제쯤 끝나는 지 공유하고, 중간 공유를 통해 진행상황을 공유하라고 하셨습니다.

 

이 부분은 커뮤니케이션이 없고 본인 개발만 하는 분들을 이야기하신 것 같습니다.

 

데드라인을 잘 지키고, 정말 늦을 것 같다면 미리 이야기하는 것이 업무하는 데 있어서 필수라고 생각했습니다.

 

 

혼자서 다 하려고 하지 않기

 

잘 안될때는 적극적으로 주변의 도움을 요청하고, 모르는건 모른다고, 부탁할건 부탁하는 것이 일 잘하는 개발자라고 하셨습니다.

 

이 역시도 위의 일정 공유와 같은 내용이라고 생각했습니다.

 

 

인정할 줄 안다.

 

고연차일 수록 고집과 자존심에 잘못을 인정하지 않는다고 합니다.

 

자신의 잘못이 있다면 인정하는 것이 첫 번째며, 죄송하단 말과 함께 정정하고 도움받았다면 감사하다고 해야 합니다.

 

 

명확한 단어와 문장 사용

 

요청을 하거나 질문을 할때 '배경'을 함께 이야기 하며, 듣는 사람이 이해하기 편한 단어와 문장을 사용하라고 하셨습니다.

 

서버개발자에게 서버개발 용어로, 디자이너에게는 디자이너 용어, 비개발자라면 개발용어를 풀어서 설명해야 합니다.

 

제가 가장 경험을 많이 한 부분인 것 같습니다.

 

이 부분은 결론을 먼저 말하고 배경을 뒤에 말하는 도치법을 사용하면 효과적인 것 같습니다.

 

 

TODO / Reminder

 

한일과 해야할일을 항상 정리한다.

 

개인 Snippet, 팀 Snippet을 정리하고, 내가 어떤 것을 했는지, 내가 뭘 해야하는지 명확하게 파악할 수 있다고 합니다.

 

휴가, 외부에 있어서 메세지는 확인했지만 나중에 해야할때, 지금 당장 그 일을 할 수 없는 상황일때, 문제 상황을 지금 당장 해결하지는 않겠지만 언젠가 하기로 했을때, 좋은 아이디어나 방법이 생각났을때

 

리마인더를 활용 하라고 하셨습니다.

 

저는 Trello를 사용하며 제가 하는 일을 Todo, Doing, Done, In Review(테스트 및 출시 직전), Release 로 구분해서 관리하고 있습니다.

 

금요일에 퇴근하기 직전에는 월요일에 업무를 수월하게 하기 위해 업무에 대해서 간략하게 메모하고 퇴근하는 습관을 들여오고 있었습니다.

 

리마인더에 대해서는 미흡한 부분이 느껴지는 부분인 것 같습니다.

 

 

알아서 잘한다.

 

A를 시키면 그에 반대되는 else 케이스에 대한 처리를 알아서 해야한다고 하셨습니다.

 

항상 개발을 하게되면 내가 손댄 부분의 파급력이 어디까지 미칠지 인지하는 것이 항상 필요하다고 생각합니다.

 

 

귀찮아 한다.

 

귀찮은 개발자가 자동화를 만든다고 하셨습니다.

 

3명이 하던 일을 자동화하여 1명이 할 수 있는 일로 만든다면 관리자 입장에서는 정말 최적의 방법으로 일 잘하는걸로 보일 수 있을 것 같습니다.

 

 

회고

 

잘한 것과 못한 것을 명확하게 인지하고, 무엇을 해야할 지를 고민해야 한다고 하셨습니다.

 

나에 대한 회고 뿐만 아니라, 타인에 대한 회고, 팀 회고, 피쳐 회고, 전체 회고들을 해야한다고 하셨습니다.

 

이런 부분들이 제게 필요한 부분이라고 생각했습니다.

 

매번 개발만 하고 다음 작업으로 들어가기 바빴는데, 작업이 끝날때 쯤 한번 회고를 하는 시간도 추가하는 것이 좋을거라고 생각했네요.

 

 

 

 

남은 네 번째 섹션에서는 듣고싶은 강연이 없어서 상권님 발표를 끝으로하여 Google Extensions I/O Extended 2023 Seoul 참석 리뷰를 마치겠습니다.

 

굿즈로 스티커와 티셔츠, 그물가방을 받았는데 아주 유용하고 유익한 시간이었습니다.

 

Google Extensions I/O Extended 2023 Seoul 굿즈

 

감사합니다!