안녕하세요 👋
Exercism을 더 나은 방향으로 개선할 아이디어를 제안하셨는데, 누군가 이 글을 보라고 알려줘서 여기 오셨나요?
우리 팀이 그 아이디어를 살펴보는 데 시간을 들이기 전에, 이 글을 읽고 그 아이디어가 예전에 이미 검토된 적은 없는지, 어떤 함정이 도사리고 있을지 한번 생각해 보시면 좋겠어요.
그런 점들과 예상되는 함정을 제안에 함께 적어 주시고, 왜 이 아이디어가 아직 적용되지 않았는지도 고민해 주시면, 더 빠르고 더 긍정적인 답변을 받을 가능성이 커요.
그럼 "체스터턴의 울타리"는 무슨 뜻일까요?
체스터턴의 울타리는 작가 G.K. 체스터턴이 1929년에 쓴 책 The Thing에 나오는 구절에서 착안한 개념이에요.
존 F. 케네디가 인용하면서 널리 알려졌어요.
원문은 이래요.
이런 경우에는 어떤 제도나 법이 있어요. 간단히 말하자면, 길을 가로질러 세워진 울타리나 문이라고 해볼까요.
요즘 시대의 개혁가는 그 앞으로 즐겁게 걸어가서 이렇게 말해요. “이게 무슨 쓸모가 있는지 모르겠어요. 치워 버려요.”
그러면 더 똑똑한 개혁가는 이렇게 답하는 게 좋아요. “쓸모를 모르신다면, 저는 절대 치우게 두지 않겠어요. 가서 생각해 보세요. 그리고 돌아와서 쓸모를 알겠다고 말할 수 있게 되면, 그때는 없애도 된다고 허락할지도 몰라요.”
체스터턴의 울타리가 말하는 바는 이래요. 어떤 것이 왜 거기 있는지 이해하지 못한다면, 그것을 왜 없애야 하는지도 아마 이해하지 못한다는 거예요.
마찬가지로, 어떤 것이 왜 없는지 이해하지 못한다면, 그것이 왜 빠져 있는지도 아마 이해하지 못한 거고요.
기억해 둘 간단한 원칙이 있어요. "울타리가 왜 세워졌는지 알기 전에는 그 울타리를 치우지 마라."
이 개념은 Exercism과 어떻게 관련이 있을까요?
Exercism에는 항상 많은 분이 커뮤니티에 합류해서 생각과 아이디어를 올려 주시는 게 정말 다행이에요.
그중 많은 아이디어는 새롭고 혁신적이고 흥미로우며, 우리 생각을 틔워 줘요.
그러니 아이디어나 제안이 있으면 언제든 환영해요!
하지만 더 자주 있는 일은, 이미 여러 번 논의된 아이디어를 올리는 경우예요.
그런 아이디어에 답하고, 이미 내린 결정을 다시 다루거나 다시 정당화하는 일은 우리 팀에 엄청난 부담이 돼요.
이 글은 그 시간과 에너지를 지키는 데 도움이 되고자 해요.
Exercism은 수천 명의 아주 뛰어난 사람들이 설계하고 만들고 다듬어 온 결과물이에요.
아주 의도적으로 만들어진 제품이라서, 어떤 것들은 거기 있도록 설계되었기 때문에 있고, 어떤 것들은 빠지도록 설계되었기 때문에 자주 빠져 있어요.
Exercism의 거의 모든 것은 여러 번 논의되고 토론되고 다시 설계되었어요.
그러니 아이디어를 올리기 전에, 우리가 이미 검토한 적이 있는지, 그리고 왜 제안하신 것과 다르게 해 왔을지 스스로에게 물어봐 주세요.
그리고 기억해요. 아이디어가 더 뻔해 보일수록, 이미 여러 번 논의되고 토론되었을 가능성이 커요. 그러니 아이디어를 제시할 때는 예상되는 문제점과 함정을 함께 짚어 주세요.
"그냥 ...하면 안 되나?"라는 생각이 든다면, 거의 확실히 이 범주에 속해요.
올리는 걸 두려워하지는 마세요. 다만 먼저 꼼꼼히 생각해 봐 주세요!
예시가 있나요?
흔한 불만 중 하나는 학생들이 멘토에게 테스트를 통과하지 못한 코드를 제출한다는 거예요.
그만큼 흔한 제안은 "코드를 제출하기 전에 CLI에서 자동으로 테스트를 돌리면 안 되나요?"예요.
좋은 아이디어처럼 보여요. CLI가 명령을 하나 실행해서 테스트를 돌리고, 실패하면 학생이 제출하지 못하게 하면 되니까요.
먼저, "명령을 하나 실행해서 테스트를 돌린다"는 게 무슨 뜻일까요?
Exercism에 있는 52개 언어 각각에 대해, 테스트를 돌리고 결과를 확인하는 스크립트를 작성한다는 뜻이에요.
꽤 수고가 들지만, 할 수는 있어요.
하지만 그 스크립트가 Windows, MacOSX, Linux에서, 그것도 가능한 모든 버전과 구성에서 동작하도록 작성해야 한다는 뜻이기도 해요. 이건 어마어마한 양의 작업이고, 어쩌면 끝이 없을지도 몰라요.
"왜 모든 구성에서 동작해야 하죠?"라고 물을 수 있어요.
왜냐하면 이 스크립트를 실행할 수 없으면 누군가가 Exercism을 쓰는 걸 막는 셈이 되기 때문이에요.
그러면 이 스크립트는 절대 실패해서도 안 된다는 뜻이기도 해요.
어떤 이유로든 스크립트가 실행되지 않으면, 그 학생은 완전히 막히게 돼요.
52*3*n개의 스크립트 중 하나에 버그가 있으면, 그 학생은 그 OS에서 더 이상 트랙을 쓸 수 없어요.
그건 어떻게 테스트할까요?
할 수 없어요.
그런데 --skip-tests 플래그를 추가하면 되지 않냐고 할 수도 있어요.
좋은 제안이지만, 사람들이 원할 때마다 테스트를 건너뛸 수 있다는 처음의 문제로 돌아가게 돼요.
다만 이제는 테스트를 통과하지 못한 코드가 제출될 가능성이 아주 조금 낮아져서 멘토의 기대치도 낮아지고, 그 결과 테스트가 실제로 통과되지 못할 때 훨씬 당황스럽고 혼란스러워져요.
"그래도 사람들이 보통은 그러지 않을 거예요"라고 주장할 수도 있어요. 테스트를 돌리는 데 0.5초밖에 걸리지 않는 언어라면 사실이에요.
하지만 테스트를 돌리는 데 20초가 걸리는 언어에서 제출할 때 20초를 더 기다려야 한다면 학생들은 엄청나게 답답할 테고, 그러면 마지막 테스트를 건너뛰는 일이 흔해질 거예요.
이 논의가 어디로 흘러가든, 여기에는 처음 보이는 것보다 훨씬 많은 복잡성이 얽혀 있다는 건 분명해요. 고려해야 할 기술적 난제도 있고, 생각해 봐야 할 워크플로 문제도 있고, 트랙마다 차이가 워낙 커서 어떤 트랙에는 빠르고 쉬운 일이 다른 트랙에는 괴로운 일이라는 사실도 깨닫게 돼요.
그래서 "제출 전에 테스트를 돌리면 안 되나요?"라는 제안을 하기보다는, 이렇게 질문해 볼까요. "사람들은 왜 테스트를 통과하지 못한 풀이를 올릴까요?"
그러면 이야기가 흥미로워져요.
일반적인 답은, 막혔거나 혼란스럽기 때문이에요.
그리고 도움이 필요하죠.
즉, 통과하지 못한 테스트를 제출하는 것은 이 학생이 _도움이 필요하다_는 걸 멘토에게 알려 주는 아주 중요한 단서예요.
네, 멘토가 그 코드가 "올바른지" 즉시 알 수 없어서 답답해요. 하지만 코드를 내려받아 실행해 확인할 수 있고(대부분의 멘토가 사소하지 않은 풀이에서는 그렇게 해요), 그러면 그 코드가 올바른지 100% 확신할 수 있어요.
그리고 막혀서 도움이 필요한 학생은 더 막히거나 더 많은 도움을 필요로 하는 상황에 빠지는 대신, 더 빨리 보고 조언해 줄 수 있는 멘토를 만나게 돼요.
참고: 사실 우리는 이 문제를 서버 측에서 테스트를 실행하는 방식으로 해결하고 있어요. 크고 비용이 많이 드는 작업이지만, 학생 경험을 개선하고 무엇보다 멘토의 시간과 에너지를 아껴 주기에 충분히 할 만한 가치가 있어요.
또 있을까요?
세 가지예요.
-
Second Order Thinking에 실린 이 글은 읽어 볼 만해요. "울타리가 왜 세워졌는지 알기 전에는 그 울타리를 치우지 마라"라는 구절은 이 글에서 나왔어요.
- G.K. 체스터턴의 _The Thing_은 여기에서 볼 수 있어요. https://archive.org/details/G.K.ChestertonTheThing.
- 정말로 새롭고 멋진 아이디어일 수도 있어요. 제안하는 걸 두려워하거나 부끄러워하지 마세요!
