서문
이번에 이야기하고 싶은 것은 개발자가 지양해야 할 공부법이다. 지향이 아니라 지양임을 다시 한 번 확인하자. 모두가 알다시피 공부법은 사람마다 다르기에 어떻게 공부해야 한다는 것보다도 어떤 공부법은 지양하는 것이 좋다는 것을 쓰는 편이 좋다는 생각이 들었다.
함수와 메서드 원형 및 목록 외우기
책을 보다보면 함수 및 메서드 목록이 몇 가지 수록되어 있는 경우가 있다. 그리고 그것을 마치 영어단어 외우듯이 공부하는 경우를 본적이 있다. 함수에는 함수를 사용하는 방법, 함수가 무엇을 리턴하고 어떤 것을 입력값으로 받는지에 대한 내용이 포함되어 있는데 이것을 몽땅 외우는 것이다.
프로그래밍 언어의 함수는 영어 단어와는 다르다. 우리가 알아야 할 것은 그저 함수의 이름 및 해당 메서드 및 함수가 어떤 패키지에 포함되어 있는지, 그것은 언제 사용하는지만 알면 된다. 그럼 매개변수와 리턴값은 어디서 볼까? 그건 바로 해당 언어의 공식 내장함수 목록이나 사용하고자 하는 라이브러리 및 프레임워크의 API 문서를 보면 된다. 프로그래밍을 하면서 코드를 작성하는 일 이외에 하는 것은 검색, 그리고 공식 문서 보기다. 각 언어의 공식 홈페이지에는 패키지와 함수에 따라 사용법과 함수 시그니처가 포함되어 있으므로 외울 필요는 없다.
위의 문서는 내가 현재 익히고 있는 Go 언어의 내장 패키지와 함수 및 메서드 목록을 확인할 수 있는 문서다. 이러한 문서를 참고하여 함수 시그니처를 확인하면 된다. 만약 json 으로 인코딩 하고 싶다면 어떨까? 그렇다면 encoding 카테고리에서 json 패키지를 찾아서 할 수 있다. 여기서 Encoder 라는 타입을 찾아보면 아래와 다음과 같다. 보면, 함수의 시그니처와 코멘트가 달려있는 모습을 볼 수 있다.
문서에서 내가 원하는 기능을 얻기 위한 핵심은 키워드를 찾는 것이다. 키워드를 알고 있다면 함수나 메서드를 외울 필요가 없고 그저 문서에서 보면 된다. 능력이 된다면 함수 시그니처를 외우는 것은 상관없겠지만, 만약 시간이 없다거나 기억력이 눈에 띄게 좋은 경우가 아니라면 함수와 메서드의 시그니처는 외울 필요가 없다. 공식 문서만 보더라도 다른 사람에게 질문해야 할 건덕지가 많이 사라지는 것을 느낄 수 있을 것이다.
프레임워크를 위해 언어 공부하기
자바/스프링, 자바스크립트/리액트. 둘의 관계는 언어/프레임워크, 언어/*라이브러리의 관계다. 그리고 둘 다 모두 시장에서 사랑받는 친구들이다. 개발자 진입하려는 일부 사람들을 보면 다음과 같은 루트를 거치는 경우가 있는 것 같다. 백엔드 개발자로 취직하고 싶은데 시장에서 가장 많이 쓰이는 것은 스프링 프레임워크고 그러려면 일단 자바/코틀린을 공부해야 한다며? 라고 말이다.
*리액트는 공식 홈페이지에 가면 라이브러리라고 되어있지만 웹 프레임워크라고 이야기하는 문서들도 많으니 너무 용어에 얽매이지 말자.
스프링 프레임워크에 초점을 맞추고 자바/코틀린은 그저 스프링 프레임워크를 위한 도구로만 여기며 언어를 공부하는 이러한 접근은 완전히 주객전도된 것이다. 만약 스프링 프레임워크를 벗어나 새로운 프레임워크를 만나거나 논프레임워크 환경에서 새로운 프레임워크를 구성하고 싶을 때는 과연 어떨까? 해당 언어에 대한 이해가 부족한 상태에서 이러한 일을 처리할 수 있을까? 아마 어려울 것이라고 생각한다.
프레임워크는 어디까지나 언어를 사용하여 구성한 틀에 불과하다. 프레임워크 이전에 언어가 있으며 그에 대한 기초가 있다면 자기만의 프레임워크를 구성하는 것도 문제가 되지 않는다. 프레임워크를 익히기 전에 언어에 대한 이해가 우선이다.
단순 문법 수준에 그치는 것이 아니라 언어의 설계자가 어떤 의도를 가지고 해당 언어를 이렇게 구성하고자 했는지를 파악하고 그것이 어떠한 형태로 사용될 수 있는지를 고민한다면 논프레임워크 환경이 되었을 때도 당황하지 않을 수 있다. 따라서 언어보다 프레임워크를 먼저 생각하는 것은 지양하고 언어에 대한 이해가 선행될 수 있도록 해보자.
코드를 똑같이 따라만 치기
클론코딩 프로젝트 진행시 많이 실수중 하나는 코드를 따라만 쳐서 실행은 가능하게 해도 정작 해당 코드가 어떤 이유로 인해 그렇게 동작하는지는 모른다는 것이다. 여기서 내가 말하는 클론코딩은 다른 사람이 작성한 코드를 그대로 따라서 타이핑하는 것을 말한다. 클론코드에 대한 공부법은 또 다른 글인 당신의 클론 코딩, 안녕하신가요? 를 참고하자.
해당 로직이나 알고리즘을 실행하는 코드에 대한 이해 없이 그저 작동하는 것으로만 넘어가게 된다면 그건 제대로 공부가 되지 않았다고 이야기할 수 있다. 우리가 언어를 배울 때 언어의 설계자가 왜 이렇게 언어를 구성했는지 이해하는 것 처럼 클론코딩을 할 때도 원본 코드의 작성자가 어떤 의도를 가지고 이렇게 구성했는지를 이해하는 것은 상당히 중요하다.
그래야만 나중에도 혼자 어플리케이션을 만들 때 써먹을 수 있기 때문이다. 가장 나쁜 예시중 하나는 블로그에 있는 소스코드를 그대로 복사 붙여넣기 한 다음 코드를 분석해보거나 이해하려는 노력하나 없이 코드를 실행해보고 안 되면 누군가에게 질문을 던지는 것이다. 이 코드를 정말 내 것이라고 말할 수 있는가? 코드에 대한 이해없이 그저 어떻게든 작동만 되게 하고자 하는 것은 더 나은 개발자가 될 수 없게 만드는 벽이다.
직접 코드를 작성하지 않고 머리로만 이해하기
코드를 똑같이 따라만 치기의 주제와는 상반되는 이야기다. 예를 들어 책이나 인강을 통해 공부를 할 때 대부분은 예제코드가 있기 마련이다. 그런데, 그러한 예제코드를 머리로만 이해했다고 해서 넘어가면 직접 손으로 짜야할 때 애먹을 수 있다. 직접 손으로 코드를 타이핑하고 이해를 하면서 넘어가는 것과 손은 가만히 놔둔채로 머리로만 이해하고 넘어가는 것은 질적으로 전혀 다른 이야기다.
예전에 친구에게 C언어를 단기간에 알려줄 때 이러한 것을 목격했다. 머리로는 이해했지만 정작 문제를 주고 코드를 작성해보라고 했더니 손이 움직이지 못했다. 오히려 가르치면서 코드를 짜고 설명한 내가 더 공부가 되었을 정도. 이렇게 되고 싶지 않다면 앞에 컴퓨터나 코딩을 할 수 없는 환경과 같은 제한적인 상황을 제외하고는 예제를 직접 손으로 작성해보지 않고 넘어가는 것은 지양하도록 하자.
언어의 문법과 이론만 공부하기
여기서 말하고자 하는 것은 분명하다. 문법과 이론공부만 하지말고 프로젝트를 시작하라는 의미다. 문법과 이론만 알아서는 프로그램을 만들어낼 수 없다. 내가 공부한 문법과 이론을 어떤 상황에 어떻게 적용하는지를 공부하기 좋은 것이 바로 프로젝트를 해보는 것이다.
이는 사람마다 순서가 조금씩 다를 수 있는데, 어떤 사람은 언어에 대한 깊은 이해보다는 튜토리얼을 통해 간단하게 언어를 익히고 프로젝트를 먼저 해보며 실무적인 감각을 익혀보기도 하고 어떤 사람은 책을 먼저 보고 언어에 대한 이해를 조금 더 깊게 한 후 프로젝트를 하기도 한다. 나는 후자에 속하지만 전자처럼 한다고해도 큰 문제가 되진 않는다.
그러나 계속 책만 보거나 기본적인 코드만 작성해본다면 실력을 늘리는 것에는 한계가 있다. 설령 언어에 대한 이해가 부족하더라도 프로젝트를 하면서 이해를 해나가면 된다. 처음부터 언어를 완벽하게 이해할 수는 없으며 애초에 프로그래밍 언어는 마스터하는 것이 불가능하다.
라이브러리와 프레임워크 정복 시도하기
또 다른 경우는 취직이나 개발 업계에 뛰어들기 전에 너무 많은 공부를 하려고 하는, 일종의 준비과정이 너무 많은 경우를 말한다 과유불급이라고 하던가. 사실 이는 준비과정이라고 할 것도 없다. 단 하나의 언어만 하더라도 세상에 존재하는 모든 라이브러리와 프레임워크에 대해 통달하는 것은 불가능하다. 하루에도 수십 수백개의 라이브러리가 등장한다. 이러한 것을 모두 알 수는 없다.
개발자는 성장이라는 가치를 크게 여기는 직업이다. 갖춰진 상태로 개발자가 되는 것은 성장과는 맞지 않는다. 누구든 처음에는 미숙하다. 어떤 라이브러리가 있는지, 프레임워크를 어떻게 사용하면 좋을 지는 회사를 다니면서 익히면 된다. 그렇다고해서 백지상태로 가거나 기본조차 안 된 상태에서 가는 것은 허용하지 않는다.
여기서 기본의 범위에 대해 논의가 될 수 있는데, 내가 생각하는 기본은 최소한 자신이 하는 언어에 대한 이해가 명확하며 다른 언어를 배우는데 막힘이 없고, 컴퓨터 공학 지식이 있으며 새로운 것을 배우려는 의지가 있는 상태를 말한다. 처음부터 너무 많은 것을 하려고 하는 것은 사람을 지치게 만드는 원인이다. 많은 것을 알고 공부하면 좋긴하지만 그렇게 되기란 쉽지않다.
자바를 사용하는 백엔드 개발자가 되기 위해 자바/코틀린, 스프링/스프링 부트는 어느정도 알아야 하지만 보안, 네트워크, 도커/쿠버네티스, AWS, 디자인 패턴, 아키텍처와 같은 사항은 공부해보면 좋지만 처음부터 깊게 알아갈 필요는 없고 그렇게 하려고 했다가는 지치기 마련이다.
수 많은 라이브러리와 프레임워크를 익히다가 그만 지쳐서 개발을 그만두는 일이 없길 바래본다.
마치며
이 글은 내가 프로그래밍 언어를 공부하고, 다른 사람이 언어를 공부할 때 느끼는 것들에 대해 지켜보면서 내린 결론이다. 책을 보든 인강을 듣든 프로젝트를 하든 그 어떠한 공부법도 상관없지만, 적어도 위에 나열한 것들에 대해서는 공부법에 상관없이 지켜져야 하는 공통요소이기 때문에 처음 개발을 공부하고자 하거나 지금까지의 개발공부에 대해 돌아보고 싶다면 위에 나열한 것들을 되돌아보도록 하자. 이는 스스로에게 하는 말이기도 하다.
