[책] 오늘도 개발자가 안 된다고 말했다

책을 읽고 난 느낀점 정리

일단 뭐랄까 개발자가 뭔가 외계인도 아니고, 선망의 대상도 아닐진데 뭔가 다른 세상 사람인것처럼 대하는 글의 느낌이 매우 신선하게 다가왔다.

1. 어딘가 이상한 비전공자의 협업

기획자 김군의 협업

서비스 구조와 인체 구조의 닮은 점 중에서

이게 비유가 이상하다.

증상을 파악하고 처방을 한다는 부분은 인체(의학?)와 비슷하다는 건 어느정도 공감이 가는데,
위처럼 분류한 것은 오해의 소지가 많아 보인다.

"개발자끼리도 생각이 다르다" 중에서

사람이니까 당연히 서로 생각하는 바가 다른게 당연하다. 특히 뭐든 낙관적인 사람도 있고 비관적인 사람도 있다.
다만 개발에서 요청을 받아들일 때 기간과 가능성을 정할때는 그저 POC수준에서 구현하는 것인지, 아니면 실제 서비스로 써야 하는지에 따라 기간과 가능성이 정말 많이 달라질 수 밖에 없다.

그리고 이 부분에 대해서 개발자마다의 차이가 있으니 당연히 오랜 시간 함께 지내다보면 그 개발자가 어떤 성향인지 알게 되고 개발자의 성향에 맞는 대응이 생기는 것은 당연한 것 같다.

디자이너 김 양의 협업

과거에 psd 파일을 직접 받아서 잘라서 웹사이트를 만들던 시절이 실제로 있었다.

"직접 개발해볼 수 있지 않을까?라는 착각" 중에서

디자이너가 개발을 공부하는 것에 대한 부분이 나왔는데 십분 공감이 간다. 나는 구현을 생각하는 경향이 있다. 이 틀을 깨고 디자인과 개발을 나눠서 할 수 있다면 좋겠는데, 나는 개발 한번 배워 보는 건 어때요? 라고 말을 건넬때 정말로 개발을 해보라는 의미였는데, 구조를 이해하는 수준으로 배우란 의미로 생각한다는 것도 신기하다.

 

"우리가 협업을 할 수 있었던 이유" 에서

"무식하면 용감하다는 말이 있듯이 아무것도 몰랐기 때문에 개발자의 말에 더 경청할 수 있었고, 이해되지 않는 내용은 질문을 반복하면서 협업을 위해 알고 있어야 하는 정보가 무엇인지 빠르게 학습할 수 있었다. 이른바 소통하기 위해 소통을 했던 것이다."

나는 이 문장이 개발자와 아니, 거의 모든 다른 도메인과 협업해야 하는 사람들의 마음속에 담아야 할 핵심 문장이 아닌가 생각한다.

심지어 같은 개발자라고 하더라도 경청하는 마음과 배우는 마음으로 협업한다면 비록 문제를 해결하진 못해도 협업의 과정에서의 문제는 사라지지 않을까?

2. 온몸으로 느낀 개발자

세가지 유형의 개발자

- 안된다고 말을 달고 사는 개발자

1, 서비스 구조를 고려하지 않고 개발을 요청하는 경우

2. 안정성에 영향을 주는 개발 건을 요청하는 경우

3. 쌓인 일이 많을 때 개발을 요청하는 경우

이 세가지 만은 아닐것 같은데 중요한 세가지 지점같다. 네번째로 중요하지 않아 보이는데 만들기 어렵고(하기싫은) 경우가 있지 않나 싶다. 1번과 겹치는 것 같기도 하지만, 서비스 구조와 겹치지 않더라도 그냥 개발자가 만들기 싫은 경우도 있다고 생각한다. (개발자도 그냥 평범한 사람이고 게으른 사람도 많다. 나...)

- 무엇이든 가능하다고 말하는 개발자

1. 기능의 구현 가능 여부만 놓고 대답하는 경우

2. 자신의 업무만 한정지어 가능하다고 하는 경우

세번째가 빠진 것 같다. 경험이 적은 신입인 경우. 어느정도 경력이 쌓인 개발자가 무엇이든 가능하다고 말할리가 없다. 반대로 소프트웨어의 세상에서 불가능한것도 사실 없다. 단지 제한된 자원으로 가능하냐의 문제가 첫번째고, 그걸 내가 해야 한다는게 두번째이다.

누군가 사장을 제외하고 같은 급여로 52시간 일하던 이에게 120시간 일하라고 하면 그냥 네 하고 일할 사람이 얼마나 될까?

개발자에게 가능하다. 라는 대답은 나에게 그 의무가 부여되는 것과 같다. 그 무게를 알 수록 무엇이든 가능하다고 대답할 수는 없을 것이다.

- 대안을 제안하는 개발자

앞에서도 말했지만 많은 것들이 협업을 한다면 당연히 해야 할 일이라고 생각한다. 누군가의 의견에 안되요. 가 아니라 안되면 대안을 제시하는 것이 맞다. 개발자가 부정적으로 보이는 이유는 안된다에서 끝나는 경우가 많기 때문이 아닐까? 물론 대안을 제시한다는 것조차 언젠가부터 잘 생각하게 된다. 앞에도 말했지만 그 대안이 나의 의무가 된다.

그렇기 때문에 때론 그 일을 실제 개발하지 않을 동료 개발자나 개발팀장같은 사람이 필요해진다. 직접 구현을 하진 않으며 대안을 제안하는 협업능력을 갖춘 사람이다. 의무에 대한 부담없이 개발 가능성을 이야기할 수 있지 않을까?

협업을 잘하는 개발자

- 집요한 문제해결

- 비즈니스를 이해하는 눈

- 쉽게 말하는 소통의 기술

- 체계적인 업무 관리와 빠른 피드백