상대적 행복

취업 전과 취업 후는 느끼는 시야가 다릅니다. 많이 달랐습니다. 우선 정말로 행복했습니다. 그동안 독학을 하면서 사수들에 대한 질문이 고팠으니까요.

일단 업무 환경이 너무나 행복했습니다. 이전 직업이 직업군인 이었던지라 유연출근제와 같은 스타트업 문화가 너무나 달았습니다. 지금도 그렇고 앞으로도 업무환경에 대해서 불만이 전혀 없을 것 같아요. 인간 관계의 스트레스도 없을 것 같습니다. 전 직업과 비교해 환경적으로 너무 좋아졌기 때문일까 행복에 겨워있던 저에게 팀원분들께서 심하게 긍정적이라고 하셨어요. 이런말은 좋게 받아 들이려고 합니다. 하지만 힘든 것도 좋다고 생각했습니다. 힘든 것을 겪고나면 분명히 성장하는 자신을 볼 수 있기 때문이니까요.

좋은 개발 문화를 위하여

처음에 입사하고 독학하던 습관 때문에 개발환경을 세팅하고 스텍을 공부하면서 모르는 것이 있으면 일단 스스로 어느정도 답을 도출할 때까지 파보고 있었습니다. 이점 덕분에 차후 질문하면서 빠른 이해를 거듭할 수 있었고 질문의 범위를 축소하며 구체적인 그림을 그릴수 있었습니다. 하지만 문제는 '효율' 이었죠. 취업 전에는 시간이 남아돌아서 무작정 시간을 때려부어서 원하는 답과 깊이를 채워나갔습니다.

하지만 회사는 달랐습니다. '효율' : '시간의 가성비'를 아주 중요하게 여겼습니다. 그런점을 보면서 스스로 하나의 착각을 했었던 점도 있었습니다. 나의 시간은 시니어의 시간에 비해 별로 중요하지 않다. 라는 착각을 요

시니어 : 10분 정도 고민하고 모르겠으면 질문을 통해 같이 고민해봅시다.
나 : 시니어의 시간과 저의 시간은 다르니 너무 많은 질문은 민폐가 되지 않을까요?
시니어 : 시간적인 가치는 그럴 수 있지만 길게 봤을 때 그렇지 않아요. 너무 스스로 길게 고민하다가 나온 결과물은 도리어 질이 낮은 코드가 될 수 있어요. 또 저는 좋은 주니어를 키워 장기적으로 좋은 선순환을 만들어가는 개발문화를 만들어가는 것이 더 중요하다고 생각해요.

좋은 개발문화 라는 토픽은 정말로 매력적인 주제였습니다. 내가 고민을 하고 질문을 하며 코드를 짜고 리뷰를 받는 모든 것이 우리회사의 개발문화로서 합류하기 때문이죠. 좋은 개발문화를 위해, 더 나은 소통 구조를 위해 끊임 없이 git flow 전략을 바꾸고, 배포 전략을 바꾸고, 협업방식을 조율하는 과정은 그자체로 앞으로 나아가는 성장력이었습니다.

정말로 중요한 것은 효율이 문제가 아니라 '좋은 개발 문화'를 만드는 것 그자체로 보였습니다. 나의 행동과 말이 개발문화가 되므로 자그마한 질문이나 테스크를 처리할 때에도 어떤 과정을 거쳐야 하는지, 왜 그러한 과정을 거쳐서 행동을 해야하는 지 스스로 검증을 해야했습니다. 그러면서 매일 그러한 고민을 팀과 공유하고 피드백을 받으면서 팀의 협업 방식은 지금도 항상 변하고 있습니다. [ 문서화된 협업방식은 계속 업데이트 되어갑니다. ]

왜 개발을 하는가?

취업하기 전에 배민이 뽑고싶은 개발자 라는 유튜브 영상을 보고 비즈니스 문제를 고민하는 개발자가 되어야 한다.라고 막연히 생각하고 목표로 삼았던 기억이 있습니다. 실제로 면접을 보면서 포부를 밝힐때에 많이 말했죠. 하지만 실제로 왜 필요한 지에 대해서 느껴본적은 없었습니다. 취업 전이 였으니까요.

자그마한 테스크들을 처리하며 팀의 코드에 적응하던 와중 제가 올린 PR을 리뷰 받을 때였습니다.

시니어 : 이 테스크는 전혀 할 필요가 없을 거 같은데 이렇게 한 이유를 알 수 있을까요?
나 : 이건은 QA에서 올라온 건으로 이렇게 동작을 해야해서 고쳤습니다.
시니어 : 정말인가요? 제가 알기로 저희 정책상 애초에 그렇게 동작을 하면 안될 것 같은데요.
나 : ... 아, 제가 정책을 한번 살펴볼게요.
시니어 : ( 왜 이렇게 동작을 하면 안되는지 정책을 설명하며 ) 같이 PO님께 가서 기획이 맞는지 그리고 기획의 배경에 대해서 물어보시죠.
PO : ( 시니어의 설명을 듣고 ), 이점은 브렌딩실에서 이러한 의도로 이벤트를 열게 되었습니다. 그런데 정책상 이동작은 이번 이벤트에서 동작하면 사용자에게 다른의도로 전달 될 수 있겠네요. 회의에서 다시 논의해보겠습니다. 저희 정책상 그런 동작은 하면 안돼요. 이부분은 정책변경건과 연결되니까 다음 일정에 함께 다시 진행하겠습니다.
시니어 : 네, 알겠습니다. 두드림님 PR은 close 해주시고 QA 팀에게 멘션 걸어주세요. 항상 개발을 하기전에 기획과 맞는지 살펴보시고 그기획의 배경에 대한 이해를 해주셔야 정확한 의도를 맞고 개발을 할 수 있어요.
나 : 넵! 정말 감사드립니다!! ( 대박 교훈이다. )

비즈니스 문제를 고민하는 개발자가 되겠다던 포부를 지닌 신입개발자는 어느새 자기도 모르게 코드짜는 것에만 집중한 채 들어오는 일만 처리하는 코드 머신이 되었던 것이죠. 생각으로는 알고 있었으나 경험으로 겪은 것은 정말 달랐습니다. 내가 짠 코드가 얼마나 좋은 코드이기전에 애초에 할 필요가 없던 일이거나 도리어 함으로서 잘못된 동작을 야기 시킬 수 있던 선례였습니다.

비즈니스와 개발

실제로 돈이 움직이는 회사에서 개발은 정말 그 실행여부를 두고 손해와 이익을 보게 됩니다. 잘못된 협업방식은 회사의 직접적인 손해를 미치게 됩니다.

PO : 마케팅 실에서 갑자기 예고도 없이 이런 이벤트를 열었는데 일단 개발자 분들께 가능 여부를 알아보고 싶어요. 잘못된 일처리 방식이라 마케팅 부서와는 다음부터 이러한 부분은 함께 회의를 하자고 강경하게 이야기 했습니다. ( 어떤 이벤트 인지 설명 )
시니어들 : 후 ... 그걸 그때까지 하자구요? 저희가 감당가능 할 수 있을지 테스트 기간도 필요합니다. 저희는 그기간안에 맞추지 못해요. 이벤트 미뤄야 합니다.

위와같은 경험들을 같이 보고 경험하면서 내가 지금 짜고 있는 코드는 어떤 배경에서 이뤄지는 결과물인가를 명확하게 짚어보게 되었습니다. 이코드를 왜 짜는지 모른다면 실제로 기획과 동작이 조금씩 비틀리며 의도가 달라지게 되고 이는 곧 회사의 손해로 이어지기 때문입니다. 혹은 두번 세번 시간적으로 여러번 일을 하게 됩니다.

치밀한 테스트

우리회사는 역동적인 성장과 함께 너무나 자주 바뀌는 역동적인 UI 때문에 프론트 유닛테스트를 하고 있지는 않습니다. 다만 일년의 목표로서 테스트 케이스 달성률을 세웠고 퍼센트를 높이려고 하고 있습니다.

그과도기에서 [개발자의 테스트 -> 동료의 검증 -> QA -> 서비스 배포] 라는 흐름으로 코드가 검증하고 있는데 가장 첫번째인 개발자의 테스트가 저에게는 가장 중요했습니다. 개발을 하면서 당연히 되겠지 하던 코드들이 실제 서비스 배포가 끝나서야 실제 사용자들의 다양한 환경에서 동작하며 hotline 이슈가 되는 경험들이 신입인 저에게는 너무 많았습니다. 위의 코드의 검증으로 어느정도 검증을 마쳤다 한들 개발자의 테스트로서 먼저 거르는 작업이 많아야 합니다.

이론은 가능하지만 실제로 되는지 테스트하는 것은 별개입니다.

사파리, 크롬, 안드로이드 시스템 웹뷰, 크롬 웹뷰, 싱글 웹뷰, 멀티 웹뷰등 수많은 케이스에 대해서 이코드가 어떻게 동작할지 고려하며 특정 환경에서 라이브러리나 함수가 다르게 동작하는 경우들을 생각합니다.

이러한 경험들은 정말로 수많은 경험들로 채워가야합니다. 경험과 이론에 기반한 치밀한 테스트와 논리적인 추론, 디버깅 능력도 경력 개발자의 힘의 일부처럼 보였습니다. 작은 디버그 작업이라도 아는 지식들을 총원하는 경험이 늘어가며 저에게 경력이 의미있게 생기고 있구나 라고 느끼고 있습니다.

회고

두달차 신입개발자가 회사에 겨우 적응하며 정말 많은 것들을 배웠지만 가장 인상 깊게 배운 것들을 잊고 싶지 않았습니다. 앞으로도 계속 좋은 경험들을 추가하며 의미있는 경력을 쌓고 좋은 개발문화를 위해 노력하는 개발자가 되도록 노력하겠습니다. 매일 매일 새롭게!