layout: post
title: "우테코에서 찾은 나만의 효과적인 공부법"
description: "우테코를 통해 찾은 학습법에 대해 공유합니다."
author: woniee
date: 2020-06-24 09:00:00 +0900
categories: techcourse
published: true

안녕하세요. 교육코스개발팀 이원미입니다. 51명의 크루가 우아한테크코스 한 달 생활기라는 주제로 작성한 첫 번째 글은 모두 잘 읽어보셨나요?

레벨 2를 마무리하면서 크루들이 작성한 글의 주제는 ‘우테코에서 찾은 나만의 효과적인 공부법’입니다. 글을 작성하기 전, 주제가 너무 어렵다며 엄살을 부리던 크루들의 모습이 생각나네요. (글쓰기 결과물을 보니, 정말 엄살이었다는 걸 느낄 수 있었습니다^^)

우테코는 기존의 수동적인 학습방법에서 벗어나 크루들이 능동적이고, 자기주도적으로 학습하기를 희망하고 있는데요. 우테코를 통해 크루들의 학습 방법은 어떻게 변화했는지, 그리고 어떻게 자신만의 학습법을 찾아나아가고 있는지 글을 통해 확인해 주시길 바랍니다.

이번에도 최선을 다해 작성해 준 크루들에게 다시 한번 감사의 말을 전합니다. ☺️

쪼밀리(조수진)의 글

기계공학 전공생의 좌충우돌 프로그래밍 학습기

할 건 많은데, 시간이 모자라요. 어떻게 공부해야 해요~?????

레벨1을 마칠 때 즈음 찾아온 고민이다. 열심히 했는데도 Todo 리스트의 채워지는 속도가 지워지는 속도보다 빨랐다. 당황스럽고 어려웠다.

기계공학을 전공했다. 기계공학은 오랜 세월에 거쳐 정립된 수학과 물리 법칙을 기반으로 한 학문이다. 이런 과목에 익숙해서인지 기존의 공부 방법은 소프트웨어를 학습하는데 적절하지 못했다.

개념과 원리 vs 핵심과 경험

기계공학은 정/동역학, 열역학, 고체역학, 유체역학으로 유명한 4대 고전 역학들과 미적분, 공업수학, 선형대수, 통계 등의 오래된 수학을 주로 다룬다. 원리를 이해해야 현실의 문제에 응용할 수 있다. 기초 과목들과 개념들이 중요하고, 선수 과목을 이해하지 못하면 다음 단계를 따라갈 수 없다. 이해할 때까지 고민해야 했다. 주로 텍스트를 이용한 공부를 했다. (처음 소프트웨어를 공부할 때 코드는 한 줄도 안 치고 자바의 정석 책만 주구장창 봤던 기억이 난다 ㅎㅎ)

또, 하나의 지식을 익히는 데 시간이 오래 걸렸다. 2시간 이상은 확보해야 공부를 할 수 있었다.

프로그래밍을 공부할 때는 학습 방법이 달라져야 한다는 것을 깨달았다. 핵심을 빠르게 파악하고 기술의 사용법을 우선 습득하는 것이 효과적일 때가 많았다. 그 경험이 쌓여야 동작 원리와 철학에 대한 지식을 이해할 수 있었고, 코드의 관점에서 프로그램의 관점으로 시야를 넓힐 수 있었다. 처음부터 모든 걸 확실히 이해하려고 하면 시간이 오래 걸렸고, 이해한 것도 금방 잊어버렸다. 이해할 수 있는 만큼 받아들이고 궁금하거나 어려운 것은 백로그에 담아 두고 과감히 넘어간다. 나머지는 지식이 더 쌓였을 때 추가 학습을 한다.

또한 IT업계는 새로운 기술이 쏟아져 나오고 학습할 내용이 방대하다. 모든 기술을 세세하게 다 이해하려면 결국 시간이 부족하다. 업계 특성적으로도 새로운 학습 방법이 유용하다고 생각한다.

확실한 설계 vs 지속적인 리팩토링

이전 직장에서 냉장고 제품 개발을 했다. 한 제품군의 컴프레서 냉력을 이례적으로 높게 올리는 작업을 한 적이 있다. 실 사용처에서 과냉 문제나 안전사고가 날 수도 있기 때문에 부담이 막중했다. (휴대폰이 터지던 시절이라 남의 일 같지 않았다..! 오들오들) 조그마한 오류가 아주 큰 사고로 이어질 수 있어서 꼼꼼하고 정확하고 완벽하게 설계하는 것이 중요했다. 처음 프로그램을 개발할 때도 습관처럼 머릿속으로 코드가 다 그려져야 구현을 시작할 수 있었다.

소프트웨어를 개발할 때는 처음부터 완벽하게 만들려고 하기 보다 일단 동작하는 코드를 만드는 것이 중요하다. 동작하는 코드가 좋은 코드를 만들기 위한 첫걸음이다. 한 번에 가장 좋은 코드를 작성할 수 있으면 좋겠지만, 그건 (나는) 불가능하다. 초안을 만들고 수정에 수정을 거듭하는 것이 소프트웨어 개발과 학습에 맞는 자세라고 생각한다.

Right Answer vs Best Answer

수학과 물리는 항상 정답이 있다. 모르는 건 책을 읽거나 식을 증명해보면서 스스로 공부하는 것이 효율적이었다. 아무리 해도 모르겠을 때에야 선생님 혹은 교수님께 물었다.

프로그래밍에는 정답이 없다. 현재 상황에서 적절한 코드인지 그리고 얼마나 설득력이 있는지가 중요하다. 많은 사람과 생각을 공유하는 것이 최적의 답을 찾기에 효과적이었다. 여러 관점과 아이디어를 코드에 녹여본다. 다시 다양한 답안과 비교해본다. 그 과정에서 여러 코드의 장단점을 배울 수 있다.

그런 점에서 우아한테크코스는 최적의 답을 찾는 연습을 하기에 가장 알맞은 공간이라고 할 수 있다. 항상 열의에 넘치는 크루들과 질문에 열려있는 코치들 그리고 잡담을 중요시하는 분위기까지! 새로운 학습법에 대한 깨달음에 그치지 않고 적용해볼 수 있는 절호의 기회다.

맺으며

레벨1에서는 기존의 학습 방법밖에 몰랐고 속도가 느렸다. 담당 코치와 면담을 하며 이런 고민을 털어놓았다. 시간과 일의 단위를 잘게 쪼개고 현재 목표에 집중하는 연습을 해보라는 조언을 받았다. 레벨2에서는 조언을 따라 새로운 방식을 채택해보니 속도가 빨라지고, 일이 진행된다는 느낌을 받아서 덜 지치고 재미가 있었다. 효율적으로 학습하려고 노력하다보니 서서히 핵심과 실습 위주 그리고 빠른 구현과 리팩토링의 방향으로 학습 패턴이 변화했다. 서로의 다름에 유연한 크루들과의 잡담도 인사이트가 가득하고 즐거운 시간이었다. 레벨3에서도 앞서 배운 학습법을 조금 더 활용해보고자 한다.

끗-🥰

디디(김태헌)의 글

개념 원리

개념 원리, 들어보신 적 있으신가요? 여러분들이 학창 시절 수학 공부를 해봤다면 한 번쯤 들어봤을 거예요. 제목 그대로, 개념과 원리를 충분히 학습하고 나서 단계별로 문제를 푸는 책이죠. 대부분의 초등학생은 이 방법으로 공부를 시작합니다. 수학 익힘책보다 수학책을 먼저 보는 게 정상이죠. 그 방식이 너무나도 맘에 들었어요. 개념을 모른 채 문제를 푸는 건 상상도 할 수 없었죠. 문제를 풀다가 모르는 개념이 나오면 다시 복습하고 문제를 풀곤 했어요. 학원 강사로 일을 할 땐, 개념이 얼마나 중요한지에 대해 가르치고 다녔습니다. 다짜고짜 문제만 풀고 있는 학생에겐 지적하기도 했죠. 이렇게 전 일종의 ‘학습 고정관념’에 사로잡혀 있었습니다.

우아한 테크코스

학습 고정관념은 우테코에 온 첫날에도 그대로였어요. 하지만 우아한 테크코스에선 수학책을 나눠주지 않더라고요. 수학 익힘책만 주고선 문제를 풀라고 해요. 강의도 거의 없죠. 일주일에 2~3시간이 전부거든요. 그동안의 제 학습 방법이 부정되는 기분이었어요. 그때부턴 남는 시간에 책을 읽어가며 공부했어요. 제 방식대로.

하지만 스프링책은 아무리 읽어도 이해가 되지 않았어요. 알아야 할 건 너무나도 많은데, 이걸 왜 알아야 하는지는 알려주지 않더라고요. 마치 모르는 언어의 발음부터 배우는 기분이었죠. 그때부터 학습 고정관념에 금이 가기 시작했어요. 책에 아무리 시간을 쏟아도 얻을 게 없어 보였죠. 또한 내용이 너무 방대해서 모든 걸 기억하기엔 역부족이었어요. 이런 이유로 공부 방법에 관해 같이 공부하는 크루들과 대화를 많이 나눴어요. 결론은 하나였죠. 일단 코딩 먼저 해봐라. 책 말고 실습을 해라. 이렇게 방황하던 중 레벨2가 시작되고 브라운의 첫 강의를 듣게 되었죠.

자동차 운전을 배울 때 자동차의 역사나 구체적인 내부 구동 방식보다는 운전법을 먼저 배운다.

운전법을 익힌 다음 운전이 익숙해질 때쯤 내부 구조나 동작 원리에 관해서 관심을 가진다. – 브라운

고민하는 걸 알고 있다는 듯이 브라운이 공부법에 대해 강의를 했어요. 정신이 번쩍 들더라고요. 개념 먼저 공부해야 한다는 고정관념이 깨지는 순간이었어요. 이때부터 사이드 프로젝트를 시작했어요. 간단한 게시판이지만 매일 배운 걸 적용해볼 수 있었죠. 새로운 내용을 학습할 땐, 그 개념을 어떻게 제 프로젝트에 적용할지를 먼저 생각해요. 항상 책이 아닌 코딩으로 시작했죠. 코딩하다가 모르는 내용이 나올 때는 씨유의 조언을 참고했어요.

학습 중 모르는 기술에 대해 기록해놔라. 기술 부채가 쌓이면 상환하며 학습한다.

책을 다 읽으려고 하지 마라. 책의 목차를 인덱싱해놓고, 모르는 내용을 발견할 때 그 책을 찾아본다. – 씨유

프로젝트에 새로 배운 개념을 적용하다 보면 모르는 내용을 마주쳐요. 만약 적용에 성공하더라도 그 지식은 휘발되기 좋죠. 그래서 크루들과 공유할 수 있는 공유 기술 부채를 만들었어요. 모르거나 알고 싶었던 내용의 부채를 쌓아놓죠. 주말마다 상환 시간을 갖도록 합니다. 기술 부채를 공유하면서 우리에게 필요한 내용을 효과적으로 학습할 수 있거든요.

빚도 재산이다 -디디

마치며

물론 전 아직 한참 부족하다고 생각해요. 말씀드린 공부법도 저에게만 맞는 방식일 수도 있어요. 공부법이란 건 사람마다, 배우는 내용마다 천차만별인 것 같아요. 비단 프로그래밍뿐만 아니라 다른 영역에서도요. 중요한 건 학습법에 문제가 있다는 걸 인지하지 못한다면 이전의 저처럼 고생할 거라는 겁니다. 우아한 테크코스에 오지 않았다면 저도 마찬가지였을 테고요. 여러분들이 평소에 당연하다고 여겼던 공부법도 다시 한번 확인해보세요. 과연 지금 내가 배우는 주제에 대한 적절한 학습법은 무엇일까? 좀 더 효율적으로 할 수 있는 방법은 없을까? 같은 질문들로요.

우아한 테크코스의 장점은 여기서 나오지 않나 싶어요. 제가 겪을 시행착오를 미리 겪어본 코치님들께 여쭤볼 수 있다는 점. 같은 내용을 공부하면서 깨달음을 얻은 크루들과 함께라는 점. 공부한 것들을 자유롭게 공유하는 환경. 이러한 긍정적인 요소가 합쳐져서 강력한 시너지를 발생시키는 것 같아요. 다음에 또 글을 쓰게 된다면, 이런 시너지를 통해 더욱 성장한 제 모습을 보여드리도록 할게요. 여러분들도 자신만의 공부법을 통해 성장하셔서 다시 뵙길 바랄게요.

소니(박공손)의 글

일단 돌아가면 되는거 아니야?

우테코에서 공부하면서 이전과 가장 많이 달라진 건 개발에 대한 나의 태도이다.

개발을 처음 시작할 때는 그냥 되는 게 신기했다. 내가 짠 코드가 돌아가는 게 신기했고, 책과 강의를 보고 따라친 코드가 그대로 동작하는 게 신기했다. 그 당시 나에겐 코드가 돌아가는 게 중요했다. 어떻게 돌아가는지는 중요치 않았다. 그렇게 신나게 토이 프로젝트 몇 개를 만들고 스스로 뿌듯해했다. 이런 공부 방법이 잘못되었다는 걸 알게 된 건 한 스타트업 면접을 보고 난 후였다. 운 좋게 서류 합격이 된 후 면접을 보게 되었고 거기서 내 민낯이 드러났다.

• "방금 작성한 코드의 시간복잡도는 얼마나 될까요?"
• "오버로딩과 오버라이딩의 차이는 무엇인가요? 코드로 설명해주세요"
• "Call by value 와 Call by reference 의 차이는 무엇이죠? 메모리에는 어떻게 할당되나요?"
• "문자열 비교는 equals를 사용하고 숫자 비교는 == 을 사용하는데 차이가 뭔가요?"

개발을 하면서 깊이 생각해보지 않고 지나친 것들이었다. 그냥 책에서 하라는 대로 했고, 문제가 생기면 스택오버플로우 답변을 참고해 해결했다. 그렇게 되는가 보다 하고 넘어갔던 것들에 대해 질문을 받은 나는 제대로 답변할 수 없었다. 면접이 끝나고서야 알았다. 화면에 보이는 화려한 기능보다 그 기능이 어떻게 돌아가는지 아는 게 더 중요하다는 것을.

근데 왜 돌아가는거지?

우테코에 들어와서는 개발 공부를 하는 태도가 달라졌다. 코드가 돌아가는 것보다 왜 돌아가는지가 더 궁금하다. 이전에는 ‘왜 안 되지?’라는 말을 많이 했다면, 이제는 ‘왜 되지?’라는 말을 많이 한다. 이전에는 일단 되면 되나 보다 하고 넘어갔다. 원하는 기능이 있으면 검색한 코드를 복사 붙여넣기 했고, 코드가 돌아가면 좋아했다. 왜 되는지보단 일단 되는 게 중요했다. 그런데 이제는 해당 기능이 어떻게 동작하는지가 더 궁금하다. 책이나 블로그에서 하라는 대로 하면 되는 건 알겠는데, 왜 되는지가 궁금하다.

이를테면 아래와 같은 것들이다.

• SpringBoot의 수많은 어노테이션이 자동으로 무언가를 해준다는데, 어떤걸 자동으로 해주는 건지 어노테이션 별 차이점은 무엇인지가 궁금하다. 테스트 코드에서 @WebMvcTest에서는 안 되던 게 @SpringBootTest로 바꾸니까 되네? 왜..?
• VO(Value Object) 값을 비교하는 테스트코드를 돌렸는데 실패한다. equals()와 hashcode()를 오버라이딩 해주니 테스트가 통과한다. 왜..? 이상한 건 equals()만 오버라이딩 해도 테스트가 통과한다. 그럼 hashcode()는 왜 같이 정의해주지? 이전 같았으면 그냥 같이해주라니까 그런가보다 하고 넘어갔을 텐데, 이제는 그렇게 넘어가려니 너무 찜찜하다.
• git reset -—hard 는 위험하니 조심해서 써야 한다고 한다. 왜? 복구할 수 없다고? 아 그렇구나.. 응? 검색해보니 복구 할 수 있다는데? 그게 어떻게 가능한 거지? git이 데이터를 저장하는 방식이 궁금하다.

공부를 하다 보면 하루에도 몇 번씩 위와 같은 의문, 찜찜함, 궁금증이 생긴다. 예전 같았으면 그냥 넘어갔겠지만 지금은 직접 찾아보고, 이해하고, 정리한다. 이후 내가 이해한 내용을 크루와 코치에게 다시 질문하고 토론하는 과정을 통해 제대로 이해했는지 확인한다.

우테코 교육도 당장 돌아가는 코드를 짜기보단, 시간이 좀 더 걸리더라도 읽기 쉽고, 유지 보수가 용이한 코드를 짜도록 유도한다. 그래서인지 크루들 간 대화 주제도 특정 기술에 대한 이야기보다 도메인 구조나 기능의 원리 (ex. DB 테이블의 구조, 스프링 인터셉터의 원리 등)에 대한 토론이 더 많다.

이런 환경에서 공부하다 보니 개발을 대하는 태도가 많이 달라졌다. 이전에는 기능을 구현해도 스스로 자신이 없었다. 코드가 조금만 달라져도 이해하기 힘들었고, 동작 원리를 제대로 모르니 설명할 수 없었다. 예전에 실수로 git reset —hard를 친 후 다시 되돌리지 못해 처음부터 코드를 다시 짠 적이 있다. 이제는 필요할 땐 자신 있게 git reset -—hard를 치고, 되돌리고 싶을 땐 git reflog를 이용해 되돌린다.

기술 사용자를 넘어 개발자로

자동차를 운전하는 사람은 운전을 위한 작동법만 익히면 된다. 엔진이 돌아가는 원리에 대해서는 몰라도 된다. 하지만 자동차를 만드는 엔지니어라면 엔진이 돌아가는 원리와 타이어의 종류별 차이와 장단점에 대해 알고 사용해야 한다. 개발도 비슷하다고 생각한다. 서비스를 이용하는 사람은 사용법만 아는 걸로 충분하다. 하지만 서비스를 만드는 개발자는 단순히 기술의 사용법을 넘어 동작 원리를 이해해야 한다. 그렇지 않으면 자신이 짠 코드에 대해 자신이 없고 불안하다.

무작정 돌아가는 코드를 만들 때는 무언가 배우는 것 같으면서도 항상 불안했다. 기능의 사용법을 공부해서 쓰긴 했는데 동작하는 원리에 대해서는 모르고 사용했기 때문이다. 이제는 기능의 사용법을 익히는 동시에 그 뒤에서 일어나는 동작 방식에 대해 공부하려고 노력한다. 시간은 두 배 이상 걸리지만 그만큼 기능에 대한 이해도 더 깊어지는 것 같다. 우테코에서 기술보다 기술을 학습하는 태도를 배우고 있다. 하루하루 궁금했던 점을 알아가는 재미가 있다. 그래서 이전보다 개발이 훨씬 재미있다. 이런 재미를 알게 해준 캡틴과 코치, 크루들에게 감사하다. 🙂