개발자에게 필요한 소프트 스킬이란 무엇인가? 센스있게 일하는 방법은 무엇인가?

---

목차

 

 

최근에 기술 문서 작성을 위해 문서작성과 관련된 도서가 없는지 찾다가 'Doc for Developers'라는 책을 구매하게 되었다. 아직 다 읽지는 못했는데, 첫 페이지에 '지식의 저주'라는 단어가 나온다. 

 

지식의 저주
(curse of knowledge)란 어떤 개인이 다른 사람들과 의사소통을 할 때 다른 사람도 이해할 수 있는 배경을 가지고 있다고 자신도 모르게 추측하여 발생하는 인식적 편견이다

 

그러다가 문득 최근에 개발자와 기획자 간에 의사소통, 혹은 개발 팀원들끼리의 의사소통에 문제가 있는 사례들을 생각해 보며 과연 개발자에게 필요한 소프트 스킬이란 무엇인가?라는 고민을 해보게 되었다.

 

 

 

🤔 소프트 스킬이란 무엇인가?

 

주니어 개발자나 개발자를 준비하는 사람들과 이야기를 나눌 때, 나는 항상 '소프트 스킬'의 중요성을 이야기한다. 개발자에게 중요한 것은 개발하는 실력뿐만 아니라 협업하는 능력, 대화하는 능력, 이해하는 능력 등 다양한 소프트 스킬이 필요하다. 물론! 소프트 스킬은 협업을 하는 집단에서 일을 하는 사람이라면 누구나 필요한 것이라고 생각한다. 

 

그런데, 많은 글들이나 인터뷰에서 소프트 스킬을 강조하지만, 정작 그게 무엇인지 구체적인 예나 사례, 어떻게 키우는지 등을 알려주지 않는다. 마치 수능 1등이 '교과서 위주로 공부했어요'라고 말하는 느낌이다. ㅋㅋ

 

 소프트 스킬이 중요하다고 말하지만,
정작 소프트 스킬이 무엇인지 알려주지 않는다. 😏

 

 

나는 소프트스킬이 흔히 말하는 센스와 비슷하다고 생각한다. 우리는 일상에서 '어 저사람 센스 있네~', '오~ 센스~!'라는 말을 가끔 하게 된다. 친구들과 커피를 마시러 가서 커피를 주문하고 자리에 앉았는데, 빨대를 가져오는 것을 까먹었다. 하지만 옆에 앉은 친구가 내 빨대까지 챙겨 왔을 때 우리는 '오 이 친구 센스 있네~'라고 생각할 수 있다. 

 

이 상황에서 센스는 '상대방이 겪을 문제나 상황등을 고려하고 더 나아가 그것을 해결해 주기 위해 노력하는 행위'라고 정의해 볼 수 있다. 자 그럼 이걸 일과 연결시켜 보자.

 

나는 회사생활을 하면서 많은 갈등 문제들을 만나왔다. 그게 팀 동료의 문제일 수도 있고, 저기 멀리 다른 팀의 문제를 블라인드나 소문으로 들은 것일 수도 있다. 혹은 친구한테 들은 친구 회사 이야기일 수도?

 

반면에 나는 이런 갈등을 잘 회피하고 있다. 나는 어느 회사에 가도 '회의를 잘하는 개발자', '기획자와 이야기를 잘하는 개발자'라는 이미지가 찍힌다. 자랑으로 들릴 수 있을 것 같은데, 그렇게 생각하면 님말이 맞음.

 

센스 있게, 혹은 일을 잘하는 사람, 으로 일하는 나만의 방법을 고민하면서 정리해 보니 2가지가 있는 것 같다.

 

 

 

👨‍💻 센스 있게 일하기 첫 번째, "지난번에 어디까지 했죠?" 히스토리 파악하기

 

첫 번째는 히스토리 파악이다. 우리는 개발을 하다가 특정 코드가 왜 이렇게 개발되었는지 파악할 때 '히스토리를 파악한다'라는 말을 많이 사용한다. git commit log나 회의록등을 찾아보며 코드가 왜 이렇게 작성되었는지 이유를 찾는 과정이다. 

 

나는 이런 히스토리 파악이 코드만 대상으로 할게 아니라 더 확장할 필요가 있다고 생각한다. 간단한 예로 점심, 저녁 메뉴에 대한 히스토리다.

 

최근 재택을 많이 하긴 하지만 출근도 가끔 하는데, 출근할 때 팀원들끼리 저녁을 먹으로 나간다. 하지만 우리는 1층에서 3~5분 정도 소요한다. 바로 메뉴를 고르기 위해서다. (K-직장인 국룰)

 

우리가 메뉴를 정하는 방법은 간단하다.

 

1.  누군가 먹고 싶은 게 있다? -> 2번으로 이동
2. 그 메뉴를 최근에 먹었나? -> Yes: 1번으로 이동, No: 3번으로 이동
3. 못 먹는 사람이 있나? -> Yes: 1번으로 이동, No: 메뉴 선택!

 

아마 대부분 비슷하지 않을까 싶다. 1번에서 멤버 전부 먹고 싶은 게 없다면 가장 먹은 지 오래된 것을 먹기도 한다. ㅋㅋ 

자 이제 기억을 더듬어보자. 메뉴를 고를 때 항상 이렇게 말하는 사람이 있다. 

 

"어제 뭐 먹었지?"

 

이렇게 말하는 사람은 메뉴에 대한 히스토리 관리를 안 하는 사람이거나 먹는 거에 관심이 없는 사람이다. 하지만 히스토리 관리를 하거나 먹는 것에 관심이 있는 사람은 바로 기억한다.

 

"어제 부대찌개~"

 

히스토리 관리는 이런 거다. 코드뿐만 아니라 사소한 것에도 히스토리 관리가 필요하다. 만약 아무도 메뉴에 대한 히스토리를 기억 못 한다면 최악의 경우 매일 같은 음식만 먹어야 한다.

 

그럼 이제 약간 업무의 영역으로 들어와 보자. 우리는 일주일에 적게는 1~2회, 많게는 수십 회의 회의를 진행한다. 회의는 일회성인 경우도 있고 반복되는 경우도 있다. 정기적인 회의가 있다면, 회의를 시작할 때 가장 먼저 무엇을 하는가? 바로 '지난 회의 때 어디까지 했지?'이다. 만약 회의록이 있다면 지난 회의록을 간단하게 리뷰하고 다시 회의를 진행하면 된다. 하지만 이렇게 리뷰하더라고 개개인마다 지난 회의에 대해 기억하는 정도가 다르다. 따라서 회의를 진행하면서 '지난번에 이렇게 정했잖아요~'라는 말을 많이 하게 된다.

 

만약 회의에 참여한 사람 모두가 지난 회의에 대한 기억을 다 하고 있다면, 즉 히스토리를 다 알고 있는 사람이라면 어떨까? 그럼 지난 회의에 대한 리뷰를 하지 않아도 모두가 똑같은 이해 수준으로 회의를 진행할 수 있다. 이게 포인트다. 

 

대기업에서 일을 할 때, 회의시간의 대부분 '상사에게 일을 설명'하는 시간이었다. 부장이나 팀장이 들어간 회의는 최소 30분은 기존 히스토리에 대해 설명하는 시간이었으며, 한 사람이 설명하면 다른 사람들은 상사가 이해하기까지 앉아서 기다리는 시간이다. 지금 생각해도 아주 비효율적이다. 

 

'아마존에서는 이렇게 일한다'라는 책에는 아마존의 회의방법이 나온다. 아마존에서는 회의를 소집한 사람이 회의를 소집한 이유나 아젠다 등을 1장으로 요약해서 회의시작하면 모든 사람한테 나눠준다. 회의에 참여한 사람들은 3~5분 정도 나눠준 종이를 읽으면 회의를 진행하게 된다. 이 회의방식은 모든 사람의 눈높이를 맞추는 효과가 있으며 히스토리 파악도 가능하게 한다. 대신 내용을 1장으로 요약을 잘해야 모든 사람들이 쉽게 이해하기 때문에 1장을 잘 요약하는 일이 가장 어렵다고 한다.

 

아마존의 기업문화를 모방할 수 있다면 가장 베스트겠지만, 문화를 도입하는 것은 개인이 노력해서 되는 게 아니기 때문에 힘들 수 있다. 우리가 할 수 있는 건, 최대한 회의에 대한 히스토리를 가지고 있는 것이다. 개발자인 내가 생각했을 때 일을 잘하는 기획자는 무엇인가 지난 일을 설명하지 않아도 알고 있다. 이상적인 회의에서는 대명사 가지고도 회의가 끝나기도 한다.

 

나: "그거 그렇게 하는 거 변한 거 없죠?"
기획자: "네, 그거 저번에 그렇게 안 하고 반대로 하려고 했던 거 캔슬돼서 그냥 원래대로 하시면 돼요~"

 

위 대화를 히스토리가 전혀 없는 사람이 들으면 뭐지? 하겠지만, 지난 회의에 히스토리를 다 알고 있다면 아주 명확한 대화가 된다. 이렇게 히스토리를 잘 알고 있다면 커뮤니케이션에 대한 코스트가 확 줄어든다.

 

 

히스토리를 파악하면 커뮤니케이션이 쉬워진다.

 

 

 

히스토리 파악에 대해 회의에 대해서만 언급했지만, 개인에 대해 대상이 될 수도 있다. 우리 주변에는 꼭 같은 얘기를 반복하는 사람이 한 두 명쯤은 있다. 

 

'나 저번에 핸드폰 잃어버려서 바꿨잖아~!'
'응 벌써 3번째 들었어'
'아? 내가 얘기했나?'

 

반복적인 얘기를 하는 사람은, 내가 누구에게 무슨 얘기를 했는지 히스토리를 기억하지 않는 사람이다. 이런 사람들은 내가 누구와 어디까지 얘기했는지 기억하는 것에 관심이 없기 때문에 대화를 이어나가기 힘들다. 항상 이전 이야기를 다시 해주고 본론으로 넘어가야 하기 때문에 

커뮤니케이션 코스트가 높아진다. 반면 이전 이야기를 잘 기억하는 사람들은 얘기하기가 쉽다. 이전 설명 없이 새로운 얘기를 바로 하면 되기 때문이다. 혹시라도 '대화하기 편한 상대'라는 이미지를 갖고 싶다면, 주변인들과 나눈 대화의 히스토리를 잘 기억해 보자.

 

 

 

👨‍💻 센스 있게 일하기 두 번째, "왜 저럴까?" 고민하기

 

두 번째는 상대방이 왜 저러는지 고민하는 것이다. 표현이 좀 이상하긴 한대, 간단히 말하면 상대방에 입장에서 고민해 보라는 거다. 주변 기획자분들이 'XXX 개발자랑은 일하기가 너무 불편해'라고 했을 때 10중에 8이 대부분 상대방 입장을 고려 안 하는 개발자다. 

 

나는 기획자, 아니 대부분의 사람이 무언가 말을 하면, '왜 저렇게 말하지?'라는 고민을 먼저 하게 된다. 글 처음에 언급한 지식의 저주에 현혹되지 않기 위해서다. 사람들은 대부분 나와 같은 생각을 다른 사람도 하고 있다고 생각한다. 따라서 내가 생각하는 것과 다르게 말하면 그 사람이 틀리다고 생각하고 멍청하다고 생각하게 된다. 하지만 대부분의 경우에는, 상대방과 내가 아는 상황이 다른 경우라는 것을 알 수 있다.

 

최근에 서비스 사용자가 늘어나서 앱이 느려지는 이슈가 생겼다. 이슈를 해결하기 위해 개발자와 기획자가 모여서 회의를 진행했다. 이슈를 해결하기 위해서는 서버를 늘리던지, 사용자에게 보이는 화면에 데이터를 줄여서 앱 성능을 향상하는 방법이 있었다.

 

기획자 A: "기존 화면을 건드리면 UX가 바뀌니 서버를 늘리는 방향으로 가시죠?"
개발자 B: "굳이 서버를 늘려야 하나요? 코드로 바꿀 수 있을 것 같은데?" 
기획자 A: "아까 말했다시피 UX가 바뀌면 사용자가 불편할 수도 있으니까요"
개발자 B: "자주 사용하는 화면도 아니고 별 이슈 없을 것 같은데요?"
...

 

 

위 대화는 끝이 없을지도 모른다. 우리는 이렇게 정답이 없는 회의를 많이 경험해 보았을 것이다. 그럼 여기서 "왜 저럴까?"라는 것을 넣으면 어떻게 될까?

 

기획자 A: "기존 화면을 건드리면 UX가 바뀌니 서버를 늘리는 방향으로 가시죠?"
개발자 B: "굳이 서버를 늘려야 하나요? 코드로 바꿀 수 있을 것 같은데?" 
기획자 A: "혹시 서버를 늘리면 다른 이슈가 발생하는 걸까요?"
개발자 B: "네 저희가 사용하는 서버는 사용 비용이 높은 서버로 늘리게 되면 월 서버 비용이 1.5배 오를 수 있습니다."
기획자 A: "그렇군요. 그럼 사용자가 어느 정도 불편할지 예상해 보고 양자택일을 해야겠네요."
개발자 B: "해당 화면에 진입하는 유저는 전체 5% 정도로 집계됩니다. 의사결정할 때 참고하세요"
...

 

너무 극적으로 화목해지긴 했지만, 기획자 A가 먼저 개발자 B에 대답을 듣고 고민을 한 흔적이 보인다. "서버를 늘리지 않기를 바라는 것 같은데 왜 그럴까? 서버를 늘리면 다른 문제가 생기는 건가?"라는 고민을 해봄으로써 왜 개발자가 서버를 늘리는 것보다 화면을 고치는 게 더 좋겠다고 말한 지 이해할 수 있다. 이처럼 상대방이 왜 그렇게 말했는지 조금만 고민해 본다면, 일을 좀 더 쉽게 진행할 수 있게 된다.

 

 

내가 이런 상황을 가장 많이 느끼는 건 클라이언트 개발자와 협업을 하는 경우다. 내 업무가 백엔드다 보니 클라이언트 개발자와 협업할 때가 많은데, 대부분의 개발자들은 자기의 영역에 대한 지식만 가지고 있는 경우가 많다.

 

클라이언트 개발자: 응답에서 is_used라는 변수가 안 내려오는데 확인해 주실 수 있나요?
백엔드 개발자: 아 그거 안 내려갈 수도 있어요.
클라이언트 개발자: 필수 값인데 안 내려온다고요?
백엔드 개발자: 넵 서버가 그렇게 만들어져 있어요.
클라이언트 개발자: 넣어주실 수 있나요?
백엔드 개발자: 왜 넣어야 하죠??

 

적절한 예를 생각하다가 이런 대화를 생각했는데, 적절하지 않을 수 있다 ㅋㅋ 일단 두 개발자는 서로의 개발 영역이 어떻게 개발되었는지 모른다. 클라이언트에서 특정 라이브러리가 항상 json 필수값을 받아야 하는 것이라면 값을 추가해 주는 게 맞을 거다. 하지만 백엔드 개발자 입장에서 값이 없으면 생략하는 라이브러리를 사용했고, 예전에도 그렇게 잘 사용하고 있었기 때문에 이해가 안 가는 상황이다. 백엔드 개발자 입장에서 안 내려가는 게 당연한데, 그걸 묻는 클라이언트개발자가 이상했을 것이다. 하. 지. 만, '왜 저럴까?'생각을 한번 해본다면 대화가 조금 달라질 수도 있다.

 

클라이언트 개발자: 응답에서 is_used라는 변수가 안 내려오는데 확인해 주실 수 있나요?
백엔드 개발자: 어, 그거 안 내려갈 수도 있는데 항상 필요한 건가요?
클라이언트 개발자: 네, 이거 공통모듈에서 처리하는데 이번에 업데이트돼서 값이 없으면 에러가 나더라고요
백엔드 개발자: 아 이번에 변경되었군요. 기존에는 없으면 안 내려주는 방식이었는데, 바꿀 수 있는지 확인해 볼게요
...

 

역시나 극적으로 화목해졌다. 이렇게 상대방이 왜 그렇게 얘기하는지, 혹은 왜 그렇게 얘기할 수밖에 없는지 이해하려고 한다면, 커뮤니케이션 코스트는 줄어들고 더 빠르게 이슈를 확인할 수 있을뿐더러 일을 잘하는 인상까지 줄 수 있다.

 

*(위 예제가 적절하지 않은 이유는 Json 스펙상 boolean값이 false인 경우 필드가 없는 게 룰이다. 즉 is_used가 응답에 없다면 false로 인식해야 하는 게 정답. 이건 사용하는 라이브러리의 옵션으로 false여도 내려줄 수 있게 바꿀 수는 있을 거다)

 

 

 

 

😄 마무리

 

간단하게 쓰려고 했는데 예시까지 들면서 본격적으로 쓰게 되었다. 최근 주변에서 커뮤니케이션에 어려움을 겪는 사람들을 많이 보기도 하고, 내가 어려움을 겪기도 한다. 그럴 때마다 나는 최대한 상대방을 이해하려고 노력하고, 내가 문제일 것이다라는 생각도 적극적으로 하고 있다. 이건 누구의 잘못인지 찾는 문제가 아니라 어떻게 하면 효율적으로 이 상황을 개선할 수 있을까의 문제이기 때문이다. 

 

이 글을 읽는다고 당장 소프트 스킬이 늘거나 센스 있는 직장인이 되지는 않겠지만, 앞으로 여러분들이 일을 하는 데 있어 도움이 됐으면 하는 바람이다.