아래의 글은 제가 9개월 동안 이곳에서 교육을 수강한 방식과 그 동안의 경험을 토대로 수강 후기 및 현역/예비 개발자 분들에게 도움이 될 만한 내용을 선별하여 작성한 것입니다.

◎ 교육 기관 : (주)미래능력개발교육원
◎ 수강 과정 : 안드로이드웹앱콘텐츠개발자양성 3기
◎ 담당 교수 : 이연 교수님

공부라면 할만큼 했지만, 나이도 적지 않고 학위도 없고 자격증도 없고 무엇 하나 갖춰진 것 없는 제가 마지막 인생의 기로에서 선택한 곳이 개발자 양성 교육기관인 이곳, 미래능력개발교육원입니다. 평소 IT 쪽에 관심이 많았고 독학으로 프로그래밍도 몇 년씩 해오긴 했지만, 어디까지나 취미로 생각하고 있었고, 과연 내가 학원을 다니더라도 원하는 성과를 얻을 수 있을까, 또 제공되는 교육 수준이 내가 제대로 배울 만한 내용이 있을까 하는 의문도 들었습니다. 이번에 취업을 하지 못하면 정말 모든 게 끝이라고 생각하고 있었던 터라, 교육기관을 고를 때 일부러 안정적인 취업을 위해서 교육과정의 절반 이상을 이미 알고 있는 곳을 골랐기 때문입니다. 하지만 실제 강의를 들으면서 이런 의문들이 모두 어리석은 것이었다는 걸 금방 깨닫게 되었습니다. 첫 강의부터 교수님은 굉장히 큰 목소리로 학생들이 잠잘 생각은 꿈에도 들지 않도록 만들어주셨고, 기초 지식과 심화 지식을 적절한 타이밍에 골고루 배분하여 알려주셔서 편차가 많은 학생들 모두 지루해하거나 힘들어하지 않도록 최고로 공들였다는 것이 굉장히 잘 느껴졌습니다. 첫 강의부터 ‘정말 잘 온 것 같다’라는 생각이 들었습니다.

처음 한 달 동안 배우게 될 파트는 C언어였는데, 저는 이미 C언어의 기초는 모두 공부를 마친 상태였습니다. 하지만, 교수님의 강의는 굉장히 몰입도가 높았기 떄문에 전혀 늘어지는 일 없이 수업에 집중할 수 있었습니다. 저는 알고 있는 것을 복습하는 느낌으로 들었기 때문에 내용에만 신경 쓰는 것이 아니라, 교수님의 강의 방식, 강의 내용 및 시간 분배 등 남들이 신경쓰지 않는 부분까지 캐치하려고 노력했습니다. 그렇게 강의를 쭉 듣던 어느 날 교수님의 강의 내용 중에 의문이 드는 부분이 있었습니다. 제가 알고 있던 내용과 교수님의 설명이 달랐던 것입니다. 언뜻 들으면 그럭저럭 맞기는 한데, 사실 내부 구조를 뜯어보면 그렇지 않은 경우. 그런데 교수님도 그렇게 말씀을 하시고는, “사실은 이게 아닌데…” 라고 말씀하시고 정확한 내용은 따로 있는데, 일단은 수강생들의 이해를 돕기 위해 이렇게 가르친다라는 말씀을 덧붙이시더군요. 주로 어려운 개념이나, 처음부터 모든 내용을 정확하게 말하기 곤란한 내용들에 대해서 비유법을 쓰시거나 조금 다르게 말씀하시고는 나중에 정정해주는 방법을 사용하셨습니다. 제가 ‘어, 내가 알고 있던 거랑 다른데?’라는 생각이 들 때나, ‘아니, 방금 설명하신 대로라면 이 구조가 될 리가 없는데?’라는 생각이 들 때면 대부분 “사실은 조금 다르다”라는 말씀을 설명 중에 덧붙여 주셨습니다. 그래서 저는 교수님을 믿을 수 있었고, 아는 내용은 복습을, 처음 배우는 내용은 그 내부 구조를 남들 이상으로 추론하며 듣는 것이 습관화 되었습니다. 그러다가 가끔씩, 제가 알고 있던 내용과 확연히 다른데 교수님이 그런 말씀을 안 하시는 경우가 있었고, 저는 교수님의 강의 내용을 신뢰했기 때문에, 반대로 제가 틀렸다는 걸 깨닫고 생각을 정정하며, 다시 그 정확한 구조를 추론하는 등의 과정을 지속할 수 있었습니다. (물론 내용의 진위성은 질문 및 검색을 통해 그때그때 모두 확실히 하고 넘어갔습니다.)

첫 파트에서 이런 과정을 겪고 나니까, 제가 공부하지 않았던 이후의 과정 (자바 및 안드로이드)에서 똑같은 방식으로 강의를 들으며 연역 추론을 하는 것이 일상화가 되었습니다. 교수님께서 비유적으로 말씀하실 때는, 실제 클래스와 메서드의 내부 구조가 어떻게 형성되어 있을지 추론하는 과정을 거쳤고, 여러 단계를 거쳐 설명하실 때는 한 단계 한 단계 들을 때마다 나름대로 그 구조를 머리속에 형상화 해보고, 단계를 거치면서 형상화했던 모습과 설명이 다를 경우 추론 방식에 문제점이 있음을 깨닫고 정정하는 등의 과정을 반복했습니다. 추론 과정을 반복하다 보니 자연스레 두뇌 회전이 더 빨라졌고, 이렇게 계속 하고 나니 이제는 클래스와 메서드 이름만 보면 그 안의 내용물을 단순 추측이 아닌 실제 한 문장 한 문장을 머리 속에서 써내려갈 수 있을 정도로 실력이 오르게 되었습니다. 이쪽 분야가 완전히 처음이라면 바로 이런 추론 과정을 거치기는 힘들 테지만, 그날그날 배운 내용을 가능한 한 완벽하게 복습하고, 거기서 그치지 말고 추가적으로 더 이것저것 생각해보는 시간을 갖는 것을 강력히 추천합니다.

한 파트가 끝날 때마다 개별 또는 팀 단위로 진행하는 프로젝트 기간이 주어졌고, 이때 저는 개발 중 다른 교육생들이 막히면 여기저기 도와주곤 했습니다. 여기서 정말 좋았던 것이, 내 코드가 아닌 다른 사람들의 코드를 여러 번 보다 보니까, 오류가 발생했을 때의 상황을 인지하고 그걸 프로그램의 실행 순서에 준해서 정확하게 포인트를 찾아가는 훈련이 정말 잘 되었습니다. 자바의 클래스를 예로 들 경우, ‘멤버 변수 선언부/초기화 블록/생성자의 실행 순서에 따라, 변수의 초기화 문제 등이 발생할 수 있고 그럴 때는 NullPointerException과 같은 예외가 발생할 수 있더라’ 라는 점 등을 자연스럽게 습득하고, 에러 로그를 보거나 상황 설명만 들으면 다른 사람의 코드도 웬만해선 바로바로 문제를 해결할 수 있는 수준까지 오르게 되었습니다. 거기에 나중에는 더 저레벨 언어인 어셈블리와 기계어도 독학으로 맛을 봐서, 디버깅을 할 때 소스 코드를 보면 그걸 기계어나 어셈블리 단위로 바꿔서 생각하는 능력도 생기게 되었습니다. 여기까지 오고 나니까 프로그래밍을 할 때 어떤 에러를 만나도 여기에서 발목을 잡힐 것 같다는 생각이 안 들게 되고, 애초에 코드를 작성할 때도 기계가 행하는 동작을 머리 속으로 시뮬레이팅 할 수 있게 되니까, 에러라는 것 자체가 잘 발생하지 않게 되었습니다. 기회가 된다면 내 코드가 아닌 다른 사람의 코드도 최대한 많이 보고, 무작정 실행해 보는 것이 아니라 먼저 결과를 예측한 다음에 실행해 보는 등의 훈련도 해보는 것이 도움이 될 것입니다. 아울러, 가능하면 저레벨에서 생각해보는 습관도 들이는 것을 추천합니다. 우리가 아무리 최신 프로그래밍 언어의 문법으로 작성한다고 해도, 결국 컴퓨터라는 것은 0과 1로만 소통하는 기계이며 그 소통이라는 것은 CPU라는 명령 처리 장치를 주축으로 하여, 메인보드를 매개체로 서로 다른 하드웨어 및 주변 장치 간에 데이터나 이벤트 발생 상황 등을 주고받는 것입니다. 각각에 걸리는 시간은 서로 다르며, 그것은 서로 다른 기계어 명령으로 구성되어 있습니다. 일반 소프트웨어 개발자의 경우 기계어나 어셈블리 레벨까지 갈 필요는 없지만, 내가 아는 한도 내에서 최대한 저레벨 언어로 바꿔서 생각해 보고 이러한 행위를 할 때 실제 하드웨어의 통신은 어떤 식으로 이루어질까도 한 번씩 생각해본다면, 코드를 보는 시야가 지금보다 넓어질 것입니다.

저는 문과 출신이고, 어렸을 땐 수학 공부를 어느 정도 했지만 나중에 갈수록 그러지 못 한 케이스였습니다. 수학이 싫지는 않은데 따로 시간을 투자하기도 좀 그렇고 해서 한동안 안 하다가, 프로그래밍을 통해 수학과 친해졌습니다. 학교에서 수업 시간에 배우는 건 교과 과정에 맞춰서 학습해야 하기 때문에 실제 활용 예를 찾아서 연관짓기가 어렵고, 배우는 루트가 정해져 있기 때문에 ‘왜 이런 게 필요한 것인가?’ 혹은 ‘이런 표현은 왜 탄생한 것일까?’ 라는 부분을 체감하기가 힘들며 필요에 의해서 하는 것이 아닌, 그냥 차곡차곡 쌓는 느낌으로 학습해야 합니다. 하지만, 프로그래밍은 다릅니다. 내가 수학 공부를 안 했어도, 어떤 알고리즘을 구현하기 위해 스스로 생각해야 하며 그 과정에서 자연스럽게 수학적 사고력이 생깁니다. 다양한 분야에 시도를 하면 할수록 여러 가지 알고리즘을 구현해야만 하는 상황에 부딪히고, 그를 어떻게든 극복해내기 위해 노력하다 보면 방법을 찾아내게 되고 찾아낸 방법을 좀 더 간소하게 다듬다 보면 결국 내가 공식을 창조해내는 결과도 나옵니다. 이런 과정을 한동안 거치고 나서 수학이라는 과목을 되돌아보면, ‘내가 어릴 때 수학을 왜 이렇게 공부했던 거지?’라는 허탈감에 휩싸이게 됩니다. 중요한 것은 탄생 배경과 그 원리 그리고 활용 방식이지, 공식 외워서 답 쓰는 게 수학을 잘 하는 방법이 아닙니다. 이런 사고력을 쌓은 뒤에 필요한 부분을 찾아서 정리하는 정도만 해도 프로그래머로서의 수학적 능력은 충분해집니다. 여기까지 끌어 올린 뒤에는, 시간이 허락할 때 이것저것 틈틈이 공부를 해서 완성도를 높여가는 작업을 해나가면 되겠습니다.

앞으로 어떻게 될지는 모르겠지만, 현 시점에서 능력 있는 개발자가 되길 원한다면 영어는 필수라고 생각합니다. 당장 영어를 잘 해야 될 필요는 없습니다. 소통 능력과 작문 실력은 별개로 치더라도, 단순히 영어를 읽고 이해하는 정도라면 누구나 노력하면 금방 실력이 오를 수 있습니다. 개발자에게 필요한 필수 영어는 변수/함수/클래스/메서드 이름 및 에러 로그 등을 보고 이해하며 분석할 수 있는 능력입니다. 편집기나 컴파일러 단위에서 한글을 지원하는 경우도 꽤 있지만, 개발자라는 것이 기본적으로 하나의 프로그래밍 언어 또는 한 분야만 할 가능성은 사실상 드물기 때문에, 어떤 환경에든 적응할 수 있는 능력이 필요합니다. 그렇기 때문에 최소한의 영어가 필요한 것이고, 일단은 정 영어가 안 되면 구글 번역 등을 활용할 수도 있는데 미흡한 부분은 보충할 수 있도록 스스로 노력해야 합니다. 개발 시에 쓰이는 단어는 IT 용어이다 보니 생활 영어와는 다소 차이가 있다는 점을 인지하시고, 일단은 에러 로그나 레퍼런스 페이지 또는 Stack Overflow와 같은 곳에서 설명해줄 때 보이는 단어들 위주로 익히고, 단어들이 어느 정도 보이면 문장 해석 능력을 높이는 방향으로 나아가는 걸 추천합니다. 읽기가 어느 정도 된다면 듣기까지 할 수 있으면 더욱 좋습니다. 좋은 구글링 결과가 대부분 영어로 검색해야 나오듯이, YouTube 등에 올라가 있는 상당수의 좋은 강의 자료가 영어입니다. 영어에 익숙한 사람이라도, 개발 쪽 용어를 모르면 이해가 되지 않으므로, 평소에 영어로 자주 구글링해서 주요 단어들을 익히는 습관을 가질 필요가 있습니다. 저는 독학하던 시절에 w3schools 홈페이지에서 웹 사이트 개발에 관한 용어들을 익혔고, Stack Overflow 검색, 좀 더 실력이 나아졌을 때는 영문 위키백과와 MSDN 원문 등을 보며 공부했습니다. 영어가 되면, 수용 가능한 정보의 양이 급격하게 차이가 납니다. 자동 번역을 이용할 경우, 문법적 오류가 발생하거나 해석 순서의 오판에 따른 완전 잘못된 설명이 나오는 경우가 종종 있으므로, 대략적으로 내용을 이해한 후 반드시 그걸 실험해서 내가 본 게 맞는지 검증하는 과정을 꼭 거치시기 바랍니다.

저는 이곳 미래능력개발교육원에 와서 그야말로 인생이 바뀌게 되었습니다. 실력적으로, 인성적으로 모두 발전하는 계기가 되었고 취직도 결정되어 개발자로서의 스타트 라인에도 서게 되었습니다. 정말 입이 딱 벌어질 만큼 대단한 강의를 해주시고 고민 상담도 친절하게 해주시고 곁에서 항상 도와주신 이연 교수님 다시 한 번 감사드립니다. 교수님께서 이끌어주시지 않았다면 지금 어떻게 되었을지 모르겠네요. 그리고, 언제나 웃는 얼굴로 맞이해주신 교육원의 임직원 분들 모두에게 깊은 감사의 말씀 드립니다. 같이 수강한 모두에게도 좋은 결과 있기를 기원합니다. 감사합니다.