14.5 지속적 학습과 성장
완벽하게 공부하고 시작하기 vs 시작할 만큼 준비해서 시작하기
추석 연휴의 첫날, 나는 산책을 하며 머릿속에 떠오르는 생각들을 음성 메모로 기록했다. 그리고 시간이 날 때 이를 글로 정리해 본다
어떻게 채용/취업해야 하나?
내가 개발자로서 첫 경력을 시작한 LG-EDS에 입사했을 때를 떠올려본다. 당시 신입 사원들은 거의 1년에 가까운 시간을 교육받았다. 기술적인 부분은 물론, 직장 매너와 사회생활에 필요한 다양한 교육을 받았다. 그때는 몰랐지만, 지금 돌이켜 보면 그 시간이 얼마나 소중했는지 깨닫게 된다.
하지만 지금은 어떨까? 많은 회사들이 자신들이 사용하는 기술 스택을 나열하고, 그 기술들에 숙련된 ㅇ니재를 채용하려고 한다. 이로 인해 취업 준비생들은 업무 수행을 통해 가치를 기여하며 성장하기보다, 이런 기술들을 배우느라 많은 시간과 돈을 쓰게 된다.
기술 스택보다 중요한 것
Buckminster Fuller's Knowledge Doubling Curve, with post-1982 addition by IBM
그러나 나는 이런 접근 방식에 의문을 제기하고 싶다. 위 지식 배가 곡선 그래프를 보면 지식이 2배가 되는 데 걸리는 시간이 점점 짧아지고 있다는 것을 보여주고 있다(1900년대에 100년이 걸리던 것이, 2020년엔 12시간도 안 걸리고 있다). 이런 시대에 지금 내가 잘하는 것, 알고 있는 것이 중요할까? 지금 당장 어떤 기술을 잘 다루는 것보다 더 중요한 것은 무엇일까?
바로 '학습 능력'과 '적응력'이다.
1999년, 내가 스타트업으로 이직할 때의 경험을 떠올려본다. 당시 나는 주로 Microsoft COM+ 환경에서 MTS, VisualC++ 등을 통해 개발을 하고 있었고, Java와 EJB를 몰랐다. 이 점에 대해서 면접 때 괜찮을지 물어봤었다. 그때 담당자는
"그건 와서 배워도 된다"
고 했다. Java는 잘 몰랐지만 C++, 객체지향에 대한 기본 지식을 면접 때 어필해서 나는 채용이 되었다. 실제로 입사 후 빠르게 새로운 기술을 익히고 적용할 수 있었다. 새로운 기술을 배울 수 있는 기본기가 있고, 열정이 있다면 할 수 있는 일이었던 것이다.
실제로 입사했을 때 "Thinking jn Java" 원서를 주면서 Java를 공부할 시간을 1주일 줬었다. Java를 충분히 알기에는 택도 없이 부족한 시간이었다. 하지만 시간이 지나고 나니 그때 1주일이 매우 적절했다고 본다. Java, EJB를 모르는 개발자가 충분히 배우려면 몇 달이 걸릴 것이다. 하지만 몇 달 후에 정말 개발을 하기에 부족함이 없었을까? 아닐 것이다. 그러니 1주일이라는 압박적인 시간에 힘들게 준비를 하고 이후에는 일을 하면서 부족한 부분을 채워나가는 것이 훨씬 실용적인 방법이다.
취업 준비도 마찬가지인 것 같아. 완벽히 준비해도 부족함이 있을 것이다. 시작할 수 있을 만큼 준비하고 업무를 하면서 배우고 성장하는 것이 맞는 방법일 것이다. 물론 취업 자체가 어려운 시대인 것이 아쉽지만 말이다.
코딩 실력 vs 협업 능력
한때 나는
"협업이 안 되어도 실력만 좋으면 된다"
고 생각했다. 처음 Daum에서 팀장이 되었을 때 개발(구현) 실력만 뛰어나다면 의사소통 등 협업에 문제가 있어도 함께 일할 수 있다고 생각했었다. 그에게 내가 일을 시키고, 다른 사람들과의 협업은 내가 개입하면 된다고 생각했다. 이렇게 하면 구현 역량만 뛰어나기만 하면 더 높은 기여를 하고 성장할 수 있을 것이라고 생각했었다.
하지만 시간이 지나며 깨달은 것은, 우리의 코드는 단순히 기계와 소통하기 위한 것이 아니라 팀 동료들과 의사소통하기 위한 수단이라는 점을 더 많이 느끼게 되었기 때문이다. 그러니 아무리 개발 역량이 뛰어나더라도 협업 역량이 부족하다면 같이 일하기 어렵다는 것을 알게 되었다. 그리고 내가 개입해서 협업을 하는 것도 한계가 있었다. 특히 함께 일해야 하는 구성원의 수가 늘면 더 불가한 일이었다.
심지어 일부 회사들은 블라인드 코딩 테스트만으로 개발자를 채용하기도 했다. 이때 오랜 기간 개발 팀장을 한 후배가 했던 말이 생각난다.
"코딩을 못해서 나를 괴롭힌 신입은 한 번도 없다."
이는 코딩 능력보다 협업 역량, 사회성 등이 실제 업무에서 얼마나 중요한지를 잘 보여준다.
클린 코드와 실용주의 사이의 균형
개발자로서 성장하면서, 나는 클린 코드와 전문가(장인) 정신의 중요성을 강조하곤 했다. 이때 나는 실무에서는 좀 떨어져서 개발 조직의 방향성을 제시하고, 구성원들이 한 방향으로 정렬되로고 하고, 경영진과 개발 조직 간의 가교 역할을 하며 개발 문화 개선에 몰두할 때였다.
지금도 이전과 같은 역할도 하지만, 그때메 비해 회사가 작아지고 작은 개발 조직을 리딩하다 보니 보다 실무적인 고민을 한다. 예를 들어 누군가 복잡하거나 이해하기 어려운 비즈니스 로직을 구현하고 있는데 버스 팩터가 낮으면 그의 이직 등으로 인해 발생 가능한 위험을 걱정하게 된다. 그러다 보니, 새로운 관점을 갖게 되었다.
지금은 "회사의 일이 되게 하고 돈을 벌게 하는 것"이 가장 중요하다고 생각한다. 클린 코드도 중요하지만, 클린 코드도 결국 팀원들 간의 의사소통을 위해서 필요한 것뿐이다. Ron Jeffries가 말한
"Clean code that works"
에서 "clean code"가 주된 목표(주어)이지만 "that works"는 필수 조건이다.
동작하지 않는다면 clean code는 무의미하다. 돌아가는 코드를 만들면서 기여하고, 그 과정에서 점진적으로 코드의 품질을 높여가는 것이 실용적인 접근 방식이다. 동작하지 않아도 된다면 엄청나게 훌륭해 보이는 코드를 작성하는 것은 어렵지 않을 것이다.
만일 클린 코드, 전문가 정신이 너무 중요해서 clean code가 가장 우선순위가 높다면 개발자로서의 경력을 처음 시작한 주니어 개발자는 언제 자신이 작성한 코드를 배포할 수 있을까?
객체지향 원칙, SOLID 원칙, Design Patterns, Refactoring 등의 측면에서 부족함이 있어서 메서드, 클래스 등이 제대로 나눠져 있지 않고, 이해하기 어려워서 코멘트로 도배가 되어 있더라도 자신의 의도를 팀원들에게 전달할 수 있고, 현재의 요구사항을 수용하면서 올바르게 동작한다면 배포할 수 있어야 한다.
배포한 코드가 자주 읽어야 하고, 자주 수정되어야 하다면 시간이 지나면서 리팩터링을 통해 지속적으로 개선될 것이다.
Premature Optimization
Donald Knuth는 "Structured Programming With Go To Statements"에서
"프로그래머들은 그들의 프로그램에서 중요하지 않은 부분의 속도에 대해 생각하거나 걱정하는 데 엄청난 시간을 낭비합니다. 이러한 효율성 추구는 실제로 디버깅과 유지보수를 고려할 때 매우 부정적인 영향을 미칩니다. 우리는 작은 효율성에 대해서는 잊어야 합니다. 즉, 97% 정도의 시간 동안은 그렇게 해야 합니다. 조급한 최적화는 모든 악의 근원입니다. 하지만 그 중요한 3%의 기회는 놓치지 말아야 합니다"라고 말했다.
이 글을 보면 97%가 불필요한 조숙한 최적화라고 한다
그러니 우리는 지금 100% 최적화(리팩터링)할 필요가 없다. 오히려 그러면 안 된다. 지금 필요한 만큼만 균형 있게 개선하고, 시간이 있다면 다른 중요한 기능들을 빠르게 동작하는 게 더 맞는 방법이다. 정말 중요한 코드라면 계속해서 마주할 것이고, 그때마다 조금씩 개선하는 것이 맞다.
다만 배포된 후에 필요한 경우에 적절한 개선(리팩터링)을 할 수 있다는 것이 전제가 되어야 한다.
기술부채는 당장 채무를 지지 않을 수 있지만 속도를 위해서 의도적으로 채무를 지는 것이어야 한다. 상환 능력이 없는 채무는 파산으로 이르게 되기 때문이다.
지속적 학습의 중요성
결국, 개발자로서 성공하기 위해 가장 중요한 것은 무엇일까? 그것은 바로 지속적으로 학습하고 성장하는 능력이다. 특정 기술을 아는 것보다, 새로운 기술을 빠르게 습득하고 적용할 수 있는 능력이 더 중요하다. 최근에 채용을 할 때 가장 중요하게 보는 측면은 후보자가 스스로 학습하여 지식을 습득하고 성장할 수 있는가이다. 모든 것을 누군가가 알려주지 않더라도 스스로 배울 수 있는 사람인지? 어려운 기술을 빠르게 학습하고 적용하여 배움을 얻은 경험이 있는지가 중요하다.
온라인 강의나 부트캠프는 좋은 시작점이 될 수 있지만, 그것만으로는 충분하지 않다. 실제 문제를 해결하며 겪는 경험, 그 과정에서 필요한 정보를 찾아 학습하는 능력, 그리고 동료들과 협력하며 성장하는 자세가 진정한 개발자의 자질이다.
SK Planet으로 이직을 할 때 휴가가 많이 남아서 미리 준비할 수 있는 시간이 있었다. 이때 Spring Cloud를 기반 MSA 적용을 통해 11번가 아키텍처 개선을 준비했었다. 당시 나는 Spring Cloud에 대해 깊은 지식이 많지 않았다. 그래서 Udemy에서 2~3만 원 정도 하는 강의를 들으면서 전체적인 이해를 빠르게 했고, 이후 책, 공식문서, 예제, 테스트 등을 통해 이해를 깊게 했다. 남이 알려주는 것은 이 정도 수준으로 활용하는 것이 맞아 보인다. 이렇게 좋은 시작을 위한 강의는 그렇게 깊거나 비쌀 필요가 없다고 생각한다. 디테일은 후에 실무에서 겪는 어려운 문제를 스스로 탐색, 학습을 통해 해결해 가면서 채워야 하는 것이다. 온라인 강의와 같은 지름길에 정상적인 경로와 같은 것을 기대하지 말아야 한다.
마지막으로, 신입 개발자들에게 조언하고 싶다. 처음부터 완벽할 필요는 없다. 아니 완벽하게 알고 나서 무엇인가를 시작하려고 하지 말아야 한다.
객체지향을 정확하게 이해하고, 도메인 주도 설계를 정확하게 이해하고, JPA를 정확하게 이해하고 시작하려 하지 말아야 한다고 생각한다. 시작할 수 있는 정도로 아는 것으로 시작해서 일을 하면서 문제를 겪으면서 책, 공식 문서 등을 통해 필요한 정보를 배우는 것이 더 효과적이다.
완벽한 상태에서 시작하려고 하지 말자. 우리는 사전에 무엇이 완벽한지 미리 알 수 없다. 우리는 문제를 풀면서 문제를 이해하고 그리고 발생 가능한 이슈를 알게 된다.
당신이 얼마나 많은 것을 알고 있는지보다, 얼마나 빠르고 효과적으로 학습할 수 있는지가 더 중요하다.
