완전한 기능을 갖춘 Exercism 트랙에는 두 종류의 연습 문제가 있어요: 개념 연습 문제와 실습 문제예요.
이 둘은 근본적으로 다르면서 서로를 잘 보완해 줘요.
트랙의 개념 연습 문제는 특정 프로그래밍 언어의 기초를 이루는 개별 개념을 가르치기 위해 설계된 문제예요.
이 개념들이 모여 _실러버스_를 이뤄요.
이 문서에는 트랙의 실러버스를 성공적으로 설계하는 방법에 대한 안내와 팁이 담겨 있어요.
실러버스의 목표
실러버스의 최종 목표는 학생이 대상 언어로 관용적인 코드를 편하게 읽고 쓸 수 있게 이끄는 것이에요.
개별 개념 연습 문제는 초점이 아주 좁아요.
언어에 대한 무언가를 이해하는 쪽으로 학생을 옮겨 주는, 작고 목표가 분명한 디딤돌이에요.
이미 소개된 개념 위에만 쌓여요.
문제를 풀면서 학생은 그 개념에 익숙해지기 시작해요.
이해는 주로 직접 해보면서 생기고, 설명을 통해서 생기는 경우는 훨씬 적어요.
설명 콘텐츠는 학생이 문제를 풀기 위해 필요한 아이디어를 소개하기 위한 것이에요. (그래서 파일 이름도 "introduction.md"로 정했어요.)
학생이 모든 것을 미리 이해하지 않고도 곧바로 코드를 쓰기 시작할 수 있으면 좋겠어요.
그래서 세부 사항은 대충 넘어가고, 많은 부분을 설명하지 않고 남겨 둬요.
가능하면 단순하게 만들고 코드 스텁을 제공해요.
이렇게 하면 시작할 때 드는 인지 부담이 줄고, 지식이 자리 잡을 시간과 여유가 생겨요.
이런 접근은 학생에게 이런 것들이 필요 없다는 뜻이 아니에요. 아직은 몰라도 된다는 뜻이죠.
가장 초반의 문제에는 관용적이지 않은 코드가 들어가야 할 때가 많아요.
처음에는 학생이 언어의 대부분을 아직 모르고, 대부분의 개념도 아직 소개되지 않았기 때문이에요.
초반 문제에서 관용적이지 않은 코드를 허용하면, 학생은 낯선 영역에서 큰 걸음을 몇 번 내딛는 대신 익숙한 영역에서 작은 걸음을 여러 번 내딛을 수 있어요.
그 결과 더 빠르고 더 부드럽게 관용적인 코드를 쓰는 단계에 도달할 수 있어요.
기본 구조
연습 문제는 트리 구조로 되어 있고, 맨 위에 시작점 역할을 하는 입문 문제가 있어요.
뒤에 나오는 문제는 앞에서 배운 개념을 이미 이해하고 있어야 하는 개념을 다뤄요.
다른 트랙에서 가져오기
다른 언어 트랙이 개념 연습 문제를 어떻게 만들어 왔는지 살펴보는 것도 도움이 돼요.
다른 언어 트랙의 개념 연습 문제 예시는 여기에서 볼 수 있어요.
다만 다른 문제를 자기 트랙 문제의 출발점으로 삼기로 했다면, 결과물이 자기 언어에 실제로 존재하는 개념을 다루도록 주의해요.
개념은 때로는 미묘하게, 때로는 크게 달라요.
어떤 개념은 다른 언어에 아예 존재하지 않기도 해요.
실러버스, 그러니까 개념 트리는 이 특정 언어에 존재하는 개념을 나타내야 해요.
다른 트랙이 넣었다는 이유만으로 개념을 넣지 마세요.
어떤 경우에는, 사람들이 실제로 존재하는 개념으로 우회해야 하는 일이 많다는 이유로 그 개념을 넣고 싶어질 수 있어요.
그렇게 하는 대신, 그 언어가 실제로 사용하는 개념을 소개하고, 그런 상황에서 그것을 어떻게 쓰는지 설명하는 문제를 추가하는 걸 고려해 봐요.
예를 들어 Go에는 열거형이 없어요.
대신 Go의 개념 트리는 상수를 소개하고, 다른 언어에서 열거형을 쓸 법한 상황에서 상수를 어떻게 사용하는지 가르쳐요.
도움 요청하기
도움이 필요하면 주저하지 말고 물어봐요.
코드 리뷰에서 논의하는 것보다는 미리, 또는 문제를 만드는 도중에 물어보는 게 더 좋아요.
GitHub에서는 @exercism/learning-mode 팀을 멘션할 수 있어요.
Exercism 포럼에서는 Exercism Support 카테고리에 이슈를 열어요.
시작하기
우리 경험상 실러버스를 개발하는 가장 실용적인 방법은 가장 단순한 개념부터 시작해 개념 트리를 자연스럽게 키워 나가는 것이었어요.
모든 것을 미리 설계할 필요는 없고, 사실 너무 멀리까지 내다보지 않는 편이 대체로 도움이 돼요.
그 언어로 무엇이든 작성하는 데 가장 근본이 되는, 꼭 필요한 최소한의 개념부터 시작해요.
또 평범한 개발자에게 가장 익숙한 개념부터 시작하려고 해요.
익숙한 것은 좋아요. 익숙한 것은 헷갈리지 않아요.
목표는 관용적인 코드를 쓰는 것이지만, 거기까지 가는 디딤돌이 항상 관용적이지는 않다는 걸 기억해요.
익숙한 것을 사용하는 것, 그게 그 언어의 훌륭한 코드 예시가 아니더라도, 학생이 그 언어답게 쓰인 코드라는 목표에 더 빨리 다가가도록 도와줘요.
첫 번째 문제 만들기
개념 트리 전체를 미리 그려 보려 하기보다는, 그냥 첫 번째 문제부터 시작해요.
첫 번째 문제의 목표는 학생이 가능한 한 적은 마찰로 학습을 시작할 수 있게 하는 것이에요.
이 언어의 코드가 어떻게 생겼는지 익숙해지는 첫걸음을 내딛는 거예요.
학생은 짧은 코드를 작성할 수도 있고, 문제를 완성하기 위해 스텁에 몇 줄만 덧붙일 수도 있어요.
학생은 이 문제에 접근하기 위해 이미 "Hello, World!"를 풀었어요.
그런데 "Hello, World!"에서는 문구만 바꾸면 돼요.
언어의 문법은 아직 하나도 익숙하지 않을 수 있어요.
빠른 성취를 얻고, 학생이 문법의 최소한만 익혀도 자신 있게 앞으로 나아갈 수 있도록 하는 데 초점을 맞춰 봐요.
첫 번째 문제 만들기에서 더 자세히 볼 수 있어요.
그다음 문제
첫 번째 문제는 기본 개념을 소개하는 몇 개의 문제를 열어 줘야 해요.
여기에는 원시 타입이나 기본 타입, 그리고 그런 타입에 대한 단순한 연산 같은 것이 들어가요.
그다음 문제 만들기에서 더 자세히 볼 수 있어요.
그다음엔 뭘 할까요?
여기서부터 흥미로워지기 시작할 때가 많아요.
이 시점에서는 얼마든지 다룰 수 있는 주제가 많아요.
다음에 어떤 개념을 다룰지는 어떻게 정할까요?
사실 크게 상관없어요.
그럴듯해 보이는 곳에서 시작하기만 하면 괜찮아요.
우리가 생각하는 "그럴듯함"이 무엇인지는 개념 트리 확장하기에서 더 자세히 볼 수 있어요.
실습 문제를 개념 연습 문제로 바꾸지 않기
좋은 개념 연습 문제는 초점이 아주 좁고, 이상적으로는 개념 하나만 가르쳐요.
보통 기대되는 풀이 방식도 하나뿐이에요.
반면 실습 문제는 정해진 답 없이 열려 있고 탐구에 잘 어울려요.
좋은 개념 연습 문제는 대개 실습 문제로는 좋지 않고, 그 반대도 마찬가지예요.
실습 문제와 개념 연습 문제는 목표가 완전히 다르기 때문에, 실습 문제를 가져다 개념 연습 문제로 바꾸지는 않아요.
모든 개념 연습 문제는 처음부터 새로 쓰거나, 단순한 개념을 가르칠 목적으로 특별히 만든 스토리를 바탕으로 만들어요.
대충 넘어가도 괜찮아요
가끔은 막혀 있는 것처럼 느껴질 때가 있어요.
개념 A를 이해하려면 개념 B를 알아야 하고, B를 이해하려면 A를 알아야 하는 상황이죠.
이럴 때는 단순하게 만들어요.
한쪽의 복잡한 부분은 대충 넘어가고, 그 대신 다른 쪽에 학생이 익숙해지게 해요.
어떤 것은 나중에 더 깊이 다룰 거라고 하고, 지금은 이 한 부분만 이해하면 된다고 해도 전혀 문제없어요.
개념은 여러 단계를 거치면서, 시간이 지나면서 더 깊이 이해하게 돼요.
스토리 고르기
개념 연습 문제에는 항상 스토리가 있어요.
다른 트랙에서 문제를 포크했다면 그 문제에는 이미 스토리가 있어요.
그러면 준비 끝이에요.
사용할 수 있는 기존 스토리나 포크할 수 있는 문제가 있는지 보려면 스토리 목록을 확인해 봐요.
개념은 있는데 스토리가 없다면, 소개하려는 개념을 사용하는 작고 단순한 코드 예제를 써 보는 걸 추천해요.
그다음 그 코드에 맞춰 스토리를 거꾸로 만들어 붙여요.
스토리는 어이없을 만큼 단순하게 유지해요.
좋은 소설일 필요는 없어요.
탄탄한 줄거리나 인물 묘사도 필요 없어요.
두어 줄이면 충분해요.
스토리 아이디어는 Exercism 팀과 함께 의논해 봐요.
우리는 알맞은 스토리를 떠올리는 데 경험이 많아요.
스토리를 정했다면, 스토리에 맞게 코드를 조금 손봐야 할 거예요.
커뮤니티의 기여
실러버스 작업에는 서로 다르지만 얽혀 있는 두 가지 활동이 있어요:
- 실러버스 설계: 개념을 고르고 순서 정하기
- 문제 구현: 문서를 쓰고, 그 개념을 가르칠 문제 만들기
더 넓은 커뮤니티가 문제 구현에 기여하도록 하는 것이 재미있고 풍요롭다는 걸 경험으로 알았어요.
다만 실러버스 설계 자체는, 복잡한 부분까지 포함한 전체 실러버스를 함께 이해해 나가는 소규모 기여자 팀과 함께하는 편이 더 수월해요.
그래도 커뮤니티 기여를 열기 전에, 실러버스 설계 팀이 먼저 다섯 개에서 여섯 개 정도의 개념을 직접 구현해 보는 걸 추천해요.
그러면 실러버스 설계 핵심 팀이 더 넓은 커뮤니티의 풀 리퀘스트를 리뷰하기 전에 그 과정을 스스로 이해하게 되는 데 도움이 돼요.
또 이런 상위 개념에 대해서는 이슈를 만들기도 더 쉽고, 신경 써야 할 제약이 적어서 커뮤니티 구성원이 작업하기에 더 재미있는 편이에요.
이슈 만들기
개념 연습 문제를 만들기 위한 이슈를 어떻게 만드는 게 가장 좋은지는 아직 알아내지 못했어요.
일부 트랙에서는 개념 자체를 다루는 문제와 그 개념을 연습하는 문제를 따로 만들어 보기도 했어요.
다른 트랙에서는 체크리스트를 따라가며 처리하는 이슈를 만들어 보기도 했어요.
전체적으로는 아직 너무 부담스럽다고 생각하고, 더 나은 방법을 찾고 싶어요.
이슈를 만들기 시작할 때 그 과정에 대해 우리에게 이야기해 주세요. 그러면 앞으로 어떻게 진행할지 함께 고민해 볼게요.
더 나은 방법을 알게 되면 문서를 업데이트할게요.
