프로그래밍 강의를 시작한 지 1년이 지났습니다. 저는 강의를 하며, 수강생분들에게 제가 프로그래밍을 공부하며 어려웠던 부분들을 해결하는 여러 방법들을 (나름)최대한 쉽게 전달하려고 노력합니다.

(물론 많은 분들이 너무나도 어렵고 빠르다고 하지만…)

이번 포스팅에서는 프로그래밍이라는 분야에 대해 처음 접하는, 또는 알고는 있지만 자기 혼자 무언가를 만들어보지는 못한 분들에게 강의할 때 제가 중요하게 생각하는 것에 대해 정리해보고자 합니다.

프로젝트는 직접 하는 것

제 강의는 새로운 프로젝트를 생성하고, 원하는 기능을 몇 개 만들어서 실행해보고, 다시 새로운 프로젝트를 만드는 방식으로 이루어집니다. 특정 기능을 가진 프로젝트의 구현이 끝나는 시점마다 새 프로젝트를 만드므로, 모든 수업을 완료했으며 그 코드들을 전부 가지고 있다 해도 그 자체로는 어떠한 포트폴리오도 되지 않도록 수업을 진행합니다.

수업이 끝난 시점에서 곧바로 취업지원을 하는것은 불가능하지만, 저는 이 상태가 너무나도 당연하다고 생각합니다. 강사의 코드를 받아적으며 완성한 프로젝트는 아무 의미도 없으며, 동작 원리도 모르는 그럴싸한 애플리케이션은 자신이 만든 것이 아닙니다.

웹 프로그래밍을 할 수 있다는 자신감을 가지고, 해당 분야에서 일하기 위해서는 자신이 제로베이스부터 구현한 완성된 애플리케이션을 최소 하나나 둘 정도는 완성하는 것은 필수사항이라 생각합니다.

협업을 위한 기본 사항들

취업을 목표로 하든, 그렇지 않든 프로그래밍을 시작했다는 것은 결국 자신이 남의 코드를 보거나 남이 자신의 코드를 보거나 하게 됩니다.

프로그래밍을 처음 배울 때에는, 버전 관리 툴을 대체 왜 써야 하며, 커밋을 왜 실제 기능별로 세세하게 나눠야 하는지에 대한 이해도 부족했고, 어떻게 사용해야 하는지에 대한 감도 없습니다. 물론 이와 별개로 코드를 계속해서 개선해 나가는 것은 기분좋은 일이지만, 실제 협업에 들어가기 전까지는 코딩 컨벤션이나 버전관리 툴의 사용에 소홀하기 마련입니다.

하지만 미룬 것은 결국 기술적 부채가 되어 돌아오고, 한 번 자리잡힌 습관을 바꾸는 것은 쉽지 않습니다(제 얘기입니다). 그래서 매 최소 기능단위마다 이 단위에 이런 파일을 추가해서 커밋하고, 새 기능을 구현할 때는 브랜치를 만드며, 코드 한 줄을 작성하더라도 IDE의 소스코드 정렬 기능을 사용하는, 기본적이지만 사실 혼자한다면 잘 지켜지지 않는 습관들을 처음부터 들일 수 있도록 도와드립니다.

필요한 것은 검색과 문서, 그리고 소스코드에서

모—-든 기능들에 대한 설명서를 제가 만들 수 있다면야 문제가 없겠지만, 당연히 이건 불가능합니다.

처음에는 제 코드의 일부를 사용하는 것으로 여러 기능들을 만들 수 있겠지만, 시간이 지날 수록 배운 것과는 별개로 하고 싶은 것들이 생기고, 언젠가는 혼자서 필요한 내용을 방대한 인터넷에서 찾을 수 있어야 합니다.

수업때는 기능을 문서의 어느 부분에서 찾을 수 있으며, 또한 문서의 링크를 가져오기 위해서는 어떤 검색어를 사용해야 하는지 매 기능마다 함께 검색해서 찾아봅니다. 또한 기능의 구현에는 미리 만든 코드를 복사-붙여넣기(극혐…)하는 방식은 절대 사용하지 않으며, 문서의 가이드를 참조합니다. 만약 문서를 보고 해결하기 어렵다면, 실행가능한 코드를 검색해서 적용하지만, 적용 후 어째서 동작하는지는 다시 해당코드의 사용법이 적힌 문서를 찾아가거나 실제 라이브러리 코드를 읽으며 동작 원리를 파악합니다. (사실 이 과정에서 수강생 분들의 질문을 해결하기 위해 처음보는 소스코드를 분석하고 문서를 보다보면 저도 새롭게 알게 되는 것들이 생깁니다)

혼자 할 수 있지만 강의에서 얻는 것

프로그래밍은 유난히 다른 분야에 비해 “독학으로 충분히 가능하다”는 말을 많이 찾아볼 수 있습니다. 일명 삽질이라고 부르는 검색-시도-실패-재검색-시도-재검색-시도의 과정이 필요하기 때문이죠.

확실히 프로그래밍에 어떠한 문제든 한 번에 해결되는 마법같은 해결책은 존재하지 않습니다. 많은 경험을 통해 익힌 넓은 이해가 완전히 새로운 분야에 대한 접근에도 도움을 주는 형태라고 할까요. 추상적으로 표현하려니 어렵지만, 프로그래밍 실력은 누군가에게 족집게처럼 배워서 늘릴 수 있는 것이 아닙니다.

그럼에도 불구하고 강의를 수강했을 때 확실히 얻을 수 있는 몇 가지 이점이 있습니다.

먼저, 자신이 만들고자 하는 것에 대한 방향성을 얻을 수 있습니다. 프로그래밍에서 어떤 분야를 어떤식으로 공부해야 하는지에 대한 정보는 시시각각 빠르게 변합니다. 이미 해당 분야에서 활동중인 사람들은 해당 분야에 필요한 기술과 프레임워크에 대해 빠르게 파악하고 해당 사항을 자신의 업무나 프로젝트에 적용할 수 있지만, 프로그래밍을 처음 접하는 사람들은 너무나도 많은 기술들이 존재하기 때문에 무엇을 어떻게 공부해야 하는지 자체가 큰 혼란입니다. 저는 과거의 기술들과 지금 많이 사용되는 기술, 그리고 그 기술들을 위해 공부해야 하는 기반들에 대해 알려드려 어떤 공부를 해야 하는지에 대해 알려드립니다.

또 하나는 위에서 말한 ‘삽질’에 필요이상의 시간을 사용하는 것을 피할 수 있다는 것입니다. 어느정도 경험이 있는 프로그래머는 일정 시간이상의 삽질은 어떠한 식으로 커뮤니티에 질문을 했을 때 답을 얻을 수 있는지에 대한 감을 가지게 되지만, 그 이전에는 어떠한 질문을 해야되는지, 이 에러가 대체 무엇을 뜻하는지에 대해 알지 못하기 때문에 간단한 문제임에도 너무나도 많은 시간을 소비하고는 합니다. 프로그래밍에서 삽질은 반드시 필요한 과정이지만, 또한 효율적으로 넘겨야 할 과정입니다. 수강생 개개인들에게 발생하는 수많은 종류의 에러들을 함께 보고 해결하며, 어떤의미인지 함께 분석하는 과정은 수강생들이 삽질을 효율적으로 해결할 수 있도록 도와줍니다.

마치며

강의를 한 지 1년이 지났지만, 매번 여전히 어떻게 과정을 운영해야 할 지를 고민합니다. 컴퓨터공학 기반지식의 깊이, 알고리즘의 중요도, 수학은 어느정도를 기본적으로 알고 있어야 하며, 실제 업무에 사용되는 기술은 어느정도까지 구현을 도와주어야 하는지와 같은 여러 문제들에 대해서.

운이 좋게도 거리낌없이 이야기 할 수 있는 여러 프로그래머 친구들과 전 직장 동료들이 있어, 커리큘럼에 대해 주기적으로 논의하며 실무자들이 중요시하는 영역에 좀 더 비중을 두는 쪽으로 계속해서 과정을 개선하곤 합니다. 하지만 저를 포함한 모든 개발자들이 동의하는 사항은, 웹 프로그래밍이라는 큰 틀에 대해서는 빠르게 이해할 수 있도록 도와주되 자신이 코드를 작성할 수 있는 사람이 되도록 도와주어야 한다는 것이었습니다. 앞으로 강의를 진행하며 여러가지 기술에 대한 과정이 추가되겠지만, 지금은 이 원칙을 지키고자 합니다.