서문
개발의 세계에는 웹 개발자, 인공지능 개발자, 데이터 엔지니어, 인프라 엔지니어 등 많은 직업이 있다. 하지만 여기서 직업이 아닌 역할군의 의미로 분류되는 것이 있는데, 바로 코더와 개발자다. 이 주제는 상당히 까다로운 주제여서 자칫 논란의 여지가 될 수 있음을 잘 알고 있지만, 나 역시 개발을 수 년간 해보면서 느낀바가 다소 있기 때문에 이 글을 작성해보기로 하였다.
많은 개발자들은 코더가 되길 꺼려한다. 간단히 말해 코더는 말 그대로 코드만 작성한다. 기획, 설계, 테스팅, 배포와 같이 프로덕션 사이클에서 중요한 위치에 있는 것들에 대해서는 하지 않고, 구현 그 자체에 관심을 두고 있는 것이 코더다. 코더라는 말에는 비하의 의미가 섞여있기 때문에 많은 이들이 자신에 대해 이런 말을 쏟아내는 것에 대해 불쾌감을 드러내는 경우가 상당하다.
이 글에서는 코더가 아닌 개발자가 되려면 어떤 마음가짐을 가져야 할지를 고민해보는 시간을 갖는다. 논리력? 자료구조? 알고리즘? 수학? 아니다. 개발이라는 업(業)에 대한 이야기이며 개발자라면 가져야 할 것들에 대해 생각해본다. 만약 아래의 것들이 충족되지 못한다면 어느순간 코더로 전락할 가능성이 크다.
연차가 많다고 실력도 좋을까?
개발은 연차가 많다고 다 잘하는 것은 아니다. 신입사원이 10년차보다도 많은 연봉을 받을 수 있다. 그 말은 반대로 아무리 연차를 쌓아도 개발 실력이 나아지지 않는다면, 신입사원보다 낮아질 수도 있다는 이야기다. 업무의 프로세스가 시간이 지나서도 엇비슷해지거나 하나의 프로세스로 구성되는 작업에 대해 장인정신이 필요한 숙련도가 요구되어 누가 보기에도 장인이 만든 것은 다른 사람과는 다르다고 생각되는 직업군에 대해서는 웬만하면 연차가 쌓일수록 실력과 노하우가 늘어나는 것이 일반적이다.
그러나 개발업계는 수시로 변한다. 여러 갈래가 있지만 가장 변화가 심하다고 생각되는 부분은 웹 분야에서도 프론트엔드다. 프론트엔드 프레임워크는 수시로 새로운 프레임워크가 등장하며 시장이 요구하는 프레임워크도 달라진다. 프론트엔드 라이브러리를 평정하던 제이쿼리의 시대는 가고 리액트의 시대가 왔듯이 말이다. 만약, 수 년간 제이쿼리를 하고 제이쿼리에 대해 너무나도 잘 아는 사람일지라도 리액트를 새로시작하는 것은 초보자보다 조금 더 앞에 나아가 있을 뿐 결국 새로 공부해야하는 것은 똑같다.
그렇다면, 개발자로써 어떻게 하면 좋을까? 바로 공부하는 것이다. 공부라는 단어때문에 벌써부터 짜증이 몰려오는 경우도 많겠지만, 어느 개발 유튜버가 이야기했듯이 개발자는 늘 공부하는 직업이다. 무엇을 개발하냐의 따라 정도의 차이는 있더라도 변화하는 시대에 맞춰서 개발자도 성장할 필요가 있다.
클라우드 슈밥이 이야기했듯이 현재 4차 산업혁명 시대를 맞이했다. 인공지능과 데이터 산업의 가치는 나날이 상승했으며 블록체인, IoT, 자율주행 등은 이제는 입에 익을 정도로 많이 듣는 단어가 되었다. 우리는 이렇듯 변화하는 시대에 대해 발걸음을 맞춰서 나아갈 필요가 있는데, 공부하지 않고 제자리에만 있다면 시간이 지날수록 도태될 수 밖에 없다.
개발은 아날로그에 가까운 방식에 대해 선호하지 않는 경향이 있다. 그렇다고 아날로그가 필요없다는 이야기는 아니다. 그리고, 현재보다 시간이 더욱 지나서 다시 한 번 놀라운 기술발전이 일어난다면, 또 다시 우리는 공부해야 한다. 공부는 개발자의 숙명이며 떨어뜨릴 수 없는 불가분의 관계다.
프로세스의 혁신과 더 나은 코드
개발자가 알고리즘을 짜면서 겪는 문제는 시간 복잡도와 공간 복잡도와 같은 알고리즘이 갖는 효율성에 대한 문제다. 같은 문제를 해결할 수 있다고 한들, 어떤 코드는 더 빠르고 적은 공간으로 할 수 있다. 이는 알고리즘에 국한되는 문제일지도 모르지만 사실 개발에서 더 나아가 인생에 대한 전략적인 고민을 해야한다는 것을 의미한다. 코드를 구현하는 사람에게 있어 알고리즘의 효율성을 높히는 일은 중요하지만, 어떤 하나의 서비스를 기획하고 배포가 되는 그 과정까지의 사이클에 있어서 얼마나 프로세스의 혁신을 이루어 낼 수 있는지도 고민해야 하는 것이다.
애자일과 같은 다양한 소프트웨어 개발 방법론이 탄생, 테스팅과 배포 자동화를 위해 CD/CI 개념이 나타나는 등 프로세스의 혁신을 위한 노력이 개발자들 사이에서 여전히 이루어지고 있다. 하지만 프로세스에 있어 정답은 없다. 어느 때는 과거 아날로그 방식처럼 FTP 를 연결하고 파일을 배포하는 방식이 나을수도 있다. 개발자는 상황에 따라 유연해지는 것이 좋으므로 반드시 이렇게 해야한다거나 이것이 정답이라는 방식으로 접근하는 것은 유연한 생각이 필요한 개발자가 되기는 어려운 사고방식이다.
현재보다 더 나은 방식이 없을까? 지금 가진 문제점이 있다면 그 문제를 어떤 방식으로 해결할 수 있을까를 고민하면서 코드를 작성해본다면 더 나은 코드와 사용자 경험이 담긴 어플리케이션, 또는 서비스를 만들고 사람들에게 소개할 수 있을 것이라 생각한다.
개발자는 코더가 아니다
개발자의 길에 진입하려는 사람, 또는 개발자에 대해 잘 모르는 사람들은 대부분 개발자가 그저 코딩만 잘하면 되는 줄 알고있다. 애초에 미디어 상에서 광고를 할때도 코딩 학원이라고 하지 개발 학원이라고 하지 않는다. 코딩이라는 말에는 설계와 테스팅, 최적화 등을 포함하는 넓은 의미의 코딩과 그저 코드 자체를 작성하는 좁은 의미의 코딩으로 생각해볼 수 있는데, 사회에서는 좁은 의미로 이해하고 있는 경우가 많은 것 같다.
내 또래 컴퓨터공학과 친구들이나 개발에 진입하려는 사람들을 가끔 보다보면 코드를 작성하기 위한 이론들, 예를 들어 문법이나 객체지향, 함수형 프로그래밍 등의 개념은 알고 있는데 정작 코드 자체는 작성하지 못하는 경우를 보았다. 이미 코드를 작성하기 위한 이론적인 지식은 탑재가 되었지만 다른 것이 부족한 것이다.
바로 현실세계과 코드 작성을 잇는 매핑능력이다. 이론은 있으나 코드를 작성하지 못하는 사람들은 현실세계에 존재하는 문제나 개체를 코드로 옮겨 표현하는 것을 어려워한다. 프로그램을 알고리즘을 통해 구현하는 그 단계보다도 더 높은 단계에 있는 추상화 단계를 생각하지 않고 구현만을 먼저 고민하게 되어 문제가 된다.
주어진 문제가 있으면 어떠한 함수, 클래스, 프로퍼티, 메서드가 필요한가, 그들간의 관계는 어떻게 연결시켜 생각할 수 있으며 현실세계와 비교했을 때 객제치향의 상속과 인터페이스가 가지는 의미를 생각하여 어떻게 코드로 나타낼 수 있을지를 고민해야 하는데, 내부 구현부터 고민하고 있으므로 막히게 된다.
이러한 코드의 설계부터 시작해서 프로그램의 무결성 유지를 위해 테스트를 하고 배포를 일관성있게 진행하며 유지보수가 수월하도록 가독성있는 코드를 작성, 리팩토링, 더 나아가 사용자에게 불편하지 않도록 사용자 경험까지 고민해보는 과정을 모두 고민할 수 있어야 개발자라고 생각한다. 단순 코드만을 작성하고 구현하는 일만이 개발자가 하는 일의 전부는 아닌 것이다.
질문하는 것도 실력이다
너무 많은 것을 질문하거나 검색만으로도 나오는 질문의 경우는 안 하는게 약일 수 있다. 같은 개발자에게 질문했을 때 가장 야박한 대답은 검색을 해보라는 것이다. 그 만큼 검색을 하면 많은 정보가 나온다는 것인데, 하나부터 끝까지 질문만 하는 사람을 본 적이 있다.
어떤 코드가 동작이 되지 않는다면 다음과 같이 질문을 바꿔어보라. 지금 이런 프로그램을 작성하고 있는데, 그걸 이렇게 하고싶고 어떤 문제가 발생했고 해결을 위해 이러한 것을 시도해봤다는 사실을 질문을 받는 대상자에게 이야기해보자. 단순히 코드만 던져놓고 동작이 안 된다고 한다거나 검색도 안 해보고 질문만 던지는 행위는 주위사람을 괴롭히려고 하는 의도라고 밖에 생각되지 않는다. 또는 검색을 위해 문제에 해결에 대한 키워드를 물어보는 것도 좋은 방법이다.
구글과 같은 검색엔진이 있는 한 개발자에게 있어 검색 능력은 큰 힘이다. 실제로 알고리즘을 작성하는 실력이나 코드를 작성하는 능력자체가 떨어진다고 하더라도 검색을 통해 어느정도 극복이 가능하다. 검색이 누적되고 축적되면 어느순간 자기것이 되기 마련이다.
하지만 질문을 하기 전에 먼저 실험을 해보아야 한다. 질문을 받는 사람은 질문자가 해당 문제에 대해 얼마나 시도를 해보았는지 어느정도 직감적으로 알 수 있기 때문에 무작정 질문했다가는 상대방도 기분나쁘게 받아들일 뿐이다. 질문을 하기전에 먼저 작성해볼 수 있는 코드는 작성해보고 질문을 던지는 것이 더 나은 개발자가 되기 위한 길이라고 볼 수 있다.
기술보다, 먼저 무엇을 만들지 고민하라
이는 창의력과 관련된 문제로 생각될 수 있다. 예를 들면 내가 자바를 할 줄 안다고 생각해보자. 그러면 무언가 포트폴리오를 만들고자 할때 이런 생각을 먼저 해보기 나름이다.
내가 자바를 할 줄 아는데 이걸로 만들 수 있는 것은 무엇일까?
이래서는 멋진 프로그램을 만들기 어렵다. 나 같은 경우를 이야기해보자면, 무언가를 만들어야겠다 싶을 때 먼저 만들 것을 결정하고 그에 필요한 기술스택을 설정한다. 예를 들면 스트리밍 서비스를 만들고 싶다고 해보았을 때, 스트리밍 서비스를 만들기 위한 첫 번째 과정은 오픈소스 라이브러리나 프레임워크를 검색해보는 것이다. 물론 여기서 스트리밍 서비스 자체에 대한 기술적 이해도가 없는 경우라면 그것이 먼저 선행되어야 한다. 그런 다음 내가 할 줄 아는 언어에 대한 SDK 를 찾고 그에 대한 공식 문서를 보고 코드를 작성해보는 과정을 거친다.
개발자는 무언가를 만드는 직업이다. 도구를 먼저 생각하고 무엇을 만들지 고민하면 만들 수 있는 것에 제약이 있지만, 그 순서를 바꾸어 무엇을 만들지 생각하고 도구를 결정하면 벽이 어느정도 허물어지기 마련이다. 따라서 프로그래밍 언어에 대해 호불호는 가질 수 있지만 너무 집착을 가지는 것은 그다지 바람직하지 못하다. 프로그래밍 언어는 그저 프로그램을 개발하기 위한 도구일 뿐이다.
마치며
여기까지 내가 생각하는 코더가 아닌 개발자가 되기 위한 요소들에 대해 적어봤다. 개발 업계를 살펴보고 있으면 주니어 개발자는 넘치는데 3년차 이상 중급, 시니어 개발자는 많이 없는 것 같다. 그 만큼 신규로 개발자를 하려는 친구들이 개발자라는 직업에 대한 이해가 부족한 상태에서 진입하고 있기 때문이 아닐까 조심스레 추측해본다.
