코딩한 지 98일 째 깨달은 것들.
*TIL은 Today I learned의 약자다. 앞으로 TIL을 많이 올려볼 계획이다. 새로운 것을 배울 때마다 올릴 건데, 매일 올릴 수 있었으면 좋겠다.
나만의 프로그래밍 공부 커리큘럼 짜기라는 글을 쓴 게 5월 9일인데 그 이후로 한 번도 글을 작성하지 않았다. 반성하고 있다. 나는 게을렀다. 하지만, 오늘부터 다시 글을 열심히 써볼까 한다.
내 생각에 지금까지 글을 쓰지 못한 이유는 완벽한 글을 쓰려고 했기 때문이다. 뜻밖에도 지난 글이 공유가 상당히 많이 되어(현재 500에 육박하고 있다...) 다음 글을 쓰는 데에 부담이 생겼다. '갑자기 구독자들이 늘어났는데, 좋은 글을 쓰지 못하면 어떡하지...?'하는 불안감.
하지만, 나는 작가가 아니다. 그냥 내가 배운 것들을 공유하고 싶은 하나의 블로거일 뿐이다. 그래서 이제부터는가볍게, 대신 자주 글을 써볼까 한다.
오늘은 코딩을 시작한지 98일째다. 30분 밖에 못한 날도 있었고 595분이나 한 적도 있었는데, 자랑할 만한 점은 어쨌든 하루도 빠짐없이 코딩을 했다는 사실이다. 부끄럽지만 아래처럼 기록도 했다. 1pomo란 pomodoro라는 시간 관리 기법의 한 단위다. 스탑워치로 시간을 재면서 공부를 하는데, 공부를 시작할 때부터 집중이 흐트러질 때까지 시간을 재는 것이다. 집중이 흐트러지면 5~10분 정도 휴식을 취하고 다시 공부를 시작한다. 이 단위를 1pomo라고 정한 것이다. 보통 10시간 정도 앉아 있으면 3~5시간 정도 집중을 하더라. 내가 집중력 고자라는 것을 알게 되었다.(^^...) 공부를 손에 놓은 지 너무 오래되서 그런 것이다!
어쨌든, 나는 지난 3개월 동안 많이 변했는데, 3월의 나를 되돌아보면:
자바로 자료구조를 배우는 수업에서 이해가 1도 안돼서 드랍(수강취소)을 했다.
html, css의 기초적인 문법을 알고 있다.
C언어를 공부하기 시작했다. 처음이다.
딱, 비전공자스럽다. 그리고 현재의 나는:
C언어를 꽤 잘 다룰 수 있게 되면서 컴퓨터의 동작 원리에 대해 흥미가 생겼다.
자바, 파이썬, 자바스크립트 언어를 적당히 쓸 수 있다.
대학생 5명을(두 그룹) 대상으로 C언어를 기반으로 하는 컴퓨터공학 기초 수업을 진행하고 있다.
동아리에서 장고(파이썬) 프레임워크로 웹 프로그래밍을 배우고 있다. MVC 디자인 패턴과 HTTP에 대해 어렴풋이 이해하고 있다. html structure를 짜는 연습을 하고 있고, SCSS로 CSS를 DRY(Don't Repeat Yourself!)하게 작성해보고 있다. css UI 프레임워크인 bootstrap 4의 코드를 뜯어 보면서 공부하고 있다.
파이썬을 이용하여 크롤링을 할 수 있다. 크롤링을 이용하여 실제 세상의 문제를 해결하는 경험을 해봤다.
우아한형제들 테크 캠프의 코딩 테스트를 준비하려고 기초 자료구조를 공부했고, 응시하여 500점 만점에 400점 정도의 점수를 취득했다.(시험의 난이도가 평이했기 때문에 낮은 점수다. 쉬웠다고 생각했는데 틀렸더라. 역시 디테일이 생명.) 결국 떨어졌지만, 코딩 테스트를 응시해봤다는 것만으로도 소중한 경험이었다.
능력적인 변화도 많았지만, 가장 큰 변화는 내 최대 관심사가 '코딩'이 되었다는 점이다. 독서, 사람을 만나는 시간을 제외하고는 거의 코딩 생각만 한다. 친구들을 만나면 '아, 코딩하고 싶다.'라는 말을 습관적으로 뱉는다. 물론, 전략적인 행동이었다. 어떤 것이 하고 싶다고 자주 말하게 되면 실제로 그렇게 생각하게 되는 경향이 있기 때문이다. 그런데, 이제는 실제로 자꾸만 코딩이 하고 싶다. 지금도 글 쓸 시간에 코딩하는 게 나은데... 하는 생각을 하고 있다...
음. 사실, 여기까진 내 자랑이다.
어제 개발자 코스프레를 하려고 이브레인 HR 컨퍼런스에 갔는데(무려 5만 원짜리 컨퍼런스였다!), 토요일 아침 10시부터 오후 6시까지 지치지 않고 강연을 듣고 있는 개발자들이 빼곡히 들어선 공간의 에너지는 엄청났다. 자극이 되었다. 가장 좋았던 것은 애자일 컨설팅 김창준님의 강연이었다.
프로그래밍 학습에 있어서 학교식 학습의 효과에 대해 비판을 제기하셨다. 근거가 개인의 경험이 아니라, 저명한 연구들이라서 좋았다. 일반적으로 사람들은 자신의 경험을 갖고 조언을 한다. 물론, 이것이 도움이 될 수 있지만, 개인의 경험은 주관적일 수밖에 없다. 그에 반해 김창준 씨는 연구들을 갖고 설득력 있게 말씀을 해주셔서 신뢰가 갔다. 또한, 평소에 학교의 수업 방식에 대해 '이게 과연 가장 효율적인 학습 방식이 맞나?'하는 생각을 갖고 있었으므로 더 공감이 되었다. 감명 받아서 집에 와서 이 분의 인강(60,000원)을 구매해서 바로 들었다.(약 4시간 정도의 분량) 컨퍼런스에서 들은 내용 중 학습에 관련된 것과 인강 컨텐츠 중 기억에 남는 것을 요약해보면 다음과 같다. 나의 방식대로 해석했으므로 강사님의 컨텐츠와 조금은 다를 수 있다:
연차와 프로그래밍 실력의 상관관계는 없다. 입사 초기의 경력은 학습에 도움이 될 수 있지만, 그 이후에는 같은 일을 반복하는 경향이 있어서 연차만으로 실력이 향상되지 않는다.
학교식 수업은 공부하는 것에 대한 확실성이 높을 때 효과적이다. 하지만, 소프트웨어 개발은 불확실한 분야다. 회사에서 실제로 일을 해보면 책에 있는 내용 외의 문제가 발생한다. '상사님. 근데, 이거 책에 안 나오는 건데요?'라고 할텐가? (아마, 짤리지 않을까 싶다.)
순차적으로 학습하는 것은 학교식 방법이다. 우리는 어릴 때부터 학교 교육을 열심히 받아서 책을 처음부터 순차적으로 끝까지 공부하려는 경향이 매우 강한데, 그럴 필요가 없다. 필요한 부분만 찾아보면 된다. 예를 들면, 우리가 언어를 공부한다고 치면 대충 자료형, 조건문, 반복문 이런 식으로 목차가 나눠져 있다. 근데, 우리가 프로그램을 짤 때 조건문만 쓰는 경우가 있나? 없다. 그래서, 어떤 프로그램을 만들지 먼저 생각하고 그 프로그램을 만들기 위해 필요한 테마를 찾아보며 공부하는 것이 좋다. 목표가 있기 때문에 훨씬 재미있고 능동적으로 공부할 수 있다.
야생 학습이라는 접근이 필요하다. 야생 학습이란 무엇이냐. 우리는 '공부 == 책 읽기'라고 생각하는 경향이 있는데, 우리는 실생활에서 그렇게 공부하지 않는다. 이를테면 에어컨을 샀다고 해보자. 리모콘으로 에어컨을 제어할 때, 매뉴얼을 처음부터 끝까지 다 읽은 다음 리모콘을 조작하나? 아니다. 일단, 이것저것 눌러본 다음에 매뉴얼에서 필요한 부분만 보거나, 아니면 주변 사람들한테 물어 보는 방식으로 배운다. 소프트웨어 개발 공부도 이런 방식으로 해야 한다는 것이다. 책은 하나의 도구일 뿐이라고 생각해야 한다.
1만 시간의 법칙은 잘못 해석되고 있다. 그냥 1만 시간을 채운다고 해서 전문성을 가질 수 있는 게 아니다. 우리는 1만 시간 이상 걸어왔지만, 걷기의 전문가가 아니다. 중요한 것은 '의도적 수련'을 하는 것이다. 의도적 수련에서 중요한 것은 1. 잘 정의된 과제(잘했다 못했다의 기준이 명확한가) 2. 적절한 난이도(너무 어렵지도 쉽지도 않게) 3. 빈번하고, 명확한 피드백 4. 반복과 실수 교정의 기회(하나를 여러 방식으로 해보면서 의도적으로 실수하고 교정할 수 있는가)
공부에 왕도는 없다 라는 건 사실이 아니다. 교육학 연구(메타 분석)에 따르면, 비효과적인 공부법과 효과적인 공부법이 있다. 효과적 공부법을 나열해보면: 읽으면서 스스로 질문 던져보기, 시험 치기, 텍스트 보지 않고(책 덮고) 요약하기, 학습한 것과 기존에 알던 것과의 연관성을 말로 설명해보기, 여러 주제 섞어서 공부하기, 어떤 것을 공부할 때 그것을 다양한 방식으로 변형해보기, 의도적으로 실수하고 고쳐 보기. 공통점은 머리가 아파야 한다는 것이다. 쉽게 이해되는 건 공부가 잘 된다는 느낌이 들 수는 있어도 효과적인 학습 방법이 아니다. 대표적인 예로 밑줄, 하이라이팅이 있다.
학습 능력이 뛰어난 사람은 어떤 프로그램을 만들지 잘 설계해놓고 그 프로그램을 만들면서 학습을 한다. 처음부터 대단한 프로그램을 만들려고 하는 게 아니라 아주 간단한 프로그램을 만들고 그 프로그램의 기능을 하나 하나씩 개선해나가는 방식으로 공부를 한다.
하고 있는 것에 대해 구체적으로, 작게 쪼개서 시각화하는 것이 중요하다. 예를 들면, 태스크를 만들 때 '코딩하기' 보다 'django post application 데이터베이스 설계하고 모델 코드 작성하기' 라고 해야 지루하지 않고, 자기효능감을 느끼기에도 좋아서 학습을 더 잘, 지속적으로 할 수 있다는 것이다. 오늘도 '코딩하기', 내일도 '코딩하기'면 너무 지루하지 않겠는가? 그리고 작게 쪼갤수록 더 많은 것을 한 것처럼 느낄 수 있다. 실제로 무언가를 많이 하는 것보다, 많이 했다고 느끼는 것이 자기효능감에 있어 더 중요하며, 자기효능감은 학습의 지속성과 연관성이 높을 것이다.(이는 나의 생각이다.)
요약한다고 했지만 꽤 길다... 요약은 한계가 있으므로 직접 강의를 구매해서 보는 것을 추천한다. 6만 원 이상의 가치를 지닌다고 생각한다.
(8.22 추가) 강의에 대한 요약을 잘해준 글이 있어서 링크한다.
내가 지난 번에 쓴 포스팅인 나만의 프로그래밍 공부 커리큘럼 짜기 는 위의 방법들과 꽤나 대조적이다. 그래서 나는 그것이 효율적인 학습 커리큘럼이 아니라고 판단을 내렸다. 저 커리큘럼은 그냥 대학이 만들어놓은 '표준' 커리큘럼이다. 표준 커리큘럼이란 대다수의 사람들에게 보편적으로 나쁘지 않은 안전한 커리큘럼이라는 의미다. 즉, '개개인에게 가장 적합한 커리큘럼인가?'라는 질문에 대해선 확답할 수 없다는 것이다. 혹시나 내 포스팅을 보고 본인의 커리큘럼을 짜서 열심히 공부하고 계시던 분이라면, 비판적으로 재고해볼 필요가 있다. 뭐, 아직 어떤 분야의 개발자가 될 것인지 정해지지 않은 상황이라면 안전한 커리큘럼을 따라가는 것도 나쁘지 않다고 생각한다. 하지만, 나같은 경우에 염두하고 있는 분야가 있어서 내게 가장 적합한 방법을 찾아야겠다고 생각했다.
나는 웹, 앱, 게임 프로그래밍에 관심이 있고 현재 웹 프로그래밍을 공부하고 있다. 나는 어떤 분야에서 전문성을 얻고 싶을까? 게임은 아니다. 흥미는 있지만 생소한 분야라서, 효율적인 학습을 위해서는 원래 알던 분야를 공부하는 게 좋기 때문이다. 남은 것은 웹, 앱. 이 둘은 비슷한 분야에 속하므로 웹(앱) 프로그래밍의 전문성을 쌓기로 했다. 웹에서 세부적으로 들어가면 프론트엔드, 백엔드가 있는데, 나는 프론트엔드에 더 관심이 많다. 하지만, 프론트엔드를 잘하려면 백엔드 또한 공부하는 게 좋다고 생각했다. 내가 현업 종사자라면 우선순위를 잘 정해야겠지만, 학생이라 공부할 시간이 많아서 둘다 공부할 수 있다.(실제로 그러고 있기도 하다.)
그러면 나의 중장기 목표는 '웹 프로그래밍을 프론트엔드 중심으로 공부하는 것'이 된다. 이를 좀 더 세부적으로 쪼개고 싶다. 웹 프론트엔드 개발자에게 요구되는 기술은 뭘까? 이건 딴 얘기인데, 나는 들어가고 싶은 회사가 있는데, 그것은 '우아한형제들'이다. 우아한형제들의 프론트엔드 개발자 채용 공고를 참조한 뒤, 적절하게 공부 순서를 짜고 이를 전문가에게 피드백을 받으면 좋을 거라고 생각했다. 자, 채용 공고를 한 번 볼까.
음. 아는 것도 있고 모르는 것도 있다. 그래서 일단 잘 아는 것과 적당히 아는 것과 전혀 모르는 것을 구분하기로 했다.
잘 알고 있는 것: html
대충은 알고 있는 것: 웹 프론트앤드 개발 경험, css, javascript(ES6), Git & Github, HTTP, React.js, 가벼운 백앤드 서비스 개발 경험(Django) 및 Database에 대한 이해(RDBMS, SQL)
전혀 모르는 것: AWS, Grunt, Gulp, Webpack, Browserify, 단위 테스트, UI 테스트 자동화 및 배포 자동화 경험, 웹사이트 성능 측정 및 최적화 경험, 웹사이트 보안에 대한 이해
1. Grunt, Gulp, webpack, browserify는 배포 시에 빌드해야 하는 것들(js 모듈 번들링, minify, SCSS 등)을 자동화해주는 툴인 것 같다. node.js로 작동한다. 다음은 참고한 링크들이다.
2. 단위 테스트, UI 테스트 자동화 및 배포 자동화는 자바스크립트의 활용폭이 넓어지면서 테스트할 게 많아졌는데 그걸 일일이 개발자가 다 하는 건 개발자스럽지 못하므로 그걸 자동화하는 것을 의미하는 것 같다. 여러 도구들이 있더라. jasmin, chai, mocha, istanbul, JSCoverage 등등.. 참고한 링크들이다.
3. 웹사이트 성능 측정 및 최적화에 대해서는 야후가 공개한 성능 최적화 내부 노하우에 대한 인사이트를 정리한 네이버 기술 블로그의 글이 좋더라.
오오미 프론트엔드 개발자가 되기 위해선 공부해야 할 게 정말로 많다는 사실을 알게 되었다! 그리고 내가 모르는 것들은 대부분 DRY(Don't Repeat Yourself!) 및 성능 최적화와 관련된 것들이었다. 나는 아직 개발도 잘 못하기 때문에, 성능 최적화 같은 것은 별로 염두해두고 있지 않았나보다. 뭐, 앞으로 열심히 공부하면 된다. 또, 든 생각은 일을 하면서 실제로 운영되는 서비스를 갖고 학습하는 게 효율적일 것 같다는 생각이 들었다.
자, 이제 어떤 기술을 공부할지 다 파악했다. 일단, 대충은 알고 있는 것부터 공부를 할 것이다. 그것들을 다 공부하면 전혀 모르는 것 중에서 대충은 알고 있는 것이 생길 수도 있다. 반복하다보면 모든 걸 다 공부할 수 있지 않을까. 그렇다면, 각 기술을 어떻게 공부할 것인가? 공식 문서를 읽을까? 책을 읽을까? 강의를 들을까? 프로그램을 만들 것이다. 웹 서비스라는 프로그램을 만들 것이다. 현재 동아리 팀원들과 함께 진행하고 있는 프로젝트가 있는데, 그 프로젝트에 각 기술을 적용해보려고 한다. 어떤 서비스냐면 그건 배포할 즈음에 알려줄 것이다.(근데, 포스팅 과정에서 왠지 밝혀질 것 같다.) 처음부터 모든 기술을 써볼 순 없으므로, 단계적으로 각 기술들을 학습할 수 있도록 서비스 개발 과정을 설계할 것이다. 이는 학습을 위한 과제를 모델링하는 것이라 할 수 있겠다. 간단한 기능만을 수행하는 서비스에서 시작해서 기술을 하나하나씩 덧붙여 서비스를 개선해나가면서 학습을 진행할 것이다. 일단 재미가 있을 거고 야생 학습을 하기에도 좋을 것이다.
[웹 서비스 만들기]
프론트엔드
(1단계) html, 장고 템플릿 문법, bootstrap 4, 장고 url 패턴 디자인
(2단계) jQuery로 동적 페이지 구현(url 이동 최소화), bootstrap 4 css로 스타일링
(3단계) React.js, bootstrap 4 Scss로 스타일링
(4단계) React.js, Scss로 css 파일 직접 만들기
백엔드
(1단계) 기획한 서비스의 데이터베이스를 설계해보고 장고 모델(MVC의 모델) 코드 짜보기
(2단계) 장고 뷰(MVC의 컨트롤러)로 데이터베이스 이리저리 가공해보기
깃헙
(1단계) 브랜치, 머지 이용해서 협업하기
(2단계) 이전 커밋으로 왔다갔다 하기
데이터베이스
(1단계) 장고 ORM
(2단계) SQL 기본
일단 러프하게 나누면 이 정도다. 좀 더 세부적으로 나누는 건 작업을 해봐야 알 수 있을 것 같다. '전혀 모르는 것'들은 지금은 넣지 않았다. 아마 저것들을 다 공부한 뒤에 업데이트가 될 것이다. 자, 이제 무엇을 어떤 순서로 프로그램하면서 공부할지가 대충 정해졌다.
다음은 어떻게 의도적 수련을 할 것인지다.
잘했다 못했다의 기준을 어떻게 만들 것인가?
난이도가 적절한지 어떻게 알 수 있나?
어떻게 피드백을 얻을 것인가?
어떻게 의도적으로 실수를 반복하고 교정해볼 것인가?
흠. 잘 모르겠다. 일단, 코딩을 해봐야 감이 잡힐 것 같다. 그렇다면, 오늘은 여기까지만 하자. 이 정도면 꽤나 많이 했다. 직접 코딩을 해본 뒤에 의도적 수련에 대한 것을 정리해서 올려보겠다.
오늘 한 것을 요약해보면 다음과 같다:
1. 중장기 목표 설정: 웹 프로그래밍을 프론트엔드 중심으로 공부하기
2. 공부할 세부적인 항목 설정: 우아한형제들에서 웹 프론트엔드 개발자에게 요구하는 기술들 공부하기
3. 각 항목을 어떤 프로그램을 만들면서 달성할 것인가? 팀 프로젝트를 하며 웹 서비스 만들기
4. 각 항목을 어떻게 의도적으로 수련할 것인가? 아직 잘 모르겠다.
앞으로 어떻게 공부할지에 대한 밑그림을 대충 그려보았다. 이제 빨리 해보고 매일마다 기록할 것.