2주차 회고록
사실 2주차부터는 각 일차에 느낀 점을 기록하지 않아서 그런지, 기억이 나지 않는다. 그래서, 간단하게나마 기억을 끄집어대며 적어본다. 누락된 날은 딱히 느낀 점이 없었던 날이었다.
7일차
유난히도 설계가 고통스러웠던 미션이었다. 나는 개념을 잘 안다고 생각했고, 실제 개발에서도 해당 기능을 잘 쓰고 있었지만, 좋은 원칙을 지켜야 한다고 스스로에게 제약을 걸었기 때문에, 결국 12시간 동안 코딩을 한 끝에 미션을 마무리할 수 있었다.
만약 하던 대로 코딩을 했으면 좀 더 빠르게 끝낼 수 있었지만, 그만큼 성장을 하지 못하지 않았을까?
8일차
7일차에서 오래 걸리는 미션이 나왔기 때문이었는지에 대한 반대급부로, 8일차에는 쉬운 미션이 나왔다! 1일차 이후로 가장 빠르게 끝냈던 미션이었다.
다시 한 번 강조하지만, 우리가 미션을 해결하는 이유는 그 주제를 학습하기 위해서 입니다.
스스로 선택해야 하는 사항들에 대해 근거가 될 사항들을 물어볼 수 있지만 결국 스스로 결정해야 합니다.
다른 사람이 결정해주길 바라는 질문보다는, 스스로 기준을 찾아보고 그 내용들을 질문해보세요.
항상 질문할 때는 학습을 해서 결정해야 하는 것인가 아닌가 판단해보시고
답변하시는 분들도 대신 결정해주지는 마세요. 대신 자신의 선택에 대한 근거와 배경에 대한 이야기를 나눠주시는 게 서로의 성장에 도움이 됩니다.
중간에 챌린지 마스터 JK님이 이 말씀을 남겼다. 미션 해결에 목을 메어서, 미션을 어떻게 해석할지, 이 부분을 어떤 방식으로 처리해야 할지에 대한 질문이 많아졌었는데, 그 점에 대한 내용이었다.
실제 개발 환경에서는 누구도 구현 방식에 대해 떠먹여주지 않는다. 고객의 요구사항은 모호하고, 개발자 스스로가 구현 방법을 정해야 할 때가 있다. 중요한 것은 학습이지, 미션에 대해 정답을 구현하는 것이 아니다. 미션은 미션일 뿐, 부스트캠프의 본래 목적은 학습임을 기억하자.
9일차
요구사항 OO는 어떠한 의미가 있으며, 왜 사용되는지, 그리고 어떻게 응용될 수 있을까?
-나, 피어 세션에서
8일차 미션을 끝내고, 피어 세션에서 나는 어떠한 요구사항에 대해 질문을 했다. 슬랙에도 해당 내용에 대해 해석을 요구하는 질문이 많았었는데, 나는 더 나아가서, 저렇게 구현하도록 시킨 의도를 알고 싶었다. 단순히 시켜서 그렇게 구현했다는 답변이 먼저 들어왔지만, 해당 의도를 좀 더 동료들과 고민해보니, 그 속에 담긴 진짜 의미를 스스로 깨닫게 되었다.
학습 과정에서 왜? 라는 질문을 던지는 것은 중요하다. 단순히 요구사항을 어떻게 구현해야 하는가가 아니라, 요구사항을 왜 그렇게 구현해야 했는지, 그렇게 구현하면 어떠한 의미가 있는지를 확인하는 것이 진짜 지속 가능한 학습이라고 생각했다.
10일차
10일차만에 만난 실력자였다.
3주차 회고록
(5일동안 무려 48시간이나 코딩했다. 세상에...)
가장 힘들다고 악명이 높았던 3주차였고 실제로도 그랬다. 사실 4주차를 안 해봐서 잘 모르지만 1주차~3주차 통합해서 3주차 구현 완료 시간과 평균 학습 시간이 제일 길었다.
구체적으로 어떻게 힘들었냐면, 설계가 매우 힘들었다. 1주차~2주차는 그래도 어떠한 구조로 짜면 될 것이다고 설계가 그려졌지만, 3주차의 경우 설계 방법이 잘 그려지지 않았다. 설계하는 과정에서 특정한 CS 지식의 동작 원리가 요구되고, 해당 CS 지식의 동작 원리를 정확하게 알아야 미션을 수행할 수 있었다. 확실히 3주차 미션부터는 미션의 질과 난이도가 향상되었다는 느낌이 들었고, 구현 과정에서 전반적인 흐름 등을 확실하게 공부할 수 있어서 좋았다.
참고로, 3주차부터 전 기수 대비 주제 순서가 완전히 달라진다. 무슨 내용을 배우는지는 알 수 있어도, 언제 뭐가 나올지는 알 수 없으리라.
11일차
11일차는 지옥의 3주차 문제 중 그나마 가장 어렵지 않았던 문제였다. 이번주부터는 좀 더 깊은 학습을 하기 위해, 실제와 비슷한 방향으로 구현하려고 노력하는 일종의 모래주머니를 찼었던 것 같다. 그렇기 때문에, 좀 더 많은 학습을 할 수 있었지만, 더 많은 구현을 해야 해서 더 힘들었다고 생각했다.
12일차
이번 문제는 15일차까지의 문제 중 가장 어려웠던 문제였다. 제일 인상 깊었던 건 13일차였지만, 제일 구현에 시간이 오래 걸렸던 것은 12일차였다. 위에서 말했던, CS지식의 동작 원리를 몰라서 설계가 매우 힘든 문제의 대표주자에 속했다. 심지어 전에 1번 조사까지 했는데도 불구하고!
굴욕(?)을 겪으면서 본인의 무지를 다시금 확일할 수 있었던 시간이었다.
13일차
작년 기수에서도 악명높은 '그 문제'가 나왔다. 그 문제가 뭐였는지는 작년 부스트캠퍼의 후기를 참고하시라. 3주차에서 가장 인상 깊었던 내용이어서 그런지, 15일차 갈틱폰 주제로 13일차 내용만 나왔다더라.
이전 일차에서 배운 신기술을 시험삼아 적용해 보았다. 11일차에서 배운 내용을 적용하거나, 8일차에서 배운 내용을 응용하여 코드를 아름답게 만들기도 했다. 결론적으로, 각 함수의 로직을 쉽게 해석할 수 있던 코드가 되었으나, 그 반대급부로 함수의 제목이 장황해진다는 단점이 존재했다. 각 코드의 로직은 이해할 수 있을 정도가 되었으나 전체 코드의 흐름을 어떻게 개선해야 할지가 관건이 될 것 같다.
14일차
포기할 용기도 필요하다.
13일차에 학습 정리를 마무리하느라 새벽 5시에 자서 그런지, 새벽 4시에 자도 제때 일어났던 내가 늦잠을 자 버렸다... 그 날은 결국 피어세션을 제대로 수행할 수 없었다. 학습도 중요하지만, 건강과 페이스가 무엇보다도 중요하다. 데드라인 전까지 충실히 학습을 수행하고, 데드라인이 넘으면 일단락할 용기도 필요하다고 느꼈다.
학습 분량이 매우 많았기 때문에, 이 날은 처음으로 학습 정리를 완벽하게 수행하지 못한 날이었다. 아쉽긴 했지만, 학습정리를 하느라 밤을 새는 것보다는 낫다고 판단이 되어서 3시 30분에 일단락하고 학습정리를 마무리했다.
15일차
이번 일차에는 같은 팀원들과 갈틱폰을 진행했다. 그 내용은 이 링크를 참조해 보자. 지난 주에서 다른 조가 갈틱폰을 진행했기에, 재밌어 보여서 먼저 하자고 제안했고, 다른 팀원들도 흔쾌히 승낙해 주셨다.
결과적으로, 색다른 팀 회고 경험을 할 수 있었으며, 부스트캠퍼의 고통과 경험을 재미있게 공유할 수 있었으며, 지금까지 배웠던 것을 그림으로 표현하면서 복습도 하는 시간을 가질 수 있었다.
긍정적인 에너지를 주는 사람이 되자.
피어 세션을 마치고, 팀 회고를 하면서, 피어 피드백을 칭찬으로 시작하는 한 캠퍼의 이야기가 나왔다. 이 말을 듣고, 나 스스로에게 나는 긍정적인 에너지를 주는 사람인가 하고 다시 생각해 봤다. 나는 가끔은 칭찬도 하지만, 보통은 코드 스타일에 대해 가르침을 주는 입장이라, 긍정적인 에너지를 주지는 못했던 것 같다.
남의 피드백도 나의 피드백처럼 여겨서, 나 자신도 칭찬으로 피드백을 시작하며 긍정적인 에너지를 주는 사람이 되어야겠다고 생각했다.
다른 시간에는 팀 프로젝트 비스무리한 것을 했다. 각자 함수 하나씩 만들어서 해당 함수를 합치는 미니 팀 프로젝트였는데, 아무래도 다른 사람이 내 코드의 결과를 받아서 처리해야 하기 때문에, 공통된 입출력 포맷에 대해 많이 설계에 시간을 쏟았었다. 결론적으로 프로그램을 내부 로직의 시선이 아니라, 매개변수와 반환값이라는 인터페이스 관점에서 프로그래밍을 바라봤던 뜻깊은 경험이었던 것 같다.
회고-부스트캠프에서 나의 위치
부스트캠프에서 나는 어느 쪽이냐 하면, 잘하는 위치에 있다. 그렇다고, CS지식까지 잘하진 않고, 코딩 관련해서 특수한 테크닉을 정말 많이 쓰고, 코드를 구조적으로 잘 짜려고 노력하는 사람이다. 그래서인지, 대체로 나 자신이 누군가에게 가르치는 입장이 되는 경우가 많고, 코드에 대해 의미있는 피드백을 받은 적도 많이 없었던 것 같다. 이는 실력자들이 모인 부스트캠프에서 나 자신이 인정받았다는 의미도 있지만, 반대로 성장 잠재성이 크지 않다는 의미도 있다.
이번 부스트캠프 챌린지에서 이루고 싶은 것은 2가지였다.
- CS지식에 대한 확실한 이해
- 코딩 스타일 개선
이 중, 첫 번째, CS지식에 대한 확실한 이해는 미션을 하면서 CS지식이 어떻게 돌아가는지를 익히고, 학습정리를 하면서 얻어간 것 같다. 중요한 것은 2번째였는데, 부분적으로만 개선했던 것 같다. 커밋 컨벤션 사용은 할 수 있었고, 중복되는 함수를 분리하는 습관을 기를 수 있었으나, 그것을 제외하면 나 자신의 코드 스타일은 크게 바뀌지 않았다고 생각한다. (2021년과 비교해서는 달라진 것은 맞으나, 2022년 초 모던 자바스크립트 프로그래밍을 공부하면서 구조 분해 할당, 스프레드 연산자 등 ES6 테크닉과 map, filter, reduce 등 선언적 프로그래밍의 사용으로 인해 달라진 것에 가까웠다.)
대부분 가르치면서 자기 자신도 배우게 된다지만, 코딩 스타일 같은 경우는 그렇지 않은 것 같았고, 지금까지의 활동에서는 나 자신이 그렇다. 어떻게 하면 우리는 피어 피드백 시간에 가르치는 사람과 배우는 사람 모두 의미 있는 성장을 할 수 있을까?
