마스터 JK 노트 | 부스트캠프 미션을 설계하며
글쓴이: 코드스쿼드 모바일 마스터 김정 케텔 시절부터 개발자 커뮤니티에서 영향을 받아 성장했고, 만들면서 배운 경험을 전파하는 소프트웨어 교육 개발자입니다. 취미로 하던 맥 개발자 OSXDev 커뮤니티를 거쳐 레츠스위프트 커뮤니티까지 함께 성장하는 애플 개발자 생태계를 꿈꾸고 있습니다. 부스트캠프에서는 야생에서 방황하는 캠퍼들에게 지도와 나침반을 보여주는 JK 역할입니다.
'만들면서 배울 수 있다'는 학습에 대한 문제 정의는 100년 전부터 시작됐지만 그것을 해결하는 학습은 여전히 시험 점수 높이는 것을 목표로 합니다. 시험공부가 아니라면 도대체 무엇을 어떻게 만들면서 무엇을 배울 수 있는가는 여전히 중요한 문제입니다.
학습자에게 익숙한 문제: 목표지향 학습
개발자로 성장하기 위해서는 실무에서 일하듯 피드백을 주고받을 수 있는 환경이 좋습니다. 그렇지만 학습자 스스로 이런 학습 환경을 만드는 것은 거의 불가능에 가깝습니다. 경험하지 못하거나 해보지 않은 일을 미리 다 알 수 없으니까요.
예전부터 선배 개발자들은 학습자들에게 '실무에 가까운 프로젝트 경험이 중요하다'라고 강조해왔습니다. 많은 부트캠프에서 프로젝트를 잘하기 위한 지식과 경험을 제공하는 이유이기도 합니다. 그러다 보니 개인 프로젝트나 팀 프로젝트로 IT 서비스를 만들어 본 경험이 평균적으로 많아졌습니다. 그러나 아쉽게도 많은 프로젝트들이 과정에서 배운 시행착오나 아쉬운 부분을 개선하기보다는 겉으로 화려한 결과를 만드는 것이 목표인 경우가 많았습니다.
많은 학습자가 독서, 자격증 취득, 포트폴리오 완성을 위한 프로젝트 경험 등에서 성취감을 얻는 데 익숙합니다. 하지만 이런 목표 지향 학습은 '익숙함'의 감정을 '알고 있다는 착각'으로 오해하게 만들어 정작 자신이 무엇을 모르는지 파악하는 메타인지하기 어렵게 만듭니다. 지식을 많이 소비하지만 서로 연결해서 결과를 만들어내는 과정에 대한 적절한 피드백을 받아보지 못해서 성장하는 데 필요한 영양소로 전환하지 못하는 경우가 많습니다. 주로 프로젝트 결과물 자체가 목표였기 때문입니다.
한동안 IT기업들이 채용 절차에 코딩테스트 플랫폼을 활용해서 채점 결과를 반영했습니다. 그러다 보니 토익 만점이지만 영어 회화가 안되는 현상과 동일하게, 코딩테스트를 암기식으로 외워서 풀고 테스트 항목은 만점 받았지만 스스로 설계해야 하는 문제는 시작조차 못하는 경우가 생겼습니다. 문제에 제한적으로 주어진 테스트 케이스만 통과하는 코드를 작성할 뿐, 테스트 케이스 자체를 스스로 생각하지 못하는 현상도 있었습니다. 선배 개발자들이 보기에는 프로젝트도 경험하고 코딩테스트 점수도 좋지만 오히려 기본기는 부족한 입사 지원자를 자주 만날 수 있었습니다.
설계자가 준비하는 낯선 문제: 미션
학습자가 단지 프로젝트를 만들었다는 성취감이나 코딩테스트에서의 어려운 알고리즘 암기식 성취감을 위한 수동적이고 익숙한 학습 방식을 바꿔야 했습니다. 그러기 위해서는 크기가 작지만 도전적인 미션을 PBL(Problem-based Learning) 방식으로 제공하는 게 적절해 보였습니다. PBL 방식에서 Problem은 학습 단위입니다. 베이직에서 미션은 하루 4시간 이내로 해결할 수 있고, 챌린지에서 미션은 8시간 이내로 해결하는 것을 기준으로 잡았습니다. 미션을 해결하기 위해서 학습해야 하는 지식의 범위, 분량과 난이도에 따라서 일부 미션은 더 상향되기도 했습니다.
베이직과 챌린지 미션을 설계할 때마다 개발자들이 암묵적으로 반복하는 소프트웨어 공학의 단계를 펼쳐놓고 고민했습니다. 개발자는 해결해야 하는 문제를 해석하고, 요구사항을 분석하고 개발해야 하는 범위와 구조를 설계하고, 설계한 내용에 대해 우선순위도 결정합니다. 결정한 개발 계획과 설계에 따라 적절한 개발 환경에서 구현하고, 설계나 개발 과정의 오류를 찾아내고 고치고, 배포해서 사용자 피드백을 수집하고 개선하는 작업을 반복합니다. 미션을 설계할 때는 이런 소프트웨어 공학의 문제 해결 과정을 일부에서 전체까지 다양하게 조합했습니다. 학습자들이 바로 코드부터 작성하지 않고 문제의 맥락을 이해하면서 스스로 결정해야 할 부분과 코드로 구현해서 검증해야 하는 경험을 다양하게 펼쳐놓도록 준비했습니다. 그러면 학습자들은 '이런 단계가 필요하구나!', '저런 단계도 더 신경 써야겠구나' 하고 무심코 지나쳤던 단계들에 주의를 기울이기 시작합니다.
학습자는 미션을 읽는 순간부터 학습을 시작합니다. 어떤 미션은 꼭 코드를 만들지 않고 해결해야 하는 미션도 있습니다. 미션은 입출력 테스트 케이스가 명확한 코드를 만들거나, 특정 알고리즘을 외워서 작성하는 암기식 코딩 문제가 아닙니다. 실무에서 모든 상황을 판단해 주고 입출력을 설계해 주지 않는 것처럼 스스로 제약사항과 동작 조건을 찾아야 하는 진짜 문제 형태를 가집니다. 미션을 설명하는 문장을 읽고 이런 의미일까 저런 의미일까 해석하면서 스스로 마주하는 상황마다 주어진 조건을 해결하기 위해서는 필요한 지식을 찾아야 합니다. 지식을 검색하고 학습하며 다양한 시도를 반복하는 과정에서 지식은 구조화되고 암묵지로 쌓여 이상적인 학습이 이루어집니다.
이렇게 미션을 해결하면서 지식을 학습하는 이상적인 학습 과정을 경험하기 위해서는 단지 미션을 해결하는 것만으로 부족합니다. 기존의 목표 지향 학습과 달라지기 위해서는 학습 결과뿐만 아니라 학습 과정에 대해 피드백하는 주변 환경이 필요합니다. 실수하고 이런저런 방향으로 도전했던 학습 과정과 의사결정 과정을 드러내서 설명하는 대상이 가까이에 있어야 합니다. 학습 과정을 설명하면서 지식을 구조화하고, 다른 사람의 학습 과정을 들으면서 다시 변형이 일어나고, 서로 물어보고 답변하고 새로운 방향을 고려하면서 지식을 다시 재구조화하고 경험은 풍부해집니다.
부스트캠프는 베이직 → 챌린지 → 멤버십 단계로 나눠지지만 학습에 대한 고민, 미션 설계에 대한 철학은 모두 동일합니다. 학습할 지식의 도메인 분야, 학습 범위와 기준 시간, 스스로 해야 하는 학습 단계가 4시간부터 하루, 이틀, 일주일까지 단계적으로 늘어납니다. 그중에서도 자기 주도적으로 학습하고 함께 성장하기 위한 방식을 스스로 깨치는 베이직과 챌린지 미션 설계를 중심으로 저의 고민을 설명하겠습니다.
베이직 미션 설계
베이직 미션은 개인 학습 시간대가 다르거나 배경지식이 다양하다고 가정하고 새로운 지식 학습은 최소화하면서 4시간 이내에 결과를 만드는 것을 기준으로 정했습니다. 분석, 설계, 구현, 검증 단계를 의도적으로 분리하고, 일주일 단위로 금요일에 가까울수록 단계적으로 분량이 조금 늘어나거나 난이도에 변화를 주었습니다. 코드 없이 미션을 해결하는 절차를 스스로 기준에 맞춰 계획하는 문제 해결 방식도 준비했습니다. 미션에 주어진 조건 이외에 나만의 기준이나 제약 사항을 추가해서 서로 비교할 수 있도록 했습니다. 아래는 베이직 미션의 예시입니다.
학습 목표
주어진 상황을 파악하고 문제 해결을 위한 적절한 데이터 구조와 프로그래밍 흐름을 설계할 수 있다.
구현 단계 이전에 문제 해결에 필요한 데이터 구조와 샘플 데이터를 구조화할 수 있다.
데이터 구조에 필요한 데이터 타입을 적절하게 선택할 수 있다.
내가 설계한 데이터 구조와 프로그램 흐름을 적절한 형식으로 문서화하고 설명할 수 있다.
기능요구사항
다음과 같은 흐름으로 동작하는 웹 혹은 앱 서비스를 개발하고 있다고 가정한다. 가칭 ACME 서비스를 사용하는 사용자들의 화면별 사용 이력을 히스토리 데이터로 보관하려고 한다. 액션에 따라 보여 주는 화면, 해당 화면에서 동작 이벤트, 특정 화면에서 전환하는 화면을 기록하는 데이터 구조와 타입을 스스로 판단해서 결정한다.
동작에 대한 설명은 다음과 같다. 글로 명시되지 않은 흐름은 그림을 보고 스스로 파악해 본다.
시작하면 로그인되어 있는 상태인지 아닌지에 따라 <로그인 화면>을 보여 주거나 바로 <메인 화면>으로 전환한다.
로그인 화면에서 성공한 경우에만 <메인 화면>으로 전환한다.
프로그래밍 요구사항
위 서비스 동작에 대한 사용자 이력을 저장하기 위해서 데이터 구조와 저장하는 프로그램 구조를 설계한다. 설계 결과는 자신의 생각을 가장 적절하게 표현하는 형식을 스스로 선택한다. 왜 선택했는지도 설명하는 게 좋다.
학습 환경 측면에서 미션을 해결하는 과정마다 학습자의 실수를 스스로 기억하고 정리하고 공유하는 활동을 추가했습니다. 실수 없이 한 번에 완벽하게 코드를 만드는 것보다 사소한 실수, 반복하는 실수, 치명적인 실수까지 스스로 학습이 쌓이는 지점을 정리해서 공유하는 '실수 축제' 활동을 만들었습니다. "나도 그랬는데!" 하고 공감하기도 하고, 실수에 대한 해결 방법도 있기 때문에 이런저런 상황에서 해결 방법도 배울 수 있었습니다.
미션에 대한 학습 과정을 포함한 학습 저장소를 제출하면 다른 사람이 제출한 링크에 들어가서 과정과 결과를 모두 확인하고 의견을 남겨 주는 활동도 중요했습니다. 다른 학습자의 생각 틀거리를 이해하기 위해 질문하기도 하고, 서로 다른 제약사항이나 코드에 대해서 의견을 남기고 받습니다. 이런 활동조차 처음인 학습자가 많아서 학습에 긍정적인 영향을 주었습니다.
챌린지 미션 설계
처음 베이직을 설계할 때는 챌린지의 축소판처럼 생각하기도 했지만 서로 다른 방향에서 발전하고 있습니다. 챌린지에서의 미션은 하루 단위 '8시간 + 𝛼 '분량으로 구성되며, 학습 목표인 CS 지식을 학습해야 문제 해결이 쉬워지는 'CS 개념별 미션'입니다. 아래는 챌린지 미션의 예시입니다.
기능 요구 사항
설계 요구 사항
개발하기 전에 설계 결과를 [README.md] 파일에 작성해야 한다.
설계 방향, 의도한 동작 방법, 데이터 흐름과 호출 흐름 등을 표현하는 설계 다이어그램 또는 문서가 있어야 한다.
다이어그램은 (UML 형식이 아니더라도) 데이터와 동작 흐름을 보여 줄 수 있으면 된다. 손으로 그려도 된다.
프로세스별 메모리 분석 리서치
프로세스별로 메모리 사용 현황을 모니터링하는 방법과 지표를 확인한다.
프로세스 메모리에서 영역 혹은 세그먼트가 차지하는 크기를 확인해야 한다.
각 영역별로 어떤 용도로 사용되는지 확인한다.
Node.js에서 프로그램을 실행하는 동안 Heap 메모리 영역에 대해 분석하는 방법을 확인한다.
프로그래밍 요구사항
분석한 프로세스 메모리 구조를 바탕으로 비슷하게 동작하는 시뮬레이션하는 프로그램을 작성한다. 다음 내용은 설계를 도와주는 내용을 포함하고 있다.
다음과 같은 영역을 최소한 크기를 정해서 미리 확보한다.
STACK 영역: 어셈블리 코드를 실행하면서 호출할 때마다 필요한 값을 스택 방식으로 Push하거나 Pop하는 영역
HEAP 영역: 어셈블리 코드를 실행하면서 메모리 할당 요청이 있을 때 사용할 공간을 확보하는 영역
TEXT 영역(문자열 배열): 입력으로 주어지는 어셈블리 코드가 저장되는 영역
예를 들어 명령어 한 줄(배열 인덱스 1개)이 4바이트씩이라고 가정한다.
스택에서 힙 영역에 메모리 주소를 다룰 때는
포인터변수 개념을 직접 구현해야 한다.프로그램에서 처리하는 모든 포인터 메모리 사이즈는 4바이트를 기준으로 한다.
힌트: 언어에서 4바이트를 기준으로 동작하는 타입을 활용한다.
일반적으로 동작하도록 설계하고 구현한다.
시나리오 흐름에 맞는 예시 프로그램을 작성하고, 실행해 본다.
다양한 경우에 대한 동작을 확인하기 위한 시나리오 흐름은 스스로 결정한다.
챌린지에서는 매일 미션을 읽고 학습 저장소에 마크다운 형식으로 '나만의 체크포인트'를 작성합니다. 나만의 체크포인트에는 학습 과정과 개발에 대한 목표와 이를 달성하기 위해 스스로 작게 나눈 task가 체크포인트로 포함되어야 합니다. 체크포인트는 단지 구현해야 하는 기능 목록이 아닙니다. 이번 미션을 해결하기 위해서 학습 분량, 지식 정리와 활용, 기능 목록을 모두 포함합니다. 회사에서 조직과 팀에게 주어진 목표에 맞춰서 내 일감을 정리하는 것처럼 스스로 학습 목표를 이루기 위한 전략을 고민해야 합니다. 자신의 위치나 방향을 잃어버리고 지속해서 방황하지 않도록 길잡이 힌트 영상이나 고민할 지점을 시간차를 두고 알려 줍니다.
문제 해결 시간을 충분히 보내고 나서 다음날 아침에는 설계자가 미리 준비한 통합 체크포인트를 기준으로 스스로 셀프 점검도 해보고, 스터디 그룹 내에 다른 인원들 코드를 읽고 컴파일링도 해야 합니다. 피어 피드백 시간은 혼자 하는 미션 해결 자체보다 짧지만 그만큼 밀도는 높게 토론하고 새로운 시야를 찾을 수 있는 필수 학습 활동입니다.
수료생이 챌린지에서 가장 만족하는 활동은 피어 피드백입니다. 그리고 가장 아쉬워하는 부분은 바로 피어 피드백 이후에 개선하지 못하고 바로 다음 미션을 시작해야 하는 점을 뽑았습니다. 미션의 난이도가 높을수록 완수하지 못했다는 아쉬움이 컸고, 학습을 통해 개선할 점을 깨닫고 나니 오히려 더 큰 미련이 남았습니다. 그래서 난이도가 높은 3-4주 차 미션들을 이틀 동안 나눠서 진행하도록 펼쳐서 개선하는 시간을 추가했습니다. 개선한 부분에 대해서는 동료와의 실시간 피드백 대신 AI 도구로 진행하는 피어세션으로 보완했습니다. 그리고 AI와 함께 진행한 피어 피드백에 대한 과정도 서로 공유하고 읽어보면서 좋은 사례를 찾아갈 수 있도록 안내했습니다. 미션 해결 과정이 쉽지 않지만 서로 다양한 관점에서 피드백을 주고받고 개선하는 단계를 거치면서 각자 방향에서 부족한 부분을 채우는 학습을 진행할 수 있었습니다.
숨겨진 진짜 미션: 지식 학습과 미션 구현의 균형 찾기
챌린지에서는 비전공자라서 모르겠다고 회피하거나 전공자도 어렵다고만 느꼈던 CS 과목을 학습해야 합니다. 챌린지 미션은 CS 지식을 기반으로 만들어집니다. 예를 들어, 브라우저나 Git 명령 같은 서브시스템을 제한적인 조건에 맞게 직접 설계하고 구현하면서 종합적인 학습을 경험합니다. 학습자 개인 단위로 보면, 미션에서 다루는 배경지식에 대한 '학습'과 기능 및 프로그래밍 요구사항에 대한 '구현' 사이에서 다양한 전략과 패턴을 보입니다. 이미 학습했던 지식은 구현해 보면서 미처 연결하지 못했던 지식과 연결고리를 찾기도 하고, 기능을 미처 구현하지는 못했지만 학습하고 정리하는 것만으로도 기존의 지식과 연결시킬 수 있습니다.
설계자 입장에서는 다양한 CS 지식을 편식하지 않고 골고루 학습하면서 서로 연결고리를 찾아내길 바랍니다. 단지 기능 구현만 완성하기보다는 스터디 그룹 내에서도 다양한 학습 전략과 연결고리를 공유해서 함께 성장하기를 기대했습니다. 매일 학습자 스스로 길을 찾아야 하는 숲속에서 지나치게 헤매지 않도록 지도와 나침반을 제공했습니다. 예를 들어, PBL 방식에서 학습자가 놓칠 수 있는 경험과 지식의 연결지점을 점검하는 체크포인트를 제공합니다. 학습 측면에서 특정 지식을 학습하고 정리했는지 묻고, 그 지식이 실제 시스템에 어디에서 어떻게 사용되는지 되새기며 내가 만든 미션과 비교하도록 유도합니다. 마지막으로 피어세션이 단지 숙제 검사하는 시간이 아니라 학습자의 새로운 학습의 시작점이 되는지 매주 살펴봤습니다.
AI 시대를 즐기는 개발자
베이직과 챌린지 미션만 보면 직접 만들면서 배우는 구시대 개발자 학습 방법일 수도 있습니다. AI 시대에 개발자의 역할은 단순한 코드 구현에 그치지 않습니다. 베이직에서 챌린지, 멤버십으로 이어지는 과정에서 반복적으로 강조해온 문제 해결 능력이 핵심입니다. 개발자는 탄탄한 기본기를 바탕으로 AI의 결과물을 비판적으로 검증해야 하며, 공동의 목표를 달성하기 위해 주도적인 소통과 협력을 이끌어낼 수 있어야 합니다. 저에게는 미션만큼이나 학습자가 미션을 소화하고 공유하는 활동을 함께 설계하는 게 가장 어려운 미션이었습니다.
부스트캠프에서 미션은 학습 단위이면서 문제 해결 단위입니다. 기반이 되는 지식을 학습하고 경험을 공유하고 피드백을 주고받으면서 여러 가지 정답으로 가는 길을 보는 방법을 학습합니다. AI 시대에도 지속 가능한 개발자로 성장하기 위해서는 낯선 문제가 가득한 야생에서도 스스로와 동료를 이해하고 문제 해결 과정을 즐기는 경험이 필요하기 때문입니다.
Last updated