4주 동안의 챌린지 과정이 마무리 되었습니다.
4주차의 회고는, 전체 과정을 돌아보며 작성했습니다.
챌린지 과정 이전의 저는 책 혹은 검색을 통해 혼자 학습하고, 혼자 개발하는 것에 익숙했습니다. 그리고, 정답이 존재하는 문제에서 고득점을 받는 것에만 집중해왔습니다. 하지만, 챌린지 과정은 정답이 없어서 혼란스러웠습니다.
따라서, 1주차에는 이 챌린지 과정이 단순히 멤버십을 가기 위한 하나의 평가라고 생각했고, 주어지는 미션을 모두 마무리해야 한다는 강박이 있었습니다. 피어 세션에서 동료 캠퍼의 결과물을 보며, 적지 않게 질투심도 느끼고, 경계하기도 했던 것 같습니다.
하지만, 4주가 지난 지금, 챌린지 과정의 의미를 조금은 깨닫게 되었습니다. “나를 알고 성장하기”라는 말의 핵심은 “나의 속도를 파악해라”였던 것 같습니다.
단순히 해결을 위해 기계적으로 코드를 작성하는 것이 아닌, 나에게 알맞은 속도로 필요한 부분은 학습하고, 실현 가능한 목표를 설정하고 달성하는 과정에서 더 근거 있는 설득력 있는 개발자로 성장하는 방법을 배운 것 같습니다.
또, 피어 세션을 통해 남을 부러워하고 질투하는 것이 아니라 내가 어떤 부분이 남들에 비해 부족한지를 알 수 있었고, 그 점을 개선해 나갈 수 있는 기회를 얻은 것 같습니다.
→ 앞으로도 제 속도에 맞는 학습 - 분석 - 설계 - 구현의 과정을 유지할 것 같습니다. 무리한 목표를 세우고 기계적인 코드 작성을 하는 개발자가 아닌 챌린지 과정에서 발전시켜 온 실현 가능한 목표를 설정하고 그 목표를 달성하는 개발자가 되보려 합니다.
챌린지의 미션에는 정답이 없습니다. 그 미션을 해결하는 정해진 방법도 없습니다. 무엇을 할지, 어떻게 할지는 모두 제가 스스로 결정하고 행동해야 했습니다. 마치 제 속도를 제가 찾아냈듯이, 얼마나 학습하고 어떤 목표를 세워 해결해 나갈지는 오롯이 제 몫이었습니다.
따라서, 저는 주차가 진행될수록 미션을 해결하는 것과 함께 새로운 목표를 세우는 것에도 집중해 보았습니다. 두 번째 주차에는 전체 설계에 대한 그림을 그리고, 피어 세션을 위한 발표를 준비했습니다. 세 번째 주차에는 “소프트웨어 장인”이라는 책에서 인상 깊었던 “낮은 사기는 개발자들의 주된 실패 요인”의 “낮은 사기”를 해결하기 위해 가벼운 질문을 통해 분위기를 끌어 올리고, 더 많은 피드백 질문을 하려고 노력했습니다. 마지막 주차에는 3주차 동료분에게 영감을 얻어 피어 세션에서 더 적극적으로 질문하고 답변하기 위해 모든 그룹 캠퍼들의 코드를 여러 테스트 케이스로 실행해 보는 도전을 했습니다.
물론, 이러한 도전이 매일 성공적이지는 않았습니다. 하지만 새로운 도전에서의 작은 성공이 도전 자체를 즐거움으로 바꾸어주었고, 매주 새로운 도전을 할 수 있는 계기가 되었던 것 같습니다.
사실 저는 새로운 것에 잘 도전하는 개발자는 아니었던 것 같습니다. 하지만, 챌린지에서의 경험을 통해 제 한계를 조금씩 갱신해 나갈 수 있었던 것 같습니다.
→ 사실 저는 새로운 것에 잘 도전하는 개발자는 아니었던 것 같습니다. 하지만 이제는 새로운 도전을 통해 제 한계를 갱신할 수 있는, 그리고 여러 방법을 시도해보며 저의 성장을 위해 최선의 선택을 할 수 있는 개발자가 되보려 합니다.
네이버 부스트캠프를 시작하기 전에는, 개발하면서 생긴 궁금한 점이나 공부한 내용을 노션이나 블로그에 간단히 정리하는 정도에 그쳤습니다. 필요한 정보를 그때그때 찾다 보니, 지식들을 체계적으로 정리하지는 못했던 것 같습니다. 하지만 챌린지 과정을 진행하면서, 단순히 지식을 학습하고 정리하는 데 그치지 않고, 이를 도식화하는 시도를 해보았습니다. 도식화를 통해 각 용어와 개념들 사이의 연결고리를 시각적으로 확인할 수 있었고, 이를 통해 더 체계적으로 지식을 정리하고 활용할 수 있게 되었습니다.
또한, 피어세션을 준비하면서 제가 설계하고 구현한 내용을 명확하게 표현할 필요성을 느꼈습니다. 잘 동작하는 코드가 항상 다른 사람들이 이해하기 쉬운 것은 아니었기 때문에, 설계 과정이나 동작 흐름을 더 잘 설명하기 위해 다이어그램을 그려 첨부했습니다. 이 부분은 2주차에 동료 캠퍼분의 README
를 보고 배워야 겠다고 생각한 부분이었습니다. 저도 동료분의 이해가 쉬웠듯, 제가 그림을 통해 동료분들이 더 쉽게 이해할 수 있을 것이라 생각했습니다. 그 결과, 캠퍼분들이 이를 통해 내용을 더 쉽게 이해할 수 있었다고 말해주셨던 기억이 납니다.
→ 그럼에도 불구하고, 저는 여전히 “왜”라는 질문을 충분히 던지지 못한 것 같습니다. 배경 지식에 대한 기존의 이해도를 파악하고, 어떤 부분을 더 공부해야겠다는 생각은 많이 했지만, 그 지식이 왜 필요한지에 대해서는 깊이 고민하지 않았던 것 같습니다. 앞으로는 단순히 지식을 학습하는 것에 그치지 않고, 그 지식이 왜 필요한지, 그리고 그것이 어떤 맥락에서 활용될 수 있는지를 더 깊이 생각해보고 정리하는 습관을 들이고 싶습니다.
“나의 성장이 온전히 내 힘만으로 이뤄진 것이 아니다”
챌린지 과정 동안, 저는 동료들과 함께 성장하는 것이 얼마나 즐거운 일인지, 그리고 얼마나 중요한지 깊이 깨닫게 되었습니다. 처음에는 혼자 문제를 해결하는 데만 집중했지만, 시간이 지날수록 동료 캠퍼분들과의 함께하는 것이 문제 해결과 학습에 얼마나 큰 도움이 되는지 알게 되었습니다.
처음에는 동료 캠퍼분들을 경쟁 상대로 보았던 것 같습니다. 그래서 좋은 설계나 구현 내용을 보면 궁금한 점을 질문하기보다는 속으로 질투를 느꼈던 것 같습니다. 하지만 이런 태도는 저에게도 동료 캠퍼분들에게도 도움이 되지 않았다는 것을 깨달았습니다.
그래서 2주차부터는 스터디 그룹의 캠퍼분들의 장점을 나도 따라 해보는 시도를 했습니다. 2주차에는 설계를 그림으로 나타내기, 3주차에는 피어 세션의 분위기를 밝게 유지하기, 4주차에는 다양한 방법으로 코드를 테스트해보고 질문하기 등을 시도했습니다.이렇게 다른 분들의 장점을 흡수하려고 하다 보니, 그것들을 제 강점 중 하나로 만들어 낼 수 있었고, 이 강점으로 다시 다른 캠퍼분들에게 영향을 줄 수 있었다고 생각합니다.
→ 개발자로서 동료와의 협력, 특히 동료와의 소통은 매우 중요한 요소라고 생각합니다. 동료들과의 소통을 통해 제가 몰랐던 것을 배우고, 또 제가 아는 것을 공유하며 정리하는 과정에서 더 큰 성장의 기회를 얻을 수 있다는 확신이 생겼습니다. 동료와 함께 성장할 수 있는, 장점을 흡수하고 제 강점을 전달할 수 있는 개발자가 되고 싶습니다.