개발자들 중 일을 못하는 사람들이 있다. 그리고 일 못하는 개발자가 일을 못하는 원인은 단순히 개발을 못해서가 아닐 경우가 꽤나 많다. 언어에 대한 지식이나 알고리즘 문제는 기가 막히게 잘 푸는데 이상하게 일은 진도가 안 나가는 사람.. 그런 사람을 본 적이 있다면 공감이 갈 것이다. 그래서 많은 개발자들이 추측했을 때 그들이 일을 못하는 건 태도나 성향 때문이라고 말한다. 정말 그럴까?
물론 정말로 태도나 성향이 개발자와 맞지 않는(난 사실 개발자를 못하는 원인이 태도나 성향에 있다면 그냥 ‘일’이라는 것하고 안 맞는 사람일 거라고 생각함) 사람들도 있겠지만, 내가 생각했을 때 가장 큰 원인은 잘못된 방향 설정, 다르게 말하면 잘못된 선택 때문이다. 개발자라면 방향이 잘못된 노력이 얼마나 허무한지 모두 공감할 것이다. 똑같은 문제를 마주했을 때 나는 몇 주를 낑낑대도 문제 해결이 안되는데, 어떤 사람은 그걸 3시간 만에 뚝딱 해치우는 충격적인 경험. 이런 경험을 하면 어떤 개발자든 절망에 빠지지 않을 수 없다. 그렇다면 도대체 잘못된 선택이 무엇이고, 올바른 선택은 어떻게 하는 것일까? 나는 이에 대한 생각을 책 ‘자신 있게 결정하라’를 보며 나름대로 정리해볼 수 있었다.
일 못하는 개발자의 잘못된 선택 4가지
책 ‘자신 있게 결정하라’에서 소개된 선택을 방해하는 4가지 악당 유형을 보며 우리가 피해야 할 개발자 유형 4가지에 대해서 생각해보자.
- 편협한 악당 - 드라마 ‘미안하다 사랑한다’(아재의 향기)의 주인공 소지섭 같은 유형. “나랑 결혼할래, 나랑 죽을래”
- 고집스러운 악당 - 정치나 종교에 푹 빠진 분들이 자주 이런 실수를 저지른다. 나에게 유리한 정보만 모아서 스스로의 확신을 강화하는 유형. “내가 하면 로맨스 남이 하면 불륜.”
- 감정적인 악당 - 감정에 휘둘려 잘못된 선택을 하는 유형 “그러지 말았어야 했는데..”
- 확신에 찬 악당 - 스스로의 선택이 절대 틀렸을 리 없다고 확신하는 유형 “나는 성공할 거야, 왜냐하면 이건 내 꿈이거든!”
사례 1 - 편협한 개발자
“웹 개발을 하고 싶은데 Java를 쓸까요, Python을 쓸까요?”
그냥 일반 사람들이 봤을 때는 별거 아닌 질문. 근데 개발자 커뮤니티에서는 나라를 불문하고 이 주제로 싸우는 사람들이 꼭 있다. 잠깐 그들이 말하는 걸 들어보자.
자바 마스터: "자바가 최고다. 왜냐하면 최고이기 때문이다."
파이썬 마스터: "아니다 파이썬이 최고다. 왜냐하면 최고이기 때문이다."
응 둘 다 틀렸어. C#이 최고야 :P ... 는 농담이고ㅋ, 이렇게 싸우는 사람들은 사실 각자가 생각하는 '전제조건' 하에 자신이 옹호하는 언어가 최고라고 주장하고 있다. 문제는 그 '전제조건'이라는 게 공유되지 않을 때도 많고, 심지어 그 범위가 너무 좁아서 올바른 판단을 하기도 어렵다.
책 '자신 있게 결정하라'의 저자 히스 형제는 이런 사람들이 '범위 한정 성향(narrow framing)'에 빠져있다고 표현한다. 즉, 좁은 프레임에 갇혀있다는 거다.
만약 우리 개발자들이 일을 하고 있는 영역이 유구한 역사와 전통이 이어져와 모든 구성요소들이 변하지 않는다고 한다면.. 이런 식의 생각의 단순화(아름다운 단어 치환!)가 도움이 될 수 있다. 하지만 프로그래밍 기술은 5년만 지나도 별세계다. (물론 그렇다고 전통적인 기본 지식이나 역사를 배울 필요가 없다는 얘기는 아니다. 그냥 새로운 거 죽어라 계속 공부해야 한다고 노예자..."퍽")
이런 식으로 스스로를 사고의 틀에 가두는 사람은 새로운 환경에 적응하기 힘들고, 계속해서 환경이 발전 및 변화해가는 IT업계에서 일을 잘하기가 매우 힘들다.
사례 2 - 고집스러운 개발자
"개발자라면 IDE(코드 작성을 돕는 도구)가 제공하는 코드 자동완성(==인텔리센스) 없이 한 땀 한 땀 타이핑해야지"
이런 주장을 하며 한-땀 한-땀 코드를 작성하는 자칭 장인분들이 있다. 물론 그들이 주장하는 바도 일리가 있다. 자동완성에 너무 의존하다 보면 IDE가 없는 환경에서 간단한 코드 한 줄도 작성하지 못하는 개발자들이 많고, 코드의 흐름에 대한 이해도가 떨어질 가능성도 있기 때문이다. 하지만 이런 근거들은 어디까지나 본인의 주장에 유리한 근거만 모아둔 것이다.
코드 자동완성을 잘 활용하는 개발자가 쓸데없는 타이핑 없이, 그리고 처음 사용하는 외부 라이브러리 등을 사용할 때 매번 화면 번갈아 봐 가며 써야 할 필요성 없이 빠르게 코드를 작성할 수도 있다. 한 땀 한 땀 타이핑하다가 실수했을 때 본인이 타이핑을 잘못했는지도 모르고 오타 찾아서 헤매게 될 수도 있고 말이다.
자신의 의견을 꺽지 않는 고집스러운 개발자는 해롭다. 본인만 일을 못하면 괜찮지만, 팀 전체의 생산성을 낮추고 사기 또한 낮출 가능성이 높기 때문이다.
사례 3 - 감정적인 개발자
"이 함수를 이제 안 쓰네, 근데 언제 또 쓸지 모르니까 일단 보관해둬야지."
정말 많은 개발자들이 이런 식으로 더 이상 사용하지 않는 코드를 보관해둔다. 그리고 1년이 지나고, 2년이 지나고, 3년이 지나고.. 코드 작성자는 퇴사하고, 5년 뒤 입사한 신입.
"도대체 왜 이렇게 쓸데없는 코드가 많아! 끄아아아아아!"
이런 식으로 본인이 짠 코드를 지우기가 뭔가 아깝기도 하고, 나중에 또 쓸 수도 있기도 하니까 보관하는 개발자들이 꽤나 많다. 본인 개인 프로젝트라면 상관없겠지만, 회사 제품에 이런 식의 코드를 남기기 시작하면 덩치 큰 쓰레기가 돼서, 최악의 경우 서비스에 큰 기능을 업데이트하고 싶을 때 차라리 새로 만드는 게 더 빠른 상황이 될 수 있다.
아무리 내 시간과 에너지가 들어간 코드가 자식같이 느껴지더라도.. 이런 감정에 휘둘리다가 정말 큰 감정의 역풍을 맞이할 수가 있다.
사례 4 - 확신에 찬 개발자
"이 버그는 저쪽팀 코드 문제겠지. 왜냐하면 난 완벽한 코드를 짰거든."
만약 같이 일하는 개발자가 이런 식으로 생각한다면 어떨까? 생각만 해도 끔찍하다. 자신이 작성한 코드, 자신이 설계한 구조에 버그가 없다는 확신을 가진 개발자가 여태까지 어떻게 살아왔을까 상상하기도 힘들다. 그런데 그 일이 발생했습니다. 물론 저 정도로 극단적인 경우는 잘 없다. 하지만 은근히 이런 식의 전제조건을 갖고 협조 요청을 하는 개발자들이 존재한다. 근데 막상 내 코드 부분 확인하면서 요청한 사람에게 다시 질문해보면 본인 코드를 테스트 조차 해보지 않은 경우가 있다.
같이 일하는 사람을 화나게 만드는 개발자. 일을 못할 수밖에 없다.
선택을 잘해야 일도 잘한다
만약 당신이 위에 해당하는 유형의 실수를 저지르고 있는가? 그렇다면 당장 개발자를 그만둬라.. 썩.. 꺼~~~ 농담 :)
이런 유형의 실수는 올바른 선택 프로세스를 따른다면 쉽게 개선될 수 있다.
좋은 선택을 부르는 프로세스 "WRAP"
- 옵션을 넓혀라(Widen your options)
- 내 가정에 대한 현실성을 테스트해라(Reality-test your assumption)
- 결정하기 전에 거리를 둬라(Attain distance before deciding)
- 틀릴 것을 대비해라(Prepare to be wrong)
편협한 개발자 해결책 - 개발언어는 도구일 뿐, 다른 도구도 많다
만약 당신이 편협한 개발자의 실수를 저지른다면, 한 가지만 실행한다면 당장 편협함에서 탈출할 수 있다.
개발할 언어가 자바와 파이썬 중에 고민되면, 둘 다 선택하지 않는다는 가정하에 대안을 찾아봐라. 만약 두 가지 옵션 중에 고민된다면 둘 다 제외하고, 한 가지 옵션을 할지 말지 고민된다면 한 가지를 제외하자. 그렇다면 내가 개발할 서비스에서 언어가 제공해줘야 할 핵심 요소가 무엇인지 제대로 생각해볼 수 있을 것이다.
이 한 가지 외에도 다양한 생각 전환의 방법이 있다. 내가 개발할 서비스와 비슷한 서비스에서 선택한 언어를 찾아볼 수도 있고(모방), 자바와 파이썬 둘다를 혼용하는 선택지를 생각해볼 수도 있다(멀티 트레킹).
책 '자신 있게 결정하라'에서는 이 방식들 외에도 다양한 생각 전환의 팁을 소개해주니 만약 궁금하다면 책을 일독해보길 권한다.
고집스러운 개발자 해결책 - 손 코딩 덕후, IDE 커스텀 덕후가 되다.
"레드 썬! 지금부터 당신은 IDE의 모든 세부 기능을 사용하고, 심지어 키를 커스텀해서 사용하는 IDE 커스텀 덕후입니다."
만약 당신이 위에서 언급된 손 코딩 지지자라면, 이제부터 툴을 잘 활용하면 개발 생산성에 어떤 도움이 될지 자료를 찾아서 정리해보자. 그렇다면 생각보다 내가 사용하고 싶은 편리한 기능들을 많이 발견하고 마음을 열게 될 것이다. 이 방식이 바로 '반대자가 되어보기' 방법이다. 흔히 사자성어로 '역지사지'라고 한다.
그 외에도 무조건 IDE 커스텀 기능 직접 써보기(고의적으로 실수하기), 특정 툴 쓸 때만 툴 기능 이용해 보기(작은 실행) 등의 방식을 통해 내가 가진 신념(손 코딩!)의 현실성을 테스트해볼 수 있다.
책에서 나온 내용대로 현실성을 테스트하는 게 습관화된다면, 개발자들 사이에서 매우 유행하는 '테스트 주도 개발'의 모습이 나오지 않을까 싶다.
감정적인 개발자 해결책 - 코드는 코드일 뿐, 자식이 아니다.
자식 애지중지 키웠더니 부모 등쳐먹고 나이 40 넘도록 집에서 백수짓만 하고 있다면 어떨까? 만약 당신이 사용하지도 않는 코드를 계속 남겨둔다면, 이런 자식과 별다를 게 없다.
그 외에도 진짜 내가 가진 가치관과 직결되어있어서 감정적으로 선택하기 너무 힘든 경우가 있을 수도 있다. 만약 당신이 6개월 내에 제품 하나를 만들어야 하는 팀의 팀장이 됐다고 가정해보자. 근데 당신은 높은 생산성과 깔끔한 코드에 큰 가치를 두고 있다. 근데 이게 일정상 둘 중 하나를 포기해야 되는 상황이 됐다. 이럴 때는 진짜 중요한 핵심 가치관이 무엇인지 정해야 한다. 그리고 하나를 정했다면, 그 요소를 방해하는 요인들은 지우도록 노력해야 한다.
확신에 찬 개발자 - 버그는 언제나 발생한다.
"드디어 완성! 아 버그 있네. 고쳐야지"
"드디어 완성! 어? 버그가 없네. 이상하다"
개발자들 사이에서 밈(meme)으로 유행하는 말이다. 틀린 게 없는 게 틀린 거다라는 이런 유형의 농담이 만연 해있는 건, 소프트웨어 개발의 특성상 본인이 만든 제품의 이상 여부를 즉각적으로 피드백받을 수 있는 개발자들의 업무환경과 크게 연관돼있다. 그런데도 확신에 찼다고? 이건 안돼. 당장 개발자 그만둬. 꺼져!(엄근진)
개발자는 실력이 중요하다.
실력이 좋은 개발자는 일을 잘해야 한다.
일을 잘하려면 프로세스가 좋아야 한다.
프로세스가 좋으려면 '자신 있게 결정하라'를 읽어야 한다.
| 프로그래밍에 대한 생각 |
| 실력을 키우는 독서 |
'서평' 카테고리의 다른 글
| 돈이 되는 사이드 프로젝트를 위한 5가지 팁 (17) | 2019.09.16 |
|---|---|
| 내향적인 개발자를 위한 직장생활백서 (13) | 2019.09.11 |
| 진짜 강한 사람이 되는 방법 (0) | 2019.08.27 |
| 사랑스런 오베에게 배우고 싶은 5가지 (0) | 2019.08.20 |
| 제대로 돈 아끼는 방법, 알고 싶으세요? (0) | 2019.08.13 |
