brunch

You can make anything
by writing

C.S.Lewis

by 정주홍 Mar 11. 2024

첫날의 인사

우리 엔지니어 조직에 새로 합류하시는 분들과 첫날에는 꼭 인사를 나누는 시간을 가진다. 말하자면 OT 시간인데, 우리 회사와 조직, 문화, 업무 방식 등에 대해 간략하게 말씀드린다. 수시로 채용을 진행하다 보니 같은 날짜에 많은 개발자 분들이 입사한 적이 없어서 1대 1로 이야기를 나눴었는데, 이번에는 그러기 어려울 것 같아 함께 인사를 나누기로 했다. 그러다 보니 즉흥적으로 설명하던 것보다 좀 더 정돈해서 말씀드려야겠다고 생각해서 정리를 좀 했는데 글로도 옮겨두려고 한다.

우리 조직을 관통하는 키워드를 하나 고르라고 하면 효율이라고 생각한다. 내가 처음 입사할 때부터 그랬었는데 아마 창립 멤버들의 성향이 그러하기 때문일 것 같다. 효율을 추구하다 보니 자리 잡은 문화나 업무 방식들인데, 어떤 식으로 발현됐는지를 생각하면서 읽어보면 더 재미있지 않을까 싶다.

먼저 문화 몇 가지를 꼽자면 중요한 것에 집중하고, 지속적으로 개선하며, 기쁘게 동료를 돕는 것 세 가지가 있다. 하나씩 살펴보자.

우리는 중요한 것에 집중하자는 문화를 갖고 있다. 어떻게 보면 너무나도 뻔하지만 실제로는 많은 곳들에서 지켜지지 않는 문화다. 예시를 생각해 보면 이렇다.

우리 개발팀이 그동안 제품 개발을 해오면서 만들어진 규칙들이 있다. 예를 들면 개발 작업에 들어가기 전에 테크 스펙을 작성하고 리뷰를 받는다거나, 배포 전에 코드 리뷰를 반드시 거쳐야 한다 등의 규칙들이다. 하지만 이렇게 규칙이 만들어지고 나면 오히려 규칙이 발목을 잡는 경우들도 생긴다. 아주 간단한 작업인데도 불구하고 모든 프로세스를 지키느라 하루 이틀이면 할 작업을 1주일 이상 걸리게 된다거나 하는 것이다. 규칙을 지키는 게 중요한 게 아니라 고객에게 가치를 전달하는 게 중요한데, 규칙을 지키느라 오히려 중요한 것을 하지 못하거나 늦어지는 꼴이다.

좀 더 코딩과 밀접한 것으로는 리팩토링이 있다. 리팩토링을 하는 이유는 앞으로의 새로운 기능 개발이나 유지 보수를 더 잘하기 위함이다. 다르게 말하면 새로운 기능을 개발하거나 유지 보수할 일이 없다면 리팩토링의 효용이 없는 것이다. 차라리 그 시간에 다른 무언가를 자동화하는 것에 리소스를 쓰는 게 더 나을 수 있다.

규칙을 만들면 안 된다거나, 리팩토링을 하면 안 된다는 식의 주장은 아니다. 하지만 내가 지금 하고 있는 행동들이 중요한 것에 집중하는 것이 맞는지에 대해 계속 고민하고 의심하는 것이 필요하다.

다음으로는 지속적으로 개선하는 것을 중요하게 생각하는 문화가 있다. 대표적으로 리뷰가 있는데, 더 좋은 코드를 만들기 위한 코드 리뷰, 주기적인 회고, 포스트모텀 등 수많은 종류의 리뷰들이 있다. 회고에서는 진행했거나 진행 중인 업무에 대해 어려운 점이나 불편한 점을 고려했을 때 어떻게 시스템을 개선하면 좋을지에 대해 이야기하기도 하고, 포스트모텀에서는 장애가 발생하게 된 근본 원인을 찾아서 해결하여 재발하지 않도록 하기 위해 노력한다. 그 외에도 주기적으로 1 on 1이나 동료 리뷰를 통해 피드백을 교환하면서 어떤 부분을 개선하면 좋을지 등에 대해 이야기를 나눈다.

나는 새로 합류하신 분들에게 적극적으로 아이디어를 제시해 주시길 부탁드린다. 기존 팀원들은 생산적이지 않은 방식인데도 불구하고 이미 익숙해져서 좋다고 느끼고 있거나 아예 아이디어가 없어서 개선할 생각도 못하고 있을 수 있는 것과 달리 새로 합류하시는 분들은 새로운 시각을 갖고 문제를 바라봐주실 수 있고, 이전에 경험했던 좋았던 방법 등을 공유해 주실 수 있기 때문이다. 우리가 더 개선하는 것을 추구하는 문화를 갖고 있기 때문에 새로운 아이디어를 제안해 주셨을 때 그분이 우리를 더 성장할 수 있게 해 주시는 분이라 생각해서 더욱 긍정적으로 보기도 한다.

마지막으로 기쁘게 동료를 돕는 문화가 있는데, 나만의 생각이 아니라 실제로 조직에 새로 합류하신 분들이 이 문화를 놀랍게 여기시곤 한다. 동료를 돕는 문화가 잘 작동할 수 있는 것에는 앞서 중요한 것에 집중하자는 것과도 일맥상통한다. 결국 일이 잘 되는 게 중요한데, 서로 도왔을 때 노력의 총합이 오히려 더 줄기도 하고, 일이 잘 되는 게 중요하지 누가 일을 얼마나 하냐를 따지지 않기 때문이다.

예를 들어, CS 조직에서 기술 관련 어려움이 있을 때 직접 찾아봐서 해결할 수도 있겠지만 개발팀에서 조금만 도와줘도 훨씬 빨리 문제를 해결할 수 있다. 그리고 개발팀으로부터 도움을 받기만 하지 않는다. 우리가 전달한 지식을 잘 재정리하여 다시 개발팀에 문의하는 일이 적어지도록 노력해 주신다. 또한, 우리도 시스템 장애를 종종 내곤 하는데, CS 조직에서 어려운 역할을 해주시기도 한다. 이런 상부상조 관계가 CS 조직 간에만 있는 게 아니고 프로덕트 개발 조직 내 다른 팀이나 세일즈 조직 등 전반적으로 모든 조직과 비슷한 관계를 가진다.

이러한 문화에서 만들어진 분위기가 많은 이들의 회사 생활 만족도 향상에도 꽤나 도움이 된다는 게 내 생각이기도 하다. 도움이 필요할 때 비난하는 게 아니라 발 벗고 나서줄 거라는 믿음이 있으니 안심되지 않을까.

문화에 대해서는 이 정도로 마무리하고 이제는 업무 방식과 관련하여 크게 커뮤니케이션과 협업 방식 정도를 이야기해보려고 한다.

우리는 커뮤니케이션을 할 때 핑퐁을 줄이는 것을 추구한다. 그러기 위해서 발화자가 더 정성을 들여서 메세지를 작성하고, 명확하고 간결하게 커뮤니케이션해서 오해를 줄이고, 더 많은 컨텍스트를 함께 공유해서 상대방이 상황을 정확하게 이해할 수 있게 하려고 한다.

일을 하다 보면 상대방이 무슨 의도를 갖고 말하는 것인지나 배경 상황을 몰라서 커뮤니케이션이 길어지는 경험을 하곤 한다. 커뮤니케이션이 길어지면 커뮤니케이션이 끝나지 않아서 일이 진행이 안 되고, 커뮤니케이션 과정에 포함된 사람들의 시간은 시간대로 또 많이 소모한다. 그래서 우리는 요청이나 질문을 할 때 맥락을 함께 전달하는 것을 선호한다. 예를 들어 질문 배경과 질문 이유(Reason of question, 줄여서 roq라고 많이 쓴다.) 등을 함께 쓰는 것이다.

최근에 커뮤니케이션이 잘 됐다고 생각되는 케이스가 하나 있었는데 아래와 같았다.

질문: 프론트엔드 팀에 질문드립니다. 권한 관리에 사용하는 A라는 API를 B API와 같은 방식으로 바꾸는 것이 프론트엔드 쪽에서는 얼마나 어려운 일일까요?

Roq: 권한 관리 시스템을 개선하고 있는데 A API의 작동 방식 때문에 어려움이 있습니다. B와 같이 바꾸면 유지 보수가 훨씬 쉬워져서 바꿀 수 있을지 알아보려고 합니다. 근데 프론트엔드 쪽에서 많은 작업이 필요하다면 기존 API를 당분간 유지하는 방식으로 작업할지 의사 결정할 때 참고하려고 합니다.

프론트엔드 팀에서는 작업을 한다면 1주일 이내로 가능할 것 같지만 최근에 밀린 일들이 많아서 언제 작업 가능할지는 예상하기 어렵다고 답변했고, 질문자는 이번에는 기존 A API를 유지하기 위해 자신이 좀 더 작업을 하는 것이 나을 것 같다고 의사 결정할 수 있었다. 또한, 커뮤니케이션 핑퐁이 거의 없게 결론에 도달하여 효율적이었다.

위와 같은 예시 외에도 다른 담당자나 상위 조직장에게 의사 결정 요청을 할 때 어떤 배경에 의해 의사 결정이 필요한지, 개인적으로 먼저 고민해 본 안과 장단점은 무엇인지 등을 함께 공유하곤 한다. 이렇게 하면 의사 결정권자가 커뮤니케이션을 통해 정보를 획득하는 단계를 없애거나 줄일 수 있다.

협업할 때는 커뮤니케이션을 더 많이 하는 것을 추구한다. 내가 지금 무슨 일을 하고 있는지에 대해 지속적으로 공유해서 엉뚱한 길로 새는 것을 방지하고, 막히는 부분이 있다면 적극적으로 도움을 청한다. 앞서 말한 우리의 문화가 있기 때문에 누군가 기꺼이 도와줄 것이라 믿는다. 문제를 해결하는데 어려움을 겪고 있다면 왜 도움을 요청하지 않았냐고 되묻는다.

그리고 액션 아이템을 도출하는 것을 매우 중요하게 생각한다. 특히, 회의에서 액션 아이템이 만들어지지 않으면 안 된다. 회의는 많은 사람들의 시간을 쓰는 정말 비싼 활동이기 때문이다. 나 또한 처음 입사했을 때는 액션 아이템을 만들면 일이 늘어나는 것 같아서 찝찝했었는데 이제는 상관하지 않는다. 일단 열린 마음으로 액션 아이템들을 나열해 보고 당장 최우선으로 해야 하는 것, 중요하게 챙겨야 하는 것, 나중에라도 하면 좋을 것으로 우선순위를 매겨 상황에 따라 처리한다.

이렇게 우리의 문화와 업무 방식을 열심히 말씀드리는 이유는 앞으로 함께 align을 잘해주시길 부탁드리기 위함이다. 그래야 손발과 사고방식이 잘 맞는 하나의 팀이 될 수 있기 때문이다. 물론 짧은 시간 내에 빠르게 설명드리다 보니 완벽하게 숙지하긴 어렵다. 하지만 책도 여러 번 읽으면 더 이해가 잘 되듯, 이렇게 한 번 설명을 듣고 나면 앞으로 경험하는 것들이 더 잘 와닿으시지 않을까 싶다.

keyword

정주홍 소속 직업 개발자

터프 프로그래머

구독자 622

작가의 이전글 신입 개발자들을 위한 구직 조언 의사 결정의 핵심은 타이밍 작가의 다음글

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari