부스트캠프 챌린지 완주 후기
부스트캠프 웹·모바일 10기 챌린지 완주 후기
❝ Learning by Doing for Problem Solving ❞
(개인적인 인사이트를 덧붙였다. 원문은 “Learning by Doing”)
1. 서론
개발 공부는 작년 9월 내일 배움 캠프에서 Swift 트랙에 참여하며 본격적으로 시작했다.
수료가 끝나고서는 이력서를 채우기 위해 혼자 어플을 만들어보며 시간을 보냈다.
물론 뜻대로 잘 흘러가진 않았고, 3개월동안 앱스토어에 올릴만한 제대로 된 앱을 만들어내지 못했다.
이땐 CS 지식과 관련해서는 아는 게 거의 없었고, AI를 어떻게 활용할지에 대한 생각도 전혀 없었다.
그러던 중 네이버 부스트캠프를 모집 중이란 배너를 보고 베이직에 도전하게 되었고,
다행히 문제해결력 테스트까지 통과하여 지난 7월 14일 챌린지 과정을 시작했다.
2. 도전 전 나의 성장 목표
챌린지 OT를 보며 AI 시대의 개발자, 문제 해결력, CS 지식 등이 챌린지 과정의 주요 키워드라고 생각했다.
각 키워드에 대한 나의 이해는 다음과 같았다.
AI 시대의 개발자로서 AI를 잘 쓴다는 것은 구현을 맡기지 말고 내 아이디어를 더 정교하게 다듬는 보조 도구정도로만 활용하는 것이라 생각했다.
즉, 내 생각의 정리와 검증에 대해서만 초점을 두었다.
문제 해결력에 대해선 요구 사항을 명확히 정의할 수 있는 능력이 핵심이라고 생각했다.
답이 없거나 모르는 상황에서 자신만의 정의를 내릴 수 있는 것이 가장 중요해보였다.
CS 지식은 다소 수동적으로 받아들이고 있었는데,
단순히 커리큘럼을 따라가며 암기하면 끝인 단순한 이론들 정도로만 생각했다.
당시엔 구체적으로 목표를 세워야 한다는 생각을 갖지 못했기 때문에,
“CS 지식을 충분히 가지기”나 “문제를 스스로 정의할 수 있는 개발자”정도로 목표를 세웠던 것 같다.
구체적인 목표 달성 기준이 없었고, 기록해둔 것도 아니기 때문에 챌린지 과정 중에 이 목표를 떠올리는 일은 거의 없었다.
그러나 흥미롭게도 챌린지의 핵심 키워드들이 자연스레 목표를 달성할 수 있는 방향으로 나를 이끌었고,
CS 지식이나 문제 해결력, AI 활용 등에서 예상보다 큰 성장을 경험했다.
3. 학습과 구현 그리고 몰입
챌린지 미션을 해결하는 과정은 크게 학습과 구현으로 나눌 수 있었다.
그리고 각 파트에 얼마나 시간을 투자할 건지는 스스로 정해야 했다.
나는 비전공자인만큼 매 미션마다 모든 키워드가 낯설었고 학습의 비중을 도저히 줄일 수 없었다.
그래서 조금이라도 더 효율적으로, 정확하게 학습을 하기 위해 노력했고,
그 과정에서 나만의 몰입 전략을 세울 수 있었다.
3.1 자기 주도 학습
베이직에서의 경험을 미루어보았을 때,
효율적인 학습과 몰입을 위해선 무엇보다 내 의지가 가장 중요했다.
때문에 스스로 학습을 주도하고 해쳐나가기 위한 원동력을 찾아야 했다.
Swift와의 연결 고리 만들기
CS 지식 학습 과정을 가능한 Swift에서의 적용과 연관지어보려고 노력했다.
이전 부트캠프에서 CS보다는 차라리 Swift를 더 공부하라는 말을 들었지만,
막상 공부해보니 생각보다 앱을 만드는 과정에도 CS지식이 많이 녹아들어 있었다.
기존엔 별 생각 없이 사용하던 것들의 원리를 알게 되었고, 학습과 경험이 많이 이어질 수록 흥미도와 몰입도가 함께 올라갔다.
구현을 위한 설계, 설계를 위한 학습
원동력으로 삼은 다른 하나는 학습이 곧 설계의 바탕이 된다는 걸 느낀 경험이었다.
미션 초반에 해당 경험을 하게 되었는데, 충분한 학습이 막힘없는 설계로 이어지는 것에 성취감을 느꼈다.
이는 곧 학습에 몰입해야 한다는 생각의 근거가 되어주었기에 그만큼 더 열심히 공부할 수 있었던 것 같다.
다만 이 경험이 나중엔 고정관념이나 강박처럼 작용하는 문제가 있었다.
3.2 체력 관리
지속적인 몰입을 위해선 컨디션 관리가 필요했다.
첫 주차에 느낀 바로는 5시를 넘어서 잠들 때, 낮잠을 자더라도 하루 종일 집중력이 떨어졌다.
때문에 2주차 부터는 하루를 설계할 때 5시를 기준으로 삼고 반드시 그전에 잠들도록 노력했다.
체력 관리의 핵심은 체력 한계를 넘지 않도록 욕심을 절제하는 것이었다.
하루를 무리하면 다음날을 포기해야 한다는 걸 인지하고,
한 주 간의 컨디션이 모두 비슷할 수 있게 조절했다.
4. 내가 정의한 문제 해결력
베이직에서 얻은 인사이트의 핵심은 애매한 요구사항에 대해 스스로 정의하는 능력이 필요하다는 것이다.
하지만 이 능력이 곧 문제 해결력으로 이어지는 것은 아니었다.
베이직에서 해당 능력을 내세운 이유는 문제 정의에서부터 막히기 쉽기 때문에, 미리 시행착오를 경험하길 바라서였다.
챌린지를 진행하며 내가 느낀 문제 해결력이란
문제를 스스로 정의내리는 것에 해결을 위한 과정 전체를 설계할 수 있는 능력을 더한 것이었다.
여기에 문제 해결을 끝낸 뒤 점검이나 회고를 통해 점진적으로 개선하고 자신만의 해결법을 구축하는 노력이 필요했다.
나는 문제 해결력을 높이기 위해 매 미션마다 다음의 과정을 거쳤다.
4.1 문제 분석 및 정의
챌린지에서 주어지는 모든 미션에는 미션 해결을 통해 이루고자 하는 목표가 제시되었다.
이에 더불어 개인적으로 미션에서 이루고자 하는 목표를 추가하여 해결 방향을 잡았다.
모든 미션에서 해결하고자 하는 문제의 본질은 목표에 담겨있다고 생각했다.
따라서 목표를 항상 중심으로 두고 학습과 구현을 오가며 미션을 해결해나갔다.
물론 구현을 위한 요구사항도 중요했고, 어떻게 요구사항을 분석할지도 고민했다.
하지만 챌린지 과정을 통해서 궁극적으로 얻고자 하는 건 성공적인 구현이 아니라고 판단했다.
즉, 학습과 구현은 최종 목표가 아니라 수단이란 것이다.
베이직과 챌린지 과정의 핵심 키워드 중 하나는 Learning by Doing인데,
그 뒤에 for Problem Solving이 숨어있다고 생각했다.
예를 들어, 미션의 목표가 “커피 종류를 이해하고, 원하는 음료를 만들 수 있다.”라고 한다면,
개인 목표로 “커피를 집에서 내릴 때와 가게에서 내릴 때의 차이를 찾기”를 추가하거나
지난 미션에서 얻은 인사이트 “각 단계를 도식화 하여 이해하기” 등을 추가했다.
이후 커피 종류 학습과 음료 만들기라는 구현을 오고 가며 목표를 달성해나가는 식이었다.
4.2. 문제를 해결하기 위한 Task 파악
최종적으로 이루고자 하는 목표를 위해 학습과 구현을 이용한다는 말은
반대로 학습과 구현이 문제 해결에 중요한 역할을 한다는 걸 의미한다.
각 미션마다 목표를 이루기 위해 내게 부족한 지식은 무엇인지,
지식을 바탕으로 어떤 구현을 해봐야 하는지를 정리할 필요가 있었다.
다행히도 모든 미션에서 각 목표를 이루기 위한 사전 학습 키워드, 필요한 배경 지식, 구현 요구사항을 제시해주었다.
이를 바탕으로 어떤 부분을 학습하고, 구현 요구사항을 어떻게 풀어나갈지는 다시 스스로 정의했다.
커피를 다시 예로 들자면 “단맛이 나는 음료를 만들기”라는 요구사항과 함께,
바닐라, 카라멜, 짠맛과 단맛의 상호 작용 등의 키워드를 제시받는다.
그러면 바닐라, 카라멜 외에는 어떤 재료가 있는지, 단맛이라는 건 어떻게 작용하고 짠맛이 왜 키워드에 포함되었는지 등을 학습 Task로 넣는다.
이후 음료를 만들기 위한 설계를 하고, 설계를 바탕으로 다시 구현에 대한 Task를 작성한다.
Task들은 구현과 학습을 진행하면서 얼마든지 추가되고 변경될 수 있었다.
4.3 Task를 더 작게 쪼개고, 우선 순위를 부여하기
앞서 구현과 학습에 대해 필요한 작업들을 파악하고 나열했다면,
다음은 각 Task를 더 작게 쪼개고 우선순위를 부여하는 작업을 진행했다.
우선 순위를 정하는 것은 꽤 까다롭고, 미션 해결의 방향을 정하는 결정적 요소였다고 생각한다.
학습을 우선 순위로 두는 분들도 계셨고, 구현을 위주로 진행하는 분들도 계셨다.
이 우선 순위를 어떻게 정하느냐에 따라 각자의 미션 수행 결과가 달라진다 해도 과언이 아닐 것이다.
나는 앞서 말했 듯 지식이 부족하다는 생각이 강했고, 지식이 있을 때 매끄럽게 이어지는 설계에 혹했다.
나중에 깨달았지만, 내가 주로 구현해나가던 방식은 탑-다운 방식이었다.
전체 구조와 흐름을 먼저 정의할 수 있어야 하기 때문에 설계 전 지식이 많이 필요했고,
대신 의존성 분리나 테스터블하게 개선할 요소가 적었다.
미션 후반부로 갈수록 학습에 대한 욕심을 내려두고 구현해볼 작은 기능 하나에 집중하는 시도를 해보았다.
이런 하위 기능 단위의 구현을 쌓아올리는 방식이 바텀-업 방식이라고 하던데,
원하는 기능을 구현하기 위한 지식 학습 설정 → 학습 → 설계 및 구현의 반복이 이어지니 기존보다 학습과 구현에 투자하는 시간의 비율이 비슷해졌다.
대신 의존성 분리나 테스트를 위한 구조를 신경쓰지 못했고, 공통 로직을 선별해서 분리하는 작업도 따로 필요했다.
미션을 수행하는 과정 속에서는 학습을 많이 하니까, 단순히 학습량을 줄여서 밸런스를 잡는 것이라고 생각했는데,
회고를 쓰며 생각해보니 어떻게 설계하고 구현해나갈 것인가가 학습과 구현의 밸런스를 정하는 듯 하다.
Task를 작게 쪼개는 건 미션 해결 전반에 걸쳐 지속적으로 수행되었는데,
우선순위를 정하기 전에도 어느정도 Task를 분리할 필요가 있었고 각 Task를 수행할 때도 세분화할 필요가 있었다.
설계와 구현을 위주로 작업을 분리할 때는 주로 하나의 역할 또는 기능을 단위로 분리했다.
학습에 대한 부분은 AI의 도움을 많이 받았는데, 각 키워드를 이해하기 위해 필요한 커리큘럼을 제안 받아 활용했다.
커피를 다시 예로 들자면 “단 음료 만들기”의 구현을 위해 “커피 추출”, “베이스 제조” 등의 확실한 역할 단위로 분리했다.
그리고 커피 추출을 다시 “원두 준비”, “잔 예열”, “푸어링” 등의 기능 단위로 쪼개어 하나씩 구현했다.
학습의 경우엔 “단맛과 바닐라, 소금과 단맛”등의 키워드를 바탕으로 AI에게 학습 커리큘럼을 짜달라고 요청한다.
그럼 “단 맛에 대한 이해, 나트륨이 단맛 수용체에 미치는 영향, 바닐라 향의 주요 화합물, 실질적 예시와의 결합” 등의 자연스러운 학습 순서를 반영한 Task가 도출된다.
여기서 주제에서 너무 멀어지는 부분을 정리하고, 구현에 필요해보이는 부분을 순차적으로 학습한다.
4.4 시행 착오와 회고를 통한 점진적 개선
미션 수행의 둘째 날쯤부터 학습과 구현의 밸런스가 어긋났다는 걸 느꼈다.
이때 OT에서 스스로 다양하게 접근해보려 해야 한다라는 말을 하신 게 떠올랐다.
여러 관점의 시행착오를 위해 피어분들의 수행 과정을 컴파일링하면서 따라할 수 있는 건 최대한 다 따라해보고,
혼자서도 앞서 말한 바텀-업과 탑-다운 방식처럼 다른 방향으로 해결해나가보려고 했다.
그러나 생각보다 구현에 더 집중하거나 새로운 정리 방법을 도입해보는 게 자연스럽게 되진 않았다.
이 문제를 해결하기 위해 매 미션을 진행하고 돌아보면서 왜 잘 안 되는지,
어떤 점이 방해요소인지 등을 최대한 메타적으로 파악하려고 애썼다.
그 과정에서 점검과 셀프 피드백이 확실히 개선에 도움 된다는 점을 느끼고,
후반부에 이르러서는 거의 모든 Task를 수행하면서 수행 시간, 결과, 문제점 점검 및 셀프 피드백을 기록했다.
셀프 피드백이 동일한 작업을 다시 시도할 때 반영이 안 되는 경우에 대해서도 분석하는 등 최대한 개선이 쌓여나갈 수 있게 노력했다.
개선을 쌓아나갔던 예를 들자면,
팀원의 이해를 위해 다이어그램을 도입하기 시작했다.
미션을 진행하며 다이어그램을 그리는 게 생각보다 오래 걸린다는 점을 인식했고,
개선을 위해 동료 분들이 사용하던 mermaid 코드나 UMLPlant, diagram.net 등의 도구를 활용해보려 시도했다.
최종적으로는 설계를 바탕으로 AI에게 mermaid 코드 초안을 받고,
excalidraw에서 수정하는 식으로 개선하여 작업 속도와 개인화를 모두 챙겼다.
5. 도움과 협력
5.1 동료와의 협업
처음으로 학습과 구현 사이의 밸런스를 고민했을 때도,
앞서 말한 다이어 그램을 개선하기 위해 고민할 때도 항상 동료들이 적극적으로 도움을 주었다.
Slack엔 늘 자신이 열심히 모은 정보를 공유하고자 하는 분들이 넘쳐났고,
매일 함께 밤을 새며 서로에게 힘이 되어줬던 동료들도 있었다.
지금도 기억에 남는 인사이트 중 하나는 질문을 엄청 적극적으로 하신 분에게서 받았다.
그전에도 피드백 시간엔 서로 질문을 주고 받긴 했지만 뭐랄까 그분은 결이 달랐다.
단순하게 궁금한 점을 물어보시는 것이라 하셨지만,
이어지는 질문들에 적극적으로 대답 하면서 다시 한 번 내 생각을 정리하고 의도를 설명하는 경험이 굉장히 긍정적으로 다가왔다.
피드백 시간을 위한 질문이 아니라 진심으로 내 의도를 궁금해하시는 기분이 들어서였던 것 같기도 하다.
이후로 나도 열심히 질문을 해보려고 노력했고,
질문을 통해 의도를 들으니 고정관념처럼 가지고 있던 부분에 대해 다시 생각하는 계기가 되었다.
가령 싱글톤은 의존성이 숨겨지면서 강하게 결합하고 메모리 관리에서도 손해를 보는 패턴이란 생각에 거의 사용하지 않았다.
이 싱글톤의 사용 이유에 대해 간단하게 사용할 수 있다고 대답해주신 분이 계셨다.
그때의 문답을 통해 의존성이나 강한 결합은 사교적 단위 테스트를 수행하는 관점에선 감안할 수 있는 범위이고,
지금 구현할 기능에 더욱 집중할 수 있으므로 학습 단계에서 활용할 때, 이점이 생각보다 많은 패턴일 수 있겠단 생각으로 이어졌다.
어제는 동료의 추천으로 Rectangle이라는 앱을 받아서 사용 중인데 굉장히 만족스럽다.
이렇듯 미션 해결에만 국한된 게 아니라 추천하는 노래나 AI 활용법 등 다양한 방면으로 정보를 주고 받았다.
늘 동료들에게 새로운 인사이트나 도움을 받으니 자연스레 나도 조금이라도 도움이 되고자 하는 마음이 생겨났는데, 이게 커뮤니티의 선순환이구나 싶었다.
모든 과정이 힘들었지만, 모든 과정에 동료가 있었기에 그나마 버틸만했다고 생각한다.
5.2 마스터라는 나침반
미션 해결을 위해 학습에 빠져들기 시작하면 지금 학습 중이 내용이 구현에 필요한 부분인지 아니면 상관없는 부분인지 분별하기가 어렵다.
다만 아래의 그림처럼 방향을 잘못 잡아 헤메더라도 목표에 도달하면 되기 때문에, 부스트캠프는 마음껏 헤멜 수 있도록 내버려둔다.
대신 목표는 단 맛이 나는 음료인데, 단 맛을 느끼는 혀의 수용체에 대해 공부하고 있다면 그건 길을 너무 심하게 잃은 것이다.
이런 경우를 어느정도 방지하고 목표에 도달할 수 있게 캠프에서 지원해주는 나침반이 있다.
매일 하나의 영상을 통해 어떤 식으로 접근하길 의도했는지, 어떤 방향으로 학습을 파고드는 게 좋은지 알려주신다.
아마 혼자서라면 전부 놓쳤을 것 같은 포인트들을 배우고 미션과 관련성을 유지하면서 깊게 파고드는 게 어떤 건지 느낄 수 있었다.
대신 OT에서 설명한 것처럼 타인의 접근을 보면 더욱 해당 접근 방식에 갇혀버리니까
최대한 스스로 다양하게 접근해보려고 시도한 뒤에 시청해야 했다.
영상의 내용도 주로 미션을 마무리한 사람과 소통하는 듯한 말이 자주 나왔다.
5.3 AI 활용 경험
❝ The future is already here it’s just not evenly distributed ❞
챌린지 이전까지는 주로 내가 떠올리거나 결정한 사안에 대해 확신을 얻는 용도로 가장 많이 활용했다.
이 방식은 2가지 문제점이 존재했는데,
첫 번째는 OT에서 나온 내용으로 내가 맞다는 걸 물어보고 확신하는 게 마냥 좋은 게 아니라는 점이다.
이런 행동이 당장의 심리적 안심을 얻을 순 있지만 확신은 외부의 결정이 아니라 스스로 찾아야 하는 부분이라고 한다.
즉, AI가 대체해서는 안될 영역에 속하는 것이다.
그리고 확신을 한 번 가지면 다른 해결 방법에 대한 확장이 막혀버리고, 다양성을 잃게 된다.
다른 하나는 사용자인 나 스스로 AI의 가능성을 거의 닫아두고 사용했다는 점이다.
기존엔 문맥과 프롬프트에 많은 영향을 받긴 하지만 그것들도 결국 원하는 답을 받을 확률을 높여주는 것일 뿐,
확률에 기댄 대답들임에는 변화가 없다고 생각했다.
그러니 AI가 내놓는 대답들에는 확신을 가질 수 없었다.
이런 생각은 전부 내가 AI를 확신을 얻는 도구로만 사용했기 때문에 가지게 된 것이었다.
그러나 챌린지 과정에서 다양한 AI 활용 사례들을 동료들로부터 듣고 경험하며
대규모 데이터를 요약하고, 재구성하고, 개인화된 컨텐츠를 생산해내는 부분에서 엄청나게 강하다는 걸 느꼈다.
자연스레 AI를 활용하는 방식은 단순히 정답을 확인하는 단계를 넘어, 나의 학습을 돕는 방향으로 바뀌었다.
예를 들어 공룡책 원문처럼 인터넷에 존재하는 신뢰도 높은 레퍼런스를 찾도록 한다.
그리고 학습에 필요한 부분만 추출하고 번역·요약하여 빠른 이해를 돕는다.
또는 WWDC의 스크립트를 학습시켜 원하는 키워드에 해당하는 부분을 빠르게 찾아내,
기존이라면 시간 문제로 포기했을 부분까지 탐색할 수 있었다.
이후, 이해한 지식을 다시 AI에게 설명하며 학습시킨 레퍼런스와의 교차검증을 거친다.
이렇게 레퍼런스를 기반으로 AI에게 도움받아 학습하는 과정은
기존의 “추측 → 정답 확인” 과정보다 훨씬 효율적으로 신뢰도 있는 지식을 받아들일 수 있었다.
피드백 시에도 활용했는데, 내가 만들어낸 문서·코드를 바탕으로 내 의도를 묻는 질문을 만들도록 했다.
기존의 동료 간 피드백에는 시간 제한으로 인한 인지 능력 한계와 감정적 배려로 인해 비판이 어렵다는 문제가 존재했다.
AI는 이런 한계에서 매우 자유롭게 예리한 질문들이나 깊이 있는 비판, 꼬리 질문들을 얻을 수 있는 장점이 좋았다.
피드백에 대한 대답을 글로 인출하며 논리적인 연결을 한 번 더 생각해볼 수 있고,
모든 대답이 기록으로 남아있다는 점도 긍정적이었다.
또, FP의 재귀적 사고와 같이 도저히 내 머리로는 시간 내에 이뤄내기 힘든 부분에 대한 힌트를 받기에도 적합했다.
동작 가능한 간단한 예시들을 보며 이론이 어떻게 구현으로 이어지는지 먼저 학습하고 혼자서 반복해보는 것은,
모든 걸 혼자 다시 발명해내는 것보다 훨씬 효율적으로 사고를 확장할 수 있었다.
말 그대로 미래는 이미 내 옆에 와있었지만,
확률에 기반한 대답이란 고정관념에 갇혀 누리지 못하고 있었다.
그러나 챌린지를 거치며 불확실성보다 확장 가능성을 훨씬 더 크게 가지고 있는 것이 AI라는 생각으로 바뀌었다.
6. 마지막 인사이트
지난 1–3주차의 회고에 기록한 인사이트 외에도 과정 전체를 되돌아봤을 때 기억에 남는 인사이트가 있다.
6.1 기술적 성장
다양한 분야의 CS 지식을 학습하고 실제로 구현하는 과정은 단편적인 지식을 넘어서
내가 사용하는 개발 도구, 환경에 대한 이해를 이루게 해주었다.
이런 이해는 각종 에러 상황에서 빛을 발휘한다고 생각한다.
예를 들어 Xcode에서 XCTest 파일 빌드 시 Linker 에러가 났을 때,
기존에는 에러에 대한 이해 없이 막연히 검색해보거나 새로 만들었을 것이다.
지금은 Linker의 역할을 기반으로 기존 모듈과 타게팅이 잘 안 되는 것때문이라는 짐작을 통해
보다 정확하게 에러의 원인을 찾아낼 수 있을 것이라 기대된다.
모든 CS 지식을 학습하거나 모든 CS 에러를 이해하기엔 멀었지만,
적어도 처음보는 문제에 대해 나도 이해할 수 있을 것이란 자신감을 가지게 되었다.
6.2 회고를 통한 인사이트
지난 회고들 그리고 지금 이 회고를 작성하면서 깨달은 건
작성 중에 새롭게 깨닫는 점이 정말 많다는 것이다.
단순하고 두루뭉실한 인식 정도를 명확하게 글로 인출하는 과정에서
다시 한 번 생각하고 정리하면서 새로운 인사이트가 도출된다.
구체적으로 적기엔 내용이 중복되어 생략하지만,
앞으로도 주간회고를 위한 시간을 꼭 투자하려고 마음먹을만큼 회고가 가져다주는 이점이 너무 좋았다.
지난 회고 기록
7. 마무리
7.1 Thanks to 여자친구
한 달이란 긴 시간동안 매일매일 나를 돌봐준 여자친구가 있어 무사히 완주할 수 있었다.
정말로 그 무엇도 신경쓰지 않고 도전에 몰입할 수 있는 환경을 만들어준 덕에 앞서 작성한 모든 성장을 얻을 수 있었다.
이 글은 지난 한 달의 회고이면서 여자친구에게 보내는 감사편지이다.
늘 많이 고맙고 많이 사랑한다.
7.2. Thanks to 부스트캠프
비전공자로서 챌린지 과정을 수행하며 가장 크게 느낀 점은,
하나의 철학이 삶의 모든 영역에 스며들 듯,
이 과정에서 얻은 경험 역시 개발을 넘어 어떤 분야에서도 힘이 될것이란 기대감이다.
문제를 해결하기 위해 단계를 나누고, 필요한 것을 찾아 적용하고, 다시 배우며 개선하는 과정.
그리고 아주 작은 기능이라도 끝까지 완성했을 때 느낀 성취감.
이 모든 순간이 앞으로 마주할 어떤 문제 앞에서도 물러서지 않게 해줄 거라 확신한다.
도전의 끝에 개발자가 되지 못하더라도,
이 과정에서 배운 열정과 주도적인 문제 해결력은 내 안에 남아 오래도록 영향을 끼칠 것이다.
한 달이라는 짧은 시간동안 분명히 이전과는 다른 사람이 되었고,
앞으로도 이 교육 과정이 많은 사람들에게 같은 변화를 선물하길 바란다.
