이전 시간에 집요함이 개발자의 성장에 있어서 매우 중요하다는 것을 집요하게 강조했다. 좀비 모드라는 표현을 써 가면서 말이다. 그런데 집요함 사용법에는 몇 가지 주의 사항이 있다. 잘 숙지하여 집요함이라는 까다로운 무기를 성공적으로 다룰 수 있길!
맺고 끊기
집요함이 개발자를 성장시키는데 중요한 요인이긴 하지만 자칫 잘못하면 집착을 집요함으로 착각할 수도 있다. 개발이라는 것은 시간이라는 요인으로부터 자유로울 수 없다. 보통은 어느 정도 일정을 산정한 후 개발에 착수하게 되는데, 일정에 악영향을 줄 정도로 집요함을 발휘한다면, 집요한 것이 아니라 집착하고 있는 것은 아닌지 점검해 보아야 한다.
보통 어떤 개념이나 기술을 파다 보면 어디까지 파야 하는 것인가 싶을 정도로 끝이 보이지 않는 경우가 생각보다 자주 있다. 한 개념을 파는데 새로운 개념이 나오고 거기서 또 다른 개념이 나오며 마치 그래프의 DFS(Depth First Search)처럼 계속 파고 또 파게 되는 것이다. 시간이 무한정이라면 상관없겠지만, 우리는 정해진 일정 속에서 개발을 해야 한다. 무한정 팔 수만은 없다.
어느 순간 파는 것을 멈추는 것이 필요하다. 문제는 '어느 선에서 멈춰야 하는가?'인데 정해진 법칙이 따로 있는 것은 아니다. 개인의 감이 필요한데, 본인의 기술적 수준이나 현재 개발 상황 등을 종합적으로 고려하여 어느 선에서 멈출지 감을 잡아야 한다.
선을 잡는 나만의(?) 팁을 공유하고자 한다. 새로운 개념이나 기술을 이해하기 위해 필수적으로 알고 넘어가야 하는 개념들은 상대적으로 원 개념에 가까이 있기 마련이다. 반면에 depth가 깊어지면 깊어질수록 원 개념과는 점점 멀어져서 연관성이 떨어지는데 이런 개념들은 잘 몰라도 원 개념을 이해하는 데는 큰 어려움이 없다. 이런 관점에서 처음 목적했던 개념을 이해하는데 집중하기 위해 보통은 1-depth나 2-depth, 많으면 3-depth 정도까지만 파고 더 이상 파진 않는다. 즉, 파고 들어가되 원래 알고자 했던 개념을 이해하려는 소기의 목적을 달성하기 위한 범위 내에서 파고 들어간다.
시간을 다스리는 자
비슷한 맥락에서 시간을 분배하는 것 또한 중요하다. 가령 새로운 회사에 입사했다고 가정해 보자. 그 회사는 여러 기술 스택들을 사용하는데, 대부분 사용해 보지 않은 기술들이다. 회사는 자선 단체가 아니기 때문에, 신규 입사자에게 무한정 시간을 줄 수 없다. 즉, 새로운 기술이나 개념들을 한정된 시간 내에서 파악해야 하는데, 집요함이라는 이유로 하나의 기술이나 개념을 이해하는데 지나치게 많은 시간을 사용한다면, 나머지 다른 기술들을 이해하기 위한 시간은 턱없이 부족해질 것이다.
이런 경우엔 나무의 가지나 잎 하나하나를 디테일하게 살피려고 하기보다는 전체적인 숲을 보는 게 더 좋다. 각 기술의 개념과 특징은 무엇인지, 왜 필요한지, 장단점은 무엇인지, 주의사항은 없는지, 어떤 이유와 용도로 회사 서비스에서 사용하게 됐는지 등등 기술들의 전반적인 사항을 파악하는 데 시간을 투자하는 게 좋다. 디테일한 사용법이나 설정은 실제 개발을 진행하면서 파악해도 늦지 않다. 그리고 전반적으로 파악할 때 혼자 노력하는 것도 좋지만, 동료의 도움을 받는 것도 중요하다. 먼저 일하고 있던 동료의 설명은 엔진에 부스터를 다는 것과 같다.
그대로 멈춰랏!!
개발을 하다 보면 심심찮게 삽질을 하게 된다. 구현을 했는데 원하는 대로 동작하지 않는 것이다. 문제를 해결하려고 이런저런 노력을 했지만 해결되진 않고, 한 시간 두 시간 세 시간 네 시간.. 삽질의 시간은 점점 길어져 간다. '집요해야 해. 정답은 집요함이야.. 오늘 안에 이 문제를 반드시 죠져버리게쒀!!!'
하지만 난 퇴근을 추천한다. 개인적인 경험이나 주위의 사례를 비춰 봤을 때 안 되는 것을 계속 붙잡고 있기보다는 쉬고 와서 다음 날 다시 해보는 게 더 좋은 결과와 효율을 보일 때가 많았다. 우리 뇌는 컴퓨터의 CPU가 아니기 때문에 24/7(24 시간 세븐 데이즈) 풀(full)로 동작할 수 없다. 쉴 때는 쉬어줘야 한다. 머리 쓰는 일도 많은 에너지를 필요로 하기 때문에 개발하고 있는 시간이 길어지면 길어질수록 집중력과 두뇌 회전력(?)이 점차 떨어질 수밖에 없다. 뇌도 휴식이 필요하다.
누군가는 일정이 빡빡해서 어쩔 수 없다고 할지 모르겠다. 한두 번이야 그럴 수 있겠지만 이런 일이 비일비재하다면 어쩔 수 없다고 말하기 이전에 애초에 일정 산정 방식에 문제가 있는 것은 아닌지 점검해 봐야 한다. 버퍼 없이 일정을 너무 빡빡하게 잡은 것은 아닌지 혹은 일정 산정을 정확히 못하고 있는 것은 아닌지 말이다.
멈추는 것도 능력이고 잘 쉬는 것도 능력이다. (이 말이 태만함의 명분이 되진 않길 간절히 바란다.) 오늘 목표했던 분량까지 깔끔하게 마무리 짓고 퇴근하고 싶겠지만, 물고 늘어져도 잘 풀리지 않을 때는 자리를 박차고 일어나도 괜찮다. 아니, 그래야 한다. 번 아웃(burn out) 되지 않으려면, 이 바닥에서 롱 런(long-run) 하려면, 오늘만 살 것처럼 개발하기보다는 적절히 끊어주며 본인의 컨디션을 꾸준하게 유지하는 것이 더 중요하니까.
개발이 전부가 아님을..
집요함을 지나치게 발휘하다 보면 곁다리로 부작용이 생길 수 있는데, 바로 개발 만능주의다. 집요하게 파다 보니 개발자로서 당연히 성장하게 되고, 개발하는 게 재밌어지게 된다. 그러다 보면 보이는 문제마다 기술적으로 풀고 싶은 욕구가 생길 수 있는데, 그 자체는 건강하다고 생각하지만 개발 만능주의에 빠진다면 그건 위험하다. 개발자라면 맞닥뜨리는 모든 문제를 기술로 해결해야만 훌륭한 개발자일까?
문제를 푸는 방식은 다양하다. 개발로 풀 수도 있지만 정책이나 운영으로 풀 수도 있다.
미국에서 수백만 달러를 들여서 우주에서 쓸 수 있는 볼펜을 개발했다.
이걸 들고 우주 정거장에 도착한 미국 우주 비행사들이 소련 우주 비행사들에게 볼펜을 자랑을 하자
소련 우주 비행사들이 퉁명스럽게 말했다.
"우린 연필 쓰는데?"
많이들 알고 있는 이 이야기는 (실제와는 조금 다르지만 어쨌든) 시사하는 바가 크다. 기술과 개발은 분명 아주 강력한 도구이지만 인적/경제적/시간적 비용이 많이 드는 일이다. 현업에서의 개발은 99.999% 한정된 시간과 자원 속에서 개발하기 마련이라 모든 문제들을 개발로 푸는 것은 답이 아닐 수 있다.
예를 들어보자. 한국에서 론칭 후 성공 가도를 달리고 있는 어떤 서비스가 있다고 하자. 이제는 서비스의 글로벌화를 목표로 우선 동남아 시장부터 공략하기로 야심 차게 준비하고 있는데,, 이게 웬걸? 일부 동남아 국가의 네트워크 인프라가 좋지 않아서 인터넷 속도가 느리고 잘 끊긴다는 것을 뒤늦게 알게 됐다. 그러다 보니 한국에서는 잘 동작하고 있던 기능들이 해당 국가에서는 잘 동작하지 않는 현상이 발생하는 것이다. 어떤 해결책이 있을까? 열악한 네트워크 환경에서도 잘 동작할 수 있도록 개발팀이 달라붙어서 튜닝하는 것도 방법일 수 있겠지만, 전략적인 판단에 따라 인터넷 환경이 좋지 않은 국가에서는 우선은 서비스하지 않는다고 정책적으로 정할 수도 있다.
또 다른 예를 들어보자. 이제 곧 앱 출시를 눈앞에 두고 있다. 그런데 고객 대응을 어떻게 할지를 놓고 고민이다. 앱 출시 전이라 고객 문의가 어느 정도로 올지 알 수 없으니 고객 지원팀을 꾸리기는 부담스럽다. 팀을 꾸릴 돈도 없다. 그럼 문의 게시판을 하나 개발할까? 아니면 우선은 이메일 계정을 올려놓고 문의는 메일로 달라고 할까? 전략적으로 판단할 여지가 있는 문제다.
이처럼 개발 외에도 유효한 방법들이 있음을 이해하고 열린 마음으로 접근해야 한다. 비슷한 맥락에서 이미 누군가가 개발해 놓은 것이 있어서 가져다 쓰기만 하면 되는데 (대표적인 예로 각종 라이브러리) 굳이 직접 개발하겠다는 것 또한 고민해 볼 문제다. 시간과 인력을 들여서라도 직접 개발하고 싶다면 팀을 포함하여 이해 당사자들이 납득할 만한 합당한 이유와 설득의 과정이 있어야 한다. 그렇지 않고 개인의 성취감이나 도전 의식 때문이라면, 생각을 굽혀서 양보하거나 따로 개인 시간을 들여서 개발하는 것이 더 합당한 처신일 것이다. 이미 있는 걸 쓰면 되는데 집요하게 굳이 새로 개발하겠다는 것,, 어쩌면 집요함이 아니라 집착 아니었을까?
멈춰야 비로소 보이는 것들
공교롭게도 풀소유 논란이 있었던 혜민 스님의 책 제목과 비슷한데, 그 책 내용은 어떨지 모르겠다. 앞 부분에서 뇌를 쉬어주는 것에 대한 중요성을 언급했는데, 좀 더 긴 호흡으로 쉼을 가지는 것도 중요하다는 것을 말하고 싶었다.
개발자로 잘 성장하고 싶어서 하루하루 집요하게 열심히 끈질기게 꾸준히 살다 보면 개발 한가운데서 늘 살게 되는데, 이따금 개발은 OFF 하고 쉼을 가지는 것이 필요하다. 환기라고 할까? 분위기 전환이라고 할까? 개발자의 성장이라는 것이 개발만 주구장창 주야장천 한다고 꼭 잘 되는 것은 아닌 것 같고, 이따금 주위도 둘러보고 여행도 가보고 개발 서적은 잠시 구석에 짱 박아두고 읽고 싶었던 책이나 영화를 보면서 개발 외의 인풋(input)을 만들어 줄 필요가 있다. 그러면서 삶에 대해서, 소중한 것에 대해서 생각해 보는 시간을 가져 보는 것이다.
성장 자체가 목적이 될 수도 있겠지만 (그런 경우라면 논외로 하고) 결국 나는 왜 성장하고 싶은지, 성장해서 무엇을 하고 싶은지, 지금까지 걸어온 길은 어땠는지, 무엇이 나에게 정말 소중한지에 대한 묵상이 필요하다. 승마장의 경주마처럼 앞만 보고 개발만 하다 보면 어느 순간 뒤를 돌아봤을 때 '무엇을 위해 이렇게..' 흔히 말하는 현타가 올 수 있다.
멈춰야만 볼 수 있는 것들을 챙기자.
개발자도 결국 삶을 사는 사람이니까.