최근 여러 기술 아티클, 블로그(네카라쿠배 등) 글들을 읽으며, 수많은 글 중에서도 중요도가 높은 글을 먼저 읽고 싶다는 생각이 들었다. 물론 조회수나 추천 수를 기반으로 글을 선별할 수도 있었지만, 그래도 한 번 더 사람의 손길을 거치고, 책으로 엄선된 글들은 더 신뢰할 수 있을 거라는 판단이 들었고, 요즘 우아한 개발이란 책을 읽게 되었다. 그렇게 읽게 된 책에 대한 내 생각을 글로 남기고자 한다.
나를 포함해 내 글을 읽는 사람들이 책에 실린 글의 원문이 궁금해질 수 있겠다는 생각이 들었다. 그래서 글 중간중간 블로그 원문 링크를 삽입해, 내 글을 읽고 흥미가 생겼다면 원문까지 바로 확인할 수 있도록 작성했다.
참고로, 책과 블로그 원문은 각기 다른 장점이 있다. 블로그 원문은 곁들여 읽을만한 참고 글, 자료들도 같이 정리되어 있어서 원한다면 더 깊이 읽을 수 있고, 반면 책은 문장의 톤이 더 정제되어 있어 더욱 부드럽고 읽기 편하게 다가왔다. 상황에 따라 더 도움이 되는 방향으로 선택하길 바란다.
글의 본문에 들어가기 앞서서 소감부터 말하자면 좋은 개발자란 어떤 사람인지, 그리고 개발자는 어떤 태도와 자세를 가져야 하는지에 대해 스스로 깊이 고민해 볼 수도 배울 수도 있는 시간이었고, 내가 앞으로 어떤 개발자가 되고 싶은지, 또 지향해야 할 팀 문화는 무엇인지에 대해서도 배우고 생각할 수 있었다.
방법론적인 소감으론, 훌륭한 선배 개발자들은 문제를 어떻게 바라보고, 어떤 사고 흐름을 거쳐 해결해 나가는지를 엿볼 수 있었고 그 과정에서 얻은 개발 오답노트를 편히 접함으로써, 내가 직접 같은 문제를 겪지 않더라도 예방하고 대비할 수 있는 지혜를 얻을 수 있었다,
또한 PM, QA, SRE팀 등 다양한 직군의 시선에서 바라본 이야기도 함께 담고 있어, 마치 그들이 되어보는 듯한 경험을 할 수 있었다. 덕분에 미래 내가 맡을 일만이 아니라 동료들의 역할, 관점까지도 이해하게 되면서 보다 넓은 시야를 갖게 도와주었다.
마지막 소감으로, 이 책의 글들이 입을 모아 전달하고자 한 메시지는 “우리가 하는 모든 일의 종착지는 사용자예요”라는 말로 들렸다. 그러니 나도 사용자의 경험을 늘 고려하는 수고로운 사람이 되어야겠다.
왜 이렇게 소감을 남길 수 있었는지는, 후술할 글에서 하나씩 풀어보고자 한다.
좋은 개발자란 함께 할 준비가 되어 있는 사람
좋은 개발자란 머리가 좋고 코드를 잘 작성하는 사람만을 지칭하는 게 아니라 함께 일하는 동료들과 어떻게 관계를 맺고, 팀 전체의 성장을 위해 어떤 태도를 가지는지가 더 중요하다는 걸 배울 수 있었다.
이와 관련해 책 중간에 인상 깊었던 문장 중 하나는 “최고의 복지는 좋은 동료다.”라는 말이었다. 여기서 말하는 “좋은 동료”란, “누구의 일로 나누지 않고 함께 할 각오가 되어 있는 사람”이라고 표현되었는데, 이 문장을 보면서 개발자는 혼자가 아닌 함께 일하는 사람이고, 그 함께의 무게를 감당할 자세가 되어 있어야 진짜 좋은 개발자가 될 수 있겠다고 느꼈다.
그리고 우아한 형제들 팀이 프로젝트를 진행할 때 추구했던 방향으로는 “모두가 신뢰할 수 있고, 이해할 수 있는 방향”을 강조했다. 이를 완수하기 위해 아래에서 더 자세하게 다룰 KPT 문화를 적용하는 등 다양한 방면으로 함께 나아가는 방향을 만들어가는 게 인상 깊었다.
읽는 중간중간 반가운 문장도 존재했는데, 바로 “송파구에서 일 잘하는 11가지 방법 “이었다. 그 중 첫 번째 방법인 “12시 1분은 12시가 아니다”를 팀 프로젝트를 진행할 당시, 팀 규칙에 적용해 회의 시간에 늦지 않게 분주했던 기억이 떠올라 재밌는 회고를 갖기도 했다.
팀 프로젝트 얘기가 나왔으니 부트캠프 시절을 좀 더 해보자면, “실무는 개인이 잘해서만 되는 것이 아니라 팀 중심으로 팀이 잘 나아가야 한다.”는 멘토님의 이야기가 기억에 남는다. 그때 당시엔 구체적인 사례와 함께 전해 들은 게 아니라 이해는 했으나 평면적으로 다가왔었다. 그러나 이 책을 통해 선배 개발자들의 경험이 녹아든 글들을 읽으면서 왜 팀 중심인지 입체적으로 이해할 수 있었다.
또한 개발자는 개발만 잘해야 하는 게 아니라, 다양한 직군의 동료들과 함께 협업해야 한다는 점도 다시 한번 배울 수 있었다. 책 속에서 PM이 어떻게 일을 조율하고 , 소통하는지 , QA과 SRE팀 가지는 고충은 무엇인지 시니어와 주니어 각각의 입장에서 어떤 고민과 시선을 가지고 일하는지 등 다양한 관점에서 쓰인 이야기들을 실무에 나가기 전 미리 경험해 볼 수 있다는 점에서 감사하기도 했다.
글들을 읽으면서 지금까지 머릿속 한쪽에 생생하게 남아있는 중학교 도덕 교과서 귀퉁이에 적혀있던 역지사지라는 사자성어가 떠올랐다. 그 말이 단지 교우 관계에만 국한되는 것이 아니라, 함께 일하는 동료를 이해하고 존중해야 하는 실무에서도 꼭 필요한 덕목이라는 점을 다시금 깨달았다. 그리고 개발자는 혼자 잘하는 사람이 아니라, 함께 잘하는 사람이 되어야 한다는 점을.
좋은 문화는 팀을 성장하게 만든다.
이 책을 통해 우아한 형제들은 실제로 어떤 팀 문화를 만들고, 실천해 나가는지를 엿볼 수도 있었다.
책에서 소개한 여러 팀 문화 중 인상 깊었던 두 가지만 말해보자면, 첫 번째로 “낮은 공유 문턱의 문화”였다. 사실 나조차도 가끔은 내가 무언갈 공유하고자 할 때 이런저런 생각을 하며 다른 사람들은 이렇게 생각하지 않을까? 하는 심리학에서 말하는 인지 왜곡 중 하나인 독심술 오류를 겪곤 하는데 우아한 형제들에선 작은 정보도 자유롭게 공유되고, 누군가의 질문이나 제안을 팀 전체가 열린 마음으로 받아들인다는 점이 인상 깊었고, 나 역시 그런 문화 속에서 일하고 싶다는 생각이 자연스럽게 들었다.
두 번째로는 KPT(Keep, Problem, Try) 회고 방식이었다. KPT는 한 팀이 2주 단위로 스프린트를 진행하고 마지막 날에 진행하는 회고 방식인데 이 방식으로 팀의 문화가 탄생하거나 변화하거나 폐기된다.
- Keep은 지속되었으면 하는 점
- Problem은 문제가 있거나 변화가 필요한 점
- Try는 잘하는 걸 더 잘하려면, 문제가 있는 점을 해결하려면 시도해 볼 점을 뜻한다.
어떻게 보면 이 단순한 세 가지 항목으로 팀이 더 나은 방향으로 나아갈 수 있게 활용한다는 점이 흥미로웠고, 나도 이 방식을 경험해 보고 싶다는 설렘을 느끼게 해줬다. 그리고 회고를 형식적인 절차로 두지 않고, 팀 문화를 만드는 도구로도 사용된다는 점이 인상 깊었다.
다양한 팀 문화들을 읽으면서 한 가지 생각이 떠오르기도 했다. 실무에 나갔을 때, 만약 이런 건강한 팀 문화가 없다면 신입이라는 위치라도 용기를 내어 마음 맞는 동료들과 함께 작은 시도라도 해보고 싶다는 생각이었다. 작은 팀 안에서라도 건강한 문화의 씨앗을 심을 수 있다면 그것만으로도 의미 있는 일이지 않을까 생각한다.
만약 이미 좋은 팀 문화가 정착된 기업이라면, 그 안에서 더욱 적극적으로 참여하고, 선배 개발자들을 관찰하고 배우고 싶다.
난 이런 시니어 개발자가 되고 싶어요 (+ 군대 경험)
이 책을 읽으며, 난 어떤 개발자가 되고 싶은지 미래를 그릴 수 있도록 도와주기도 했다.
우아한 형제들에선 시니어가 관리자 트랙과 전문가(실무자) 트랙을 나눠서 개인의 커리어 패스를 쌓도록 지원해 준다는 부분이었는데, 아직 일을 시작하지 않았지만, 내 미래 커리어의 방향성에 대해 생각해 볼 수 있는 좋은 계기가 되었다.
개인적인 경험을 잠깐 말하자면, 나 스스로 리더십을 고민하고 체험해 볼 수 있었던 시절이 있었는데 그건 바로 군 생활이었다. 누군가에게는 군대 경험이 특별하지 않을 수 있지만, 나에게는 인생의 선배로서 본보기가 되는 좋은 간부님들과 인연을 현재까지도 맺을 수 있었고, 정해진 규율과 계급 체계 속에서 리더의 역할을 가장 오랫동안 체감할 수 있었던 시기였다. 리더의 역할은 운이 좋게도 분대장 역할을 맡으면서 시작되었는데, 모종의 이유로 일찍이 일병 때부터 약 1년 이상 맡게 되었다. 그 시절 난 상병, 병장 분대장들 사이에서 오랫동안 막내 분대장으로 나름의 처세술도 배우고, 동시에 생활관 내의 다양한 병과(작전, 정보, 인사, 동원)를 가진 선임, 동기, 후임들의 각 처부별 고충을 듣고 도와줄 수 있는 부분을 찾아 내가 근무에 대신 투입하는 등 실질적인 도움을 주거나 문제를 같이 고민해 나가며 해결해 나갔던 뿌듯함을 느낀 시간이 많았다.
특히 기억에 남는 건, 나보다 업무적으로 뛰어나거나, 머리가 좋다고 판단된 후임들을 관리할 때였다. 앞서 얘기한 병과 중 작전/정보 계열을 부여받아 대위급 이상의 과장님들과 임무 수행을 하다 보니 우리의 일이 곧 간부님들의 고과에 영향을 주어서 늘 문제가 생기지 않도록 주의했었다. 그러다 보니 자칫 내 강압적인 태도나 판단 실수로 후임들의 역량을 제한할 수도, 이에 따라 간부님들께도 악영향을 미칠 수 있으니 최대한 후임들의 의견을 받아들이고, 장점을 역량껏 펼칠 수 있도록 노력했었다.
물론 군대 분대장 경험을 사회의 리더 역할과 완전히 동일하게 비교할 수는 없다는 걸 알고, 더 깊고 넓은 리더십 경험을 가진 사람들과 비교했을 때 나의 경험이 부족해 보일 수도 있다. 그렇지만 중요한 건 내게 주어진 환경 속에서 나에게 맞는 리더의 유형을 찾아갈 수 있었고, 내가 어떤 방식으로 팀을 이끄는 것이 잘 맞는지를 스스로 실험해 볼 수 있었던 큰 배움의 시간이었다.
지금은 디버깅이나 주어진 구현 사항들을 마치 알고리즘 문제를 풀듯이 분석하고 해결해 가는 과정 자체가 즐겁지만, 언젠가 전문가(실무자)의 길과 관리자의 길 사이에서 하나를 선택해야 하는 순간에 이 책을 읽으며 했던 생각들이 도움이 돼, 올바른 방향으로 나아갈 수 있게 도와줄 거라 믿는다.
모든 길의 종착지는 사용자
책 전반에 쓰인 글들을 종합해 보면 “우리에겐 작은 트래픽 하나지만, 누군가(사용자)에겐 번거로움과 피해로 이어질 수 있다.”는 책 속의 문장에서 엿볼 수 있는 결국 모든 길의 종착지는 사용자였다.
예를 들어, 허위 리뷰를 막기 위해 머신러닝을 도입한 이유 역시 사용자에게 정확한 정보를 제공하기 위함이었고, 다양한 서비스 개선도 결국엔 사용자가 불편을 겪지 않고 편리하게 쓸 수 있도록 하기 위함이었다.
“만드는 사람이 수고로우면 쓰는 사람이 편하고, 만드는 사람이 편하면 쓰는 사람들이 수고롭다.”는 우아한 형제들 팀의 문구를 보고 내 개인 프로젝트가 떠오르기도 했다. 개인 프로젝트를 진행하면서 “어떻게 하면 사용자가 더 편하게 사용할 수 있을까”를 고민했고, 그 고민이 더 어려운 길이었지만 늘 1순위로 선택했었는데 그 방향이 틀리지 않았다는 확신과 위안도 얻을 수 있었다.
할 얘기가 많지만
이외에도 이 글에서 미처 다루지 못한 양질의 오답 노트와 인사이트들이 정말 많이 담겨있다.
- 좋은 테스트 코드 시나리오는 결국 명세가 된다는 점 (+ 좋은 테스트 코드 작성 기준)
- 지식이 부족한 상태에서 당시로서 가장 나은 대안을 찾는 방법
- 개발자 머피의 법칙을 대비하는 법 (“어, 이거 이렇게 하면 잘못될 것 같지만, 에이 설마 …”)
- 우아한 형제의 외부 라이브러리 선택 기준
- 외부 시스템에 대한 대처방안
- 등등…
그러니 현직 개발자든, 취업을 준비하는 예비 개발자든 누구라도, 본인의 상황에 맞게 커스터마이징해 적용해 보고 나아가 그 경험을 다른 사람들과도 나눈다면 더할 나위 없이 기쁘겠다. 그럼 이만!