brunch

브런치북 개발자가 되고 싶지 않아요 06화

라이킷 7 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by sehrjung Oct 22. 2023

자기 검열

스스로를 괴롭히기

일 할 때 내가 갖고 있는 좋은 습관 중 하나는 상대에게 질문하기 전 최대한 스스로 답을 찾으려 노력한다는 거다. 그래도 답을 찾지 못했을 때는 내가 무엇을 왜 모르고 어떤 부분에서 막혔는지에 대해 질문한다.

이렇게 하는 이유는 떠 주는 밥만 먹는다는 이야기를 듣기 싫은 탓도 있을 거고, 상대의 시간을 낭비하고 싶지 않아서이기도 한 것 같다. 또 한 편으로는 쟤는 저것도 몰라? 무슨 저런 걸 물어봐?라고 상대가 생각할까 봐, 사실은 너무나도 어리석은 질문이었을까 봐 그런 걸 지도 모른다.

아마 베를린에서 시니어 엔지니어로 일하기 시작하고 몇 개월이 흘렀을 때였을 거다. 나는 아래 강박들이 더 강해진 스스로를 발견했다.

- 틀린 말을 할까 봐 말하기 전에 엄청 긴장한다

- 페어 프로그래밍을 하다가 잘 해내지 못할까 봐 식은땀을 흘린다

- 기술적으로 서로 다른 의견이 있을 때는 대체로 상대의 의견을 따른다

고양이를 만지면 강박이 조금 나아지는 것 같기도...?

1. 이제 스스로 해야지

신입 일 년 차 때 일이다. 어떤 일을 하다가 도저히 모르겠어서 옆자리 선배에게 "선배님 질문이 있는데요. 도와주실 수 있나요?"하고 물었던 적이 있다. 어쩌면 그는 그날따라 기분이 좋지 않았을 수도 있고 유독 바쁜 날을 보내고 있었을지도 모른다.

그는 내 쪽을 보지도 않고 퉁명스럽게 "이제 그 정도 연차 됐으면 스스로 해."라고 대답했다.

나는 고작 일 년 차인데. 매번 아무 생각 없이 질문하는 것도 아니고. 그리고 신입이면 가장 마음껏 질문할 수 있는 연차이지 않은가? 자존심이 상한 나는 화장실에 가서 눈물을 흘리며 더럽고 치사한 XX라고 생각했다.

그리고 다짐했다. 내가 선배가 된다면 저딴 선배가 되지 말아야겠다고. 후배가 모르는 것들을 잘 알려주고, 어떻게 똑똑하게 일해야 하는지 차근차근 설명해 주는 선배가 되어야겠다고.

2. 동기 비동기도 몰라?

이건 이년 차 초 때 일이다. 테크 리더가 어떤 프로토콜 문서를 읽고 구두로 빠르게 요약해 달리기래 대충 저녁식사를 끝내고 자리로 돌아와 열심히 영어문서를 읽었던 기억이 있다.

빠르게 읽고 나서 내가 요약한 부분을 전달했는데 리더가 내게 "이 프로토콜은 동기 방식이야 비동기 방식이야?"라고 물었다. 나는 기억이 나지 않는다 대답했고 그는 그런 나를 답답해하며 "동기 비동기도 몰라?" 하고 핀잔을 주는 게 아닌가.

나는 이게 그렇게 까지 잘못한 일인가 싶었다. 모르면 좋게 좋게 가르쳐주는 게 시니어의 역할 아닌가? 이 놈이나 저 놈이나 화가 치솟는 일이었다.

건너편에서 이 상황을 모두 듣고 있던 한 책임님 (과장직급) 한 분은 잠시 후 내 자리에 와서 함께 기술문서를 읽어주시겠다고 했다. 이런 문서는 어떻게 읽어야 하고 이 뜻은 무엇이고 저 뜻은 무엇인지 설명해 주셨고 올챙이였던 시절을 잊은 그들을 함께 험담하며 다음에 같이 치킨을 먹으러 가자고 약속했다.

3. 기술적 가스라이팅(?)

대부분의 개발팀 내에서는 기술적 입김이 센 사람이 최소 한 명 존재한다. 그 사람은 상대의 의견도 잘 수용하는 평화로운 사람일 수도, 내 마음대로 고집쟁이일 수도 있는 일이다.

안타깝게도 내가 일했던 대부분의 개발팀에서는 내 마음대로 고집쟁이들이 즐비했고 그들과 대적하는 순간 전쟁이 시작됐다.

베를린에서 처음 입사한 회사는 개발자 스무 명이 조금 넘는 스타트업이었는데 기술적 가스라이팅이 더 도드라지게 활보칠 수 있는 환경이었던 것 같다.

회사 초기부터 일한 개발자 D 씨는 내가 입사하기 전 클라우드 팀 - 내가 입사한 팀이다 - 에서 일했다. 그는 제 마음대로 개발팀을 전두지휘 하고 있었는데 새로운 테크리더 O 씨가 입사하는 바람에 문제가 생겨버렸다.

D와 O는 둘 다 의견이 강한 편이었어서 그 둘이 회의를 할 때면 회의실에서 고성이 오갔다고 했다. 내가 팀에 입사했을 때는 이미 D는 infrastructure 팀을 만들어 그 부서에서 일하고 있었다.

입사 후 나는 D와 O로부터 자유로울 수 없었는데, D는 클라우드 팀이 짜는 코드나 기술적 문서에 언제나고 코멘트를 달았다. 좋게 말하면 다른 팀에 대한 관심, 나쁘게 말하면 지나친 간섭과 방해라고 생각했다.

예를 들면 나는 예전에 로깅 관련 라이브러리를 만드는 업무를 맡은 적이 있는데, 내가 작성한 기술문서를 읽은 D는 다른 방법으로 구현했으면 좋겠다는 의견을 달았다. 영어가 모국어였던 그는 자신이 쓴 문장에 대한 별다른 검열 없이 생각나는 대로 코멘트를 달았던 반면, 영어가 비모국어였던 나는 성심성의껏 그 의견에 반하는 의견을 재댓글 달았다. 하지만 D는 자신의 업무가 바쁘다는 핑계로 내 의견을 읽지 않고 있었다.

문제는 팀 내에 D의견 신봉자인 사람들이 여럿 있었고 그들은 그의 의견을 받기 전까지 내 일을 잠시 멈추자고 했다.

물론 D는 굉장히 똑똑한 사람이었고 분명 배울 게 많았을 거라고 인정한다. 하지만 이제 갓 입사한 내 눈에는 팀사람 대부분이 항상 D의 의견을 따르고 그의 의견대로 움직이는 꼭두각시들 같아 보일 뿐이었다. 결국 나도 그 꼭두각시 역할을 할 수밖에 없었지만 말이다.

4. 싸워서 쟁취하라

이건 3. 기술적 가스라이팅과 연결되는 이야기다.

테크리더 O는 내게 D와 의견 싸움을 해서 내 의견을 쟁취해 내라며, 평화주의를 고수하는 내 업무 스타일을 지적해 왔다.

나는 O에게 "사람마다 성향이 다른 거고 나는 싸우면서까지 내 의견을 강요하고 싶지 않아." 라 대답했지만 그는 이건 성향이 다른 게 아니라 내 업무 방식이 잘못됐으니 고쳐야 한다고 주장할 뿐이었다.

어쩌면 누군가는 O의 방식이 옳다고 생각할지도 모른다. 어떻게 서든 상대가 내 말을 듣게 하도록 지지고 볶으며 싸워야 하는 걸지도 모른다. 하지만 이건 세상 구하는 일도 아닌 데다 기껏해야 조그마한 기술적 의견 차이인걸? 무엇보다 회사 일이란 팀워크를 기반으로 함께 하는 일인데 동료와 얼굴을 붉히면서까지 일하고 싶지 않았다. 또 내 말을 들을 준비되지 않은 사람에게 이런 걸로 에너지를 낭비하고 싶지 않기도 했다.

결국 그런 개발자를 대항해 내가 선택했던 방식은 의견이 강한 사람의 말대로 구현을 하되, 그 방식이 결국에는 잘못됐음을 증명해 내는 거였다. 물론 구현을 하다가 상대의 방법이 정말로 옳았을 때도 있고, 제3의 더 나은 방법을 발견할 때도 있다.

나는 결국 늘 내 업무 스타일을 지적하던 O에게 팀을 바꾸고 싶다고 말했다. 너와 나는 일하는 스타일이 잘 맞지 않는 것 같으니 내가 팀을 바꾸겠다고 말이다. 그는 자신은 그런 의도가 아니었다며 다시는 그런 식으로 내게 밀어붙이지 않겠다고 말했고, 그의 미안함이 느껴져 조금 더 팀에 머물며 상황을 지켜보기로 했다. 하지만 결국은 도돌이표였고 그는 내가 바뀌기를 원했다.

2020년 12월. 오랜만에 방문한 한국에서 해외 입국자 자가격리를 하며 회사를 그만두어야 하나 고민하고 있었을 때 즈음 메일로 해고 통지를 받았다.

스무 명에 달하는 개발자들은 팬데믹으로 해고를 당했고 명단에는 O와 나 둘 모두 들어있었다.

keyword

Brunch Book

개발자가 되고 싶지 않아요