좋은 동료를 잃고, 좋은 동료를 만났다

6월의 시작은 좋은 동료를 잃는 것으로 시작했습니다

빈집 팀은 PO, FE, BE, Design 직군의 총 6명 크루로 이루어져 있습니다. 각자의 직무는 다르지만, 하나의 목표를 이루기 위해 모인 목적 조직으로 활동하고 있습니다.

목적 조직은 단순히 각자의 역할만 잘 수행한다고 유지되는 조직은 아니라고 생각합니다. 서로가 바라보는 목적과 목표가 같아야 하고, 그 방향에 공감할 수 있어야 함께 나아갈 수 있습니다.

그래서 크루원 한 명이 팀을 나간다는 소식을 들었을 때 쉽게 받아들이기 어려웠습니다. 과거 좋은 동료를 잃었던 경험이 다시 떠올랐고, 이번에도 어떻게든 붙잡고 싶다는 생각이 들었습니다.

무엇이든 액션을 취하면 상황을 바꿀 수 있을 것 같았지만, 결국 동료의 결정을 바꾸지는 못했습니다. 그렇다면 적어도 이번 일을 단순히 좋은 동료를 잃은 경험으로만 남기고 싶지는 않았습니다.

그때부터 저는 동료를 붙잡는 것보다, 이번 경험을 통해 우리가 무엇을 배울 수 있을지에 조금 더 집중하기 시작했습니다.

우리는 무엇을 배울 수 있었을까

이번 활동은 제가 목적 조직에서 일해보는 첫 경험이입니다. 하지만 여기서 저는 목적 조직의 구성원이라기보다, 여전히 직군별 R&R에 갇힌 사람처럼 행동하고 있었습니다.

FE나 Design 영역에서 부족한 부분이 보이더라도 의견을 말하는 것보다 이게 참견이나 월권으로 느껴지지 않을까? 라는 생각을 했었습니다.

프로덕트에 필요한 의견이 있어도 직군이 다르다는 이유로 대화를 피하게 되었고 이런 태도는 오히려 하나의 목표를 바라봐야 하는 목적 조직에 적합하지 않은 행동이었다는 것을 알게 되었습니다.

좋은 결과가 나오면 어드바이스고, 나쁜 결과가 나오면 블레임일까?

프로덕트에 대해 깊이 고민한 뒤 더 나은 결과를 만들기 위해 나누는 의견이라면, 그리고 해결책을 제시하는 의견이라면 그것을 어드바이스인지 블레임인지 구분하는 것은 크게 중요하지 않다는 것을 멘토링을 통해 알게 되었었습니다. 그리고 서로 다른 생각을 꺼내고 충돌하며 더 나은 방향을 찾아가는 과정 자체가 협업이란 것을 알게 되었습니다.

그래서 상대를 설득하기 위해서는 논리적인 근거가 필요하고, 백엔드 엔지니어라면 데이터를 기반으로 문제를 설명하고 원하는 방향을 제안할 수 있어야 할 것 같습니다.

결국 이번 경험을 통해 적극적으로 의견을 내는 것과, 그 의견을 뒷받침할 근거를 준비하는 것이 목적 조직의 구성원에게 필요한 태도라는 것을 배웠습니다.

팀 전반의 근본적인 문제는 공감의 부족이었습니다

저는 처음에 이번 일을 제 행동을 중심으로 바라봤습니다. 내가 어떤 의견을 말하지 못했는지, 어떤 액션을 놓쳤는지를 생각하며 개인적인 회고를 이어갔습니다.

하지만 PO님과의 원온원을 통해 이번 사건을 조금 더 넓은 관점에서 바라볼 수 있었습니다.

PO님은 개인의 행동보다 팀 전체에서 사건이 어떻게 시작되었는지를 분석했고, 그 과정에서 우리에게 부족했던 태도로 ‘공감’을 이야기해 주셨습니다.

이 말을 듣고 나서야 우리가 사용자에게는 끊임없이 공감하려 하면서도, 정작 함께 일하는 팀원의 상황과 생각에는 충분히 공감하지 못했다는 생각이 들었습니다.

우리가 만들고 있는 프로덕트의 목적은 사용자에게 효용을 제공하는 것입니다. 그렇기 때문에 사용자의 문제와 감정에 공감하는 것은 중요합니다.

하지만 그 효용을 함께 만들어가는 사람은 결국 팀원입니다. 팀원이 어떤 생각을 하고 있는지, 어떤 어려움을 겪고 있는지 이해하지 못한다면 하나의 목표를 향해 지속적으로 나아가기는 어렵습니다.

결국 사용자에 대한 공감만큼이나 팀원에 대한 공감도 중요한 의사결정 요소가 되어야 한다는 것을 알게 되었습니다.

앞으로의 협업에서는 제 의견을 적극적으로 전달하는 것에 그치지 않고, 그 전에 상대의 생각과 상황을 이해하려는 태도에도 조금 더 비중을 두어야 할 것 같습니다.

새로운 뉴페이스의 등장

그렇게 한 명의 동료를 떠나보낸 뒤, 새로운 Design 파트 크루원을 만나게 되었습니다.

새로운 크루원이 팀에 잘 적응할 수 있도록 많이 괴롭?혀야 할 것 같습니다. 다만 이전처럼 각자의 역할 안에서만 대화하는 것이 아니라, 먼저 다가가 생각을 묻고 서로의 의견을 편하게 나눌 수 있는 관계를 만들어보려고 합니다.

지난 사건을 단순히 아쉬운 기억으로 남기지 않으려면, 그때 배운 것을 새로운 관계 속에서 직접 실천해야 한다고 생각합니다.

그래서 앞으로는 공감을 바탕으로 상대의 생각을 이해하고, 필요한 순간에는 직군에 갇히지 않고 적극적으로 의견을 내보려고 합니다.

다시 한번 좋은 동료를 잃은 경험을 통해 목적 조직으로써 협업하는 방법을 배웠고, 이제는 새롭게 만난 좋은 동료와 그 배움을 실천해 보려고 합니다.

‘잘한다’의 기준이 명확해지는 중

개발 조무사, 혹은 개발 조무래기 시절에는 다른 사람에게 “잘한다”라는 말을 자주 했습니다.

그런데 곰곰이 생각해 보니, 저는 주로 그 사람의 액션과 그로 인해 나온 결과, 그리고 그 결과가 만든 영향까지 세 가지를 보고 잘한다고 판단했던 것 같습니다.

상황을 예로 들면 이렇습니다. 동료가 맡은 작업을 빠르게 끝냈고, 결과물이 프로덕트에서 문제없이 동작한다면 저는 그 동료에게 “잘한다”라고 말했습니다.

돌이켜보면 제가 했던 칭찬은 결과보다도 속도에 더 치중되어 있었습니다.

하지만 AI가 발전하면서 구현 자체가 더 이상 가장 큰 병목이 아니게 된 지금, 단순히 빠르게 결과를 냈다는 이유로 잘한다고 평가하는 것은 조금 주의해야 한다고 생각합니다. 결과와 그로 인한 영향이 긍정적이었다는 이유만으로 그 사람의 역량 전체를 판단하는 것 역시 마찬가지입니다.

그래서 요즘은 제가 생각하는 ‘잘한다’의 기준을 조금씩 명확하게 세워가고 있습니다. 어쩌면 이 기준은 다른 사람뿐 아니라 저 자신을 판단하는 지표가 될 수도 있을 것 같습니다.

속도가 아니라 판단과 선택, 결정에 집중하기

결국 중요한 것은 좋은 결과와 그로 인한 긍정적인 영향을 단발성으로 끝내지 않고, 지속 가능한 사건으로 만들 수 있느냐인 것 같습니다.

기획, 개발, 소통을 하다 보면 수많은 선택의 기로를 마주하게 됩니다. 그때 어떤 배경과 기준을 가지고 판단했는지, 무엇을 근거로 특정한 선택과 결정을 내렸는지를 들여다봐야 합니다.

그래야 그 사람이 결과를 만들기까지 들인 노력과 과정을 이해할 수 있고, 그제야 진정성 있게 “잘한다”라는 칭찬을 건넬 수 있다고 생각합니다.

고등학교 시절 한 선배에게 들었던 이야기가 있습니다.

칭찬을 함부로 하면 그 친구가 겉멋이 들 수도 있다.

당시에는 이 말을 깊이 이해하지 못했습니다. 하지만 지금 생각해 보면, 단순히 겉으로 드러난 모습만 보고 칭찬하지 말고 그 사람의 과정과 기준까지 살펴보라는 조언이 아니었을까 싶습니다.

어쩌면 제가 그동안 다른 사람에게 했던 “잘한다”라는 말 역시, 보이는 결과만을 가지고 너무 쉽게 건넨 칭찬이었을지도 모릅니다.

정리하자면

과거에는 한 선배에게 칭찬에도 기준이 필요하다는 말을 들었지만, 2년이 지난 지금에서야 그 기준을 세울 준비가 된 것 같아 기쁩니다.

다만 조금 늦게 깨달았다는 아쉬움도 남습니다. 그렇기 때문에 앞으로는 더 명확한 기준을 가지되, 그 기준에만 매몰되지 않도록 열린 사고를 유지하려고 합니다.

함께하는 동료에게 진심으로 “잘한다”라고 말하기 위해, 결과만 바라보지 않고 그 결과를 만들기까지 어떤 판단과 선택이 있었는지 먼저 물어보려고 합니다.

그 질문이 동료를 더 깊이 이해하는 시작이 되고, 서로에게 긍정적인 영향을 주는 대화로 이어질 수 있도록 행동해 보려고 합니다.

좋은 동료는 최고의 복지다

2024년 개발자를 직업으로 선택한 순간, 스스로에게 던진 첫 번째 질문은 좋은 동료란 무엇인가?였습니다.

그리고 그 답을 찾기 위해 지금까지 여러 동료와 함께 일하며 크고 작은 경험을 쌓아가고 있습니다.

지금까지 제가 찾은 좋은 동료의 조건은 신뢰와 충돌, 그리고 그 기반이 되는 타인에 대한 배려입니다.

신뢰하는 동료와의 충돌은 결국 팀에 긍정적인 영향을 준다.

협업을 하면서 크고 작은 충돌을 여러 번 경험했습니다. 당시에는 불편하고 어려운 순간도 있었지만, 그 충돌은 대부분 우리가 더 나은 방향으로 나아가는 계기가 되었습니다.

이러한 충돌이 긍정적인 결과로 이어질 수 있었던 이유는 서로에 대한 신뢰가 있었기 때문입니다. 상대가 나를 공격하기 위해 의견을 내는 것이 아니라, 함께 더 좋은 결과를 만들기 위해 이야기하고 있다는 믿음이 있었습니다.

어쩌면 서로를 신뢰하는 정도만큼 솔직하게 충돌할 수 있었던 것 같습니다.

파멸로 치닫는 재난적인 상황이 아니라면, 충돌 자체가 목적은 아니다

어떤 조직에서는 충돌을 ‘챌린지’라고 부른다고 합니다.

충돌이나 챌린지는 단순히 서로 다른 의견을 내세우고 누가 옳은지를 가리는 과정이 아닙니다. 의견이 다를 때 디베이트를 통해 서로의 생각을 맞추고, 우리가 가고자 하는 목적과 방향을 다시 한번 점검하기 위한 과정에 가깝습니다.

결국 충돌의 목적은 상대를 이기는 것이 아니라, 지금보다 더 좋은 방향으로 나아가는 데 있다고 생각합니다.

그렇기 때문에 충돌이 있었다는 사실 자체보다, 그 충돌을 통해 무엇이 달라졌는지가 더 중요합니다.

충돌하는 이유는 충돌하기 전보다 더 나은 상황을 만들기 위해서다

충돌은 그 행위 자체에 의미를 두기보다, 충돌 이후 어떤 액션으로 이어질지를 고민해야 한다고 생각합니다.

충돌하기 전과 후에 우리의 생각과 행동은 어떻게 달라질 것인지, 그 대화를 통해 팀은 어떤 방향으로 나아갈 것인지를 함께 고민해야 합니다.

그러기 위해서는 충돌하기 전부터 어떤 이야기를 나눌 것인지에 대한 아젠다가 필요합니다. 단순히 불만을 꺼내는 것이 아니라, 현재 어떤 문제가 있고 그 문제를 해결해 어떤 방향으로 나아가고 싶은지를 정리해야 합니다.

그리고 그 방향은 개인의 감정이나 목표가 아니라 팀 전체가 지향하는 목적과 연결되어야 합니다.

팀의 목표와 부합하지 않는 충돌은 서로를 지치게 만들 수 있지만, 공동의 목적을 향한 충돌은 팀을 앞으로 나아가게 만듭니다.

빵도감의 결과를 두고 충돌하다

최근 빵도감의 마케팅과 지표 확인이 늦어지면서 스스로 위기감을 느꼈습니다.

이전 포스팅에도 기록했듯이, 시간이 지났음에도 우리가 만들어낸 결과가 기대만큼 크지 않다고 느꼈기 때문입니다.

그동안 많은 시간을 들여 프로덕트를 만들었지만, 실제 사용자에게 어떤 가치를 전달하고 있는지 확인하는 액션은 상대적으로 부족했습니다. 개발과 구현에는 계속해서 시간을 사용하면서도, 정작 우리가 올바른 방향으로 가고 있는지를 보여주는 지표는 충분히 들여다보지 못했습니다.

이러한 상황에서 저는 지금보다 더 적극적으로 마케팅을 진행하고, 사용자 반응과 지표를 빠르게 확인해야 한다고 생각했습니다.

하지만 단순히 “우리가 느리다”거나 “더 열심히 해야 한다”는 말만으로는 좋은 충돌이 될 수 없습니다. 왜 지금 이 이야기를 해야 하는지, 무엇을 바꾸고 싶은지, 그리고 그 변화가 빵도감의 목표와 어떻게 연결되는지를 먼저 정리해야 했습니다.

결국 이번 충돌의 방향성은 누군가의 속도를 지적하는 것이 아니라, 우리가 만든 프로덕트가 실제 사용자에게 닿고 있는지 더 빠르게 확인할 수 있는 구조를 만드는 데 있어야 한다고 생각합니다.

개발을 얼마나 빠르게 했는지가 아니라, 우리가 세운 가설을 얼마나 빠르게 검증하고 다음 액션으로 연결할 수 있는지를 이야기해야 합니다.

그리고 이러한 이야기를 솔직하게 꺼낼 수 있는 관계가 바로 제가 생각하는 좋은 동료의 모습 중 하나입니다.

서로를 신뢰하기 때문에 불편한 이야기를 피하지 않고, 팀의 더 나은 결과를 위해 충돌할 수 있는 동료. 그리고 충돌이 끝난 뒤에는 함께 다음 액션을 고민하고 실행할 수 있는 동료.

그런 동료와 함께할 수 있다는 것은 어떤 제도나 환경보다도 큰 복지라고 생각합니다.

나는 어떤 엔지니어가 될 것인가

최근 한 유니콘 스타트업으로부터 인터뷰 기회를 받아 참여했습니다.

인터뷰에서 제가 주로 이야기한 키워드는 ‘효용’과 ‘좋은 동료’였습니다. 순조롭게 대화가 이어지던 중, 평소보다 오래 생각하게 만든 질문이 하나 있었습니다.

5년 후, 어떤 모습의 개발자가 되어 있을 것인가?

그동안 여러 면접과 인터뷰에서 미래에 관한 질문을 받아왔고, 대부분은 어렵지 않게 답할 수 있었습니다. 하지만 이날만큼은 막연한 이상이 아니라 현실적으로 그려지는 모습을 이야기하고 싶었습니다.

오랜 고민 끝에 답변을 내놓았지만, 인터뷰가 끝난 뒤에도 충분한 답이 아니었다는 생각이 남았습니다. 그래서 이번 글을 통해 그때의 생각을 조금 더 이어가 보려고 합니다.

돌이켜보면 질문의 의도를 먼저 확인했어야 했다는 생각도 듭니다. 기술적으로 어떤 엔지니어가 되고 싶은지를 묻는 것인지, 아니면 태도와 가치관에 관한 모습을 묻는 것인지 다소 애매했는데 이 회고에선 질문의 범위를 정하지 않고, 제가 생각하는 5년 후의 모습을 직접 찾아가 보려고 합니다.

실력이 좋은 엔지니어?

처음 떠올린 모습은 실력이 좋은 엔지니어였습니다.

그치만 실력은 시간이 지나면 평준화 되는 부분이라고 생각합니다. 처음에는 사람마다 큰 차이가 나더라도, 같은 환경에서 계속 배우고 경험하다 보면 결국 비슷한 수준에 도달하는 모습을 SSAFY 생활을 통해 보았습니다.

물론 모든 사람이 완전히 같은 실력을 갖게 된다는 의미는 아닙니다. 다만 5년 동안 꾸준히 개발자로 일했다면 지금보다 실력이 좋아지는 것은 너무나 당연한 결과에 가깝다고 생각합니다.

그렇기 때문에 5년 후의 모습을 단순히 ‘실력이 좋은 개발자’라고 정의하기에는 조금 부족하게 느껴졌습니다. 오히려 개발자로서 시간을 보냈다면 마땅히 도달해야 하는 모습에 더 가까웠습니다.

효용을 생각하는 엔지니어?

다음으로 떠올린 모습은 효용을 생각하는 엔지니어였습니다.

제가 개발한 프로덕트나 직접 만든 기능을 사용자가 실제로 사용한다는 것은 지금 생각해도 항상 설레는 일입니다.

대화로 사용자를 설득하지 않아도, 사용자는 프로덕션을 직접 사용한 뒤 계속 사용할지 판단합니다. 사용자가 사용한다는 것은 그 프로덕션을이 사용자의 문제를 해결하거나, 적어도 사용하기 전보다 더 나은 가치를 제공하고 있다는 의미라고 생각합니다.

그렇기 때문에 개발 과정에서 구현 자체보다 사용자가 얻는 효용을 먼저 생각하려고 합니다. 어떤 기술을 사용했는지보다 이 기능이 실제로 필요한지, 사용자의 문제를 해결하고 있는지를 중요하게 바라봅니다.

하지만 이 모습 역시 지금의 저와 크게 다르지 않았습니다.

5년 뒤에도 효용을 우선으로 생각할 것이냐고 묻는다면 당연히 그렇다고 답할 것 같습니다. 다만 조금 더 성장한 모습을 그려본다면, 효용을 생각하는 태도 역시 실력이 좋은 엔지니어와 마찬가지로 당연히 갖추어야 할 모습에 가깝다고 느껴졌습니다.

효용을 생각하는 것은 분명 중요한 태도지만, 그것만으로 어떤 엔지니어가 되고 싶은지를 완전히 설명하기에는 부족했습니다.

좋은 동료를 고민하는 엔지니어

마지막으로 떠오른 모습은 ‘좋은 동료’ 였습니다.

좋은 동료란 무엇인가?

이 질문은 사피셜 기자단 활동을 하면서 모든 인터뷰이에게 마지막으로 던졌던 질문입니다.

당시 제가 SSAFY 생활을 통해 얻고 싶었던 것 중 하나도 바로 ‘좋은 동료란 무엇인가’에 대한 답이었습니다. 하지만 SSAFY가 끝날 때까지도 그 질문에 명확한 답을 내리지는 못했습니다.

대신 그곳에서 만난 좋은 동료와 함께하고, 때로는 부딪히고, 서로에게 영향을 주고받는 과정 속에서 조금씩 저만의 답을 만들어갈 수 있었습니다.

그렇게 제가 내린 좋은 동료에 대한 정의는 다음과 같습니다.

서로를 향한 배려 속에서 용기 있는 충돌을 통해 신뢰를 쌓고 서로에게 긍정적인 영향을 주는 동료

이 한 문장을 온전히 이해하고 제 것으로 받아들이기까지 꽤 오랜 시간이 걸렸습니다. 그만큼 값비싼 배움이기도 했습니다.

그래서 지금 ‘어떤 엔지니어가 되고 싶은가?’라는 질문을 받는다면, 기술적으로 뛰어난 엔지니어나 실력 있는 엔지니어보다 누군가에게 좋은 동료가 될 수 있는 엔지니어가 되고 싶습니다.