우아한테크코스 레벨2가 끝났다. 우아한테크코스(이후부터는 줄여서 '우테코'라고 부르겠다.)를 하면서 많은 것을 느꼈고 변했다. 그 중 하나의 이유로 이 글을 쓰고 있기도 하다. 우테코에 들어와서 알게 된 사실 한 가지는 개발자는 실력도 중요하지만 그 만큼 커뮤니케이션 능력도 중요하다고 한다. 그러므로 자기 생각을 남들에게 글이든 말이든 잘 표현해야 한다. 그런데 나는 내 생각을 말이든 글이든 표현하는게 너무 어려웠다. 그래서 우테코를 진행하면서 힘들었던 점이 많았던 것 같다. 하지만 이를 극복해야 한다고 생각했고, 글로 표현하는 것을 연습하고자 블로그 활동을 본격적으로 해보고자 한다. 이 글이 내 다짐을 표현하는 첫 시작이고, 꾸준히 갔으면 하는 큰 바램이다...

우테코 레벨 1로 돌아가보자. 포비가 처음 했던 말이 아직도 기억에 남는다.

"우아한테크코스는 여러분이 지금까지 배웠던 방식과는 매우 다르다. 단순히 지식을 주입시키기보다는 스스로 방법을 찾아야 한다. 우리는 여러분들을 계속해서 멘붕에 빠뜨릴 것이다."

멘붕... 처음에는 배우는 지식의 난이도가 그 만큼 어렵다고만 생각했다. 아니면 단순히 겁주는 것은 아닐까 했다. 레벨 2가 끝난 지금 최소한 나에게만은 진짜였다.

지금까지 느꼈던 멘붕을 정리해보면 크게 3가지 키워드가 떠오른다. 개발 방식, 공부 방법, 커뮤니케이션(협업)이다. 하나씩 그 때를 떠올려보며 정리해보자.

개발 방식

우테코를 시작할 때 가장 처음 마주한 멘붕이다. TDD와 페어 프로그래밍. 둘 다 처음 들어본 말이었다. 그 당시에는 전혀 무엇인지 감도 잡히지 않았다.

페어 프로그래밍

먼저 페어 프로그래밍을 보면 단어로만 봤을 때는 2명이서 코딩을 하는 거구나라고 생각했다. 그 당시 이걸 왜하는 걸까 너무 비효율적인 것은 아닐까 생각하기도 했다. 레벨 1에서는 한 미션 빼고는 모두 페어 프로그래밍으로 했는데 단점보다 장점을 훨씬 많이 느꼈다. 특히 배움이 목적이라면 더할 나위 없이 좋은 방법이라 생각했다.

페어 프로그래밍은 기본적으로 두 가지 역할이 존재한다. 한 명은 코딩을 하고 한 명은 옆에서 조언을 한다. 그리고 여기에는 몇 가지 규칙이 있었다.

  • 코드는 두 명이 반드시 동의해야 한다.
  • 한 명이 코딩을 하고 있을 때 조언 하는 사람은 절대 키보드를 잡아서는 안된다.
  • 두 역할을 일정한 시간마다 교대한다.

내가 생각하는 가장 기본적인 규칙이고 나머지는 페어마다 세세한 규칙을 정해서 수행하였다. 여기서 느낀 가장 큰 장점은 코드를 작성한 이유가 생긴다는 것이다. 즉 생각을 하면서 코딩을 할 수 있는 점이었다. 내가 이 코드를 왜 이렇게 짰는지 페어에게 설명해주어야 한다. 그러면서 자연스럽게 가독성과 좀 더 좋은 코드를 만들려면 어떻게 해야할까를 생각하게 된다. 그 외에도 페어와 생각을 공유하면서 내가 몰랐던 부분을 알게 되었다.

페어와 생각을 공유하는 것은 말로 해야하기 때문에 자연스럽게 커뮤니케이션 능력도 기를 수 있었다. 아쉬운점이 있다면 지금까지는 대부분 yes맨이었다. 페어의 생각이나 리뷰어의 피드백, 우테코 강의에서 말해준 부분을 단순히 적용하기만 했다. 의심을 한 적이 거의 없는 것 같다. 포비는 항상 답은 없으므로 자신의 주관에 따라 프로그래밍을 하라고 했다. 그런데 코드에 대한 내 주관은 없었다. 나는 코드를 짤 때 라는 생각을 거의 하지 않았다. 지금와서야 조금씩 하려고 노력하고 있는데 코드에 대한 나의 주관이 생겼으면 하는 바램이다.

TDD

TDD는 테스트 주도 개발로 프로던셕 코드보다 테스트 코드를 먼저 작성하는 것이다. 우테코의 미션 개발방식은 기본적으로 TDD로 진행한다. 처음에는 이게 무엇을 하는 건가 싶었다. 지금까지 테스트 코드를 만들어 본 적이 없었다.(프리코스때 잠깐 해보긴 했다.) 테스트 코드 자체도 어색한데 테스트 코드를 먼저 작성하라니, 말도 안된다고 생각했다. 예상대로 정말 어려웠다. 아직도 사다리 게임 미션 때 멘붕한게 잊혀지지 않는다.

포비도 TDD는 매우 어려운 방식이므로 오랜 연습이 필요하다고 한다. 레벨 2가 끝난 지금도 TDD는 여전히 어렵다. 심지어 웹 서비스에서는 TDD 한계가 뚜렷하기 때문에 이를 해결하는 ATDD를 했는데, 내 멘붕은 더 심해졌다...

그래도 TDD를 통해 테스트 코드의 장점을 많이 알게 되었다. 그래서 이제는 항상 테스트 코드를 작성하려고 노력하고 있으며, 의식적으로 TDD 방식을 따르려고 하고 있다.

공부 방법

우테코의 강의는 포비가 처음 한 말처럼 지식을 주입시키는 방식이 아니었다. 레벨 1때는 일주일에 2 번씩 오전에만 강의했고 미션을 이렇게 이렇게 해야한다는 것을 가르치기 보다는 미션을 하면서 나온 질문들이나 리뷰어의 피드백들 중에 필요한 부분을 중점적으로 강의를 하였다. 이러한 강의도 자세히 가르쳐 주기보다는 키워드를 제시해서 이런 공부를 해보는 것이 좋겠다는 방식이었다. 결과적으로 공부는 스스로 해나가야했다.

레벨 2에는 이 부분이 더 심해졌다. 웹 서비스를 개발하기 위해 스프링부트 프레임워크를 사용했다. 스프링부트를 처음 사용해본 것이기 때문에 공부할 것이 너무 너무 많았다. 강의에서 이를 모두 가르치는 것 역시 불가능한 일이었다. 진행하면서 깨달은 점이 있다면 프레임워크 내부 동작을 하나하나 이해하기보다는 동작하는 기능에 초점을 맞추었다. 검색을 통해 코드를 보면서 이런 코드는 이런 결과로 동작한다는 것만 파악하고 이를 사용한다. 내부 동작은 지금 공부할 시기가 아니었다. 물론 중간중간에 궁금하면 찾아보거나 크루들과 얘기도 해보고 코치한테 묻기도 했다. 하지만 중요한 점은 프레임워크를 익숙하게 사용할 줄 알고 난 후에 내부동작을 공부하는 것도 좋은 방법이라는 것이었다.(우아한 형제들 개발자 조영호님이 알려주신 팁이었다.)

개발에 대해 열정적인 크루들이 많은 만큼 자연스럽게 스터디도 하게 되었다. 처음하는 스터디였고 스터디원들이 모두 적극적이었다. 스터디를 통해 얻은 지식도 좋았지만 스터디원들이 어떻게 공부하는지도 많이 배우게 되었다.

개발자는 평생 공부해야 하는 직업이라고 한다. 그래서 그런지 자신만의 공부 방법을 가지는 것이 중요하다고 생각한다. 레벨 2의 글쓰기 미션 또한 자신만의 공부 방법이라는 주제였다. 물론 아직까지 나만의 공부법을 찾지는 못했다. 지금도 하루하루 무엇을 할지 계획하고 기록하는 것이 좋을 것 같아 TIL를 작성하기 시작했다. 여전히 나에게 맞는 공부 방법을 찾아가고 있는 과정이다.

미니 프로젝트

개발자에게 중요한 부분은 협업이라고 했다. 이를 조금 경험할 수 있었던 것이 레벨 2의 미니 프로젝트였다. 나 포함 5명으로 이루어진 팀으로 페이스북을 따라 만드는 프로젝트를 하였다. 처음으로 제대로 하는 프로젝트라고 생각했다.

프로젝트를 시작할 때 전체 기능, 팀 규칙, 컨벤션, 개발 방식 등을 팀원들과 회의로 정하였다. 프로젝트를 할 때 생각보다 맞춰야할 부분과 문서 정리할 부분이 엄청 많았다. 회의도 자주 했고, 그 속에서 팀원들과 의견을 맞추기도 힘들었다. 그래서 우리 팀에서는 의견이 맞지 않을 때 맞추는 방법을 정했는데, 다수결 이었다. 물론 이 방법은 소수의 의견을 무시할 수 있으므로 장단점이 있었지만 회의를 너무 오래 하는 것도 안좋다는 것을 알게 되었다. 여기서 너무 많은 힘을 뺄 수 있기 때문이다. 답이 없는 부분으로 인해 회의가 길어진다면 이를 결정하는 규칙을 만드는 것이 필요하다고 생각되었다.
(자세한 문서 정리는 https://github.com/1-sunshine/miniprojects-2019에서 확인할 수 있다.)

위 링크의 회고록에도 간단히 정리했었지만, 미니 프로젝트를 하면서 좋았던 점과 아쉬웠던 점을 정리해보자.

  • 좋았던 점
    • 이 때까지 경험해보지 못한 제대로된 팀 프로젝트를 해봤다는 생각을 했다. 팀 규칙, 코딩 컨벤션, 서로 구현한 기능 합치기, 회의 등등 여러 활동을 해봐서 좋았다.
    • 미니 프로젝트 이전에 수행했던 나만의 블로그 미션에서 해봤던 기능을 다시 한번 복습하며 구현해보았고 좀 더 심화된 기능을 추가해보았다.
      • 게시글 CRUD
      • 공개 범위에 따른 게시글 조회
      • 프론트 비동기 처리
    • 데모 동영상 찍기, 프로젝트 소개 판넬 만들기 등 개발 외의 활동을 해봤다.
    • 프론트 앤드 코드를 좀 더 깔끔하게 리팩토링 해보았다.
  • 아쉬웠던 점
    • 회의를 할 때 다양한 의견을 내지 못했던 점과 다른 사람의 의견에 대해 좀 더 솔직한 생각을 말하지 못한 점
    • 배포, S3, 소켓 등을 직접 경험해보지 못했다.
    • 결정된 팀원의 의견에 적극적으로 호응하지 못한 점
    • 다른 사람의 코드를 대부분 제대로 확인하지 못하거나 이해하지 못했다.

취업

우테코에 왔을 때 가장 큰 목표는 취업이었다. 개발에 대해 깊게 생각해본적은 없지만 그냥 큰 회사가서 돈을 많이 버는게 목표였다. 어떤 개발자가 되고 싶은지는 별로 생각이 없었다.

포비는 말했다.

"취업에 대해 심각하게 고민할 필요는 없다. 수료만 하면 어떻게든 취업하게 해주겠다. 일단 수료할 생각부터 해라."

레벨 1때는 이 말을 듣고 '과정이 얼마나 어려우면 수료만 하면 취업이 되는 걸까?', '수료하면 우아한 형제들에서 다 뽑아주는 걸까?', '수료하고도 취업 못하면 어떡하지?' 등등 취업 생각뿐이 없었다. 취업 생각에 가려져 정작 중요한 부분은 보지 못했다.

레벨 2가 끝나고 취업에 대한 생각이 많이 변했다. 취업을 위해서는 무조건 알고리즘을 잘풀고 중요한 전공 지식을 외우고, 회사에서 많이 쓰는 프레임워크를 써봐야하는 줄 알았다. 물론 이 세 가지가 취업을 하는데 중요하다. 하지만 근본적으로 내가 왜 개발자가 되려고 하는지, 어떤 개발자가 되고 싶은지는 전혀 생각해 본적이 없다는 것이다.

레벨 2까지 크루들과 같이 미션, 프로젝트를 하면서 내가 어떤 개발자가 돼야할까를 생각하기 시작했다. 이 생각을 시작했다는게 중요한 것 같다. 아직까지 나만의 학습법도 없고, 어떤 개발자가 돼야하는지 확신이 서지는 않는다. 하지만 개발 실력도 중요하지만 개발자에 대한 주관적인 확신이 있었으면 좋겠다고 생각했다. 이 부분은 지금부터 꾸준히 생각해봐야겠다.

마지막으로...

처음으로 내 생각을 정리하면서 회고를 작성하다 보니 별로 만족스럽지는 못하다. 한 번에 너무 많은 일을 적으려다보니 못 적은 부분도 많고 부족한 부분이 너무 많다. 글쓰기 연습이 많이 많이 필요한 부분이라고 생각했다. 이제부터는 무엇인가를 할 때마다 회고를 정리하는 연습을 할 예정이다. 올해는 우아한테크코스라는 큰 이벤트가 있어서 다행이다. 다른 개발자 분들의 블로그를 보면 상반기와 하반기를 나눠서 회고를 하는 것을 많이 보았다. 내년에는 이러한 방식으로 회고하는 것도 생각해보아야겠다.

이번주 수요일 레벨 3을 갈 수 있다는 메일을 받았다. 많이 안심했고 매우 기분이 좋았다. 레벨 3에는 좀 더 나 자신에 대해 알아가는 시간이었으면 좋겠다. 계획대로 공부한다면 더 좋겠지만 내가 개발자로 살아가는데 나만의 주관이 생겼으면 좋겠다. 레벨 3도 화이팅!