23 min read

퇴사의 기쁨과 슬픔

며칠 전에 퇴사했다. 7월을 끝으로 2년이 조금 넘는 시간이 지나갔다. 첫 창업이었고, 명시적으로 어떤 직책을 맡아본 것도 처음이었다. 나름의 방식으로 진심을 다했고, 나름의 방식으로 문제를 해결하려고 했고, 나름의 방식으로 사람들을 대했던 것 같다. 하지만 결국은 내가 없는게 회사가 잘 되는데 도움이 될 것이라고 판단해서 퇴사를 결정했다.

많은 일들을 경험하고 고민하는 과정에서, 배운 것을 기록하고 새로 알게 된 나를 살펴보겠다는 마음에 글을 쓴다. 나에 대해서 알게된 만큼 다음에는 더 잘 할 수 있기를 기대하면서 말이다.

배운 것

프로그래머로서 적정 설계하기

나에게 '적정 설계'는 가까워지려고 한없이 노력하겠지만 영원히 도달할 수는 없는 개념이다. 그렇기 때문에 이 항목도 '내가 적정 설계를 할 수 있게 되었다'는 말 보단, '내가 시도했던 것들 중 적정 설계가 아니었다고 판단한 것들'이라는 의미라고 할 수 있다.

  • 채팅 서비스를 센드버드를 사용해서 구현한 것
  • 작은 팀에서 바운디드 컨텍스트로 일부 코드를 격리한 것
  • 어드민을 독립된 프로젝트로 생각한 것(서버 입장에서)

처음에는 센드버드를 사용해서 아주 빠르게 채팅 서비스를 구축할 수 있었지만, 바로 다음 상황에서부터 문제가 발생했다. 채팅 자체 외에, 센드버드에 저장된 데이터를 활용해서 기능을 구현해야 했는데, 이를 위해서 데이터를 두벌로 관리했다(센드버드 + 우리 DB). 이는 sdk 활용이나 데이터를 소싱하는데 혼란을 가져왔던 것 같다. 다음에는 (채팅 트래픽이 많은게 아니라면)그냥 게시판 만들듯이 단순하게 구현할 것 같다.

바운디드 컨텍스트는 조직이 일하는 방식과 방향을 같이해야 하는 것 같다. 우리 팀은 상당히 작았기 때문에, 일하는 직원 사이에 맥락을 구분하기가 힘들었다(실제로 사람들이 엄격히 구분된 맥락에서 일하고 있지 않음). 그런데도 코드를 격리하는 것은 도메인 모델이 실제 업무와 달라지게 두는 것과 같다. 불필요하게 복잡도만 키운 셈이다.

어드민을 독립적인 프로젝트로 구현하는 경우는 이전 회사에서 흔했기 때문에, 이번에도 어드민을 독립적인 바운디드 컨텍스트로 구현했다. 하지만 어드민이라는 이유만으로 비즈니스 로직이 분리되는 것은 아니었다. 오히려 어드민이라는 화면이 (서버)메인 도메인 모델의 비즈니스 로직을 이용한다고 보는것이 적절했다. 서버 입장에서는 코드를 분리할 필요가 없다. 다만 권한 관리만 잘 해주면 된다.

전체적으로, 코드를 격리할 시간에 도메인 모델의 테스트 코드나 하나 더 짜는게 낫겠다는 생각을 했다. 이 외에도 도메인 이벤트나 레파지토리 패턴을 구현했던 경험은 아쉬운 점은 있었지만 아주 좋았다. 코드에 대한 자세한 내용은 따로 글을 작성하면 좋을 것 같다.

제품의 방향성 생각하기

여전히 나는 고객의 목소리로부터 최초의 프로젝트 제안(거창한 제안이 아닌 그냥 한줄짜리 아이디어라도)까지 도달하기를 어려워하는 사람이다. 요새 표현으로 말해보자면 '0 -> 1'이 잘 안되는 사람이라고도 말할 수 있을 것 같다. 내가 제안한게 하나도 없는 것은 아니지만, 최소한 내 눈으로 봤을 때는 누구나 생각할 수 있거나 인상적이지 못한 제안만 했다는 느낌이다. 그러나 여러번의 경험을 통해, 다음과 같은 기준들은 생긴 것 같다.

  • 내가 생각하는 좋은 비전의 기준
  • 우리가 생각해낸 프로젝트를 평가하는 나의 기준
  • 그 프로젝트들 사이의 우선순위를 평가하는 나의 기준

최고의 비전, 프로젝트, 우선순위를 찾을 수 있는 능력이 생겼다는 뜻은 아니다. 내가 어떤 사람인지 더 잘 알게 되고, 그에 따라 내 가치관에 부합하는 기준들을 조금 더 명확하게 가질 수 있게 되었다는 뜻이다. 그래서 그 기준이 뭐냐?라고 묻는다면, '한마디의 일반적인 원칙으로 정리하기는 어렵다'는 맥빠진 대답밖에 못할 것 같지만...(이것도 정리해 봐야지) 그래도 상황에 따라 내 기준에 맞으면서도 최대한 합리적인 선택을 하는 연습을 할 수 있었다.

실무와 병행하다 보니 의사 결정에 충분히 시간을 쏟지 못했던 것도 후회스럽다. 프로젝트를 계획할 때, 이미 나를 한명의 온전한 개발자로 생각해서 일정 계획을 수립했다. 일정을 맞추기 위해 개발에 집중하다 보니, 다음 프로젝트를 준비하는데 병목이 생겼던 것 같다. 아래에서도 말하겠지만, 의사 결정권이 있는 사람은 항상 의사 결정을 최우선 순위로 두고 일을 해야 하는 것 같다.

매니저로서 경험 쌓기

개발이 한창 진행중일 때, 기획의 구멍이나 자세한 의사결정들을 처리해야하는 입장이었던게 좋은 경험이었다. 실무자 모두가 나를 바라보고 있는데, 진짜로 '나는 내 일 보다 남의 일을 해주는게 더 중요하다'는 사실을 명시적으로 깨닫게 된 것 같다. 사실 매니저로서 어찌보면 당연한 말이지만, 항상 다른 사람의 일에 신경쓰고 내가 그들의 병목이 되지 않게(가장 높은 우선순위) 노력했던 경험은 새롭고 즐거웠던 것 같다.

커뮤니케이션과 의사 결정에 있어서 팀원들 사이에 오해가 발생하지 않게 신경썼다. 자세한 내용은 아래에 작성했는데, 요는 내가 원하는 바를 스스로 명확히 하고, 그것을 직접적으로 전달하는 것을 중요하게 생각했다는 것이다. '앞으로 이런 방식으로 커뮤니케이션 해주세요', '그 일보다 이 일이 더 중요하니까 먼저 진행해주세요' 같은 말을 주저 없이 하려고 노력했다. 팀을 원하는 방향으로 변화시키기 위해서는, 내 생각을 구체적으로(엉뚱한 결과가 나오지 않게) + 끈기있게(행동을 바꾸려면 시간이 오래 걸림) 전달하는게 가장 중요한 것 같다. 물론 그 과정에서 팀원 -> 팀장의 방향으로 피드백을 줄 수 있는 심리적 안정감을 형성하는 것도 정말 중요하지만 말이다.

또, 신입 팀원 중 한 분이 처음에 자신감이 많이 없어서 팀에서 안정감을 주기 위해 노력했다. 물론 나보다는 바로 옆에서 일하는 사수의 영향(그 분도 좋은 분이었기 때문에)이 더 컸을 것 같지만, 그래도 내가 할 수 있는 일을 하려고 했다. 내가 그 분께 실제로 공감하고 있다는 것을 알려주고 싶었고(나도 그랬으니), 주니어가 기대에 못 미치는 성과를 낸 것은 팀원의 잘못이 아니라, 이룰 수 있는 목표를 설정하고 거기에 단계적으로 갈 수 있게 유도하지 못한 팀장의 잘못이라는 것을 알려주고 싶었다. 실제로 주니어 팀원에게 문제가 생겼을 때는, 대체적으로 회사 탓일 확률이 높다고 생각하는 편이다. 그분의 실력을 빠르게 올리기 위해서 그 분의 사수와 이야기를 많이 나누고 스터디나 페어프로그래밍 같은 실천도 했다. 결과적으로 몇 달 후에는 자신감이 많이 상승해서 아주 뿌듯했다. 지금 생각해보니, 변화를 만드는데 가장 효과가 좋았던게 무엇이었는지 그 분께 더 명시적으로 피드백을 받았으면 더 좋았을 것 같은데...

나에 대해서 알게 된 것

사실 이 부분이 제일 중요하다! 힘든 일이 많이 있었고, 나름의 노력은 했지만 실패도 정말 많이 했다(결과의 실패도 있겠지만 과정의 실패). 그러다 보니 나에 대해서 많이 알게 되었는데, 이를 정리해서 기록해두려고 한다.

커뮤니케이션 방식

오해가 발생하는 것에 민감하다. 오해 때문에 일을 두번하거나, 했던 말을 계속 반복해야 하는 상황을 피하는 것을 중요하게 생각한다. 그러다보니 항상 내 의도가 충분히 전달이 되지 않을까봐, 내가 상대방의 의도를 오해하거나 상대방이 내 의도를 오해할까봐 많이 걱정을 한다. 그래서 다음과 같은 것들을 선호하고, 나와 상대방이 지켜주기를 기대한다.

  • 내 의도를 최대한 구체적으로 밝히고 많은 맥락을 첨부하는 것을 선호한다.
  • 반대로 상대방의 의도와 맥락에 대한 질문을 많이 해주는 것을 선호한다.
  • 내가 느끼는 문제 의식을 말할 때는 최대한 좁혀서 말하는 것을 선호한다(뾰족하게 '이 부분이 문제입니다'라고 할 수 있게). 광의의 표현을 사용할수록 상대방에게 내 마음을 맞춰보라고 하는 뉘앙스를 풍길 수 있는데, 이를 최대한 피하려고 노력한다.
  • 문제를 제기할 때는 내가 궁극적으로 원하는 모습/상황/결과가 뭔지 구체적으로 이야기하는 것을 선호한다. 내가 원하는 바를 구체적으로 설명할 수 없다면, 스스로 어떤게 문제라고 생각하는지 인지하지 못하고 있는 셈이다. 본인이 알지 못하는 문제는 다른 사람도 알 수 없다.
  • 일반화 표현을 사용하지 말고 구체적인 사례 중심적으로 말하는 것을 선호한다. 위와 비슷하다. 일반적-추상적 표현은 각자의 해석을 다르게 하고 그러면 행동을 다르게 한다. 결국 내 의도와 관계 없는 결과를 얻게 될 확률이 있다.
  • '열린 질문'은 없다는 믿음을 가지고 있다. 왜냐하면 '의도' 없는 발화는 없다고 믿기 때문이다. 발화자는 항상 자기의 의도가 뭔지 잘 알고 있어야 하고, 듣는 사람에게 이를 충분히 공유해야 한다. 모든 질문은 항상 어느정도는 '닫힌 질문'일 수 밖에 없다.

이런 것들을 중요하게 생각하다보니 그에 따른 단점들도 많이 경험했던 것 같다. 어쩌면 양날의 검일지도 모르겠다. 단점들에 대한 피드백도 여러번 받았는데, 정리해보면 대개 아래와 같은 현상으로 나타났던 것 같다.

  • 내가 고민한 내용과 맥락을 최대한 많이 전달하려는 과정에서, 나도 모르게 '내가 모든 것을 다 생각해 봤다'는 완고한 뉘앙스를 풍기기 쉽다.
  • 의도와 맥락을 파악한답시고 지나치게 따지거나 꼬치꼬치 캐묻는 느낌을 준다. 상대방이 많이 생각해본적 없는 문제에 대해서 구체적인 질문을 하는 것은, 발화 스킬에 따라 공격적으로 보이기 쉽기 때문에 섬세한 주의가 필요하다.
  • 이런 스타일의 대화 방식 자체가 상대방을 숨막히게 하거나 질려버리게 할 수 있다.
  • 만약 리더의 입장이라면, 팀원들과 구체적인 이야기를 많이 할 수록 마이크로 매니징의 함정에 빠지기 쉽다.

정확하게 내용을 전달하면서 상대방의 감정과 반응을 동시에 고려하는 방법을 익히는 것은 내 평생의 과제이다. 유명한 책 <래디컬 캔도어>의 '직접적 대립'과 '개인적 관심'을 동시에 가져야 한다는 말과 비슷한 내용인 것 같다. 하지만 아직도 어렵다. 특히나 내가 기대를 많이하고 있는 상대(나보다 나이도 많고 좋은 경력에 똑똑한 상사)에게는 더더욱 어렵다. 이 부분을 어떻게 더 좋게 만들 수 있을지... 솔직히 지금으로서는 너무 막막한 상황이다. 지금으로서 내가 할 수 있는 것은, 내가 내 스타일에 대해서 더 잘 알게된 만큼, 내 스타일과 상대방을 향한 기대를 빨리 공개하고 거기서부터 출발하는 것이다. 이 부분에서 언젠가는 내가 만족할 만한 수준에 오를 수 있을까? 어디서 코칭이라도 알아봐야 할지...

또 '의도를 구체적으로 전달하는 것'과 '위임을 하지 않는 것'의 차이를 명확히 알고, 적절한 선('적절한 선'이라는 단어는 너무 추상적이어서 별다른 의미를 담지 못하는 말이겠지만) 위에서 움직이기 위해서 노력해야 할 것 같다.

의사 결정 방식

나는 빠르고 투명한 의사 결정을 좋아한다. 이렇게만 말해버리면 너무 뻔한 이야기가 될 것 같으니 조금 더 구체적으로 말해보자면,

  • 말 그대로 의사 결정에 걸리는 시간이 짧은 것을 선호한다. 결정권자가 결정을 하루 미루면, 실무자들은 (팀원의 수 X 하루) 만큼의 시간을 낭비하게 된다. 그러기 위해서 결정권자는 모든 업무 중에 의사 결정을 최우선 순위로 두고 일하는 것이 좋다고 생각한다.
  • (당연하게도) 고민의 기간이 극단적으로 짧은 것은 예외로 한다. 다음 프로젝트를 정하는 회의에서 고민을 시작한지 5분만에 결정을 내릴 수는 없다. 회의 전에 최소 수시간 정도는 고민을 해왔어야 한다.
  • 당장 결정이 어려우면 '지금은 어려우니 언제까지 결정하겠다'고 결정하는 것을 선호한다. 이것은 차선의 상황이지만, 어쨌거나 결정을 한 것이다. 아무것도 결정하지 않은 것보다는 훨씬 나은 상황이다.
  • 결정을 미룰때는 '왜 지금 결정하기 어려운지' 그 고민을 구체적으로 공유하는 것을 선호한다. 결정권자가 어떤 고민을 하고 있는지 알아야 실무자가 그 결정을 돕기 위한 의견이나 자료를 공유할 수 있다.
  • 팀이 빠르게 움직이기 위해서, 리더가 전권을 행사하는 것을 선호한다(민주적 결정 비선호). 특히 팀이 작을 수록 더 그렇다. 이건 내 퇴사의 직접적인 이유이기도 하다. 내가 대표의 의견에 반대를 너무 많이 한다고 느꼈기 때문이다.

사실 빠르게 결정한다는 것은 정말 어려운 일이다... 중요한 일일 수록 더 그렇다. 그러나 같은 결과를 도출한다는 가정 아래, 항상 빠르게 결정하는 것이 천천히 결정하는 것 보다 좋다. 왜냐하면 작은 회사에게 시간은 가장 중요한 자원이고, 결정이 늦어지는 만큼 시도해볼 수 있는 프로젝트의 수가 줄어들기 때문이다. 어떤 프로젝트가 성공할 수 있을지 확신하기 어려운 불확실성의 세계에서, 시도의 횟수를 늘리는 것은 나에게는 너무 중요하게 느껴진다.

그럼에도 불구하고 결정을 미루게 되는 상황은 언제나 반드시 발생하기 마련이다. 하지만 그 상황은 더 오래 고민하면 더 좋은 결과를 도출할 수 있을 것 같다는 '실마리'가 있을 때여야 한다는 생각이다. 여기를 찾아보면 궁금증이 해결될 것 같다던지, 누구에게 물어보면 경험을 공유 받을 수 있을 것 같다던지 등등... '실마리' 없는 결정 지연은 '혹시 좀 더 있으면 뭐라도 떠오르지 않을까'라고 요행을 바라는 것과 같다. 그리고 그 실마리를 찾았으면 반드시 '팀에게 공유'해야(결정 지연 사유를 공유하는 셈이다) 한다고 생각한다.

갈등 해결 방식

갈등 해결 방식을 맞춰나가는 것은 회사를 포함한 모든 인간관계의 핵심이라고 할 수 있을 정도로 중요하면서도 어려운 분야인 것 같다. 이 부분을 더 잘하기 위해서는 (물론 다른 분야도 마찬가지겠지만 특히 더)'내가 선호하는 갈등 해결 방식을 명확하게 알기'에 집중해야겠다는 생각을 했다.

  • 가능한 빠르게 해결하는 것을 선호한다. 해결되지 않은 갈등 상태는 업무 퍼포먼스를 포함한 모든 일상 생활에 치명적인 문제를 일으킨다.
  • 감정(욕망)에 먼저 집중하고, 내용은 나중에 살펴보는 것을 것을 선호한다. 나와 상대방이 가진 욕망과 감정을 아는게 제일 중요하다. 개인적으로는 가장 힘든 부분이다. 갈등이 시작되면 습관적으로 내용부터 이야기하려고 한다.
  • 그러다보니 본인의 감정이나 욕망을 언어화(말 혹은 글)하는데 거부감이나 어려움이 없는 사람을 선호한다. 언어화는 구체적일수록 좋다(내 마음을 더 자세히 알고 있다는 뜻이니).
  • 아직 내 마음을 눈치채지 못했거나 정리가 안 된 상태라서 빠르게 대화가 불가능하다면, '아직 정리가 안 되었으니 이 날에(날짜 정하기 중요) 다시 이야기해 보자'라고 말해주는 것을 선호한다.

나의 세계관 안에서, 사람은 이성으로 움직이지 않는다. 탄탄한 논리를 갖춘 주장이 있을 수 있지만, 그 논리를 주장하고 싶은 마음(동기) 자체는 감정이나 욕망으로부터 나온다는 생각이다('가치관' 조차도 감정이나 욕망으로부터 구성되는 경우도 꽤 있는 것 같다). 그래서 갈등의 내용에만 집중하면 저 사람의 동기를 이해하지 못하고 다음에 비슷한 갈등이 반복될 확률이 높아진다고 생각한다.

하지만 아는 것과 별개로, 실제로는 이렇게 감정에 집중하는 대화를 하는 것은 정말 어려운 것 같다.

  • 내 스스로의 상태를 관찰하기 위한 섬세함
  • 내 저열하고 부정적인 마음을 스스로 인정하고, 상대방에게도 공개할 수 있는 용기
  • 대체로 남에게 있는 부정적인 속성은 나에게도 있다는 믿음

이 필요한 것 같다. 매번 노력한다고 생각하지만 대부분의 경우 당시에는 잘 모른다. 내가 어떤 감정과 욕망으로 말했고 행동했는지, 그 마음을 정당화하기 위해서 얼마나 화려한 논리를 수단적으로 가져다 붙이려고 했었는지... 나중이 되서야 부끄럽게 인정하는 경우가 태반이다(나중에라도 인정하면 다행).

그렇다면 최근에 있었던 갈등에서의 내 마음은 어땠을까? 많은 경우 내가 아는 뭔가를 것을 상대방이 모른다고 느꼈을 때 따라오는 자만심과 상대방을 향한 실망감이었던 것 같다. 흔히 '사람들은 자기가 아는 것이 반드시 알아야 하는 제일 중요한 것이고, 자기가 모르는 것은 알 필요가 없는 것이라고 생각한다'는 말을 하는데, 당시의 내 마음도 비슷한 경우라고 할 수 있다. 물론 내가 중요하다고 생각하는 것이 실제로 전혀 중요하지 않은 것은 아니었겠지만, 내가 너무 지나치게 강조했을 수 있다. 내가 관심이 많은 문제에 상대방도 부응해주기를 강박적으로 바라는 것이다. 하지만 꽤 많은 문제는 천천히 해결해도(심지어는 그대로 두어도) 괜찮을 수 있다. 하자만 그럼에도 불구하고 가볍게 보지 못하고 초조한 이유는, 문제 해결하고 싶다는 마음 자체보다, 상대방에게 영향력을 행사하면서 내 존재감을 인정받고 싶다는 본능적인 욕망이 앞섰기 때문일 수 있다.

실망감도 마찬가지다. 실망감 만큼 바보 같은 감정도 없는 것 같다. 나에게 장점과 단점이 있는 것 처럼 상대방도 마찬가지일텐데, 멋대로 완벽한(완벽해야하는) 상대방을 그려놓고 거기에 미치지 못할 경우 엄격한 뭔가를 들이대는 것은 혼자서 우스꽝스러운 1인극을 하는 것과 같다. 효과적인 태도가 아니다.

이런 내 마음을 충분히 안 상태에서 다시 한 번 같은 갈등 상황에 처하게 된다고 해도, 결과가 달라지지는 않을 수 있다(실제로도 아닐 것 같다). 하지만 시작과 과정은 꽤 달랐을 것이다. 나에게는 그게 중요한 것 같다. 결과를 바꿀 수 있는, 그러면서 내가 할 수 있는 유일한 방법은 과정을 더 잘 하는 것 밖에는 없을테니까...

슬픔

이런저런 일들을 겪을 수록 나에 대해서 더 많이 알게되고, 그럴수록 내 문제가 더 선명하게 눈에 들어온다. 그 중 어떤 문제는 상당히 오랜 기간(십수년 이상) 나를 괴롭혀온 것도 있다. 나는 분명히 조금씩 나아지고 있다. 스스로 중요하게 생각하는(잘하고 싶은) 모든 분야에서 2년 전 보다 약간이라도 나아졌다. 하지만 솔직히 말하면 이상적인 나와 현실적인 나의 갭이 여전히 너무 커 보일 때가 많다. 이럴 때 나는 무력감을 느끼고 내가 뭔가를(그게 뭐든) 이룰 수 있을 것 같다는 생각이 들지 않는다. 그럴 때 슬프다. 슬픔은 무력함의 감정이다.

기쁨

하지만 내가 내 자의식과 인정욕구를 조금이나마 내려놓을 수 있다면(내 스타일과 철학을 유지하면서도 자의식을 내려놓겠다는 말은 종종 모순처럼 느껴진다), 스스로와 주변에게 더 가볍고 너그러운 마음을 가질 수 있다면(왜 평소에는 잘만 느끼는 공허의 감정이 회사 안에서는 느껴지지 않는 걸까?), '현실과 이상의 갭'보다 '조금씩 나아지는 나'에 집중할 수 있다면, 내 안의 무력감과 슬픔의 감정을 앞으로도 계속 일할 수 있는 힘으로, 기쁨으로 바꿀 수 있을지도 모르겠다. 그 때가 되면 무언가를 이룰 수 없을 것 같다는 생각도 들지 않을 것이다. 왜냐하면 무언가를 이룬다는 것이, 목적지에 도달한다는 것이 더 이상 중요하지 않을테니까...