끄적끄적/회고록

Adios 2022 (Part 1. 회사편)

DevOwen 2022. 12. 30. 03:19

https://www.brinknews.com/what-will-be-the-greatest-challenge-of-2022/

올 해도 어김없이 한 해가 마무리가 되는 시점이 왔다. 나는 연례 행사로 연말에 한 해를 정리하면서 회고록을 쓴다. 올 해도 마찬가지로 2022년 회고록을 써보려고 한다. 정리를 하다 보니 내용이 많아서 Part 1. 회사편, Part 2. 개인편 으로 나누어서 회고를 작성해 보려고 한다.

지난 회고록이 궁금하다면?

올해 여름 회사에서 프로필 사진을 다시 찍었다.

2년 사이에 참 많이 변한 나 ㅋㅋ

Table of contents

DropBox Career Framework SWE 2 기준표 점검

  • 잘 한 부분
  • 잘 못한 부분

프로덕트 (Product)

  • 비대면진료 서비스
  • V4 전사 마이그레이션
  • B2B 웹
  • B2C 모바일

비즈니스 (Business)

  • 시리즈 A 투자 유치
  • 안드로이드 의료 카테고리 1위! (앱스토어는 2위)
  • 전국 5,000처 이상의 병원에 굿닥 태블릿이 설치되다.

성장 (Growth)

  • Frontend (React)
  • Mobile (React Native)
  • 코드 리뷰
  • 브라운 백 세미나
  • 북 스터디

재택근무 그리고 워케이션

  • 내가 생각하는 재택근무의 장점과 단점
  • 10월 2주간 다녀온 부산 워케이션
  • 앞으로 해보고 싶은 근무제도

 

Dropbox Career Framework SWE IC2

💡 I am prolific at delivering resilient and sustainable software projects from design to implementation and rollout.

나는 탄력있고 지속가능한 소프트웨어를 디자인부터 구현, 출시까지 전달하는 역할에서 많은 결과를 낸다.

작년 말 세웠던 목표 중 하나로 Dropbox Career Framework 에 나와있는 엔지니어의 역량을 측정하는 기준을 바탕으로 IC2 정도의 수준 (약 2~5년의 경력을 가진 mid level engineer)을 달성하는 것을 도전해 보기로 마음 먹었다. 미국의 큰 회사들은 대부분 자사의 엔지니어 역량 기준표가 있지만, 지금 우리 회사는 이 기준표가 없어서 나름 업계에서 잘 알려진 회사의 기준표를 가지고 측정해 보기로 했다.

한 해 동안 내가 회사에서 업무를 하면서 이 기준표에 따라 잘한 것, 보통, 잘 못한 것을 나누어 보았다. 따로 매니저나 선임에게 평가를 받거나 하지는 않았고(공식적인 것이 아니었기 때문) 셀프 평가를 했다. 이 기준 표에 따라 내가 잘 한 부분과 잘 못 한 부분을 나누어 이야기 해보고자 한다.

잘 한 부분

  • [Scope] I execute defined projects to achieve team-level goals. 나는 정의된 프로젝트를 실행해서 팀 수준의 목표들을 달성한다.
  • [Collaborative Reach] I work primarily within the scope of my team with high-level guidance from my manager/TL. 나는 나의 매니저/테크 리드로부터 높은 수준의 가이드를 받아 내 팀 안의 범위 내에서 주로 업무를 한다.
  • [Result > Impact] I work with my manager to direct my focus so my work advances my team's goals. 나는 나의 집중을 위해 매니저와 함께 협업하며 나의 작업은 나의 팀 목표들에 다가가게 만든다.
  • [Result > Impact] I effectively participate in the core processes of my team, including recommending and implementing process improvements. 나는 프로세스 개선을 추천하고 수행하는 것을 포함하여, 나의 팀의 주요 프로세스에 효율적으로 참여한다.
  • [Results > Ownership] I follow through on my commitments, take responsibility for my work, and deliver on time. 나는 나의 헌심을 통해 따르며, 나의 작업에 책임감을 가지고, 시간 안에 전달한다.
  • [Results > Ownership] I proactively identify and advocate for opportunities to improve the current state of projects. 나는 프로젝트의 현재 상태를 개선하기 위한 기회들을 능동적으로 확인하고 지지한다.
  • [Results > Ownership] I own my failures and learn from them. 나는 실패를 소유하고 그들로부터 배운다.
  • [Direction > Innovation] I ask questions and contribute to new ideas/approaches. 나는 질문하고 새로운 아이디어나 접근에 기여한다.
  • [Talent > Personal Growth] I have self-awareness about my strengths and areas for development. 나는 개발을 위한 나의 강점과 분야를 스스로 잘 알고 있다.
  • [Talent > Personal Growth] I drive discussions with my manager about aspirational goals and seek out opportunities to learn and grow. 나는 나의 매니저와 열망있는 목표들에 관한 의견들을 도출하고 배우고 성장하는 기회들을 찾는다.
  • [Culture > Collaboration] I can effectively collaborate to get work done. 나는 효율적으로 협업하여 일이 마무리되게 할 수 있다.
  • [Culture > Organizational Health] I contribute to a positive sense of community on the team (e.g. engage in team lunches, team offsites, and other group activities, help with new-hire on-boarding). 나는 팀에서 공동체에 긍정적인 감정들에 기여한다. (팀 런치를 열고, 팀 오프사이트를 하고, 그룹 활동을 하고, 신규 입사자의 온보딩을 돕는 등)
  • [Culture > Communication] I share relevant information on my projects to my manager, team and customers. 나는 나의 프로젝트와 관련된 정보를 나의 매니저, 팀, 그리고 고객에게 공유한다.

잘 못한 부분

  • [Result > Decision Making] I Identify and gather input from others and consider customer needs to make informed and timely decisions. 나는 다른 이들로부터 인풋을 확인하고 모으고 고객 니즈를 고려하기 위한 충분한 정보와 시간 내의 결정을 한다.
  • [Talent > Hiring] I am able to represent my team’s initiatives and goals to candidates in a compelling way. 나는 나의 팀 계획과 목표를 후보자에게 설득력있게 나타낼 수 있다.
  • [Talent > Development] I offer honest feedback that is delivered with empathy to help others learn and grow. 나는 정직한 피드백을 제공하여, 이것이 공감을 이끌어 내고 다른 사람들을 배우고 성장하는데 돕게 한다.
  • [Craft > Software Design] I’m able to understand the existing designs and technology choices within my area, and I make appropriate adjustments to existing designs when necessary. 나는 나의 분야에서 기존의 디자인과 기술 선택을 이해할 수 있고, 필요 시에 기존 디자인에 적절한 수정을 가할 수 있다.

 

프로덕트 (Product)

한 해 동안 굿닥에서 다양한 프로덕트를 맡아서 기여를 했다. 굵직했던 프로덕트 및 사건들을 중심으로 서술해 보면 다음과 같다.

비대면 진료 서비스

내가 속한 스쿼드(하나의 제품을 담당하는 조직을 우리는 스쿼드라고 부른다)에서 비대면 진료 서비스를 직접적으로 개발하지는 않는다. 다만 올해 2월 오미크론이 전국에 빠르게 확산되면서, 비대면 진료 서비스를 빠르게 출시하는 것이 전사적으로 굉장히 중요하고 시급한 목표가 되었던 적이 있었다. 이 때 우리 스쿼드에서도 비대면 진료 서비스 출시를 위해 같이 노력했고, 나는 약사분들을 위한 B2B 웹 어플리케이션을 만들었다.

인상적이었던 점은, 우리는 환자들이 비대면으로 진료를 받고 발급받은 처방전의 정보들(환자 정보, 처방 약 목록, 약국 정보 등)을 빠르게 불러와서 약사분들께 전달을 드려야 하는 과제가 있었는데 이 목표를 위해 OCR을 고민했던 적이 있었다. 단순하게 생각해서 처방전을 스캔해서 필요한 정보들을 딱딱 받아서, 약국에 보내주면 굉장히 효율적일 것 같았다. 다만 여러가지 기술적인 이슈들이 있었고, 결국 오퍼레이션으로 초반에는 처방전과 약국을 매칭하는 방향으로 가게 되었다. 이 때 느낀게 두 가지 정도 있었는데

  1. 어떤 기술을 도입하고자 할 때 그걸 도입했을 때 장점보다는 단점, 한계를 잘 찾는게 더 어렵고 더 중요하다.
  2. 어떤 문제를 푸는 방법에 꼭 기술적인 해결을 통한 방법만 있는 것이 아니고, 기술이 항상 정답이 되는 것도 절대 아니다.

V4 전사 마이그레이션

작년 말부터 올해 상반기까지 전사적으로 기술 부채를 청산하고 모든 웹, 앱, 서버, 데이터 등을 새로 만드는 마이그레이션 작업을 진행했었다. 이 시기에 사실 나도 스트레스를 굉장히 많이 받았었고, 회의감도 많이 들었었는데 가시적으로 뭔가가 좋아지거나 새로운 기능이 나오는 것이 아닌데 너무나도 고려해야 할 것들이 많고 힘들었기 때문이다. 작업자가 모두 퇴사한 레거시를 하나하나 파악하고 문서를 뒤져가며 찾는 작업은 피곤하고 지루했다. 그나마 내가 맡은 웹은 좀 나은 편이었는데, 다른 파트는 엔지니어 분들이 훨씬 더 스트레스를 많이 받으셨고 실제로 이 과정에서 퇴사하신 분들도 상당히 계셨다.

전사 마이그레이션은 결국 4월 경 마무리가 되었고, 한 5월까지는 안정화 작업을 계속 했던 것 같다. 그리고 내가 속한 스쿼드 제품(태블릿을 통한 병원의 진료접수를 디지털화 하는 제품)의 마이그레이션은 그 이후로 별도의 기간을 거쳐서 진행이 되었는데 그 작업은 8월 정도 시작해서 12월에 온전하게 마이그레이션이 끝났다.

22년 8월 V4 태블릿 마이그레이션 첫 병원 설치 성공한 감격의 순간

이 마이그레이션은 회사 전체적으로도 굉장히 중요한 마일스톤이었는데, (예상한 것보다는 늦어졌지만) 그래도 연말에 마무리를 잘 할 수 있어서 너무나도 다행이고 감사하다. 마이그레이션을 통해 내가 깨달은 점을 두 가지 정도 적어보면,

  1. 개발을 하면서 히스토리 관리, 복잡도 관리, 퇴사자 인수인계 등 개발과 직접적으로 연관이 없고 일정상 미뤄지기 쉬운 요소들을 소홀히 하면 나중에 스노우볼이 되어서 깔릴 수가 있으니 작은 규모, 단계일 때부터 잘 컨트롤을 해야 한다.
  2. 내가 생각하기에 불가능 하다고 여겨지는 일들도 좋은 동료들을 만나서 같이 한 마음으로 한다면 이루어 낼 수 있다.

B2B 웹

내가 올 한해 가장 많은 기여를 한 프로덕트이다. 병원이 굿닥의 여러가지 서비스를 사용할 때 쓰는 웹 어플리케이션으로 프로덕트 명은 파트너스(Partners)이다. 병원이 환자들과 연결될 수 있게 환자에게 문자메시지/알림톡을 보내거나, 리뷰를 보고 댓글을 달거나, 접수 통계를 확인하는 등의 기능들로 이 서비스를 사용한다. 기존에 이 제품이 V3 버전으로 있었는데 이걸 작년 말부터 해서 올해 4월 마이그레이션 때 V4로 재작성을 했다. 처음에는 나와 같은 스쿼드 소속이었던 프론트엔드 개발자 분 한 분하고 둘이서 같이 만들다가, 그 분이 퇴사를 하시고 회사의 다른 프론트엔드 개발자 분들도 기능을 추가하면서 지금은 거의 7~8명 이상이 같이 만들고 있는 회사의 메인 프로덕트가 되었다.

파트너스 서비스의 홈 화면

B2C 모바일

올해 9월 경부터 모바일 앱 개발을 병행하게 되었다. 우리 회사는 모바일 앱이 React Native로 되어 있는데(올해 V4 마이그레이션을 하면서 기존에 네이티브 스택에서 전환했다) 아무래도 내가 React를 해왔어서 그런지 큰 어려움 없이 온보딩 해서 작업을 할 수 있었던 것 같다. React와 비슷한 점이 많아서 편하게 개발을 할 수 있는 장점도 있었지만, 반면에 환경 설정도 처음에는 많이 시간을 잡아먹었고, 속성 요소들도 다르고(ex. 웹에서 div, section 같은 태그들을 썼다면 앱에서는 View, ScrollView, FlatList 같은 요소들을 쓴다) 테스트도 모바일 폰과 시뮬레이터로 하다보니 낯설었다. 두 세달 정도 열심히 적응한 결과 지금은 모바일 개발자들 대비 0.7~0.8인분 정도는 할 수 있게 된 것 같다.(내 추측?)

굿닥 모바일 앱 - 내가 처음 작업한 마이 페이지 > 리뷰 페이지

 

비즈니스 (Business)

나는 엔지니어다보니 비즈니스적인 감각이 부족하고 지식도 부족해서 여기서 막 전문적인 이야기를 담을 수는 없지만, 한 해 동안 회사가 비즈니스적으로 얼마나 성장했는지를 옆에서 지켜보면서 느낀 점들 위주로 공유해 보려고 한다.

시리즈 A 투자유치

출처 : 플래텀

아무래도 우리 회사에서 올 한 해 있었던 가장 큰 성과를 꼽으라면 시리즈 A 투자 유치가 아니었을까 싶다. 작년부터 시리즈 A 투자 유치를 준비해 왔고, 예상보다 투자 라운드를 클로징하기까지 시간이 길어지면서 나도 많이 힘들었는데 대표님들이나 다른 구성원 분들은 얼마나 더 힘들었을지 감히 헤아릴 수 없을 것 같다. 내가 사실 이 투자를 받는데 얼마나 기여를 했는지?는 모르겠지만 ㅎㅎ 회사가 물적분할을 한 후 첫 투자 유치까지 함께 전 과정을 하면서 이루어낸 첫 성과여서 너무나도 기쁘고 뿌듯했다. 앞으로 더더더 성장하는 회사를 만들어 가고 싶다.

안드로이드 의료 카테고리 1위! (앱스토어는 2위)

모바일 앱 서비스를 만들면서 모든 사람이 그렇겠듯이, 많은 사람들에게 사랑받는 서비스를 만들고 싶은 마음이 당연히 클 것이라고 생각한다. 나도 마찬가지였다. 사실 굿닥이라는 앱이 플레이스토어나 앱스토어에서 상위권을 차지하는 앱은 아니었다. 나는 내가 만드는 서비스가 플레이스토어/앱스토어 1위를 찍는 모습을 꼭 보고 싶었고 회사를 다니면서 스스로에게 세운 목표로 세웠다.

22년 3월 구글 플레이스토어 기준으로 의료 카테고리 1등을 했다.

올해 2월 오미크론이 터지면서 비대면 진료에 대한 수요가 폭등하고, 이 힘을 받아(?) 많은 사람들이 굿닥을 설치하고 사용하기 시작했다. 사실 아플 때 찾는 앱이라 많은 사람들이 쓴다는 것이 꼭 좋은 일이라고 보기는 어렵다. 그럼에도 3월 즈음에 우리 앱이 구글 플레이스토어 의료 카테고리에서 1등을 찍었을 때 너무 기쁘고 뿌듯했다. 앱스토어도 계속 모니터링 했는데 안타깝게도 2위가 최고 순위였다. 이 글을 쓰는 시점에서는 조금 내려가긴 했지만, 앞으로 또 높은 순위를 찍을 수 있도록 더더더 좋은 앱을 만들어 봐야 겠다.

전국 5,000처 이상의 병원에 굿닥 태블릿이 설치되다.

내가 속한 스쿼드는 병원과 환자를 연결하여 진료, 접수를 하는 과정을 편안하고 쉽게 만드는데 노력하고 있다. 스쿼드에 여러가지 중요한 비즈니스적인 목표가 있는데 그 중의 하나인 병원 5,000처에 굿닥 태블릿을 설치하고 연결하는 마일스톤을 연말에 이룰 수가 있게 되었다. 이 목표를 달성하기 위해서 스쿼드의 PO를 비롯해서 개발, 디자인, QA, 영업, 사업개발 등등 모든 구성원 분들이 정말정말 고생을 많이 하셨는데 달성할 수 있어서 너무 기쁘고 다행이라는 생각이 든다.

 

성장 (Growth)

올 한해 회사를 다니면서 개인적으로 참 많은 성장을 했다. 몇 가지 공유를 해 보려고 한다.

Frontend (React)

회사에서 두 개 정도의 큰 프론트엔드 레포를 처음부터 만들고 관리했다. 기술 스택은 둘이 거의 동일하게 React, TypeScript, Next.js로 가져갔다. 초반에는 Atomic Design Pattern을 가지고 컴포넌트들을 만들다가, 경계가 불분명해지고 조금씩 관리가 어려워지면서 context에 로직을 담고, View에는 UI만 담는 구조로 역할을 분리했다.

graphql 스키마를 매번 직접 프론트엔드에서 작성해 주면서 백엔드의 수정사항들을 즉각적으로 반영하지 못하고 최신화가 안되는 문제가 지속적으로 발생해서 동료의 추천을 통해 codegen을 도입했다. 정말 편하고 생산성이 올라갔다. 무엇보다 백엔드에서 배포된 수정사항을 프론트에서 별도로 작업해 주지 않아도 알아서 모니터링 해주게 되어서 좋다.

한 해동안 처리했던 이슈들 중에서 어떤 부분에서 시간을 많이 잡아먹었나 돌이켜보면, 비동기 처리 이슈가 아니었을까 싶다. 재현하는 과정도 쉽지가 않을 때가 많고 디버깅도 까다롭기 때문이다. 올 해 동료들의 도움을 받아서 여러 가지 디버깅 도구들을 바탕으로 디버깅을 잘 하는 방법들에 대해서 배울 수 있었던 것 같아서 감사하다.

백엔드에서 API를 만들어 줄 때 어떻게 하면 프론트엔드가 받기 편한지(?)에 대한 고민을 해본 적이 지금까지는 별로 없었던 것 같다. 그동안 그냥 만들어 준 대로 (아무 생각 없이) 썼던 적이 대부분이었다. 지금 돌이켜보면 이 의사결정 과정도 백엔드에서 직접 하는 것이고 이 과정에서 프론트엔드에서 의견을 주는 것이 서로에게 큰 도움이 될 수 있다는 사실을 깨달았다.

Mobile (React Native)

모바일은 아직 작업을 시작한지 2~3달 정도 된 시점이라 엄청 숙련되었다고 보기는 어렵지만, 그래도 나에게 새로운 무기가 하나 더 생긴 것 같아서 기쁘다. 지금은 신규 기능 추가, 버그 픽스 정도의 역할만 할 수 있고 아직 네이티브 영역의 코드를 수정하거나, 인프라 관련된 트러블슈팅을 하는 것까지는 조금 무리이다. 내년에는 모바일에도 더 숙련된 개발자가 되고 싶다.

웹을 만들 때보다 모바일을 만들 때 더 사용성을 중요하게 체크하게 되었던 것 같다. 웹에 비해서 아무래도 작은 화면에 비슷한 양의 정보를 담아야 하기 때문이다. 그러면서 동시에 웹이 모바일의 사용성을 따라가기도 참 어렵다는 것을 깨달았다. 내년에는 웹도, 모바일도 더 나은 사용성을 가질 수 있기 위한 여러가지 방법들을 공부해 보고 싶다.

코드 리뷰

프론트엔드 개발자 분들과 코드 리뷰를 지속적으로 꾸준하게 하려고 노력한다. 코드 리뷰의 목적은 리뷰 자체가 아닌 좋은 코드베이스를 유지하는 것이라고 생각한다. 코드 리뷰 없이 좋은 코드베이스를 유지할 수 있으면 코드 리뷰가 필요 없다고 생각하며, 지금 우리 조직은 아직 그정도 수준은 아니기 때문에 꾸준하게 코드리뷰를 하려고 노력한다.

사람마다 정말 생각하는게 천차만별이라는 것을 코드리뷰를 하면서 느꼈다. 그래서 아키텍처와 관련된 싱크를 자주 하려고 노력했다. 좋은 코드베이스가 유지되려면 구성원들이 모두 합의한 컨벤션에 대해서 올바르게 이해하고 있고 왜 그걸 지켜야 하는지 인지하고 있어야 한다. 그러려면 맞춰질 때까지는 자주, 지겹도록 싱크를 맞춰야 함을 깨달았다.

좋은 코드로 파편화 되어 있는 것보다 조금 별로이더라도 일관된 컨벤션으로 모든 코드베이스가 맞춰져 있는게 여러 가지 측면에서 유리하다는 것을 깨달았다. 기존에 나는 좋은 개선을 누군가가 제안하면 그걸 가능한 수용하려고 했었던 것 같은데, 이제는 그 제안이 아무리 좋더라도 기존 컨벤션을 깬다면 조금 더 심사숙고해서 결정을 해야 한다는 것을 알게 되었다.

브라운 백 세미나

올해 가을부터 회사에서 엔지니어들을 대상으로 격주에 한 번씩 브라운 백 세미나(Brown Bag Seminar)를 주최하게 되었고 이 모임(?)을 주관하는 역할을 맡게 되었다. 주제는 엔지니어들이 관심이 있을 만한 아.무.주.제 나 가능하다. 나는 아래의 주제들을 가지고 발표를 했다.

보통 열명 내외의 엔지니어 분들이 참여를 해 주시고, 나보다 시니어이신 분들이 훨씬 더 많다. 사실 내가 발표를 하지만, 다른 동료분들이 의견을 주시는 것들을 들으면서 내가 배우는 것들이 훨씬 더 많다고 느낀다.

북 스터디

회사 동료들과 <구글 엔지니어는 이렇게 일한다> 라는 책을 가지고 회사에서 북스터디를 진행하고 있다. 책이 두꺼워서 지금 3달째 하는데도 아직 진행 중이다. 구글의 엔지니어링 문화가 정답이라고 볼 수는 없지만, 그래도 이 책을 읽으면서 배우는 점들이 많아서 유익하다. 책에 대한 내용은 읽으면서 계속 블로그에 정리를 해 보려고 한다.

 

재택근무 그리고 워케이션

내가 생각하는 재택근무의 장점과 단점

올 한 해 코로나로 인해 재택근무를 많이 했다. 나의 경우 사무실에 출근하는 것이 더 집중이 잘 되고 업무 효율이 좋아서 주로 사무실 출근을 선호하는 편이다. 그리고 또 회의가 많으면, 사무실에 나오는 편이다. 보통 일주일에 한 두 번 정도씩 재택을 하는데 내가 생각하는 재택근무의 장점과 단점은 다음과 같다.

  • 장점
    • 체력적으로 지쳐있을 때 에너지를 조금 아낄 수 있다. (출퇴근 시간과 에너지, 사무실에 있을 때 발생하는 인터럽트 등)
    • 심리적으로 편안하고 컨디션 관리에 도움이 된다.
    • 본인이 필요한 경우, 더 온전하게 혼자 몰입할 수 있다.
  • 단점
    • 재택을 오랜 기간 하면 업무에 집중도가 떨어지게 되는 경향이 있다.
      • 이러한 이유로 나는 왠만하면 재택은 이틀 이상 하지 않는다.
    • 커뮤니케이션의 심리적인 허들이 높아진다.
      • 예컨데, 옆자리에 앉은 동료에게 5분이면 물어볼 수 있는 질문을 슬랙이나 구글 밋으로 하려면 답변을 기다리고 회의를 잡는 비용이 들어간다.
    • 회사의 업무 분위기 속에서 같이 몰입하기가 상대적으로 어렵다.

10월에 2주간 다녀온 부산 워케이션

회사에서 부산 오피스가 생기고, 2주간 부산에서 일을 할 수 있는 기회가 있어서 10월 중 부산에 워케이션을 다녀왔다. 워케이션 관련해서는 별도의 블로그에 정리해 놓았다. 결과적으로 만족스러웠지만, 아쉬움도 많이 남았던 것 같다. 조금 더 저렴하게 갈 수는 없었을까? 조금 더 많은 것들을 보고 느끼고 올 수는 없었을까? 등등으로.

앞으로는 조금 더 자주, 더 길게 워케이션을 가고 싶고 가서 더 다양한 것들을 많이 해보고 오고 싶다. 예를 들어 나는 서울이라는 대도시에 살고 있는데, 굳이 워케이션을 도시로 갈 필요는 없다고 생각한다. 내가 여기서 하지 못하는 것들을 더 많이 할 수 있는 곳으로 가서 사는 것이 의미가 있다고 생각한다.

앞으로 해보고 싶은 근무제도

한 달씩 또는 몇 달씩 다양한 지역의 집을 단기 렌트해서 돌아다니면서 살고 싶다. 우리나라에서 한 달씩 단기 렌트를 (합리적인 가격으로) 할 수 있는 곳이 얼마나 있는지는 알아봐야 하겠지만… 진짜 와이파이만 잘 터지고, 주변에 최소한의 인프라가 갖춰진 곳이라면 가서 살면서 생활하면서 원격근무를 이어 나가보고 싶다. 국내에서 익숙해 지면, 해외로 나가서도 이렇게 주기적으로 돌아다니면서 현지 삶을 사는 디지털 노마드로 일을 해 보고 싶다.

22년 12월, 체크인 스쿼드에서 써주신 롤링페이퍼

Adios 2022 Part 2. 개인편 에 이어서...

저작자표시