글또콘 후기
흔치 않은 글 쓰는 개발자들의 모임
오늘 마켓컬리 사무실에서 글또콘이 열렸다. 60~70명 정도가 모인 느낌이다. 코로나 이후로 오랜만에 느껴보는 북적북적한 분위기다. 안내에 따라 백엔드 개발자 쪽에 자리를 잡았다. 백엔드 개발에 글쓰기의 고통을 나누고 있다는 공통점이 있다 보니 다른 콘퍼런스와는 달리 말을 건네기가 편했다.
마무리의 성윤 님 말씀과 같이 다양한 직군이 있어 다른 기술 콘퍼런스에 비해서는 상대적으로 일반적인 주제로 진행되었다. 하지만 개인적으로 발표마다 남는 것이 있어 후기를 여운이 식기 전에 남겨 본다. 물론 이번 글쓰기 주제를 못 정한 이유도 있다. 그래. 그렇다.
변성윤 님의 “어디로 가야 하오. 여러분들은 삶의 철학이 있나요?
성윤님. 야생 학습의 길잡이 질문성윤 님은 스스로를 어떻게 해석하고, 어떻게 삶의 방향을 정하고 계신지에 대해 말씀 주셨다. 게임 캐릭터의 대사에서 받은 영감에 따라 몇 가지 키워드를 들려주셨다.
삶의 지도: 어디로 가야 하오
성윤 님은 내가 어디로 가야 하는지를 알기 위해 과거를 정리해 두고 계셨다.
처음 보여주신 것은 인생의 주요 포인트를 정리해 둔 스프레드시트였다. 인생의 어떤 시기에 어떤 경험을 했고, 그것이 나에게 어떤 영향을 미쳤는가에 대한 내용이다. 초등학교 때 좋은 선생님을 만난 것, 아버지와 포켓몬 게임기를 사러 간 일, 이직과 팀장의 경험 등. 인생의 주요 터닝 포인트다.
나도 떠올려 보면 몇 개의 사건이 생각난다. 하지만 이렇게 명시적으로 정리하는 과정을 통해 그 사건들을 객관적으로 볼 수 있겠다 싶다.
두 번째는 삶의 지도였다. 공부, 이직, 데이터 분석가, 팀장, 디렉터, 퇴사까지의 패스가 그려져 있었다. 이렇게 나의 삶의 패스들을 도식화해 보면 나의 선택의 기준을 볼 수 있을 것 같았다. 그럼 나의 다음 패스도 자연스럽게 고민해 볼 수 있겠지.
야생 학습: 깨달음이란 스스로의 무지함이 지니는 가치를 아는 것이오.
앎이라는 것에는 끝이 없기 때문에, 새로운 것을 빠르게 습득하고 하나씩 실행하는 것에 중심을 둔다고 하셨다. 그 방식으로 김창준 님의 “야생 학습"을 소개해 주셨다. (함께 자라기, 김창준 님의 블로그 참조)
또한 야생 학습의 길잡이 질문들과 그에 대한 성윤 님의 해석, 실행 예를 소개해주셨다. (야생 학습 휴리스틱스 툴셋 참조)
여전히 우리는 의무감에 책을 읽고, 유명인의 동영상을 보고, 콘퍼런스에 참석하곤 한다. 학교 학습이다. 하지만 요즘에는 만들어 낼 결과에 중심을 두고, 학습을 진행하려 한다. 그래서 오늘은 후기를 써야겠다는 생각으로 “적극적 듣기"를 했다. 야호. 빠르게 습득하고 실행했다.
스스로 운명 개척하기: 수도승의 가르침을 받들어 스스로의 운명을 개척할 것이오.
성윤 님은 직장생활과 스스로에 대한 탐구를 통해 다음을 알게 되셨다고 한다.
나는 영향을 미치는 것이 중요한 사람이고, 0→1을 만들어 내는 것을 잘하는 사람이다.
데이터를 활용해 좋은 의사결정을 하고자 하는 사람은 많지만, 정보의 불균형이 심하고 교육으로 이를 해결해야 하겠다.
그래서 회사를 떠나, 스스로 운명을 만들어 내기로 결정하셨다고 한다.
앞으로 좋은 선택들을 해나가기 위해서는 불확실성을 줄이는 것이 중요하고, 이를 위해 “멘탈 시뮬레이션"을 활용한다고 하신다. 멘탈 시뮬레이션은 마음으로 각각의 선택에 따른 상황을 그려보고 행복감을 높일 수 있는 방향을 찾아보는 것이다. 그리고 그에 따른 준비를 하는 것이다.
마지막으로 삶의 철학을 세우기 위한 액션 플랜을 공유해 주셨다.
자신에 대한 이해: 메타인지
삶의 철학을 1년에 1개씩 만들고 기록하기
사람들과 자신의 삶의 철학 나누기
삶의 철학을 쌓기 위해 독서하기
클레이 질문 카드에 답해보기
삶의 철학이라. 무거운 주제다. 스스로도 고민을 했던 적이 있지만 그것이 과연 평생 바뀌지 않을 기준이 될 수 있을까에 대해 자신이 없었고, 입 밖으로 내지 않았다. 하지만 성윤 님의 발표를 통해 치열하게 고민하되, 변경에 자유로워져야겠다는 생각이 들었다. 그리고 내 삶의 철학을 나눔으로 그 철학을 이어갈 힘을 얻어야겠다.
학건님의 Airflow Bad Practices - 도입 전에 제발 봐줬으면 하는
학건님. Airflow를 한마디로 말해보자면백엔드 개발자에서 데이터 엔지니어로 커리어를 이어가고 있는 학건님의 발표였다. Airflow에 대해 여러 번 듣긴 했지만 내부에서는 이미 다른 도구를 사용하고 있어서 잘 알지는 못했다. 비교하면서 들어 볼 수 있는 재미있는 기회가 되었다.
Airflow에 대해서는 개발자들이 잘 이해할 수 있도록 “이쁜 젠킨스”라고 요약해 주셨다. Airbnb에서 만든 workflow management tool로 직관적 UI, 낮은 진입장벽, Python 언어의 사용을 장점으로 들어주셨다. 다만 낮은 진입장벽에 따라 반작용으로 관리를 제대로 해주지 않으면 산으로 갈 수 있다고 하셨다. 그리고 실제로 겪으신 나쁜 예와 그에 대한 대안을 들을 수 있었다.
요약하면 다음과 같다.
Python Operator의 역습
Jinja template을 최대한 사용하자.
코드 중복을 막기 위해 third party operator를 사용하도록 하자. custom operator를 만들어서 사용할 수도 있다.
비밀번호 등 중요한 정보는 Connection에 입력하고 Hook을 사용하자.
Task는 심플하게
개발할 때처럼 Task를 심플하게 작성하자.
모두를 위한 Batch는 없다.
방심했더니 모든 batch들이 Airflow안에 들어와 있었다.
명확한 기준을 세우고, 사람들의 자유도를 제약해서 원칙에 맞게 사용하도록 하자.
학건님의 말씀처럼, Airflow를 로컬에서 한번 테스트해보고 도입 여부를 고민해 봐야겠다. 새로운 것을 도입하는 것은 상대적으로 가볍고 즐거운 일이지만 운영해 나가는 것이 핵심이다.
최현구 님의 내가 테스트 코드에 집착하는 이유
현구님. 리뷰어의 이목을 끄는 테스트현구 님은 2021년 1월부터 2022년 8월까지 약 1,800개의 테스트를 작성하셨다고 한다. 테스트를 작성하면 그렇지 않았을때에 비해 2배의 시간이 걸리는데, 이렇게 시간을 들이면서까지 테스트에 집착하는 이유를 말씀해 주셨다.
테스트는 다음과 같은 장점이 있음을 익히 알고 있다.
과감한 리팩터링
애플리케이션 동작 결과 확인
개발 과정에서 설계에 대한 문제 확인
하지만 우리는 테스트 코드 작성을 동료의 시간 절약을 통한 경제성 확보라는 시선으로 바라봐야 한다는 것이 요지였다. 실제로 그러하다. 우리는 리팩터링뿐만 아니라 동료의 코드를 리뷰할 때, 관련된 로직을 작성할 때 생각보다 많은 시간을 쓰게 된다. 이때 잘 작성된 테스트 코드는 동료의 시간을 크게 절약해 준다.
현구 님은 나아가서 동료들이 테스트 코드에 관심을 가질 수 있도록 테스트 코드를 매력적으로 만드는 것에도 신경을 쓰고 계셨다. 그 방법은 다음과 같다.
특성을 나타내는 변수명을 사용한다. ex) event1 대신 “4월 1일 ~ 4월 5일 3회 차"
한글로 작성한다.
가짜 생성자를 이용해서, 테스트에 중요한 파라미터만 강조한다.
리뷰어의 이목을 끄는 테스트를 작성한다. 팀원들의 이름을 넣거나 재미있는 문구를 넣는다. 기대감을 가지고 사람들이 PR을 열어보기도 한다.
불필요한 테스트는 과감하게 생략해서 나머지 테스트를 강조한다.
특성을 잘 나타내는 변수명과 재미있는 문구를 사용하는 점은 우리 팀에서도 시도해 보면 좋겠다 싶었다. 개인적으로도 Fixture에 팀원들의 이름을 쓰곤 했는데, 그분들이 퇴사를 하고 나니 해당 이름만 고치는 PR을 만들기도 그렇고, 계속 두자니 볼 때마다 좀 쓸쓸한 느낌이 들곤 했었다. ㅠ.ㅠ
질답에서도 나온 것처럼 테스트를 작성하는 것은 어렵지 않지만 테스트 작성을 문화로 안착키는 것이 어렵다고 생각한다. 우리의 경우에는 CI과정에서 커버리지 테스트로 테스트 작성의 강제성을 부여하는 것이 처음에는 많은 도움이 되었던 것 같다. 이제는 우리도 커버리지에 크게 신경 쓰진 않는다.
신해나라님의 개발 서적 우수 리뷰어 되기
해나라님. 홍보 관점에서 좋은 리뷰란? 한빛 미디어 서평단으로 활동하고 계시고 2022년 우수리뷰어로 선정되신 믿을 수 있는 신해나라님의 발표였다. 개인적으로는 가장 기대했던 발표였고, 기대만큼 재미있었다.
해나라님의 발표를 요약해 보면 “좋은 리뷰는 출판사의 니즈에 맞게 작성해야 하고, 기술 블로그도 목적에 맞춰 글을 써야 하는 것이 다르지 않다.”이다.
소개해주신 좋은 리뷰를 작성하기 위한 팁은 다음과 같다.
책의 장점에 초점을 맞춰야 한다.
내용의 요약보다는 독자가 왜 읽어야 하는지가 중요하다.
서문에서 많은 힌트를 얻을 수 있다. 집필의 의도와 대상 독자를 알 수 있다.
본인의 고찰과 경험이 포함되어야 한다.
2,000~3,000자의 리뷰가 적절하고, SNS에는 700~800 정도로 발췌되어 공유되기 때문에 2~3 문단 안에 핵심이 포함되어야 한다.
책의 중요 문구의 인용, 다른 사례, 문어체, 전문용어 등을 통해 전문가처럼 보여야 한다.
그리고 실제 작성한 서평을 통해 위 팁이 어떻게 사용되었는지를 알려 주셨다. (예를 알려주시지 않았으면 실제 작성하신 리뷰를 찾아보고 위 팁과 맞춰 보면서 학습을 해볼까 했었다.)
이어서 기술 블로그를 작성함에 있어서도 고민해 볼 포인트를 알려 주셨다.
개인적인 목적으로 글을 쓰더라도 대상 독자는 항상 내가 아닌 타인을 고려해야 한다.
(책의 서문 읽기와 같이) 공식문서를 통해 기술의 탄생 배경, 해결하고자 하는 문제, 해결 방식을 이해할 수 있다.
기술에 대한 개인적인 경험을 적어주는 것이 좋다.
공식 문서의 인용, 다른 적용 사례, 문어체, 전문 용어 등을 통해 전문성을 보여주면 좋다.
서평, 기술 블로그와 같이 명확한 목적을 갖는 글쓰기의 경우 해나라님이 소개해주신 것처럼 명확한 기준, 적절한 템플릿을 가지고 작성을 하면 그 목적을 효과적으로 달성할 수 있겠다 싶다. 해나라님의 팁에 몇 가지를 붙여서 글쓰기 체크리스트를 만들어 두어야겠다.
발표가 끝나고 두런두런
발표가 끝나고 모여있던 백엔드 개발자끼리 이야기를 나누었다. 7명의 개발자가 모였는데, 그중 4명이 Java, 3명이 Python이었다. 아니. 이렇게 Python 비율이 높다고?
금방 지나가 버린 1시간 동안 다음과 같은 이야기를 나누었다.
어떻게 해서 글또로 흘러(?) 들어오게 되었는지?
팀으로 같이 일하기 위한 방법
원하는 개발 환경이 갖춰지지 않았을 때의 고민과 마음가짐
비개발자로의 한계와 극복하기 위한 노력
Spike 트래픽을 받아내기 위한 현실적인 방법
새로운 사람을 만나는 것을 즐거운 일이다. 그리고 공통점이 있는 사람들은 더 그렇다. 오늘 모인 분들 모두 돌아가실 때는 나와 같은 충만한 느낌을 받으셨으리라 생각한다. 주최 해주신 분들께 감사하고 꾸준한 글쓰기와 언젠가의 발표로 글또에 기여하고 싶다. (아. 이 후기로 일단 기여를!)
마지막으로 콘퍼런스를 듣느라 사진을 찍지 못했는데, 후기를 위해 사진을 제공해 주신 신해나라님, 정종윤님, 김학건님께 감사 드린다.
