그런 개발자로 괜찮은가
'문화' 편
개발자로 살아가는 데 있어 가장 중요한 게 무엇일까? 물론 개발할 수 있는 '기술'이 가장 중요하겠지만 몇 년 전부터 기술의 발전이 급변하는 세상 속에서 과연 기술만이 중요할까? 기술만 잘 알고 있으면 복잡하게 꼬인 스파게티 면 같은 문제 많은 코드를 술술 풀어헤치고, 언제 어디서든 개발자로서 행복한 삶을 영유할 수 있을까?
여러 가지 중요한 요소들 중 가장 첫 번째로 떠오르는 키워드는 바로 문화(Culture)가 아닐까 싶다. 그렇다면 문화는 개발자에게 어떤 점에서 중요하고 어떤 식으로 만들어 가는 게 좋을지에 대해 정리해보고자 한다.
[그림 1] 각 팀에 맞는 문화는 모두를 성장시킬 수 있다.개발자라는 직업을 가지고 있는 분들 중에 프리랜서나 1인 스타트업을 운영하는 분들은 제외하고 대부분의 사람들은 여러 명과 함께 공동의 목표를 달성하기 위한 “팀"이라는 단위에 소속되어 개발을 하고 있다. 야근을 매일 밥 먹듯이 하는 조직도 있을 테고 이른바 워라벨을 잘 지키며 듣기만 해도 반가운 소리인 “칼퇴"를 밥 먹듯이 하는 조직도 있을 테고. 여기서 말하고자 함은 이러한 야근 vs 칼퇴처럼 “근무 시간의 양"에 대해 이야기하려는 건 아니다. 회사, 더 깊게는 팀 내에서 어떤 문화 안에서 개발자로 살아가고 있는지에 대해 이야기하려 한다.
코드 리뷰 (code review)
팀에 속해서 개발을 하다 보면 같은 코드를 동시에 작업하곤 한다. 그래서 형상관리 도구 (요즘 git을 안 쓰는 곳이 없을 정도…)를 사용해서 동시에 개발을 진행해도 전혀 무리가 없을 정도인데 결국 작업한 결과물을 한 곳으로 병합 (merge) 해야 하는 시점이 오기 마련이고 그 시점에서 코드 리뷰(온라인/오프라인)를 하게 된다. 어떠한 사연으로 코드 리뷰 없이 빨리 merge 해야 하는 건 이해되지만 가급적 한 명 이상의 리뷰어가 승인을 한 뒤에 merge 가 돼야 한다고 생각한다(pullRequest를 단순 merge 용으로 사용하는 건 정말 잘못된 방법 중 하나). 여러 명의 하나의 코드를 변경하는 시점에서 해당 코드를 어떤 의도로 변경하는지, 중복된 코드를 만들었거나 작업자가 예상하지 못한 부분들을 릴리스 전에 서로 이야기해보면서 버그를 수정하거나 팀 컨벤션, 설계/구조를 더 효율적으로 가져갈 수 있는 절호의 찬스이기 때문이다.
여기서 중요한 포인트는 리뷰를 받는 ‘리뷰이’ 와 리뷰를 해주는 ‘리뷰어’들의 문화적인 측면에서 생각을 해볼 필요가 있다.
리뷰이(Reviewee)
리뷰어의 소중한 시간을 할애해서 자신의 코드가 이상이 없는지에 대한 ‘도움’을 요청하는 것이기 때문에 최대한 설명을 잘 적어서 리뷰하는 데 도움을 줄 수 있어야 한다.
작업을 하다 보면 한 번에 몰아서 코드 리뷰를 받는 경우가 대부분이지만 개발 생산성 측면과 코드 리뷰의 집중도, 병합 시점에서의 코드 충돌 최소화, 리뷰 시간을 줄이는 측면에서는 최대한 작은 단위로 리뷰를 요청해야 한다.
리뷰가 진행이 되지 못하여 다음 작업 또한 진행을 못하는 경우가 생기는 것을 방지하기 위해 최대한 코드 리뷰받는 부분과 의존성이 없도록 작업이 돼야 하며 그도 아니라면 정중하게 리뷰어에게 ‘부탁’을 해야 한다. (요청 이 아니라는 점!)
리뷰어의 리뷰는 “지적” 이 아니라 “함께 작업하는 코드에 대한 조언"으로 받아들여야 한다. 혹 리뷰 내용이 자신의 생각과 다르다면 토론을 통해 합의점을 찾도록 해야 한다. (무조건 리뷰어가 리뷰했다고 기계적으로 고치는 것 또한 잘못된 부분)
리뷰어(Reviewer)
리뷰이는 당신의 한마디를 간절하게 기다리고 있을 수도 있으니 최대한 정성껏 리뷰를 해주자.
온라인 코드 리뷰를 하게 된다면 “텍스트"라는 제한적인 상황에서 최대한 유연한 멘트로 코드 리뷰를 해야 한다. (자칫 잘못하다간 서로 오해가 있을 수 있으니…)
코드 양이 많다거나 리뷰를 할 수 없을 정도로 이해가 잘 안 된다면 리뷰이에게 리뷰에 도움이 될 수 있는 추가적인 내용을 요청하여 리뷰가 대기(pending) 상태로 되지 않도록 하자.
코드 리뷰 관련된 문화에 대한 내용들은 잠깐만 검색해봐도 훌륭한 포스팅들이 나오니 참고해봐도 좋을 것 같다.
공유 (Share)
무언가를 공유한다는 건 정말 나 잘했어요~ 내가 최고예요~ 하는 ‘자랑’이 목적일까? 필자가 생각하는 공유의 목적은, 자신이 했던 부분들을 ‘다시 정리’함으로써 내 것으로 만드는 과정이 되고 이를 여러 사람들에게 공유함으로써 생각을 나누며 함께 고민한다는 부분이 가장 큰 것 같다. 거기에서 나오는 시시콜콜한 의견들은 공유했던 내용을 더욱 올바른 길로 성장시켜줄 수 있고, 공유라는 작은 날갯짓이 팀, 나아가서 조직 내에 큰 바람을 일으킬 수도 있기에. 강조해서 이야기 하지만 공유는 자기 자신을 돌아볼 수 있는 훌륭한 방법이다.
어떠한 문제로 운영하고 있는 서비스가 장애(서비스를 이용할 수 없는 상태)를 맞았다고 가정해보자. 관련 담당자는 부랴부랴 장애를 수습하기 바쁠 테고 시간이 지나 다시 원상복구를 하기 마련이다. 장애를 복구해서 끝났다고 생각하면? 안타깝지만 그걸로 끝인 거다. 무엇 때문에 장애가 났는지 장애 원인을 파악하고, 동일하거나 비슷한 문제에 대해 방지하기 위한 수단은 무엇이며, 이러한 장애가 발생했을 때 어떻게 처리했는지에 대해 공유가 이루어진다면 함께 일하는 조직원들은 적어도 그러한 문제에 대해 경각심을 느끼고 더 조심히 꼼꼼하게 개발할 수 있을 것이다. (공유를 받고 스팸 처리한다면 할많하않…)
신입이던 10년 차 개발자이던 개발을 하다 새로운 기술이나 어려웠던 부분을 해결했던 경험을 공유한다고 가정해보자. 공유를 하는 사람은 소가 뒷걸음치다 얼떨결에 쥐를 잡는 것처럼 되는 게 아니라 제대로 정리를 할 수 있는 기회가 될 것이고, 공유를 받는 팀원들은 직접적으로 해당 상황을 재현하지 않아도 공유 내용을 간접 경험해 볼 수 있는 정말 좋은 기회가 될 수 있다.
무엇을 공유해야 하지 모를 땐, 아주 사소하게라도 오늘 알게 되었던 새로운 지식을 짤막하게라도 적어보는 습관을 길렀으면 한다. 나아가 팀에서 운영하는 서비스의 기술 부채를 파악하고 개선하여 공유를 하거나, 외부에서 들은 좋은 내용들을 팀 내에 도입한다거나. 다들 SODD를 한 번쯤은 해봤을 테니 하루에 하나 이상은 새로운 사실을 (혹은 알고 있었는데 제대로 숙지하고 있지 못하는 부분) 알게 될 것이라 생각한다. 무엇을 공유할지 모르는 게 아니라 공유한다는 습관이 부족한 건 아닐까.
사소한 공유 내용이 한때는 너무나 기초적이라 당연하다거나 오히려 자신의 밑천을 드러내는 것처럼 되어버린다는 생각을 가질 수도 있다. 하지만 누군가에겐 소중한 도움이 될 수 있고 부끄럽거나 쪽팔리다는 생각은 잠시뿐이며 오히려 그 기회를 통해 기초를 다잡는 순간으로 얼마든지 활용할 수 있다.
개발 관점에서의 시야 (insight)
회사는 언제나 바쁘다. 사업의 성공을 위해 하나의 팀에 속한 설계, 기획, 디자인, 개발, QA 등 다양한 직군들은 공동의 목표를 안고 열심히 달린다. 모든 직군들은 최종 결과물을 만들기 위해 사업에 필요한 여러 가지 복잡한 스펙들을 구현하기 바쁘고, 그러다 목표로 했던 일정에 맞추어 서비스를 릴리스 하는 데 성공한다. 그렇게 출시를 하고 나면 이제 두 발 뻗고 기다리기만 하면 될까? 아니다. 2차 3차를 넘어 또 다른 스펙들이 무섭게도 들어온다. (서비스 오픈 축하 회식조차 못하고…ㅠㅠ)
가장 이상적인 모습은 모든 직군들 이 일정과 스펙 협의가 끝나고 안정적으로 충분한 테스트를 거친 다음 서비스 릴리스가 돼야 하지만. 아쉽게도 서비스 릴리스 일정은 이상하게도 거꾸로 들어온다. 즉, 'X 월 Y 일에 출시하겠습니다.'라고… 그러한 악순환은 결국 최 말단(?)인 개발자들에겐 숨 막히는 야근으로 변질되고 울며 겨자 먹기식으로 개발을 하게 되지만, 하나의 스펙을 구현하기에 급급한 코드, 서비스의 스케일이 커졌을 때 확장하기 어려운 구조, 넘쳐나는 중복 코드와 예상하지 못한 문제들까지. 이러한 ‘기술 부채’는 점점 커지고 무거워져 코드를 건드리지 못하다 결국 하나둘 팀을 떠나게 되는 안타까운 모습이 반복된다. 이러한 부분들은 도대체 언제쯤 해결할 수 있을까? 그리고 누구의 탓일까? 한편으론 '한두 달만 서비스 유지만 하고 기술 부채 점검 좀 하겠습니다.'라는 도발적인 목표를 제시하고 싶으나 과연 그런다고 해결이 될까?
아무리 바빠도, 개발자는 개발 관점에서의 시야를 놓쳐서는 안 된다. 여기서 말하는 개발 관점에서의 시야는 모니터링, 중복 코드, 알림 (에러, 시스템, 기타 모니터링 지표 등), 구조/설계, CI/CD, 자동화 등 기능 개발 이외의 다양한 부분들. 이러한 부분을 리더, 혹은 일부 팀원만 관심을 갖는다면 개선이 될 거라는 기대는 너무 이기적인 생각이다.(누군가 하겠지, 내가 작업한 게 아니야, 개발할 시간도 없는데! 이런 문화가 팽배한 조직은 멀리 가지 못한다고 생각한다.) 모두가 함께 코드와 개발적인 요소들에 대해 관심을 갖고 개선의 의지가 있어야 그 개발팀은 건강하게 성장하고 오래 있고 싶거나 외부에서 오고 싶은 팀이 될 수밖에 없을 것 같다. (자신이 작업한 게 아니라 신경을 끄겠다는 사람들이 있다면… 정말 묻고 싶다. 왜 이 ‘팀’에 있는 거냐고.)
어떻게 하면 좋을까?
문화적인 측면에서 위에서 이야기한 것 말고도 정말 다양한 부분들이 많다. 애자일부터 시작해서 DevOps, SRE, 팀 컨벤션, 개발 규칙 등 개발 문화는 엄청난 시간 복잡도를 요하는 알고리즘과는 또 다른 측면에서 상당히 중요하다고 볼 수 있을 것 같다. 그렇다면 어떻게 하면 개발 문화를 좋은 방향으로 바꿀 수 있을까?
임백준 님 Facebook사실 위 임백준 님의 페이스북 글을 보고 뒤통수를 맞은 느낌이 들어 이 포스팅을 쓰기 시작하게 되었다. 한때 ‘여기는 도저히 있을 곳이 아니야’, ‘이 조직의 문화에 점점 지쳐간다’라며 이직을 생각해 보았던 필자 자신이 부끄러울 정도로. 물론 자신이 팀의 문화를 바꾸기 위한 위치(?)가 아니라면 (혹은 영향력이 없다면) 문화를 바꾸는데 힘들 수 있겠다고 말할 수 있겠지만 꼭 팀의 리더나 연차가 어느 정도 있어야지만 팀의 문화를 바꿀 수 있을까? 아니다. 위에서 이야기했던 부분들을 조금씩 ‘꾸준하게’ 해 나가면서 영향력을 펼친다면 언젠가는 그 팀의 문화가 바뀔 거라 자부한다. 물론 그 팀에 오랫동안 있던 분들(나쁘게 말하면 고인 물…)의 의견이 강하다면 그들을 설득하는 방법부터 바꿔봐야 한다. ‘레거시는 과거의 최선이었다’라는 명언은 무시할 수 없듯이 각 팀에 ‘맞춤형’ 문화를 만들어 나가야 한다.
이러한 ‘문화’ 적인 측면에서는 한 사람의 노력만으로는 절대 바뀔 수가 없다. 어떤 문화가 좋은 문화라는 정답은 없지만 적어도 현재에 안주하려 하고 변화를 싫어하는 모습들은 팀의 성장을 방해할 수밖에 없지 않을까? 회사와 팀 그리고 개인의 성장을 도모하는 문화 속에서 즐거운 개발을 할 수 있기를 바라본다.
우선 이 글을 읽는 여러분의 ‘팀’이 가지고 있는 다른 팀과 다른 유일무이한 문화가 있는가?부터 생각해보자. 없다면 사소한 것부터 만들어 나가야 하고, 있다면 과연 그 문화가 모두의 성장과 발전에 도움이 되는 문화인지 점검하는 과정이 필요하지 않을까.
이미지 출처
