나는 20대지만 처음 개발을 만난 지 올해 들어 벌써 10년이 되었다. 고등학교 2학년 때 처음 개발을 접하고 지금까지 이어오면서 한 가지 깨달은 것이 있다면, 바로 개발을 잘하는 사람과 못하는 사람은 명확하게 다르다는 점이다. '개발' 이라고 표현했지만 이제부터는 개발이 아니라 '코딩' 이라고 지칭한다. 내게 있어서 개발은 프로그래머만 하는 것이 아닌, 회사의 대표이사뿐만 아니라 기획자, 디자이너, 프로그래머 등 많은 사람들이 참여하고 설계하여 새롭고 아이디어 넘치는 제품을 만드는 일을 개발이라고 규정하고 있으므로 단순하게 주어진 문제가 있으면 이를 기술적인 코드로 구현하는 것만을 지칭할 때는 '코딩' 이라고 할 것이다.
프로그래머가 하는 일은 '현실세계의 문제를 기술적으로 해결하고 제품을 생산하는 일' 이 주요 핵심이다. 공학의 본질적인 이야기를 관통한다. 다만, 이 글의 제목이 '어떤 사람이 코딩을 잘할까?' 인 만큼 개발보다는 코딩에 초점을 맞춰보고자 한다. 나는 다른 글에서는 흥미와 적성, 마인드셋, 대외활동 등 조금은 다른 이야기들을 많이했었는데, 이 글에서는 개인의 능력에 대해 이야기해보고자 한다.
사람은 저마다 가지고 있는 능력이 다른데, 코딩의 세계에서 재능이란, 능력이란 도대체 무엇일까? 단순하게 엉덩이가 무거운 것이 코딩을 잘하는 비결이라고 하는 사람도 있었는데, 과거에는 나도 그렇게 생각했지만, 이제는 아니다. 이는 내가 코딩을 하면서 의자에 앉아있던 시간, 또한 과거에 음악대학을 가겠다고 피아노를 수년간 치면서 의자에 앉아있던 시간에 비교해보았을 때 단순하게 손가락만 움직인다고 해서 그 분야를 특출하게 잘하게 될 수는 없다는 것을 알았기 때문이다. 물론, 노력이 기본 베이스가 되어야 하는 것은 사실이지만, 단순하게 '노력만 하면 되겠지' 라고 접근했다가는 공부는 열심히 하는데 정작 성적은 안 나오는, 그런 학생이 될 가능성이 높다.
코딩에도 재능은 있다. 예체능 분야에 비해서 대중들의 눈에 덜 띄일 뿐, 재능은 존재하고 있다. 그러나 이 같은 사실이 '나는 코딩에 재능이 없다' 라고 하면서 코딩을 포기하거나 일을 회피하게 되는 근거가 되지는 않는다. 이 재능은 선천적일 수도 있지만, 후천적인 노력으로도 '어느 정도' 는 커버가 되기 때문이다. 또한 코딩에 특출난 재능이 없다고 하더라도 그저 직업으로서 먹고사는 일은 가능하다. 코딩은 예체능처럼 승자독식이 발생하는 곳은 아니니까. 그저 우리가 알아야하는 것은 코딩을 잘하는 사람들은 어떤 사람들인가? 에 대한 논의와 이를 스스로에게 적용하는 것이다.
문제를 바라보는 관점
많은 이들이 개발자가 가져야하는 덕목으로 '문제해결능력' 을 이야기한다. 물론, 중요하다. 하지만, 그전에 '문제인지능력' 이 우선되어야 한다. 문제가 무엇인지를 본질적으로 파악하는 것이 선행이 되어야만 적절한 해결책을 제시하고 이를 기술적으로 구현하기 때문이다. 코딩을 잘한다는 것의 기반에는 문제를 다양한 관점에서 이해한다는 것에서부터 시작한다. 한 가지 간단한 예를 들어보자.
우리는 유튜브와 같은 영상 플랫폼을 운영하고자 한다. 그런데, 크리에이터가 영상을 올리려고 하는데 업로드 속도가 너무 느린 것 같다는 피드백이 들어왔다. 이 문제를 어떤 방식으로 접근해야 할까? 여기서의 핵심은 '기술' 을 신경 쓰지 말아야 한다는 점이다. 아이러니하게도 개발자는 '기술' 을 사용하여 문제를 해결하는 직업이지만 어떨 때는 기술을 쓰지 않아도 해결을 할 수도 있다. 이러한 것을 고려해볼 때 기술이라는 우물에서 벗어나 다양한 관점에서 볼 필요가 있다. 문제의 인지와 말로써 해결책을 제시하는 일에는 사실 코딩이 필요하지도 않다.
영상 업로드가 느리다는 피드백에 대해 두 가지 해결책을 생각해볼 수 있다. 하나는 기술적으로 영상의 업로드 속도를 극대화하는 것이다. 또 한 가지는 크리에이터가 영상을 업로드하는 동안 다른 장치를 통해 업로드 시간이 느리지 않은 것 '처럼' 느껴지게 하는 것이다. 어떤 해결책을 적용시키냐에 따라 사용하는 기술도 달라질 것이며 논의되는 이야기 또한 다를 것이다.
제시된 두가지 해결책을 모두 시도해본다고 생각해보자. 먼저, 기술적으로 영상 업로드의 속도를 최대로 올리는 것은 한계가 명확하다. 클라이언트와 물리적으로 가까운 리전의 클라우드 스토리지를 사용하고 HTTP3 와 같은 최신 프로토콜을 사용하는 등 여러 시도를 해볼 수 있지만, 단순하게 생각해도 이는 크리에이터가 속한 국가와 네트워크 속도 및 환경에 따라 달라질 수도 있다는 치명적인 변수가 존재한다.
또 한 가지 방법인 어떤 장치를 두는 것은 어떤가? 그전에, 영상을 올린 뒤에 하는 일이 있다면 어떤 것들이 있을지 고민해보자. 제목과 설명, 태그를 설정하거나 더 나아가 자신의 콘텐츠와 유사한 주제를 탐색하고 이미 업로드 했던 다른 영상의 통계를 확인하는 일이 있을 것이다. 이 일은 크리에이터가 해야 되는 일이다. 업로드 이후에 해야 하는 이 과정을 피할 수 없다면, 차라리 영상이 업로드되는 동안 '동시에' 할 수는 없을까? 동시에 한다면 크리에이터가 영상을 업로드하는 동안 다른 일을 처리할 수 있어서 업로드 속도가 조금 더 빠르게 '느껴지지' 는 않을까?
이 같은 생각을 하는 것에 있어서 기술적인 지식이 선행되어야 하는가? 사실은 그렇지 않다. 기술적으로 가능할 수도 있고, 불가능할 수도 있다. 하지만, 이러한 아이디어가 있다는 것만으로도 해결책에 가까워진다는 것은 사실이다. 다만, 때때로 엔지니어들은 기술적인 것은 고민하지 않고 무작정 내뱉기만 하는 사람들에 대해 부정적인 시선을 내비치는 일도 있는데, 이는 사실 나도 그렇다. 경우에 따라서는 아무렇게나 던지는 의견이 게임 체인저가 되기도 하니 마냥 싫어할 일도 아닌 듯 싶다.
아이디어를 제시하는 것에는 기본적으로는 코딩이 필요하지 않지만, 적어도 코딩을 잘하는 사람들은 문제의 본질을 파악하고 해결책을 제시하는 것뿐만 아니라, 기술적인 구현 가능성 또한 가늠할 수 있다. 지금 당장은 기술적 이해가 없을지라도 적어도 문제를 다양한 관점에서 인지하고 해결책을 제시할 수 있다면 그 사람은 미래에 코딩을 잘하게 될 가능성이 높다.
그림을 그리다
우리는 어떤 것을 실행하기 전에 머릿속에서 개념을 그리고 상상하는 일을 할 수 있다. 머릿속에 그림을 그리는 일도 코딩에 대한 지식이 선행되는 것이 아니다. 간단한 예를 들어 회원가입을 구현해야 한다고 생각해보자. 적어도 이 단계에서 프로그래밍 언어와 프레임워크에 대한 생각은 무의미하다. 회원가입을 구현하기 위해 이메일과 비밀번호를 사용자에게 받는다고 가정하면, 이메일과 비밀번호를 서버에 전송해서 사용자의 관점에서 볼 때는 블랙박스인 '어떤 과정' 을 거치면 회원가입이 처리되고, 그 이후에는 로그인이 가능하다는 사실까지는 초등학생도 이해할 수 있는 수준이다.
'어떤 과정' 을 구현하는 것이 프로그래머가 해야 되는 일이자 백엔드인데, 회원가입에서의 '어떤 과정' 이란 이메일과 비밀번호를 서버의 저장소에 저장하는 것이 끝이다. 또 한 가지, 위에서 언급한 영상 업로드에 대한 예로 들어보면 동영상 업로드와 제목을 동시에 작성할 수 있도록 하려면 어떤 과정을 거쳐야 하는가? 일단, 어떤 기술이 필요한지는 잘 모르겠지만, 가장 먼저, 순차적으로 되어있는 업로드 과정과 제목 작성 프로세스를 병렬적으로 처리가 가능하도록 분리하면 되지 않을까? (기술적으로 더 나아가, 큐)
코딩을 잘하는 사람은 '어떤 과정' 에 대한 순서를 머릿속에서 빠르게 시뮬레이션하고 그리는 것이 가능하다. 그림을 그린다는 것은 때로는 서비스 전반을 관통하는 전체적인 설계가 될 수도 있으며 작게는 코드 레벨까지 내려갈 수도 있는 등 포지션에 따라 천차만별이다. 서비스와 제품을 만드는 개발자도, 시스템을 디자인하는 아키텍트도, 기술을 연구하고 사용하는 엔지니어도, 그저 동떨어진 머릿속의 상상에서 현실세계로 구현을 하기 전에 그림을 그리는 과정을 거친다.
코딩을 잘하는 사람일수록 그림을 그리는 속도가 빠르고, 재능이 있고 천재일수록 감히 평범한 사람이 범접할 수 없는 수준에 이른다. 천재가 아니어도 경력이 쌓일수록 빨라지는 것이 보편적이다. 경력과 신입의 차이는 그림을 그리는 속도와 규모가 다르다는 점이다. 만약 경력이 쌓였음에도 불구하고 신입 개발자와 크게 다르지 않다면 반성해야 한다. 반성해야겠다. 이는 코딩교육의 본질과도 연결되는데, 코딩을 교육할 때는 키보드에 손을 올리고 코드를 작성하는 것을 가르쳐야 하는 것이 아니라, 그림을 그리는 법을 먼저 가르쳐야 한다. 그림을 그리고 시작하면 개발의 생산성이 크게 향상된다. 직접 그리지 않더라도 강사가 그림을 그리면서 하면 배우는 입장에서 이해도 잘 된다. 알고리즘을 공부할 때 순서도가 중요하듯이 서비스를 만드는 일도 순서를 그리는 일은 중요하다.
그래서, 문제해결능력이 뭐야?
문제해결능력에 대한 정의는 사람마다 다르겠지만, 나는 이 글에서 문제해결능력을 문제에 대한 인지-대안-그림-구현이라는 모델을 적용해서 이야기하고자 한다. 실은 여기서 프로그래밍 언어와 프레임워크가 지대하게 영향을 미치는 부분은 사실상 '구현' 뿐이다. 하지만 '문제해결능력' 이 도대체 뭐냐고 물어보면 어째서인지 '구현' 만을 이야기하는 일이 있곤 하다. 결국 최종적인 단계인 구현을 마지막에 하기 때문이다. 그래서 사람들은 코딩을 배운다고 하면 언어와 프레임워크를 먼저 생각하는 경우가 많다. 코딩을 못한다고 하면 언어와 도구를 다루지 못해서 문제인 것이 아닌데 말이다. 그저 포토샵만 다룰 줄 안다고 디자인을 할 수 있는 게 아닌 것을.
문제를 인지하고 관점에 따라 해결책을 제시하며 그에 대한 순서를 머릿속에 그리는 일은 언어 및 프레임워크 같은 도구와는 크게 관련성이 없다. 이러한 주장에 대해 어떤 개발자는 "개발자는 정말 어려운 일이다. 단순하게 서비스를 하나 구현하는 것도 언어, 프레임워크, 알고리즘, 자료구조, OOP, 디자인패턴, 네트워크, 인프라와 같은 지식을 알아야 한다" 고 이야기한다. 이는 내가 과거에 이야기 했던 것들이기도 하고 부정할 의향은 없지만, 사실 나는 그냥 그런 것들도 그냥 구현을 위한 도구일 뿐이라 생각할 뿐이다. 단순한 기술적인 지식은 책에 나와있다. 하지만, 문제를 바라보고, 해결책을 제시하고, 그림을 그리는 일은 책에서 흔히 찾아볼 수 있는 것들인가?
'지금' 코딩을 잘하는 사람은 언어와 프레임워크를 비롯한 각종 도구를 잘 다룬다. 개발자로서 이는 당연한 일이며 상황에 따라 적절한 도구를 사용하는 것은 개발자의 덕목이다. 개발자가 도구를 쓰지 못한다는 것은 연주자가 악기를 다루지 못하는 것과 똑같다. 허나, '미래' 에 코딩을 잘하게 될지도 모르는 사람들은 적어도 '지금' 은 기술적 지식이 없는 것이 당연하다. 앞서 이야기했듯이 기술적 지식은 구현 영역에 불과하고 프로그래머를 직업으로서 가지기 위한 전제조건일 뿐이다. 기술적인 지식이 하나도 없는 사람이 추후 코딩을 잘할 수 있는가 없는가에 대한 가능성을 가늠하는 것은 기술적 지식의 문제가 아닐 것이다.
결론적으로 이야기하자면, 코딩에서의 재능과 능력이란, 빠르고 정확하게 문제를 인지하고, 해결책을 제시하며, 그림을 그리고, 언어와 프레임워크라는 도구를 써서 구현하는 것이다. 구현 이전의 세가지 단계에 대한 능력이 있다면, 도구를 잠깐만 배우더라도 얕게나마 구현이 가능해진다. 이것이 '현실세계의 문제를 기술적으로 해결하고 제품을 생산하는 일' 을 하는 공학의 본질이다.
