P-iknow(피아노)의 코드스쿼드 회고

codesquad logo 2019년 그리고 29살, 퍼포먼스 마케터였던 필자는 프론트엔드 개발자로 커리어를 시작하기로 마음먹었다. 그 결심으로 코드스쿼드라는 소프트웨어 교육기관에서 6개월(2019년 4월~9월)간 교육을 받았다. 이 글은 치열했던 그 기간에 대한 회고다. (사실 이 회고는 코드 스쿼드 수강 이후 계속해서 내용을 보강하다 8개월이 지나 공개되는 해묵은 후기이다. 회고에서 다뤘던 내용이 현실과는 다를 수 있다.)

1. 왜 코드스쿼드를 선택했나?

프론트엔드 개발자 커리어를 고민하며 독학 or 교육기관 수강을 고려했다. 그 과정에서 커뮤니티에서 코드스쿼드를 추천하는 글을 보았다. 그 글을 보고 코드스쿼드에 대해 더 알아보던 중, 더 나은 웹프론트엔드 과정을 고민하며 라는 글을 읽게 됬다.다른 기관이 "몇 개월 만에 취업", 연봉", "취업률" 이라는 키워드를 강조하는 것과 달리 소프트웨어 교육에 대한 진지한 고민이 묻어난 글이었다.(이외 YodCodd 미디엄 계정의 다른 게시물도 읽어보시길, ㅌㅇ 영상에서는 마스터 JK를 통해 코드스쿼드의 방향성과 철학을 엿볼 수 있다.)

당시 나의 목표는 "빠른 취업" 이 아니라 "스스로 학습하기 위한 토대를 갖추는 것"이었다.(제대로 배우면 취업은 알아서 따라온다고 생각했다) 미디엄 글을 통해 그리고 마스터즈코스 설명회를 통해 코드 스쿼드가 추구하는 교육 방향이 내가 생각하는 방향과 일치한다는 생각이 들었다. 내가 생각하는 방향이란 게 조금 모호한데, 단어로 구체화하면 "실전, 야생 학습, 회고, 협업, 피드백, 지속 가능성" 이 내가 코드 스쿼드를 생각할 때 떠올리는 키워드이다.

2. 내가 경험한 코드스쿼드

프론트엔드 마스터즈 코스의 수업 리뷰이다. 타 코스(IOS, 백엔드)의 수업은 경험해보지 않아 쓸 수 없다. 그러나 대체로 같은 방향성을 공유하는 모습이었다.

1) 방향과 중요도에 관한 수업 그리고 미션 베이스

일주일에 3시간 분량의 수업이 2번 있다. 코드 스쿼드의 수업은 특별했다. 내가 익숙한 수업 or 강의와 달랐는데, 개념을 A-Z로 일일이 설명하지 않았다. 수업에서 그 주에 달성해야 할 미션에 필요한 지식을 개괄적으로 소개됐고 간단한 예제를 통해 주요 개념이 구체화 됐다. 마치 개발 문서의 튜토리얼 같은 느낌이었다. 이 과정에서 미션을 하며 중요하게 생각해야 하는 부분이 언급되고, 왜 그것이 중요한지에 대한 내용이 다뤄졌다. 사실 수업이 끝나면 알쏭달쏭(?) 한 상태가 되는데, 미션을 하며 그 궁금증을 스스로 메꿔야 한다. 물론 해당 수업이 끝난 뒤 다음 수업에 미션을 진행하며 어렵거나 이해가 가지 않는 부분에 대한 Q&A 시간이 있었고(이외 시간에도 언제든 질문할 수 있었다. But 답변은 비동기(?)였다.), 아무리 검색해도 스스로 다루기에 벅찬 것들이 그 자리에서 논의되고 해결됐다.

실제 일할 때도 요구 사항만 주어진 채 스스로 문제를 해결해야 하는 상황이 많다. 미션 베이스의 학습 과정에서 미션이 요구사항이었다. 요구사항에 맞춰 문제를 해결하는 과정이 현업에서 일하는 방식과 유사했으며 친절하게 답변을 해줄 시니어가 있었다. 취업 이전에 일하는 방식을 경험하고 학습할 수 있다는 점에서 이를 좋은 학습 방법이라고 생각했다. 서두에도 언급했듯이 본인은 이런 방식의 학습을 추구했고 이런 방법을 선호했으나, 아직 개발이 너무 생소해서 기본 내용을 세세하게 전달하는 수업을 원하는 이들에게는 해당 강의 형식이 어렵고 불친절할 수 있다. 사전에 코스 설명회와 코딩 테스트, 면접이 있는 이유는 이 부분에 대해 조율을 하기 위함인 것 같다.

그리고 코드스쿼드는 특정 시기 마다 수업 난이도, 수업 방식에 대한 피드백을 요청하는데 해당 피드백을 반영하여 수업 방식과 방향이 바뀔 수 있는 곳이다. 수강생 뿐만 아니라 마스터들도 학습에 대한 학습을 하는 것이다. 실제 매 기수마다 커리큘럼이 조정되고 방향이 조금씩 바뀌는 것으로 알고 있다. 때문에 본인이 쓰는 시점의 코드스쿼드는 또 다른 코드스쿼드 일 수 있다.

2) 코드리뷰

"적절한 시기에 적절한 피드백", 성장에 있어 가장 중요한 환경이라고 생각한다. (그냥 내 생각인 것은 아니다. 창준님의 함께 자라기, 안데르스 에릭슨의 1만 시간의 재발견 등의 서적에서 피드백이 중요하다고 말한다) 여기에서 적절함이란 즉시성과 리뷰어의 피드백 대상에 대한 이해도를 말한다. 내가 어떤 미션과 코드 결과물에 대해 피드백을 받을 때 그 미션을 수행한 이후 바로 그 미션에 대한 피드백이 있을 때 효과적이다. 또한 리뷰어가 미션과 미션을 수행한 사람에 대한 이해가 높을수록 더 좋은 피드백이 나온다.

과정을 진행하며 미션 이후 하루 이틀 내에(주말이 끼면 더 오래 걸릴 수도 있다) 코드 리뷰를 받을 수 있었다. 미션 요구 사항에 부합하지 못하면 결과물을 보강하고 다시 리뷰를 다시 받을 수 있다. 마스터는 그 미션의 의도와 목표에 대해 잘 이해하고 있었기 때문에 적절한 피드백을 줄 수 있었다. 코드 스쿼드의 코드리뷰는 적절한 시기에 적절한 피드백이었다.

코드 리뷰에서 받았던 내용을 개선하며 코드의 품질을 개선할 방법들에 대해 많은 생각과 고민을 할 수 있었다. 리뷰 받는다는 사실 자체가 코드를 작성하는 시점부터 더 좋은 코드를 고민하게 하는 외부효과도 있었다. 리뷰 도중에 문제에 대해 추가적으로 고민해볼 주제를 전달받기도 했는데, 필요한 지식이 필요한 시점에 공급되어, 관련 주제를 좀 더 포괄적으로 다룰 수 있었다.

개인적으로 공부할 때는 이런 경험을 하기 어려운데 스터디를 구성해서 같은 문제를 풀고 서로 리뷰를 하면 혼자 공부하는 것의 단점을 해결할 수 있지 않을까? 생각한다. 리뷰의 이점을 리뷰하는 환경을 경험 히지 않고서는 알기 힘든데, 이 글을 읽는 사람이라면 꼭 한번 리뷰하는 환경을 구성하여 경험해봤으면 좋겠다.

3) 페어 프로그래밍

코드 스쿼드의 미션 중 동료와 페어로 해결해야 하는 미션이 있었다. 처음 페어 프로그래밍을 했을 때 낯설고 힘들기만 했다. 집중이 안 됐다. 문제 해결도 더뎠다. 하고 나면 진이 빠져서 오랫동안 지속하기 어려웠다. 또한 페어 각자가 가진 배경지식이나 이해도에 차이가 나는 경우 한 사람은 동료가 작성하는 코드를 멀뚱히 바라보고 있기만 한 경우도 있었다. 그런 경우 페어 프로그래밍이 아니라 1:1 강의가 되었다. 페어 초창기에는 그랬다. 그런데도 페어 프로그래밍을 지속해 보니 페어 프로그래밍의 장점이 있었다.

첫째, 그 사람만 알 수 있는 지식을 배울 좋은 기회였다. 페어를 하다 보면 동료가 사용하는 에디터 편의 기능, 자바스크립트의 특정 문법의 활용, 프로그래밍의 방법론 등을 지켜볼 수 있는데, 타인의 방법에 대해 질문하고 공유하는 과정에서 엄청나게 배웠다. 같이 페어하지 않으면 알 수 없는 꿀팁 들을 페어 프로그래밍 중에 많이 얻게 됐다. 잘하는 사람은 가르쳐주기만 하고 배우지 못할 것 같지만 잘하는 사람은 그 나름으로 자신의 알고 있는 지식을 타인에게 설명하는 과정에서 지식을 재조합하고 공고화 할 수 있는 기회를 얻었다. 실제 안다고 생각했던 것을 설명해보니 모르는 경우가 생길 때도 있었는데, 설명하면서 그런 부분을 보완해 확실히 알게됐다.

둘째, 커뮤니케이션 능력이 향상됐다. 같이 페어를 하다 보면 "내가 이 정도 말하면 알아들었겠지?" 했는데, 실제 상대방은 모르는 경우가 많았다. 그 과정에서 어떻게 소통해야 자기 생각을 더 잘 전달할지 고민했다. 매개체(노트, 의사 코드)를 이용하기도 하고, 관련된 블로그 링크나, 문서를 직접 작성해서 공유 했다. 그 과정에서 커뮤니케이션의 스킬을 높일 수 있었다. 회사에서 일해 보니 이런 소프트 스킬이 업무에 매우 큰 도움을 준다.

셋째, 빠른 주기의 피드백을 받을 수 있다. 페어 프로그래밍 중에는 하나의 함수, 코드 한 줄 단위로 피드백의 기회가 생겼다. 바로 옆에서 그 의도를 묻고 그 의도에 답하면서 생각 없이 작성하는 코드가 없게 되고 빠른 피드백 주기에 의해 코드의 품질이 높아졌다. (가끔은 이 정도만 해도 되지 않을까 하고 서로 타협한 적도 있는데, 다른 페어들의 코드를 보고 자극받아 처음부터 다시 짰다; ^^;) 특히 오류를 디버깅할 때 타인의 시선이 매우 큰 도움이 되었다. 혼자 하다 보면 아주 작은 실수들(변수명, 문법) 때문에 몇 시간을 낭비하는 때가 있는데, 페어로 할 때는 그런 오류들이 쉽게 발견되고 고쳐졌다.

4) 동료들 그리고 회고

위에서도 많이 언급했지만 마스터 말고 동료들한테 배우는 기회가 많았다. 막혀서 좌절할 때 동료의 도움으로 며칠 고민할 문제를 빠르게 해결했던 적이 많다. 물론 개발하며 마주하는 문제를 스스로 해결하는 능력이 중요하지만, 초기에는 어떤 키워드로 무엇을 검색해서 해결해야 할인지도 모르는 상황이 많다. 그런 상황에서 동료들이 큰 도움이 됐다.

코드 스쿼드 과정 6개월은 쉽지 않았다. 압축적으로 성장하기 위해 큰 노력이 필요했고, 노력과 비례해서 결과가 나오는 것도 아니어서, 실망하는 순간이 많았다. 그럴 때 마다 동료들이 서로를 격려했다. "괜찮다"라는 말을 서로에게 참 자주 했다. 서로 으쌰 으쌰 하는 분위기여서 힘든 순간들을 잘 이겨낼 수 있었다.

매일 아침(물론 점점 아침 출석률 저하로 아침 회고는 희미해졌다) 그리고 매주 마지막에 회고를 진행했다. 회고 시간에 개발 이야기만 한 것은 아니고 현재의 감정에 대해서도 많이 이야기했다. 이야기하는 것 자체로 마음이 편해졌고, 때때로 듣게 된 동료들의 격려와 응원이 따뜻했다. 또 회고 시간이 자신을 점검하는 주기가 되어 목표가 선명해졌다. 반성과 다짐의 시간을 보내면 다시 도약할 힘이 생겼다. 그래서 회고 시간이 좋았다.

5) 열등감 그리고 기록

필자는 컴퓨터 공학을 전공하지 않았다. 조금 늦게(29) 개발을 시작한 탓에 많이 불안하고 초조했다. 잘하는 동료들이 많았는데, 그들과 비교하며 "너무 늦었다.", "망했다"라는 생각을 자주 했다. 그 열등감이 과정 중 자신을 많이 괴롭게 했다. 마음을 잘 다스려 열등감을 연료 삼아 더 열심히 공부하려 노력했다. 그러나 열등감은 여전히 쉽게 극복이 안 되는 감정이었다.

조금 늦게 그리고 컴퓨터 공학을 전공하지 않은 상태로 개발을 시작하는 사람이라면 이 열등감과의 싸움이 힘들다. 비전공 개발자 류 콘텐츠에 잘 안 나오는 내용인데, 개발하면서 멘탈 관리는 매우 중요하다. 필자는 타인이 아닌 과거의 자신과 비교하려고 노력했고 그렇게 열등감을 조금씩 극복했다.

과거의 자신에 대한 기억은 희미하다. 잘 보이지 않아 비교가 어렵다. 비교하려면 분명하고 명확해야 한다. 그래서 기록했다. 목표와 결과 그리고 피드백, 그리고 피드백을 다시 적용한 결과에 대해 매주 블로그에 정리 했다. 그렇게 과거가 선명해졌다. (아래 4번째 chapter 시간 사용 및 학습 회고에서 그 선명함을 볼 수 있다) 과거가 선명해지면 자신과 비교가 가능하다. 기록을 통해 자신과 비교 하면 자신의 성장을 인지할 수 있다. 성장에 대한 인지는 큰 안정감이 되고 자존감의 근거가 됐다. (블로그에 작성한 회고들)

3. 아쉬운 점

CS(Computer Science) STEP은 강의로 진행되었다면 좋았을텐데..

과정 진행 중에 CS step 23이라는 병행 과정이 있었다. 각 step로 마스터가 선정한 CS 주제들과 주제에 관한 간략한 설명과 주제를 이해하는데 참고할 링크들이 정리되어 있었다. 또한 그 주제를 이해해야만 해결할 수 있는 미션이 주제에 첨부되어 있었다. 어렵고 고리타분한 CS를 문제 해결 방식으로 재편한 커리큘럼이 매우 흥미로웠다.

코드스쿼의 기획은 이랬다. "수강생들이 각 과정별(프론트, IOS, 백엔드) 23 STEP을 진행하며 CS step을 스스로 조금씩 진행한다. 전체를 다 마치지 않아도 된다. 하고 싶은 부분만 골라서 해도 된다. 여력이 될 때 한다."

초기에는 열정이 넘치는 수강생들이 CS step을 실제 병행했지만 5주가 지나자 아무도 CS에 관해 공부하지 않았다. 기본 step이 너무나 버거웠기 때문이다. 기본적으로 CS 주제 자체가 어려웠고, 그 어려운 것을 기본 step을 진행하며 시간을 내어 스스로 학습하는 것은 더 어려웠다.

그래서 CS step은 마스터들의 강의를 통해 다뤄졌다면 좋았을 것 같다. "그랬다면 일찍부터 CS step 포기하고, 각 주제에 접근조차 하지 않는 결과는 피할 수 있지 않았을까?", "그런 주제에 대해 들어는 봤다"라는 수준으로 인식의 범위를 넓힐 수 있는 기회를 얻지 않았을까?" 하는 아쉬움이 있다. (일하다 보니 그 주제를 어디서 들어본 적이 있다는 것은 문제를 인식하고, 정의하고 탐구하는데 참 많은 시간을 절약해 준다.)

서비스(프로젝트)를 경험하는 시간이 더 많았다면 좋았을 텐데..

미션 베이스로 과정이 진행되고 중간중간 페어 프로그래밍을 하는 시간이 있었으나. 그러나 그것은 실무의 방식과는 다소 거리가 있었다. 또 공통 step 이후에는 개인으로 진행하는 미션의 비중이 늘어 홀로 미션과 씨름하는 시간이 많았다. 그러다 보니 서비스 또는 프로젝트를 진행하며 마주치는 문제를 해결하는 경험, 그리고 그 과정에서 동료와 협업하는 방법들을 배울 시간이 적었다. 물론 과정 막바지에 마스터들은 이런 프로젝트를 하는 것을 권장하고 격려했다. 그러나 각 수강생의 나름의 사정과 스케줄로 팀 프로젝트를 진행하기 다소 어려웠다. 과정의 시간이 워낙 부족했지만, 동료들과 프로젝트를 진행하는 시간이 더 많았다면 어땠을까? 하는 아쉬움이 남는다

변하고 개선되는 코드스쿼드

지금 이 후기를 쓰고 있는 지금 본인의 코드 스쿼드의 과정은 물론, 그 다음 과정이 종료되었다. 슬랙을 통해 다음 기수가 진행되는 모습을 지켜보았다. 위에서 아쉬웠다고 말한 부분들이 최근 과정에 개선되어 반영되었다. 과정 초기에 아주 압축적으로 CS step에 대해 다루고, 그 다음 기본 step을 시작한다. 많은 미션들이 조별 프로젝트 형식으로 주어지고, 프로젝트가 끝난 뒤 데모를 한다. 협업하는 과정이 더 많아진 것이다. 코드 스쿼드는 계속해서 변화하고 개선되고 있다는 것을 느꼈다. (물론 그 변화로 인해 최근 과정을 종료한 수강생들이 느끼는 나름의 고충과 아쉬움이 있을 거라고 예상된다.)

4. 시간 사용 및 학습 회고

시간 사용 및 학습 회고

학습

학습 트리

학[學] > 습[習] 보다 습[習] > 학[學]

본디 학습은 배우고 익히는 것인데, 배우기만 하고 배운 것을 익히는 과정이 매우 부족했다. 이는 오래된 나의 학습 습관인데 개선이 필요하다. 안다고 생각하지만, 해당 내용을 실무에서 코드로 구현해야 하는 상황이 오면 막막해지는 때가 빈번했다. 익히지 않아서였다. ㅌㅇ 영상 중 우아한 형제들의 김민태 님이 의식적 반복이 매우 중요하다고 말씀해 주신 바가 있는데, 매우 공감한다. 내년에는 최대한 공부 주제에 대한 실습환경을 구축하고 코드로 구현하면서 공부하는 습관을 들이자. 눈으로만 쓱 관찰하는 공부는 에빙하우스의 망각 곡선에 무너진다. 최대한 글로 정리하고 코드로 구현하며 공부하도록 하자. 핵심은 "인출"이다.

선택과 집중

기본이 부족한데 저변을 넓히려고 했다. 이것저것 관심을 두고 읽었지만, 현재 기억나는 게 별로 없다. 당장 사용할 환경이 아니었기에 지속해서 학습할 수 없었다. 시간을 꽤 썼는데 성과가 없다. 이제는 좀 더 본질적이며 실무적인 공부에 집중해야 한다. 일단은 하나를 깊이 있게 공부한 뒤 차근차근 저변을 높이는 전략을 취하자. 회사에서 사용하는 REACT, JS, CSS를 자신 있게(명확하게 이해한 상태로) 다룰 수 있는 순간이 될 때까지 다른 분야의 학습은 자제(필요한 경우에 사용을 위해 공부하는 것은 OK)하도록 하자. 시간은 한정되어 있고 보다 중요한 것에 시간을 써야 한다.

학습 시간 구성

JS, REACT, HTML+CSS, 프론트엔드(특정할 수 없지만 프론트와 관련된 학습) 학습시간이 많았다. 결과적으로 현재 머릿속을 구상하는 지식이다. 더 많은 시간을 할애해 직접 실습했기 때문이다. 관련해서 블로그 글을 작성했던 부분은 오래 기억에 남으며 지금도 제대로 이해하고 있다.

이외에 컴퓨터 사이언스 관련 공부를 했지만, 의미 있는 성과를 거두지 못했다. 코드로 구현한 결과물이 없어서였다. 실체가 없다 보니 모호한 상태에서 학습을 유지했고, 더 어려워졌다. 구체성이 없는 학습은 지양하자. 특히 어려운 것을 학습할 때는 더욱 코드로 결과물을 만드는 학습 방법을 채택한다.

이외에 잡다하게 여러 가지를 시도 C/C++, 컴퓨터 구조, OS, HTTP에 관해 공부했으나 이 역시 의미 있는 성과를 거두지 못했다. 정리하지 않았고 또 지속해서 학습하지 못해서였다. 먼저 실무에 쓸 수 있으며 핵심적인 내용을 공부하도록 하자. 선택과 집중이 필요하다.

작성했던 블로그

들었던 강의

인프런 정재남 님의 Javascript ES6+ 제대로 알아보기 초급 + 중급
인프런 React 로 NodeBird SNS 만들기
생활코딩 리눅스 강좌
생활코딩 git 강좌 시리즈
벨로퍼트와 함께하는 모던 리엑트
코드스피츠 CSS, JS 강좌 다수

봤던 책들

최신 표준 HTML+디자인
CSS Missing Manual(40% 읽다 실패) → 전부 읽기 보다 필요한 부분을 우선적으로 읽자
Code, 찰스 펫졸드 (50% 읽다 실패)
자바스크립트로 하는 자료 구조와 알고리즘, 배세민(Sammie Bae) (20%)
자바스크립트 자료구조와 알고리즘, 로이아니 그로네르 지음, 이일웅 옮김
TCP/IP 쉽게 더 쉽게
하루 3분 네트워크 교실
읽기 좋은 코드가 좋은 코드다(재독 필요)
객체지향의 사실과 오해(90%)
손에 잡히는 정규 표현식
그림으로 배우는 Http & Network Basic - HTTP
OS가 보이는 그림책
인사이드 자바스크립트(재독, 뒷 부분 재 구현 필요)
Node js 교과서(40%, 추후 재 도전 필요)
리얼월드 HTTP(다 읽었으나 거의 이해하지 못함 Go 언어 습득 이후 재도전 필요)
모던 자바스크립트 입문(50% 재도전 필요)
Hello Coding 그림으로 개념을 이해하는 알고리즘

5. 코드스쿼드 이전

1) 이전에는 어떤 일을 했나?

2016년 11월, 6개월간 준비하던 지역인재 추천 전형 준비를 그만뒀다. 미래를 고민하던 찰나 개발자에 대해 막연한 동경을 했다. 끊임없이 학습해야 하는 환경(학습하는 시간을 즐기고 선호한다.), 실력으로 평가받는 문화, 성장을 중요하게 생각하는 사람들, 회고의 문화, 자율성, 뭔가 전문가의 느낌(?)이 내가 가진 개발자에 대한 환상이었다.

막연한 동경을 가지고 개발자가 되고 싶었지만 3개월간 개발 공부를 통해 인사담당자에게 "나를 채용해야 하는 이유"를 명확히 설명할 수 없었다. 3개월 뒤에는 당장 돈을 벌어야 했던 상황(당시 3개월 정도의 공부 기간을 버틸 자금이 있었기에 3개월이다.)이었다. 나를 채용해야 하는 근거를 만들기 위해 공부할 시간과 자금이 부족했다. 취업이 시급했다. 내가 시작 할 수 있는 일 중에 최대한 빨리 그리고 최대한 개발과 밀접한 곳에서 일하자고 마음 먹었다.

그래서 선택한 직무가 디지털 마케팅이다. 패스트 캠퍼스(코드스쿼드 회고 아닌가?) 디지털 마케팅스쿨 3개월 과정을 거쳐 디지털 마케팅 대행사에서 들어갔다. 다행이 처음 맡게 된 일이 웹 데이터 분석 컨설팅이었다. 해당 업무는 개발과 연관성이 있었다. 해당 직무로 1년 4개월 일했다. 웹 데이터 수집을 위해 GA, GTM 툴을 썼다. 해당 툴을 사용하기 위해서는 브라우저, DOM 구조, 이벤트, HTML, JS 지식이 필요했다. 당면한 문제를 해결해야 하기 위해 공부하면서 자연스레 프론트엔드 지식을 학습하게 되었다.

(필자의 전공은 행정학이다. 디지털마케팅 업에 뛰어들 때도 패스트 캠퍼스 디지털 마케팅 스쿨을 거쳤다. 이번이 두 번째 커리어 전환이다.)

2) 왜 개발을 시작했나?

학습하는 시간을 좋아한다. 오랫동안 고민하던 문제를 해결하는 순간에 오는 희열 때문이다. 배운 내용을 적용해 생산성 향상에 기여할 수 있는 환경은 더 좋다. (이 같은 효율 지향은 가정사로 인해 최소비용으로 최대의 퍼포먼스를 내야 했던 시절에 생겼다.) 개발자는 그런 일을 하는 사람이라고 생각했다. 비록 디지털 마케팅을 업으로 시작했지만 "기회가 되면 꼭 제대로 공부해서 커리어를 변경하자!!" 라는 생각을 마음속에 품어왔다. 커리어 전환(마케터 -> 개발자) 기간을 버티기 위한 돈을 모으며 때를 기다렸고, 그때 코드 스쿼드를 만났다.

3) 시작하기 전에 나는 어떤 상태였는가?

자바스크립트 기본 문법 정도를 알았다. 이론에 목매는 타입이라 결과물을 많이 만들어보지 않았다. 뭔가는 해야겠다는 생각에 JS 책을 무턱대고 읽었다. 퇴사할 당시에 3권의 JS 책을 읽었다. 그러나 요구사항을 보고 코드 한줄 쓰지 못했다. (당시의 학습 방법(책만 읽기)에 많은 문제가 있었다고 생각한다.) 퇴사 막바지에 코드스쿼드의 테스트를 통과하기 위해 나름의 수련을 했다. 쉬운 학습 과제들을 자주 반복해서 풀었다. 그 노력으로 겨우 코드스쿼트 테스트에 통과할 수 있었다.(+ 코드스쿼드 과정을 수강하기 위해 일련의 테스트를 거쳐야 한다.)

6. 코드스쿼드 이후

글을 읽으시면서 가장 궁금한 내용이 "코드 스쿼드를 통해 어떤 결과를 얻었나?"에 관한 내용일 것이다. 간단히 요약하면, 자바스크립트에 대한 이해도가 높아졌다. 시간을 많이 들인다면 간단한 라이브러리(예를들면 redux)의 코드를 분석 할수 있는 역량이 생겼다. 그 역량으로 문제 해결에 필요한 지식을 스스로 습득할 수 있게 됐다. 애초에 코드스쿼드에서 목표했던 바가 스스로 학습할 수 있는 역량을 기르는 것이었고 그것을 충분히 달성했다.

보통 이런 회고에는 드라마틱한 성장과 유명한 회사 취업이 동반되기 마련이다. 아쉽게도 비 전공자 기준으로 6개월은 짧은 시간이었기에 타인이 보기에 드라마틱한 성장은 없었다. 필자가 느끼기에 딱 6개월의 시간 동안 노력한 만큼 성장했다. 시간이 지난 지금도 배워야할 내용이 산더미고 아직 부족한 점이 많다. 물론 코드 한줄이 힘들었던 필자에게는 개발자로 커리어를 이어갈 수 있게 되었덨 큰 도약이었다. 이야기가 다소 두루뭉실 했는데 구체적인 결과가 궁금하다면 블로그의 about page(일종의 이력서)를 참고하시면 좋겠다.

7. 마무리 하며

개발을 시작하기로 하거나, 교육기관 수강을 고민할 때, 그 고민 자체가 무척 괴롭다. 교육기관 수강을 고려하는 대다수가 커리어의 방향 자체를 바꾸는 거대한 결정을 하는 중이고, 그런 결정은 너무 거대해서 쉽게 하기 어렵다. 거기다가 결정을 위해 살펴본 개발 커뮤니티에는 개발자의 삶에 대해 무서운 이야기(SI 개발자)가 가득하다.

그럴 때는 너무 고민만 하지 말고 실제적이고 구체적인 경험을 해보는 게 좋다. 교육기관이 궁금하다면 인터넷으로 후기만 검색하지 말고 교육 기관이 주최하는 설명회에 가서 직접 질문하고 답변을 듣자. 필자도 설명회나 코드스쿼드를 졸업한 수강생의 이야기를 들었던 경험이 결정에 많은 도움을 줬다.

코드 스쿼드 선택 당시에 수강생이 직접 쓴 회고가 많지 않아서 아쉬웠다. 충분한 정보가 있을 때 더 좋은 선택이 될 수 있는데, 이 회고가 중요한 결정을 내리는 누군가에게 도움이 됐으면 좋겠다.