2023.07.07 스타트업에서 일한다는 것 (feat.구글 엔지니어는 이렇게 일한다, Chapter 1-2를 읽고)

작년에 한참 이 책이 많이 읽힐 때 사놓고 막상 손은 안갔는데, 요새 틈틈히 읽고 있다.
얼마 읽지 않았지만 생각할 거리를 많이 던져주는 것 같다.

Chapter1. 소프트웨어 엔지니어링이란?

본격적으로 시작하기에 앞서, 먼저 두 가지 중요한 개념이 등장한다.
바로 프로그래밍(개발)과 소프트웨어 엔지니어링(개발+수정+유지보수)이다.

이 두 가지를 스펙트럼의 양 끝단으로 놓고 본다면, 현재 스타트업에 재직하고 있는 프로그래밍에 좀 더 가까운 상황인 것 같다.
내가 막 입사를 했을 때 새로운 서비스 개발을 막 시작한 상황이었고, 최근까지도 큰 업데이트를 여러차례 진행했다.
빠르게 서비스를 런칭하고 여러가지 상황들을 시험해야하는 스타트업의 특성 상 우리는 대규모 업데이트만 해도 꽤 자주 진행했고, 새로 기획이 나올 때마다 기존 기능이 아에 사라지거나 신규 기능을 개발하는 경우도 많았다.
정말 며칠 전에 개발한 기능이 갑자기 아에 빠지는 경우도 있었다.

회사 상황상, 그리고 이러한 의사결정이 이루어진 과정을 공유하고 있기 때문에 
충분히 이해할 수 있는 상황이다.
그럼에도 최소한 유지보수를 위해 비즈니스 로직과 ui는 구분하려고 노력하고 있고, 가끔은 자주 변경이 있는 상황에서 유연하게 대처가 되기도 한다.

그렇지만 보통 기획이 나오면 빠른 출시를 위해 개발 일정을 빠듯하게 잡는 경우가 많아서 꼼꼼하게 코드리뷰를 하거나 코드 퀄리티를 신경쓰기에는 시간이 촉박하다.
또 언제 사라질지 모르는 코드에 배포 일정을 미루면서까지 시간을 들이는 것도 적절하지 않다고 생각한다.

그래서 매번 개발할 때마다 이번 업데이트 끝나면 코드 정리를 하자고 말하지만 뭔가 해보기 전에 새로운 기획이 나오는 경우도 많다😂

서비스 정식 출시도 됬고, 아마 이런 대규모 업데이트는 앞으로 점점 줄어들지 않을까 싶다.
그런 의미에서 우리 회사도 점점 소프트웨어 엔지니어링 쪽으로 나아가야하지 않을까.
그럼에도 조금 더 소프트웨어 엔지니어링을 경험할 수 있는 팀에서 일해보고 싶다는 생각도 있다.

Chapter2. 팀워크 이끌어내기

이 쳅터는 정말..... 뼈 때리는 구절이 많았다.
혼자가 아니라 팀으로 일한다는 것, 그리고 어떻게 해야 팀으로 단순히 개인이 모인 것보다 더 좋은 시너지를 낼 수 있을까 생각해보게 된다.

#사실 일할 때는 혼자 있는게 편해요

사이드 프로젝트에서 앱 개발을 혼자 진행하고 있고, 회사에서도 주1회는 보통 재택을 하고 출근해서도 유연근무 + 공용 오피스 라운지에서 할 때가 많아서 최근에는 특히 혼자 일하는 경우가 많은 것 같다.

책을 읽으면서 혼자 일하는게 편한 점은 분명 있지만 그럼으로써 내가 놓치고 있는 게 무엇일까 다시 생각해보게 되었다.

혼자 일하는게 편하다는 이유만으로 커뮤니케이션을 놓치고 있는 건 아닐까?
그런데 커뮤니케이션은 반드시 오프라인 공간을 통해서 이뤄져야 하는가?

회사와 부트캠프에서의 경험을 생각해보면 다 하기 나름인 것 같다.
(거의 재택한다는 시니어 개발자분에게 팀 내 의사소통 문제가 없냐고 물었을 때, 온라인으로 커뮤니케이션이 잘 안되는사람은 오프라인도 잘 안된다는 재밌는 답변을 받은 적이 있다)

사무실에서도 서로 대화 전혀 안하는 사람은 정말 자기 일만 하기도 하고, 또 서로 뭐하고 있는지 물어보거나 도움을 청해서 더 좋은 결과가 나오기도 했다.
부트캠프는 게더타운에서 진행했는데 거기서도 의사소통이 잘되는 사람과는 진짜 이런저런 얘기도 많이 했었고, 팀내 회의 진행할 때도 전혀 문제 없었다.

항상 사무실로 출근하지 않아도 되는 환경에서 일하고 싶다는 꿈이 있다보니 자기 변명 같기도 하지만, 꼭 오프라인으로 한정시킬 필요는 없는 것 같고, 어떤 환경에서도 어떻게 하면 의사소통을 잘 할 수 있을지 고민하는게 필요한 것 같다.

# "지금은 바쁘니 가능한 방해하지 말라"

사무실에서 여러 사람들과 함께 일할 때 내가 다른 사람을, 혹은 다른 사람이 나에게 갑자기 무언가를 물어보는 걸 선호하지 않는다.
특히 개발 특성상 집중하고 있다가 갑자기 깨지는 경우에 대화를 마치고 돌아왔을 때 다시 맥락을 잡아야 하는 경우가 있는데 흐름이 끊기는 것 같다.

그래서 코멘트나 dm처럼 바로 응답하지 않아도 되고, 상대방에게 내가 얘기할 것이 있다는 의사만 표현할 수 있는 수단을 선호하는 것 같다.

책에서도 구두로 "브레이크 포인트"라고 말하거나, 다른 방법을 사용해서 "지금은 바쁘니 가능한 방해하지 말라"는 뜻을 표현하는 방법을 만드는 팀이 많다는 얘기를 한다. 지금 우리 팀에서는 별다른 규칙은 없지만 필요하다면 이런 규칙을 만드는 것도 좋을 것 같다.

사실 지금 회사도 그렇고 전 회사에서도 사수나 가까운 팀원들에게 내가 방해할 수도 있으니 dm으로 도움을 청하는게 좋은지, 구두로 바로 물어본 적이 있다. 다들 dm보다는 구두로 바로 말해달라고 했다. 온라인보다 오프라인 대화를 좀 더 선호하는 것 같고, 본인이 집중하고 있는 상황이면 바로 조금 이따가 얘기하자고 말해줄 수 있으니 업무에 있어서도 크게 지장은 없는 것 같다.

#내 코드와 나를 동일시하지 말기

pr을 올려놓고 코멘트가 달릴 때마다 깜짝깜짝 놀란다. 누군가 내 코드를 리뷰해 준다는 건 정말 고마운 일이지만 코멘트가 다다다다 쌓일 때면 멘탈이 살짝 흔들리기도 한다.

그럴 때마다 잊지말자, 내 코드는 내가 아니다.
그리고 나에게 다른 방법이 있다고 알려주는 사람이 있다는 건 정말 감사한 일이다.

#비난하지 말기

회사에서 다른 팀원이 나와 다른 생각을 가지고 있다고 생각될 때, 특히 내 생각이 더 적절하다고 생각될 때, 상대방에게 어떻게 내 의견을 전달하는지는 정말 중요하다.
내가 맞고 상대방이 틀렸다는 생각으로 접근하면(설령 정말 그렇다고 하더라도) 상대를 비난하게 되고 좋은 관계를 형성할 수 있다.

종종 이 코드는 잘못짠 코드이고, 이게 올바른 방식이야, 라는 말을 하는 경우가 있다.
소위 말하는 클린코드, 지향점은 있을 수 있지만 정말 코드에서 정답이 있는지는 잘 모르겠다.
그리고 이렇게 말하는 경우에도 사실을 정말 정답이 있다고 생각하기 보다는 더 좋은 방법이 있을거라고 생각할 것 같다(그랬으면 좋겠다)
그렇지만 이런 말을 들었을 때 내 코드와 나를 동일시 한다면 내가 잘못한 것 처럼 느껴지기도 하고, 스스로 많이 부족하다는 생각도 든다.

상대방보다 내 생각이 더 나은 방법이라고 생각해도, 사실 내가 생각하지 못한 의도가 있을 수도 있고, 내가 생각한 것보다 좋은 방법일 수도 있다.
그래서 이런 경우에는 상대방과 대화를 하면서 서로 어떻게 생각하고 있는지 들어보고 의견을 나누는 시간이 필요하다.
회사에서도, 팀프로젝트를 할 때도 간혹 의견이 다른 경우 대화를 하다보며 더 좋은 해결책이 나오곤 했다.

다만, 이 과정에서 어떤 표현을 사용하는지는 논의의 결과와 상대방과의 관계에 큰 영향을 줄 수 있다.
내 의견을 관철하기 보다는 상대방의 의견을 먼저 충분히 듣고, 내가 어떤 의도로, 어떤 이유 때문에 이렇게 생각했다고 말하는게 도움이 되는 것 같다.
또 잘못과 같이 옳고 그름을 표현하는 단어보다는 우리 프로젝트에 더 잘 맞는 방법을 지향하는 쪽으로 대화를 이끌어 가는게 좋다고 생각한다.