~~멍청하게 혼자 기획한 부회장과 그를 까기 위한 급조된 TF(라 읽고 거지같은 동기들이라 부른다)들의 모임~~
[[TableOfContents]]

= 입출력 방식이 제각각인 것에 대한 대처 =
 * 부회장: 문제에서 정해진 입출력이 아닌 입출력에 대해서는 채점 프로그램을 돌리는 것도 아니라서 빡빡하게 안하려고 생각했음.
 * TF: 명확한 기준이 아니라서 용인은 해줬지만 채점할 때, 죄다 다르게 나와서 눈으로 일일이 확인해야 해서 골치 아팠음.
= 정답을 내놓는 샘플 Program을 미리 만들어야 한다 =
 * 부회장: 나중에도 말하겠지만, 손으로 검증할 수 있는 수준의 문제라고 생각해서 설마 준비한 테스트 케이스가 틀렸을 거란 걸 생각도 못한...
 * TF: 문제에 대한 이해가 부족했고, 그 때문에 잘못된 테스트 케이스가 나온 것은 잘못으로 인정함. 그래도 부회장이 사전에 샘플 프로그램도 만들어 뒀으면 TF가 테스트 케이스 준비에 편했을 것이라고 생각함.
= 다른 사람에게 test case 제작을 맡기고 돌려서 검증 =
 * 부회장: 나는 테스트 케이스를 만들어보라고 요청했던 TF가 전부 내가 그 전에 문제 검증을 부탁했던 TF였다. 그래서 문제에 대한 이해도는 있을 줄 알았고, 각자가 만든 테스트 케이스는 각자 들고 다니면서 채점 용도로 쓸 거라고 말해줘서 자기가 사용할 테스트 케이스니까 정확한 테스트 케이스를 만들 것이라고 생각하고 테스트 케이스 제작을 부탁했다. 그리고 TF로부터 불완전한 테스트 케이스를 받았는데 검증할 수 있는 시간이 부족했다.
 * TF: 부회장이 우리에게 테스트 케이스 만들어오는 것을 시켰더라도, 그게 진짜 맞는 지는 부회장이 한 번 확인해봤어야 했다. 그리고 만들 때, 부회장이 적어도 빠르게 테스트 케이스가 맞는지 확인할 수 있는 수단이 있는 줄 알았다.
 * 결론: TF에게 테스트 케이스를 맡길 때는 TF에게 검증까지 해야하는 지도 알려주고, TF도 검증이 필요한 테스트 케이스는 미리 넘겨줘야 한다.
= 테스트 자동화 -> 출력 형식이 엄격해야한다 =
 * 주최자가 대회를 등수를 나누는 데 의도가 있다면, 그만큼 테스트 자동화와 엄격한 출력 형식, 많은 테스트 케이스는 필수다. 하지만 애초에 대회 의도가 같이 코딩해서 서로 부족한 점을 찾는 기회가 되는 게 목표였다면 테스트 자동화까지 구현해놓는 것은 부차적으로 고려해야 하는 것이라고 결론남.
= 주최자의 의도를 분명히 사전에 전달 =
 * 주최자가 타임 어택을 의도했다면 TF도 엄격하게 검사를 함.
 * 주최자가 느슨하게 진행할 의도였다면 TF도 느슨하게 함.
 * 주최자의 의도가 클린 코드가 목적이었다면, TF가 좋은 코드를 짰는지 확인을 해야 함.
 * 이러한 의도를 전달해야 TF도 최소한 그에 맞게 행동함. 그리고 이런 의도를 미리 말하면 TF가 미리 이런 경우엔 어떻게 하냐고 물어볼 수도 있고, 의견을 제시할 수도 있다. 그렇게 하면 미리 대회 때 발생할 수 있는 문제를 제거할 수 있다.
= 이런 의도를 TF가 확실히 공유 받고 참가자에게 전달해야함 =
 * 사전 교육이 중요함. 주최자가 생각하는 진행 방식을 TF가 미리 알고 있어야 함.
= TF 적절한 수로 해야됨 =
 * TF가 너무 부족했음. 특히 채점이 자동화가 아니라면 그만큼 TF 수는 많아야 함. (TF 5명이서 개고생함)
= 문제의 난이도 =
 * 문제의 난이도 조절을 위해서 처음에는 튜터들을 출제자로 두고 튜티들만 대회에 참가하는 방향으로 바꾸자는 제의가 들어왔다
 * 하지만 대회 의도가 튜터와 튜티가 서로 협력하면서 튜티에게 잘 하는 사람의 코드를 배우게 하는 게 의도라면 튜터도 참가자로 같이 있어야 한다.
 * 여담이지만 이번 문제지의 가독성이 너무 부족했다.(부회장은 분명 베타테스트를 세번이나 돌렸는데 왜 다들 그 때는 말 안하고 대회 시작하고 나서야 이거 가독성 떨어지네라고 말하지... ㅠㅠㅠ)
 * 그리고 만약 문제가 이번년도 같은 스타일이 아닌 예년같은 스타일이면 테스트 케이스도 많지 않고 정답인지 확인하기도 쉽다. 그러니 테스트 자동화와 TF 수는 문제 스타일에 따라 재고해봐야함.
= 튜터는 어느정도까지 관여 =
 * 처음에는 튜티들의 공평한 경쟁을 위해서 튜터가 최대한 관여를 안하는게 낫다고 생각했는데, 이번 대회의 의도는 서로 협력하는 게 의도였기 때문에 튜터의 지시에 제한을 거는 것은 문제가 있다고 판단함.
 * 그렇다고 튜터가 구현에 대한 생각을 다 하면, 튜티는 코드 짜는 기계가 되는 게 아니냐는 말이 나옴.
 * 대회 목적이 튜터같은 실력자가 구현을 하는 방법을 튜티가 배우는 게 목적이라면, 튜티에게 그런 걸 가르칠 수 있는, 기계적으로 남의 코드를 짜게 하는게 아니고 코드의 의미를 알게 할 수 있어야 함.
 * 그래서 튜터가 구현을 말을 하고 튜티가 코드를 짜게 하되, (11번 항목에서 설명할) 코드 띄우고 투표하는 시간에, 튜티가 나가서 그 코드의 역할과 이렇게 짠 의도 등을 발표하는 시간을 갖게 하면, 튜터가 튜티에게 코딩을 강제했는지 아니면 튜티가 이해할 수 있는 수준을 설명했는지 알 수 있다는 아이디어가 나옴.
= 비공개된 테스트 =
 * 참가자들이 제출할 답안을 위키에 올린 다음, TF가 위키에서 제출 답안을 받게 했는데 공개된 곳에 올리면 문제가 있다고 판단함. (실제로는 부정행위 문제는 안 생겼지만...)
 * 비공개된 테스트가 필요함. gist를 쓰자는 의견도 있긴 한데 결론적으로 비공개된 테스트 방법은 두 가지 조건이 만족되어야 한다.
 1. 제출 시간을 기록할 수 있을 것
 2. 다른 팀이 볼 수 없어야 함, 수정도 불가
= 주최자의 의도는 가르치는 거였는데 실제론 그걸 못함 =
 * 주최자의 의도는 있었는데 그걸 제대로 이끌어내질 못함. 이건 주최자가 너무 대충 생각함(부회장: 죄송합니다 ㅠㅠ)
 * 주최자가 배경지식에 대해 충분히 설명을 못함. (부회장의 변명: 너무 시작부터 사람들의 집중력이 떨어졌음. 특히 강단이 앞에 있는 장소에서 할거면 사람들이 앞을 바라보게 앉혀야 함. 그렇지 않으면 다 등 돌리고 자기 할 거 하고 있음. 참가자들이 앞을 보고 앉도록 TF에게 미리 시켰어야 했음)
 * 주최자는 또한 클린 코드에 대한 경험을 주고 싶었는데 대회 진행이 타임어택만 있었음. (변명: 타임어택이 가장 공평하게 평가할 수 있었고, 문제의 질을 따지는 것은 사람마다 제각각이라서 하기가 어렵다고 판단함.)
 * 만약 굳이 클린 코드를 의도로 해서 대회를 진행한다면, 다음 대회에서는 타임어택을 빼고, 제한된 시간 안에 코드를 완성해서 각자의 코드를 띄워두고 다른 팀보고 잘 짠 코드인지 투표하게 해서 가장 많은 좋아요(?)를 획득한 팀을 우승으로 하게 하자는 아이디어가 나왔음. 다음 회장단은 참고.
= 결론 =
 * 문제가 코드가 길어지고 어려울수록 대회 전에 TF 많이 뽑아서 기획해야함... 그렇지 않으면 위의 문제가 발생할 수 있음. 그리고 언제나 대회의 의도는 모두가 미리 공유하고 있어야 함.
 * 제발 행사 좀 도와줘... 왜 다들 바쁘다고 TF 해줄 수 있냐고 물어보면 도와주질 않냐...
-------------------------------------------------------------------------------------------------------------------
[CodeRace] [CodeRace/2016]