brunch

브런치북 사적인 호감 09화

라이킷 10 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 공원 Mar 18. 2019

좋은 동료가 되고 싶은 나에게

개발자로 일하며 몇 개의 계절을 보냈다.

개발을 배우기 전까지 나는 전형적인 우리나라의 문과생이었는데, 그때는 개발자라는 걸 상상해보면 영화나 드라마에 나오는 것처럼 어두운 방(?)에 혼자 앉아 알 수 없는 명령어들이 떠있는 컴퓨터 화면을 바라보며 일할 것만 같았다. 그러니까 사람들과 하는 일이라기보다는 컴퓨터와 마주 앉아 씨름하는 일.

개발을 배우기 시작한 뒤에도 한동안 이건 개인의 능력으로 헤쳐나가야 하는 기술적인 일이라고 여겼다. 프레임워크, 설계, 테스트, 네이밍, 클린 코드... 배울수록 기술적으로 어려운 부분들은 계속해서 나왔고 개발자로 잘 일할 수 있으려면 이 문제들을 다 헤쳐나갈 수 있는 슈퍼개발자가 되어야 한다고 생각했다.

그러니까 이런 거

막상 회사에 들어와 보니 생각과는 조금 달랐다.

물론 직업 성격상 기술적인 부분은 당연히 계속해서 익히고 고민해야 하지만, 그게 다는 아니었다. 슈퍼개발자가 당장 될 수도 없지만, 슈퍼개발자가 되어야만 일을 할 수 있는 것은 아니었고, 컴퓨터보다는 동료들과 잘 이야기할 수 있어야 했다.

내가 무슨 생각으로 코드를 이렇게 짰는지 공유해야 했고, 같이 일할 때 오해가 생기지 않도록 기록을 남겨야 했고, 회의에 들어가 의견을 듣고 말해야 했고, 코딩 자체보다 내가 무엇을 코딩해야 하는지를 분석하고 같이 확인하는 데에 시간이 더 들여야 하는 때도 많았다.

사실은 이렇다

결국은 사람과 같이 해야 하는 일이었던 거다. 일을 하나씩 잘 마무리해내려면 슈퍼개발자 이전에 좋은 동료가 되려면 어떻게 해야 하는지를 배워야 했다. 몰라서 챙기지 못했던 것, 실수했던 것, 새로운 것들을 시도하며 배운 것들에서 나름대로 다음부터는 이렇게 해야지를 다짐해두곤 했다.

'못한다'고 할 수 있는 능력

원래도 혼자 파고들어서 생각하고 고민하는 성향이라 이게 정말 어려웠다. 일정이 빠듯할 때, 기술적으로 잘 안 풀릴 때, 다른 파트와 커뮤니케이션이 꼬일 때 등등 일이 잘 안될 것 같은 순간들은 참 많다. 처음에는 그렇게 어려움이 생기면 어떻게든 혼자 해결해내려고 애썼다. 못한다고 하는 순간 내 스스로가 못나 보이는 마음, 어렵다고 하면 나를 무능하게 보는 건 아닐까 하는 걱정, 혼자서도 척척 모든 걸 해내는 잘난 사람이 되고 싶은 욕심, 못한다고 말하기 어려운 이유는 너무도 많다.

물론 당연히 내가 할 수 있는 것들은 책임지고 해낼 수 있어야 한다. 해낼 수 있는 일을 늘려가고 싶기도 하고. 하지만 한편으로는 못하겠을 때는 제때제때 안되겠다고 하고 도움을 요청해야 했다. 요즘은 적절한 타이밍에 적절하게 도움을 요청할 수 있는 것 자체가 일종의 '능력'이라는 생각도 든다. 제가 이런 문제가 있어서, 이런 해결책을 시도해보려고 했는데, 이런 부분에서 잘 안되고 있어서 도움이 필요하다는 식의 요청을 할 수 있는 것.

내가 어떤 걸 모르고 있어서인지, 일정을 잘못 계산했던 것인지, 동료의 백업이 필요한 것인지. 못한다고 할 줄 알아야, 할 수 있도록 하려면 어떻게 해야 할지를 같이 이야기할 수 있었다.

Strong view, weakly held

조직 문화에 대한 글을 한참 읽어대던 때가 있었는데, 그중 좋은 팀원의 조건으로 'strong view, weakly held'를 설명하는 글이 있었다. 검색을 다시 해보면 아마도 올바른 의사결정을 할 때 따르는 프로세스를 제안하는 개념( 'Strong Opinions, Weakly Held')에서 따온 것 같은데, 조금 변형해서 그냥 같이 일하는 태도에도 적용할 만하다 싶었다. 분명하게 내 의견을 가지되, 언제든지 틀릴 수 있다는 것을 명심하기.

개발에서 베스트 프랙티스라는 것들이 있기는 하지만, 매일의 내가 판단해서 해결해야 하는 문제들에는 어느 한 가지 안이 명확하게 항상 더 좋다고 하기 애매한 경우가 많다. 1안을 선택하면 장기적으로 다른 스펙도 대응할 수 있는 대신 개발 일정이 조금 더 필요한데, 2안을 선택하면 더 빠르게 개발할 수 있는 대신 딱 지금 상태만 대응이 가능해서 스펙이 변경되면 같이 수정이 필요하다거나. 변경될 일이 있을지 없을지, 얼만큼 바뀔 수 있을지 같은 건 상황 따라 다르고 기능 따라 다르니 이런 경우에 정해진 답은 없는 노릇이다.

약간 팔랑귀에 걱정병을 지병으로 앓고 있는 나는 이런 경우에 무척 곤란해진다. 1안으로 했는데 변경될 일이 사실 없으면 불필요한 일 아닌가? 근데 2안으로 했다가 다음 달에 막상 또 수정해야 하면 우째? 어느 쪽을 선택해도 위험요소가 있으니 내가 한 선택이 잘못될까봐 겁이 났다. 그렇다고 내가 하나를 선택하지 않은 채로 동료들에게 1안 2안을 늘어놓고 설명만 하다가 사람마다 의견이 갈리면 더 혼란만 커졌다.

우짠담

요즘은 이런 경우에 판단하는 연습을 하려고 노력중이다. 지금으로서는 추가로 수정해야 할 일이 거의 없을 것 같으니 수정 범위가 적은 2안을 선택하자는 식으로 어느 한쪽을 선택하고 그걸 동료들에게도 공유하는 연습. 의견을 구하더라도 일단은 내 선택을 정해두고, 대신 내가 미처 생각하지 못한 부분들이 있다면 그때그때 선택을 바꿀 수 있게 가벼운 마음을 준비한다.

같이 잘 일하기 위한 방법도 어떤 팀에, 어떤 상황에 있느냐에 따라 계속해서 바뀔 게 분명하다. 지금의 나는 이런 것들을 좋은 동료가 되기 위해 스스로 지키고 싶은 것들로 생각하지만, 시간이 지나고 경험이 쌓이며 생각이 바뀔 수도 있다. 작년에는 맞았던 방법이 올해에는 틀릴 수도 있다.

그렇더라도 일단은 그때 그때 내 나름의 방식대로 분명하게 대처하고, 언제든지 더 나은 방식이 있다면 다시 녹여낼 수 있는 사람이 되고 싶다. 그렇게 해서 시간이 많이 지나더라도 ‘저 사람은 대체 왜 저러나’ 싶던 꼰대가 내가 되는 속상한 일은 일어나지 않길 바라며.

keyword

Brunch Book

사적인 호감