문제 해결형 개발자가 되려면

지난 글에서 제가 회사 사람들에게 '훌륭한 개발자는 어떤 개발자인가요?'라고 물었는데요. 답을 종합해보니 팀원들이 같이 일하고 싶어하는 개발자와 그렇지 않은 개발자의 차이가 뚜렷하게 드러났죠.

스펙 구현형 개발자는 솔루션에 집중하기 때문에 '아 그건 안 돼요'라는 말을 많이 하게 되지만, 문제 해결형 개발자는 단순히 '된다, 안 된다'가 아니라 문제를 해결하는 것에 집중합니다. 그래서 '이건 어떤 문제를 풀기 위한 건가요?'라는 질문을 먼저 합니다.

문제 해결하는 개발자가 되어야 한다고 말하기는 쉽지만, 실제로 그렇게 변화하기는 어렵습니다. 커뮤니케이션은 마치 지금 여러분이 스마트폰을 보고 있는 자세처럼 몸에 배어 있는 것이고, 쉽게 고쳐지지 않습니다.

실제로 지속 가능한 변화를 만들기 위해서는 추상적인 말보다는 구체적이고 행동 가능한 습관이 필요합니다. 문제 해결형 개발자가 될 수 있는 좋은 습관 4가지를 고민해보았습니다.

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

첫번째 습관입니다.

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

스펙 구현형 개발자가 가장 많이 하는 실수는 문제에 대해서 생각해보지 않고 곧장 해결책으로 집중하는 건데요. 엔지니어로서는 항상 솔루션에 초점이 가는 본능이 있는 것 같아요. 그렇기 때문에 의도적으로 문제에 초점을 맞춰야 되는데요.

실전에서 이걸 해보는 방법은 간단합니다. 그냥 한 번 더 물어보면 돼요. 내가 당장 뭔가를 대답하고 싶은 욕구를 잠시 내려놓고요. 무조건 한 번 더 물어봅니다.

'어? 이건 어떤 문제를 해결하는 것일까요? 어떤 의도와 맥락을 가진 것일까요?'

재질문하는 것만으로도 공동의 목표와 문제로 초점을 좁힐 수가 있습니다.

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

여러분 그런 경험 하신 적 있을 거예요.

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

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

커뮤니케이션을 잘 하는 사람들은 내가 이 단어를 썼다고 해서 당연히 저 사람도 이렇게 이해했겠지라는 가정을 잘 하지 않아요.

이걸 싱크하는 가장 좋은 방법이 상대방의 말을 듣고 내가 이해한 바를 한번 요약해서 되물어 보는 거예요.

저는 이런 말투를 많이 써요. '제가 이해한 바로는 이러한 이러한 거라고 이해를 했는데, 이 내용이 맞을까요?'라고 하면서 다시 물어보곤 해요. 이게 내가 이해한 게 맞으면 상대방이 나에 대한 신뢰도가 올라가고, 만약에 내가 이해한 게 좀 틀렸으면 앞으로의 비효율을 막을 수 있으니까 굉장히 좋은 거고요.

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

개발자로 일하다 보면 종종 '이거 왜 안 돼요?' 같은 질문을 받게 되잖아요? 이때 대부분은 기술적인 설명으로 대답하게 되죠. 예를 들어, '기술적으로 어려워서요', '이 DB가 분리되어 있어서...' 이런 식으로 말이죠.

하지만 사실은, 다른 팀원들, 특히 다른 직군 사람들이 진짜 알고 싶어하는 건 그게 기술적으로 왜 어려운지가 아니에요. 그들은 이 문제를 해결할 다른 방법이나, 그들이 해야 할 행동이 무엇인지가 궁금한 거죠.

그래서 개발자로서, 어떤 이유를 설명하려고 할 때 복잡하게 돌아가지 말고, 바로 핵심을 짚어요. '이 문제가 어떤 제약 조건 때문에 어렵다'고 말하고, '그럼 이 제약 조건을 좀 더 줄일 수 있는 다른 방법은 뭐가 있을까요?', '이걸 어떻게 우회할 수 있을까요?' 이렇게 대화를 이어가 보세요.

이렇게 하면, 대화가 훨씬 쉽게 풀린다는 걸 알게 될 거예요.

중요한 건, '어렵다'는 걸 납득시키려는 게 아니라, 대안에 집중하는 거예요. 왜냐하면, 우리가 해야 할 일은 그냥 스펙을 구현하는 게 아니라, 문제를 해결하는 거니까요.

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

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

예를 들어, 로그인하는 동안 외부 API를 써서 인증을 구현하는데, 응답이 너무 늦게 온다고 가정해볼게요. 사용자 입장에서는 인증하는데 시간이 오래 걸리니 이탈하게 되겠죠. 인증 API를 다른 걸로 바꾸거나 직접 구현하면 몇 개월의 개발이 들어가는 상황입니다. 그래서 '이거 인증 빠르게 할 수 없어요?'라는 질문에 '안 돼요'라고 답하고 싶어집니다.

하지만 이 딜레마를 해결하는 실제 방법이 있었어요. 순서를 바꿔서, 인증 응답이 오기 전에 다음 화면으로 넘어가고, 그 다음에 인증 응답이 와서 결과를 보고, 필요한 게 있으면 추가적인 화면을 진행하거나 그냥 통과시켜주는 거였죠.

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

이건 제가 일하는 회사에서 실제로 있었던 사례인데요, 여기서 말씀드리고 싶은 건, 충분히 고민을 해보면 '한다/안 한다'라는 것 말고도 세상엔 많은 해결책이 있다는 겁니다. 개발자가 문제 해결을 하는 사람이라고 생각한다면, 단순히 '한다/안 한다'의 사고에 갇히지 말아야 해요.

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

중요한 것은 빨리 결론을 내지 않고, '좀 다른 방법이 없을까?'라고 생각을 해보는 거예요.

요약 정리

마지막으로 습관 네 가지를 정리해볼게요.

1. 개발 스펙과 관련된 질문, 요청을 들었을 때 바로 답을 하는 대신에, 이 요구사항이 해결하는 문제와 의도, 제약 조건을 먼저 물어봅니다.

2. 상대방의 말을 듣고 나서 바로 내 답을 얘기하는 대신에, 상대방의 말을 이해한 것을 한 번 더 공유합니다.

3. 상대방의 해결책이 어렵다고 생각될 때, 안 되는 이유를 납득시키는 대신에, 제약을 덜 받는 다른 방향성이나 대안을 제시합니다.

4. 하느냐, 안 하느냐의 딜레마 상황이라고 느껴질 때, '아, 이건 안 될 것 같다'라고 단정하는 대신에, 둘 다 만족시킬 수 있는 다른 방법은 없을까 한 번 더 고민해 봅니다.

문제 해결형 개발자라는 것은 그렇게 거창한 것이 아니에요.

여러분들이 지금 개발을 하고 계신다면, 제가 방금 말씀드린 그 순간들이 분명히 있으실 거고요.

그때 본능적으로 나오는 행동 대신에, 오늘 말씀드린 습관을 한 번이라도 시도해보신다면, 그런 하루하루가 작지만 쌓여서 어느새 다른 팀원들이 너무나 같이 일하고 싶어하는 개발자가 되어있을 거라고 확신합니다.

영상으로 보기
👉 https://youtu.be/yWwMM5Lnqhg?si=G5b2iSFio3oLz77m