이런 개발자가 되자. 문제 해결형 개발자

문제 해결형 개발자가 되자.

 

실제로 지속 가능한 변화를 만들기 위해서는 추상적인 말보다는 구체적이고 행동 가능한 습관이 필요하다. 

문제 해결형 개발자가 될 수 있는 좋은 습관 4가지를 소개한다. 

1. 해결하려는 문제와 맥락에 대해서 먼저 묻는다.

요구사항에 대해서 들으면, 된다 안된다 말을 하기 전에 그것이 해결하려는 문제와 맥락에 대해서 먼저 묻는다.

 

스펙 구현형 개발자가 가장 많이 하는 실수는 문제에 대해서 생각해보지 않고 곧장 해결책으로 집중하는 건데...

엔지니어로서는 항상 솔루션에 초점이 가는 본능이 있는 것 같다.

그렇기 때문에 의도적으로 문제에 초점을 맞춰야 된다..

실전에서 이걸 해보는 방법은 간단하다. 그냥 한 번 더 물어보면 된다.

내가 당장 뭔가를 대답하고 싶은 욕구를 잠시 내려놓고 무조건 한 번 더 물어보자.

 

'어? 이건 어떤 문제를 해결하는 것일까? 어떤 의도와 맥락을 가진 것일까?'
재질문하는 것만으로도 공동의 목표와 문제로 초점을 좁힐 수가 있다.

 

2. 상대방의 말을 듣고 내가 이해한 바를 공유한다.

분명히 서로 같은 단어를 써서 말을 하는데, '어? 저 사람 잘못 이해한 것 같은데? 쎄한데?' 이런 느낌 드실 때가 있다.

 

만약에 상세 화면에 대한 얘기를 하고 있고, 상대방도 상세화면에 대한 얘기를 하고 있는데

나는 상세화면이 시간대에 따른 내역을 보여주는 거라고 생각했는데 상대방은 추가적인 액션을 하는 그런 상세화면이라고 생각할 수도 있다. 왜냐하면 사람들은 같은 단어를 보고도 서로 다르게 이해할 수 있기 때문이다.

 

커뮤니케이션을 잘 하는 사람들은 내가 이 단어를 썼다고 해서 당연히 저 사람도 이렇게 이해했겠지라는 가정을 잘 하지 않는다. 이걸 싱크하는 가장 좋은 방법이 상대방의 말을 듣고 내가 이해한 바를 한번 요약해서 되물어 보는 것이다.

 

'제가 이해한 바로는 이러한 이러한 거라고 이해를 했는데, 이 내용이 맞을까요?'라고 하면서 다시 물어보곤 한다.

이게 내가 이해한 게 맞으면 상대방이 나에 대한 신뢰도가 올라가고,

만약에 내가 이해한 게 좀 틀렸으면 앞으로의 비효율을 막을 수 있으니까 굉장히 좋은 거다.

3. 안 되는 이유 대신, 상대방 관점에서 대안을 제시한다.

개발자로 일하다 보면 종종 '이거 왜 안 돼요?' 같은 질문을 받게 된다.

이때 대부분은 기술적인 설명으로 대답한다.

예를 들어, '기술적으로 어려워서요', '이 DB가 분리되어 있어서...' 이런 식으로 말이다.

 

하지만 사실은, 다른 팀원들, 특히 다른 직군 사람들이 진짜 알고 싶어하는 건 그게 기술적으로 왜 어려운지가 아니다.

그들은 이 문제를 해결할 다른 방법이나, 그들이 해야 할 행동이 무엇인지가 궁금한 거다.

 

그래서 개발자로서, 어떤 이유를 설명하려고 할 때 복잡하게 돌아가지 말고, 바로 핵심을 짚어서

'이 문제가 어떤 제약 조건 때문에 어렵다'고 말하고, '그럼 이 제약 조건을 좀 더 줄일 수 있는 다른 방법은 뭐가 있을까요?', '이걸 어떻게 우회할 수 있을까요?' 이렇게 대화를 이어가 보자. 이렇게 하면, 대화가 훨씬 쉽게 풀릴 것이다.

중요한 건, '어렵다'는 걸 납득시키려는 게 아니라, 대안에 집중하는 것이다. 

왜냐하면, 우리가 해야 할 일은 그냥 스펙을 구현하는 게 아니라, 문제를 해결하는 것이기 떄문이다.

 

4. 문제를 해결할 또 다른 방법은 없을지 고민해본다.

개발을 하다 보면 항상 딜레마에 빠지게 된다.

예를 들어, 로그인하는 동안 외부 API를 써서 인증을 구현하는데, 응답이 너무 늦게 온다고 가정해보자. 

사용자 입장에서는 인증하는데 시간이 오래 걸리니 이탈하게 될 것이다. 인증 API를 다른 걸로 바꾸거나 직접 구현하면 몇 개월의 개발이 들어가는 상황이다. 그래서 '이거 인증 빠르게 할 수 없어요?'라는 질문에 '안 돼요'라고 답하고 싶어진다.

 

하지만 이 딜레마를 해결하는 실제 방법이 있다. 순서를 바꿔서, 인증 응답이 오기 전에 다음 화면으로 넘어가고,

그 다음에 인증 응답이 와서 결과를 보고, 필요한 게 있으면 추가적인 화면을 진행하거나 그냥 통과시켜주는 거다.

 

이렇게 되면 대부분의 사람들은 로딩을 기다리지 않고 로그인을 끝낼 수 있다.

 

충분히 고민을 해보면 '한다/안 한다'라는 것 말고도 세상엔 많은 해결책이 있다는 것이다.

개발자가 문제 해결을 하는 사람이라고 생각한다면, 단순히 '한다/안 한다'의 사고에 갇히지 말아야 한다.

 

예를 들어, '버튼을 추가하면 유저는 편하지만 개발자의 리소스가 많이 든다'라고 할 때, 섣불리 결론을 내지 않고 '유저가 편하면서도 개발자의 공수가 적게 드는 방법은 없을까?' 한 번 더 고민해보는 것이다. 이런 마인드를 가진 사람들은 새로운 요청 사항이 들어왔을 때 '아 그건 안 돼요'가 아니라 '혹시 다른 방법은 없을까요?' '이런 건 어떨까요?'라는 말이 나오게 된다. 중요한 것은 빨리 결론을 내지 않고, '좀 다른 방법이 없을까?'라고 생각을 해보는 것이다.

 

 

마무리하면서...

문제 해결형 개발자라는 것은 그렇게 거창한 것이 아니다.
지금 개발을 하고 계신 분들이 있다면, 제가 방금 말씀드린 그 순간들이 분명히 있을 것이다.

그때 본능적으로 나오는 행동 대신에, 오늘 말씀드린 습관을 한 번이라도 시도해본다면,

하루하루가 작지만 쌓여서 어느새 다른 팀원들이 너무나 같이 일하고 싶어하는 개발자가 되어있을 거라고 확신한다.