[네이버 멤버쉽 10기] 내가 못한다는 사실을 인정하는 것

🎞️ 너무 늦은 후기

다시 만난 세계

네이버 부스트캠프 10기 멤버쉽 과정에 참여한 지 벌써 3주가 지나갔다. 왜이리 늦게 후기를 작성했냐고 한다면 할 말이 없다. 귀찮기 때문일까 혹은 과정에 적응해야 해서일까, 아무런 이유를 대어봐도 핑계로만 다가올 것 같다. 한 가지 명확한 것은 의도적으로 후기를 늦게 올렸다는 것이다. 복합적인 요소가 적용되었겠지만 챌린지 과정이 끝난 그 주부터 지금까지 방황하고 있다는 생각이 내 주위를 멤돌았고 이에 대한 고민이 어느 정도 정리되기 전까지는 회고를 작성하고 싶지 않았다.

챌린지 과정에 참여하는 나의 마음 가짐은 정확히 두 개였다.

• "매일매일 나의 최대로 성장하겠다"
• "무슨 일이 있어도 멤버쉽에 입과하겠다."

이 두 가지 목표에 대해 혼란스러웠던 시절도 있었지만 스스로 생각을 정리해보며 극복해보기도 하였다. 결론적으로 챌린지 과정 당시의 나의 목표는 성공적으로 달성하였다. 하나의 문제를 해결하기 위해 몇 시간을 집중하여 달려나가기도 하였고, 그에 대한 결과물이 운이 좋게 자격 요건을 넘어설 수 있어 멤버쉽 과정에 입과할 수 있었다.

그럼 왜 너가 바래왔던 목표를 달성했는데 이렇게 칭얼거리고 있냐?

목표의 부재

"멤버쉽 과정에만 입과한다면 내 모든 것을 다 줘도 좋아"라는 생각과 목표로 달려왔고 식사, 수면을 제외하고는 모든 시간을 개발에 할애하며 최선을 다해왔다.

하지만 막상 챌린지 과정이 끝나고 한 주의 휴식 시간을 가졌을 때부터 갑자기 모든 힘이 쫙 풀리면서 느슨해졌음을 느끼게 되었다. 어떻게 비유해야할 지는 모르겠지만, 매일매일 치열하게 도파민을 느끼는 삶을 살아오다가 더 큰 도파민을 느끼지 못해 도파민 부족으로 의욕을 상실해버린 기분이었다.

그럼에도 어렵게 얻어낸 기회를 놓치고 싶지는 않았기에 멤버쉽 과정의 전체적인 목표를 설정하고 첫 주를 시작하였다.

잠깐 타올랐다 사라지는 불꽃이 아닌, 오래도록 꺼지지 않는 불씨가 될 것

챌린지 기간은 단기간에 최대한의 노력을 쏟아부어야 했던 반면, 멤버쉽은 장기간동안 내가 보여줄 수 있는 퍼포먼스를 적절히 분할해가며 성장할 수 있어야 했다. 그렇기에, 잠시동안 강렬하게 타오르는 불꽃이 아닌, 은은하게 지속될 수 있는 불씨가 되기를 희망하였다.

다만, 내가 한 가지 놓쳤던 점이 있었다. 그것은 바로 "은은하다"라는 모호한 언어를 사용하였다는 것이다.

너무 이쁜 단어이지만 오히려 나에게는 모호하였기에 그 정도를 찾아가기 위한 시도와 실패를 반복해야만 하였다. 이전에도 언급하였듯이 챌린지 과정에서는 "챌린지 = 나의 삶" 라는 방정식이 들어맞았지만 멤버쉽 과정에서는 "멤버쉽 ⊂ 나의 삶" 과 같은 관계식으로 접근하였다. 즉, 멤버쉽 과정과 나의 삶을 함께 유지하기 위한 그 밸런스를 잡아가는 것이 나에게 가장 큰 문제였던 것 같다.

지금까지 장황하게 설명하였지만 간단히 말해보면 워라벨, 아니 멤라벨을 맞추기 어렵다는 이야기였다. 개발에 치우치면 불씨가 꺼져버릴까 두려웠고 라이프에 치우치면 불씨가 너무 희미하여 이 과정을 놓치는 것 같아 불안하였다. 어차피 내 라이프라 해봤자, 운동하는 것 밖에 없었는데 그 운동이 3시간이라는 게 무시하지 못할 영역이었다.

그래서 주차별로 개발과 운동의 밸런스를 잡아보려 여러 시도를 해보았다.

• 1주차: 매 평일 19시부터 22시까지 운동 후, 집와서 00시까지 개발 후 마무리
• 2주차: 화, 목만 19시부터 22시까지 운동 후, 집와서 00시까지 개발 후 마무리
• 3주차: 매 평일 20시부터 21시까지 운동 후, 집와서 00시까지 개발 후 마무리

여러 시도를 해왔다는 뜻은, 이러한 시도들에도 멤버쉽 과정이 나에게 온전한 충만함으로 다가오지 못하였다는 증거였다. 점차적으로 운동의 시간을 줄이거나 혹은 주어진 시간 내에서 멤버쉽 과정에서 더 높은 효율을 뽑아낼 수 있는 방법을 고안해보며 더 다양한 시도를 반복해볼 것 같다.

결론적으로 이러한 현상이 발생한 이유를 정리해보면 "개발에만 전념하였던 챌린지 과정과 달리, 멤버쉽 과정에서는 개발 뿐만 아니라 여러 가지 환경 요소들을 관리할 수 있어야 했기에 혼란스러움" 이었으며, 개발과 환경 요소들의 밸런스를 제대로 잡지 못하는 이유는 "멤버쉽 과정에 대한 나의 목표가 없거나 모호"하였기 때문이라고 판단하였다.

한 번 더 개선

챌린지에서 내가 가장 크게 배웠던 점은 "복잡할 수록 쉬운 것부터 시작하자"이다.

지금 나의 상황을 미루어 보았을 때 쉽게 생각해본다면,

• "너 운동 많이 하고 싶어? 그러면 운동해"
• "너가 많이 성장하고 싶어? 그러면 개발해"

둘 중 하나를 선택하면 된다. 만약 둘 다 하고 싶다면 우선 순위를 정해서 적당한 시간을 할당하면 되고, 우선 순위는 현재 나의 목표에 의해 부여하면 된다.

물론 운동 또한 스트레스 해소제이자 잘해지고 싶은 종목 중 하나이기에 포기할 수는 없지만, 현재의 기회를 놓치지 않고 개발에 더 집중하여 성장하고 싶다는 생각이 더 크다.

이에 대해, "멤버쉽의 목표를 어떻게 설정할 수 있을까?"에 대해 고민하던 중 우연히 하나의 뉴스레터를 접하게 되었다.

노마드코더 니꼬의 뉴스 레터를 구독해두었었는데, 인생 목표 정하는 법과 관련된 글이 발간되어 읽게 되었다. 해당 레터에서는 how to stop feeling lost in tech: the wafflehouse method 라는 원문에서 소개하는 "길을 잃었을 때, 다시 목표를 설정할 수 있는 방법"에 대해 직접 경험해보고 소개하는 글을 담았다.

목표를 설정하는 방법은 생각보다 어렵지 않았다.

1. 내가 온전히 편안함을 느낄 수 있는 공간에서 48시간을 할애하여 "5년 후의 미래"에 대해 생각하고 이에 대해 생생하게 보일 때까지 써보고 그려본다.
2. 그렇게 그려진 이미지에 대해 5년 > 3년 > 1년 > 월별 > 일별 계획으로 구체화된 목표를 낮춰가며 계획을 세우고 이를 달성해나가는 것.

이 글을 읽으며 가장 크게 느꼈던 점은, "멤버쉽 과정이 내 개발 인생의 종착지가 아니라는 것" 이다. 멤버쉽 입과에 대한 목표에 너무 매몰되어 왔기에 막상 목표에 달성한 후에 방황하게 되지 않았나? 라는 생각이 문뜩 들었던 것 같다.

개발을 공부하겠다고 마음을 다잡았을 때, 서점에서 이런 저런 개발 서적들에 적혀있는 여러 예제들을 구경하면서 "이런 예제들을 책 읽듯 자연스레 이해할 수 있을 정도로 성장할 것"이라 다짐하며 동기부여를 받았던 순간이 있었는데 아마 그런 순간들이 미약하게나마 설정한 'n년 후의 목표'가 되었지 않았나싶다.

비록 아직, 이와 같은 방법을 실행해보지는 못했지만 시간들여 가까운 시일내에 도전해볼 것 같다.

"5년 뒤에 나는 어떤 개발자가 되어있기를 희망하는가"에 대해서.

🏳️ 내가 못한다는 사실을 인정하는 것

3주간의 멤버쉽 기간 동안에 느꼈고 배웠던 가장 큰 경험이었다.

비록 '5년 후 나의 모습'을 설정하진 않았지만, 그래도 '6개월 후의 나의 모습' 은 간단하게 상상해볼 수 있었다. 사실 아직 나의 문제는 해결되지 않았기 때문에 목표 설정을 위해 상상해야만 했다.

나의 코드는 내가 설계한 명확한 근거에 의해 동작하여야 하며, 나는 내가 작성한 모든 코드에 대해 논리적으로 설명할 수 있어야 한다.

내가 이런 목표를 설정하게 된 계기는 두 가지 경험을 통해 얻게 되었다.

수료자 밋업

멤버쉽 과정에 처음 입문하는 뉴비들을 위해 수료생분들을 초청하여 여러 주제에 대해 조언을 받을 수 있는 밋업이 진행되었다. 이런저런 다양한 이야기들을 해주셔서 내가 고민하고 있는 내용들 혹은 생각하지 못했던 부분에 대해 상당히 많은 인사이트를 얻을 수 있었다.

다양한 영감들 중 가장 인상깊게 들었던 이야기는 "내가 작성한 코드에 대해서 논리적으로 설명할 수 있어야 한다" 는 조언이다. 한 문장으로 살펴보면 사실 당연한 이야기처럼 보일 수 있지만 한 문장 안에 두 가지 포인트가 내포되어 있다.

• "내가 작성한", "논리적으로"

  AI가 발전한 시대에서 더욱 강조되고 있는 부분이라 생각이 든다. AI를 사용하는 것은 필수가 되었지만 이에 의존하지 않고 활용할 수 있어야 한다. AI에게 코드를 제공받을 수 있지만, 이는 내가 설계한 환경 안에서 코드가 제공된다던가 혹은 제공된 코드를 응용할 수 있을 정도의 온전한 이해가 필수적이라고 생각하였다. 그리고 이러한 조건이 충족되어야, "내가 작성하였다"라고 말할 수 있을 것이고 이에 대해 "논리적인 사고에 의해 작성된 코드"라 설명할 수 있을 것이다.

  이러한 사고 과정이 깊어지기 위해서는 나의 코드를 기록하거나 남의 코드를 깊이 있게 읽어보는 것이 중요하다고 조언을 받았다.

  내가 작성한 코드에 대해 어떻게 그런 결과물이 나올 수 있었는 지 그 과정을 기록하는 습관을 통해 나의 근거에 대해 다시 한 번 구체적으로 정리해볼 수 있고 개선할 수 있는 점을 확인하며 내가 갖는 논리적 사고에 대해 보완해볼 수 있는 기회를 얻게 된다.

  또한, 동료들의 코드를 확인해보며 다양한 개성들을 확인해볼 수 있다. 누구는 깊은 학습을 통해 세심한 부분까지 고려한 반면, 누구는 기본적인 것을 중시하여 코드 베이스의 탄탄함을 챙긴다던가 혹은 창의적인 방식을 통해 예상하지 못한 방법으로 문제를 해결하는 모습들을 확인해볼 수 있다. 이러한 점들을 피드백을 통해 확인하여 나의 코드에 녹여보려는 시도들도 '나만의 코드'를 강화하는 데 큰 도움이 될 것이라 생각한다.

• "논리적으로", "설명할 수"

  우선적으로 코드를 논리적으로 설명하기 위해서 해당 코드는 '내가 작성했다'는 전제 조건이 필요하다.

  나의 설계 하에 코드를 작성하였더라도 이를 누군가에게 다시 '논리적으로 설명'하는 것은 또 다른 역량이 필요하다. 이는 특히, 매일 진행되는 피어 세션에 의해 처절하게 느끼고 있다.

  내가 설계하며 고민한 흔적들을 문서로 작성하는 것도, 이를 기반으로 코드를 작성하는 것은 머리 속에서만 발생한 사고 과정을 통해 이루어지기 때문에 비교적 편안한 환경에서 자유롭게 작성할 수 있다. 하지만 이를 다시 입 밖으로 꺼내서 누군가에게 설명하는 것은 나의 환경과 청자의 환경을 고려하며 이해하기 쉬운 언어로 변화시켜나가며 논리적으로 전달해야 하기에 연습이 필요하다고 느꼈다.

  어쨌든 언젠간 나의 코드를 직접적으로 설명해야 하는 순간들이 많이 다가올 것이기에 매일매일 적극적으로 코드 피드백을 하여 동료들에게 질문하는 방법도, 질문에 대해 내가 답변하는 순간들도 최대한 많이 경험하면서 나만의 노하우를 쌓아가고 싶다.

의도적인 불편함

"내가 작성한 코드는 내가 설계한 명확한 근거에 의해 동작해야 한다."라는 깨달음을 확연히 알 수 있었던 경험에 해당한다.

챌린지에서는 애초에 학습해야 하는 키워드들이 내가 '모른다'고 확실히 알고 있었기에 이에 대해 충분한 학습을 진행하하고 나만의 언어로 재구성을 한 뒤에 구현에 들어갈 수 있었다. 하지만 멤버쉽 과정에서는 내가 어느 정도 '안다고' 생각한 키워드들이 등장하였고 충분한 학습과 설계 없이 구현에 들어가려다 보니 이런 저런 문제들을 마주하며 무너질 수 밖에 없었다.

더군다나, 미션의 범위가 넓어지며 디렉토리 구조부터 구현 내용까지 효과적인 설계를 위해 고민하고 결정해야하는 것들도 점차 많아지다보니 문제 해결 과정에서 혼란이 많이 발생되었던 것 같다.

항상 의식해야 하지만 "내가 안다고 생각하는 것들을 항상 의심" 해야 한다는 것을 쉽게 잊어버리는 것 같았다. 그렇다보니, 당연히 효과적인 설계는 기대하기 힘들었고 설계의 수정이 거듭되다 보니 정신적인 스트레스가 점차 쌓여갔다.

결국, 몇 일을 고민한 끝에 내가 내린 결론은 "의도적으로 불편함을 만들자"였다.

완벽한 디렉토리 구조, 효과적인 설계는 처음부터 짜잔하고 만들어진 것이 절대 아닐 것이다. 개발 역사에 몇 십년을 거쳐 만들어진 지식의 집합체이며 지금도 발전해나가는 과정일텐데 일개의 개발자(진) 한 명이 이걸 감히 논하려 해? 무례한 것.

사실 이러한 사고 과정에 이르기까지 결국 "나는 개발을 잘 못한다."라는 것을 인정해야만 하였다. 이러한 구조가 현재 상황에 대해 best practice라는 것을 알고 있지만 이게 왜 best인 지 알지 못한다면 개발에서는 best일지 언정 나에게는 결국 worst라는 생각이 들었고, 그조차 생각하지 못한다는 나의 수준을 인정해야만 하였다.

이러한 경험은 AI를 통해 코드를 제공받았을 때 이루어졌다. 어떤 디자인 패턴에 대해 학습하기 위해 AI를 통해 예시 코드를 요청하였을 때, 전지전능하신 AI께서는 미래의 예상되는 모든 문제들을 보완할 수 있는 코드를 작성해서 제공한다.

하지만 미천한 나는 당연히 제공받은 모든 코드를 이해할 수 없었고 나에게는 두 가지 선택지가 나왔다.

1. 해당 코드를 최대한 이해해보고 응용하여 나의 코드로 가져다 사용할 것인가
2. 해당 코드를 전부 제거하고 내가 온전히 이해한 코드만 가져다 사용할 것인가

이 또한 사람 성격에 따라 다른 선택이 나올 것이지만, 자존심빼면 시체인 나는 2번을 선택하였다.

사실 내가 '알고 있다'는 것에 대해 의심하고 있는 상태였기에, AI가 제공된 코드에 대해 흐름을 이해하고 '아 이렇기에 저렇게 작성했구나'라고 말하는 수준에 그쳤다는 것 또한 내가 해당 코드를 명확히 이해하였다고 말할 자신이 없었다.

그리고 2번에 맞춰 "의도적인 불편함" 을 만들어냈다. 디자인 패턴은 무슨, 하나의 파일에 모든 코드를 절차적으로 작성하고 4번의 depth까지 들어가는 함수를 만들어내고 중복적인 코드를 무한정 만들어냈다. 그렇게 나는 '동작'에만 집중해서 코드를 작성하였다.

그 후에는 당연히 눈에 보이는 불편함을 하나씩 제거해나갔다. 물론 나의 근거에 의한 불편함을 정의하고 이를 개선시켜나가는 과정을 하나씩 기록하였다. 그렇게 눈에 보이는 불편함들을 제거하고 나니, 나름 그 체계가 잡히고 나만의 효율적인 구조가 눈에 보이기 시작하였던 것 같다.

물론 내가 생각하지 못했던 부분에 대해 개선해볼 수 있는 점도 분명 존재하기 때문에 이러한 부분은 AI를 적극적으로 활용해볼 수 있었다. 내가 작성한 코드와 내가 왜 그렇게 작성하였는 지에 대해 명확히 설명하고 이러한 접근법에 대해 개선해볼 수 있는 점을 제공해달라는 식의 프롬프트를 작성하였고 AI는 "정말 잘했다🤗"는 칭찬과 함께(사실 이게 가장 중요) 개선해볼 수 있는 점을 여러 제공해주었다.

신기하게도 이러한 개선점들을 하나씩 고쳐나가고 스스로 기록하며 정리하다보니 점차 내가 원했던 디자인 패턴에 비슷해져감을 느꼈던 것 같다. 물론 그런 디자인 패턴으로 접근하기 위해 의도적으로 코드를 작성해나갔지만, 내가 직접 불편함을 겪고 "어떠한 불편함을 개선하기 위해 코드를 수정하다보니 이러한 디자인 패턴이 나왔네? 그러니깐 코드나 디렉토리 구조가 이렇게 짜여지는 구나" 라는 것을 깨달으며 스스로 기록해볼 수 있는 소중한 경험을 해나갈 수 있었다.

당연히 그런 과정을 통해 도출된 결과물이 알라딘의 램프마냥 모든 문제를 해결해주지는 않겠지만, 중요한 것은 이러한 경험이 "직접 마주한 불편함을 해소하기 위해 나만의 근거로 개선된 코드" 를 작성해봤다는 경험과 과거의 불편함을 해소해주는 현대의 여러 도구들이나 클린 코드와 같은 컨벤션이 "왜" 탄생하게 되었는 지를 고민하며 사용해볼 수 있는 조그만한 습관을 제공하였다는 점에서 의의를 갖는다고 생각한다.

🏅 결론

글을 시작할 때, 나는 "의도적으로 후기를 늦게 올렸다고" 작성하였다.

앞으로도 매주 회고를 적지는 않을 것 같다. 매주 작성하다보면 의도적으로 적어야 한다는 강박이 나도 몰래 스멀스멀 올라올 것 같기 때문이다. 아직 정리되지 않은 깨달음으로 회고를 작성했다가 매 주, 그 전 주 회고에 대해 수정만 할 것 같다는 생각이 들었다.😅

다만, 주기적으로 작성되여야 할 필요성은 느낀다. 딱 3주 정도면 내가 그 동안 경험하고 내린 결론들에 대해 정리하여 회고를 작성할 수 있을 것 같다. (물론 지금 작성한 시기가 딱 3주가 지났기 때문이라는 사실은 비밀이다.)

그러면 다음 3주까지 다시 한 번 열심히 실패하고 경험해가며 새로운 인사이트들을 얻어가보려 한다.

1. 5년 후 나의 모습을 상상하며 목표를 세워보자
2. 내가 작성한 코드는 논리적으로 내가 설명할 수 있어야 하는 코드여야 한다.