brunch

라이킷 13 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by roseline Jan 19. 2022

따뜻한 개발자 되기

따뜻한 로봇이 되는 게 목표입니다

따뜻한 로봇이 되자

내 신년 목표는 따뜻한 로봇이 되는 것이다.

친구에게 올해부터는 따뜻한 사람이 되겠다고 하니 그건 안되고 따뜻한 로봇은 될 수 있을 거라 했다.

사실 나는 사람들에게 따뜻하게 대한다고 생각했는데 회사 사람들이 보기엔 나는 로봇에 가까웠던 것 같다.

동료들에게 재미로 내 MBTI를 맞춰보라고 했는데 단박에 INTJ(공감능력 부족한 계획형 인간)라는 것을 알아본 것이다.

What do you mean I'm cold?

한 팀원분이 사례를 들어주셨다. 이 분이 신규입사자였을 당시 와이파이가 안되서 나에게

"혹시 와이파이 되시나요?"

라고 물어보셨다. 그런데 내가,

"네. 전 잘 되는데요"

이러고 말았다는 것이다(뒤도 안돌아봤댄다). 충격이었다. 그런 일이 있었는지 기억도 안났기 때문이다.

나의 무심함에 반성을 하고 올해부터는 따뜻한 로봇이 되기로 마음 먹었다. 친구들에게는 그래도 겉차속따(겉은 차가워보이지만 속은 따뜻하다)라는 얘기를 몇 번 들어봐서 회사에서만이라도 나의 따뜻한 면모를 보여주고자 한다.

왜 따뜻한 개발자가 되고 싶은가.

회사에서 나는 개발자다. 따뜻한 개발자가 되고 싶다. 왜? 개발자는 컴퓨터와만 일하는 게 아니라 사람과 함께 일한다.

기획자, 디자이너, 프로젝트 오너와도 협업하면서 커뮤니케이션을 해야하고 때로는 프로덕트에 대한 자신의 주장을 펼칠 수도 있다.

이럴 때 동료들에게 냉정하고 프로페셔널한 모습만 보여준다면 일부 겁 많은 사람들은 나에게 어떤 의견을 제시하거나 자신이 모르는 것에 대해 질문하는 것을 꺼려할 수도 있다.

개발자의 독성 말투에 대해 다뤄진 글이 있을 정도로 개발자의 무시하는 말투, 거들먹거림 등은 실로 존재하고, 이는 팀웤을 저하시킬 수 있는 요소가 될 수 있다.

최근 같이 협업한 개발자 분 중에 '아 정말 이 사람 밝고 긍정적이다'라고 느껴진 분이 계셨다. 항상 웃는 얼굴에 '감사합니다' 또는 '죄송합니다'를 두번 씩 말씀하시는 분이었다.

몇번의 짧은 대화 밖에 나눠본 적이 없지만 질문이나 의견을 제시하기에도 거리낌 없이 편하고 또 그분이 부탁하면 빨리 대응해주려고 노력했다.

요청할 때 압박을 주는 경우 그로 인한 스트레스 때문에 집중이 잘 안되거나 할 때가 있는데, 내 심리 상태가 편안한 경우 좀 더 침착하게 대응할 수 있게 된다. 심리 상태는 집중력에 영향을 주고 집중력에 따라 내 업무 몰입도가 달라진다.

나도 누군가에게 긍정적인 에너지를 주고 일에 집중할 수 있게 도와주는 사람이 된다면 좋겠다고 생각했다. 그러니 말에 가시가 돋힌 차가운 개발자 말고 따뜻한 개발자가 되자.

따뜻한 개발자가 되기 위한 노력 3가지

3은 완전한 숫자다. 뭐든 3가지를 들면 완벽하고 안정적으로 보인다. 그래서 더도 말고 덜도 말고 따뜻한 개발자가 되기 위해 할 수 있는 것들 3가지만 말해보려 한다.

1. 인사하기

업무 요청을 할 때는 '안녕하세요 :)' 한 마디라도 덧붙이자. 대면이라면 웃으면서 인사하고, 슬랙이라면 웃는 이모티콘과 함께 보내자. 인사는 나에게 주의를 집중시키기 위한 용도로도 사용할 수 있다.

일에 집중하고 있는 사람에게 다짜고짜 업무 내용부터 말하면 '네?'라는 대답이 돌아오기 쉽다. 이럴 때는 '안녕하세요~'로 먼저 이목을 끈 뒤 요청 사항을 말해 보자.

그리고 상대가 내 요청을 들어주었을 때는 '감사합니다'라는 인사를 잊지 말자. 그리고 경험상 '감사합니다'를 두번 하면 정말 정말 감사한 것처럼 느껴진다. 홍진호처럼 두번 씩 말해보자. 감사합니다. 감사합니다.

2. 배려하기

개발자는 전문성을 띄고 있기 때문에 용어 자체도 공부하지 않으면 알기 어려운 것들이 많다. '라이브러리' 같은 경우도 일반인에게는 도서관이지만 개발자에게는 제 3자가 미리 만들어놓은 코드들의 모음이다. 따라서 내게 익숙한 용어라도 상대가 알아듣지 못할 것 같다면 다른 방식으로 풀어서 설명해야 한다.

예를 들어, 특정 라이브러리에 문제가 있어서 버그가 생긴 것이다라는 상황을 설명할 때는, '외부에서 가져다 쓰는 코드에 버그가 있어서 저희 쪽에서도 문제가 생긴 것 같습니다' 정도로 설명한다. 괜히 상대방이 모르는 용어를 써서 '그것도 몰라요?!'라고 거들먹거렸다가 최홍만같은 기획자한테 인생은 실전임을 배우지 말고.

그리고 같은 개발자들 사이에서도 어려운 버그가 있어 요청할 때는 문제의 배경과 에러 로그 등 상황 설명을 충분히 해야 한다. 개발자들의 지식인 같은 사이트인 '스택오버플로우'에서 질문을 잘하는 방법은 '나의 개발 환경에 대한 설명, 에러가 난 코드, 그리고 에러 로그, 내가 원하는 결과' 등을 충분히 설명하는 것이다. 이는 상대방이 내게 질문을 여러번 하게 하지 않기 위한 최소한의 배려이다.

3. 된다하기

전 직장에서 일할 때 동료 개발자가 싱글벙글한 얼굴로 책을 들고 왔다. 무슨 책인고 봤더니 '오늘도 개발자가 안된다고 했다'라는 책이었다. 책 이름이 웃겼다. 왜 웃겼을까? 공감되기 때문이다. 개발자가 기획자나 디자이너의 요청에 네거티브한 스탠스를 취하는 경우가 많다.

물론 '안된다'에도 충분한 이유가 있다. 하지만 왜 안되는지 충분히 설명하지 않으면 '무조건적인 안된다'가 된다. 따라서 안되는 데 분명한 이유가 있다면 2번의 배려하기를 적용해 상대방을 설득시킨다. 그 외에 안된다는 웬만하면 지양하자.

그저 내가 귀찮기 때문에, 이 일이 번거롭기 때문이라는 이유로는 안된다. 안되는 이유를 스스로 생각해보고 스스로 납득이 된다면 '안된다'고 말하고 스스로도 납득이 안되는 이유라면 '된다'라고 해보자. 고객지향적인 태도로 일하다 보면 된다라고 말하는 개발자가 되어있을 것이다.

이런 개발자가 많아지다보면 '요즘은 개발자가 된다고 한다'라는 책이 나오지 않을까. 하.하.하.

+ 책 '심플 소프트웨어'를 보고 무조건적인 '된다'도 안좋다는 걸 깨달았다. 안좋은 기획은 복잡한 코드를 만든다. 꼭 필요한 기능도 아니고 코드의 복잡성만 낳는 기획이라면 '아니요'라고 말할 수도 있어야 한다. 대신에 '아니요'라고 말할 때는 무례하게 말해서는 안되고 상대의 수고를 인정함과 동시에 안좋은 기획을 대신할 좋은 대책을 제시해야 한다.

이상 인간이 되고 싶은 로봇의 주저리주저리.

인간이 될 수 없다면 따뜻한 로봇이라도 되는 수 밖에... 후후