2022. 4. 4. 02:11ㆍ회고
지금 보고 계시는 글은 코드스쿼드 마스터즈 과정에 참여하며 느끼고 학습한 내용을 정리한 글입니다.
벌써 코드스쿼드 과정을 시작한지 3개월이 지났습니다.
Java와 Spring, 문제풀이나 CS의 전반적 지식이 늘어났습니다. 아직 갈 길이 멀지만, 그래도 시작할 시점과는 달리 무엇을 해야할 지는 알게 돼서 조급한 마음은 없습니다.
생각보다 좋은 개발자가 되는 것은 쉽지 않은 것 같습니다. 과정 중간에 있던 선배기수들의 과정 수료 후기, 직장에서의 삶, 과정동안 고민했고 현재 진행중인 고민을 들으며 '6개월만 열심히 하면 개발자로 전직할 수 있겠지' 하는 생각은 정말 말도 되지 않았다는 것을 깨달았습니다.
그래도 느끼고 배운 것은, '마라톤 같은 개발 인생에서 어떻게 야생환경에 적응하고 스스로 답을 찾을 수 있는가' 입니다. 기껏해야 3개월 입문해본 뉴비가 무엇을 알겠느냐고 생각하시겠지만.. 생판 아무것도 모르는 곳에 던져져 정말 아무것도........ 가르쳐주지 않는 마스터님들 아래에서 미션을 수행하며 이른바 '삽질력'이 상승했습니다. 어차피 삽질할 것이라면 미리 해두고 시행착오를 줄이는 것이 좋은 방법이라고 생각합니다. 아무것도 가르쳐주지 않는다고는 했지만, 세심한 코드리뷰와 일주일에 두 번 있는 개발 세미나(?) 가 있어서 더욱 빨리 성장할 수 있었습니다.
그리고, 선배 개발자분들, 뛰어난 동료들이 지식을 공유하는 분위기의 문화나, 시키지 않았지만 순수한 학문적 궁금증에 밤을 새며 지식을 쌓고, 그 귀중한 정제된 지식을 거리낌 없이 나누어주는 따듯함이 감사했습니다.
# 학습 회고
- CS10 코스
과정 순서 :
진법 - 리눅스 - 자료구조 - 객체지향과 상속 - 메모리 - 함수형 프로그래밍 - 멀티 프로세스 및 스레드 스케줄링 - 비동기 프로그래밍 - DB - HTTP와 TCP/IP 네트워크
나름 전공자라는 자신만만함이 무참히 깨진 시간이었습니다. 오래 전 배워 기억이 나지 않거나, 알고 있다고 생각했는데 잘못 알고 있거나.. 등 삽질력이 많이 올라간 시간이었습니다.
모르는 것을 익히는 시간은 고통스럽지만, 해냈을 때의 성취감과 그 성과는 정말 크다고 생각합니다. 매주 2개의 미션이 차례대로 공개될 때 마다 고통스러웠지만 꾸역꾸역 소화했습니다. 지금도 CS지식을 안다고 자신있게 말하지는 못하지만, 최소한 무엇을 모르고 어떤 공부를 해야할지는 알게 되었습니다. (kocw 반효경 교수님 최고......)
- git
코드스쿼드에서는 모든 미션을 git으로 진행합니다. 그래서 git의 사용법과 대략적인 flow를 아는 것이 중요합니다. 이것 또한 야생형으로 익히게 되었습니다. Issue가 발행되고, 단계를 수행할 때 마다 PR을 보내고 검토 후 merge를 받는 시스템입니다.
그런데 만약, 1단계 PR을 보내고 2단계를 진행하던 중, 1단계 PR에 change requests가 뜬다면 2단계와의 conflicts는 어떻게 해결할 것인가... 또 다른 시나리오로, 2단계 PR에 1단계 commit이 함께 중복되어 보인다면? 실수로 main에 PR을 보내고 merge되는 해프닝은 애교였습니다. 수 많은 삽질과 호통 끝에, 이제는 cherry-pick이나 rebase 등을 활용해서 나름 커밋내역과 프로젝트를 관리할 줄 알게 되었습니다.
커밋 컨벤션이나 리뷰어와 저 모두의 생산성을 위한 PR 작성법과 소통법도 배울 수 있었습니다. github1s 를 통해 멤버들의 코드를 보며 배우는 것은 또 다른 재미를 얻을 수 있었습니다.
- 문제풀이
어렵고 먼 길이지만 언젠가는 해야 할 개발자 지망생의 필수 코스, 문제풀이입니다. 저는 다행히도 본 과정 전에 3개월정도 문제풀이 알고리즘 스터디에서 기초를 닦고 온 경험이 있었습니다. 그래서 CS10 과정중 병행하여 진행되는 문제풀이 세션에 어려움은 없었습니다. 그래서 조금 안주하게 되었습니다. 그러나.... 실제 소위 말하는 '네카라쿠배' 기출문제를 접하고 나니 자신감이 수직하락하게 되었습니다.
그래서 ! 알고리즘 스터디에 다시 들어가게 되었습니다 ㅎㅎ. 매 주 발표자가 알고리즘 분류 중 하나의 개념과 적용과 풀이, 시간복잡도나 노하우를 공유하고 주중에 문제를 푸는 간단한 스터디입니다. 경험이 있어 가벼운 마음으로 도전했지만, 여전히 쉽지는 않습니다. 최근에는 벨만포드 알고리즘을 접했는데, 단순한 다익스트라인 줄 알고 덤볐다가 보기좋게 나가떨어졌습니다. 문제풀이도 다른 어느 분야만큼 깊이가 있어서 정도를 정해두고 과열되지 않게 조금씩 준비해보려 합니다.
아직은 문제풀이가 즐겁습니다. Java나 Spring의 개념을 정리하려 영어 공식문서를 찾아보거나, 수 많은 인터페이스와 구현체를 뒤져야 하는 노동은 없기 때문입니다. 끝이 없는 언어와 프레임워크에 대한 공부 대신, 유일하게 한두시간 할애하면 '맞았습니다!"를 띄워주는 끝이 있는 공부라서 더 그런 것 같기도 합니다. 아마 취준을 위한 공부로 끝내는 것이 아니라, 개발자 인생이 고단할 때 머리를 식혀주는 리프레쉬의 도구로 계속 쓸 것 같습니다.
- Spring
당연히 해야하는 Spring 공부. 코드스쿼드 시간 동안 기초는 닦아야겠다고 다짐했습니다. 다행히도, 너무 재밌습니다...! 어쩌면 우아한형제들의 기술이사 김영한님과 함께해서 더 흥미가 솟는 것 같기도 합니다. 어쩌면 토비의 스프링으로 어렵게 공부해야 했을 스프링 프레임워크를 실습 위주로 개념을 친절히 설명해주며 체득할 수 있게 도와주십니다. (토비의 스프링이 나쁘다는 뜻은 아닙니다. 책으로 공부하는 것이 시간이 더 많이 들기 때문입니다ㅠㅠ) 과정 중 병행하려니 많이 듣지는 못했네요. Test의 중요성도 더 알게 되고, 현업의 이야기들이나 역사를 훑으며 변화되어온 java web 생태계의 흐름을 따라오니 엄청나게 추상화된 spring boot의 기능들도 더 이해도 높고 유연하게 적용할 수 있었습니다.
이어지는 이야기인데, 코드스쿼드에서 순수 java코드로 web application server를 구현하는 미션이 있습니다. 소켓부터 시작해서 client로 부터 온 InputStream 을 읽어 파싱하고, 다시 비즈니스 로직을 수행한 후 Outputstream에 write하는 과정 전체를 구현하게 되었습니다. 이 미션 과정 중 mvc 1편과 2편 강의가 너무 큰 도움이 되었습니다. spring의 현재dispatcherservlet 구조이 완성되기까지 어떤 흐름으로 WAS가 발전되었는가, HandlerMapping이나 adapter, view, frontController 패턴 등 많은 내용을 배울 수 있었습니다. 혹시 이 글을 보고 계시는 분이 계시다면 주저하지 말고 인프런에 투자하세요.... 개발자 인생이 달라지는 경험을 했습니다. 그냥 단순한 프레임워크라고 생각했던 스프링이 얼마나 많은 생각과 시행착오를 겪으며 만들어진 피의 결과물인지를 알 수 있었습니다. ! 추상화된 결과물만 사용하게 된다면 스프링의 영혼은 알지 못하게 되실 거에요....ㅠ (3개월차가 이런 이야기 하는 것이 이제보니 조금 우습기는 하네요.....ㅎㅎㅎ)
그리고! 또! 스터디에 들어가게 되었습니다. Nathan이 수고해주셔서 틀을 잡고, http://egloos.zum.com/agile/v/3684946 삼색볼펜법으로 진행하는 6인 '토비의 스프링' 스터디!
아직까지는 순조롭습니다. IOC, DI, TEST 등 스프링의 정수를 -ing 형으로 체득하고 있습니다. 과정중에만 진행하는 것이 아니고, 개발자로 전직하고 나서도 1400페이지..?가 넘는 이 책을 완독할 예정입니다. 스프링 어플리케이션 개발자라면 누구나 추천하는 데에는 이유가 있을것이라 믿고 바이블처럼 읽는 중입니다. 다행히, 우려와는 다르게 인프런 강의를 듣고 책을 읽으니 더 와닿는 부분이 많습니다. 여러분도 힘들겠지만 토비의 스프링 한 번 읽어보시기를 추천합니다 !
- JAVA
남궁성 선생님은 정말 최고입니다.. Java 개발자라면 누구나 입을 모아 추천하는 입문 기본서!
https://www.youtube.com/watch?v=oJlCC1DutbA&list=PLW2UjW795-f6xWA2_MUhEVgPauhGl3xIp&index=1
무료 온라인 강의도 있습니다. 개인적으로 이 강의만 체득한다면 기본은 할 수 있으리라 생각합니다. 인프런에 올라왔다면 30만원은 되지 않을까 하는 퀄리티의 강의입니다. (근거는 없습니다..)
물론 개념을 익히는 것과 실제 서비스에서 적용을 하는 것과의 괴리는 상당합니다.... stream이나 optional, thread 같은 개념을 자유자재로 사용하려면 조금 더 경험이 쌓여야 가능할 것 같습니다.
# 좋았던 점
- 회고
코드스쿼드에서는 매일 하는 회고가 필수입니다. 회고라고 해서 거창한 것이 아니고, 공유 문서에 하루 있었던 일과 개선해야 할 점, 현재 감정상태나 고민, 배운 기록 등을 남기는 행위입니다.
현재 시점에서 1월에 했던 고민들을 보면, 얼마되지 않았지만 보기에 귀엽습니다. 저렇게 쉬운 걸 두고 쩔쩔맸다는 말이느냐..ㅎㅎ 하기도 하고 과거의 너무 커보였던 고민이 의식하지도 않은 사이에 자연스레 해결되어 있는 상황을 보며 감사하기도 합니다.
참 건강한 문화인 것 같습니다. 누군가의 고민이 남겨진 회고를 보고 이야기를 시도해 볼 수도 있고, 오늘 하루 미션을 도와준 누군가에게 감사를 표할 수도 있고, 말씀드린 것 처럼 과거의 고민의 기록이나 학습기록을 보고 앞으로 가야할 방향을 다시 잡을 수도 있습니다.
- 모각코(모여서 각자 코딩)
2022 백엔드 코스 Discord 채널이 새로 개설되었습니다. zoom에서 나눴던 생산적인 이야기와 서로 보냈던 즐거웠던 기록들이 회의가 종료되면 사라지는 것이 아쉬워서 멤버 kukim의 주도로 만들어졌는데, 너무 좋습니다. 일주일 중 어느 시간에 들어가도 모각코를 할 멤버가 한명은 있습니다. 덕분에 긴장된 분위기에서 언제나 학습을 이어나갈 수 있다는 것이 참 감사했습니다. 시시콜콜한 이야기나 고민을 나누고, 궁금증이나 정보를 나누는 코너도 있습니다.
열심히 지식을 나눠준다고 해서 누가 알아주는 것도 아닌데, 멤버들이 참 열심입니다. 어려운 것을 물어보면 본인의 미션도 내려놓고 친절하게 도와줍니다... 왜 이렇게 열심일까 생각해봤는데, 모르겠습니다. 개발자들의 문화가 이런 것인가 싶습니다. 컴퓨터 하는 사람중에는 나쁜사람이 없나? 하는 생각이 들기도 합니다.... 여튼 좋습니다. 좋은데 설명할 방법이 없습니다.. 혹시 코드스쿼드 고민중이시라면 고민없이 지원해보시기 바랍니다...
- 페어 프로그래밍
코드스쿼드에서는 Pair Programming을 권장합니다. 두 명의 멤버가 짝을 이뤄 하나의 컴퓨터(화면)만 두고 미션을 수행하는 것입니다. 한 명의 Navigator가 다른 한 명의 Driver에게 지시를 내리면 Driver는 그대로 화면에 코드를 입력하거나, 검색을 수행하거나, 지시에 소극적으로 의문을 제기하는 방식입니다. 당연히 코드 작성속도는 정말 극단적으로 줄어들고, 체력도 훨씬 많이 소모됩니다. 평소에는 뇌를 거치지 않은 날것의 코드를 작성했다면, 이제는 Driver를 이해시켜야 앞으로 나갈 수 있으니 무조건 뇌를 거친 코드를 내뱉어야 합니다. 그런데, 코드의 퀄리티는 극단적으로 상승합니다. 평소에는 시도조차 해보지 않았을 리팩토링도 거침없이 진행할 수 있게 되고, 더 좋은 코드를 함께 고민하며 TDD를 시도하기도 합니다. 멤버 각자가 모든 지식을 알고 있진 않지만, 두 명이 모인다면 모르는 분야의 지식의 넓이가 훨씬 줄어들게 됩니다. 그래서 상호보완적인 코드가 나올 수 있습니다. 예를 들어, 한 멤버는 Optional에 대한 이해가 적은 대신, 디자인 패턴이나 원칙에 대해 바싹하고, 다른 멤버는 Optional과 Stream의 마스터인 동시에 디자인 패턴에 약하다면 이보다 더 좋은 스승은 서로에게 없을 것입니다. 물론 모든 상황에서 최선인 경우는 아니겠지만(모르는 영역이 서로 겹치는 상황....?), Pair Programming을 진행하며 상대방의 코드에 담긴 철학을 배울 수 있었고 이 같은 기회는 정말 코드스쿼드가 아니면 배울 수 없을 것 같습니다. 누군가의 코드를 따라할 순 있지만 영혼까지 베껴오지는 못합니다. pair를 진행하면 정말 영혼의 단짝이 된 것처럼 코드에 애착이 생기고 정말로... 결과물이 자랑스럽습니다...(물론 리뷰어에게 호통을 듣는 것은 여전합니다..)
# 아쉬웠던 점
- 조금 늦은 리뷰..?
조금 조심스러운 이야기입니다. 현업자분들에게 리뷰를 받다보니 조금씩 늦어지는 것이 당연합니다. 직장과 리뷰를 병행하시기 때문입니다. 하지만 저같이 결과물의 코멘트를 즉각적으로 받고 싶어하는 성향이라면.. 조금 힘들 수도 있습니다. 다음 스텝을 밟고 싶은데 전 스텝의 상태가 blocking 되어있으면 조금 힘들었습니다...
그런데 이것 또한 훈련이 아닐까 생각합니다...ㅎㅎ 현업에서 코드리뷰를 적극적으로 해줄 수 있는 상황의 사수가 과연 몇퍼센트나 될까요.. 그 시간 동안 스스로 답을 찾아가는 것도 하나의 방법이 아닐까 생각해봅니다.
- 문서 작성
저번 회고에서도 했었던 고민입니다. 문서화가 정말 중요하다는 것을 알지만 글을 쓰는 것이 조금 부담스럽기도 합니다. 낮은 확률로 다른 사람에게 도움이 될 수도 있지만 꾸준히 배운 내용을 남겨 무엇보다도 미래의 저에게 도움이 되는 것이 목표인데, 하루하루 배우는 것이 주가 되어 우선순위가 저 멀리 가있습니다. 의식적으로 노력해야 나아지는 것임을 명심하고 열심히좀... 제발 ! 해봐야겠습니다!
(그래도 TDD에 관한 글을 하나 썼습니다 !)
'회고' 카테고리의 다른 글
| 말하는 감자의 13개월 개발자 취준 회고 (14) | 2023.02.09 |
|---|---|
| 코드스쿼드 마스터즈 백엔드[JAVA] 코스 마무리 회고 [2022.06.10] (16) | 2022.06.14 |
| 코드스쿼드 TODO 프로젝트 학습회고 [2022.04.04 - 2022.04.15] (3) | 2022.04.16 |
| 코드스쿼드 마스터즈 백엔드[JAVA] 코스 2주차 회고 [2022.01.16] (0) | 2022.01.17 |
| 코드스쿼드 CS02 - 가상머신 리눅스, 쉘 스크립트 (0) | 2022.01.06 |