네이버 부스트캠프 9기 Web 챌린지 수료 후기
👂 도대체 나는 왜 개발자가 되려고 하는 걸까?
챌린지를 수료하는 시점에서 스스로에게 답하고 싶은 질문이다. 폭풍같은 4주를 돌아보기에 앞서, 나는 왜 개발자가 되고자 하는지부터 짚고 넘어가고 싶다. 부스트캠프 지원을 준비하며 시니어 개발자로부터 받은 유일한 긍정적 피드백은 다음과 같았다. ”개발자가 되고자하는 확고한 동기와 좋은 태도” 그런데 챌린지 과정에서 이러한 내 강점에 대해 끊임없이 의문을 갖게 되었다.
스스로에게 반복해서 질문했다. 이유는 명확하다. 뉴스에 흔히 언급되는 연봉말고, 겉으로 보이는 특정 이미지 말고, 진짜 ‘엔지니어’로서 내가 무엇을 하고 싶은지?가 불분명했기 때문이다. 누구나 선망할 만한 멋있는 말로 포장된 동기가 아니라, 내가 어떤 성장의 고통과 어려움을 겪어도 늘 나를 지탱해줄 확신이 필요했다.
그리고 완벽히는 아니더라도, 챌린지 과정 속에서 이 질문에 대한 답을 어렴풋이 더 완성해갈 수 있었다. 간단히 요약해서 설명하자면 다음과 같다.
첫째, 나는 문제 해결을 좋아한다. 어렸을 적부터 일을 벌리던 사람이다. 발전할 거리가 없어보여도 새로운 문제를 정의해서라도 도전하는 것을 즐겨왔던 것 같다. 그 행위들이 모두 개발과 관련된 것들은 아니었다. 그러나 그 과정과 의미가 개발과 참 닮아있다. 잠깐 경험했던 창업팀에서의 험난한 일들도, 매번 학생회장으로서 (욕먹으며) 도전했던 모든 일도 말이다. 챌린지에서 경험한 개발은 모두 문제 해결의 과정들이었다.
둘째, 개발 생태계와 문화를 좋아한다. 나는 사람을 너무나 좋아한다. 이때문에 어렸을 적부터 컴퓨터와 대화하고 빠져 사는 일명 Nerd(너드)의 정체성을 갖지 못함에 아쉬워했다. 그런데 ‘커뮤니티 속 성장’을 할 수 있는 챌린지를 겪으며 생각이 완전히 바뀌었다. 사람을 좋아하고 가까이 하는 성격덕분에 오히려 더 많은 것을 배울 수 있었다. 동료의 말, 동료의 궁금증, 동료의 표현방식, 동료의 사고의 흐름은 나에게 생각보다 더 큰 영향을 미쳤다. 개발자로서의 일하는 방식과 모습은 정의하는 이에 따라 다르겠지만, 적어도 나는 다른 개발자들과 함께 일하고 성장하는 개발자를 꿈꾼다. 개발자가 되고 싶은 동기이자, 동시에 지향점이다.
셋째, 개발이 꿈을 조각하는 일이라고 믿는다. 이전부터 내가 궁극적으로 되고자하는 이상적인 어른은 ‘좋은 질문을 던질 수 있어야 한다.’ 내 가치관과 태도에 큰 영향을 미쳤던 몇몇 순간들은 모두 나에게 어떠한 질문들을 안겨 주곤 했다. 내가 세상을 살아가며 ‘보람이 있다’고 느끼는 일들도 모두 비슷한 결이라고 생각한다. 나는 ’개발’이 여러 사람들에게 이러한 질문을 안겨줄 수 있는 모든 경험에 맞닿아 있을 수 있기 때문에 강력하다고 생각한다. 누군가의 경험과 꿈을 설계하고 실현할 수 있는 행위이기에 더욱 설렌다.
작년 이 시점을 돌아보면, 좀 웃기기도 하다. 창업팀에 개발이 아닌 다른 직무로 합류하며 나는 다음과 같은 말을 했다.
‘개발은 단순히 문제 해결의 도구니까 . . . 더 큰 그림을 바라보고 싶다 . . .’
그러나, 개발 과정의 매력과 더 큰 가능성을 알게 되었기에 개발을 아끼는 관점이 달라졌다.
🏃♀️ 챌린지에서의 몰입
부스트캠프 홈페이지에서는 챌린지를 다음과 같이 묘사한다.
제한된 시간 내 강도 높은 프로그래밍 미션 해결에 도전하며 한계를 극복합니다. 컴퓨터 공학의 기초 지식을 프로그래밍에 적용하고, 커뮤니티 안에서 동료와 함께 학습하고 방법을 연습하는 과정입니다.
너무나 정확한 묘사다…. “한계”에 도전한다. 내가 마주했던 몇 가지 한계들과 이를 극복하기 위해 발버둥쳤던 소중한 몰입의 순간들을 기준으로 카테고리화해서 정리해보겠다. (하고 싶은 말이 너무 많은데, 핵심을 담는 것도 중요하니 최대한 요약한다)
😂 대체 어떻게 학습해야 하나요.
챌린지는 컴퓨터 공학 지식을 “학습”하는 동시에 “학습하는 방법”을 익힌다. 미션의 내용들을 공개할 수는 없지만, 챌린지 과정은 소프트웨어의 동작 원리의 중요성을 몸으로 부딪히며 배울 수 있도록 구성되어 있다. 가령, 나는 운영체제의 메모리 관련된 A라는 개념을 전혀 알지 못했는데, 미션을 해결하는 과정에서 동료들과 자연스럽게 의문을 가졌던 A라는 상황이 이미 운영체제의 중요한 개념 중 하나였다.
몸으로 부딪히며 배우는 건 참 좋은 일인데 . . . 문제는 이 모든 배움들을 어떻게 나의 것으로 흡수하느냐였다.
일마다, 주마다 회고를 쓰며 한 번도 빠짐없이 등장한 고민은 더 나은 학습에 대한 것이었다. 머리가 터질 것 같기도 했지만, 학습하는 방법에 대한 치열한 고민이 결국에는 더 나은 학습의 토대를 만들어주었다. ‘기록과 정리’를 위한, 목적이 전치된 학습이 아니라, 정말 나에게 도움이 되는 학습 방식을 찾는 과정이었다.
이를 통해 몇 가지 배운 원칙이 있는데 다음과 같다.
(1) 학습의 시작은 스노우볼이 중요하다. 배경지식이 풍부하고, 시야가 넓으면 더 큰 스노우볼을 굴리듯 같은 주제에 대해서도 더 풍부하게 학습을 할 수 있다.
당연한 말이지만, 시사하는 바는 다를지 모른다. 캠퍼마다 또는 시기마다 스노우볼의 크기는 다르다. 나는 늘 동료 캠퍼들에 비해 너무나도 작은 스노우볼을 갖고 있다고 느껴왔다. 때로는 이 사실이 괴롭기도 했지만, 학습을 부스트해줄 수 있는 탄력제가 되기도 했다. 동료들의 학습을 둘러보고, 하나의 배움에서 또다른 배움으로 확장하기 위해 노력했다. 이 노력들이 모두 나의 스노우볼을 차츰 키워주는 과정이라고 믿었고 실제로 그랬다고 생각한다.
(2) 오늘은 ‘A라는 개념을 공부하자!’보다 ‘A가 왜 등장했지?’, ‘A의 특성은 뭐지?’, ‘A를 대체할 수 있는 다른 B,C와의 차이점은 뭐지?’처럼 구체적이고 연속적인 학습이 효과적이다.
여전히 수능의 학습방식에 젖어있는 사람이라 그런지 구조화되어있지 않는 파편화된 지식들을 나만의 경로에 따라 흡수하는 것이 너무나 어려웠다. 좋은 문제집만 고르면 정해진 목차와 로드맵을 열심히 따라가면 되었던 그동안의 공부방식을 버려야만 했다.
과거의 내가 git을 배울 때는 학습의 방식이 다음의 상황에 그쳤다. ‘git중요하지,,, 다른 사람들은 요즘 무슨 교재를 보지?’
VS
챌린지를 통해 나는 다음과 같이 바뀌었다. ’git이 왜 필요할까? 그럼 나는 git에 대해 무엇을 알아야하지? 이 명령어를 쓸 때 컴퓨터에서는 어떤 일들이 벌어질까? 직접 해볼까?’
극단적인 차이로 과장한 것처럼 보일지 모르겠으나, 실제로 그랬다. 지속 가능한 개발자는 늘 이면에 있는 것들을 당연하게 여기지 않고 끊임없이 궁금해하며 학습한다는 것을 깨닫게 되었다. 그래야만 특정 문제에 대해 더 깊이 있게 사고하고 ‘해결’할 수 있을테니까 말이다.
(3) 자신에게 맞는 학습 방식은 각자 다르다. 누군가의 학습 방식을 선망하고 그대로 따라하기보다, 나에게 맞는 학습 방식을 찾는 참고자료로 쓰는 것이 좋다.
수료한 시점에서도 학습 방식과 관련하여 아쉬운 점이 많다. 처음부터 내가 “모르거나” “애매하게 알거나” “틀리게 아는” 것들을 구분하고, 이를 내것으로 흡수하는 것에만 충실했다면 더 좋았을 것 같다. 그런데 나에게 맞는 학습 방식을 찾느라 몇 주는 (거의 절반은…) 방황했다.
이 방황하는 과정에서 다른 사람들의 학습 방식에 많이 휩쓸리기도 했다. “A님은 저것도 하네. 나도 해야 하는데” “B님은 저렇게 정리하네, 나도 해야지”와 같이 생각하느라 나에게 온전히 맞는 방식을 찾기보다는 이것저것 다 해야 할 것 같은 모호한 불안감만 느꼈다. 물론 제대로 실천도 못했다.
주말에 정비를 하고 몇 번 울고(?) 속상해하고(?) 고민하고 난 후에야 나만의 학습 경로를 찾는 데 집중할 수 있었다. 진짜 ‘성장’을 원해서 학습하다보면 내가 무엇이 궁금하고 어떤 것이 가장 부족하고 어떠한 순서의 학습이 나에게 잘 맞고 도움이 되는지 알게 된다. 물론! 아직 갈 길이 멀지만, 적어도 감은 잡은 것 같다.
학습은 가속도를 만들어가는 과정이다.
컴퓨터 공학이 본전공이 아닌 복수전공이고, 또 개발자를 꿈꾸게 된 시점이 늦기도 해서 출발이 많이 늦었다고 절망할 때도 있었다. 그러나 꾸준하게 달리고 가속도가 붙는다면 두렵지 않은 길이라고 느낀다.
⚙️ 개발도 계획과 큰 그림이 필요합니다. ‘설계’의 필요성과 과정
그동안 내가 해오던 개발은 정교한 설계가 필요할 만큼 복잡하지 않았다. (아니면 필요했는데 내가 부족해서 필요성을 못 느끼고 실천하지 못했거나) 개발을 하다보면 키보드를 두들기는 시간보다 생각하는 시간이 더 많아야 한다, 무작정 코드를 치기보다 설계부터 해야 한다는 말을 많이 들었을 것이다.
‘당연하지~’라고 수용하고 의식해 왔던 과거와는 달리,
설계를 제대로 하지 않았을 때의 재앙(?)을 맛본 후에 실천하는 것은 차원이 달랐다.
야생에서 배운 설계에 대한 몇 가지 레슨들은 다음과 같다.
(1) 설계는 요구사항을 분석하고 이해하는 것과 맞닿아 있다.
설계를 단순히 구현을 위한 이전 단계라고 생각하면 착각이다. 설계하는 과정에서 내가 문제 상황을 어떻게 인식하고 있는지, 제약사항들을 어디까지 고려하고 있는지, 요구사항을 어떻게 해석했는지 다시 한 번 더 명확하게 정리할 수 있다.
같은 목적과 문서를 바탕으로 개발해도 수많은 다양한 결과가 나올 수 있다. 설계의 내용은 내가 낸 결과에 대한 ‘근거’이자 ‘과정에 대한 설명서’ 역할을 할 수 있어야 한다.
처음에는 “이 프로그램은 A, B, C 메소드가 필요하고요. 이 메소드는 이런 동작을 하구요~ 저 메소드는 … “ 정도가 설계인 줄 알았다. 이건 결론에 대한 부차적인 설명에 가깝지 설계가 아니다. “A 메소드가 왜 필요한가?”를 함께 담고 있어야 한다.
(2) 단순히 많은 것들을 고려하는 것이 좋은 설계가 아니다. 내가 “왜” 이렇게 구현하고 있는지 매순간 의식하고 설명할 수 있어야 한다. 물론 ‘기술적인 지식’을 바탕으로 말이다.
베이직에서는 가독성과 확장성을 어떻게 고려하여 녹여냈는지 설명한 동료들을 보며 ‘확장성’에 집착했다. 이 프로그램이 이러한 설정값이 바뀔 수도 있지 않을까? 나중에 이 부분은 이렇게 변경될 수도 있다고 가정하고 구현해볼까? 라고 생각했다.
하지만 설계는 그리 단순한 일이 아니었다. 내가 무엇을 어떠한 목적을 갖고 설계하고 있는지 ‘의식하며’ 설계할 수 있어야 한다. 확장성은 수많은 사항들 중 하나일 뿐이다.
하나의 미션에서 ”왜 이 부분에는 이러한 형태의 데이터가 들어가나요?”라는 질문을 받은 적이 있었다. ”어… 이 부분이 이러이러한 기능을 수행해서요…“라고 애매하게 대답하며 반성했다. ”그 기능을 수행한다고 해도 데이터를 A형태로 담을 수도 있고, B형태로 담을 수도 있지 않나요?”에서 멘붕이 왔다.
나는 그동안 내게 주어진 여러 가지 선택지들을 탐색하고 비교하지 않았다. 그저 가장 먼저 떠오른 옵션이 곧장 나의 설계의 선택지가 되었다. 동작하기만 하면 첫 번째로 떠올린 데이터의 흐름이 나에게는 정답이 되었던 것이다. 이제는 여러 가능세계를 생각하며 설계할 수 있게 되었다.
시간복잡도와 공간복잡도를 엄격하게 따지며 자료구조를 선택하던 한 동료의 모습,
데이터의 흐름을 명확하게 시각화하던 한 동료의 문서,
다양하게 발생할 수 있는 예외적인 상황들을 꼼꼼하게 반영하던 동료의 생각,
들을 통해 좋은 설계가 무엇인지 고민하며 나만의 관점이 조금씩 잡혀가고 있었다.
또한, 문제를 해석한 방식뿐만 아니라 ‘기술적 지식’ 또한 설계를 뒷받침하는 중요한 토대가 되어야 한다는 점,
구현 속도가 느려지는 치명적인 이유 중 하나가 ‘설계의 부족’이라는 점도 함께 배웠다.
아직도 설계는 미스테리다. 하지만, 설계의 중요성을 알고 이를 문제 해결 과정마다 꼼꼼하게 실천하는 태도를 배운 것도 큰 도약이라고 생각한다. 무엇보다 이제 설계 단계도 심도 있게 공부하고자 하는 의지가 생겼고, 이 필요성을 ‘경험’을 통해 몸소 느꼈다는 것이 뿌듯하다.
🗣️ ‘피드백’을 통한 적당한 긴장과 학습, 동료의 관점으로 스스로를 돌아볼 수 있어요.
피드백은 언제나 사람을 긴장하게 만든다. 이성적으로는 피드백의 내용이 기대되기도 하고 성장을 위해 절실하다고 느끼기도 했다 (진심 200%로 말이다) 그런데 감정적으로는 늘 부끄럽고 묘한 긴장감을 만들었다. 미션을 제대로 완수하지 못한 날에는 불안이처럼 피어 세션이 떨리기도 했다. 어떠한 동료도 공격하는 피드백을 하진 않았으나, 받기 전부터 스스로의 부족한점이 한없이 부끄럽고 숨고 싶었다.
하지만 몇 번의 피드백 받고 나니, 동료의 관점에서 보는 나의 코드 또는 나의 해결 과정에 대한 생각이 궁금해졌다.
스스로 몇 번을 돌아봤어도 절대 생각하지 못했을 포인트를 공짜로(?) 알게 된다니 완전히 럭키비키다 🍀
피어세션 때 동료들의 질문은 내 성장에 필요한 새로운 포인트들을 깨닫게 해주는 트리거가 되었다.
(1) 질문에 대한 대답을 하는 과정에서 나의 사고 과정을 “명확하게” 표현하는 연습을 할 수 있었다.
(2) 미흡하게 대답한 부분에서 내가 어떤 부분을 고려하지 않고 설계하거나 구현했는지 돌아볼 수 있었다.
(3) 비슷한 부분에 대해 다양한 피드백이 나올 때는 다른 동료들의 다양한 방식을 흡수할 수 있었다.
피어세션은 나의 부족한 점에 대해서 피드백 받고, 동시에 강점에 대해서도 피드백 받으며 성장을 위한 적당한 긴장감을 형성해주었다. 여러 번 들었던 긍정적인 피드백의 내용은 습관으로 굳히기 위해 노력했고, 부족한 점에 대한 피드백은 늘 기록을 통해 기억하며 반복적으로 고치기 위해 노력했다.
사실 2주차 미션을 제대로 완성하지 못한 날들이 많아지며 주말에 결국 긴장감 + 부끄러움 + 자책감이 터진 적이 있었다. 낮은 완성도 때문에 피어세션도 제대로 참여하지 못하고, 동료들이 나에게 주는 배움만큼 나는 기여하지 못한다는 생각에 빠졌기 때문이다.
주말동안 마음을 다잡게 해준 것은 ’성장에 집중하자는 마음’이었다. 피드백은 “내 부족함을 아는 것”에 그치지 않고, “나를 아는 것”이라고 생각했다. 한 주를 곱씹으며 생각해보니 미션의 완성도가 떨어졌을 때도 특정 키워드에 대해 논의를 이끈 적도 있었고, 동료들에게 칭찬을 받았던 순간들도 떠올랐다. 더 잘하고 싶어서 아쉽고 화나는 이 마음을 에너지로 바꾸자고 다짐하며 다시 일어설 수 있었다.
수료한 시점에서 돌아보면 피어세션 시간 덕분에 ‘여기까지’라고 생각하기보다 더 욕심을 갖고 도전해보고, 동료들의 관점으로 또다른 목표도 설정해보고, 나를 더 깊이있고 입체감 있게 볼 수 있었다.
🚀 99도와 100도의 차이. 가장 고통스러운 마지막 “1도”를 버티는 방법
개발을 즐거워서 시작했고 선택한 것은 나였지만 모든 순간만이 즐겁지는 않았다. 베이직, 챌린지 과정 모두 마찬가지였다. 첫 시작은 늘 설레고 즐거웠어도 몰입의 순간들을 돌이켜보면 지치는 것을 견디고, 어려운 것을 한 번 더 생각하고, 이를 악물었던 기억들이 더 많다. JK 마스터님께서 집필에 참여한 ‘개발자 원칙’이라는 책에서 발전의 순간을 버전의 업데이트에 비유한다. 그 1번의 업데이트를 위해서는 100번의 머리아픔과 시도가 필요했던 것 같다.
학창시절부터 늘 새겨왔던 김연아 선수의 말이 있다.
99도와 100도의 확연한 차이를 설명하며, 마지막 1도를 버티는 것의 중요성을 담고 있다.
챌린지 과정은 마지막 1도, 포기하고 싶은 1분의 순간이 매일 찾아왔다. 미션을 이해할 때, 설계할 때, 학습할 때, 구현할 때, 동료들과 함께할 때, 매순간 한계가 왔다. 중요한 점은, 그 순간들을 자주 경험할 수 있는 ‘기회’이기도 했기 때문에 이를 극복하고 부딪히는 훈련을 함께할 수 있었다는 점이다. 이 훈련의 과정에서 효과가 있었던 해결책들은 다음과 같다.
(1) “나를 잘 관리”하기 위한 방법을 고민하고 실천하기 시작했다. 매일 꼭 지키고자 하는 명확한 목표, 시간 단위의 계획들을 통해 변수가 생겨도 나를 통제할 수 있는 시스템을 만들었다. 물론, 계획을 넘어서서 밤을 새우고 보낸 날들이 훨씬 많긴 하다. 하지만 ‘최소한의 선’과 ‘태스크의 경계’들 덕분에 매일매일을 버틸 수 있었다.
(2) 필요할 때마다 지금 이 순간에서 벗어나 먼 미래와 꿈을 바라보는 시간을 가졌다. 동료들과의 대화나, 커뮤니티 안에서 동료들이 던져주는 꿈에 대한 좋은 질문들이 도움이 되었다. 왜 개발을 시작했고, 어떤 개발자가 되고 싶고, 챌린지의 과정이 각자에게 갖는 의미를 공유했다. 당장 숨이 가쁘게 몰아붙이며 달리는 것도 중요하지만, 내가 무엇을 위해 달리고 어디를 향해 달리고 있는지 아는 것도 중요했다.
(3) 회고를 통해 몰입하고자 하는 목표를 단순화했다. 처음에는 모든 것이 다 부족해보이니 이것저것 챙길 것이 많아 방황했다. 해야 할 것은 너무 많아 보이고, 몸은 바삐 움직이는데, 얻은 것은 아무것도 없는 바보와 같았다. 이를 해결해준 것은 ‘회고’였다.
돌아보니 어쩌면 베이직에서의 연습이 큰 도움이 되었던 것 같다. 베이직에서 회고를 통해 다음날 실천할 ‘한 가지’를 정하고 집중하곤 했다. 챌린지에서는 그것이 2-3가지로 늘긴 했지만, 실천하지도 못할 10가지 이상의 추상적인 것들을 명확한 2-3가지로 좁혀서 몰입했던 것은 성장에 가장 큰 도움이 되었던 습관이었다.
초반에는 회고를 위한 회고를 하고 있진 않은가? 형식적인 회고를 하는 것은 아닌가? 스스로 의문을 품기도 했다. 하지만 후반에 갈수록 회고를 통해 도출한 액션 플랜을 실천하며 나아지는 것을 조금은(?) 체감할 수 있었다.
교육학에서는 ‘사람은 변화를 싫어한다’고 말한다. 그렇기에 변화를 만들어내는 교육은 어려운 거라고. 한계에 도전하는 경험을 갖는다는 것은 매우 소중한 일이다. 스스로를 몰아붙일 수 있는 적절한 환경과 도움과 동료가 필요하기 때문이다. 챌린지 과정은 이 모든 것이 충족되는 감사한 환경이었다.
👩💻 내가 생각하는 ‘지속가능한 개발자’에 대하여
챌린지 수료 후 일주일 간 시간을 보내며 한 달 간의 경험을 어떻게 해석하고 내면화할지 고민했다. 나는 이렇게 결론을 냈다. 챌린지를 통해 “지속가능한 개발자”가 무엇인지에 대해 나만의 확신을 갖고 실천할 수 있는 힘을 갖게 되었다. 이전에 창업팀에서 진로와 삶의 방향에 대해 고민하며 적었던 한 글이 있다. 아래의 첨부한 그 글의 표현이 내가 생각한 지속가능한 개발자를 비유하기에 적절하다.
(이전 나의 글: https://third-me-dev.tistory.com/34)
지속 가능한 개발자는 위와 같은 우상향하는 곡선을 그리며 성장할 수 있는 사람이다. 가끔은 방황하고 방향을 못 잡을 수도 있다. 챌린지 전에 무작정 프로그래머스의 알고리즘 기출 문제를 푸는 것이 자바스크립트를 알아가는 과정의 전부라고 착각했던 나의 모습처럼 말이다. 방황한다는 사실은 중요한 것은 아니다. 그 경험에서 유의미한 배움을 얻고, “다음”을 생각하며 실천하는 것이 중요하다. 챌린지에서는 이 과정을 압축적으로 경험할 수 있었다. 매주 좌절하고 속상하고 방황하지만 끊임없이 이어지고 낯설고 새로운 경험의 연속이었으므로 도전을 이어가야만 했다. 이러한 상황 속에서 답답한 감정의 늪에만 빠져 있지 않고 나아가기 위해 해야 할 것들을 배울 수 있었다.
챌린지를 수료한 것은 끝이 아니라 시작이다. 앞으로 더 어렵고 머리 아픈 순간들도, 챌린지처럼 짜릿하고 보람찬 순간들도 가득할 것이다. 여전히 걱정되는 것도 많지만 이제는 무슨 기회든 소중히 받아들이고 도전에 부딪힐 수 있는 자신감이 생겼다.
베이직에서 성장을 위한 좋은 태도에 대해 감을 잡았다면, 챌린지에서는 직접 실천하며 나만의 강점으로 흡수할 수 있었다.
“기본기가 차이를 만든다”는 챌린지 과정의 철학처럼, 개발자로서 갖춰야 할 코어역량을 조금씩 갖추어 간다.
부스트캠프에 의존하지 않고, 그 경험들을 나의 발판으로 삼으며 나아가는 개발자가 되자.