프로그래밍 초보자들이 마스터해야 할 핵심 기둥

프로그래밍을 떠받치는 기둥들

나는 20년이 넘도록 프로그래밍을 해왔다. 그 동안, 나는 많은 사람들과 일하며 보람을 얻었고 그들로부터 많이 배우기도 했다. 갓 졸업한 대학생들하고도 일하기도 했는데, 그들에게는 선생이나 멘토가 되기도 했다.

최근에 나는 완전 초보자들에게 코딩을 가르치는 프로그램에 강사로 참여한 적이 있다.

프로그램을 어떻게 만드는 지 배우는 것은 어려운 일이다. 나는 종종 대학 과목이나 훈련기관들이 프로그래밍의 중요한 측면을 놓치고 초보자들을 가르칠 때 적절한 접근을 취하지 못한다는 것을 발견하곤 한다.

여기에서 나는 내가 성공적인 프로그래밍 교육의 기초가 되어야 한다고 여기는 다섯 개의 기본적인 기둥들을 소개하고자 한다. 늘 그렇듯이, 주류 웹 애플리케이션의 맥락에서 다룰 것이다.

초보자의 목표는 프로그래밍의 기초를 마스터하고 라이브러리와 프레임워크의 중요성을 이해하는 것이다.

클라우드, 운영 일반, 빌드 도구와 같은 윗 단계의 주제들은 커리큘럼의 일부가 되어서는 안 된다. 나는 디자인 패턴에 관해서도 회의적이다. 이런 것들은 초보자들이 해본 적이 없는 경험을 전제하기 때문이다.

이제 새로운 프로그래머들이 어디서 시작해야 할 지를 살펴보자.

테스트 주도 개발(TDD)

TDD는 어마어마한 이점이 있다. 안타깝게도, 이는 초보자들이 전혀 준비되어 있지 않은 상위 주제이다.

초보자들은 테스트를 작성해서는 안 된다. 이는 그들의 기본적인 기술 수준을 뛰어넘는 것이다. 대신해서, 초보자들은 테스트를 어떻게 사용하는 지를 배워야 한다.

프로그래밍 교육 과정은 연습에 중심을 둔다. 나는 단위 테스트를 동반하는 연습을 확장해서 학생들에게 테스트를 돌릴 수 있는 준비된 환경을 제공한다.

모든 학생들이 해야 하는 것은 코드를 작성하고 테스트 러너가 빨간 불에서 녹색 불로 바뀌는 것을 보는 것이다. 결과가 게임화되는 것은 좋은 부수효과이다.

예를 들어, 다루는 기술이 스프링이라면, 나는 스프링이 다루는 범위 안에서 연습과 테스트를 제공한다. 학생들이 스프링에 대해서 알지 못해도 괜찮다. 그들이 알아야 하는 것은 연습과 테스트를 실행할 버튼인 것이다.

이에 더해서, 학생들은 디버거를 사용할 수 있어야 하고 REPL(Read-Eval-Print Loop)을 잘 다룰 수 있어야 한다. 런타임 동안에 코드를 분석하고 작은 테스트를 놀이터처럼 여기는 것은 TDD에서 매우 중요하다.

중요한 점은 학생들이 핵심 프로그래밍 기술 다음으로 기본적인 TDD 행위들을 배우게 하지 않는 것이다. 나중에 습관을 바꾸는 것은 습관을 바로 익히는 것보다 훨씬 어렵다. 학생들이 처음부터 단위 테스트와 함께 지내야 하는 이유이다.

나중에 학생들이 전문가가 되었을 때, 그들은 단위 테스트가 없는 프로젝트에 반감을 가져야 한다. 그들은 직관적으로 단위 테스트의 부재를 안티 패턴으로 파악하여야 한다.

첫번째 기초

종종 나는 초보자들이 프레임워크로 바로 시작해야 한다는 이야기를 듣는다. 이는 사람들에게 운전을 가르칠 때 경주용 자동차에 앉혀 놓고 오버스티어링을 피하라고 하는 것과도 같다. 이는 그들이 브레이크와 스로틀을 혼동한다는 것을 무시하는 것이다.

앵귤러같은 프레임워크로 시작하는 것 또한 마찬가지이다. 초보자들은 프로그래밍의 기초를 먼저 이해해야 한다. 그들은 기본 요소에 친숙해져야 하고 남의 것을 사용하기 전에 코드를 작성한다는 것이 무엇을 의미하는 지에 친숙해져야 한다.

함수, 변수, 조건, 반복의 개념은 초보자들에게는 낯선 것이지만, 이 네 요소는 프로그래밍의 기초를 이룬다. 모든 프로그램이 이것들로 만들어져 있다.

학생들은 첫 시간에 이런 개념들을 배우지만, 가장 중요한 것은 학생들이 개념들에 익숙해지는 것이다. 만약 학생들이 기초를 마스터하지 못한다면, 그 뒤에 따라오는 것들은 마법처럼 보이게 될 것이고 이는 혼란을 유발시켜 학생들을 좌절하게 만들 것이다.

교수자들은 더 많은 시간을 이런 기초에 할애해야 한다. 하지만 슬프게도, 대다수는 너무 빨리 넘어가 버린다. 문제는 교수자들이 스스로를 학생의 역할로 밀어넣는다는 것이다. 그들은 다년간 프로그래밍을 해왔고 초보자들이 겪는 문제가 무엇인지를 잊어버렸다. 전문 경주 드라이버의 문제와도 같다. 브레이크를 밟기 전에 생각을 해야 하는 사람이 있다는 것을 그냥 자동적으로 하는 사람은 상상할 수 없는 것이다.

네가지 주요 요소들을 조합하여 나는 도전적이지만 합리적인 시간 안에 해결할 수 있도록 연습을 설계한다.

좋은 예는 로마자와 아라비안 숫자를 변환하게 하는 것이다. 이는 학생들에게 인내심을 갖게 하는 과제이기도 하다. 한번 그들이 네 요소를 사용하여 문제를 푸는 데 성공한다면, 그들은 커다란 동기 부여를 얻게 될 것이다.

기초는 중요하다. 되기 전까지는 넘어가선 안 된다.

라이브러리와 프레임워크

학생들이 코딩에 많은 시간을 들이고 나면, 그들은 대부분의 코드가 이미 존재하는 라이브러리나 프레임워크로 대체될 수 있음을 배워야 한다. 이는 패턴이라기보다는 사고방식에 가까운 것이다.

내가 이전에 썼듯이, 오늘날의 개발자들은 적절한 라이브러리를 찾아내고 고를 수 있다. 그들은 자신만의 버그 많은 버전을 짜내는 데 시간을 쓰지 않는다.

태도의 전회를 위하여, “기초 단계”의 예제를 Moment.js, Jackson, Lodash, Apache Commons처럼 잘 알려진 라이브러리로 대체하는 것을 보여주어야 한다.

이렇게 하면 학생들은 바로 라이브러리의 가치를 이해할 것이다. 그들은 복잡한 문제에 머리를 쥐어싸맷겠지만 이제 라이브러리가 문제를 즉시 해결해줄 수 있다는 것을 알았을 것이다.

TDD와 마찬가지로, 학생들은 동료들이 Redux를 대체할 수 있는 상태 관리 라이브러리를 직접 만들었다고 자랑하는 것을 의심해야 한다.

학생들이 라이브러리의 유용함을 이해했다면 프레임워크의 경우에도 이해하는 데에 별 문제는 없을 것이다.

교과정의 시간표에 따라 다르겠지만, 프레임워크에 시간을 투자하는 것이 어려울 수도 있다. 그러나 내가 이미 지적했듯이, 가장 중요한 측면은 학생들의 사고방식을 모든 것을 밑바닥부터 프로그래밍하는 데에서 라이브러리를 찾아내고 사용하는 것으로 바꾸는 것이다.

이 기둥에서 나는 어떤 툴을 추가하지는 않을 것이다. 숙련된 개발자들의 문제이기 때문이다. 이러한 초기 단계에서, 학생들은 도구들을 연동하고 설정하는 것을 배워서는 안 된다.

전문가와 견습생

20대 초반에 나는 피아노를 배우고 싶었다. 나는 독학을 할 수 있을 거라고 생각했고, 선생을 찾지 않았다. 그리고 5년이 지나서, 나는 전문 강사와 상담을 했다. 글쎄, 뭐라고 해야 할까? 나는 한달 동안 지난 5년간보다 더 많은 것을 배웠다.

피아노 선생은 내가 연주하는 동안 알아차리지 못한 실수들을 지적해 주었고 내가 결코 상상하지 못했던 해석의 문제들을 일깨워 주었다. 결국, 선생은 내게 기술적인 사람인 내가 도달하기 어려운 음악과 예술에 대한 사고방식을 심어 주었다.

프로그래밍에서도 마찬가지이다. 누군가가 프로그래밍 경험이 없다면, 독학은 좋은 선택이 아니다. 수많은 성공 신화가 있다고 하더라도, 나는 혼자 하는 것의 효율성을 문제삼지 않을 수 없다.

대신에, “전문가와 견습생” 관계가 있어야 한다. 처음에 전문가는 견습생에게 맹목적으로 따라야 할 규칙을 내린다! 전문가가 규칙에 대해 설명해줄 수는 있지만, 대개 그 이유란 견습생의 이해 저편에 있다.

이러한 내면화된 규칙은 안전망과도 같은 것이다. 벗어나 버린다면, 안전한 곳으로 다시 돌아와야 한다.

가르치는 것이 독백이 되어서는 안 된다. 전문가는 각각의 학생을 개별적으로 다루어야 한다. 전문가는 학생들이 어떻게 하고 있는지를 체크하고, 조언해주고, 진도의 속도를 조정해야 한다.

견습생이 일정한 숙련 단계에 도달하고 나면, 새로운 영역에 발을 들이도록 독려해야 한다. 이제 전문가는 “지혜”를 나누고 토론에 열려 있는 멘토가 된다.

도전과 동기부여

“페이스북 클론을 만들자!” 수많은 시니어 개발자들을 거느리고 수백만 유로의 예산을 가진 CEO가 하는 말이 아니다. 프로그래머 입문 과정에서 연습하기 위해 나오는 것이다. 이런 일은 사실상 불가능하다. 더 심각한 것은, 학생들이 스스로를 꿈의 세계에 밀어넣고 자신의 기술로 닿을 수 없는 저 너머에 닿을 수 있다는 착각에 빠지는 것이다.

교수자는 이를 분명히 알아채지만, 동기부여를 위해 그런 과제를 만들어 낸다.

과제의 주요 목표는 즐거움에 있지 않다. 과제는 특정한 테크닉에 중점을 두고 만들어져야 하며 학생들이 그 테크닉을 이해할 수 있도록 도와야 한다.

동기부여는 좋지만, 내용을 희생시켜서는 안 될 일이다. 프로그래밍은 쉽지 않다. 학생들에게 본질적인 동기부여가 없다면, 코딩은 아마 그의 길이 아닐 것이다.

초보자들은 전문 개발자가 된다는 것이 무엇인지를 경험해야 한다. 그들은 많은 시간을 투자하기 전에 무엇이 그들을 기다리고 있는 지를 알아야 한다.

예를 들어, 많은 비즈니스 애플리케이션은 복잡한 형태와 그리드에 중점을 둔다. 이를 만드는 것은 중요한 기술이며 이를 가능케 하는 것은 연습이다. 페이스북 비슷한 애플리케이션을 만드는 것은 당장 배울 것이 있는 학생들에게는 좋은 수업이 아닐 수 있다는 것이다.

비슷하게, 프로그래머가 아닌 사람은 개발자들이 하루에 몇줄 안 되는 코드를 작성한다는 것에 놀랄 지도 모르겠다. 오히려 코드를 지우거나 아무 것도 못하는 때도 있다.

어째서일까? 일은 언제나 틀어질 수 있기 때문이다. 우리는 단순히 글자 때문이었다고 나중에 알게 될 매우 이상한 버그를 고치는 데에 엄청난 시간을 쓴다. 어떤 도구는 라이브러리의 마이너 버전이 업그레이드 되는 바람에 작동하지 않을 수도 있다. 혹은 누군가 파일을 깃(git)에 올려놓지 않아 시스템이 멈출 수도 있다. 이런 일들의 목록은 계속 이어진다.

학생들은 이런 경험을 즐겨야 한다. 시간 제한 속에서 미지의 라이브러리를 연습하는 것이 제대로 하는 것일 수도 있는 것이다. ;)

살면서 항상 햇빛이 비춰지지는 않는다. 초보자들은 프로그래밍의 현실을 잘 대비하여야 한다.

마지막 조언

마지막으로 또한 중요한 것은, 2주, 두달, 나아가서는 일년 안에 전문 프로그래머가 될 수는 없으며, 시간과 인내력을 요한다는 것이다.

강사들은 서두르거나 가짜 약속을 해서는 안 된다. 학생들이 개념을 이해하는 지에 대해 초점을 맞추어야 하며 너무 서둘러서 넘어가면 안 된다.


원문: Rainer Hahnekamp(2018). The main pillars of learning programming — and why beginners should master them. freeCodeCamp.