Acka1357's profile image

Acka1357

July 21, 2019 23:59

프로그래밍 대회를 개최하기 위한 10가지

이 글은 Ajou Programming Contest(2016-19 APC), 경인지역 6개대학 연합 프로그래밍 경시대회(2016-19 shake!), 전국 대학생 프로그래밍 대회 동아리 연합 여름 대회(2016 UCPC)를 운영했던 제 경험을 토대로 작성되었습니다. 프로그래밍 대회를 개최하려는 분들께 조금이나마 도움이 되었으면 하는 마음으로 대회를 맡으며 경험했던 시행착오를 모아 필요한 10가지를 정리해보았습니다.

어디까지나 제 개인의 경험에 기반한 내용으로 대회를 열기 위해서는 이래야 한다!가 아닌 아래 과정을 고려해보자는 의미로 읽어주시면 좋겠습니다. 일의 진행 순서로 나열하긴 했지만 모든 과정은 유기적입니다.

1. 대회의 성격: 참가 대상과 대회 목적을 명확히 함으로써 대회의 성격 및 형태를 결정합니다.
2. 기획 및 예산안: 대회의 시기와 운영, 상품에 대한 청사진을 그립니다.
3. 후원사: 일정 규모 이상의 오프라인 대회라면 운영을 위한 자금이 필요합니다.
4. 출제진: 프로그래밍 대회를 위해서는 대회에 사용할 새로운 문제가 필요합니다.
5. 대회 환경: 대회를 위한 플랫폼과 오프라인 대회를 위한 장소를 고려합니다.
6. 대회 홍보: 온라인/오프라인 홍보를 통해 더 많은 사람과 함께할 수 있습니다.
7. 선제: 좋은 밸런스의 문제 세트일수록 보다 많은 참가자가 즐길 수 있습니다.
8. 데이터 제작 및 검수: 문제 출제의 핵심 작업입니다.
9. 대회 전 준비: 대회 당일의 시나리오를 설정하고 필요한 것들을 미리 준비합니다.
10. 당일 운영: 아무리 준비를 하더라도 예상외의 상황은 언제나 발생할 수 있습니다.

생각보다 많아 보이죠? 실제로 많습니다. 다만 짐을 나눌 수 있는 사람이 있다면 훨씬 편해질 수 있습니다. 이 글은 모든 대회 준비 과정을 스스로 한다는 전제로 작성되었습니다. 그러니 보통 저 10가지를 본인이 모두 할 일은 없을 테니 너무 걱정 마시고 즐거운 대회를 만들어봅시다 :)

1. 대회의 성격

프로그래밍 대회에도 성격이 있습니다. 작게는 지인들끼리 즐기기 위해 자유롭게 진행하는 친선대회부터 교내 대회, 국가 대표를 선발하기 위한 올림피아드, 우수한 인재를 발굴하기 위한 기업대회, 학교간 교류를 위한 연합 대회 등 대회의 대상과 목적에 따라 대회의 성격과 형태가 달라지곤 합니다.

대회를 기획하고 있다면 누구를 위해, 어떤 목적으로 여는지를 먼저 명확히하는 것이 좋습니다. 누구나 참가 가능하며 최대한 많은 사람이 즐길 수 있는 대회? 물론 좋습니다. 하지만 이를 위해서는 참가 인원이 얼마나 될지, 온라인으로만 진행할지, 예선을 통해 참가자를 선별하여 오프라인 대회를 추가로 진행할지, 어떤 난이도의 문제 세트가 적절한지, 대회 방식은 어떤 스타일이 적합한지 등을 고려해야 합니다. 대다수의 사람이 한 문제도 풀지 못하거나, 선발의 목적을 띄고 있는 대회가 변별력이 없거나, 운영이 감당할 수 없는 규모의 참가자가 몰리는 등 대회에는 수많은 변수가 존재하기 때문입니다. 이를 위해 고려해야 할 것과 어떤 선택지가 있는지 알아봅시다.

• 참가 대상
  • 대학생 대회라면 대학원생을 포함할지, 휴학생 참가가 가능한지, 방학 때 열린다면 언제를 기준으로 재학 중 이어야 하는지 등을 미리 고민하고 고지하는 것이 좋습니다.
  • 매년 그 얼굴이 그 얼굴인 현상을 피하고 싶다면 기존 수상자를 제외하는 등의 제한도 고려해 볼 수 있습니다. 대표적으로 ICPC는 World Final에 2회 이상 출전했다면 이후 참가가 제한됩니다.
• 대회의 형태
  • ICPC 스타일처럼 문제를 완벽히 맞아야만 점수를 얻을 수 있는 형태와 통과한 테스트케이스만큼 점수를 받을 수 있는 서브태스크 스타일, 일주일 내내 열리며 그중 가장 좋은 해가 가장 높은 점수를 받는 마라톤매치 등 여러 형태가 있습니다.
  • 개인 대회인지, 혹은 팀으로 참가가 가능하다면 팀은 어떤 조건 내에서 몇 명이어야 하는지도 대회의 형태를 결정하는 요소입니다. 같은 소속의 팀원만 가능한 대회도 있고 이런 제한이 없는 대회도 있습니다.
• 대회의 규모
  • 어떤 참가자들이 얼마나 참가할지 어느 정도 예상이 되어야 준비해야 하는 문제의 난이도나 장소 등을 결정할 수 있습니다.
  • 오프라인 대회를 진행하고 싶은데 참가자가 너무 많다면 예선, 선착순, 추첨 등의 방법으로 규모에 맞게 참가자를 선별할 수 있습니다.

2. 기획 및 예산안

대회의 성격이 결정되었다면 이제 이를 위해 필요한 것들을 고려해야 합니다. 대회의 시기는 언제가 적절한지, 해당 날짜에 다른 큰 행사는 없는지 등을 확인하여 날짜를 정합니다. 특히 여름의 경우 크고 작은 대회가 많기 때문에 겹치지 않도록 요일 혹은 날짜를 조정하는 것이 좋습니다. 또한 몇 문제로 몇 시간이나 진행될지, 대회 전후로 필요한 행사는 없는지, 운영 구조는 어떻게 될지, 상품/상금에 대한 규모는 어느 정도가 적절한지 등도 기획안을 작성하며 보다 구체화할 수 있습니다.

기획안을 작성하는 것은 대회 계획의 구체화를 위해서도 도움이 되지만 운영 조직을 수립하거나 후원을 요청할 때 상대방의 행사 이해를 돕는 유효한 자료가 됩니다. 또한 기획안에서 규모와 운영 방향을 바탕으로 예산안을 작성하여 대회 성립을 위한 자금이 얼마나 필요한지도 미리 가늠해두어야겠죠? 상금 외에도 운영(출제, 시스템, 스태프), 식사(간식 포함), 홍보(포스터 혹은 홈페이지), 비품(대관, 문제지, 명찰, 풍선) 등의 분야를 구분하여 예산안을 작성한 후 필수적으로 필요한 비용과 비품을 고려해봅시다.

당연한 말이지만 대회의 규모가 커질수록 수행해야 하는 일과 필요한 역할들이 점점 많아집니다. 주의해야 할 것은 본인이 모든 일을 섬세하게 다 확인하지 않아도 되며, 그럴 수 없는 경우가 더 많다는 것입니다. 우리 몸은 하나니까요. 그러니 일을 기획할 때에 큰 그림을 그리되, 역할을 어떻게 나눌지도 미리 정하는 것이 좋습니다.

3. 후원사

상금이 없는 대회라도 일정 규모 이상의 오프라인 대회라면 운영을 위한 자금이 필요합니다. 미리 약속된 후원처가 있다면 정말 좋겠지만, 그게 아니라면 대회 수립 처음부터 필요 예산이 모이는 그 순간까지 계속해서 노력해야 하는 부분이며, 안타깝지만 노력하더라도 꼭 답이 나오는 부분은 아닙니다. 인지도가 있는 대회라면 후원사를 구하는 데 유리할 수 있으나, 가끔은 필요 자금을 모두 충당하지 못해 대회가 무산되거나, 자원봉사가 요구되거나, 진행자의 사비가 쓰이는 순간이 오기도 합니다.

교내 대회라면 먼저 학교와 논의하여 운영을 위한 예산 지원을 약속받은 후 일을 진행하는 것이 좋습니다. 어떤 지원도 없는 상태에서 대회를 기획하는 것은 무모할뿐더러 본인의 정신건강에 해로우니 꼭 일을 벌이기 전에 확률부터 계산해봅시다.

후원사를 구하는 방법은 다양합니다. 선배나 지인을 통해 해당 회사에 물어볼 수도 있고, 아무 인연이 없더라도 이메일을 통해 요청해 볼 수 있습니다. 혹은 SNS 등을 통해 공개적으로 모집하는 방법도 있습니다.

프로그래밍 대회를 응원하며 선뜻 응해주는 후원사를 위해 도움을 받는 입장에서 조금이나마 가치를 돌려줄 수 있다면 좋을 것입니다. 후원 요청을 할 때에는 제안 배경과 요청하는 내용(대회 홍보를 위한 로고 사용, 상품 비용 일부 등)과 함께 후원사를 위해 대회측에서 제안할 수 있는 내용도 고민해봅시다. 보통 후원 기업 소개 시간 제공 / 후원사와 관련된 문제 / 후원사 이름의 특별상 / 상위 입상자 정보 제공 등이 있습니다.

후원사는 대회 예산을 위해서도 필요하지만 참가자들의 보다 좋은 경험을 위해서도 다다익선입니다. 물론 너무 많다면 부작용도 있을 수 있겠으나.. 그런 행복한 고민을 해본 적이 없어 잘 모르겠네요.

4. 출제진

대부분의 대회는 새로운 문제를 사용하여 진행되며, 이를 위해서는 문제를 만들고 검수하는 출제진의 역할이 굉장히 큽니다. 특히 문제는 운영 부분을 제외하면 참가자들의 경험을 결정하는 가장 큰 요소입니다.

출제진을 꾸릴 때에는 교내대회의 경우 이전 수상자들을 모을 수도 있고, 지인에게 부탁하거나 함께해줬으면 하는 사람에게 직접 권유하는 등 출제할 사람을 미리 정해 놓는 방법이 있습니다. 또한 Call for Task와 같이 공개적으로 문제를 모집하고 모집된 문제를 사용하는 방법도 있습니다. 이 단락에서 사용되는 경험은 전자의 것입니다. 만약 자신이 운영 일로 너무 바쁘다면 출제 쪽은 믿을 수 있는 다른 사람에게 컨트롤 타워를 맡깁시다. 운영과 출제를 함께 하는 것은 생각보다 힘들 테니까요.

출제하기 전 먼저 참가자들의 규모와 수준을 예측한 후 목표 문제 수와 난이도 커브를 설정합니다. 이때 대회의 성격에 따라 문제에 사용되는 알고리즘의 종류나 난이도를 제한할 수도 있습니다. 물론 이는 출제 전 출제진들에게 공지되어야겠죠?

보통 출제한 문제가 모두 사용되는 경우는 드뭅니다. 너무 쉽거나 어려운 문제만 많거나, 분야가 겹치는 등 사용하지 못하게 되는 경우가 있기 때문에 우선은 문제 풀을 넉넉히 구성해 야합니다. 드라이브나 깃헙을 통해 자유롭게 출제를 진행하되 이 시점에는 문제의 초안 정도만 있어도 충분합니다. 또한 출제 과정 중 틈틈이 다른 사람의 문제를 보고 겹치지 않도록 하는 센스가 있다면 좋겠죠. 이후 출제된 문제들 중 선제를 통해 대회에 사용될 문제를 선별합니다. 이에 관해서는 선제에서 좀 더 자세히 다룹니다.

출제부터 선제를 거쳐 데이터 제작과 검수까지는 꽤 긴 여정이니 넉넉히 대회 시작 두 달 전부터 준비하는 것을 추천합니다.

5. 대회 환경

대회를 진행하기 위해서는 대회를 위한 기능이 있는 플랫폼이 필요합니다. 대회를 위한 기능이란 참가자를 식별할 수 있고, 코드를 제출 할 수 있으며 이를 채점할 수 있는 등의 기능을 말합니다. Baekjoon Online Judge, Codeforces와 같은 기존 플랫폼에 문의하여 과정을 따라 대회를 여는 방법이 있으며, 자체 플랫폼을 만들어 사용할 수도 있습니다.

다만 자체 플랫폼을 사용하고 싶다면 대회 기능뿐만 아니라 대회 인원을 수용할 수 있는지에 대한 스트레스 테스트, 문제 및 시스템 보안에 특히 신경 써야합니다. 바닥부터 만드는 것이 어렵다면 DOMjudge나 hustoj 등의 오픈소스를 사용할 수 있습니다. 또한 단발성이 아닌 지속적으로 자체 플랫폼을 이용해 대회를 진행한다면 이후 유지/보수에 대한 고려도 해야 합니다. 열심히 만든 플랫폼을 시스템 담당자가 바뀌었다는 이유로 사용하지 못하게 된다면 정말 슬플 테니까요.

오프라인 대회를 진행하기 위해서는 대회 장소에도 특별히 신경을 써야 합니다. 참가자들을 수용할 수 있을 만한 규모인지, 데스크탑으로 진행되는 대회라면 그 수가 충분한지, 개인 노트북을 이용하는 대회라면 네트워크 수용량이 충분한지, 노트북 충전을 위한 콘센트는 충분한지, 테이블의 배치는 적절한지, 대회 전후 행사를 위한 빔프로젝터와 스크린이 있는지, 스태프들이 쉴 곳이나 운영룸으로 쓸 가까운 공간이 있는지 등. 대학교 강당 등을 빌려 설비를 마련할 수 있다면 다행이지만 이런 조건을 충족하는 장소가 생각보다 많지 않습니다. 다른 대관처를 알아본다면 대관료도 생각해야겠죠? 운이 좋다면 후원사에서 보유한 공간에서 진행할 수도 있지만 기대하기는 어렵습니다.

또한 참가자가 대회 중에 대회 플랫폼 외에 다른 사이트를 사용할 수 있는지도 미리 결정해야 하고, 소프트카피와 하드카피 지참 및 참고에 관해서도 규정을 마련해야 합니다. 모든 걸 다 허용한다면 편하겠지만, 아니라면 이를 시스템으로나 감독 스태프를 통해 어떻게 규제할 것인지도 생각해야 합니다.

6. 대회 홍보

대회를 위한 필수적인 것들이 마련되었다면 이제 참가자를 모집할 시간입니다. 보통 대회에 흥미를 가진 사람이 많이 모일법한 온라인 커뮤니티 등에 게시글로 홍보합니다. 이때 대회의 정보와 참가신청지를 줄글로 공유하는 방법도 있겠으나 대회의 정보를 담고 있는 사이트가 있다면 좀 더 효과적으로 홍보할 수 있습니다. 여기에 대회 내용을 한눈에 볼 수 있는 포스터 등이 있다면 SNS에서의 홍보도 좀 더 쉽게 할 수 있겠죠?

교내 대회라면 실물 포스터를 부착하거나 학교 측에 요청하여 문자나 이메일 등을 통해 홍보할 수 있다면 더 많은 사람과 함께할 수 있을 것입니다.

7. 선제

출제를 통해 만들어진 문제 풀에서 실제로 대회에 쓰일 문제들을 선발합니다. 다양한 분야와 좋은 난이도 커브를 갖추기 위해 출제진은 선제 전 출제된 문제들을 비교하고, 분석해야 합니다.

기존에 유사한 문제가 있지는 않은지, 혹시 카피 문제는 아닌지 등의 검사가 이루어지고, 서로 생각해 온 솔루션과 난이도를 공유합니다. 좋은 문제가 많이 없어도 고민이지만 좋은 문제가 너무 많더라도 고민입니다. 앞서 말했듯이 대회에 낼 문제 수는 정해져 있기 때문에, 참가자들의 최상의 경험을 위해 일부 문제는 선택되지 않을 수 있습니다. 좋은 문제라도 해당 분야나 비슷한 난이도의 문제가 너무 많을 때에는 눈물을 머금고 떠나보내야 합니다.

일부 문제는 난이도나 풀이를 다르게 하기 위해 선제 과정에서 조건이나 제한 등이 수정될 때도 있습니다. 어려운 난이도를 목표로 낸 문제여도 아래 난이도가 부족하다면 제한을 줄여 난이도를 완화할 수 있고 출제자가 생각하지 못한 더 좋은 솔루션이 있는 경우에는 제한을 늘려 난이도를 높이기도 합니다.

선제 과정에서 중요한 것은 출제된 문제에 대한 솔직한 평가와 토의, 그리고 참가자의 눈높이에서 생각하는 것입니다. 출제자들은 가끔 자신이 출제한 문제에 대해 지나치게 낮에 평가하는 경향이 있으며 출제진이 예상한 난이도와 실제 대회에서 참가자들이 풀어나가는 난이도는 상이할 수 있습니다. 그러니 보다 예쁜 스코어보드를 만나기 위해서는 참가자의 역량을 필수적으로 고려하여 의견을 맞춰나가야 합니다.

선발된 문제만으로 탐탁지 않다면 선제 후에도 계속 새로운 문제를 제작하기도 합니다. 물론 이런 일 없이 좋은 문제가 충분히 모여있는 상태에서 선제를 진행하는 게 가장 좋습니다. 출제 기간이 길다면 좀 더 좋은 문제들이 모일 가능성이 높지만 이후 있을 데이터 제작 및 검수가 정말 중요하고 충분한 시간을 필요로하기 때문에 적당한 선을 정합시다.

8. 데이터 제작 및 검수

문제 출제의 핵심 작업입니다. 선제에서 선발된 문제들을 대회에 사용하기 위해서는 참가자들의 코드가 맞는지 검증하기 위한 데이터(테스트케이스)가 필요합니다. 출제자의 의도에 맞는 풀이를 통과시키고, 그렇지 않은 풀이를 막기 위해서는 ‘좋은 데이터’가 필요합니다. 출제진은 최대한 다양한 형태의 데이터와 코너케이스를 고려해야 합니다.

예를 들어 트리 문제라면 사향트리, 이진트리를 비롯해 다양한 형태의 트리 데이터가 필요하고, 최소 조건과 최대 조건에 맞춘 데이터도 있다면 좋을 것입니다. 오버플로우를 유발하는 데이터나 그리디한 접근을 막는 데이터, 그래프 문제라면 완전 그래프나 솜털 모양의 그래프, 컴포넌트가 여럿으로 나누어진 데이터 등등 참가자들의 상상력은 무시무시하기 때문에 문제 유형에 따라 필요한 데이터는 굉장히 다양합니다.

이렇게 데이터 생성 코드와 솔루션 코드, 틀린 코드를 여럿 작성하여 의도대로 통과하는지, 데이터에 문제는 없는지 등의 작업에는 문제 출제 플랫폼인 Polygon을 추천합니다. 이 포스팅에 폴리곤 사용법에 대한 간단한 내용이 있으니 도움이 된다면 좋겠습니다.

또한 출제진 내부 검수만으로 충분하지 않다고 생각되거나 실제 참가자들이 문제를 어떻게 풀어나갈지 알고 싶다면 외부 검수를 진행하는 것도 좋은 방법입니다. 물론 외부 검수자는 대회에 참가하지 않는 사람이어야 하며, 문제를 유출하지 않을 것이라는 신뢰가 있는 사람이어야 합니다. 내부 검수와 외부 검수 모두 선제 때와 마찬가지로 가감 없는 의견 교환이 바탕이 되어야 합니다.

모든 과정이 끝났다면 각 문제에 알맞은 메모리제한과 시간제한을 설정합니다. 이는 출제자의 의도보다 좀 더 넉넉하게 하는 것이 좋습니다. 같은 솔루션임에도 참가자마다 누군가는 통과하고, 누군가는 통과하지 못하는 상황을 피하기 위해서입니다. 하지만 넉넉하게 잡는 바람에 의도하지 않은 솔루션까지 통과하는 일이 발생하기도 하니, 이 과정 역시 다양한 방법의 실험이 필요합니다.

특히 C/C++이 아닌 다른 언어를 지원하는 대회에서 각 언어에 대한 솔루션을 보장하는지에 따라 다양한 언어의 솔루션 역시 테스트 되어야 합니다. 보통 C/C++, Java 까지는 메모리/시간 내에 통과하는 솔루션이 있음을 보장하지만 Python 등의 언어에 대해서는 보장되지 않는 경우가 많습니다.

데이터와 솔루션뿐만 아니라 문제 자체에도 집중해야 합니다. 지문이 너무 삼천포로 빠지지는 않는지, 참가자들이 이해할 수 있는 용어를 썼는지, 빠진 조건은 없는지, 예제를 통해 알려주고 싶은 내용이 있는지 등을 포함해 자신의 문제뿐 아니라 다른 출제자의 문제도 계속 읽어보면서 다듬은 후 마지막으로 맞춤법 검사까지 할 수 있다면 좋겠죠? 초보자가 많은 대회라면 지문과 예제 설명이 좀 더 친절하면 좋을 테고, 글만으로 이해가 어려운 문제에는 그림을 첨부하는 것도 추천합니다. 물론 데이터와 솔루션에 비하면 이런 부분은 선택사항이긴 합니다.

9. 대회 전 준비

플랫폼과 대회에 사용할 문제 준비가 끝나고 대회를 위한 장소까지 마련되었다면 이제 대회 당일 행사를 위한 준비를 할 때입니다. 이를 위해서는 대회 당일 일정에 따라 시나리오를 작성해보는 것이 도움이 됩니다.

스태프가 맡을 역할과 대회장 규모를 생각하여 당일 현장 관리를 위한 스태프가 몇이나 필요한지, 누가 언제 어떤 일을 할지를 정리하다 보면 언제 어떤 것이 필요하고 어떤 순서에 어떤 일을 해둬야 하는지가 보입니다. 간식이나 식사의 경우 미리미리 예약하면 원하는 때에 대회장으로 배달받을 수 있습니다.

대회 장소는 대회 전에 미리 가서 인터넷 환경이나 자리 배치 등을 체크하고, 참가자 이동 동선을 예측하여 등록 테이블이나 티셔츠, 명찰, 간식 등을 어디에 배치할 지 미리 알아두면 좋습니다. 문제지 합본, 풀이 슬라이드, 행사 진행 및 주의사항 슬라이드, 자리배치표, 참가자 명찰이나 등록지는 미리 만들어 둡시다.

대회 당일 스태프들의 업무나 주의사항을 안내하겠지만, 혹시 빼먹는 내용이 있을 수 있으니 미리 스태프 가이드를 작성해보고 공지합시다. 여유가 된다면 참가자들에게 메일을 보내 당일 일정과 필요한 것을 다시 한번 안내하는 것도 좋습니다. 외에도 당일 주차장이나 흡연 문의가 있을 수 있으니 이런 부분도 미리 알아보면 좋습니다.

10. 당일 운영

스태프들과 함께 당일 대회 환경을 마련한 후, 참가자들이 오면 이제 마지막 관문입니다. 대회 전 이것저것 시나리오를 생각하더라도 당황스러운 일이 종종 생깁니다. 이런 때를 대비해 되도록 자리를 비우지 않을 것을 권장합니다. 본인은 자리를 지키고, 현장의 각 역할 대표들에게 연락을 받고, 이를 어떻게 대처할지 등에 관한 결정을 전달하는 편이 좀 더 안정적으로 대회를 운영할 수 있습니다.

출제진들은 운영룸을 지키면서 대회 중 문제에 대한 질문에 대응합니다. 생각보다 사람들이 너무 많이 틀리거나 맞고 있다면 제출된 코드나 데이터를 한 번 더 확인해봅시다. 참가자들이 자주 하는 실수에 대해 대회가 끝난 후 풀이에서 첨언하는 것도 좋습니다.

마치며

대회를 연다는 것은 생각보다 많은 정성과 노동을 요구합니다. 다시 한번 강조하지만 모든 일을 본인이 할 수는 없습니다. 만약 교내 대회를 진행하고자 하는 학생이라면 학교 측에 의존하는 부분을 늘려 본인의 일을 줄이는 것을 추천합니다. 다만 해당 일을 맡는 사람이 프로그래밍 대회에 익숙하지 않은 사람이라면 필수적인 내용은 충분한 설명과 함께 미리 전달해야 합니다.

또한 대회가 끝난 후, 대회를 위해 도움을 준 모두에게 감사를 전하는 것을 잊지 맙시다. 특히 후원사 등에는 감사의 말과 함께 행사 결과를 담은 메일을 보내는 것이 좋겠죠? 아, 후원사에 참가자 정보를 제공할 예정이라면 참가자 등록 등의 과정에서 이에 관해 설명하고 정보 제공 동의를 받는 것도 잊지 마세요.

대회 개최는 생각보다 많은 과정이 필요하고, 모든 일이 뜻대로 되기는 힘듭니다. 모든 과정은 서로 유기적으로, 하나의 일이 밀리거나 잘못되면 다른 작업까지 연장되는 일이 많습니다. 그러니 두루 신경 쓰면서 항상 일정에 여유를 두세요. 꼭.

만약 지속 가능한 대회를 원한다면 일련의 과정을 문서로 남기고, 이후 맡게 될 사람들에게 꼭 공유해주세요. 이 글은 간단하게밖에 적지 못했지만, 각자의 대회는 각자의 사정과 환경이 있을 테니 새로운 경험을 하게 될 사람에게는 더없이 좋은 지표가 되어줄 것입니다.

그럼 모두 탈 없이, 즐거운 대회 되세요!