네이버 부스트캠프 10기 베이직 과정 후기

들어가면서

2주 전, 네이버 부스트캠프 웹/모바일 10기에 모바일(Android) 과정으로 참여했고, 지난 주 금요일에 베이직 과정을 끝마쳤습니다. 이번 회고에서는 부스트캠프의 베이직 과정에 대한 소감과 함께 2주간의 여정이 저에게 어떤 영향을 미쳤는지에 대해 이야기해보고자 합니다.

베이직 입과 전

베이직 입과 전 기존의 제 개발 공부 방식을 돌아보면, 저는 온라인 강좌 수강이나 커리큘럼이 세세하게 정해진 부트캠프 참여를 통해 개발 지식을 쌓아왔습니다. 주어진 강의를 듣고 따라 하며 "이러한 기술은 그냥 이렇게 쓰는구나" 하고 고개를 끄덕이는 수동적인 학습 방식에 익숙했습니다. 문제를 해결할 때도 근거 있는 결정보다는 "이거 많이 쓰던데", "저거 좋다던데"와 같이 타인의 의견에 의존하는 경향이 컸습니다. AI를 활용할 때도 제 사고를 확장하는 도구라기보다는, 막히는 부분에서 빠르게 정답을 찾기 위한 수단으로 의존하는 경우가 많았습니다.

여행에 비유하자면 마치 패키지 여행같은 학습 방법을 지속한 셈입니다. 가이드의 안내에 맞춰 "이거 하세요", "저기 가세요"와 같은 방식이었습니다. 베이직 과정의 OT에 참석했을 때, "Learning by Doing"이라는 키워드를 강조했지만, 아무리 그래도 처음부터 시작하는 사람들한테 기본적인 건 알려 주겠지, 기본적인 문법은 알려주지 않을까?라는 생각으로 버티고 있었던 것 같습니다.

베이직의 방식: THIS IS THE WAY

그러나 베이직 과정은 첫날부터 저를 야생으로 내던졌습니다. 기본 문법 대신 바로 요구사항을 분석해 결과를 구현하는 미션을 마주했습니다. 그제서야 부스트캠프의 모집 안내에 있던 FAQ 중 하나가 떠올랐습니다.

"베이직에서 프로그래밍 언어에 대해 연습할 수 있는 기회가 있습니다. 따라서 비전공자도 참여 가능하며 앱이나 웹 개발 경험이 없어도 지원할 수 있습니다. 다만, 적어도 하나의 프로그래밍 언어로 논리적인 코드를 작성해 본 경험이 있어야 합니다."

이전에 프론트엔드를 공부하면서 자바스크립트를 다뤄 본 적은 있었지만, 코틀린은 처음이기에 빠르게 기초적인 문법들을 공부하며 익숙해져야 했습니다. 그리고 문법에 적응할 틈도 없이, 매일같이 새로운 미션들이 쏟아져 나왔습니다.

쏟아지는 미션들

⛓️‍💥 작은 문제 해결 경험을 반복하며, 직접 부딪히고 배우기

미션의 종류는 여러가지였습니다. 요구사항을 읽고 코드로 구현하거나, 설계하는 미션, 특정 개념에 대해서 깊게 조사하는 미션 등 종류를 가리지 않고 다양한 영역에서 문제 해결력을 기를 수 있는 미션들이었습니다. 하-중-상 난이도로 구성되어 있었는데, 상 난이도의 미션을 처음 본 날에는 '이걸 하루만에 어떻게 다 하지?'라는 말을 뇌까렸던 적도 있었습니다.

그래도 어떻게든 당일 미션은 당일 내에 해결하자는 목표를 세우고, 수단과 방법을 가리지 않고(그렇다고 부스트캠프의 생활 수칙에 위배되는 방법을 사용한 건 당연히 아닙니다) 문제를 해결해냈습니다.

미션 제출 끝, 피어 피드백 시작

🔭 시야를 확장하고 한발 뒤에서 돌아보기

미션 제출이 끝나면, 피어 피드백을 진행해야 했습니다. 같은 그룹으로 묶인 캠퍼들의 제출 결과물을 살펴보면서 댓글을 통해 피드백을 하는 세션이었습니다. 사실 모든 캠퍼들의 결과물을 피드백하기는 어려웠습니다. 미션을 당일에 해결하는 것부터가 버거웠으니까요. 그래도 시간이 나면 최대한 많은 캠퍼들의 코드를 보면서, 같은 문제에 대해 다른 방식으로 접근한 부분이 있는지를 찾아보려고 노력했습니다. 그리고 인상깊었던 접근법이 있었다면 이를 다음 미션의 문제 접근법에 녹여내기도 했습니다.

데일리 회고

피어 피드백까지 완료하게 되면, 마지막으로 하루를 돌아볼 수 있는 데일리 회고 섹션이 남아 있었습니다. 매일 미션 수행 과정을 돌아보며, 성장했던 점과 아쉬웠던 점을 다시 한번 생각해 볼 수 있는 시간이었습니다.

베이직에서 잘 성장하려면?

베이직 과정을 시작할 때 처음으로 정했던 목표는 다음과 같았습니다:

스스로 문제를 정의하고, 다양한 관점에서 분석해 주도적으로 해결하는 능력을 갖춘 개발자가 되기

베이직 과정이 완전히 종료된 지금, 여태까지의 회고를 돌아보며 생각해 봤을 때 이 목표가 100% 달성된 것은 아니라고 생각합니다. 그러나 베이직을 통해 얻은 경험과 깨달음은 목표를 향해 나아갈 수 있는 단단한 발판이 되어주었습니다. 특히, 문제 해결력 테스트를 준비하며 프로그래머스에서 크레인 인형뽑기 게임이라는 문제를 풀어 봤는데, 베이직 이전의 저라면 '이게 어떤 문제지?' 하고 한참을 고민하다 포기했을 문제였습니다. 그러나 베이직 이후의 저는 베이직에서 배웠던 분석-설계-구현 방법을 되새기며 문제를 풀 수 있게 되었습니다.

예를 들어, 크레인 문제를 마주했을 때, 이전의 저라면 막막함에 바로 검색부터 하거나 AI에게 문제를 풀어달라고 요청했을 겁니다. 하지만 이제는 이렇게 사고하게 되었습니다.

1. (분석) "요구사항이 뭐지? 크레인이 인형을 뽑고, 바구니에 담는다. 같은 인형 두 개가 연속으로 쌓이면 터진다. 최종적으로 터진 인형의 총 개수를 구해야 하네." -> "이걸 데이터로 표현해볼까? 게임 보드는 2차원 배열(Array<IntArray>), 크레인 작동 위치는 1차원 배열(IntArray), 인형을 담는 바구니는 위에서 넣고 빼야 하니 Stack이 적합하겠다."

2. (설계) "크레인 작동 위치 배열을 순회하면서 각 위치에 해당하는 보드의 열을 탐색해야지. 맨 위부터 0이 아닌 인형을 찾아서 뽑고, 그 자리는 0으로 만들어야겠다. 뽑은 인형을 바구니(스택)에 넣기 전에, 바구니의 맨 위 인형과 같은지 비교해야겠다. 같으면 바구니에서 인형을 빼고(pop) 사라진 인형 개수(+2)를 기록, 다르면 그냥 바구니에 넣자(push)."

3. (구현) 이 설계에 따라 코드를 작성하니, 이전보다 훨씬 자신감 있고 논리적으로 문제를 해결할 수 있었습니다.

이 경험을 통해 '어떻게 성장해야 하는가'에 대한 저만의 답을 어렴풋이 찾게 되었습니다.

의식적인 문제 분석-설계-구현

문제의 요구사항을 수동적으로 읽고 바로 코딩에 돌입하는 것이 아니라, '컴퓨터의 관점'에서 문제를 재정의하는 과정이 핵심입니다. "이 문제를 해결하기 위해 어떤 데이터가 필요하고, 그 데이터는 어떤 상태를 가지며, 어떻게 변해야 하는가?"를 끊임없이 질문해야 한다고 생각합니다.

사고의 틀 확장하기

'정답은 하나'라는 생각에서 벗어나야 합니다. 내가 작성한 코드가 동작하더라도, 그게 유일하거나 최선의 방법은 아닐 수 있습니다. 베이직 과정의 피어 피드백은 바로 이 지점에서 가장 강력한 학습 도구가 되었다고 생각합니다. 다른 캠퍼의 코드에서 when을 활용한 깔끔한 분기 처리, 혹은 scope function을 이용해 코드를 간결하게 만든 것을 보며 "아, 이렇게도 생각할 수 있구나!"하고 감탄했던 순간들이 있었습니다. 저는 이러한 과정을 그냥 넘어가지 않고 기억해 두었다가 다음 미션에 의식적으로 적용해 보곤 했습니다. 적극적으로 동료의 코드를 분석하고, 궁금한 점은 질문하며 다양한 접근법을 흡수하려는 노력이 시야를 넓혀줄 수 있었습니다.

AI 잘 활용하기

베이직 과정을 시작하기 전 제가 세웠던 목표 중 하나는 AI에 의존하지 않는 개발자가 되는 것이었습니다. 베이직 과정을 진행하면서 해당 목표를 최대한 지키기 위해, 미션을 진행하다 막혔을 때 "이 미션을 풀어줘"가 아닌 "이 문제를 해결하기 위해 Stack을 사용하려고 하는데, 시간 복잡도 측면에서 괜찮은 선택일까?" 와 같이 문제 분석과 설계를 통해 내 생각을 먼저 제시하고 AI의 의견을 구하는 방식으로 활용했습니다.

꾸준하게 회고하고 성장하기

매일 작성했던 데일리 회고는 그 성장을 위한 체크포인트와 같은 역할을 해 주었습니다. "오늘은 시간 분배에 실패해서 상 난이도 미션을 해결하기까지 시간이 오래 걸렸다" 와 같은 아쉬웠던 점을 기록했기에, 다음 날 "중요한 기능부터 구현하고, 리드미 작성은 나중에 하자"는 구체적인 개선 전략을 세울 수 있었습니다. 실수를 부끄러워하지 말고, 오늘의 실패를 내일의 성공을 위한 데이터로 삼는 태도가 꾸준한 성장의 원동력입니다.

돌아보니 아쉬웠던 점

치열했던 만큼, 당연히 아쉬움도 많이 남았습니다.

• 복습과 추가 학습의 부재: 매일 쏟아지는 미션을 해결하는 데 급급해, 한번 사용했던 개념이나 API를 깊이 있게 파고들지 못했습니다. associateBy 같은 편리한 함수를 "어디선가 봤는데..." 하고 넘어간 뒤 다시 for문으로 구현하는 비효율을 겪기도 했습니다. 남는 시간을 최대한 활용해 배웠던 내용들을 완전히 내 것으로 만드는 시간을 가졌다면, '아는 것'과 '쓸 수 있는 것'의 간극을 더 효과적으로 줄일 수 있었을 겁니다.

• 체력적 아쉬움: "어떻게든 당일 미션은 당일 내에 해결하자"는 목표는 좋았지만, 종종 수면 시간을 줄여가며 목표를 달성했습니다. 당연히 다음 날 집중이 잘 될 리가 없었고, 특히 후반부로 갈수록 체력의 중요성을 절감했습니다.

• 조금 더 많은 시간을 리드미가 아닌 문제 해결에 투자했다면: 베이직 과정 내내 문제 해결 과정과 고민을 상세히 기록하는 것에 많은 시간을 쏟았습니다. 덕분에 언제나 리드미가 상세하게 작성되어 있어서 많은 도움을 받았다는 캠퍼분들의 피드백도 종종 볼 수 있었습니다. 물론 기록은 중요하지만, 때로는 핵심 로직 구현에 더 집중해야 할 시간에 문서 작업에 매몰되기도 했습니다. 문제 해결력 테스트에서 시간 압박을 크게 느꼈던 이유도, 정해진 시간 내에 핵심을 꿰뚫고 빠르게 구현하는 훈련이 상대적으로 부족했기 때문일지도 모릅니다. '잘 설명하는 것'과 '잘 푸는 것' 사이의 균형을 찾는 것이 중요했습니다.

베이직 과정에서 알게 된 강점과 약점

2주간의 베이직 과정은 단순히 코딩 기술을 연마하는 시간을 넘어, 개발자로서의 저 자신을 정밀하게 진단하고 이해하는 계기가 되었습니다. 매일의 미션과 회고를 통해 저는 몇 가지 뚜렷한 강점과 개선이 필요한 약점을 발견할 수 있었습니다.

강점

가장 큰 강점은 문제를 데이터의 관점에서 바라보고 체계적으로 해결책을 설계하는 '데이터 중심 사고'였습니다. 복잡한 요구사항을 마주했을 때, 저는 곧바로 구현에 뛰어들기보다 어떤 데이터 구조가 문제의 본질을 가장 잘 표현할 수 있을지 먼저 고민했습니다. 이러한 습관 덕분에 복잡한 문제 앞에서도 쉽게 길을 잃지 않을 수 있었습니다.

더불어, 한번 작성한 코드에 만족하지 않고 끊임없이 더 나은 코드를 추구하는 '리팩토링 의지'와 실수를 성장의 발판으로 삼는 '성장형 마인드셋'은 저를 앞으로 나아가게 한 원동력이었습니다. 단순히 '동작'하는 코드를 넘어 품질, 가독성, 유지보수성을 높이기 위해 노력했고, 동료의 코드나 저의 과거 실수에서 배운 점을 다음 미션에 꼭 적용하려 했습니다. 오류 로그 하나하나를 학습 기회로 삼아 근본 원인을 파고드는 과정은 지식을 더욱 단단하게 만들었습니다.

약점

하지만 이러한 강점의 이면에는 명확한 약점들도 존재했습니다. 가장 먼저, 새로운 언어(Kotlin)에 대한 유연성과 적응성의 부족이 발목을 잡았습니다. Kotlin이 제공하는 강력하고 간결한 API를 충분히 활용하지 못하고, 이전에 익숙했던 방식으로 비효율적인 '돌아가는 길'을 택하는 경향이 있었습니다. 이는 언어와 API에 대한 피상적인 이해로 이어졌습니다. 함수의 이름만 보고 기능을 추측하다가 예상치 못한 결과를 마주하고 디버깅에 시간을 쏟는 일이 잦았는데, 공식 문서를 통해 반환 값과 부수 효과를 꼼꼼히 확인하는 습관의 중요성을 절감했습니다.

이러한 비효율은 '시간 관리'의 어려움으로 이어졌습니다. 깊이 있는 탐구를 선호하는 성향과 언어 숙련도 부족이 맞물려 미션 해결 시간이 예상보다 길어졌고, 조급함으로 이어져 AI에 대한 의존도를 높이는 악순환을 만들었습니다. 학습의 깊이와 속도, 그리고 AI의 '도움'과 '의존' 사이에서 건강한 균형점을 찾는 것이 챌린지 과정을 시작하기 전까지 해결해야 하는 과제로 남게 됐습니다.

마지막으로, 문제의 '정상 경로'를 구현하는 데에는 익숙했지만, 예상치 못한 '엣지 케이스'나 예외 상황에 대한 '방어적 사고'가 부족했습니다. 사용자의 잘못된 입력, 데이터의 경계 값 등 비정상적인 경로에 대한 예측과 방어 로직 설계에 소홀했던 점은 실제 안정적인 서비스를 만들어야 할 때 치명적인 버그로 이어질 수 있는 부분이라고 생각합니다.

결론적으로 베이직 과정은 저에게 '데이터 중심적이고 끈기 있는 학습자'라는 강점을 확인시켜 주었지만, 동시에 '새로운 환경에 대한 적응, 시간 관리, 방어적 코드 작성'이라는 명확한 성장 과제도 함께 안겨주었습니다. 다른 무엇보다도 이러한 강점과 약점에 대한 명확한 인지가 베이직 과정의 가장 큰 수확이며, 앞으로 시작될 챌린지 과정을 헤쳐나갈 가장 중요한 지도가 될 것이라고 생각합니다.

문제 해결력 테스트와 챌린지 합격

10일차 미션이 끝난 뒤 바로 다음 날인 토요일에 문제 해결력 테스트를 진행했습니다. 지난 기수와 다르게 10기부터는 베이직 과정에서의 활동과 문제 해결력 테스트 결과, 그리고 지원서를 종합해 챌린지 입과 여부를 판단한다고 했는데, 그래도 문제 해결력 테스트를 너무 못 보면 챌린지 과정에 입과할 수 없을까봐 어떻게든 지난 베이직 미션들을 돌아보며 문제 해결력 테스트를 준비했습니다.

문제 해결력 테스트는 구현 문제, CS 문제, 서술형 문제 세 가지였습니다. 문제의 난이도가 어려웠다고 생각하지는 않습니다. 베이직 과정을 충실하게 진행했다면 대부분의 문제는 수월하게 풀 수 있는 정도의 난이도라고 느꼈습니다. 하지만 문제를 풀면서 정말 확실하게 와닿았던 것은 스스로가 아직 시간적 압박에 잘 대처하지 못한다는 점이었습니다. 구현 문제도 3문제 중 1문제밖에 풀지 못했을 정도로 시간에 쫓기며 문제를 풀었고, 그래서 좋은 결과를 기대하지는 않고 있었습니다.

결과를 확인하기 전까지 마음을 졸였지만, 다행히 챌린지 과정에 합격할 수 있었습니다. 베이직 과정 동안 매일 치열하게 고민하고, 꾸준히 회고하며 성장하려 했던 노력을 좋게 봐주신 것이 아닐까 생각합니다. 만약 다음 기수에 지원하시는 분들이라면 미션을 빨리 해결하고 문제 해결력 테스트 대비에 집중하는 것 보다, 베이직 과정을 성실하게 수행하면서 더 많은 것들을 얻어가겠다는 마음으로 2주간의 여정을 시작하면 좋을 것 같습니다.

나오면서: 앞으로의 길

다음 주 월요일부터는 드디어 챌린지 과정이 시작됩니다. 베이직과는 다르게 코어 타임이 정해져 있고, 동료들과 함께 피어 피드백을 통해 서로의 문제 해결 방식에 대해 토론하며 사고를 확장해나가는 경험을 한달동안 하게 됩니다. 이전 수료생 분들의 후기를 찾아보면 베이직과는 차원이 다른 미션들을 수행하게 되고, 한달 내내 제대로 잠을 자본 적이 거의 없다고 할 정도로 강도높은 과정이 될 것 같습니다.

베이직 과정이 정해진 코스 없이 스스로 길을 찾아야 하는 '탐험'이었다면, 챌린지 과정은 동료들과 함께 더 험난한 산을 오르는 '등반'과 같을 것이라고 생각합니다. 베이직에서 얻은 '스스로 생각하는 근육'과 '데이터 중심 사고'라는 나침반, 그리고 '회고를 통한 성장'이라는 비상식량을 잘 챙겨서, 앞으로의 챌린지 여정도 무사히, 그리고 즐겁게 헤쳐나가고 싶습니다. 그럼 다음에는 챌린지 과정의 회고로 찾아오겠습니다! 🧑‍💻