팀블라인드를 알게 된 계기
팀블라인드로 옮기기 전에 근무했던 회사에서는 Spring boot, Vue를 이용한 작업을 주로 맡게 되었는데 그중 Vue 작업을 많이 하게 됐다. 그러다 보니 자바스크립트를 많이 공부하게 되었다. 프로젝트를 진행하면서 서버가 Node.js로 구성된 프로젝트도 맡았었다. 팀에서 담당하는 프로젝트를 문맥 교환이 자연스러울 정도로 익숙해져야 한다는 정책에 따라 나는 거의 3개월 주기로 다른 성격의 프로젝트를 접하게 되었다. 그런데 기술 스택이 조금씩 차이가 있었다. 백엔드는 Spring을 쓰는 프로젝트도 있었지만 Node.js 기반의 프로젝트도 있었다. 두 가지 영역을 왔다갔다 하면서 작업해야 하니 Java까지 사용해서 두 개의 언어를 다루는 것보다는 하나의 언어를 다룰 수 있는 Javascript 진영에 마음이 끌렸다. 백과 프런트 둘 다 구현하면서 한 가지 언어만 신경쓰면 되니까!
당시 근무했던 SI 회사 분위기
그런데 SI 업무 특성상 갑작스러운 신규 프로젝트를 팀에서 담당하게 되고 내가 담당하진 않았지만, 인원이 모자라게 되면서 급하게 투입되었다. 당시 팀이 감당하기 어려운 프로젝트 압박 속에서 코드 품질을 유지하기가 힘들었던 상황이었고, 이는 조직과 개인 모두에게 아쉬움이 남는 기억이었다. 그러던 중 우연히도 팀블라인드 회사를 알게 되었다. 당시 근무하던 회사와 비슷한 기술 스택을 사용하고 있었다. Vue.js를 사용하고 Node.js 기반으로 작업하고 있으니 이직하더라도 도메인 학습만 된다면 바로 업무를 할 수 있을 것 같다는 기대감이 들었다. 그리고 회사가 만들고 키우는 서비스를 보면서 ‘나도 서비스에 애착을 가지면서 성장할 수 있지 않을까?’ 하는 기대를 품게 되었다. 이때였을까? 단순히 기능 개발만 하는 것이 아니라, 프로덕트를 통해 일상의 문제를 해결하고 서비스를 가꿔가면서 기술 그 자체가 아니라 서비스에도 애착을 갖게 되었다.
팀블라인드에 합류하기로 한 이유
직장 문화 현대화를 위한 사명에 동참
블라인드 커뮤니티에서는 내가 소속한 회사가 보이고 익명 사용자로서 소통할 수 있는 공간을 제공해 준다. 이 공간에서 사내 부조리한 일들이 어떻게 벌어졌는지 공론의 장이 된다. 그중 몇몇 충격적인 사건은 몇 번 방송을 타거나 뉴스 기사로 올라오기도 한다. 파급력이 커지면서 회사원이라면 대개 이 커뮤니티에 가입할 것이다.
나에 대한 뜨거운 관심
정말 신기한 것은 2021년까지 나에게 가장 많은 관심을 보여주었던 회사였다. 인터뷰에서는 같이 일하게 될 팀원 분들이 들어오셔서 이런 저런 물음을 주셨다. 나의 이력서에 밑줄까지 쳐 오시고 궁금한 점을 하나 하나 물어 주셨다. 누군가는 “그게 뭐 대수라고”라고 생각할 수도 있다. 하지만, 내가 공무원을 그만두고 첫 커리어를 내딛기 위해 개발자로서 면접장에 들어섰는데도 퇴직 이유에 관해 묻지 않는 경우도 있었다. 마찬가지로, 이 회사에서도 내게 관심을 가져주지 않을 것 같은 걱정이 있었다. 하지만, 걱정이 무색하게도 인터뷰에서는 블로그에 쓴 글까지 꺼내 질문해 주셨는데 진심으로 나를 살펴 주셨다는 인상을 받았다. 심지어 당시 블로그 글이 올라오지 않는 이유에 관한 질문까지 받았다.
입사 첫 날의 감동과 기대했던 점
그동안 일방적인 합격 통보 메일과 입사 안내 메일은 받아봤어도 이렇게 회사 구성원 한 분으로부터 한 사람을 대한다는 느낌을 받아 본 경우는 처음이다. 오퍼 수락 후 친절하게 챙겨주시는 직원분의 따뜻한 메일에 입사하기로 나의 결정은 공고해져 간 채 입사 첫 날이 다가오게 되는데…
태어나서 처음으로 경험한 맥북
“M1이 뭐예요?” 실제로 내가 한 말이다. 애플 제품은 워낙 고가의 제품이기 때문에 귀여운 내 월급으로는 엄두가 안 났다. 하다못해 그 폐쇄적인 생태계를 비집고 들어가려면 맥북뿐 아니라 아이패드, 아이폰까지 우르르 장만하게 될 것 같아서 일단 쳐다도 안 봤다. 그래서 스타트업에서는 맥북 장비를 지급하는 것은 알고 있었지만, 실제로 내가 맥북을 사용하게 될 줄은 꿈에도 몰랐다. 물론 리눅스 운영체제는 많이 다뤄봤으니 적응하는 데는 그다지 어렵지 않았다.
난생 처음으로 맥북 상자를 들어봤다.
재택근무를 기반으로 운영되는 개발 조직
2021년 감염병의 위험이 커져 지금은 상상조차 할 수 없는 일이었던 “O명 이상 집합 금지”. 감염병의 확산 방지를 이유로 헬스장이 강제로 임시 폐쇄되고 접종자만 출입할 수 있는 시기가 있었다. 다행히도 지금은 코로나 사태가 종식되었지만, 당시만 하더라도 출퇴근할 때 혹시 바이러스에 감염되는 것은 아닐까? 하는 께름한 면도 있었다. 이전의 회사에서는 옆자리에 있더라도 메신저로 소통하는 경우도 일반적이었는데 글로 서로의 의도만 잘 전달된다고 하면 굳이 사무실에 출근할 필요가 있는지에 관한 의문도 있었다. 그래서 더욱 재택을 강조하는 팀블라인드의 기조에 격하게 공감했다. 항상 재택이 효과적인 업무 효율을 발휘하는 것은 아니었지만, 상당한 장점이 있었다고 생각한다. 특히, 침대 앞 독서실 책상에 앉아 하루 10시간가량 꼬박 공부했던 내게는 자취방에 마련한 책상 위에 앉아 일거리를 쳐 내는 일은 그저 일상이었다.
다양한 팀원과의 협업
기존에는 기획자가 기획, 디자인, QA, 배포 감독까지 맡는 구조였다. 그런데 블라인드 조직에서는 PM, QA 엔지니어, 퍼블리셔, 모바일 앱 개발자, 데이터 엔지니어 분들과 협업할 수 있는 기회가 있었다. 서비스 하나를 개발하고 유지하고 고도화하기 위해서 다양한 인력이 필요하다는 것을 이곳에서 실감했다. 다양한 분야의 사람과 만나면서 어떻게 이야기하면 보다 나의 생각을 고스란히 전달할 수 있을지, 잘못 이해하게 되는 여지는 어떻게 줄일 수 있는지 고민할 수 있었던 자리였다.
다채로운 개성과 역량을 지닌 동료
보통 단순한 게시판 서비스는 백엔드, 프런트엔드, 1개의 데이터베이스 이렇게 3가지로 구성된다. 한국, 미국 통틀어 800만 명 이상의 직장인이 사용하는 ‘블라인드’ 서비스는 단순한 게시판과 인프라가 동일할까? 당연히 아니었다. 관리자페이지에서 실제 서버 게시글을 모니터링해야 하는 경우가 있었다. 작업을 하는 도중 새로고침하면 내가 이전에 봤던 게시글은 다음 페이지로 글이 몇 초 만에도 밀려난 경우도 있다. 이러한 트래픽에도 안전하게 서비스를 지탱하기 위해서는 관계형 데이터베이스, 검색을 최적화하기 위한 ElasticSearch, 읽기 성능 증대를 위해 사용하는 인-메모리 데이터베이스 Redis, Couchbase, 실시간 데이터 스트리밍을 위한 Kafka 등등.. 정말 많은 플랫폼을 이용해야 한다. 이런 플랫폼을 각각 잘 다루시는 동료분들이 협업하는 형태로 업무가 진행됐다. 특히, 하나의 이슈를 쳐 내려면 여러 개의 플랫폼에 대한 학습이 필요한데 이때 검색으로 해결되지 않는 정보는 서버팀 여러 동료분들께 문의드리면서 차분히 업무를 진행할 수 있었다.
550만 명이 이용하는 서비스에 대한 자부심
많은 이용자가 내가 몸을 담고 있는 회사의 서비스를 이용한다는 것 자체에서 자부심을 느끼게 된다. 당시만 하더라도 550만 이용자라고 했는데 2023년인 지금은 800만이 이용한다고 한다.
2022년 1월, 팀블라인드 대표님이 유퀴즈에 나오신 적이 있다. 우리 서버개발팀은 긴장하는 분위기였다. 아니나 다를까 대표님이 방송을 타자마자 회사가 소개되었고 빠르게 앱의 이용률이 증가하는 것을 CloudWatch로 응시할 수 있었다. 트래픽도 증가할 뿐만 아니라 가입자가 증가하는 광경도 목격할 수 있었다. 심지어, 트래픽이 늘어나면서 탄력적인 장애 대응에 관해서도 살필 수 있었고 그러한 부분들 역시 시니어 개발자분들의 빛나는 역량을 확인할 수 있었다.
사용자의 빠른 피드백 경험
내가 던진 농구공이 골대에 들어갔는지 한 달 뒤에 결과를 알 수 있다면 빠르게 농구 실력을 올릴 수 있을까? TDD는 빠른 주기로 피드백 받고 리팩터링하며 점진적인 코드를 개선하는 작업이다. 마찬가지로, 기획대로 서비스를 개발하여 배포하면 사용자의 빠른 피드백을 확인할 수 있는 것이 팀블라인드만의 장점이었다. 그래서 버그가 있을 때나 불편한 점이 게시글로 올라오는 상황을 목격한 경우도 있었다. 이러한 불편한 점을 개선하는 작업을 맡았는데 배포한 뒤에 이러한 개선점을 사용자에게 빠르게 피드백을 받았을 때 보람을 느낄 수 있어서 좋았다.
학습하기 쉬운 친숙한 도메인
이전 회사에서 만드는 웹 프로젝트는 통신사 임직원이 사용하는 프로그램이었다. 그래서 도메인을 일부 학습하기는 했었는데 도메인 지식이 있다고 하더라도 어떤 연유에서 이런 기획안이 나왔는지까지는 모두 알기 어려웠다. 하지만, 블라인드 서비스는 내가 사용자로서 앱을 이용하면서 왜 이러한 기능이 필요한지, 왜 이 버그를 수정하는 데 우선수위를 둬야 하는지에 관해 추론할 수 있었다. 또한, 이러한 추론을 바탕으로 현재의 결괏값이 버그인지 아닌지 판단할 수 있었다.
마치며
SI회사에서 팀블라인드로 넘어오면서 많은 경험을 하게 된 회사였다. 팀블라인드에서 대규모 서비스를 경험하면서 시야의 폭을 넓히게 된 계기였다. 특히, 다양한 직무에 종사하는 동료들과 소통하면서 협업을 어떻게 하면 좋을지에 관해서도 고민할 수 있었다. 게다가 개발자 조직은 재택 기반으로 운영되다 보니 소통은 회의를 제외하면 주로 문자로만 이루어지는 상황에서도 발빠른 대응을 할 수 있다는 점이 인상 깊었다.