띵스플로우 엔지니어링 2021년 회고.

2022년의 띵스플로우 엔지니어링 조직을 소개합니다.

2021년에 띵스플로우는 헬로우봇이라는 단일 서비스에서, 스토리플레이를 포함하여 총 3개의 서비스를 운영하는 회사로 변모했습니다. 이 과정에서 엔지니어 수도 작년에 비해 두배로 늘었고, 프로세스도 좀 더 좋아졌습니다. 새로 합류하는 분들과 역사를 공유하고 싶어 기록을 남겨봅니다.

기술스택별 직무미팅 신설.

2021년 말에 엔지니어가 20명을 넘어선 덕분에, 동일 기술스택 엔지니어들끼리 모여 기술적 성장을 도모할 수 있게 되었습니다. 각 직무별 인적 상황에 따라 성숙도가 다르긴 하지만, 기본적으로 weekly meeting 과 수시 slack 커뮤니케이션을 통해 코드 리뷰, 트러블슈팅, 공통 라이브러리 개발, 프레임웍 선정등을 함께 하고 있습니다.

현재 띵스플로우에 운영중인 직무미팅은 iOS, 안드로이드, 서버/인프라, node.js 서버, java 서버이고, 2022년 2월부터는 웹FE 직무미팅이 재개됩니다.

엔지니어 전사 미팅의 변화.

인원이 늘면서, 실질적 논의는 직무미팅 및 엔지니어링 리드 미팅으로 분산되고, 전체 엔지니어가 다 모이는 미팅의 빈도는 한달에 한번으로 줄었습니다. 이 미팅의 의미는 네트워킹에서 찾기로 했습니다.

새로 합류한 엔지니어분들이 개발 이상의 가치를 더하기 위해서는 실무에 필수적인 컨택포인트만으로는 부족합니다. 어디에 어떤 동료가 있고, 그 분들의 관심사가 무엇인지 알고 있으면, 협업과 상호 학습이 가능해집니다.

특히 판데믹 상황에서는 캐주얼한, 또 우연한 마주침이 어렵기 때문에, 멤버들이 밍글링할 수 있는 기회를 의도적으로 마련해주는 게 필요합니다.

향후에는 이 모임을 새로 조인하신 분들이 이끌어나가길 희망합니다. 어떻게 운영하는 게 바람직할지 그 분들이 가장 잘 알 수 있기 때문입니다.

기술 질문 및 코딩테스트 강화.

직무 면접에서 기반기술 이해도를 추정할 수 있는 질문을 늘렸습니다. 예제 복붙이 아닌, 구조를 이해하고 코드를 작성하는 습관을 가진 사람을 채용하기 위해서입니다. 구조에 대한 이해도가 깊은 인재는 개인적인 성장뿐 아니라, 사내에서 기술적 토론을 촉발하고, 코드 리뷰를 통해 다른 엔지니어에게 생각할 기회를 주기 때문에, 회사의 기술진 수준을 높여줍니다.

이와 함께 코딩테스트 절차를 도입했습니다. 허들이 지나치게 높아지지 않도록, 일반적인 개발 교육을 받았거나, 업무를 해 왔다면 쉽게 풀 수 있는 문제로 구성했습니다만, 효과는 굉장했다고 생각합니다. 코딩에 익숙하지 않은 지원자를 가려내는데 큰 도움이 되었습니다.

SRE 엔지니어링의 시작

서버 개발자의 우선순위는 아무래도 feature update 에 있기 때문에, 클라우드 아키텍처가 노후화되고 모니터링, 알람, 이중화, 백업, 보안등 서비스 안정화 및 비상 대책에 결함이 생겨나게 됩니다. 서비스별로 인프라 구조가 파편화되어, 서버 개발자가 부서 전환 배치되기 어렵게 하는 문제도 덤으로 생겨났습니다.

SRE 엔지니어 영입으로 이러한 부분이 개선되기 시작했고, 12월에는 유저제보가 아닌, 알람을 통해 SRE 담당자가 먼저 서비스 장애를 발견하고 선조치할 수 있었습니다.

2022년에는 쿠버네티스 도입으로 서버 배포 구조와 모니터링을 표준화하려는 계획을 가지고 있습니다.

이를 통해 새로운 서버 배포시 즉시 모니터링과 알람을 적용할 수 있게 되고, 서비스와 관계없이 배포 방식과 알람, 모니터링이 표준화됩니다. 결과적으로 서버 개발자들의 전환 배치가 원활해지고, 다른 서버의 이슈에 공동대응 및 학습을 할 수 있게 될 것으로 희망하고 있습니다.

데이터 엔지니어링의 시작

그 동안 각 서비스별로 BigQuery 를 사용할 수 있는 사람이 ad hoc 하게 데이터 분석 요청에 대응하고 있었습니다. 매출과 조직이 커지면서, 데이터 분석 니즈가 늘어나는 상황에서 요청건수와, 처리하는 man/hour 가 비례하는 방식은 바람직하지 않았습니다.

먼저, 기술 구조를 동일하게 가져가기 위해 데이터 추출 및 가공에 airflow 를 도입했고, data lake 로 BigQuery 를 사용했습니다.

이후 역시 airflow 를 이용해서, 서비스별 지표들을 요약해서 아침마다 slack 에 보내기 시작했습니다. slack 은 데이터에 기반한 커뮤니케이션을 촉발하는데 최고의 도구였습니다.

지금은 더 depth 있는 데이터를 제공하기 위해 시각화 도구로 태블로를 이용해서 대시보드를 구성하기 시작했습니다.

한편, slack daily 요약에도, 또한 태블로 시각화에도 적합하지 않은 ad hoc 한 데이터 요청은 여전히 존재합니다. 이런 데이터 요청의 경우에는 google colab 을 검토하고 있습니다. 이를 통해 product manager 가 파라미터를 변경해서 직접 쿼리를 날려볼 수 있게 하는 업무 프로세스를 목표로 하고 있습니다. 이렇게 되면, 데이터 엔지니어의 작업량은 더 줄어들면서도 데이터 활용량은 더 많아지게 할 수 있을 것으로 생각합니다.

Security 엔지니어링의 시작

앱 서비스를 제공하고 있는 회사에서는 규모와 관계없이 개인정보보호법을 준수해야 합니다. 이를 위해 관리적, 기술적 보안 조치들이 필요합니다. 개인정보처리시스템에 대해 권한 부여 절차가 생겨났고, 권한 부여시 이를 로그로 남겨 변조가 불가능하도록 백업하는 등의 사례를 예로 들 수 있겠습니다. 조만간 100억 매출을 넘어서면, 정보통신망법에 의해 요구되는 정보보호 인증(ISMS), 개인정보보호법에 의해 요구되는 개인정보보호 인증(ISMS-P)을 취득하고 유지해야 합니다. 2022년에는 개인정보보호법에서 강제하고 있는 연1회 웹사이트 취약점 진단을 보안업체와 협업하여 진행할 예정에 있고, wazuh 라는 SIEM 소프트웨어를 설치하여, 서버에 보안침해 가능성이 있는 경우 슬랙 보안알림 채널에서 받을 수 있게 하였습니다. 아직은 POC 수준이지만, 올해 서버 전체에 적용하려고 합니다.

맺음말

회사의 빠르고, 큰 성장을 뒷받침할 수 있는 엔지니어링 조직이 될 수 있기를 희망합니다. 이를 위해선 아래와 같은 부분에도 촛점을 맞춰야 할 것 같습니다.

첫째, 우리의 업은 부가가치를 설비가 아니라 사람이 만들어가는 산업입니다. 우리 사업이 잘 되려면, 멤버들이 탁월해지는 것이 기본일 것 같습니다. 더 좋은 동료를 맞이할 수 있도록 모든 수단을 다 써봅시다.

둘째, 사내외에서 좋은 practice 를 발굴해봅시다. 더 잘할 방법을 찾고, 해보고, 전파합시다. 이것이 쌓여서 합류하고 싶은 회사가 됩니다. 반대로 이런 것이 없으면 잠재적 동료들에게 합류를 권하기가 부끄러워지겠지요.

셋째, 엔지니어링 문제가 아니라, 비즈니스 문제를 푸는데 촛점을 맞춥시다. 엔지니어는 비즈니스 문제를 해결하는 사람입니다. 할 일을 더 세련되게 풀 수 있는 방법이 있는지 생각해보고 제안하는 것, 업무의 우선순위를 하고 싶은 일보다는 비즈니스 임팩트 순서로 정렬해보는 것이 전문가로서 인정받는 좋은 습관이지 않을까 생각해봅니다.