팀원에서 리더로
올해 4월 팀 리더로써 데이터플랫폼팀을 이끌게 되었다. (정식 발령은 6월)
팀원에서 리더로 바뀌게 되면서 가장 많이 새로운 역량들을 쌓을 수 있는 한 해였다.
내가 업무를 바라보는 관점과 하게된 일들이 크게 바뀌었는데, 어떤 것들이 있었고 그로부터 느낀 점들은 어떤 게 있었을까
팀 분할
연 초부터 올해 8월 상장을 앞두고 쏘카의 일하는 방식은 많이 변했다. 데이터 엔지니어링팀도 그 변화에 따라서 여러가지 변화를 시도했는데, 가장 먼저 했던 변화 중 하나는 팀을 분리하는 일이었다.
기존의 데이터 엔지니어링팀은 7명으로 한 팀에서 다루는 일의 가짓수가 매우 다양했다. 어떤 사람은 지표 작업, 누군가는 완전히 백엔드 개발, 또 누군가는 모니터링을 위해서 빅쿼리 로그를 뒤지고 있었다. 많은 컨텍스트가 필요하고 각자의 작업이 깊이가 있는 일들이라 서로 하는 일에 대해서 공유가 어려웠고, 각자의 배경도 달랐다 (BI 엔지니어 출신, DBA 출신, 개발 베이스 등등). 하나의 분야에 팀원들이 전문성을 키워나가기 쉽지 않다고 생각했기 때문에 데이터 웨어하우스와 데이터 플랫폼팀으로 나누어져서 일을 하기 시작했다.
데이터 웨어하우스 팀은 사내의 데이터를 조회하는 데이터 웨어하우스를 더 사용하기 쉽게 만들어주고 원하는 데이터를 찾아볼 수 있는 마트나 데이터를 적재 및 정제하는 일에 집중을 하기로 했다. 데이터 플랫폼팀은 DW팀과 본부 내의 여러 팀들이 사용하는 서버와 그에 필요한 인프라를 고도화하는 팀으로 나누었다. 그에 그치지 않고 데이터를 활용한 애플리케이션들을 설계하고 개발, 운영까지 하는 팀이기도 했다.
나는 데이터 플랫폼 팀에서 더 집중할 수 있는 환경을 가져갈 수 있을 거라고 생각이 들어서 데이터 플랫폼팀에서 한 해를 시작했다.
스프린트부터 TLM까지
팀이 나누어지면서 DP팀은 좀 더 '개발팀' 처럼 일할 수 있는 환경이 되었다. 모두 개발 베이스의 지식들을 가지고 있었고, 하는 업무들도 데이터 분석가와 같은 쿼리 요청의 업무 보다는 새로운 시스템을 설계하고 개발하는 업무들이었다.
쏘카 내의 개발팀의 방향성과 같이 우리도 애자일에서 말하는 스프린트 기반의 일하는 방식들을 채택했다.
기존에는 제너럴한 칸반 형식으로 일감을 우리가 알아서 가져오고, 공유만 하는 형태로 이루어져서 개발팀 보다는 ad-hoc 성 태스크가 많은 데이터 분석이나 bi 엔지니어 팀에게 어울리는 방식으로 일을 하고 있었다.
스프린트 방식은 생각보다 많은 고민들을 하게 되었다. 왜냐하면 우리는 PM이 따로 없는 팀이어서 모든 태스크를 우리가 스스로 정리, 관리 및 실행해야 했기 때문이다. 기존에는 큰 일감이던 작은 일감이던 그냥 하나의 일감으로 치고 오래 걸리면 오래 걸리는 대로 수행했다. 유저 스토리나 스토리 포인트, 인수 조건 등등 태스크를 애자일 스럽게 정의하기 위한 고민들의 연속이었다.
올해 초는 이런 우리가 일하는 방식과 왜 일하는 지에 대해서 고민했다.
그 중 산드로 만쿠소의 소프트웨어 장인이라는 책이 기억에 남고 지금도 많은 울림을 준다.
소프트웨어 장인 7장 중에서
•
일하는 방식을 바꾸기 전에 우리가 어떤 상황에 놓여있는지 파악하는 것은 대단히 중요하다
•
어떤 실행 관례들이 정말 효과 있는 지 없는 지 알기 위해서는 그에 대한 명확한 전략을 정의해야한다
•
실행 관례가 효율적이려면 반드시 모든 팀 구성원들에 의해서 그 가치가 납득되어야 한다
•
팀 구성원들이 원활한 정보 소통, 빠른 피드백, 빠른 결과물 생성, 실수 예방, 고객 만족, 최선을 다하지 못하거나 배우지 못하는 것에 대한 부끄러움을 느낄 줄 아는 것 이러한 것들에 가치를 느껴야한다
팀에서는 이전에는 없던 다양한 프로세스와 틀들을 만들기 전에 정말 많은 고민과 논의를 통해서 결정을 했다 (그로 인해서 피로도가 많이 쌓였었지만).
3월 쯤 4명의 팀원 중 하디가 나가기로 결정한 다음 부터 여러 변화의 바람이 불기 시작했다. 토마스는 우리 팀의 팀장을 겸하고 계셨지만 그룹장 역할을 담당하시면서 우리 팀 뿐만 아니라 더 넓은 시야를 바라보셔야했고, 한 명의 공석은 커 보였다. 그 즈음 나는 학교를 돌아갈지, 아니면 커리어를 계속 해야할지에 대한 고민을 하고 있었다. 커리어를 계속하기로 결정한 순간, 이왕 이렇게 된거 새로운 도전들을 해보면 좋겠다는 생각이 들었다. (옆에서 카일의 조언도 있었다. 감사합니다.)
그래서 팀장 역할을 해보기로 자원했다.
(쏘카에서 팀장의 역할은, 대부분의 한국의 스타트업들이 그러하듯, 엔지니어링 매니저보다는 테크 리더에 가까웠다. 실무를 놓을 수는 없고 그러는 와중에 매니저 역할도 해야한다. 굳이 따지자면 Tech Lead Manager)
지르고 생각했지만 날이 갈 수록 두려운 마음이 컸다. 객관적인 눈으로 봤을 때는 아직 3년차 밖에 되지 않았고 팀장의 완장을 찬다는 것은 지금까지 성장해온 속도와 방향성에 큰 제동을 걸 수도 있는 결정일 수 있다는 생각이 들었기 때문.
어떤 팀을 만들고 싶으신가요?
제일 먼저 세운 팀장으로서 나의 목표는 '내가 같이 일하고 싶은 매니저 되기'였다. 하지만 그 마저도 모호했다. 내가 같이 일하고 싶은 매니저가 어떤 모습인지 명확할 정도로 매니저와의 경험이 그렇게 많지 않았기 때문인 거 같다. 그저 마이크로매니징 하지 않고 자유를 보장하고, 믿어주는 거 정도? 이것만으로는 부족하다고 느꼈다.
그럼 내가 어떤 팀장이 되어야할까? 애초에 우리 팀에 지금 부족한 건 무얼까? 그 부족한 걸 내가 메울 수 있게 하려면 무엇이 필요할까?
이런 고민들이 머리속에 가득할 때, 코칭을 해주고 계셨던 카일이 해준 질문이 머리에 강하게 남았다.
"어떤 팀을 만들고 싶으신가요?"
그때 이 질문에 나는 어영부영 대답했었다. 그냥 눈 앞에 보이는 문제점들을 나열해가면서 방향성 보다는 현상을 늘어놨다. 하지만 그 순간에도 이 질문에 나는 그 누구보다 잘 답할 수 있어야 한다고 생각했다.
그 후로 몇 개월간은 이 질문에 대한 답을 찾아갔다.
먼저 팀원들이 하고싶은 게 무엇인지 원온원 미팅에서 파악해봤다. 각자 다른 고민 속에서 팀에서 그 고민들을 해결해줄 수 있는 것은 무엇인지, 해결할 수는 없지만 답을 찾을 수 있도록 도와줄 수 있는 것은 무엇인지 알아가는 과정이었다.
(5월 회고)
월말 마다 회고도 계속했다. 초반에는 내가 계속 팀원으로 일하려는 관성 때문인지 여유가 많이 없어서 인위적으로 내 시간의 1시간 내지는 2시간을 '팀장의 고민'이라는 시간으로 뒀다. 이 시간 동안 하던 일을 멈추고 팀에 무엇이 필요한 지, 내가 잘하고 있는 것과 못하고 있는 것은 무엇인지 되돌아 봤다.
여러 글들과 대화를 통한 인사이트들도 컸다. 카일의 팀장에 대한 글은 이전에도 읽었지만 나도 팀장이 된 다음 훨씬 더 공감하며 재미있게 읽었다. 오랜만에 만난 희창님과의 티타임은 언제나 처럼 나는 아직 갈 길이 멀구나, 그리고 나도 이 분 처럼 오래 재미있는 개발을 하고 싶다는 뽐뿌를 가득 안게 해줬다 (얼마전에 요런 글도 올라왔는데 그 때 이야기한 것들이 생각이 나서 또 재밌게 봤다). 토마스와의 중간 중간 원온원 미팅도 큰 위안이 되었다. 누구보다 우리 팀원들과 팀에 대해서 잘 이해하고 계시고 그 중간에서 내가 느끼고 있는 감정들과 고민들을 미리 겪어 보셨을 토마스는 내가 길을 잃지 않도록 언제나 잘 이끌어 주신다.
책도 많은 도움이 됐다. 그 중에서 제일은 아무래도 개발 7년차, 매니저 1일차 였다. 개발 베이스의 사람이 매니저로써 해야하는 고민들과 질문들, 그리고 가장 중요한 모든 고민들에 대한 답인 '결국 너 자신을 잘 매니징해야 다른 사람들도 매니징할 수 있다' 라는 아주 산골에 숨어사는 선인과 같은 교훈도 줬다 (비꼬는 거 아님). 매니저만을 위한 책은 아니지만 구글 엔지니어는 이렇게 일한다 도 정말 테크 포지션들의 바이블이라고 할 정도로 깊은 내공이 가득한 책이었다. 늘 결정하라, 늘 떠나라, 늘 확장하라 (Always Be Deciding, Always Be Leaving, Always Be Scaling) 라는 문구가 떠오른다. 그리고 두려움 없는 조직도 띄엄띄엄 읽었지만 매력적인 조직을 만드는 데 필요한 두려움이라는 가드레일을 없애기 위해 어떻게 행동해야하는 지 알려주었다.
그래서 나는 어떤 팀을 만들고 싶었는가?
나는 '내가 답할 수 없다' 라고 생각했다.
비전 세팅하기
6월이 되면서 팀원들이 많이 충원됐다. 세레나는 타 팀에서 우리 팀의 업무를 해보고 싶으셔서 겸직으로 참여하시게 됐고, 루디 피글렛 누즈는 신규 채용을 통해서 우리 팀에 합류했다 (그리고 한 분이 더 계셨지만, 있었는 데 없어지셨다... 잘 지내시나요...?). 팀원이 많아지면서 고민도 배가 됐다. 어떤 팀을 만들어야 할까.
그러던 고민이 커지던 와중에 딜리버리 히어로의 Manifesto를 보게 됐다. 누군가는 이걸 팀에서 운영하는 서비스의 신뢰성을 지키기 위한 원칙들로만 보겠지만, 내 눈에는 그 조직의 문화와 가고자 하는 방향, 그리고 어떤 팀이다 라는 아이덴티티를 가득 담고 있는 문서라고 보였다.
그래서 나는 신규 팀원들이 들어와 친해질 겸 워크샵 자리에서 이런 매니페스토와 우리의 비전을 만들어 봐야겠다 라고 생각했다. 팀 비전은 이전에 존재했지만, 구성원들이 다 채워지기 전에 만들어 져서 우리의 의도를 다 표현해내지 못했고, 우리가 어떤 팀으로 만들어가고 싶은지 이야기를 하는 자리가 필요했다.
(이럴 땐 아날로그가 낫더라)
비전 세팅
1.
각자의 커리어에서 중요한 가치들은 무엇인가요?
2.
비슷한 가치들 카테고리화 하기
3.
각자의 가치를 실현하려면 우리 팀은 무엇을 해야할까요?
4.
공통의 가치들을 모두 포함하는 한 마디 정하기
매니페스토 세팅
1.
비전을 이루기 위해서 팀의 구성원들이 지켜야하는 룰 3가지씩 적어보기
2.
비슷한 것들 끼리 묶기
3.
카테고리별 규칙 정하기
쉬엄쉬엄 워크샵을 통해 우리는 아래와 같은 비전과 매니페스토를 만들었다.
Data Platform Team Vision
쏘카 내부의 데이터 이용자가 비즈니스에 임팩트를 낼 수 있도록 소프트웨어 엔지니어링에 기반하여 문제를 해결합니다.
We solve problems based on software engineering so that data users in the company can make significant impacts on business side.
Data Platform Team Manifesto v1.1.0
(최근에 한 번 또 리뉴얼 됨, 언젠가 퍼블릭하게 모두 풀 수 있는 날이 오길...)
이 워크샵 덕분에 우리 팀원들 각각이 '어떤 팀을 만들고 싶은 가'에 대한 각자의 대답을 하나로 모을 수 있었고, 나름대로 아직 뚜렷하지 않지만 하나의 화살표가 만들어진 것 같다.
소프트웨어 엔지니어에서 아키텍트로
팀의 방향성을 정하고, 새로운 인원들이 온보딩 후 점차 팀의 업무에 익숙해져 가면서 내가 해야하는 것들이 더 뚜렷해졌다. 팀원들이 업무에 집중할 수 있도록 하나의 태스크보다 더 넓은 차원의 고민들을 해두는 게 내가 할 일이라고 생각했다. 더 자세히는, 1) 기술적 선택의 트레이드 오프 고려하기 2) 각 태스크에서 해야할 코드 내 변경 사항을 더 직관적으로 만들기 3) 장애물 치우기 정도가 될 수 있겠다. 최근 읽고 있는 소프트웨어 아키텍쳐 101 에서 이야기하는 소프트웨어 아키텍트가 하는 일의 서브셋 정도가 되는 일들이다.
스타일 가이드 문서를 만들었다.
파이썬 스타일 가이드는 작년 부터 팀 내에서 만들어졌으나 자주 보고 사용되지는 않았다 (생각나면 들여다 보는 정도?). 나는 스타일 가이드를 한번 더 수정해서 필요한 것들과 필요하지 않은 것들을 골라내고 팀원들의 리뷰를 다시 받았다. 그리고 내가 하는 코드 리뷰를 이 스타일 가이드 문서 기반으로 하기 시작했다. 깃헙 코멘트에서 해당 스타일 가이드의 항목을 레퍼런스 해서 팀원들이 코드 리뷰 내용을 확인할 때 한번 씩이라도 더 스타일 가이드를 읽고 그에 맞는 코드를 작성할 수 있도록 유도했다.
Helm 스타일 가이드는 팀이 가장 많이 사용하는 쿠버네티스 Helm Chart들에 대한 가이드였다. 팀원들이 각자 체크인 하는 레포가 다양했지만 쿠버네티스 상에서 프로비저닝하기 위해서는 꼭 Helm Chart 레포에 등록을 해야했다. 기존에는 Helm 차트는 각 담당자가 알아서 동작하도록 만들고 리뷰도 딱히 없이 main 브랜치에 머지하는 식이었다면, 2000개가 넘는 커밋이 쌓이는 동안 우리 팀 내에서도 Best Practice라 불릴 만한 차트 작성 방법들에 대한 유즈 케이스들이 쌓이기 시작했기 때문이다. 또한 chart-repo-actions-demo 를 참고해서 그 동안 시도했다 실패했었던 Helm 차트에 대한 PR 단계 테스트도 추가했다.
일반적인 툴 설치 가이드와 사용 가이드도 만들었다. Pyenv와 Poetry는 파이썬 프로젝트를 만들 때 우리팀에서 공통으로 쓰는 도구들이다. 기존 툴들에 대비해서 어떤 장점이 있는 지, 왜 이 도구를 우리가 사용하고 있는 지를 가이드에 녹여서 팀원들에 리뷰를 받고, 새 팀원들이 들어올 때 온보딩 목적으로 사용했다. 또한 본부 인원들 전체 대상으로 해당 문서들로 가이딩을 하고 있다.
내년에는 Airflow DAG 스타일 가이드, 코드 리뷰 가이드, 코드 체크인 가이드 등 더 팀에 맞는 우리만의 스타일 가이드 문서들을 추가할 예정
공용 템플릿 레포를 만들었다.
기존에 cookiecutter 기반으로 몇몇 템플릿이 존재했다. 하지만 cookiecutter의 단점은 템플릿의 버전이 올라갔을 때 그 템플릿을 사용한 코드 베이스에 업데이트 사항을 반영하기 굉장히 까다롭다는 점이다. 그래서 그런 단점을 보완한 copier 라는 라이브러리를 베이스로 간단하게 cli 툴로 파이썬+poetry, 메타템플릿 등 생산성을 높혀줄 수 있는 공용 템플릿을 생성할 수 있도록 했다. 하지만 안타깝게도 아직 유즈케이스가 많이 없어서 고민...
팀원들의 반복적인 업무를 줄일 수 있는 툴을 만들었다.
OX 2. 3번 이상 반복되는 작업들은 자동화한다. 팀의 매니페스토에서 처럼 나 먼저 모범을 보여야한다고 생각했다. dailystandup은 아침 마다 팀원들이 슬랙에 오늘 할일들을 공유하는 과정에서 매번 어제 무얼했는지, 그리고 오늘 무얼 할지 리포팅하는 과정에서 이곳 저곳에서 어제 할 일을 찾는게 아니라 따로 데이터베이스에 저장 시켜놔서 불러올 수 있게 하는 간단한 웹 애플리케이션이다. 현재는 구글 캘린더와 지라에서 이벤트와 티켓 정보들을 가져올 수 있게 integration을 만드는 작업을 매일 아침이나 퇴근하고 짬짬히 하고있다. script 레포는 팀에서 자주 사용하는 스크립트들을 더 범용적으로 다른 팀원들도 사용할 수 있도록 추상화하거나 그대로 사용할 수 있는 다양한 오퍼레이션들을 더 편하게 만들기 위해서 만들었다. 팀원들이 반복되는 작업을 할 때 마이크로매니징을 하지 않으면서 이 레포를 찾을 수 있도록 유도하는 과정이 아직까지 어렵지만 유의미한 시도라고 생각한다. 그 외에도 다양한 노력들이 있었지만 아직까지 갈길이 멀다.
코드 리뷰와 컴플라이언스 리뷰를 수행했다.
팀에서는 크게 4가지의 프로젝트를 수행했는데, 나는 이 모든 프로젝트의 코드에 대해서 리뷰를 했다. 주로 스타일 가이드를 잘 지켰는 지, 해당 코드베이스에 적용한 아키텍쳐가 있다면 그 부분을 잘 지켰는 지 등을 리뷰했다. 하지만 이건 단점이 더 큰거 같다. 모든 프로젝트에 대해서 어느 정도 정보와 맥락을 항상 유지해야했고, 스위칭 코스트는 굉장히 컸다. 때문에 내 리뷰가 밀리는 경우가 많았는데, 내년 부터는 스타일 가이드와 아키텍쳐 컴플라이언스 리뷰는 자동화된 테스트로, 나는 코드 스타일이나 디자인 패턴, 퍼포먼스 등 좀 더 세부적으로 코드를 봐야할 때만 리뷰할 수 있도록 시스템을 만들어야 겠다고 느꼈다.
규모가 있는 시스템을 설계했다.
팀에서는 다양한 데이터 파이프라인이나 전반적인 시스템 디자인을 많이 하고 있다. 팀의 비전 처럼 소프트웨어 엔지니어가 잘 해야하는 문제 정의로 시작해서 해결 방법, 그리고 여러가지 고려사항들을 시스템 디자인에서 시작하기 전에 팀 내에서 치열하게 논의할 수 있도록 선례들을 만들고 있다. 아직까지 공유할 만한 케이스는 없는 듯. 내년에 더 신경 써야할 부분.
여러 문서 템플릿들을 만들었다.
runbook, 가이드, 페어워크, Post Mortem, Tech Spec 템플릿 등 다양한 문서들을 팀원들이 쉽게 시작할 수 있는 템플릿들을 만들고, 템플릿에 대한 리뷰 그리고 템플릿을 사용한 문서에 대한 리뷰 절차 등도 같이 정해갔다.
문화를 만들어가는 일
우리 팀에 대해서만 고민하고 바라봐서는 중요한 기회들을 얻어내기 힘들 수 있다고 생각했다. 그래서 주로 많이 협업하게 되는 그룹, 그리고 본부에서 팀원들이 기여할 수 있는 것들을 만들어가고 싶었다. 팀의 문화를 팀 밖으로 영향을 미치는 일이 그 시작이라고 생각했다.
엔지니어링 데이
그룹 내에서 역할이 달라져서 자주 이야기하지 못하는 데이터 웨어하우스 팀과 2주에 한 번 만나서 기술적인 이야기와 발표를 하는 자리다. DW팀도 우리팀도 새로들어온 인원들이 꽤 계셔서 같이 붙어있으면 시너지가 날 수 있다고 생각했다. 이전 회사들에서 경험들을 살려서 이런 시간을 만들어봤다. 고민이 되는 것은 조직의 문화인지 아직 적극적인 공유를 유도하는 게 힘들다. 구성원들이 기술을 좋아하고 다양한 것들을 서로 나눌 수 있게 하려면 어떻게 하면 좋을 지 고민이 많다.
오피스 아워
본부 내에서 엔지니어링 적인 어려움이나 고민들이 생겼을 때 어디를 찾아가야할 지 잘 모르겠다는 피드백들이 있었다. 그래서 2주마다 한 번 자유롭게 혹은 미리 고민들을 올려두면 고민에 대한 해결법이나 같이 고민을 해보는 시간을 가지면 좋겠다고 생각해 오피스아워를 만들었다. 신기하게도 지속적으로 본부 구성원들이 찾아와서 이런 저런 질문들을 해 주시고 팀원들도 그로 부터 자아효능감을 얻는 것 같아서 뿌듯했다. (한 명도 없을 때도 있지만...)
실력이 아닌, 영향력으로 평가 받기
희창님과의 대화에서 기억에 남는 말이었다. 리더가 되면 당신의 실력이 아니라 이끄는 팀의 영향력으로 평가된다. 나는 스스로 굉장히 많은 노력을 하는 엔지니어라고 생각했다. 남들보다 2배 3배 되는 시간을 투자하고 그로 인해서 내가 다뤄봤던 영역에 대해서는 아웃풋이 자신이 있었다. 하지만 이제는 내가 만든 기술적 선택과 코드로 평가받는 게 아니라 나와 팀원들이 만들어 가는 결과물이 나를 평가하는 요소가 된다.
•
관리가 아니라, 결정하기
무엇을 하는 지 관리하고 감시하는 게 아니라, 팀원들의 고민이 있을 때나 트레이드 오프 중에서 차악을 선택해야할 때 결정할 수 있도록 해야한다.
•
내가 하고 싶지만 양보하기
답답하면 내가 뛰는 게 편하다는 내 업무 좌우명이었다. 하지만 그건 이제 자랑이 아니라는 걸 뼈져리게 느낀다. 내가 다 해내려는 태도는 단일 실패점 (SPOF)을 만들었고, 그는 팀에 큰 장애물이 되는 걸 몸소 확인했다. 내가 하면 더 잘 할 수 있다고 생각할 땐 내가 나서는 것 보다 팀원들과 태스크에 대해서 이야기 할 때 시각을 넓혀줄 수 있도록 유도하고 논의하면서 서로 만족할만한 결과물이 나올 수 있도록 하는 연습을 하고 있다.
•
더 확장하기
중요하지 않은 일은 버리고, 중요한 일에 집중해야 한다. 그래야 더 중요한 일들을 많이 해나갈 수 있고, 더 임팩트 있고 재밌는 일들을 해볼 수 있다고 믿는다.
•
아직 풀지 못한 과제
많은 고민을 했지만 첫 술에 배부를 수 없듯이, 부족한 것들이 많이 떠오른다.
팀 내의 우리가 가야할 아이덴티티는 정했지만, 외부에서 바라보는 우리 팀의 아이덴티티가 얼라인되지 않았다. 조직 내에서 더 큰 영향력을 발휘할 수 있도록 내년에는 많은 시도들을 해봐야 한다.
여유도 많이 부족했다. 매니저로서의 역할을 다 하지 못하고 내가 너무 내 일만 하고 있나라는 생각이 들 때가 많았다. 더 매니징을 위한 여유 시간을 두자.
결론적으로 팀장 그리고 TLM으로써의 경험은 내게 눈을 번쩍 뜨게할 만한 경험이었다. 아름다운 아키텍쳐, 유려한 디자인 패턴, 그리고 힙한 새로운 기술들에 메여있어 보이지 않던 것들이 보이기 시작했고, 한 명의 엔지니어가 아니라 팀으로써, 그리고 그 일원으로써 내가 해야하는 역할들을 찾아가는 여정이었다. 내년에는 더 많은 성과들로 회고할 수 있으면 좋겠다.