Skip to content

Chapter 6 Soft Skills #1663

@jongfeel

Description

@jongfeel

Chapter 6 소프트 스킬

소프트 스킬이 필요한 이유

오늘날 소프트웨어는 팀 단위로 작성됩니다.
팀은 사람들로 이루어지며, 사람들은 의견과 감정, 두려움의 영향을 받습니다.
팀으로 일하는 것은 매우 보람 있을 수 있습니다.
하지만 한 번의 잘못된 발걸음이 하루를 망치는 지뢰밭이 될 수도 있습니다.

소프트 스킬과 단순함

신뢰와 명확한 소통이 없으면 표현하기 쉬워야 할 것들이 훨씬 더 복잡해지고, 오해가 빈번해집니다.
시스템이나 설계를 올바르게 이해했다고 확신할 수 없다면, 이를 단순화하기는 어렵습니다.

PRACTICE 16 의견 대립은 제로섬 게임이 아닙니다

아이디어 38 의견 대립을 제로섬 게임으로 생각하면 누구도 이길 수 없습니다.

한 쪽 주장에도, 다른 쪽 주장에도 각각 진실의 요소가 있다고 보고, 그 둘을 종합해 더 새롭고 더 큰 무언가를 만들어 내는 데서 가치를 찾습니다.
이 접근이 중요한 또 다른 이유는, 대립으로 치달을 뻔한 상황을 흥미롭고 생산적인 대화로 바꾸어 준다는 점입니다.

변증법적 사고 훈련

다음에 누군가와 의견이 다를 때는 그 사람을 곧바로 ‘바보’로 단정하지 마세요.
그들이 틀렸다는 것을 보여주려고 하기보다는 대신 내가 틀렸을지도 모른다고 생각해 보세요.
왜 그런 입장을 갖게 됐는지 고민해 보세요.
상대를 함정에 빠뜨리려는 의도가 아니라, 그 배경에서 통찰을 얻을 수 있기 때문입니다.
여러분이 할 일은 스스로 옳다는 것을 증명하거나 상대방이 틀렸음을 입증하는 것이 아닙니다.
각 입장에서 타당한 부분을 찾아내고, 이를 바탕으로 원래보다 더 나은 새로운 해법으로 나아가는 거죠.

실전에서는 좀 까다롭습니다.
자칫 건방지거나 교활하게 보일 수 있거든요.
예를 들어 이렇게 말해 보세요.
‘말씀 이해합니다. 다만 제 경험상으론 좀 다른 것 같아서 xyz에 대해 더 자세히 알고 싶네요.
어떤 근거로 그렇게 생각하시게 되었는지 말씀해 주실 수 있습니까?’

반박하려 들지 마세요.
이기려는 게 아니니까요.
상대의 관점에서 바라보는 연습입니다.
덤으로 새로운 걸 배우게 되고요.

아이디어 39 절대적인 태도는 단순함의 적입니다.

절대적인 원칙으로 움직이는 팀은 절대 효율적일 수 없습니다.
세상이 바뀔 때 스스로 바뀌기가 훨씬 어려워질 겁니다.
게다가 다양한 관점을 종합해서 나오는 더 좋은 아이디어도 놓치게 되고요.

PRACTICE 17 공감 능력 기르기

공감이란 다른 사람이 느끼는 바를 이해하고 그 점을 고려해 상대를 대하는 능력입니다.

공감은 사회적 윤활제 역할을 해 서로가 만족스러운 결정을 내리게 해 줍니다.
서로 공감하면 팀이 이 작업을 더 효율적이고 효과적으로 수행할수록 단순함이 증가하고 업무는 더 민첩해집니다.

다른 사람에 대한 공감이 있으면 많은 시행착오 과정을 줄일 수 있습니다.
상대방이 여러분을 신뢰한다는 것을 알기 때문에 조금씩 나아갈 수 있습니다.
실수해도 비난받기보다 좌절감과 후회를 이해받을 거라는 걸 아니까요.
정서적 안전망이 있으면 더 자유롭게 실험할 수 있습니다.

공감은 본래 여러 사람 간 관계에 관한 거지만, 어떻게 표현하고 활용할지는 각자 스스로 찾아야 합니다.
그래서 핵심은 팀이 구성원들의 상호작용을 수용하고 증폭시키는 겁니다.

사람들에게 시간을 내어 주기

상대가 말을 풀어낼 수 있도록 질문 몇 가지를 준비해 두는 겁니다.
사람들은 이것을 ‘스몰 톡small talk’이라고 부르는데 집단을 이어 붙이는 접착제에 가깝습니다.
결국 필요한 건, 상대의 말을 기울여 들어 줄 시간을 내는 것뿐입니다.

아이디어 40 스몰 톡은 말하기가 아니라 경청이 중요합니다.

누군가와 편하게 대화할 수 있다는 것은 그 사람과 그 사람의 삶에 대해 기억할 만큼 관심을 기울인다는 뜻입니다.

다른 사람들에게 나는 어떻게 보일까?

아이디어 41 사람들이 여러분의 감정을 안다고 가정하지 말고 직접 알려 주세요.

이렇게 해 보세요

기분이 나쁘지 않은 사람도 누군가 계속 기분이 상했냐고 물어보면 곧 나빠집니다.
대신 상대방이 기분을 좋아지게 만드는 질문 방식이 있답니다.

‘안녕하세요, Jan! 오늘은 좀 어때요?’
‘리포트 포매터의 버그를 찾느라 오전이 다 갔네요.’
‘저런! 정말 답답했겠네요.’
‘사실 꽤 즐거웠어요.’
‘정말요? 왜 그렇죠?’
    
게임처럼 해 보세요.
주기적으로 상대를 관찰해 기분을 평가해 보고, 직접 묻지 않고도 물어볼 방법을 찾아보세요.

영향력 확인하기

개발자인 우리는 회사 내 거의 모든 사람보다 전반적인 비즈니스에 대해 더 많이 알고 있습니다.

이로 인해 다른 사람과의 소통에서 특권을 가진 쪽에 서는 경우가 많습니다.
우리는 다른 사람 위에 군림하거나 우리만 아는 지식을 휘둘러 스스로를 특별하고 강력하다고 느낄 수 있습니다.
우위를 점할 수 있죠.

상급자에게도 통합니다

관리자들은 암묵적으로 자신이 책임지는 팀원들이 제멋대로 행동하지 않도록 통제해야 한다고 느낄 수 있습니다.
따라서 그들과 대화할 때 공감하는 법을 익히세요.
상대에게 위협이라고 여겨진다는 인상을 없애고 모든 대화가 끝날 때 쯤상대가 스스로에 대해 더 기분좋게 느끼도록 만드세요.

PRACTICE 18 사물에도 공감하기

아이디어 42 환경과 싸우지 말고 이해하세요.

사람에게 공감한다는 건 그 사람의 관점에서 세상을 경험하고, 어떻게 작동하는지, 무엇을 할 수 있고 어디까지가 한계인지 이해한다는 뜻입니다.
사물은 사람처럼 내면의 시각을 가진 존재는 아니지만, 그 역시 나름의 작동 방식이 있고, 할 수 있는 일과 한계가 있습니다.

이걸 알고 거기에 맞게 행동하는 것도 공감의 한 형태이고, 사회적 공감처럼 익혀서 쓰기 시작하면 세상이 훨씬 쉽고 단순해집니다.

코드에 귀 기울이기

가장 좋은 출발점은 디버깅입니다.

디버깅할 때 가끔 어려움을 겪는다면 관점을 바꿔 보세요.
내 실수로 비정상적으로 동작하도록 강요받는 불쌍한 코드를 떠올려 보세요.

디버깅을 한 단계 넘어서서, 무의식이 작업에 대해 경고 신호를 보내고 있는지 찾아 보세요.
증상은 종종 미묘하기도 하지만 다음과 같습니다.

  • 평소보다 더 자주 자리에서 일어나 음료를 마시러 갑니다.
  • 계속 이름을 바꾸고 있습니다.
  • 타이핑이 힘든 작업이라고 느껴집니다.
  • 그만하고 다른 일을 하고 싶어합니다.
  • 그 외의 회피 행동을 합니다.

두려움의 선물

잠재의식의 외침에 귀를 기울이세요

다음 번에 기분이 묘하거나 뭔가가 조금 이상하게 느껴질 때, 가볍게 넘기지 않도록 하세요.
대신 그 감정을 살펴보세요.
직전에 여러분은 무엇을 하고 있었습니까? 어떻게 느껴지나요?

도움이 되는 요령이 있습니다.
사람들이 샤워를 하거나 걸을 때 최고의 아이디어가 떠오른다고 말하는 걸 아시나요?
의식적인 뇌가 휴식 상태에 있을 때입니다.
이때 잠재의식이 뚫고 나올 공간이 생깁니다.

그래서 저는 뭔가 이상함을 느낄 때, 그 원인을 즉시 파악할 수 없으면 잠시 쉬어갑니다.
걷거나, 낙서를 시작하거나, 정리를 합니다.
종종 사건을 촉발한 것이 무엇이었는지 제 머릿속에 갑자기 떠오릅니다.

여러분에게도 효과적일 가능성이 높습니다.

PRACTICE 19 이야기 엮기

설전 대신 소설을

개발자의 역할은 정보를 전달하고 효과적으로 소통하는 일입니다.
이를 위해서는 현재 처한 상황을 충분히 고려해야 합니다.

  • 어떤 정보가 맥락에서 중요한지 파악하는 것이 중요합니다.
  • 이 내용을 효과적으로 전달하기 위해 어떤 용어를 사용하는 것이 적절할까요?
  • 해당 용어를 활용해 정보를 설명할 수 있는 비유나 은유가 있을까요?
  • 비유를 사용할 때, 비유로 인해 일부 정보가 누락되거나 잘못 전달된다면 이해에 영향을 미치나요?

아이디어 43 비유는 유용한 허구입니다. 비유는 복잡한 개념을 쉽게 설명하거나 전달할 때 활용되지만, 실제와 완전히 일치하지 않는다는 점을 인식해야 합니다.

100% 정확한 기술적인 답변은, 상대방이 모든 세부 사항을 여러분만큼 잘 알고 있지 않은 이상 오히려 혼란을 일으킬 수 있습니다.
대부분 정확한 비유나 은유는 종종 약간의 허구를 수반한다는 트레이드오프가 있습니다.
즉, 설명의 혼란을 줄이기 위해 현실과 다소 차이가 나는 부분을 감수해야 할 때가 있습니다.

도메인 선택하기

이런 스토리텔링에서 어려운 건 도메인, 즉 이야기의 배경이 되는 세계를 선택하는 일입니다.
메시지를 충분히 전달할 수 있을 만큼 풍부해야 하지만, 동시에 양쪽 모두가 쉽게 이해할 수 있어야 하죠.

그래서 이 기법은 여러분과 상대방이 공통된 배경 지식을 갖고 있을 때에만 사용하는 것이 바람직합니다.

다음과 같은 도메인은 피하세요.

  • 한 사람만이 깊이 있는 전문 지식을 보유한 도메인
  • 정치, 종교, 사회적 이슈 등
  • 구축에 오랜 시간이 걸리는 환경
  • 최근 이슈가 되는 인물이나 소셜 미디어에서 화제가 되고 있는 사건
NOTE 낯선 개념을 설명하기 위해 이야기를 만들어내는 것은, 실제로는 상대방의 관점에서 상황을 바라보고 있기 때문입니다.
누군가가 단순한 질문에 대해 이해할 수 없는 전문 용어로 대답한다면, 상대방은 위축되거나 무지하다고 느끼고, 답답함이나 심지어 분노까지 느낄 수 있습니다.

그래서 공감을 바탕으로 우리의 세계를 상대방이 이해할 수 있는 방식으로 풀어내야 합니다.

비유의 본질

좋은 비유는 여기서 더 나아 갑니다.
설명하는 시스템이 실제로 어떻게 동작하는지, 구성 요소들이 실제로 어떻게 상호작용해 결과를 만들어내는지 보여 줍니다.
비유가 효과적이려면, 비유의 각 구성 요소도 서로 상호작용해야 하며, 이런 상호작용의 결과가 현실과 연결돼야 합니다.

인덱스 예시에 적용하면 다음과 같습니다.

  • 색인은 책에서 특정 정보를 매우 빠르게 찾도록 합니다.
    • 데이터베이스 인덱스를 사용하면 특정 데이터의 위치를 매우 빠르게 조회할 수 있습니다.
  • 색인은 책 내에서 공간을 차지합니다.
    • 데이터베이스 인덱스도 저장 공간을 차지합니다.
  • 인덱스가 많을수록 원하는 데이터를 조회할 수 있는 방법도 다양해집니다.
    • 데이터베이스 인덱스가 많을수록 데이터를 빠르게 찾을 수 있는 방법도 다양해집니다.
  • 인덱스가 많아질수록 저장 공간도 더 필요합니다.
    • 데이터베이스 인덱스를 많이 생성할수록 더 많은 저장 공간이 필요합니다.

이 매핑이 완벽한가요? 전혀 그렇지 않습니다.
가장 큰 오해 중 하나는, 책의 색인이 차지하는 공간이 데이터베이스 인덱스에 비해 상당히 적다는 점입니다.
또한 인덱스가 제공할 수 있는 데이터베이스 레벨의 다양한 기능도 모두 생략했습니다.
하지만 이런 디테일은 여기서 중요하지 않습니다.
이 비유만으로도 우리가 전달하려는 핵심을 충분히 설명할 수 있기 때문입니다.

비유 만들기

시스템을 공항에 비유해 볼게요.
승객이 공항에 와서 체크인하는 과정은 사용자와 동일합니다. 셀프 체크인 기계를 찾아 수속을 하죠.
이런 기계들이 들어오는 요청을 처리하는 서버예요.
그 후에는 보안 검사를 통과하려고 줄을 서야 하고요.
이건 한 번에 하나씩만 할 수 있습니다.
데이터베이스를 업데이트하려고 대기 중인 요청과 같습니다.

모두가 비행기 타는 데 시간이 오래 걸린다고 불평합니다.
승객이 동시에 더 도착해도 대응하려고 체크인 기계를 더 추가하면 된다고 생각할 수 있습니다.
이 방법으로도 문제는 안 풀려요.
여전히 보안 검색대에서 대기하니까요.

그래서, 보안 검색대 병목에 집중해야 합니다.
어떻게 하면 더 빠르게 통과시킬까요?
검색대를 더 설치해 운영할까요?
한 사람을 검색하는 보안 절차를 줄여 각 승객을 더 빨리 처리할까요?

이런 이유로 저희 팀은 데이터베이스 병목을 살펴보는 데 시간을 쓰는 게 더 효과적이라고 봅니다.

이 비유는 꽤 적절하다고 생각합니다.
현실 세계에서의 개념들(애플리케이션, 요청 처리, 데이터베이스 경합)이 비유에서의 요소들인 기차역, 표 발급기, 보안 검색과 잘 대응됩니다.
현실 세계에서 일어나는 상호작용은 이야기 속의 상호작용과 대응되도록 모델링되며, 이러한 유사성을 통해 도출할 수 있는 결론은 현실 세계에도 동일하게 적용할 수 있습니다.

아이디어 44 스토리에서 등장하는 개념들은 실제 세계의 대응 개념처럼 상호작용해야 합니다.

성과에 대한 불안감

비유는 연습할 수 있습니다.
연습을 거듭하면 즉각적으로 대응하는 능력도 늘어납니다.
여기 세 가지 아이디어가 있습니다.

오프라인 스토리텔링 연습

이메일은 즉답 부담 없이 이 기술을 연습하기 딱 좋습니다.

질문 메일이 오면 바로 답하지 말고 잠시 생각해 보세요.
발신자가 진짜 필요로 하는 게 뭔지, 그걸 어떻게 효과적으로 설명할 수 있을지 스스로 물어보는 거죠.
체크리스트를 만들어 활용하는 것도 좋습니다.
소셜 스토리텔링 연습

이모나 고모가 찾아와서 (다시) 내가 무슨 일을 하는지 묻습니다.
또는 삼촌이 ‘SSID가 도대체 뭐냐?’고 질문합니다.

이만큼 우호적인 청중도 없습니다.
동료들에게 이렇게 말하고 연습할 수도 있습니다.
‘지금 새로운 설명 방식을 찾아보고 있는데, 제 실험 대상이 되어 주실 수 있을까요?’ 그리고 최선을 다해 설명해 보세요.
진행하면서 상대방이 이해하고 있는지 계속 확인하고요.
즉흥 연기 수업을 들어보세요

제일 잘 따라하지 못한 사람들도 대화 중에 잠시 생각할 시간을 벌면서 흐름을 이어가기 위한 유용한 대화 기법(이를테면, ‘예, 그리고…’)을 배웠습니다.

스스로도 이야기를 들려주세요

제가 이야기의 영역에서 사고하기 시작하면, 그 안에 등장하는 가상의 객체들이 어떻게 상호작용해 나름의 (가상의) 결과를 만들어 내는지 떠올릴 수 있습니다.
때로는 이러한 동작을 제 문제 영역에 다시 연결해 해석할 수 있습니다.

스스로에게 질문해 보세요

기술에 익숙하지 않은 친구에게 아래 기술 질문들을 설명할 때 쓸 만한 비유를 몇 가지 생각해 보세요.

1. 스택 또는 LIFOLast-In, First-Out는 어떻게 작동하나요?
2. FIFOFirst-In, First-Out 큐는 어떻게 작동하나요?
3. SSID란 무엇인가요?
4. 컴퓨터의 메모리와 스토리지는 어떻게 다를까요?

Metadata

Metadata

Assignees

Labels

2026Simplicity미니멀리즘 프로그래머 - AI 시대, 복잡함을 줄이고 가치를 올리는 개발 원칙

Projects

Status

Done

Relationships

None yet

Development

No branches or pull requests

Issue actions