인프런 퇴근길 밋업 with LINE에 다녀온 따끈따끈한 후기

인프런 퇴근길 밋업을 다녀와 작성했는데, 밤 12시 피곤한 상태로 작성한 글이라 오류able한 글입니다. 혹시 틀린 내용이 있다면 댓글로 알려주시면 호다닥 수정하겠습니다.

6:1이라는 엄청난 경쟁률을 뚫고 인프런 퇴근길 밋업 with line에 다녀왔습니다. 플러터가 핫해서인지 인프런이 핫해서인지 라인이 핫해서인지 모두 다 해당되겠조 아무튼 못가서 아쉬운 분들이 많이 계실듯하여 바로 집에오자마자 냅다 노트북 열고 후기를 씁니다.

발표 영상과 자료는 추후 인프런에도 업로드 된다고 하니 세션의 내용을 자세히 알고싶은 분들은 인프런에서 보시면 좋을 것 같아요!

직장 동료들 분과 (이직을 성공해서 이제는 전 직장 동료분들이 되어버린..!하핫) 모두 참가 신청을 했는데 운이 좋게도 동료 한분과 당첨이 돼서 함께 다녀왔답니다. 샌드위치를 주신다고 하셔서 편의점 삼각 샌드위치를 상상했는데 무려 서브웨이!!!! ((인프런 최고 짱))

이번 밋업은 플러터를 사용하고 계신 라인 개발자 3분의 발표로 이루어져 있었고 마지막엔 함께 모여 이야기를 주고받을 수 있는 네트워킹 시간으로 구성되어있었습니다. 그동안 많지는 않지만 온,오프라인 기술 관련 세미나들을 보면서 사실 많은걸 배우거나 인상깊은 세미나는 없었어서 큰 기대를 하진 않고 '키워드 하나라도 얻어가자'라는 생각으로 간건데, 인프런 퇴근길 밋업은 내용도 구성도 너무 만족했습니다!

세션 톺아보기

1. Flutter 엔지니어로 직무 전환한 이야기 - 김종식님

한 줄 후기 : 플러터를 제대로 쓴다는 건 저렇게 쓰는 것이구나,,!

첫 세션은 종식님이 열어주셨는데요, 발표를 진행해주시는 LINE의 abc studio가 어떤 팀인지 먼저 소개해주신 후, flutter 개발자로 직무를 전환하면서 경험한 것들을 나누어 주셨습니다.

abc studio는 어떤 팀인가?

abc studio는 above beyond for change라는 뜻을 지니고 있다고 해요. 사람들이 필요로하는 제품을 필요한 때 빠르게 만들어내는 프로덕트 메이커로 새로운 시도를 많이하는 조직이라고 합니다. 다양한 서비스를 만들어왔고 그 중 하나가 일본의 배민이라고 너무나 잘 알려진 demaecan이라고 합니다. 저는 배달앱을 통째로 flutter로 recode하는 유명한 라인 블로그글을 통해 demaecan을 알고있었는데, 이번 세션을 통해 좀 더 그 고민 과정들을 생생히 들을 수 있어서 좋았습니다.

단순히 일본의 배달의 민족일거라고만 생각했는데 사용자가 배달을 할 때 쓰는 컨슈머 앱, 파트너 앱 , 음식 이외 다양한 상품 취급하는 retail app , 배송 제안 확인 상품 전달하는 driver app 등 총 4개의 앱으로 서비스를 운영 중인 굉장히 큰 서비스여서 놀라웠습니다.

이런 큰 서비스를 운영하면서 유저의 피드백을 수집할 수 있는 서비스를 직접 개발하여 실제 서비스에 적용중이라고 해요. abc studio가 사용자에게 민감하게 반응하는 조직이란 걸 알 수 있었던 부분이였습니다. 해당 코드는 오픈 소스로 공개되어있으니 관심있는 분들은 살펴보시는 것도 좋을 듯 해요.

abc studio 팀은 기술 교류를 위해 매주 1시간 정도 flutter discussion이나 flutter tea time을 가진다고 해요. 네트워킹 시간에 이 부분에 대하여 좀 더 자세한 이야기를 들을 수 있었습니다. 저 또한 팀 내에서 플러터 위클리나, 먼슬리같은 세미나를 통해 기술경험을 해본 경험이 있는데 꾸준히 지속하기가 쉽지 않더라구요. 유진님께서는 해당 발표가 큰 부담이 없는 양과 시간으로 이루어져있기 때문에 지속 가능하다는 이야기를 해주셨습니다. 추가적으로, 라인에서는 플러터 개발자들이 각기 다른 앱들로 나누어져있어서 소통할 일이 많이 없는데 이런 시간을 함께 가지며 누가 어떤 문제를 겪고 있고 해결과정은 어떻게 되는지, 혹은 나는 '이런 해결방법을 써봤다' 공유하면서 도움이 많이 되었다고 하셨습니다.

abc studio팀의 행보가 더 궁금하신 분들은 instagram과 youtube를 통해 보실 수 있다고 합니다. 이번 밋업을 통해 수평적이면서도 기술적으로도 이렇게나 적극적인 성장을 이루는 팀이 있다는 걸 알게돼서 앞으로 많은 레퍼런스가 될 것 같습니다.

flutter 엔지니어로 직무 전환한 이야기

안드로이드 네이티브 개발자셨던 종식님은 크로스 플랫폼 기술은 하나의 도전과제로 생각하셨다고 해요. 그러다가 네이티브에서 rn으로 기술을 변환하는 경험을 해보셨는데 테마가 적절히 적용되지 않는 이슈 등 짜잘짜잘 이슈들이 있어 다시 네이티브로 변환하셨다고 해요. 이 실패 경험을 통해 프로젝트 자체가 그 기술 하나로 구성되지 않으면 힘들다는 것을 배우셨다고 합니다.

이후 라인에 합류하게 되신 후 flutter를 도입하게 되어서 빠른 학습이 필요한 상황이 오셨다고해요. 당시 dart.dev/language, effective-dart 등 다트 공식 문서에 나와있는 실제 예들을 dartpad.dev를 통해 실행해보며 언어를 익히셨다고 합니다. async await, cascade notation 개념들이 특히 익히는데 시간이 좀 걸렸으나 이 부분은 실제 코드를 사용해보시면서 숙달이 되었다고 하셨습니다. 물론 저도 실무에서 두 개념을 쓰는데 큰 어려움은 없지만, 그렇다고 내가 저 개념들을 100프로 이해하고 설명할 수 있나?하기엔 자신이 없어서 해당 키워드들도 파봐야겠다는 생각이 들었습니다.

종식님이 flutter로 recode하는 프로젝트를 맡아 직접 사용해보시면서 느낀 장점은 모듈화를 통해 기능이나 도메인을 패키지 단위로 분리가능하다는 점이였다고 합니다. 실제 코드들을 보여주셨는데 많은 기능들을 패키지로 분리시켜 사용하시더라구요. 저는 실무에서 어떤 기능을 독립적인 모듈로 만들어 사용해본 경험이 없어서 놀라웠고 모듈화를 적용했을 때의 장점이 궁금했습니다.

패키지들로 기능들을 분리시킨 후, melos라는 다중 패키지 관리 도구를 통해 패키지들을 연결할 수 있고 명령을 동시 실행가능하다고 합니다. 또한 vscode에서 패키지별 참조관계를 시각적으로 볼 수 있다고 합니다.

패키지들의 테스트 코드를 실행하고 결과로 나오는 파일들을 병합해서 genhtml로 가시화해서 사용한다고 하셨습니다. 실제 적용시켜보고 싶으신 분들이나 자세한 내용을 보고싶은 분들은 종식님의 flutter 패키지로 공통 모듈 리팩토링하기 글을 참고하면 좋을 것 같습니다.

또한 프로젝트에서 get it 과 injectable 패키지를 활용해 의존성 주입한 내용을 발표해주셨는데, 의존성 주입을 통해 코드 분리가 명확해지면서 테스트가 용이하게 되었다고 해요. 해당 내용은 종식님의 Flutter DI: get_it + injectable 블로그 글을 참고해주세요! 저는 이부분이 제일 어려웠어서 해당 글로 다시 복습해보려고 합니다.

마무리 때 종식님이 기술을 어떻게 학습하는지에 대한 이야기를 나누어주셨는데요. 종식님이 개인적으로 학습할 때 중요하다고 생각하시는 건 회고를 꾸준히 하시는 것라고 해요. 종식님이 갑자기 산책을 나가신다고 하면 그것은 회고를 하러 가시는 것
거의 매일 산책을 하며 회고를 하거나, 문서화가 필요할 땐 문서화로 회고를 진행 하신다고 하셨는데, 저 또한 자칭 피드백 광인인 입장에서 늘 스스로 회고 방식에 대한 회의감과 의문점이 있어서 회고 방법에 관해 추가 질문을 드렸습니다.

종식님은 스스로에게 솔직하고 정확하게 회고하는 방식이 필요하다고 답변해주셨습니다. 왜지?라고 스스로 왜라는걸 계속 묻고 묻고 묻다보면, 그 왜에 대한 질문에 스스로 답이 나오지 않는 지점이 있다고. 그 지점까지 물어보라고 하시더라구요. 그동안 회고를 위한 겉핥기회고를 해오진 않았나, 스스로 정말 솔직하게 회고했나라고 반성하게 되었답니다. 이 깊은 회고 방식은 아직은 추상적으로만 와닿기에 앞으로 업무를 해나가면서 숙달해나가야하는 부분인 것 같습니다.

나는 어떤 것을 배웠나

사실 종식님이 네이티브 개발자에서 플러터로 직무 전환을 하며 경험하셨던 것들에 대한 내용은 코흘리개 주니어 플러터 개발자의 입장에서 한번에 이해하기 어려운 내용들이 많았습니다. 공부 자극이 되는 세션이였습니다 더욱이 저는 네이티브 경험이 없기에 더 어려웠지만, 플러터 개발자분들 중 네이티브를 원래 다루셨던 분들에게 도움이 많이 되는 세션이였던 것 같습니다. 함께 간 제 동료분(안드로이드 전문가)은 도움이 많이 되었다고 하니, 네이티브를 경험해보셨거나 네이티브에서 플러터로 직무 전환을 하려고 하시는 분들은 들어보셔도 좋을 듯 합니다!

짧은 시간에 많은 내용이 담겨 있다보니 좀 아쉬웠는데, 종식님이 블로그 글로 정리해두신 자료들이 많아서 공부하기가 참 좋을 것 같습니다. 저는 의존성 주입이나 모듈화에 대해 블로그 글을 통해 좀 더 공부를 한 후 복습차원으로 다시 들어보려합니다. 모듈화나 의존성 주입과 관련한 패키지들의 실사용예제를 볼 수 있어서 좋았던 세션이였습니다. 그저 바로바로 안따라와주는 저의 두뇌가 아쉬울 뿐..

2. Flutter 프로젝트에 테스트 들이붓기 - 최연두

한줄후기 : 내가 뭘본거지?.. 실무에 저렇게 테스트코드를 똑똑하게 적용하신 것도 놀랍고.. 연두님의 발표실력도.. 어메이징.. 그저 놀라움의 연속..! 같은 최씨에 같은 연차인데..! 나는 왜..!

연두님은 1년 1개월동안 프로젝트에 테스트 코드를 들이부었던 경험을 공유해주셨습니다. 저는 실무에서 테스트코드를 적용해본 적이 없고, 실무에서 테스트를 적용해봤다는 분들을 만나기가 어려워서 드디어..! 말로만 듣던 테스트 코드를 보는구나..! 가장 기대했던 세션이에요. 하지만 기대한 것 보다 훨씬 더 많은 것을 얻어갈 수 있었던 세션이었습니다. 플러터에서 테스트코드를 어떻게 적용하는지 관심이 있으신 분들은 꼬옥 인프런가서 들어주세요..! 강추입니다.

테스트 코드를 적용한 과정

연두님은 4개의 앱 중 retail app을 만드셨다고 합니다. 초기에 개발과 qa, deploy가 모두 고정된 기간안에 해내야했고, 그렇기에 기간에 대한 압박이 있었습니다. 어느 회사나 그렇듯 기간에 쫓겨 테스트를 고려하지 않은 설계를 해왔고, 실제 이슈가 발생하진 않았지만 코드에 대한 신뢰도가 낮다는 팀 단위의 공감이 있었다고 합니다. 따라서 테스트 코드를 적용시키기로 하셨어요.

사실 모든 회사가 테스트 코드가 필요하다는 것에 공감은 하지만, 실무에서 현실적으로 추진시키기가 어렵습니다. 이 부분에 대해 추가 질문을 드렸는데, 연두님은 다른 팀에게 우리가 테스트 코드를 적용시키기 위해 일정을 늘려달라고 설득할 순 없는 일이기에 맞춰진 일정에 그저 팀 개개인이 열심히..! 의지로 해내셨다고 해요. 비결은 그냥 하는 것..해내는 것..

그리고 테스트 코드를 도입할 때 모든 코드들에 추가하자!가 아니라, 이전 코드들은 우선 리팩토링 시에 따로 추가하는 것으로 하고 지금부터 생성된 pr에만 테스트 코드를 넣는 것으로 시작하셨다고 합니다. merge 규칙에 테스트 코드를 유효 커버리지 rate를 정해놓고 이 rate 이상 넣는 것으로 강제로 적용시켰는데요.

만일 너무 일정이 빡세서 절대 불가능한 상황에서는 pr에 freepass test label을 붙여서 유효 커버리지 rate 조건이 통과안되도 들어갈 수 있는 예외 규칙을 추가했습니다. 이 부분을 듣고 실무에서 적용할 수 있겠다는 용기가 생겼습니다. 적용할 수 있는 부분부터, 예외 조건을 걸어두고 하면 할 수 있겠는데?!라는 생각이 들었습니다.

그 다음으로는, 보이는 위젯과 보이지 않는 위젯을 테스트한 실제 코드 예시를 보여주셨습니다.

보이는 위젯을 테스트 하는 법!

golden test : 스냅샷 테스트라고도 불리며, 특정 시점에 결과물이 우리가 원하는 정답 이미지(golden image)와 같은지 비교하는 테스트

저는 골든 테스트라는 개념을 처음 알았습니다(히히 반성합니다) 골든 테스트를 통해 보이는 위젯을 테스트하면 우리가 의도한 대로 ui가 제대로 나왔는지 확인할 수 있습니다.

골든 이미지를 생성하는 방법은 간단합니다. flutter test --update-goldens 명령어를 실행하면 파일 이름에 맞게 골든 이미지가 생성된다고 합니다. 그렇게 생성된 이미지를 우리가 의도한 ui가 맞는지 파일을 보고 확인 후, flutter test로 테스트를 돌면서 snapshot을 비교해 맞게 그려졌는지 확인하며 테스트가 진행됩니다. 이 골든 테스트를 작은 버튼 위젯부터 화면 단위까지 하고있다고 해요.

이렇게 골든 테스트를 하면 리뷰어에게 신뢰도 있게 전달이 가능하고, ui를 위해 직접 빌드하지 않고도 기기 별로 보여지는 이미지를 확인 가능해서 편리하다고 합니다. 단순 UI만 비교해 테스트를 할 수 있는 것이 아니라, 시나리오 테스트도 수행이 가능하다고 해요. 로그인 시 실패한다면 실패했을 때 뜨는 ui와 성공했을 때 main page가 나오는 시나리오에 따라 테스트하는 코드도 살펴볼 수 있었답니다. 골든 테스트를 실무에 적용시킨 사례를 자세히 보고싶다면 연두님 세션을 꼭 들어보세요!

보이지 않는 위젯을 테스트 하는 법!

보이지 않는 함수와 같은 것들을 테스트 했던 방식도 소개를 해주셨습니다. 크게 동기와 비동기 함수가 있다고 했을 때, 동기 함수들은 테스트 순서에 맞게 실행되지만, 비동기 함수의 경우 테스트 순서에 맞게 잘 실행되지 않는기 때문에 비동기 함수 테스트를 중심으로 소개를 해주셨습니다.

fakeAsync 패키지를 소개해주셨는데, 해당 패키지는 시간을 제어할 수 있는 환경을 만들어 준다고 해요. 테스트가 실제 시간이 경과할 때까지 기다릴 필요 없이 해당 시간에 예약된 모든 비동기 이벤트를 실행하도록 해준다고 해요. 5초에 한번씩 서버에 리퀘스트를 보내는 테스트 등을 실무에서 할 일이 많은데 그럴 때 이런 패키지를 활용해 테스트하면 되는구나 배웠답니다.

나는 어떤 것을 배웠나

제가 위에 요약해둔 내용들은 너무 너무 요약된 내용들 이고, 사실 연두님이 해당 세션을 들을 때 필요한 개념들을 짚어가주시면서 자세히 설명을 해주셨기 때문에 직접 해당 세션을 들으시는게 훨씬 도움이 되실거에요! (저도 다시 들을 것이에요..)

테스트 코드를 넣고 코드의 신뢰도를 넣는 것에서 가장 중요한 것은 실천이라는 것을 배웠습니다. 그동안 말로만 테스트코드를 넣고 싶어 하지않았나 반성했고, 기간에 쫓기면서도 더 좋은 코드를 위해 적극적으로 일하는 abc studio 팀을 닮고싶다는 생각이 많이 들었습니다. 네트워킹 시간에 운이 좋게 쿠팡 개발자분과도 이야기를 나눌 수 있었는데, 쿠팡에서도 테스트 코드를 적용시켜 일하고 계시더라구요. 테스트 코드는 존재한다..!

3. 플러터 canvas로 어디까지 해봤니? - 조용대

한줄후기 : 욕심이 많은 개발자라면 페인트를 써보자!

위에 보이는 이미지의 연기는 용대님이 구현한 것..! 세션을 듣는 내내 감탄의 감탄이 나왔습니다. 단순하지만 또 구현하기 어려운 점선구현이나 squircle ui 구현하는 방법부터 저걸 어떻게 구현해~!~!싶은 애니메이션들이 가능하다. 욕심만 많다면 가능하다!는 것을 보여주셨습니다. 굉장히 아무것도 아니라는 듯 무심히 차분히 발표하시는게 킬링 포인트였답니다. 네트워킹 시간에 따로 용대님은 팀에서 저..저 역할(?)만을 맡으신거냐고 다른 팀원분께 여쭤봤는데 아니라고 하셔서 더욱더 놀라웠답니다.

용대님은 rederobject 객체가 어떻게 구현되어있는지, ticker가 어떤 방식으로 동작하는지 원리부터 설명을 해주셨습니다. 평소에 ticker에 대해 궁금했던 분들이나, custompaint+ customPainter를 활용해 좀 복잡한 차트같은 것을 구현하는데 힘들었던 개발자분들에게 도움이 될 것 같은 세션이였습니다. 현란한 화면에 현혹되어 필기를 많이 못해서 세션을 다시 들어야할 것 같아요..! 저도 다양한 애니메이션을 구현해보고싶은 욕망이 있기에 재밌게 들었습니다.

ticker를 직접 다루는것이 언제나 좋은 방법은 아니지만, ticker를 활용하면 자유롭게 관리가 가능하기 때문에 복잡한 애니메이션을 구현할 때 직접 다루신다고 해요. ticker의 동작 방식이 재귀 프로세스로 멈추기 전까지 반복되도록 구현되어있는게 신기하고 재밌었습니다.

직접 ticker와 canvas를 통해 구현하신 다양한 ui를 보여주셨는데, 특히나 인상깊었고 재밌었던 부분은 데마에칸 앱에 들어간 이스터 에그였습니다. 아직 sns에 발견한 고객이 없어서 슬퍼하시는데, 슬퍼하실만한 퀄리티의 이스터 에그였어요. 플러터의 다른 패키지를 활용하지 않고도 저정도의 퀄리티로 애니메이션이 가능하구나를 직접 볼 수 있어서 좋았습니다. 누가 제발 발견해줘라!!!!!!

나는 어떤 것을 배웠나

이전 세션의 연두님도 그렇고, 이번 용대님도 인상깊었던 부분이 적극적이고 주도적으로 기술을 적용시켰다는 부분이었어요. 누가 시킨 것도 아닌데 정말 기술과 앱을 사랑하기에 나오는 노력들에 감탄을 했습니다.

사용자를 위해 기술을 배우고 사용하는 개발자가 되어야겠다는 생각이 들었습니다. 정말 필요한 기능을 제때 구현하는 것이 개발자의 기본이고 중요하지만, 이스터 에그와 같이 단순 앱의 재미요소를 진심을 다해 넣는 개발자도 세상엔 너무나 필요한 것 같습니다 히히.

밋업을 마치며

최고의 플러터 세션을 마련해주신 라인 개발자분들과, 인프런의 긍정적인 에너지를 뿜뿜하며 밋업이 잘 진행될 수 있게 도움주신 커뮤니티 분들 특히 연의님의 유려한 진행 능력! 모두들 이런 고퀄 행사를 진행해주셔서 너무 감사합니다. 이 후기글을 쓰는데 어제 밤부터 오늘까지 이틀간 작성을 하게 되었네요. 그치만 기억하고싶고 배운게 많은걸! 얼른 인프런에 밋업 영상 올라올 때까지 숨참고 기다리겠읍

아쉬웠던 부분

개인적으로 오픈채팅방이 하나 개설되었으면 좋겠다는 생각이 들었습니다. 세션 진행 중 실시간 질문도 가능하고, 이후 꾸준히 소통할 수 있는 채팅방이 있으면 좋을 것 같아요! 이렇게 많은 플러터 개발자 분들을 만났는데 조별로만 이야기를 나누고 헤어지게 되어 아쉬웠습니다. 언제 또 이런 규모로 플러터 개발자 분들을 만나게 될까요

저는 현재 다니던 회사를 퇴사하고 이직할 회사에 대기 중이라 명함이 없는 상태로 참여하게 되어서, 급히 명함을 만들었답니다. 하지만 밋업날 배송이 안와서 명함을 못드려 슬퍼서 이제야 공유합니다. qr은 링크드인으로 연결되니까 혹시 저와 소통하고 싶은 분은 이 qr찍어서 일촌 신청 보내주시면 감사히 받겠습니다. 밋업에 가신 분들이나 못가신 분들도 환영입니다! 긴 후기 읽어주셔서 감사합니다 :)