---

경력을 시작한 지 2년 쯤 지났을 때, 팀장님이 질문했습니다. “함께 일하고 싶은 사람은 어떤 사람일까요?”

괜찮은 대답을 하지 못 했습니다. 막연한 좋은 모습들 중 하나를 답했던 기억이 납니다. “똑똑하고 호기심 많은 사람이요.”

벌써 경력이 만 4년이나 차서, 절대 주니어라고 말할 수 없게 됐습니다. 코딩테스트 평가도 하고, 면접도 들어가기 시작했습니다. 누군가의 합격과 불합격에 관여하기 시작해 마음이 무거웠습니다.

기준이 필요했습니다. ‘좋은 개발자’를 논하는 것은 어렵다고 하던데, 꼭 그렇지는 않습니다. 조직마다 자신들의 가치관을 다루는 core value나 leadership principle을 정리하고 있습니다. Tesla의 The Anti-Handbook, Netflix의 Culture나 The Rare Responsible Person, Amazon의 Leadership Principles 같은 것처럼 말입니다.

저희 조직에는 아직 완전한 core value나 leadership principle이 없습니다. 문화와 복지, 인재상을 정리해둔 것이 있지만 조금 추상적입니다. 각 항목들이 실제로 동작했던 사례가 소개되지 않으니 덜 와닿았습니다.

불평처럼 보이지만 그런 의도는 아닙니다. 지저분해야 정리를 하는 것일텐데, 아직 그 정도 규모는 아니기 때문입니다. 단지, 평가를 하며 혼란스러울 때가 있었을 뿐입니다. 리드급과 저의 평가가 갈릴 때가 많았고, 그 때마다 구두로 align을 맞추곤 했습니다.

‘좋은 동료가 최고의 복지’라고 많이들 이야기합니다. 제가 무언가 잘못 평가해서, 우리 팀이 좋지 않은 동료와 함께 일하게 만들면 제 자신이 너무 실망스럽고 팀에게 미안할 것 같았습니다. 조직 수준에 core value를 제시하기엔 아직 저의 솜씨가 부족한 것 같아, 저에게 ‘함께 일하고 싶은 사람’은 누구인지를 먼저 정리해보기로 했습니다.

-

무려 5부작이나 될 정도로 항목이 많습니다. 떠오르는 것들을 다 적다 보니 이렇게 되었네요. 죄다 나열해놓은 것 같지만 그렇지만도 않습니다. 어떻게 생각하실지 모르겠지만, 성실함, 열정, 오랜 시간 일하는 것처럼 ‘열심히’의 영역은 개인적으로 그렇게 중요히 생각하는 가치가 아니어서 제외했습니다.

읽다 보면 공감이 되다가도, 당장 제 모습을 되돌아보면 해당되는 항목이 많지 않은 것 같습니다. 글을 제 손으로 쓰면서도 동기부여가 많이 됐습니다. 앞으로도 열심히 나아가야 할 것 같습니다.

당연한 말만 하는 글이 될까 싶어, 제가 직접 경험한 사례를 최대한 담았습니다. 공감과 도움이 되는 글이 되면 좋겠습니다. 여러분들에게 ‘함께 일하고 싶은 사람’은 어떤 사람인가요? 댓글로 얘기해보면 좋겠네요.

여기 있는 내용의 대부분은 제 주변 동료들의 모습을 가지고 왔습니다. 함께 일하고 싶은 사람들이 가득한 AB180의 팀원이 되시길 추천드립니다. 👀

---

업무 습관

좋은 업무 습관은 일머리에서 비롯됩니다. 최소한의 실무 능력만 있으면, 일머리로 작업을 이끌어나가는 부분이 많습니다. 경력과 업무 수행 능력에는 상관성이 거의 없다는 연구가 꽤 있습니다. 경험에 빗대어 봐도 신입과 10년차의 차이는 극명했지만, 3년차와 10년차의 차이는 크지 않았습니다. 기술적인 역량과 인사이트가 부족하더라도, 조금 더 세심하고, 조금 더 적절한 도움을 요청하는 것으로 보완이 되는 것 같습니다.

전반적으로 능동적인 모습이 좋게 작용하는 듯 합니다. 면접을 보면서도 ‘이 프로젝트를 통해서 뭘 배웠나요? 어떤 어려움이 있었고 어떻게 해결했나요?’ 같은 질문을 했던 기억이 납니다.

혼자서 탐구한 흔적이 있는 질문

누구나 도움이 필요할 때가 있지만, 모두의 시간은 소중합니다. 현실적으로 얘기하면, 내게 도움을 줄 수 있는 사람은 나와 연봉이 비슷하거나 높습니다. 동료들이 본인의 업무에 집중해서 가치를 창출할 수 있게 만들어 주어야 합니다.

질문을 하지 말라는 것은 아닙니다. 혼자서 앓다가 일정 다 돼서 터뜨리는 건 더 안 좋습니다. 일을 혼자서 완벽하게 진행하기 어렵다는 것은 모두 이해하고 있습니다. 어차피 도움을 요청해야 한다면, 자기 시간을 조금 더 들여 필요한 도움만을 요청하는 사람이 좋습니다.

Finger princess라는 말이 있습니다. 검색만 해도 쉽게 찾을 수 있는 정보를, 아무런 노력 없이 답을 얻으려는 사람을 뜻합니다. 앞뒤 없이 ‘이거 안돼요’나 ‘~가 뭐에요?’같은 질문을 마주치면 당황스럽습니다. 도움을 많이 받으려 하다 보면 성장 곡선에서 고점이 명확해집니다. 가장 높게 올라가도 2등입니다. 1등에게 도움을 받아야 하기 때문입니다.

잘 정리된 질문은 서로의 시간 소비를 줄이고, 나서서 답해주고 싶게 만듭니다. 물어보기 전에 충분히 탐구하고, 상대방이 무엇을 되물어볼 지 생각하는 사람은 협업하기 정말 좋습니다.

저는 질문할 때가 되면 항상 다음처럼 내용을 정리하고, 두괄식으로(핵심 먼저) 전달하고자 합니다.

• 답변자에게 바라는 action

  → 무언가를 알려주길 바라는지, 의견이 필요한 것인지, 결정이 필요한 것인지, 문제 해결을 바라는지 등
  

• 질문 발생의 배경

  → 질문이 왜 발생했는지 (어쩌다 질문까지 하게 됐는지)
  → 자체적으로 도달한 결론과 생각의 흐름
  

• 답변자를 위한 부가 정보

  → 무엇을 하다 발생한 질문인지에 대한 context
  → 문제 제기라면 재현 방법, 캡쳐, 화면 녹화 등
  → 변화가 생기는 것이라면 as-is/to-be를 명시
  → 참고를 위한 message나 티켓 등의 링크를 제공
  

예를 들면,

[답변자에게 바라는 action]
친구 목록 API의 response에 있는 order key가 삭제되었을 때 문제가 없을지 프론트엔드의 크로스체크를 요청드립니다.

[질문 발생의 배경]
order 를 삭제한 API를 개발 서버에 배포했을 때 문제가 없음을 확인했고,
프론트엔드 repository를 clone받아 확인했을 때 usage가 특별히 보이지는 않았습니다.
그러나 order 라는 키워드가 변수명에도 쓰이는 등 general한 것이다 보니, 도구의 도움을 받기가 어려워 요청하게 됐습니다.

[답변자를 위한 부가 정보]
order 라는 key는 각 친구가 목록에서 몇 번째 순서에 표시되어야 하는지를 뜻하는 key인데요,
이 값을 쿼리하는 것이 API의 실행 시간에서 높은 비중을 차지하고 있습니다.
원래는 최적화를 하려고 했는데, usage가 없는 것으로 보여 삭제하고자 합니다.

사용자 정의 순서로 친구 목록을 정렬하게 위해 order 라는 것을 사용했던 걸로 기억하는데, 이 기능은 2022-04-07자로 삭제(티켓이나 PR 등의 링크)된 기록이 있습니다.

이렇게까지 정리한다는 것이 과하다고 생각할 수 있습니다. 하지만 상대방이 되물어보기 시작하면 커뮤니케이션 비용이 훨씬 높아집니다. 툭 던진 질문에 다음과 같은 답변이 달린다고 생각해 봅시다. 핑퐁이 답답해질 모습이 눈에 선합니다.

• 문맥을 고려했을 때 질문하신 내용은 ~같은데, 제가 이해한 게 맞을까요?
• 문제 재현은 어떤 방식으로 해야 될까요?
• 질문의 취지가 무엇인가요? 의견을 구하는 것인지, 의사결정이 필요한 것인지 알려주세요.

잘 정리된 질문은 신뢰를 쌓아 줍니다. ‘하다하다 안 돼서 질문했겠거니’ 하며 더 적극적으로, 유의미한 답변을 주려고 노력하게 됩니다. 신뢰 쌓기(earn trust)는 어려운 과제지만, 질문을 잘 하는 것으로 꽤 확보할 수 있는 것 같습니다.

가끔 PM분들이 개발자 도구를 켜서 DOM을 보거나, API 호출 기록을 해석하려는 모습을 볼 때가 있습니다.

이제는 질문이 기다려지기까지 합니다. ‘이 사람이 다음에는 또 얼마나 어려운 걸 물어보려나’

빈말이 아니라, 뻔하지 않은 질문은 항상 즐거운 것 같습니다.

이거 궁금하셨죠?

커뮤니케이션을 잘 해야 한다는 이야기가 많지만, 조금 답답한 주제입니다. 도대체 무엇이 ‘좋은 커뮤니케이션’을 결정하는 것일까요?

기본적으로 회사 동료는 서로 남이라는 것을 인지해야 합니다. 자신의 상태를 공유하는 것은 협업의 기본입니다. 일이 잘 진행되고 있는지, 장애물이나 위험 신호는 없는지와 같은 것 말입니다.

여기에 더해, 누군가 물어보기 전에 먼저 답을 제출하는 사람이 있습니다. ‘이거 궁금하셨죠?’ 라고 하는 듯이요. 이러한 선제적 대응은 커뮤니케이션을 비롯한 대부분의 협업 과정에서 긍정적인 효과를 줍니다.

• ‘작업 어떻게 돼가요?’, ‘앞으로의 계획이 무엇인가요?’ 같은 질문을 받기 전에, 먼저 상황을 공유하는 것

• 피드백이 있을 법한 부분에 본인의 의사결정 흐름을 미리 첨언하는 것

• 확인 여부를 최소한 ✅ 와 같은 이모지로 응답하는 것

• 요청을 언제까지 처리할지, 또는 언제까지 상황을 공유해줄지 ETA를 알려주는 것

• 질문에 대한 시급도를 명시하는 것

옳은 일을 위해 누구와도 대화할 수 있는 사람

신입 때에는 ‘높은 사람’들을 참 무서워했습니다. 회사에 대한 나쁜 환상이 있었던 건지, 문제를 제기하면 혼날 것 같아 자신있게 말하지 못했던 기억이 납니다.

회사에 있는 사람들은 모두 mission을 달성하기 위해 모인 사람들입니다. 눈치보지 않는 것을 넘어서, 회사 전체의 이익을 위해 누구와도 대화할 수 있는 사람이 좋습니다. 옳은 일이 일어나도록 하기 위해 CEO와도 대화할 준비가 되어있는 사람과 함께 일하고 싶습니다.

이 부분은 Tesla의 The Anti-Handbook에 포함된 Communication 항목과도 닿아 있는 것 같습니다.

Anyone at Tesla can and should email or talk to anyone else according to what they think is the fastest way to solve a problem for the benefit of the whole company.
테슬라의 모든 사람은 회사 전체의 이익을 위해 문제를 해결하는 가장 빠른 방법에 따라 이메일을 보내거나 다른 사람과 대화할 수 있습니다.

You can talk with your manager, you can talk to your manager’s manager, you can talk directly to a VP in another department, you can talk to Elon - you can talk to anyone without anyone else’s permission.
매니저와 대화할 수도 있고, 매니저의 매니저와 대화할 수도 있고, 다른 부서의 VP와 직접 대화할 수도 있고, Elon과 대화할 수도 있습니다. 다른 사람의 허락 없이 누구와도 대화할 수 있습니다.

Moreover, you should consider yourself obligate to do until the right thing happens.
게다가, 여러분은 옳은 일이 일어날 때까지 행동해야 할 의무가 있다고 생각해야 합니다.

-

똑같은 의견이라도, 옆자리에 앉아 있는 동료에게 전달할 때와 대표에게 전달할 때의 압박감은 다릅니다. ‘아마 그럴 것 같아요’같은 추정은 근거가 될 수 없습니다. 데이터를 가져와 근거를 보충하고, 우리의 상황에 맞는 실험 결과를 덧붙이는 식으로 의견을 견고하게 만들어야 합니다. 이야기보다 사실을 전달해야 합니다.

그렇게 습관이 만들어지고 나면 옆자리 동료와 대화할 때도 충분한 검증을 거친 주장을 할 수 있게 됩니다. 대화가 붕 떠버려 아무 결론도 안 나는 것보다, 건설적인 토론이 항상 좋습니다.

이런 사람들은 참 소중합니다. 잠깐만 대화를 나눴는데도 혼자 삽질하던 문제가 해결되고, 우리 시스템을 개선할 수 있는 아이디어가 나오곤 합니다.

독성 말투가 없는

비난하지 말라는 이야기가 아닙니다. 비난하지 않는 건 너무나도 당연한 것입니다. 개선하려는 시도조차 없이 뒷담을 하거나, 나이를 듣고 반말하는 사람들, 말 끊는 사람들, 감정을 드러내는 사람들, … 하여튼 이렇게 어른스럽지 못한 사람들과는 절대 함께하고 싶지 않습니다.

커뮤니케이션에 배려를 담자는 이야기입니다. 배려 없는 대화의 핑계로 ‘효율적인 커뮤니케이션을 한다’, ‘나는 컴퓨터랑 대화하는 사람이다’ 같은 말을 들을 때가 있습니다. 솔직히 그냥 무책임한 사람처럼 보입니다. 사회성 문제로 병원을 다닐 정도가 아니라면, 동료와 팀에게 말로 피해를 끼치는 것은 금기시되어야 합니다.

독성 말투는 은연중에 조직에 해를 주게 됩니다. 말 하나에 팀워크가 깨지고, 팀 전체의 사기를 저하시키기도 합니다. ‘말’에 대한 속담이 많은 이유가 있는 것 같습니다.

사실 이것은 독성 말투가 무엇인지를 인지하는 것에서 반은 먹고 들어가는 것 같습니다. 독성 말투라는 게 생각보다 허들이 높기 때문입니다. 다음은 독성 말투의 목록을 정리한 것입니다. 듣는 입장에서 어떻게 들리는지, 그리고 개선된 말투는 무엇인지 이어붙였습니다.

• “왜 이렇게 하셨나요?”

  • 듣는 입장 : “도대체 왜 이렇게까지밖에 못 했나요? 이것보다 나은 옵션이 얼마나 많은데?”
  • 개선된 말투 : “이렇게 판단한 이유가 있을까요? 의사결정 과정이 궁금합니다.”

• “이해가 안 되시나요?”

  • 듣는 입장 : “제가 이렇게까지 설명했는데도 이해가 안 되는 게 저도 이해가 안 되네요. 얼마나 더 쉽게 설명해드려야 하나요?”
  • 개선된 말투 : “어떤 부분이 어려워서 갸우뚱하고 계신가요?”

• “이거 아직도 안 되고 있나요?”

  • 듣는 입장 : “일을 하고는 있는건가요? 혹시 놀고 있는 건 아니죠?”
  • 개선된 말투 : “이 작업이 진행되지 못하고 있는 원인이 있을까요? 어떤 지원이 필요한가요?”

너무나도 직선적인 성격이라 어렵다면, 그냥 말 앞에 ‘혹시’만 붙여줘도 문장이 훨씬 부드러워집니다. “혹시 왜 이렇게 하셨나요?”, “혹시 이해가 안 되시나요?” 처럼 말입니다.

기본적으로 내가 잘못했을 가능성을 기저에 깔아놓고 대화해야 한다고 생각합니다. 과거에 사이드 프로젝트를 하던 중, 디자이너에게 “와이어프레임 왜 아직도 확인 안 하셨나요?” 라는 말을 들었던 적이 있습니다. 그러나 저는 어떠한 문서도 받은 적이 없었고, 알고 보니 그 디자이너분의 인터넷 문제로 링크가 전송되지 않았던 것이었습니다.

신경질은 낼 수 있다고 봅니다. 오늘따라 일이 참 안 풀리는데, 오늘따라 다들 나를 찾으면 힘들긴 합니다. 그런데 그게 기본값인 사람들은 당연히 좋지 않습니다. 감정을 숨기고 이성으로 배려를 담아 대화하는 것, 적어도 그러려고 노력하는 사람이 좋습니다.

이 주제에 대해 정말 잘 정리된 글이 있습니다 : 기술 업계의 독성 말투 문제, 고칩시다!

안 되는 이유보다, 되게 하려면 필요한 리소스를 제시

안 된다는 말은 가장 마지막에 나와야 합니다. 새로운 아이디어를 어떻게 만들어낼 수 있을 지 고민하는 것이 당연히 먼저입니다. 본능적으로 안 되는 이유부터 생각하는 사람들은, 일 하기 싫어 핑계대는 사람으로 보입니다. ‘일 하기 싫은 건 당연한 것 아닌가’라고 물어본다면, ‘그 정도의 missionary도 없이 왜 같이 일하고 있는지’를 되물어볼 것 같습니다.

‘안 되면 되게 하라’는 말이 있습니다. 가혹하게 들릴 지 모르겠지만, 안 되는 걸 열심히 비틀어서 어떻게든 되게 만드는 사람은 영웅과도 같습니다. 또한, 일을 되게 만들기 위해 모두 도와줄 준비가 되어 있다는 것을 알아야 합니다.

기획자가 원하는 아이디어를 그대로 만들어내는 것은 당연히 어렵습니다. 구현 난이도가 높거나 우선순위 문제로 일정을 못 맞출수도 있고, 기술적인 문제로 기획자가 원하는 퀄리티가 나오지 못 할수도 있습니다.

이런 문제는 대화를 통해 원만하게 해결되곤 합니다. 기획자는 기술적인 세부 사항에 대해 완벽히 알지 못하므로, 구현 난이도를 측정하기 어렵기 때문입니다. “이래저래 해서 어려워요” 하면, “아 정말요?! 그렇게 구현이 어려운 기능인지 몰랐어요. 이건 그냥 spec-out 해도 돼요” 같은 답변을 받았던 기억이 많습니다.

일이 되게 만들기 위해 어떤 리소스나 변화가 필요한지를 제시하고 얻어내는 사람이 좋습니다. 때로는 설득도 필요하고, 토론도 필요합니다. 그런 과정을 거쳐 어떻게든 결과물을 만들어낼 수 있게 준비하는 모습은 정말 프로정신이 강한 사람으로 느껴집니다.

• “이 기능은 구현에 워킹타임이 3일 정도 필요합니다. 리소스를 많이 잡아먹는 부분이 어떤 스펙 때문인데, 이것을 이렇게이렇게 바꾸면 워킹타임을 1일로 축소할 수 있으니 검토 부탁드립니다.”

• “현재 설정된 due를 맞추기가 어렵습니다. 지금 이런이런 작업을 진행하고 있는데, 직후에 바로 착수해도 due를 5일정도 넘길 듯 합니다. 일정 변경이 가능하면 부탁드리고, 불가능하다면 우선순위 조절이나 담당자 변경을 제안해보도록 하겠습니다.”

꽤나 강조하고 싶은 역량입니다. 작업이 시작되기 전부터 머리를 핑핑 돌리며 견적을 내서 대략적인 일정을 내놓고, 설득을 위한 커뮤니케이션이 되는 사람이면, 세세한 코칭 없이 일하게 해도 되겠다는 생각이 들기 때문입니다. 신뢰하는 만큼 자유를 부여하게 되는데, 이런 사람들은 자유를 얻기도 쉽습니다.

문제를 해결하고 나면, 원인을 파악하고 재발방지

“이 코드 누가 짰어!”

무서운 말입니다. 범인을 찾으려는 행동입니다. git에는 blame 이라는 명령어가 있습니다. 이것을 이용하면 특정 line을 가장 마지막에 건드린 사람이 누구인지를 알 수 있습니다.

blame은 비난이라는 뜻입니다. (사실 책임이라는 뜻도 있지만, 조금 의미를 부여하고 싶었습니다.)

문제의 범인이 나라서 고개를 숙여야 하거나, 내가 아니어서 ‘다행이다’라고 생각해야 하는 상황이 온다면 참 아쉬울 것 같습니다.

저는 시말서를 써본 적이 없습니다. 그리고 회사 내에서 시말서가 오가는 것도 본 적이 없습니다. 실수를 안 해서가 아니라, 조직의 문화가 그렇습니다. 문제가 발생했을 때 개인의 실수를 비난하지 않고, 실수가 발생하지 않는 시스템을 만드는 데에 집중하는 포스트모텀(postmortem) 문화를 가지고 있기 때문입니다. 포스트모텀에 대해서는 사고를 쳐도 혼나지 않는 회사라는 글을 읽어보면 좋을 것 같습니다.

저는 과거에 100GB가 넘는 테이블에 alter table을 날려, 테이블 전체에 lock을 걸었던 적이 있습니다. 때문에 매우 중요한 컴포넌트가 몇 분간 다운됐고, 문제의 원인이 저라는 것을 인지하고 나서부터 정신이 아득해졌습니다. 가장 먼저 생각했던 건 당연히 ‘혼나겠다’ 였습니다.

팀장님은 저를 회의실로 데리고 갔지만, 혼내지 않았습니다. 본인이 커리어 초반에 실수를 해서, 서비스에 큰 문제를 발생시켰던 경험을 이야기해줬습니다. 본인이 아직까지 개발자로 일하고 있는 것은 당시에 혼나지 않아서였고, 실수가 다시 발생하지 않도록 시스템을 개선하면 될 일이니 주눅들지 말라고 다독여줬습니다.

이후에 개발자에게 부여되는 DB 유저에서 DDL 권한이 제거되었고, 이러한 실수는 몇 년이 지난 지금까지도 일어나지 않았습니다.

-

소프트웨어 개발은 모든 행동에 리스크가 있는, 위험이 도사리는 분야입니다. 마음가짐이나 규칙같은 것으로 문제를 방어하려는 것은 정말 위험한 행동입니다. 문제가 발생하는 것은 사람의 역량 문제라기보단 시스템의 문제라고 봐야 합니다. ‘실수한 게 당당하고 자랑이냐’고 하면 물론 아닙니다. 조심해야 하는 건 맞지만, 소프트웨어 시스템은 겨우 조심하는 정도로 방지가 되는 복잡성이 아니라서 그렇습니다. 범인을 찾고 사람을 타박하는 분위기에서는 팀이 100%의 역량을 발휘하기 어렵습니다.

“죄송합니다”는 사람의 기분을 풀어주기 위한 말입니다. 아무리 사과해도 소프트웨어는 바뀌지 않습니다. 중요한 건 재발 방지입니다. 실수를 했다는 것은 개인적으로 아쉽고 분한 일입니다. 하지만, 나중에 동료가 똑같은 실수를 하지 않게 만드는 것이 이상적인 모습입니다.

조직 문화로서의 이야기만 했지만, 개인 수준에서도 충분히 적용할 수 있습니다. 개인 프로젝트에 적용해볼 수도 있고, 단순히 에러의 사후 처리만으로 사용할 것도 아닙니다. 시행착오를 많이 겪은 프로젝트가 있다면, 다음에는 시행착오를 겪지 않기 위해 어떻게 개선할 수 있을지 고민하는 것도 포스트모텀입니다. 아예 생활에 연결지을 수도 있습니다. 알람시계가 고장나 잠에서 깨지 못 했다면, 알람시계를 더 두는 것으로 문제를 해결할 수 있는 것입니다(놀랍게도 저는 알람시계가 3개 있습니다 ㅋㅋ).

‘앞으로 안 그래야지’하고 마음먹기만 하는 사람보다, 재발 방지를 위해 노력해본 사람과 함께 일하고 싶습니다.

근거, 사례, 대안을 제시하는 사람

피드백을 주고받을 때가 있습니다. “이거 별로에요”라고만 하면, “그래서 어떻게 하라는 건데?”라고 반문하게 됩니다. 단순한 찬성과 반대보다, 제안을 담아 피드백해주는 사람이 좋습니다. 근거가 충분하지 않으면 주장이 강하지 않다고 느낍니다. ‘제대로 찾아보고 말하긴 하는거야?’ 같은 생각을 하게 됩니다.

가능하면 실제 사례를 통해 근거를 제시하고, 내가 한다면 어떻게 했을지 대안을 제시하는 것이 좋습니다. 코드를 대신 짜달라는 것도 아니고, 자신이 생각하는 올바른 방향이 무엇인지 설명해주는 것이 건설적인 토론을 할 수 있게 만들어 주기 때문입니다.

실험할 줄 알고, 숫자를 통해 납득하는 사람

‘빠르다’, ‘용량이 크다’처럼 형용사로 이루어진 의견은 받아들이기 애매합니다. 얼마나 빠르길래 빠르다고 말하는 건지, 얼마나 용량이 크길래 크다고 말하는 건지 알 수 없기 때문입니다.

숫자를 좋아하는 사람들이 있습니다. ‘15ms 나와요’, ‘1MB 정도 돼요’처럼 명시적인 단어를 의견에 담곤 합니다. 이렇게 숫자가 담긴 의견을 받게 되면 참 좋습니다. 빠른지, 느린지, 큰지, 작은지에 대해 직접 평가할 수 있기 때문입니다.

이런 사람들의 특징은 실험을 좋아하고, 숫자를 통해 납득한다는 것입니다. 이야기가 아니라 사실을 중요하게 생각합니다.

일반적으로 Java는 빠르고, Python은 느립니다. 그렇다면 구체적으로 어떤 부분이 얼마나 차이나는지에 대해 알 필요가 있습니다. Java vs Python performance benchmark 같은 키워드로 구글링할 수도 있겠지만, 우리 서비스의 워크로드를 기준으로 설명하는 것이 더 설득력이 있습니다. ‘벤치마크 자료를 보니 Java가 10배 빠르다’ 보다는, ‘어떤어떤 API를 Java와 Python 각각으로 만들어 실험해 봤더니 throughput이 얼마, latency가 얼마 차이나더라’ 같은 이야기가 더 좋습니다.

실험에는 시간이 들어갑니다. ‘뭐 굳이 실험까지 해야 하나’라는 생각이 들 때도 있습니다…만, 저는 대부분의 실험이 시간 낭비라고 생각하지 않습니다. 통계만 보고 적용했다가, 예상한 만큼 이득을 보지 못 했던 경험이 많아 그렇습니다.

간단한 실험을 통해 쌓은 경험을 바탕으로, 나중에는 어려운 문제를 잘 실험할 수 있게 됩니다. 변인 통제, 반복 측정같은 실험 이론이나 percentile같은 개념은 책으로 학습하지 않았더라도 경험을 통해 체득되곤 하는 것 같습니다.

동료의 피드백으로 자신을 평가하는 사람

Co-worker로서의 잘잘못은 ‘남이 보는 나’를 통해 평가하는 것이 좋습니다. 속히 말해 눈 가리고 귀 막는 사람들은 받아들이기 어려운 것 같습니다.

주변에서 ‘잘 했다’고 해도, 그렇게 생각하지 않고 자기 자신을 채찍질하는 사람이 있습니다. 최고 점수를 받아도 그동안의 성과 때문이라고 생각하질 않습니다. 자신이 기대를 받고 있는 것으로 받아들이고, 앞으로 더 잘하라는 격려로 받아들이곤 합니다. 이건 그래도 괜찮습니다. 제 주변에도 이런 동료들이 있는데, 달려나가는 걸 가로막을 수는 없으니 지치지 말라고만 응원해주고 싶습니다.

반대로, 주변에서 ‘못 했다’고 해도 그것을 자신에 대한 공격으로 받아들이고 꽁꽁 숨어버리는 사람이 있습니다. 당연히 부정적인 피드백은 아픕니다. 앞으로의 업무에 있어서 멘탈 관리를 위해 잠깐 방어적으로 생각하는 것은 괜찮지만, 결국은 발전을 위해 납득해야 하는 소중한 의견들입니다. 아무리 남이라고 해도, 동료에게 부정적인 피드백을 전달하는 것은 쉽지 않은 일이기 때문입니다. 피드백은 누군가의 의욕을 저하시키기 위함이 아니라, 다 같이 잘 하기 위함이라는 것을 인지해야 합니다.

이건 저에게 있어서도 하나의 과제인 것 같습니다. 어떤 피드백은 금방 고치기 어렵기 때문입니다. 곧 동료평가가 시작되는데, 저번에 받았던 피드백을 이번에 또 받으면 어쩌나 무섭기도 합니다. 하지만 좋은 동료가 되기 위해, 받아들이고, 나아지는 모습을 보여줘야 할 것 같습니다.

기술 적용에 이유가 있는 사람

학교 후배의 코드를 리뷰할 때였습니다. 최대 1년의 날짜 범위를 선택해 통계를 조회할 수 있는 기능이었습니다. 코드 중에, 시작일과 종료일 차이의 최대값을 366일로 설정해 둔 부분이 있었습니다. 이유를 물어보니, 윤년을 고려했다고 답했습니다. 윤년이 아닌 해도 있으니 100점짜리 답은 아니었지만, 근거를 담은 값 하나가 그 후배를 바라보는 시선을 완전히 바꿨던 기억이 납니다.

얼마 안 지나 또 다른 코드를 리뷰했습니다. 게시판 서비스였는데, API에서 게시글의 작성 시각을 UTC로 변환해 내려주도록 한 있었습니다. 후배는 “다른 나라는 시차가 있어서 알아보니 timezone이라는 개념이 있었고, UTC가 기준점이더라. 그래서 UTC로 내려주고 프론트엔드가 상황에 따라 변환하도록 만들었다”고 설명했습니다. 이것도 물론 100점짜리 답은 아니었습니다. 국제화하거나 외국에서 사용할 여지가 없는 서비스였고, ISO 8601같은 옵션도 있었기 때문입니다.

그러나 고민해본 흔적이 있고, 확장성을 고려했다는 것이 보기 좋았습니다. ‘당연히’라고 생각하기보다 이유를 고민하고, 대안을 검토하고, 현재 시점에 가장 좋은 옵션이 무엇인지 고려하는 것은 언제나 소중한 일입니다.

정답이 아니어도 괜찮고, 고민해본 흔적이 있으면 되는 것 같습니다. 고민하는 방법만 가르치면 알아서 하겠다는 생각을 갖게 됩니다.

Strong View, Weakly Held, Followership

We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress!
우리는 가능한 한 빨리 틀렸음을 증명하려고 노력합니다. 그래야만 발전을 찾을 수 있기 때문입니다.

노벨 물리학상을 수상한 리처드 파인만의 명언입니다. 대부분의 조직은 가장 나은 방법을 찾고자 토론을 합니다. 여기서 토론이 올바른 방향을 찾아가기보다, 자신의 의견이 채택되는 것을 더 중요하게 여기는 사람이 있습니다.

자신이 낸 의견이 채택되지 못하면 아쉽습니다. 덜 기여한 것 같고, 도움되지 않는다는 생각이 들기도 합니다. 자신의 의견이 완벽하다고 굳게 믿고 있었다면 조직에 대한 신뢰를 의심하게 되기도 합니다. ‘이렇게 좋은 의견을 받아들이지 못 하다니’ 하며 조직의 수준에 의문을 갖습니다. 합당한 이유가 있어서 반려된 것인데도 말입니다.

하지만 협업에 있어서는, 이렇게 방어기제가 발동하는 것은 좋지 않습니다. 내 의견이 좋아보이는 것은 확증편향과 관련되어 있습니다. 자기 생각과 일치하는 정보만 받아들이고, 다른 생각은 배척하는 심리입니다. 의견이 신념이 되어버리기 전에, Weakly Held할 수 있도록 태도를 바꿔야 합니다.

-

제 동료들은 의견을 최초로 제시하기까지 오랜 시간을 갖습니다. 그리고 의견을 제시한 뒤에는 근거를 더 뒷받침하려고 하지 않습니다. 대신 다른 의견, 되도록이면 자신의 것과 상반되는 의견의 근거를 찾아보는 과정을 거칩니다. 그렇게 학습하고 나면 생각을 고수할지, 생각을 바꿀지 결정합니다.

무조건 양보하라는 것은 아닙니다. 자신의 의견에 자신감을 갖고 주장하는 것은 당연히 좋고, 자신감이 생길 만큼 충분한 논거를 쌓는 것은 의무라고 생각합니다(Strong View). 그러나 토론에서는 내 의견과 남의 의견을 나누어 생각하는 것보다, 주어를 빼고 모든 의견이 단순한 선택지라고 생각하는 모습이 필요합니다. 자기 의견의 근거를 찾아보는 만큼, 다른 의견의 근거를 찾아봐야 더 객관적일 수 있습니다(Weakly Held).

근거가 바뀌면 의견도 바꾸는 유연한 모습이 있어야 합니다. 생각이 자주 바뀌는 것을 나쁘게 생각할 필요는 없다고 봅니다. 가설로 채워야 하는 부분이 있기에, 의견이 갈리는 것은 당연합니다. 때문에 처음부터 100점짜리 정답을 찾아낼 수는 없습니다. ‘이런이런 근거 때문에 내가 생각을 바꿨다’로 마무리되는 토론이 바람직하다고 생각합니다.

토론이 끝나면 그 결과에 관계 없이, followership을 가지고 일이 잘 될 수 있도록 지원하는 사람이 좋습니다. 팀 플레이어로서 꼭 필요한 역량입니다. 선심쓰듯 양보하고, 자기 의견대로 안 됐다고 토라져 아무 도움도 안 주다가, 그 방법이 틀렸다는 것이 드러나면 ‘거 봐라’ 하는 모습은 정말 보기 안 좋습니다.

‘내가 틀리진 않았을까’ 생각하며, 자기 자신과의 토론을 해왔던 사람이 이런 부분에서 좋은 모습을 보여주는 것 같습니다. 애초에 양질의, 정답에 가까운 의견을 내기도 하고 말입니다.

요약

1. 질문 막 하지 말고, 최대한 탐구하고 정리해서 가져가자.

2. 물어볼 때까지 기다리지 말고, 웬만한 건 먼저 얘기하자.

3. 옳은 일이 일어날 때까지 계속해서 대화할 의무가 있다고 생각하자.

4. 말에 배려를 담자.

5. 안 되는 이유를 찾을 시간에, 되게 만들기 위한 리소스를 요청하자.

6. 문제 해결만큼 재발 방지도 중요하다.

7. 딴지 걸거나 훈수 두는 식으로 피드백하지 말고, 근거, 사례, 대안을 구체적으로 제시하자.

8. 실험해서 숫자를 뽑아낸 뒤, 이야기가 아니라 사실을 기반으로 의견을 내자.

9. 동료의 평가가 가장 정확하다.

10. 기술에 당연한 것은 없으니 항상 이유를 고민하자.

11. 내 의견에 고집을 부리지 말고, 토론이 올바른 결론을 낼 수 있도록 돕자.