의외로 전국 대학생 프로그래밍 경시대회ICPC 리저널이 매년 열리는 나라는 많지 않습니다. 서강대학교에서는 2005년부터 매년 대회를 열어 작년에는 무려 17번째 교내 프로그래밍 대회가 열렸고, 전국 대학생 프로그래밍 대회 동아리 연합에서는 올해로 11번째 대회를 개최했습니다. 넥슨과 삼성전자 — 대한민국 최고의 게임 기업과 대한민국 최대의 정보기술 기업 — 도 꾸준히 관심을 갖고 대회를 열고 있습니다(각각 7회, 8회째). 최근에는 현대모비스 및 여러 스타트업들도 자체 대회를 개최하고 있습니다.
이렇게 프로그래밍 대회에 대한 국가적 관심이 커지고 있는 상황에서 학교/동아리 및 커뮤니티 대회 개최에 대한 수요가 커지는 것은 어떻게 보면 당연한 일인데요, 백준 온라인 저지가 학교/동아리 대회에 대해 무료로 채점 환경을 제공하고 있다는 건 참 다행인 점입니다.
디스크립션 작업에서 발생하는 문제들
하지만 이런 좋은 플랫폼이 있음에도 불구하고 온사이트 대회에서는 문제지를 만들어야 한다는 점 때문에 디스크립션을 작성하는 과정에서 마주하는 근본적 문제들이 존재합니다.
출제자: (BOJ에서만 지문을 수정하고) 디스크립션 수정했어요!
검수자 A: (출력할 문제지를 보면서) 🤔 어디가 수정됐다는 거지…
검수자 B: (BOJ 지문과 출력할 문제지가 다른 상황을 보면서) 😵 어느 쪽이 의도된 지문일까?
이런 상황이 생길 수 있기 때문에 세팅 경험이 많은 사람이 있다면 BOJ와 문제지 중 한 쪽을 유일한 원천single source of truth으로 두고 작업하도록 하는 경우를 볼 수 있습니다. 가령 지문 작업은 BOJ에서만 하고 마지막 날에 모든 문제를 문제지에 옮긴다던가, 아니면 반대로 하는 식입니다.
그래도 여전히 몇 가지 문제가 있습니다. 가령 문제지를 Google Docs나 Word 등에서 작업하고 BOJ Stack에 붙여넣으면 포매팅이 영 이상해집니다.
BOJ에 문제를 올리려면 HTML이 꽤 깨끗해야 합니다. 개인적으로 좋은 제약조건이라고 생각합니다. 근데 워드 프로세서는 일반적으로 그렇지 않죠. 이 제약 때문에 워드 프로세서에서 바로 붙여넣기할 수 없습니다.
그렇다고 메모장에 붙여넣은 후 거기서 다시 가져오자니 열심히 만들어 둔 예쁜 리스트와 수식들이 전부 깨집니다. 공들여 만든 수식 $X=\frac{p_1l_1+p_2l_2+\cdots +p_Nl_N}{p_1+p_2+\cdots +p_N} =\frac{\sum_{i=1}^{N}p_il_i}{\sum_{i=1}^{N}p_i}$를 붙여넣었더니 X=p1l1+p2l2++pNlNp1+p2++pN=i=1Npilii=1Npi가 되어 있는 건 그다지 유쾌한 경험은 아니겠죠.
반대로 가자니… BOJ 수식 렌더 방식은 LaTeX인데, 이걸 그대로 지원하는 워드 프로세서는 잘 없는 것 같고, 그렇다고 Markdown 기반으로 작업하자니 글자에 색상을 못 넣는다거나 그림 포매팅을 자유롭게 하지 못하는 등의 제약이 많습니다.1
워드 프로세서를 사용하지 않는다면 어떨까요? 프로그래밍 문제의 디스크립션에는 수식이 정말 많이 등장하기 때문에 ICPC를 비롯한 여러 대회에서 여러 세터들이 LaTeX로 세팅하는 편입니다. 요즘에는 문제 제작에 있어서 필수불가결한 플랫폼인 Codeforces의 Polygon 플랫폼도 디스크립션을 LaTeX로 입력하도록 하고 있으며, UCPC도 LaTeX로 문제지를 세팅하고 있습니다.
BOJ의 수식 렌더 방식이 LaTeX라니 뭔가 순조롭게 옮길 수 있을 것 같습니다. 하지만 LaTeX에도 문제가 많습니다. 가령…
수식뿐 아니라 본문에서도 여러 명령어를 사용할 수 있습니다. 예를 들어 \alpha 명령어는 그리스 문자 α를 입력합니다.
리스트도 명령어를 쳐서 만듭니다. \begin{enumerate} ... \end{enumerate} 등입니다.
기타 LaTeX만의 이상한 점들이 있습니다. 예를 들어 '는 무조건 오른쪽 닫는 작은따옴표입니다. ``는 왼쪽 여는 큰따옴표를 렌더합니다.
결국 지금까지는 어떻게 하든 문제마다 디스크립션을 한 땀 한 땀 옮겨 줘야 하는 경우가 대부분이었습니다. 제 경우에는 이런 작업을 2019/2020/2021년 서강대학교 프로그래밍 대회, 2020/2021 겨울/2021 여름 신촌 연합, UCPC 2020의 일곱 번의 대회에서 모든 문제에 대해 해 왔고 올해도 숨은 왼쪽 여는 따옴표 찾기를 하고 싶지는 않았습니다.
그래서 LaTeX, 특히 Polygon 플랫폼과 많은 대회들이 사용하는 olymp.sty 형식 디스크립션들을 복사-붙여넣기할 수 있는 HTML로 바꿔 주는 툴을 만들었습니다. latex-utensils를 이용해 LaTeX를 파싱해 AST로 만들고, AST를 탐색하면서 다시 HTML로 빌드해 주는 툴입니다. 생성되는 HTML은 BOJ Stack 가이드라인을 최대한 따르려고 노력합니다.
원하는 경우 MathJax를 사용하지 않고 sup, sub, em 등을 이용해 수식을 렌더하도록 할 수 있습니다. 이 모드에서 렌더한 모든 수식도 BOJ 가이드라인을 최대한 따르려고 노력합니다. 예를 들어,
LaTeX에서는 연산자와 문자 사이에 띄어쓰기가 없더라도 변환된 HTML에는 자동으로 띄어쓰기가 들어갑니다.
수식 안에 있는 모든 문자는 HTML로 변환할 때 이탤릭이 됩니다.
\times는 ×가 됩니다. - (빼기 기호)는 −가 됩니다.
라이트 버전 MathJax라고 생각하시면 됩니다. 아직 안 되는 것들도 있습니다. 명령어 재정의와 tabular 환경, 그리고 이미지 지원이 대표적인 예인데, 이미지 지원을 제외하고는 아마 다른 대회에서 출제/검수를 맡게 될 때 만들지 않을까 싶습니다.
바뀐 워크플로우
이제 Polygon 패키지 혹은 문제지를 만들고, 변환기의 도움을 받아 HTML로 변환한 뒤 BOJ Stack에 복사/붙여넣기만 하면 됩니다.
디스크립션 작업을 버전 관리가 되는 Polygon 혹은 실시간 편집이 되는 Overleaf의 둘 중의 하나로 일원화할 수 있어서 플랫폼 간의 컨플릭트가 사라지고, LaTeX에서 HTML 또는 HTML에서 LaTeX로 변환하는 과정을 더 이상 손으로 하지 않아도 되기 때문에 실수할 여지도 줄어들고 시간도 아낄 수 있습니다. 디스크립션 변환할 시간에 틀린 풀이 하나 더 짜고 데이터 하나 더 만들어 넣을 수 있게 되었습니다.
이미 UCPC 2022의 모든 문제를 이 툴을 사용해 변환했습니다. 모든 변환은 클라이언트에서 이루어지니 문제 유출 염려 없이 안심하시고 사용하셔도 괜찮습니다.
ckeditor 대응
Stack은 ckeditor를 쓰고 있는데, 포매팅이 있는 외부 HTML을 복사-붙여넣기하면 시맨틱한 요소를 빼고 모든 포매팅을 지워 버립니다. 아래 스크립트를 실행해 붙여넣기 필터를 전부 없애 줘야 합니다.
var o=CKEDITOR.filter.instances;Object.keys(o).forEach((k)=>o[k].disable())
여담
툴이 완벽하지 않은 부분들이 있으니 버그를 발견하신 경우 GitHub에 이슈 혹은 PR을 남겨 주시면 감사하겠습니다.
각주
디스크립션에서 글자에 색상을 넣지 못하는 건 의외로 중요한 이슈입니다! 특히 입력부에서 제시하는 어떤 문자열을 그대로 출력하라고 할 때 모노스페이스 폰트와 함께 글자 색상을 바꾸면 가독성이 굉장히 향상됩니다. ↑
언어는 도구에 불과하다고들 합니다. 그리고 모든 도구는 용도와 장단점이 있습니다. 알고리즘 문제해결 필드에서 언어라는 도구를 어떻게 사용하면 좋을까요?
프로그래밍 대회에서의 문제해결에 대해 많은 이야기를 할 예정이지만 이제는 코딩 테스트도 알고리즘 문제해결에서 상당한 비중을 차지하고 있기 때문에 먼저 코딩 테스트에 대해 간단하게만 이야기해보겠습니다.
코딩 테스트
코딩 테스트는 기업이 많은 지원자를 세심하게 리뷰하기 힘들기 때문에 두는 스크리닝screening 과정 중 하나로, 코딩 테스트 문제의 출제 목적은 수험자의 구현력과 논리적 사고력이 일정 수준 이상인지 평가하는 데에 있습니다.
일반적으로 같은 알고리즘을 짠다면 C++로 짜는 게 시간/공간 사용량 면에서 가장 효율적이라고 합니다. 하지만 현업에서 모두가 C++을 사용하지는 않죠? 가령 Typescript로 백엔드 개발을 하는 조직이 있는데 C++로 지원자를 평가한다고 생각해 봅시다. 지원자는 C++에 대한 이해가 부족해 Javascript에서 하던 것처럼 vector<int> 값을 &나 *도 안 붙이고 함수 인자로 넘겨버립니다.1 이 얼마나 끔찍한 일인가요? 지원자는 제 실력을 못 내고, 회사는 지원자를 제대로 평가할 수 없게 됩니다.
그래서 일반적으로 코딩 테스트 문제들의 시간 제한과 메모리 제한은 언어마다 다르도록 설정하거나 언어에 따라 배수를 두는 편입니다. 그래서 저는 코딩 테스트를 준비하시는 분들께는 자신이 가장 자신있는 언어 혹은 입문하기 쉬운 언어로 시작하시기를 추천드립니다.
문제를 만드는 입장에서 여러 언어의 존재는 참 머리아픈 일입니다. $\mathcal{O}\left(n^2\right)$ 솔루션은 돌게 하고 싶지만 $\mathcal{O}\left(n^2 \log n\right)$은 돌지 않게 하고 싶은 경우에서 C++만 놓고 생길 수 있는 일들에 대해 알아봅시다.
$\mathcal{O}\left(n^2\right)$ 솔루션 — 1.4초
$\mathcal{O}\left(n^2\right)$ 솔루션 + mmap fast I/O + Ofast — 1.0초
결국 언어가 하나 추가될 때마다 모든 언어에 대해 문제 상황과 시간 제한, 그리고 데이터를 다시 고민해야 하는 상황에 빠집니다! 특히 언어별로 추가 시간을 주지 않는 일반적인 ICPC 스타일 대회의 경우 시간 제한 설정의 난이도는 말 그대로 기하급수적으로 증가합니다. 솔루션을 작성하는 데 있어서도 언어별로 조심해야 할 점들이 다른 건 말할 것도 없구요.
이렇게 여러 언어를 대응하는 것은 공수가 많이 드는 일이기 때문에 보통은 C++ 솔루션만 작성하고 다른 언어의 통과를 보장하지 않습니다. 알고리즘 대회에서 코드 간 형평성은 시간 복잡도를 기준으로 결정하는 것이 가장 좋다고 생각하는 입장에서는 언어별 추가 시간을 줬다가 Python에서 비효율적인 시간 복잡도로 작성한 코드가 통과할 수도 있고요.
참가자 입장에서
그래서 프로그래밍 대회 참가자 입장에서는 C++ 스탯만 쌓아도 충분합니다. 프로그래밍 대회들이 C++에서 풀기 까다로운 문제들을 잘 안 내는 것도 있습니다.
하지만 해결가능성이 C++만으로 보장되더라도, 보통은 다른 언어들의 사용을 어느 정도 허용하기 때문에 여러 언어들의 사용 방법을 알아 둬서 나쁠 건 전혀 없습니다. 문제를 읽고 머릿속에서 코드 길이 견적을 내 봤는데 C++ 코드보다 Python 코드 길이가 훨씬 짧다면, Python으로 코드를 짜고 해결 시각에서 상당한 우위를 점할 수 있습니다.
또한 언어별로 특징적인 기능들이 존재하는 경우 이 기능들을 최대한 활용해 문제해결 도움을 받을 수도 있습니다. C++이 아닌 언어에서 문제해결이 현저히 쉬워지는 몇 가지 예를 소개합니다.
문자열 다루기 — Python
문자열 파싱은 Python에서 쉬워지는 경우가 많습니다.
C++의 std::string은 일반적으로 다른 언어에는 있는 split이 없고, char를 하나하나 처리하기 싫다면 std::istringstream 등을 이용해야 합니다.
C++의 경우 비 ASCII 문자의 처리가 어렵습니다. 비 ASCII 문자들은 나오면 안 된다고 생각하는 것과 별개로….
C++의 정규식은 활용하기가 귀찮게 되어 있습니다.
Python의 f-string이 너무 강력합니다.
C++로 문자열에서 숫자들을 찾는 정규식을 구현하면 이렇게 됩니다.
regex re("\\d");
string str;
auto begin = sregex_iterator(str.begin(), str.end(), re);
auto end = sregex_iterator();
for (auto iter = begin; iter != end; iter++) {
smatch match = *iter;
cout << match.str() << " ";
}
cout << endl;
Python으로는 비슷한 작업을 아래와 같이 할 수 있습니다.
import re
p = re.compile('\\d')
result = p.findall(str)
print(result)
크고 정확한 수 다루기 — Python, Java, Kotlin
C++에서 가장 큰 부호 있는 정수 자료형은 $2^{63}-1 \approx 9.2 \times 10^{18}$까지를 표현할 수 있습니다.3 많은 문제들의 $N$ 제한이 $10^{18}$을 잘 초과하지 않는 이유이기도 합니다.
하지만 이 범위를 넘어가는 수의 사칙연산이 필요하다면 직접 구현체를 만들어야 합니다. 특히 큰 수의 곱셈과 나눗셈의 경우 단순히 $\mathcal{O}\left(1\right)$로 생각할 수 있는 문제가 아닙니다. $n$자리 곱셈을 초등학교에서 하듯이 구현하면 $\mathcal{O}\left(n^2\right)$의 시간이 걸리며, 더 효율적인 곱셈 방법이 필요하다면 $\mathcal{O}\left(n^{\log_2 3}\right)$의 Karatsuba 알고리즘 혹은 $\mathcal{O}\left(n \log n\right)$의 FFT를 짤 수 있어야 합니다.
정수 곱셈 문제들을 FFT로 풀 수 있듯이 이 사실에 기반해 FFT 문제를 Python 정수로 풀 수도 있기는 합니다. 아래는 이동 (BOJ #1607)를 실제로 Python으로 해결한 코드입니다. Karatsuba는 FFT보다 느린 경우가 많기 때문에 굳이 추천하지는 않고 대충 이런 방법도 있다는 걸 보여드리기 위해 남깁니다.
정확한 유리수 표현arbitrary precision이 필요한 경우 Python decimal과 Java BigDecimal을 사용할 수 있습니다. 추가로 Python은 어떤 유리수도 표현 및 계산할 수 있는 Fraction 모듈을 제공합니다.
특히 Google Code Jam에서는 제한이 $10^{18}$을 초과하는 큰 수를 다루는 문제들이 종종 등장하므로 알아 두면 좋습니다.
C++에서 mod $p$의 나눗셈을 하려면 보통 Fermat의 소정리($n \times n^{p-2} \bmod p = 1$)를 바탕으로 분할 정복을 이용한 거듭제곱을 구현합니다.
놀랍게도 Python의 내장 pow 함수는 서로소인 $n$과 $m$에 대해 $n \bmod m$를 빠르게 구할 수 있습니다. 심지어 $m$이 소수가 아니어도 됩니다. C++에서는 $m$이 소수가 아닌 경우에는 Euler’s totient function 혹은 확장 Euclidean 알고리즘 구현에 대해 알고 있어야 합니다.
다각형의 bool 연산(and, or, xor 등)은 C++로 직접 구현할 경우 상당히 다루기 힘든 주제입니다. Java의 java.awt.geom은 이런 작업들을 처리해 주는 구현체입니다. 단순다각형뿐만 아니라 원, 타원, 2-3차 베지어 곡선 등으로 이루어진 도형의 불 연산을 처리할 수 있고, 구한 도형의 꼭짓점 정보 등을 쉽게 구할 수 있습니다.
java.awt.geom 패키지를 활용해 문제를 해결하면 난이도가 꽤 낮아지는 문제들의 예시로는 이런 것들이 있습니다.
여기 졸업을 앞두고 있는 사람 두 명과 펍지 엔지니어 한 명, 넥슨 엔지니어 한 명이 있습니다. 이 사람들은 어쩌다 이런 시국에 인천공항 버거킹에 모이게 되었을까요.
세렌디피티
휴가를 쓰고 호캉스를 온 날 조식을 먹으러 가려던 찰나 이상한 메일을 받게 됩니다. Fwd: ICPC World Finals Moscow – Sogang University라는 제목의 메일입니다. 월드 파이널? 대체 왜? 하는 심정으로 열어본 메일에는 믿기 힘든 내용이 적혀 있었습니다.
‘서강대학교 ICPC 관련인들께, […] 팀 Redshift가 모스크바에서 열리는 월드 파이널의 참가 자격을 얻게 되었습니다. 10월 1일에서 6일까지 모스크바에 올 수 있으면 됩니다. 한국에서 코로나19가 유행하면서 모스크바까지 오는 것이 힘들지도 모르겠습니다만, (아직까지 참석 가능성에 대한 회신이 없는 관계로) 팀이 정말 희망이 없는지 ICPC 매니저께서 확실히 알아야 합니다. 임 코치님께 회신을 요청해 주시면 감사하겠습니다.’
‘안녕하세요 코치님, […] 8월 9일 오후 11:59 CST까지 회신 부탁드리겠습니다. 이 때까지 회신이 없으면 참가하지 못하는 걸로 간주하도록 하겠습니다. 질문이 있으면 자유롭게 회신 부탁드려요. 월드 파이널에서 뵙길 바라겠습니다!’
맙소사, 오늘은 8월 12일인데…
빠르게 머리를 굴려 봅니다. 스팸메일은 아닌 거 같다. 진짜 월드 파이널에 진출한 거 같긴 하다. ICPC 본부에서 8월 9일까지 답장을 주라고 했는데, 8월 12일에 이런 메일이 왔다. 그것도 학회 홈페이지 맨 밑에 적힌 메일 주소로 왔다.
그러면 제가 할 일은 명확했습니다. 최대한 빨리 회신을 보내야 합니다. 바로 코치 교수님과 팀원들에게 전화를 걸어서 협조를 구했습니다.
첫 번째 산: 참가 신청
2019년 레드시프트는 17학번 박건(lvalue), 17학번 이준석(semteo04)과 저(shiftpsh)로 이루어진 팀이었습니다. 같은 나이라서 서로 편하게 반말하고 있어요. 글을 읽고 계신 분들이라면 이름보다는 핸들이 더 익숙할 테니, 앞으로는 핸들로 적도록 하겠습니다.
semteo04는 펍지에서 산업기능요원으로 복무 중입니다. 그렇다는 건 보통 평일 아침에 일어나 있고, 따라서 전화를 받을 수 있다는 뜻입니다. 누구보다 경쟁 프로그래밍에 진심인 친구여서 아마 월파라면 무슨 일이 있어도 휴가를 쓰고 비행기에 함께 오를 것입니다. 그리고 몇 분 안 지나 제가 옳게 봤다는 걸 확인할 수 있었습니다.
lvalue는 졸업하고 KAIST AI대학원에서 연구를 하고 있습니다. 아마 아침에 안 일어나 있을 것입니다. 평소에도 전화를 안 받기로 유명합니다. 나중에 연락하기로 합니다. 다행히도 트위터 맞팔이라, 멘션이나 DM을 보내면 곧잘 확인할 것입니다.
코치 교수님께서는 제 어셈블리프로그래밍 교수님이셨는데, 당시 러시아발 해외입국자는 14일 자가격리가 필요했기 때문에 안타깝게도 본인께서는 참석하지 않길 원하셨습니다. 그리고 이후 받은 lvalue의 연락에서 연구하느라 바빠서 참석하기 어려울 것 같다는 답변을 들었습니다.
이렇게 시작부터 두 가지 문제가 생겼습니다.
코치가 참석할 수 없다면 팀의 참가자격은 유지되는가.
팀원이 참석할 수 없는 경우에도 그러한가.
다행히도 예외적인 경우였기 때문에 팀원을 2019년 혹은 2020년 리저널 참가 이력이 있는 학생으로 대체 가능했으며, 코치가 참석하지 않아도 괜찮다는 답변을 받았습니다.
2021년 레드시프트는 lvalue 대신 전해성(seastar105) 선배와 함께 UCPC에 출전해서 5등상을 받은 바 있습니다. 이 구성으로 다시 출전하고 싶었지만 안타깝게도 seastar105 선배께서는 당해년도 리저널 본선 출전 이력이 없으셨습니다.
그래서 학회 슬랙에서 최대한 빠르게 모집했습니다. 이윤제(yjyj1027) 선배와 이상원(gumgood) 선배께서 빠르게 연락을 주셨습니다. gumgood 선배께서 더 빠르게 연락을 주신 관계로, 이렇게 모스크바행 레드시프트가 결성되었습니다. 메일을 받고 7시간만입니다.
이후 임지환(raararaara) 선배께서 co-coach로 오시길 희망하셔서, 이렇게 4명이서 여행 계획을 세우게 되었습니다.
티켓은 10위(UNIST Underdog 팀)와 11위(경북대학교 Catdriip 팀)까지 내려가서 한국에서만 7개 팀이 출전하는 유례없는 해가 되었습니다. 대회 참가를 위해서는 예방접종을 완료해야 했는데, 아시아태평양 지역 내에서 한국과 일부 나라를 제외하고는 백신 수급 상황이 좋지 않거나, 러시아발 입국자에 대한 자가격리 조치가 강력했거나, 아예 입출국을 허용하지 않았습니다. 한국의 비교적 나은 방역 상황으로 인해 운좋게 티켓을 얻었다고 생각합니다.
두 번째 산: 백신
사람들은 종종 제 장점을 강력한 추진력을 가졌다는 것이라고 말합니다. 반대로 말하면 앞만 보고 가느라 사소한 것들을 놓치는 건 약점이라고 할 수 있을 것 같습니다. 일단 참가할 수 있다고 질러놨지만…
…출국 전에 예방접종을 완료해야 했습니다. 출국 예정일은 9월 말, 지금은 8월 12일이었습니다. 50일가량 남은 상황이었습니다. 그러나 fully vaccinated의 의미는 ‘접종 완료 후 14일 경과’이고, ‘접종 완료’는 2차접종이 필요한 백신의 경우 2차접종까지를 의미하기 때문에 2차접종을 36일 안에 받아야 한다는 뜻이 되었습니다.
네 명 모두 1차조차 미접종이었습니다. 당시 Pfizer 백신은 1차와 2차접종 사이 간격이 6주(=42일)였고, 그조차도 접종받기 너무나 어려웠습니다.
먼저 정부의 도움을 얻는 방법을 알아봤습니다. 질병관리청까지 올라갔다 내려온다고 합니다. 왠지 오래 걸릴 것 같은 느낌이 듭니다. ICPC는 소관부처가 어디일까요? ICPC는 경제활동일까요?
초청장이 있긴 하지만 여권번호가 적혀 있지 않아 아마도 승인해주지 않을 것 같았습니다. 그래도 일단 서류를 작성해 보냈습니다.
하지만 만에 하나 불승인되면 출국할 수 없게 됩니다. 불확실한 도박에 걸 수 없었습니다. 모두가 머리를 싸매면서 각자의 방법으로 갖가지 채널로 문의했습니다.
그러던 중 다행히도 저희 어머니께서 동네 병원에 직접 전화를 걸어 예약을 성공하셨습니다. 같은 방법으로 저뿐만 아니라 팀원 모두 동네 브루트포싱으로 1차접종 예약에 성공합니다. 접종일은 바로 이틀 후인 8월 14일이었습니다.
8월 14일은 UCPC 본선이기도 했습니다. 타이레놀 한 알을 먹고 바로 서강대 앞 스터디 카페로 달려가 UCPC 본선을 치뤘습니다.
1차접종은 가능한 한 최대한 빠르게 했지만 2차접종을 앞당기는 것이 필요했습니다. 당시 Pfizer 백신은 6주 후에 접종이 가능했습니다.
다행히도 접종 간격을 앞당기는 것은 보건소에 문의를 넣으면 비교적으로 쉽게 처리할 수 있었습니다. 양천구보건소에 수십 번 전화를 시도한 끝에 접종 간격을 4주로 단축할 수 있었습니다. 팀원 모두가 9월 11일에 2차접종을 완료했고 9월 말 출국 일정에 차질이 없게 되었습니다.
세 번째 산: 여행 일정과 경비
semteo04와 저는 산업기능요원으로 복무 중입니다. 그게 무슨 뜻이냐면 대학생이지만 직장에 다니고 있다는 뜻이고, 그게 무슨 뜻이냐면 여행을 다녀오려면 휴가를 써야 된다는 뜻입니다. 남은 휴가일 수를 고려해서 여행 일정을 잘 짜야 합니다.
또 하나 문제는 여행 경비였습니다. ICPC에서 지원해 주는 것은 대회 기간 중의 숙식 비용뿐이었습니다. 대회 기간을 벗어난 비용과 비행기값은 우리가 부담해야 했고, 이는 결코 만만한 비용은 아닙니다.
학교의 힘을 빌리기로 합니다. 방콕 리저널에 참가했을 때
‘㉠학교 대표가 아니라서 지원해줄 수 없다, ㉡학교 대표로 중국(2010년 월드 파이널) 갈 때는 지원해줬으니 나중에 ㉢학교 대표가 되어 와라’
는 말을 듣고 살짝 분했던 기억이 있습니다. 이제는 학교가 뭐야 국가대표가 되었으니 당당히 지원해 달라는 연락을 드렸습니다.
하지만 아무리 ㉢학교 대표가 되더라도 시국에 학교가 지원을 해주는 것도 학교 입장에서는 부담스러울 수 있을 거라고 생각했고, 백신 접종 간격을 4주로 단축시키기 위해 + 휴가를 쓰기 위해 당장 항공권이 필요한 상황이었습니다. 그렇게 고민하던 찰나 정말 감사하게도 ㉡학교 대표의 최백준(baekjoon) 선배께서 도와주실 수 있다는 말씀을 해 주셨습니다.
한국 → 프랑스: Pfizer, Moderna, AstraZeneca 백신 2회 접종 후 2주 경과
한국 → 네덜란드: 접종확인서가 있는 경우 자가격리 면제
따라서 한국 → 러시아, 한국 → 폴란드 → 러시아, 한국 → 터키 → 러시아 중 하나를 타는 게 이상적이어 보였습니다. 가는편으로는 출발 시간이 제일 괜찮아 보였고 최단 소요시간이 붙어 있었던 폴란드항공을 타고 가기로 합니다. 백신 접종 연장을 위해 항공권이 당장 필요했고, 제가 당장 보유 현금은 제일 많았기에 일단 결제했습니다.
그리고 오는편은 가격이 싼 터키항공으로 예약했습니다. 항공권 예약을 마치고 백신접종 기간도 단축시키고 휴가도 썼습니다. 미필인 semteo04와 저는 국외여행허가서 신청을 완료합니다. 남은 휴가 8일 모두를 러시아에 쏟아부었습니다. 다만…
네 번째 산: 지원 불가, 그리고…
법인카드 결제분만 지원이 가능하며, 그 중에서도 재학생에게만 지원이 가능하다는 답변이 돌아왔습니다. 이미 결제했기 때문에 지원이 힘들다는 것이었습니다. 백준님께는 죄송하게 된 일이지만 사실 그렇게 큰 충격은 아니었습니다.
그러나 진짜 문제는 따로 있었습니다.
당시 러시아는 경유항공편의 경우 경유지를 제한하고 있었습니다. 그 중에 폴란드가 없었습니다.
ICPC 운영 측에 비자 발급을 도와줄 수 있느냐고 여쭤봤더니 ‘러시아 정부 차원에서 입국승인 행정명령을 내렸기 때문에 안심해도 좋다’는 답변이 돌아왔습니다. 불안하지만 일단은 안심합니다.
그러나 진짜 문제는 따로 있었습니다.
오는편이 연착되었습니다. 연착 자체는 큰 문제가 아니지만, 휴가를 전부 소모해버려 이대로면 산업기능요원 복무가 연장되고 맙니다.
결국 불안했던 가는편을 포함해 모든 항공권을 취소하고, 새로 여정을 짜기로 했습니다. 가는편은 9월 28일 터키 경유 밤비행기로, 오는편은 10월 8일 대한항공 직항으로 결정합니다.
새로 항공권을 결제하면서 2명분의 경우 학과 지원을 받을 수 있었고, 나머지 2명분의 경우 네 명이 똑같이 분담하기로 결정했습니다(~32만 원). 싼 값에 러시아 다녀오는 셈 치고요.
ICPC 대시보드에는 호텔 예약 정보 조회 기능도 있습니다. 신기하죠.
호텔은 대회 기간 중에만 지원되었습니다. 여정 중에 대회 기간이 아닌 기간의 경우 따로 결제했습니다. 다행히도 따로 결제한 날들과 지원받은 날들의 예약을 합쳐 주셔서 방을 옮기지 않고 지낼 수 있었습니다.
이제 공항에서 PCR 테스트만 받고 결과지를 챙겨 가면 모든 준비는 끝납니다. PCR 검사 결과가 나올 때까지는 6시간가량이 걸린다고 합니다. 가는편을 밤비행기로 변경한 덕분에 당일에 검사를 받아도 문제없게 되었습니다.
이스탄불으로
한국을 떠나기 위한 모든 준비를 마쳤습니다. 출국심사를 마치고 경유지인 이스탄불로 이동합니다.
Bit은 좋아 보이지만 나중에 뭔가 하려면 돈을 내야 될 것 같은 분위기를 느껴서 제외했습니다. 그냥 rollup을 직접 쓰는 것과 create-react-library의 도움을 받는 것 중에서 고민하다가 create-react-library를 골랐습니다. 간단해 보여서였습니다.
프로젝트를 만들고 기존에 쓰던 테마 정의와 함께 Button 컴포넌트를 옮겨왔습니다.
어 그런데 뭔가 이상합니다.
분명히 테마도 타입 정의가 잘 되어 있고 styled-components도 잘 임포트되어 있는데 테마 속성들이 전부 any로 뜹니다. 심지어는 styled component prop도 any가 뜹니다. 타입 추론이 없는데 어떻게 개발을 합니까? 이건 천재지변입니다.
styled-components가 peerDependencies에만 있고 devDependencies에는 없었음을 확인하고 고치는 데는 의외로 많은 시간이 걸렸습니다.
dependencies, devDependencies, peerDependencies
TL;DR: 라이브러리를 개발할 때 peerDependencies에 뭔가를 추가하려면 devDependencies에도 똑같은 패키지를 추가해야 합니다.
너무 기니까 dependencies를 줄여서 deps라고 부르도록 합시다.
deps와 devDeps는 패키지를 빌드했을 때 프로덕션 번들에 포함되는지 아닌지의 차이가 있습니다. devDeps에는 주로 @types/*라던가 Prettier, Babel 플러그인과 같이 개발 과정이나 빌드 등을 도와주는 패키지들이 들어갑니다. 이미 완성된 코드에다 ESLint를 돌릴 이유는 없으니까요.
하지만 deps와 devDeps는 사실 일반적인 프론트엔드 프로젝트에서는 별 상관이 없습니다. 이는 webpack의 번들 방식 때문인데, webpack은 entryPoint부터 시작해서 import들을 따라가면서 패키지들을 필요에 따라 넣기 때문입니다. create-react-app이 @types/* 같은 의존 패키지들을 전부 devDeps가 아니라 deps에 때려박아도 별 일 없는 이유이기도 합니다. 개인적으로는 싫지만…
라이브러리를 만들면 아무도 의존하지 않는 패키지 – 예를 들면 프론트엔드 앱 – 를 만들 때는 볼 수 없었던 peerDeps와 마주하게 됩니다. peerDeps에 의존성을 추가하면 내 패키지에서 의존성을 관리하는 대신 내 패키지를 의존하는 패키지에서 의존성을 대신 관리하게 됩니다.
말이 조금 헷갈리는데, 예를 들어 내 프로젝트가 라이브러리 A, B, C를 쓰는데, 세 라이브러리 모두가 D라는 패키지에 의존한다고 합시다.
세 라이브러리에서 D를 deps로 두는 경우에는 node_modules에 A > D, B > D, C > D 모두가 들어가게 됩니다.
D를 peerDeps로 두는 경우에는 node_modules에 A, B, C, D가 따로따로 들어가고, 내 프로젝트 단에서 A, B, C 각각이 내 프로젝트에서 직접 가져온 D에 의존할 수 있도록 해 줍니다.
요약하면, peerDeps는 의존성 트리 최적화를 위해 내 패키지를 쓸 패키지들에게 ‘이거 대신 설치해 주세요’라고 설명하는 것과 같습니다. 이건 ‘내 패키지 자체에서는 이 의존성을 굳이 쓰지 않겠어요’라는 말과 같은 말입니다. 다 좋은데 그러면 내가 내 패키지는 어떻게 개발하죠?
결과적으로는 peerDeps와 deps 모두에 의존성이 들어가야 합니다. 이렇게 하면 빌드된 index.js에서 peerDeps만 require를 사용하도록 바뀌고 나머지는 잘 번들됩니다. 이 require는 로컬 환경에서는 deps에 의해 설치된 패키지를, 피의존 환경에서는 이 패키지의 peerDeps에 의해 설치된 패키지를 활용할 것입니다.
알고 나면 어렵지 않은 이유지만, 라이브러리를 만드는 입장에서 peerDeps를 설명해 둔 리소스가 현저히 적어서 알기까지 너무 오래 걸렸습니다. 이건 험난한 여정의 시작일 뿐이라는 걸 당시의 저는 몰랐습니다.
이건 안 좋은 코드의 예입니다. solved.ac에서는 버튼에 색상을 그렇게 많이 집어넣거나 색상에 애니메이션을 줄 일이 없었기 때문에 기존에는 이렇게 구현했지만, styled-components는 모든 경우의 수마다 CSS 클래스를 하나씩 만들 거고 자칫 다이나믹할 수 있는 값을 이런 식으로 구현하면 퍼포먼스 이슈가 생길 것은 안 봐도 비디오, 웰 노운 팩트입니다.
따라서 CSS 변수를 사용하기로 합니다. 스타일드 컴포넌트 안에서는 색상 등을 var(--solvedac-button-background-color) 등으로 정의하고, 컴포넌트에 인라인 스타일로 --solvedac-button-background-color: #17ce3a와 같은 식으로 넣어주면 됩니다. 이걸 잘 쓰기 위해 타입스크립트의 도움을 받고 싶습니다. 예를 들어 아래와 같은 코드를 작성하면…
const ButtonContainer = styled.button<ButtonContainerProps>`
display: inline-block;
vertical-align: middle;
text-align: center;
background: ${v.backgroundColor}; // Does not trigger class name generation which is good
/* ... */
`
이게 전부 타입 추론이 되게 하기 위해서 열심히 타입스크립트 매드무비를 찍습니다. readonly를 사용하면 string 배열을 tuple 취급하게 할 수 있습니다. 여기서 [...T]는 TS 4.0 기능입니다.
export const cssVariables = <T extends Array<string>>(
names: readonly [...T],
prefix: string
): [
{ [key in T[number]]: `--solvedac-${string}` },
{ [key in T[number]]: `var(--solvedac-${string})` }
] => {
const vars = Object.fromEntries(
names.map((name) => [
name,
`--solvedac-${prefix}-${name
.replace(/[A-Z]/g, (m) => `-${m.toLowerCase()}`)
.replace(/^-/, '')}`,
])
) as { [key in T[number]]: `--solvedac-${string}` }
const v = Object.fromEntries(
Object.entries(vars).map(([k, v]) => [k, `var(${v})`])
) as { [key in T[number]]: `var(--solvedac-${string})` }
return [vars, v]
}
이렇게 하면 에디터가 타입 추론을 잘 해 줍니다. 그런데 갑자기 빌드가 되지 않습니다. 이번엔 왜일까요?
CSSProperties와 다시 만나는 declaration merging
리액트는 기본적으로 인라인 스타일에 --solvedac-button-background-color 같은 걸 허용하지 않습니다. CSSProperties의 키가 아니기 때문입니다. 리액트의 index.d.ts에는 이런 주석이 달려 있습니다.
export interface CSSProperties extends CSS.Properties<string | number> {
/**
* The index signature was removed to enable closed typing for style
* using CSSType. You're able to use type assertion or module augmentation
* to add properties or an index signature of your own.
*
* For examples and more information, visit:
* https://github.com/frenic/csstype#what-should-i-do-when-i-get-type-errors
*/
}
직접 인덱스 시그니쳐를 만들고 싶으면 type assert를 하거나 module augmentation을 하라고 합니다.
리액트 프로젝트에서 타입스크립트 관련해서 뭔가 안 된다 싶으면 이 친구입니다. react-scripts는 자기만의 webpack 설정 등을 쓰기로 유명합니다.
create-react-library는 react-scripts@3.4.1을 설치해 줍니다. TS 4.0을 지원하지 않는 버전입니다. yarn add react-scripts@latest -D로 해결해 줍니다.
이외에도 microbundle-crl은 예전 버전의 Babel을 사용하고 있으며, 2년 전 microbundle 소스의 포크입니다. Unfork 해 줍니다.
Zero configuration을 표방하는 패키지를 종종 보게 되는데, 일반적인 경우에는 좋지만 일반적이지 않은 경우에는 꽤 골치아파지게 됩니다. 여담으로 react-scripts를 쓰면서 webpack 구성을 바꿔야 하는 경우가 있다면, eject하는 대신 react-app-rewired를 사용해 보시기 바랍니다.
dist/index.js를 확인해 봤을 때 컴포넌트 ID는 빌드 시점에 생성되는 것을 알 수 있습니다. Babel 플러그인이 잘 동작했다는 뜻입니다.
그러면 의심이 가는 부분은 solved.ac 프론트엔드 프로젝트에서 ServerStyleSheet를 collectStyles 해 주는 부분입니다. 이 방향으로 검색해 봤더니 FAQ가 하나 나옵니다. yarn link에 대한 내용이지만 이 라이브러리에도 적용할 수 있을 것 같습니다.
styled-components는 싱글톤이고, 각자의 스코프에서 렌더할 컴포넌트들을 전부 관리합니다. 따라서 solved.ac 프론트엔드 프로젝트와 방금 만든 UI 라이브러리에 있는 styled-components는 다른 styled-components라는 뜻입니다. 이걸 강제로 같게 만들어서 한 쪽의 styled-components가 프론트엔드 프로젝트와 UI 라이브러리 모두의 컴포넌트를 관리하게 해 줘야 합니다.
모든 require('styled-components')가 특정 경로의 모듈로 resolve 되도록 모듈 alias를 해 주면 되는데 Next.js + Typescript 환경에서는 비교적 간단하게 해결할 수 있었습니다.
Update: @solved-ac/ui-react는 이제 emotion을 사용하고 있습니다. emotion은 일부 셀렉터를 제외하고는 SSR 환경에서 별도의 설정 없이 사용할 수 있습니다. (2022/06/20)
사수 무제한 제공 거짓말 사건
컴포넌트를 라이브러리화하고 정상적으로 렌더하기 위한 과정들이었습니다. 모르면 맞아야 하는 도메인 지식들이 너무 많은데, 컴포넌트 라이브러리를 만드는 사람이 많지 않은지 리소스도 상당히 적었고 그로 인해 너무 고생을 많이 했습니다. 나는 있는 코드를 그대로 올리면 누군가 코드 리뷰를 해 주지 않을까 싶었던 것뿐인데!
그래도 이제 잘 동작하니까 계속 여러 컴포넌트들을 정리해서 올려봐야겠어요. 가뜩이나 리소스 없는 분야인 것 같은데 이 글이라도 여러분의 쓸데없는 삽질 예방에 도움이 되었으면 좋겠습니다.
“들어갈 자리가 있으면 매우 좋은 아이디어라고 생각합니다. 베이컨 떡 말이 해먹으면 진짜 맛있을 것 같아요. 부대찌개 만들 때도 미친듯이 넣고. 베이컨은 냉동실에 오래 넣어도 괜찮아서, 해동도 간단한 편이고 베이컨 좋아하면 그렇게 해도 될 듯 합니다.” – 익명의 반죽가 (아무튼 크리에이터)
“‘잘 보관한다면’ 구운 고기를 매일 아침 먹을 수 있을 것 같네요.” – 묘지기 (지하세계 스트리머)
“먹는 입장에선 비효율적이라고 보는 게 유통기한의 문제가 있을 수 있지 않을까요? 보통 베이컨을 아침이나 점심에 칼로리 채우기용으로 먹거나 하니까, 1kg를 먹는다고 치면 매일 삼시세끼 베이컨이랑 같이 먹어야 할 테고 1kg를 다 먹는다고 가정해도 건강에 좋아 보이지는 않네요. 비쌀 텐데…. 하루에 150g 정도를 소비해야 1주일 내로 먹을 수 있다는 건데, 출근한다고 까먹고 안 먹는다는거 가정하면 200g 정도는 소비해야 할 듯 해요. 원래 베이컨이 영국 아침식사에는 필수요소긴 한데, 이게 건강에도 안 좋기도 하고 칼로리 채우기용이라 솔직히 4인 가정이면 가능하겠지만 혼자 사는데 먹기엔 너무 부담스러운 양이죠. 특히나 혼자 사는 직장인이 매일 아침에 밥을 챙겨먹을 리도 없을 것 같고요. 뭔가 밖에 여기저기 다니면서 활동하는 거 아니면 베이컨은 비추입니다. 기름기도 많고….” – 익명의 아즈사와 코하네 팬 (연구원)
“로켓프레시로 사면 쌉니다. 바이럴은 아닙니다.” – 프로그래머 아님 (그래픽 디자이너)
“베이컨을 1kg나 사둘 필요가 있을까 싶지만, 100g 사서 나중에 부족한 것보단 1kg를 사서 쟁여놓는 게 낫지 않나 싶습니다. 데이터센터 인수 썰처럼 더 저렴한 것도 있고요.” – 익명의 바다를 헤엄치는 민물고기 (육군? 정보보호병)
“자취생 필수품이군요. 냉동고에 충분한 공간이 있다면 쟁여 놓을 가치가 충분한 물건이네요.” – 익명의 지나가던 트위터 요정 (전자오락 기술자)
“냉동 베이컨은 안 사봐서 모르겠네요. 하지만 있다면 좋을 것 같네요.” – cubelover (넥슨 ML 엔지니어)
“베이컨 맛있지요 😋 근데 여기선 보통 냉장 상태로 판매가 돼서 냉동 베이컨은 경험해 보진 못했네요. 미국인 아침 식사에 필수요소예요.” – 익명의 일본식 라면 애호가 (NVIDIAMLOps 엔지니어)
“1kg…. 일단 있으면 먹겠지만…. 생각보다 양이 많아서 냉동시킬 때 요령이 필요할 거 같은 느낌이네요. 종이 호일을 두고 한 장 한 장이나 한 말이 정도씩 나누면 서로 안 붙어서 먹을 때나 보관할 때 편해요.” – 익명의 체대생 (학부생)
“아무래도 많다…라는 생각밖에 할 수가 없는 양의 고기입니다. 양의 고기가 아니고 돼지의 고기이기는 하지만, 그런 건 아무래도 좋습니다.” – 키파 (알리오 에 올리오 엔지니어)
“적당히 먹고 싶은 만큼 먹고 남은 걸 베이컨 잼 같은걸 만들면 될 것 같아요. 자기가 만들기 싫으면 다른 사람 시키세요.” – 익명의 퇴사한 직장 상사 (새내기과정학부 3학년)
“저는 그거 갖고 싶어요. 구워서 밥에도 먹고 파스타도 해 먹고 에그 인 헬도 해 먹고 볶음밥도 해 먹고….” – 익명의 프랑스는 베이컨 (컴퓨터공학과 3학년)
“냉동 베이컨은 몇 달 갈 걸요? 근데 여기저기 넣어먹기 좋아서 예전에 샀는데 금방 다 먹었습니다.” – 개어렵네요 (대충 써주세요)
solved.ac를 운영하면서 다양한 채널에서 사이트에 대한 의견들을 모으는 편입니다. 특히 그 중에서도 트위터 맞팔 분들께서는 저에게 창의적인 기능 아이디어들을 추천해 주고 계신데요, 몇 개만 봅시다.
그래서 직접 만들어 봤습니다.
한별포스
2022년 4월 1일 정오부터 만우절 대회인 진짜 최종 구데기컵 2 2가 끝날 때까지 프로필 닉네임 위에 별을 25개 띄워봤습니다. 이게 대략 무슨 뜻인지 아시는 메이플 유저 분들께서는 대체 이게 왜 여깄지 하면서 당황하셨을 것 같습니다. 모르시더라도 마우스를 올리면 밑줄이 떠서 되게 클릭하고 싶게 만들었기 때문에 한번쯤은 클릭해보셨을 것 같아요. 이걸 클릭하면 한별포스 이벤트 페이지로 갑니다.
‘스타포스’라는 이름을 그대로 쓸 수는 없고…, solved.ac 길라잡이에 등장할 캐릭터 ‘한별이’의 이름을 빌려왔습니다. 귀엽지 않나요? 카카오 이모티콘으로 쓸 수 있어요.
여하튼 한별포스는 메이플스토리의 스타포스를 거의 그대로 가져온 이벤트였습니다. 프로필을 강화할 수 있습니다. 강화하면 프로필 위에 뜨는 별의 갯수가 변하는 것 이외엔 아무 일도 일어나지 않습니다.
스타포스?
스타포스 강화가 어떻게 돌아가는지를 요약해보면 이렇습니다.
강화에 성공하면 별이 하나 늘어납니다.
실패에는 세 가지 경우가 있습니다.
별 개수가 유지됩니다. 10성까지에서 강화 시도에 실패한 경우 무조건 유지되며, 15성과 20성에서 실패한 경우에도 파괴되지 않았다면 무조건 유지됩니다.
별이 하나 줄어듭니다. 10성까지 그리고 15성과 20성에서 강화 시도에 실패하는 경우에는 일어나지 않습니다.
장비가 파괴됩니다. 12성 이상에서 강화를 시도하는 경우 드문 확률로 일어납니다. 이후 같은 장비를 준비해 장비를 복구할 수 있으며, 12성부터 다시 시작합니다.
스타캐치를 제외한 모든 요소를 그대로 가져와봤습니다. 스타캐치를 가져오지 않은 이유는 스타캐치에 성공했는지 아닌지를 서버에서 검증하기가 어렵기 때문인데, 대신 한별이가 그려진 배경을 프로필 배경으로 설정하면 같은 효과의 ‘한별캐치’를 적용해 줍니다.
이벤트 가격과 보상 설정
30일동안 매일 1문제씩을 푼다면 적당히 하루 75조각, 한 달 2,250조각을 얻는다고 봅니다(10일동안 매일 5문제 + 5기여를 해도 이 정도를 벌 수 있습니다). 그래서 일단 이런 유저가 22성까지 달성할 수 있는 것을 목표로 비용을 설정합니다.
이렇게 하려면 1번 강화 당 비용을 현저히 낮게 잡아야 합니다. 프로필 파괴 시 복구 비용도 없앴습니다. 기댓값을 보면서 강화 비용을 미세하게 조정했고, 정확한 비용은 아래와 같습니다.
10성 이하를 목표로 강화: 별조각 1개
15성 이하를 목표로 강화: 별조각 2개
20성 이하를 목표로 강화: 별조각 3개
25성 이하를 목표로 강화: 별조각 4개
이 때의 기댓값은 이렇습니다. 이 블로그에서 기댓값 계산 매드무비를 찍고 싶었지만 이미 다른 분께서 작성해 주신 다른 매드무비가 있어서 생략합니다. 요약하면 이렇습니다. (한별캐치 없음 / 한별캐치 있음)
0성 → 10성: 18조각 / 17조각
0성 → 15성: 138조각 / 117조각
0성 → 17성: 215조각 / 181조각
0성 → 20성: 1,143조각 / 851조각
0성 → 21성: 1,417조각 / 1,043조각
0성 → 22성: 2,330조각 / 1,654조각
0성 → 23성: 36,569조각 / 23,955조각
주의해야 할 점은 스타포스 기댓값은 편차가 굉장히 크다는 점이고, 여기는 알고리즘 문제해결을 공부하는 곳이고, 참가자들이 이벤트 시작 후 1시간 안으로 기댓값 테이블을 전부 계산해버릴 것이라는 점입니다. 메이플스토리 같은 경우에는 상위 95% 유저는 상위 50% 유저보다 2.5배 많은 재화를 소모해야 한다는 시뮬레이션이 있을 정도입니다. 만우절 이벤트인데 너무 스트레스를 받지는 않았으면 해서, 많은 유저들이 얻도록 하려는 22성 보상까지에 대해서는 기댓값의 2배에서 3배쯤이 되도록 설정했습니다.
1등 보상을 따로 둔 것은 나름의 실험 같은 거였는데, 기댓값에 따르면 21성까지는 성공 확률이 최소 30%여서 할 만 하고, 잔고가 3조각이어도 강화 버튼을 누르는 게 이득입니다. 하지만 22성에서 성공 확률 3%의 강화 버튼을 누르는 건 일반적으로 손해입니다. 1등이 22성으로 모두가 행복하게 별조각을 5,000개씩 더 받고 끝날지, 아니면 남들이 별조각 5,000개를 더 받는 걸 막기 위해 22성에서 버튼을 누를지 궁금했습니다.
결과적으로 solvedac 계정을 제외하고 23성을 달성한 유저는 22명이었네요. 23성에서 강화 버튼을 눌러서 터진 분들도 계십니다. 무섭습니다…. 개인적으로는 23성이 나온다면 24성이 한 명 이하로 나온다고 예상했는데 24성은 나오지 않았네요.
얼마나 썼을까
통계를 따로 계산하지 않아서 로그를 CSV 덤프로 까봤습니다. 3,519명의 유저가 총 1,636,385번 강화를 시도했고, 4,762,579개의 별조각을 소모했습니다.
각 단계별 강화 시도 횟수는 이렇습니다.
0성에서는 3,677번의 강화 시도가 있었습니다. $\frac{3\,519}{3\,677}\approx 0.957$이므로, 한별캐치를 고려하면 대략 맞습니다.
9성 이하에서는 모든 단계에서 7,000번 이하의 강화 시도가 있었고, 10성에서는 149,682번의 강화 시도가 있었습니다. 9성 이하로는 돌아올 수 없기 때문에 강화 시도가 적습니다.
15성에서의 강화 시도가 가장 많습니다(340,776번). 15성과 20성 완충 구간의 경우 그래프가 폭 튀어나와 있습니다.
20성에서의 강화 시도는 24,071번, 21성에서는 9,927번입니다.
22성에서의 강화 시도는 2,040번이며 이 중 23성으로의 강화를 성공한 경우는 70번이었습니다.
23성에서의 강화 시도는 37번이며 이 중 24성으로의 강화를 성공한 경우는 없었습니다.
이 이벤트에서 별조각을 가장 많이 쓰신 분은 별조각을 28,396개 소모하셨으며, 7,882번의 강화 시도를 했습니다. 이 분께서는 22성에서 강화 버튼을 16번 누르셨지만 23성에 도달하지 못하시고 17성으로 마감하셨습니다.
최종 22성 유저 중 가장 적은 별조각을 소모한 경우 겨우 64개를, 가장 많은 별조각을 소모한 경우 무려 21,364개를 소모하셨습니다. 물론 가장 많은 별조각을 소모한 경우는 22성에서 프로필이 파괴된 후 다시 돌아온 경우이긴 합니다. 17성의 경우는 최소 44개, 최대 28,396개였습니다.
마지막으로 22성에 주차한 저는 2,264개의 별조각을 소모했습니다. 기댓값을 약간 상회합니다.
이모저모
솔브드가 메이플 인벤에 소개되는 신기한 경험을 했습니다. 댓글에 22성 인증이 꽤 올라오던데 알고리즘 문제 푸시는 분들과 메이플스토리 유저 간의 교집합이 어느 정도 되는 것 같습니다. 저도 그렇구요.
저희 학회에서도 문제는 안 풀고 한별포스하는 데 심취해 계셨다고 하고 들리는 소문으로는 SSAFY에서도 한별포스 강화전을 했다고 하네요.
작년엔 대규모 리팩터링을 하느라 만우절 이벤트를 못 했는데 올해는 뭔가 보여드릴 수 있었습니다. 재밌게 즐겨 주셨나요? 스타포스 추가해 달라는 걸 진짜 들어줄 줄은 몰랐나요? 솔브드는 알고리즘 문제해결을 재밌게 배울 수 있게 하자는 사명 아래 어떻게 하면 사이트를 좀 더 재밌게 만들 수 있을까 고민하다 보니 게임을 기획하듯이 기획하고 있습니다. 재밌게 즐겨주셨다면 다행입니다!
그치만 이번엔 너무 게임밖에 없었을지도 모르겠네요. 문제를 푸는 것과 연계해서 별조각을 더 다양한 방법으로 주고, 별조각을 사용할 만한 곳들이 많아졌으면 좋겠다는 생각을 하게 만들었던 이벤트였습니다. 앞으로 이런 방향으로 컨텐츠 업데이트를 해보고 싶어요.
코로나가 올해 12월에는 끝나있을 줄 알았죠. 일일 확진자 수가 최고치를 갱신 중이라는 작년 회고가 무색하게, 연말 확진자 수는 만 명에 가까워지고 있어요. 하지만 위드 코로나 체험판과 이런 시국에 다녀온 월드 파이널 덕분에 작년보다는 여기저기 많이 돌아다녔답니다.
덧없는 인생 목표
운좋게도 ICPC World Finals에 초청받게 되었습니다. 대회에 참여하려면 팀원 세 명이 모두 접종완료여야 하는데 한국의 백신 수급 상황이 좋았던 영향이었습니다. 모스크바 시내도 구경하고, 문제도 구경만 하다 왔어요.
2019년에는 월드 파이널을 그렇게 나가고 싶어했던 것 같은데, 월드 파이널 진출이 나름의 인생 목표였습니다. 그런만큼 엄청 멀게 느껴졌던 곳이기도 했구요. 그런데 이렇게 허무하게 달성해 버렸네요. 마음 한 켠에 애매함이 남습니다. 사실 제가 원했던 건 월드 파이널 진출 자체가 아니라 한국 리저널에서 월드 파이널에 진출할 만한 실력을 갖는 것이었는지도 모르겠습니다.
좋은 경험이었지만 87위라는 성적은 개인적으로는 정말 정말 많이 아쉬웠고, 비록 2019년 서울 리저널 상위 팀이었기에 기회를 잡았던 것도 맞는 말이지만 코로나 시국이 아니었다면 진출하지 못했을 것이기에 목표를 제대로 이루지 못한 것 같다는 생각이 계속 듭니다. 그래서 이미 이룬 목표지만 복학 후에 한 번 더 도전해 보려고 합니다. 아쉬움을 풀고 싶어요.
월드 파이널 참가 및 모스크바 여행 후기를 작성하고 있습니다. 기대해 주세요!
소프트웨어 개발
solved.ac
올해도 작년에 이어 solved.ac 개발에 많은 노력을 쏟았습니다. 올해에도 큼직한 기능들을 정리해 봅시다.
출처 기반 문제 검색. (1월) 문제 출처를 기반으로 검색할 수 있습니다. from:sogang, from:ioi2021 같은 게 되죠.
solved.ac 디스코드 및 디스코드 연동. (6월) solved.ac 계정과 Discord 계정을 연결해 solved.ac에서 티어가 변경되면 Discord에서 역할이 바로 변경되게끔 했습니다. 본인의 solved.ac 닉네임을 채팅 닉네임으로 사용해야 하기 때문에 서버 채팅 관리 부담도 적죠.
스트릭. (7월) 연속으로 문제를 해결한 날짜 수를 계산해 줍니다. 스트릭이 생긴 이후로 문제를 풀고 싶은 마음이 더 생기지 않았나요?
별조각. (10월) 문제를 풀고 기여를 하면 뭔가 재화를 드려요.
문제 해결 이벤트. (11월) 우여곡절은 많았지만 빼빼로 데이 이벤트를 진행했습니다. 진짜 빼빼로를 보내드렸어요.
코인과 코인샵. (11월) 프로필 배경과 스트릭 프리즈를 구매할 수 있어요.
정말 많네요!
3월에 AC 레이팅 업데이트를 하고 나서는 기존에 PHP로 짜여 있던 백엔드를 전부 Express.js로 포팅했는데요, 기존의 백엔드 서버가 EC2에 올라가 있고 제가 FTP로 수정했으며 버전 관리 같은 거 하나도 안 했다면 믿으시겠나요? 지금은 상상할 수도 없는 일이네요.
solved.ac의 API 셋은 기존에도 방대했어서 Express로 포팅하는 데에는 장장 3달이 걸렸습니다. 하지만 포팅이 완료된 6월 이후의 업데이트 내역들을 보면 DP를 참 잘 돌린 거 같아요. 시간이 된다면 포팅 후기도 작성해 보고 싶습니다. 사실 이렇게 말하면 나중에 결국 안 쓰게 되긴 합니다. 시간을 내서 써야 하는 건데 어렵더라구요.
백엔드를 포팅하고 나서 지금까지, 즉 3월부터 12월까지 새로 알게 된 큼지막한 기술과 방법론들을 정리해 보면
Github Actions: CI/CD
AWS ECR을 통해 ECS에 무중단 배포
Github Actions를 사용해 자동 배포까지
Sequelize: ORM
yarn 워크스페이스와 lerna를 이용해 모노레포 구축
클라이언트와 서버 간 쉬운 코드 공유를 통해 효율적인 작업환경 구축
Express로 레이트 리미팅 미들웨어 제작
SQL optimizer hints를 이용한 쿼리 최적화 — 문제 고급 검색 속도를 엄청나게 향상했어요
정도가 있겠습니다. 저는 되게 야매로 개발한다고 주장하고 실제로도 그러고 있는데, 이제야 조금 제대로 뭔가를 만들고 있다는 느낌이네요. 그래도 아직 많이 부족하다고 느끼고, 더 성장하고 싶습니다. 이제는 TDD를 해보고 싶은데….
내년에는 새로운 기능 개발보다는 길라잡이를 작성할 수 있는 기반을 마련하는 데 열중하고 싶습니다. 길라잡이가 너무 너무 너무 너무 미뤄졌죠 죄송해요 내년에도잘부탁드려요
뭔가 (상대적으로) 챌린징한 프론트엔드 태스크와 챌린징한 백엔드 태스크를 매년 번갈아 하는 거 같은 느낌이네요. 내년에는 길라잡이 기반을 완성할 수 있을까요?
한국정보올림피아드 대회 프론트엔드
올해는 온라인으로 개최된 한국정보올림피아드의 대회 시스템 프론트엔드를 직접 설계 및 개발했습니다. 디자인도 다 했습니다.
수많은 챌린징한 프론트엔드 태스크를 다뤘습니다. 예를 들어…
웹소켓을 통한 실시간 채점 정보 취득
언어 서버가 없어서 완벽하지는 않지만, 약간의 편의를 제공하는 자동완성
크기 조절이 가능한 문제 스테이트먼트 / 코드 에디터 2분할 화면, 너무 길어지면 잘리며 버튼을 누르면 열고 닫을 수 있는 코드 블록, LaTeX 렌더가 가능한 스낵바, 비버챌린지(유저가 상호작용할 수 있는, 캔버스에 랜더하는 자바스크립트 코드를 동적으로 엠베드하기) …
부정행위 예방을 위한 화면 녹화 및 기타 여러 솔루션
등이 있습니다. 더 자세하게 말하지는 못하지만 정말 힘들었던 프로젝트였습니다. 제가 대학생이 되어서 알고리즘 문제해결을 시작해서 그런지 정보올림피아드에 나가보지 못한 걸 아쉬워했는데요, 이렇게라도 참가하게 되어 뿌듯했던 프로젝트였습니다. NYPC도 마찬가지구요!
준비되지 않은 나 앞에 성큼 다가와 버린
왠진 모르겠는데 회사를 다니다 보니까 직함이 생겼어요…. 와아….
부족한 실력으로 면접관도 되어 보고 회사의 여러 일들에 관여하게 되다가 12월에 파트장으로 발령받았어요. 작은 파트긴 하지만 처음으로 해 보는 매니징이라 잘 해낼 수 있을지 겁나네요.
저 잘 하고 있는 걸까요? 그렇지 않더라도 저를 믿어 주고 계시는 분들께 실망이 되지 않도록 잘해내봐야겠어요
새삼 이 때가 얼마나 좋았는지 실감이 나요. 사실 아직은 저거 ‘팀장님’으로 바꾸면 유효하긴 한데
대회 프로그래밍
NYPC
NYPC 시스템 개발에 이어 올해는 출제를 했습니다.
저는 예선 1번 계단과 예선 7번 루트가 많은 트리를 냈습니다. 계단 문제는 제가 계단을 하루에 100층씩 오르면서 살을 뺐던 걸 문제로 만든 거고, 루트가 많은 트리는 회사에서 의자에 앉아서 빙글빙글 돌다가 어 이거 괜찮네 하고 낸 문제입니다. 최고의 대회에 제 문제들을 선보일 수 있어서 너무 영광이었습니다!
같이 파스타도 먹으러 가고 돈까스도 먹으러 가고 곰탕도 먹으러 가고 김치찌개도 먹으러 가고 치맥도 하러 가고 카페도 가고 칵테일바도 가고 모든 순간을 함께하고 있습니다. 최고로 행복한 나날들을 보내고 있어요.
그리고 최고의 생일축하를 받았습니다. 절대 잊지 못할 거 같아요.
원래 부모님과 같이 살았는데, 회사가 너무 멀어서 낙성대에서 자취를 시작했습니다. 출퇴근 시간이 왕복 1.5시간 정도 줄었고, 샤로수길에서 배달이 됩니다.
다만 이게 문제가…. 12월부터 6월까지 매일 계단을 100층씩 오르면서 살을 15kg나 뺐는데, 자취 시작하고 나서 배달 음식 자주 먹고 애인과 여기저기 같이 다니다 보니 딱 뺀 만큼 다시 쪄버렸습니다. 다시 빼버리겠다는 결심으로 매일 집 뒷편 산을 오르고 있습니다.
자취하면서 마파두부랑 카르보나라를 자주 해먹었습니다. 요리 실력이 늘었어요. 카르보나라는 크림 카르보나라는 아니고 노른자랑 치즈로만 맛을 내는 카르보나라인데, 많이 연습했더니 이제 노른자를 익히지 않고도 따뜻한 카르보나라를 만들 수 있게 됐습니다. 자취방이 인덕션이 1구라 여전히 조금 어렵긴 해요.
노트북이 고장나서 새로 샀습니다. 메인 작업 컴퓨터로 이미 맥을 쓰고 있긴 하지만, 맥북은 하이퍼커넥트에서 인턴할 때 잠깐 써 본 걸 제외하면 인생 처음으로 써 보네요. 일정 성능 이상이라면 배터리가 오래가는 게 제일 중요하다고 생각해서 14인치 프로 모델로 샀습니다. 잘 산 거 같아요.
번호 $i$인 사람은 수 $D_i$를 갖고 있는데, $i + D_i \leq N$라면 $i$번 사람과 $i + D_i$번 사람은 친구입니다. 또, 친구의 친구는 친구입니다.
이 때, ‘극대 그룹’의 수를 찾아야 합니다.
친구 관계를 그래프로 생각해 봅시다. ‘친구의 친구가 친구‘라는 말을 잘 생각해 보면, 어떤 연결 요소 안의 모든 사람들은 서로 친구가 됩니다.
따라서 DFS/BFS 여러 번을 통해 연결 요소의 수를 세 주면 문제의 답이 됩니다. 또는 DSUdisjoint set union를 사용해도 됩니다. DFS/BFS를 사용하면 $\mathcal{O}\left(N\right)$만에 해결할 수 있습니다.
저는 DSU를 사용해서 풀었습니다.
#include <bits/stdc++.h>
using namespace std;
using ll = long long;
using ld = long double;
using pii = pair<int, int>;
/* [t] [c] [s] */
int dsu[100001];
int find(int u) {
return dsu[u] == u ? u : (dsu[u] = find(dsu[u]));
}
void merge(int u, int v) {
u = find(u), v = find(v);
if (u != v) dsu[v] = u;
}
void solve() {
int n;
cin >> n;
iota(dsu + 1, dsu + 1 + n, 1);
for (int i = 1; i <= n; i++) {
int x;
cin >> x;
if (i + x > n) continue;
merge(i, i + x);
}
set<int> s;
for (int i = 1; i <= n; i++) s.emplace(find(i));
cout << s.size() << endl;
}
int main() {
cin.tie(nullptr), cout.tie(nullptr), ios::sync_with_stdio(false);
#ifdef _SHIFTPSH
freopen("_run/in.txt", "r", stdin), freopen("_run/out.txt", "w", stdout);
#endif
int t;
cin >> t;
for (int _ = 1; _ <= t; _++) {
cout << "Case #" << _ << endl;
solve();
}
return 0;
}
DSU를 만들 때 std::iota라는 좋은 함수를 사용하면 쉽고 빠르게 초기화할 수 있습니다. STL에 이런 함수가 있다는 게 좀 의외일까요?
1차 2번 – 이진수
길이가 $n \leq 50\,000$인 비트 문자열 $a$가 있고, 같은 길이의 비트 문자열 $b$를 다음과 같이 정의합니다. $\vee$는 OR 연산입니다.
\[b_i = \left(a_{i-t} \vee a_{i+t}\right)\]
$b$가 주어지면, 사전순으로 제일 앞서는 $a$를 구해야 합니다.
약간 헤멜 수 있는 문제였던 것 같습니다. 일단 두 가지 사실을 기반으로 생각해봅시다.
$b_i$가 켜져 있다면, $a_{i-t}$ 또는 $a_{i+t}$가 켜져 있어야 합니다.
$a_i$가 켜져 있다면, $b_{i-t}$와 $b_{i+t}$가 모두 켜져 있어야 합니다.
이제 $b_i$를 왼쪽부터 보면서, 켜져 있으면서 아직 $a_{i-t}$와 $a_{i+t}$ 모두가 꺼져 있는 $b_i$들에 대해, 그리디하게 $a$의 비트들을 켜 줍니다.
오른쪽($a_{i+t}$) 비트를 켤 수 있으면 켜 줍니다. 오른쪽 비트를 켤 수 있으려면, $b_{i+2t}$가 존재하지 않거나 켜져 있어야 합니다. 이는 사전 순으로 가장 먼저 오는 $a$를 구성하기 위함입니다.
오른쪽 비트를 켤 수 없다면 왼쪽($a_{i-t}$) 비트를 켜 줍니다.
생각해 보면 모든 $b_i$에 대해 둘 중 하나 이상을 켤 수 있는 경우만 입력으로 주어진다는 사실을 알 수 있습니다. 이를 그대로 구현해 주면 됩니다. $\mathcal{O}\left(n\right)$만에 해결할 수 있습니다.
#include <bits/stdc++.h>
using namespace std;
using ll = long long;
using ld = long double;
using pii = pair<int, int>;
/* [t] [c] [s] */
void solve() {
int n, t;
cin >> n >> t;
string b;
cin >> b;
vector<int> a(n);
for (int i = 0; i < n; i++) {
if (b[i] == '0') continue;
int l = i - t, r = i + t;
if ((l >= 0 && a[l]) || (r < n && a[r])) continue;
int ll = l - t, rr = r + t;
if (r < n) {
if (rr >= n || b[rr] == '1') {
a[r] = 1;
continue;
}
}
if (l >= 0) {
if (ll < 0 || b[ll] == '1') {
a[l] = 1;
continue;
}
}
}
for (int i = 0; i < n; i++) cout << a[i];
cout << endl;
}
int main() {
cin.tie(nullptr), cout.tie(nullptr), ios::sync_with_stdio(false);
#ifdef _SHIFTPSH
freopen("_run/in.txt", "r", stdin), freopen("_run/out.txt", "w", stdout);
#endif
int t;
cin >> t;
for (int _ = 1; _ <= t; _++) {
cout << "Case #" << _ << endl;
solve();
}
return 0;
}
1차 3번 – No Cycle
정점 $N \leq 500$개, 간선 $M+K$개의 그래프가 있습니다. $M+K$의 간선 중 $M \leq 2\,000$개는 방향이 있고, $K \leq 2\,000$개는 방향이 정해지지 않았습니다.
이 때 $K$개의 간선들의 방향을 잘 정해서, 사이클이 없는 그래프를 구성하고 싶습니다. 방향이 정해진 $M$개의 간선들만 있는 경우에는 사이클이 없는 상태입니다.
답은 $K$글자의 비트 문자열입니다. 방향이 없는 $i$번째 간선의 입력이 $\textcolor{#ff3b57}{u}$ $\textcolor{#ffb717}{v}$로 주어졌을 때, $\textcolor{#ff3b57}{u} \rightarrow\textcolor{#ffb717}{v}$로 방향을 정했다면 $0$, $\textcolor{#ffb717}{v} \rightarrow \textcolor{#ff3b57}{u}$로 방향을 정했다면 $1$입니다. 이 때 사전 순으로 가장 앞서는 비트 문자열을 출력해야 합니다.
사이클이 없는 방향 그래프에서, 임의의 정점 $\textcolor{#ff3b57}{u}$와 $\textcolor{#ffb717}{v}$를 고르고 그 정점을 잇는 간선을 추가한다고 생각해 봅시다. $\textcolor{#ff3b57}{u} \rightarrow\textcolor{#ffb717}{v}$로 정할 수도 있고 $\textcolor{#ffb717}{v} \rightarrow \textcolor{#ff3b57}{u}$로 정할 수도 있습니다. 두 경우 모두가 사이클을 만드는 경우가 있을까요?
$\textcolor{#ff3b57}{u} \rightarrow\textcolor{#ffb717}{v}$라는 간선을 추가했을 때 사이클이 생긴다는 것은, $\textcolor{#ffb717}{v} \rightarrow \textcolor{#ff3b57}{u}$로 가는 경로가 이미 존재한다는 사실과 동치입니다.
따라서 $\textcolor{#ff3b57}{u} \rightarrow\textcolor{#ffb717}{v}$도 사이클을 만들고 $\textcolor{#ffb717}{v} \rightarrow \textcolor{#ff3b57}{u}$도 사이클을 만든다면, 각각 $\textcolor{#ffb717}{v} \rightarrow \textcolor{#ff3b57}{u}$라는 경로와 $\textcolor{#ff3b57}{u} \rightarrow\textcolor{#ffb717}{v}$라는 경로 모두가 이미 존재해야 됩니다.
하지만 그런 두 개의 경로가 이미 존재한다면, 그 두 개의 경로만으로 사이클을 만들 수 있습니다. 이는 우리가 처음에 한 가정 — 사이클이 없는 방향 그래프 — 에 모순됩니다. 따라서 $\textcolor{#ff3b57}{u} \rightarrow\textcolor{#ffb717}{v}$와 $\textcolor{#ffb717}{v} \rightarrow \textcolor{#ff3b57}{u}$ 중 적어도 하나는 새로운 사이클을 만들지 않는다는 사실을 알 수 있습니다.
그러므로 이미 사이클이 없는 방향 그래프라면, 간선들을 무한정 추가해줄 수 있습니다. 그래프의 정점과 간선의 수가 작기 때문에, 간선을 추가해줄 때마다 사이클이 생기는지 생기지 않는지 확인하면서 간선을 하나씩 추가해나갈 수 있습니다.
사전 순으로 가장 앞서는 비트 문자열을 구성해야 하므로, 우선 $\textcolor{#ff3b57}{u} \rightarrow\textcolor{#ffb717}{v}$를 추가한 뒤 사이클이 안 생긴다면 그대로 가져갑니다. 사이클이 생긴다면 위의 증명을 통해 $\textcolor{#ffb717}{v} \rightarrow \textcolor{#ff3b57}{u}$를 추가해줄 수 있음이 보장된다는 것을 알 수 있으므로, 그렇게 해 줍니다.
사이클의 존재 여부를 판단하는 방법은 여러 가지가 있습니다. 저는 DFS로 구현했습니다. 그래프가 연결 그래프임은 보장되지 않으므로, 방문하지 않은 모든 정점에서 DFS를 시작해야 함에 유의합니다.
간선을 $K$개 추가해 주고, 추가할 때마다 DFS를 한 번 해야 하므로 $\mathcal{O}\left(K\left(N+K+M\right)\right)$의 시간이 걸립니다.
#include <bits/stdc++.h>
using namespace std;
using ll = long long;
using ld = long double;
using pii = pair<int, int>;
/* [t] [c] [s] */
bitset<501> root;
int vis[501], ans[2000];
bool dfs(int u, const vector<vector<int>> &graph) {
// check for cycles
if (vis[u]) return vis[u] == -1;
vis[u] = -1;
for (int v : graph[u]) {
if (dfs(v, graph)) return true;
}
vis[u] = 1;
return false;
}
void solve() {
int n, m, k;
cin >> n >> m >> k;
root.reset(), root.flip();
vector<vector<int>> graph(n + 1);
for (int i = 0; i < m; i++) {
int u, v;
cin >> u >> v;
graph[u].emplace_back(v);
}
for (int i = 0; i < k; i++) {
int u, v;
cin >> u >> v;
// 0?
graph[u].emplace_back(v);
memset(vis, 0, sizeof vis);
bool flag = true;
for (int x = 1; x <= n; x++) {
if (vis[x]) continue;
if (dfs(x, graph)) {
flag = false;
break;
}
}
ans[i] = !flag;
if (flag) continue;
// 1?
graph[u].pop_back();
graph[v].emplace_back(u);
}
for (int i = 0; i < k; i++) cout << ans[i];
cout << endl;
}
int main() {
cin.tie(nullptr), cout.tie(nullptr), ios::sync_with_stdio(false);
#ifdef _SHIFTPSH
freopen("_run/in.txt", "r", stdin), freopen("_run/out.txt", "w", stdout);
#endif
int t;
cin >> t;
for (int _ = 1; _ <= t; _++) {
cout << "Case #" << _ << endl;
solve();
}
return 0;
}
1차 4번 – 예약 시스템
$2 \times m$개의 방이 있는 호텔이 있습니다. $m \leq 50\,000$입니다.
$n\leq 20\,000$개 그룹의 투숙객들이 호텔에 묵으려 합니다. 각 그룹의 크기는 $5$ 이상이고, 한 명이 한 개의 방에 묵습니다.
모든 투숙객들은 스트레스 지수 $w_i$를 갖고 있어서, 인접한 방에 다른 그룹의 투숙객이 있고 그 투숙객의 스트레스 지수가 $w_j$라면, 그 쌍에 대해 $w_i + w_j$만큼의 충돌이 발생합니다. 모든 쌍에 대해 충돌의 합을 최소화하고 싶습니다.
(그냥 이렇게 설명하면 끝나는 문제인데, SCPC 운영진은 디스크립션을 어렵게 쓰는 재주가 있는 걸까요?)
SCPC의 서브태스크는 보통은 만점 풀이와는 무관한 브루트포스 풀이를 요구하는 경향이 있는데, 이 문제는 서브태스크 순서대로 생각해 보면 정해 풀이까지 다다를 수 있는 문제였다고 생각합니다.
문제를 처음 읽으면 어떻게 배치해야 될지 조차 감이 오지 않지만 서브태스크가 그룹 크기가 홀수 또는 짝수인 경우로 나뉘어 있다는 점에서 착안해 아래와 같은 접근을 시작할 수 있었습니다.
서브태스크 1: 그룹이 모두 짝수인 경우
우선 그룹의 크기 $l_i$가 모두 짝수일 때의 경우, 최적의 배치가 어떻게 되는지 생각해 봅시다. 다른 그룹과 ‘닿는’ 부분이 최소화되면 좋을 것 같습니다. 그런 배치는 아래 그림과 같이, $2 \times \frac{l_i}{2}$ 직사각형들을 이어 붙인 경우가 됩니다.
이 때 핑크색으로 칠한 부분에서 충돌이 일어납니다.
그룹의 순서가 정해져 있을 때 충돌의 합을 최소화하려면, 첫 번째 그룹과 마지막 그룹에서는 제일 작은 원소 $2$개씩을 고르고, 나머지 그룹에서는 제일 작은 원소 $4$개씩을 고르면 됩니다.
다르게 생각한다면 모든 그룹에서 제일 작은 원소 $4$개씩을 고른 후, 두 개의 그룹에서만 $3$번째로 작은 원소와 $4$번째로 작은 원소 하나씩을 빼 주면 됩니다.
$i$번째 그룹에서 $j$번째로 작은 원소를 $m_{i,j}$라고 합시다. 그러면 모든 그룹을 $m_{i,3}+m_{i,4}$ 순으로 정렬한 후, $\sum_i \left(m_{i,1}+m_{i,2}+m_{i,3}+m_{i+4}\right)$에서 $m_{i,3}+m_{i,4}$가 제일 큰 두 그룹만 빼 주면 정답입니다.
서브태스크 2: 그룹이 모두 홀수인 경우
짝수인 경우와 비슷하게 배치해줄 수 있습니다.
이 경우에는 충돌이 조금 더 많이 생기긴 합니다만, 짝수의 경우와 비슷하게 접근할 수 있습니다.
우선 각 그룹마다 두 번씩 충돌이 일어나는 원소가 하나 있는데, 이를 그 그룹에서 가장 작은 원소로 둡시다. 그러면 모든 그룹에서 제일 작은 원소 $4$개씩을 고른 후, 두 개의 그룹에서만 $3$번째로 작은 원소와 $4$번째로 작은 원소 하나씩을 빼 주면 되는 것은 동일합니다만, 가장 작은 원소는 한 번 더 더해줘야 합니다.
다시 말하면 모든 그룹을 $m_{i,3}+m_{i,4}$ 순으로 정렬한 후, $\sum_i \left(\textcolor{#ff3b57}{2m_{i,1}}+m_{i,2}+m_{i,3}+m_{i+4}\right)$에서 $m_{i,3}+m_{i,4}$가 제일 큰 두 그룹만 빼 주면 정답입니다.
서브태스크 3: 짝수 그룹과 홀수 그룹이 섞여 있는 경우
위에서의 접근을 바탕으로, 크게는 $3$가지 경우로 나눠 생각할 수 있습니다.
짝수 그룹과 홀수 그룹이 하나 이상씩 있다면, 맨 왼쪽 그룹과 맨 오른쪽 그룹에 짝수 그룹 하나와 홀수 그룹 하나씩이 있는 경우
짝수 그룹의 개수가 $2$개 이상이라면, 맨 왼쪽 그룹과 맨 오른쪽 그룹이 모두 짝수 그룹인 경우
홀수 그룹의 개수가 $2$개 이상이라면, 맨 왼쪽 그룹과 맨 오른쪽 그룹이 모두 홀수 그룹인 경우
3a: 맨 왼쪽 그룹과 맨 오른쪽 그룹에 짝수 그룹 하나와 홀수 그룹 하나씩이 있는 경우
먼저 홀수 그룹들을 전부 왼쪽에 배치하고, 나머지 짝수 그룹들을 전부 오른쪽에 배치합시다.
짝수 그룹 중 $m_{i,3}+m_{i,4}$가 가장 큰 그룹 하나와, 홀수 그룹 중 $m_{i,3}+m_{i,4}$가 가장 큰 그룹 하나를 골라서 빼 주면 됩니다.
3b: 맨 왼쪽 그룹과 맨 오른쪽 그룹이 모두 짝수 그룹인 경우
위의 경우와 비슷합니다. 오른쪽에 있는 짝수 그룹들 중 하나를 빼다가 맨 왼쪽에 붙이면 됩니다.
짝수 그룹 중 $m_{i,3}+m_{i,4}$가 가장 큰 그룹 두 개를 골라서 빼 주면 됩니다.
3c: 맨 왼쪽 그룹과 맨 오른쪽 그룹이 모두 홀수 그룹인 경우
이 경우는 약간 까다롭습니다.
일단 홀수 그룹 두 개를 잘 합치면 직사각형을 만들 수 있다는 점에서 착안해 아래와 같은 배치를 생각할 수 있습니다.
이 경우, 홀수 그룹 중 $m_{i,3}+m_{i,4}$가 가장 큰 그룹 두 개를 골라서 빼 주면 됩니다.
하지만 이런 경우는 홀수 그룹이 $4$개 이상인 경우에만 만들 수 있습니다. 홀수 그룹이 $2$개라면 어쩔 수 없이 아래와 같은 경우로 구성해야 합니다.
이 경우에는, 짝수 그룹들에서 $\sum_i \left(\textcolor{#ff3b57}{2m_{i,1}}+\textcolor{#ff3b57}{2m_{i,2}}+m_{i,3}+m_{i+4}\right)$를 해 줘야 합니다. 홀수 그룹이 $2$개인 경우에만 특수하게 처리해줍시다.
모든 경우를 고려한 코드는 아래와 같습니다. 정렬이 필요하기 때문에 $\mathcal{O}\left(n \log n\right)$만큼의 시간이 걸립니다. 사실 제일 큰 두 개 그룹만 구해도 상관없기 때문에, 잘 짠다면 $\mathcal{O}\left(n\right)$도 가능하지만요.
#include <bits/stdc++.h>
using namespace std;
using ll = long long;
using ld = long double;
using pii = pair<int, int>;
/* [t] [c] [s] */
int a[100000];
pii p[20000];
void solve() {
int n, m;
cin >> n >> m;
ll s = 0, sa = 0;
ll oc = 0, ec = 0;
for (int i = 0; i < n; i++) {
int l;
cin >> l;
for (int j = 0; j < l; j++) cin >> a[j];
sort(a, a + l);
((l & 1) ? oc : ec)++;
p[i].first = a[2] + a[3];
p[i].second = (l & 1);
s += (1 + (l & 1)) * a[0] + a[1] + a[2] + a[3];
sa += 2 * a[0] + (2 - (l & 1)) * a[1] + a[2] + a[3];
}
sort(p, p + n, greater<>());
if (oc && ec) {
ll coe = 0, coo = 0, cee = 0;
// coe: o o .. o e .. e e
int o = 0, e = 0;
for (int i = 0; i < n; i++) {
if (!o && p[i].second) {
coe += p[i].first;
o++;
}
if (!e && !p[i].second) {
coe += p[i].first;
e++;
}
if (o && e) break;
}
// coo: o o .. o e .. e o .. o o
if (oc >= 2) {
o = 0;
for (int i = 0; i < n; i++) {
if (o < 2 && p[i].second) {
coo += p[i].first;
o++;
}
if (o >= 2) break;
}
}
// cee: e e .. e o .. o e .. e e
if (ec >= 2) {
e = 0;
for (int i = 0; i < n; i++) {
if (e < 2 && !p[i].second) {
cee += p[i].first;
e++;
}
if (e >= 2) break;
}
}
vector<ll> cd;
cd.emplace_back(s - coe);
cd.emplace_back(sa - coo);
cd.emplace_back(s - cee);
if (oc >= 4) cd.emplace_back(s - coo);
s = *min_element(cd.begin(), cd.end());
} else {
s -= p[0].first + p[1].first;
}
cout << s << endl;
}
int main() {
cin.tie(nullptr), cout.tie(nullptr), ios::sync_with_stdio(false);
#ifdef _SHIFTPSH
freopen("_run/in.txt", "r", stdin), freopen("_run/out.txt", "w", stdout);
#endif
int t;
cin >> t;
for (int _ = 1; _ <= t; _++) {
cout << "Case #" << _ << endl;
solve();
}
return 0;
}
$s$는 다음의 합입니다.
\[s=\sum_i \begin{cases}m_{i,1}+m_{i,2}+m_{i,3}+m_{i,4} &\text{if } l_i\text{ is even}\\ 2m_{i,1}+m_{i,2}+m_{i,3}+m_{i,4} &\text{if } l_i\text{ is odd}\end{cases}\]
$sa$는 홀수 그룹이 $2$개인 경우 특수 처리를 해 주기 위한 값으로서 다음의 합입니다.
\[sa=\sum_i \begin{cases}2m_{i,1}+2m_{i,2}+m_{i,3}+m_{i,4} &\text{if } l_i\text{ is even}\\ 2m_{i,1}+m_{i,2}+m_{i,3}+m_{i,4} &\text{if } l_i\text{ is odd}\end{cases}\]
배열 $p$에는 모든 그룹들에 대해 홀/짝 정보와 $m_{i,3}+m_{i,4}$ 정보를 저장해 두고 정렬했습니다.
여담
이 문제는 오후 7시 33분에 한 번 수정되었습니다.
예약 시스템 문제에서 조건이 하나 빠져 있었습니다. 아래와 같이 명시했고, 제출 횟수를 20회로 늘릴 것입니다.
– 한 집합에 속한 예약자들은 모두 한 덩어리의 방들을 배정 받아야 한다. 한 덩어리의 방들이란 덩어리에 속한 어떤 방 두개에 대해서도, 덩어리에 속하고 인접한 방들을 통해서 이동이 가능하다는 의미이다.
그런 말이 쓰여 있지는 않았지만, 운이 좋게도? 당연히 연결 요소여야 최소일 것이라고 생각하고 풀었고, 문제를 맞을 수 있었습니다. 연결 요소가 아니어도 괜찮았을 경우, 다음과 같은 반례가 있습니다.
$100\,000$개 이하의 미지수 $X_i$들에 대해 다음 쿼리들을 수행해야 합니다. 쿼리의 수는 $200\,000$개 이하입니다.
1 i j d: $X_i + d = X_j$라는 조건을 추가합니다.
2 i j: $X_i-X_j$를 출력합니다. 조건이 모순된다면 CF를, 주어진 조건들만으로 알 수 없다면 NC를 출력합니다.
$d$가 없다면 간단한 DSU 문제입니다. 이걸로 서브태스크 1과 3을 쉽게 해결할 수 있습니다.
DSU 트리의 간선들에 가중치가 있다고 생각한다면 서브태스크 2와 4를 해결할 수 있습니다.
우리가 DSU 쿼리를 $\mathcal{O}\left(\alpha\left(N\right)\right)$만에 할 수 있는 이유는 경로 압축path compression이라는 좋은 테크닉이 있어서입니다. $p_u$가 노드 $u$의 부모 노드라고 한다면, $u$의 루트를 구하는 함수 $\mathrm{find}$에서 경로 압축은 다음과 같이 재귀적으로 수행했습니다.
이렇게 하면 $u$에서 $u$의 루트 $r$로 가는 경로 위에 있는 모든 정점들의 부모가 아예 $r$로 바뀌어 버리게 됩니다.
현재 노드 $u$에서 부모 노드 $p_u$로 가는 비용을 $d_u$라고 합시다. 그러면 $d_u$도 비슷한 방법으로 압축해버릴 수 있습니다.
$\mathrm{find}$ 함수를 돌릴 때 $u$의 부모 노드는 $p_u$였고, $p_u$의 부모 노드는 $r$이었습니다. 따라서 $u$에서 $r$까지 가는 데는 $d_u + d_{p_u}$만큼의 비용이 필요합니다. $\mathrm{find}$ 함수에서 경로 압축을 수행하면서, $d_u$를 $d_u + d_{p_u}$로 업데이트해 주면 됩니다. 이제 가중치가 있는 DSU 트리에서도 경로 압축을 할 수 있습니다.
1번 쿼리와 2번 쿼리 모두 $\mathcal{O}\left(\alpha\left(N\right)\right)$만큼의 시간이 걸립니다. 총 시간 복잡도는 $\mathcal{O}\left(K\alpha\left(N\right)\right)$입니다.
밥 먹고 알고리즘 공부만 하면 얼마나 걸릴지는 몰라도 언젠가는 코드포스 레이팅 3,000이 될 겁니다.
뭐, 세상에는 레이팅이 3,000을 넘는 괴물들도 다수 있지만 일단은 이론적으로 밥만 먹고 문제만 풀면 언젠가는 3,000에 갈 수 있다고 합시다. 사람마다 걸리는 시간은 다르겠지만요. 이를 근거로 공부한 시간 $t$에 대한 실력 $f$를 아래와 같이 모델링해 봅시다.
\[f\left(t\right) = 3\ 000 \left(1-a^t\right)\]
공부한 시간 v. 레이팅
하지만 실력은 올라가기만 하는 건 아닙니다. 어떤 날은 컨디션이 좋아서 머리가 잘 돌아가고 문제가 잘 풀릴 수도 있는 반면 어떤 날은 피곤하거나 우울하거나 뭐 물리적으로는 손가락이 아프다거나 할 수 있죠. 그렇기 때문에 조금 더 정확하게 실력을 모델링하려면 노이즈를 끼워야 할 겁니다. 대충 아래와 같은 모델은 어떤가요?
\[f\left(t\right) = 3\ 000 \left(1-a^t\right) + b \sin \left(ct\right)\]
공부한 시간 v. 레이팅 (약간 더 현실적인 모델)
좋습니다. $t$의 스케일이 얼마일지는 모르겠지만 이게 우리의 현재와 미래 실력을 대략적으로 모델링해준다고 합시다. 믿어 주세요.
하지만 제 레이팅은 계속 제자리인걸요
위 그래프에서 어떤 사람이 레이팅 1,400에서 1,600까지 가는 여정만을 한 번 살펴봅시다.
1,400 — 1,600
아마 가장 먼저 드는 생각은 이거일 거예요. ‘실력은커녕 내 그래프는 이거랑 비슷하지도 않은데…’ 맞아요. 쉽게 와닿지 않죠? 하지만 제가 여기에다 점을 몇 개 찍어볼게요.
1,400 — 1,600
… 어떤가요, 있을 법한 그래프이지 않나요? 운이 정말 나쁘다면 이런 경우도 가능할 거구요.
4연속 하락
이 그래프의 주인공은 과연 영영 파란색 닉네임을 달지 못하게 되는 걸까요? 우리는 결국에는 1,600이 될 거라는 사실을 알고 있지만, 점선을 지우고 나서 이게 자신의 그래프라고 생각한다면 정말 슬플지도 모르겠네요…
사실 저도 경험해 봤습니다
대회는 실력의 샘플링에 불과하다
여기서 중요한 관찰이 하나 있습니다.
우리가 모델링한 실력 그래프와 코드포스 레이팅 그래프 사이에는 큰 차이점이 있습니다. 우리 그래프는 연속적이지만 코드포스 그래프는 그렇지 않다는 점입니다. 이는 ‘대회’라는 시스템의 본질에서 기인합니다.
대회는 우리 실력이 지금 이 순간 어땠는지만을 알려주지, 실력을 실시간으로 알려주지는 않습니다.
이게 왜 큰 차이냐면, 코드포스 레이팅 그래프가 우리의 실력을 정확하게 말해주지 않는다는 뜻이기 때문입니다.
한 마디로, 대회는 실력의 샘플링에 불과합니다. 심지어 샘플링 주기가 짧지도 않습니다. 그래서 사실 그래프에 찍힌 점들만 보고 거시적으로 어디로 갈지 예측하는 건 불가능에 가깝습니다. 위에서는 실력 기복을 $b \sin ct$라고 퉁쳤지만 사실 그렇지도 않을 거구요.
게다가 보통 한 대회에는 문제가 6개밖에 없기 때문에, 모든 분야가 고르게 출제될 수도 없으며, 운 나쁘게 내가 자신없는 분야가 출제되어서 평소보다 못 풀 수도 있습니다. 다시 말하면 샘플링 자체도 그렇게 완벽하지는 않습니다.
문제 수 이야기가 나와서 말인데 레이팅 말고 대회에서 해결한 문제 수로 바꿔서 생각해 볼까요? 코드포스에서는 몇 문제를 풀었는지가 레이팅을 결정하는 중요 요소로 작용하죠. 하지만 푼 문제 수는 보통 한 자리 정수입니다. 굉장히 이산적인데요, 대회마다 나오는 문제의 난이도가 일정하다고 하면, 위에서 만든 실력 모델링 그래프는 대략 아래처럼 됩니다.
문제 수로 봤을 때의 그래프
똑같은 3솔브여도, C를 간신히 해결한 3솔브와 D를 다 생각했는데 시간이 약간 부족해서 못 푼 3솔브는 다를 겁니다. 여유롭게 3솔브를 하고 아깝게 4번째 문제를 못 풀었다면 적어도 간신히 3솔브를 했을 때보다는 확실히 성장했을 테지만, 결과적으로 스코어보드에 보이는 건 똑같이 세 개의 초록색이겠죠.
마지막으로, 코드포스의 레이팅 공식조차 실력을 완벽하게 표현해 주지는 못합니다. 코드포스의 공식은 마지막으로 친 대회 결과에 상당히 큰 영향을 받도록 설계되어 있습니다. 최근 5개 정도 대회만 실력을 유의미하게 반영해 주는데요, 연속적으로 운이 좋거나 나쁘면 아예 색깔이 바뀔 수도 있는 시스템이라 평소 실력을 제대로 반영해 주지 못합니다. 관련해서는 djm03178님의 Codeforces 레이팅에 관련된 글을 읽어 보면 좋습니다.
그러니까 문제를 평소보다 못 풀어도 괜찮고, 레이팅이 떨어지더라도 괜찮아요. 애초에 그게 진짜 본인의 실력은 아닐 거예요.
그래서 목적지는 레이팅이 아니다
라고 말하고 싶습니다. 바꿔 말하자면, 레이팅은 진짜 실력이 아니고, PS 실력을 키우는 것과 레이팅을 올리는 것은 비슷해 보이면서도 다르다고 생각합니다.
물론 색깔을 바꾸기 위해 알고리즘 문제해결 공부를 하는 것도 정말 멋진 일입니다. 하지만 그 과정이 정말 지치고 힘이 든다면, 레이팅은 좋은 목표가 아닐지도 모릅니다.
하지만 실력을 키우면 레이팅은 자연스럽게 올라갈 거예요. 이런 마음가짐을 가지고, 대회를 충분히 많이 치면 언젠가는 목표하는 레이팅이 될 수 있다는 희망을 갖고, 나 자신의 가능성을 믿도록 합시다.
조금 현실적인 조언
업솔빙 / 문제 수를 목표로 하기 — 그래도 해결하는 문제 수는 레이팅보다 직관적이면서도 그렇게 많이 변하는 값은 아니기 때문에 목표로서 유의미하다고 생각합니다. 문제 레이팅을 목표로 하는 것과 맥락을 같이하는데요, 대회에서 풀었던 제일 어려운 문제의 다음 번 문제를 해결하려고 시도해 봅시다. 모르겠다면 에디토리얼을 보고 인사이트를 얻어갑시다. 아까운 실수로 틀렸다면 너무 자책하지 말고 오히려 자신을 격려해 줍시다. 뼈아픈 실수일수록 반복하는 일이 적을 거예요. 궁극적으로는 대회에서 해결할 수 있는 문제 수를 늘리는 것을 목표로 합시다.
문제 레이팅을 목표로 하기 — 문제 수를 목표로 하는 것과 맥락을 같이합니다. 코드포스 대회가 끝나면 Problemset에 문제 레이팅이 공개됩니다. 목표 문제 레이팅 $r$을 정해 두고, 대회가 끝난 후 $r$ 이하의 문제들을 풀어보는 것으로 단련해 봅시다. 궁극적으로는 대회 시간 내에 $r$ 이하의 문제들을 안정적으로 풀 수 있는 것을 목표로 합시다.
버추얼 컨테스트 돌리기 — 코드포스에는 끝난 대회를 가상 참가할 수 있는 기능이 있습니다. 또 가상 컨테스트 참여로 가상 레이팅을 계산할 수 있는 서비스도 있습니다. 이 서비스를 활용해 가상 컨테스트를 자주 치면 실력도 단련할 수 있고, 앞서 언급한 샘플링 주기의 문제도 어느 정도 해결할 수 있겠죠.
Atcoder — 일본 기반의 알고리즘 대회 사이트입니다. Atcoder는 코드포스의 레이팅 공식과 달리 현재까지 참여한 모든 대회의 퍼포먼스를 가중평균하는 식으로 레이팅을 계산하기 때문에 참가자의 평소 실력을 좀 더 잘 반영한다고 생각합니다. 게다가 문제도 코드포스보다 훨씬 깔끔하며, 시스텟이 없고, 무엇보다 시간대가 같아서 주말 오후 9시에 부담없이 참여할 수 있다는 장점도 있습니다. 강력하게 추천합니다.
팀 연습 하다 오기 — 조금 더 긴 시간 동안 더 어려운 문제들에 대해서 생각해볼 수 있는 좋은 방법입니다. 새로운 인사이트를 얻을 수 있습니다.
당분간 쉬기 — 너무 지쳤다면 괜찮아질 때까지 쉬어도 괜찮습니다. 알고리즘은 잊고 놀러 나가서 맛있는 거 먹고 옵시다. 금방 다시 회복할 수 있을 거예요.
알고리즘 문제해결이 여러분을 마음고생시키지 않았으면 좋겠어요. 여러분의 문제해결을 항상 응원합니다.
Baekjoon Online Judge 문제들에 난이도와 태그를 매겨서, BOJ에 있는 방대한 문제들 중 어떤 문제를 풀면 좋을지 훨씬 쉽게 고를 수 있는 수단을 제공합니다.
푼 문제 수가 아닌, 푼 문제들의 난이도의 구성을 바탕으로 한 실력 지표와 이를 기반으로 한 순위 등을 제공해, 알고리즘 문제해결 학습자들에게 더 흥미로운 문제를 해결할 동기를 부여합니다.
실력 지표의 경우, 기존에는 문제를 해결할 때마다 경험치가 쌓이고, 푼 문제들의 경험치의 총 합을 기준으로 실력 지표인 티어를 결정했습니다. 이 방식은 solved.ac가 처음 만들어진 2019년 6월 6일부터 2년 가까히 이어져왔습니다만, 오는 1일부터는 새로운 실력 지표인 AC RATING으로 티어를 결정하게 됩니다. AC RATING은 아래의 합으로 결정되며, 이론적으로 3,450 이하의 정수 값입니다.
푼 문제들을 난이도 순으로 내림차순 정렬했을 때, 상위 100개 문제의 난이도 값의 합 (최대 3,000)
CLASS에 따른 보너스 (최대 250)
푼 문제 수에 따른 보너스 (최대 175)
기여 수에 따른 보너스 (최대 25)
아니 잘 쓰던 경험치 냅두고 왜 이제 와서 이상한 조건의 레이팅을?이라고 생각하실까봐 레이팅제가 어떤 과정을 거쳐 탄생했는지에 대해 소개합니다.
경험치제의 문제점
기존의 경험치제를 간략하게 요약하면 이렇습니다.
브론즈 5 문제를 해결하면 320점을 주도록 합니다. 어떤 문제보다 1티어 높은 문제의 경우 약 1.5배의 경험치를 주도록 합니다.
브론즈 4 티어가 되려면, 브론즈 5 티어를 달성한 이후 브론즈 4 문제를 20문제 더 해결해야 하도록 합니다. 티어 $x$가 되려면, 티어 $x-1$을 달성한 후 난이도 $x$의 문제를 $n_x$개 더 해결해야 하도록 합니다.
기여 한 건마다 경험치 10,000을 줍니다.
이는 여러분께서 자신의 티어와 비슷한 난이도의 문제를 해결할 것으로 기대하고 기획한 것이었습니다. 하지만 여러 부작용이 있었습니다.
단적인 예로 아무것도 해결하지 않은 사람이 루비 1 문제 하나를 풀면 그 한 문제 덕분에 바로 다이아몬드 5가 됩니다. 알고리즘 실력을 키우고 싶은지 아닌지는 제쳐두고, 티어를 올리고 싶다면 힘들게 브론즈 실버를 캐면서 차근차근 올라갈 필요 없이 어려운 문제 하나만 풀면 되는 것입니다.
보통 그런 ‘어려운 문제’는 혼자 힘으로 해결하기 상당히 어렵기 때문에 인터넷을 참고해 해결하는 경우가 많고, 해결하는 순간 경험치 구성의 대부분을 차지해 버리게 됩니다. 이제 본인 실력의 문제를 해결하는 것으로는 경험치가 1%도 오르지 않습니다.
루비 V 한 문제가 경험치의 93.4%를 차지하는 극단적인 사례.
위 유저가 해결한 문제 중 가장 어려운 문제는 루비 V이고, 그 다음은 골드 II 한 문제, 골드 III 두 문제, 골드 V 열한 문제입니다.
기존 경험치제에서 이 유저의 티어는 플래티넘 V인데, 플래티넘 V 유저가 골드 V 한 문제를 풀어서 얻을 수 있는 경험치량은 0.411%입니다.
루비 V 한 문제를 풀지 않았다면? 이 유저의 티어는 실버 I이었을 것이며, 이 경우 골드 V 한 문제는 무려 6.02%의 경험치를 줍니다. 그러면 현재 루비 V 문제 하나를 해결한 상황에서 골드 V 문제를 푸는 게 과연 매력이 있을까요? 그렇다고 플래티넘 문제들을 푸는데 많은 시간을 소비할까요?
대부분의 경우, 의욕을 잃거나 새로운 어려운 문제를 찾아 떠나게 됩니다. 이런 점을 노린 코드 카피 어뷰징이 solved.ac가 등장한 이후 상당히 빈번하게 발생했습니다. solved.ac는 알고리즘 문제해결 학습자들의 학습 동기 증진을 목적으로 하는 사이트인데, 기존 경험치제가 학습자를 다소 좋지 않은 학습 방향으로 유도한다는 생각이 들었습니다.
또한 한 문제를 풀면 경험치를 얼마나 주는지, 다음 티어로 올라가기 위해서는 총 경험치가 얼마쯤 되어야 하는지 혹은 어떤 문제를 얼마나 해결해야 하는지 알기가 어려웠다는 사소한 문제도 있었습니다. 더구나 현재 1위의 총 경험치의 자릿수는 11자리나 되어 상당히 비직관적입니다.
레이팅제의 목표
기존의 제도에는 이런 문제점들이 있었고, 이를 어느 정도 해결하기 위해 많은 고민 끝에 새로 레이팅 제도를 만들었습니다. 새 레이팅 제도의 목표는 아래와 같았습니다.
실력을 정확히 측정하는 것과 동기를 불러일으키는 것 사이 어딘가에서 적당히 줄다리기합니다. 둘 다 완벽하게 되면 더 좋고요.
낮은 티어의 유저들이 새롭고 다양한 알고리즘 분야를 접하는 것을 장려합니다.
푼 문제가 현저히 많다고 레이팅이 현저히 높아지거나, 어려운 문제 하나가 레이팅의 대부분을 차지하게 되는 현상을 최대한 완화합니다.
직관적인 값으로 보여지도록 합니다.
서버가 빠르게 계산할 수 있도록 합니다.
실력 측정 vs 동기 부여
기존의 경험치제나, 새로 도입하게 되는 레이팅제나 사용자의 정확한 실력을 반영해 주기 원하시는 분들이 많았습니다. 결론부터 말하자면 정확한 실력을 가늠하는 건 불가능했기 때문에, 레이팅과 실력과의 상관관계를 높이는 것은 목표로 하지 않았고, 기존과 같이 약한 상관관계를 보이게 하는 것으로 만족했습니다.
정확한 실력을 가늠하는 것이 불가능한 이유는 BOJ가 OJ이기 때문입니다. OJ에 등록된 문제들은 이미 어딘가에서 출제되었던 문제들이고, 많은 경우 쉽게 해설을 찾아볼 수 있습니다. 반면 대회 플랫폼의 경우 매번 새로운 문제들을 주고 틀린 횟수와 해결 시간을 바탕으로 실력을 계산합니다.
따라서 OJ 쪽은 대회 플랫폼에 비해 유저의 실력을 계산하기 위해 사용할 수 있는 정보와 그 정보의 신뢰도 모두가 현저히 떨어집니다. 심지어 대회 플랫폼의 레이팅도 정확한 실력을 반영한다고는 할 수 없습니다. 대회는 실력을 샘플링하는 것에 지나지 않기 때문입니다. 수능 모의고사에서 1등급을 받은 학생이 수능에서도 같은 등급을 받을 것이라는 보장이 없듯이요…
이런 이유로 레이팅과 실력과의 대략적인 상관관계는 기존 수준으로 유지하되 새 레이팅 제도가 목표로 하는 동기 부여적 측면을 더 부각시킬 수 있는 쪽으로 기획 방향을 정했습니다.
레이팅의 뼈대
무작정 높은 난이도의 문제를 푸려고 하게 되는 이유는, 높은 난이도의 문제가 푸는 데 오랜 시간이 걸림에도 불구하고 티어 상승이라는 측면에서 상당히 매력적으로 보이기 때문입니다.
기존 경험치제에서 루비 I 문제 하나를 푸는 것은 브론즈 V 문제 약 30만개를 푸는 것과 비슷한 경험치를 줬고, 이는 문제해결에 쏟는 시간 대비 엄청난 가성비를 보여줍니다. 모든 티어에서 상당히 매력적으로 보이는 게 당연합니다. 따라서 매력을 너프하기 위해서는, 일단 문제 해결로 얻는 경험치가 난이도에 따라 기하급수적으로 올라가는 식이 아니어야 합니다.
하지만 그렇게 되면 난이도에 관계없이 문제를 많이 해결한 사람이 무조건 유리해집니다. 레이팅이 적용된 다른 OJ들이나 비슷한 구조의 게임들이 이를 막는 방법은 크게 두 가지가 있습니다.
반영되는 문제 수에 제한을 둡니다. $n$문제를 반영한다면, 어떤 사용자가 난이도 $x$까지의 문제를 해결할 수 있을 때 이론적으로 받을 수 있는 최대치는 $nx$입니다.
모든 문제를 반영하되 적당한 상수 $0<r<1$을 정해서 첫 문제에는 $1$을, 두 번째 문제에는 $r$을, 세 번째 문제에는 $r^2$를 곱해나가는 식으로 합니다. 어떤 사용자가 난이도 $x$까지의 문제를 해결할 수 있을 때 이론적으로 받을 수 있는 최대치는 $\frac{x}{1-r}$입니다.
두 방법은 사실상 같습니다만 첫 번째 방법은 서버가 계산하기 쉬운 대신 특정 난이도 이상의 문제를 풀지 않으면 아무리 문제를 풀어도 레이팅이 아예 오르지 않는다는 단점이 있고, 두 번째 방법은 문제를 풀면 레이팅이 계속 오르겠다는 믿음을 주는 대신(실제로는 1점 올리기는 상당히 어렵습니다) 서버가 레이팅을 계산하는 코스트가 조금 더 든다는 단점이 있습니다.
그래서 문제를 풀면 레이팅이 오르겠다는 믿음은 다른 방법으로 주기로 하고 첫 번째 방법을 택했습니다. 100문제를 해결하면 레이팅이 수렴했다고 보고, 푼 문제들을 난이도 순으로 정렬해 상위 100개 문제의 난이도 값의 단순합을 레이팅의 가장 많은 부분을 차지하도록 했습니다. 공교롭게도 solved.ac의 문제 난이도는 0부터 30까지라서 이렇게 하면 총 3,000점이 되고, 다른 대회 플랫폼들의 4자리수 레이팅과 비슷한 값이 되어 직관적이게 됩니다.
상위 100문제의 난이도 합으로 결정
여기에 문제 해결 수에 따른 보너스 레이팅을 $\left\lfloor 175\left( 1-0.995^n \right) \right\rceil$만큼 주어 약 1,200문제를 해결할 때까지 어느 문제나 해결해도 레이팅이 오른다는 믿음을 주도록 유도했습니다. 다만 실제로 믿으실지는 모르겠습니다. 믿어 주세요.
기존 기획은 이 100문제를 (5년간 출제된 OI/ICPC 문제) 50개와 나머지 문제 50개를 반영하려 했으나, 그렇게 할 근거가 부족하여 100문제를 합하는 것으로 선회했습니다.
새롭고 다양한 알고리즘 문제해결 장려
CLASS
solved.ac에는 티어 외에도 CLASS라는 실력 지표가 있습니다. 실력대별로 미리 정해진 48문제 중 20문제 이상을 해결하면 얻을 수 있습니다.
CLASS 문제들은 수준에 따라 교육적인 목적을 갖고 정해져 있습니다. 예를 들어,
CLASS 1는 프로그래밍 혹은 알고리즘 문제해결 입문자가 풀어보면 좋을 만한 문제들로 구성했습니다.
CLASS 2는 코딩 테스트나 프로그래밍 대회 등에서 자주 등장하는 주제들 중 초심자가 이해하고 구현하기 쉬운 주제들로 구성했습니다. (브루트포싱, 기초 수학, 정렬, 큐, 스택, 덱)
CLASS 3은 CLASS 2에서 등장한 주제들을 전부 이해하고 나서 시도하면 좋을 만한 주제들로 구성했습니다. (그래프, 그래프 탐색, 힙, 우선순위 큐, 다이나믹 프로그래밍 등)
CLASS 4는 CLASS 3과 비슷하지만 더 어렵다고 느껴지는 주제들을 담았습니다. (백트래킹, 최단 경로 문제, 어려운 구현, 어려운 다이나믹 프로그래밍, 어려운 그래프 문제 등)
낮은 CLASS 문제들은 ‘단계별로 풀어보기’와 비슷한 구성으로 초심자가 가면 좋을 만한 길을 추천해 주는 것을 목표로 했습니다. 이를 더더욱 권장하기 위해 레이팅에 CLASS 보너스를 추가했습니다. 다만, 새 레이팅과 실력과의 괴리가 생길 것을 감안해 낮은 티어에서는 CLASS 보너스가 매력적으로 보이지만 높은 티어에서는 CLASS 보너스의 유무가 랭킹에 큰 차이를 주지 않도록 다음과 같이 정했습니다.
CLASS 1, 2: +25점
CLASS 3, 4, 5: +50점
CLASS 6~: +10점
CLASS 6부터는 주로 프로그래밍 대회에만 등장하는 어려운 주제들을 다루고 있습니다. 또한 CLASS 6 이상을 취득할 수 있는 실력의 사람이라면 CLASS 5 정도는 쉽게 취득할 수 있고, 굳이 CLASS 문제를 해결하지 않더라도 실력을 늘릴 방법을 많이 알고 있을 것이라고 생각했기 때문에 CLASS 6 이상에서의 레이팅 보상은 랭킹에 크게 영향을 미치지 않는 방향으로 결정했습니다.
레이팅 컷
레이팅에 따른 티어는 크게 두 가지 요소를 고려해 정했습니다.
티어 $x$의 유저 입장에서 티어 $x+1$로 가기 위한 과정에서의 경험은 적절한가
티어에 따른 유저 비율이 어떻게 변화할 것인가
특히 새로운 레이팅 제도에서는 상위 100문제를 반영하고 있는데, 알고리즘 공부를 막 시작한 입장에서는 100문제를 해결하는 것부터 버거울 수 있겠습니다. 따라서 ‘몇 CLASS이길 기대하는가?’와 더불어 낮은 티어의 경우 ‘몇 문제를 해결하는 것을 기대하는가?’를 고려했습니다. 예를 들자면
기존 경험치제의 브론즈 구간에서는 실력에 맞는 문제를 약 30문제 정도를 해결하는 것을 기대했습니다. 새로운 레이팅제에서는 CLASS 1~2를 해결하는 여정을 고려하여 레이팅 컷을 정했습니다.
골드 구간부터는 100문제 이상 해결을 기대하고, 상위 100문제에서 기대하는 난이도 평균을 고려했습니다. 예컨대 골드 III 유저는 평균적으로 클래스 2~3에 실버 II에서 골드 V 수준의 문제를 쉽게 해결할 수 있을 것으로 생각했습니다. 클래스 5를 달아 레이팅 100~150을 챙기고, 클래스 5를 풀면서 골드 상위~플레 하위 문제들에 익숙해져 상위 100문제를 그렇게 구성한다면 어느새 플래티넘이 되어 있을 것입니다.
이론적인 레이팅 만점은 3450이지만 루비 구간의 문제들이 부족하고 상위 100문제가 이미 다이아몬드와 루비로 꽉 차 있는 상황에서 더 어려운 루비 문제를 해결하는 것 자체가 상당히 어려운 과정임을 감안해 루비 구간은 촘촘하게 나눴습니다.
그렇게 하면서도 레이팅 컷이 직관적인 수가 되도록 했습니다 – 브론즈 30, 실버 200, 골드 800, 플래티넘 1600, 다이아몬드 2200, 루비 2700. 이렇게 각각의 티어에서 많은 고민 끝에 레이팅 컷을 정했습니다.
새 레이팅 컷
플래티넘, 골드, 실버, 브론즈가 각각 상위 10%, 33%, 67%, 100%가 되는 것이 이상적이라고 생각하고 있습니다만, 당시 레이팅 공식이 공개되지 않았음을 고려해 기존보다 약간 더 어렵게 설정했습니다. 레이팅 공식이 공개되는 것이 유저 비율에 영향을 미칠 수 있어서입니다.
레이팅 vs 기존 실력 지표
(왼쪽) 새 티어와 코드포스 레이팅의 상관관계, (오른쪽) 기존 티어와 코드포스 레이팅의 상관관계
신규 레이팅제에서, 코드포스 아이디가 존재하는 상위 569명을 대상으로 코드포스 레이팅과 새 티어를 비교한 결과 기존 티어에 비해 상관관계가 약해졌습니다만, 기존과 같이 어느 정도의 상관관계는 유지하는 양상을 보였습니다. Inversion count도 기존 148,135회에서 161,462로 증가했습니다. 기존 경험치제의 문제점을 해결하기 위해 실력과의 상관관계를 다소 희생했으나, 여전히 어느 정도 유의미한 상관관계를 가진다고 해석했습니다.
극복해야 할 과제
새로운 레이팅제도 완벽하진 않습니다. 대표적으로 1,200문제를 해결해 문제 수 보너스 175점을 모두 받은 유저의 경우, 새 레이팅제에서는 상위 100문제보다 낮은 난이도의 문제를 해결하는 것의 의미가 없어집니다. 충분히 흥미로운 문제가 있을 수도 있지만요. 또한 CLASS 보너스 레이팅을 산입하는 것이 좋은 선택인가에 대한 논의도 있었습니다.
이런 부분들에 대해서는 레이팅제로 운영해보면서 어떻게 개선할 수 있을지에 대해 고민해 보기로 했습니다. 길라잡이 컨텐츠를 잘 만드는 것 등 레이팅 공식 외적으로도 개선할 수 있는 부분이 있을지도 모르겠습니다.
티어를 어떻게 결정할지를 정하는 것은 solved.ac 전체를 통틀어 가장 어려운 기획입니다. 그만큼 수많은 고민 끝에 만들어진 기획인데, 고민한 만큼 긍정적으로 정착하면 좋겠습니다.
이후 계획
제가 직장인이 되었고 또 여러가지 일들로 바빠지다 보니 solved.ac에 새로운 컨텐츠를 만들 시간이 상대적으로 부족해졌습니다. 현재 계획하고 있는 것들은 이렇습니다.
백엔드 리팩터링(~6월). 프론트엔드에 이어 백엔드입니다. 현재 백엔드는 PHP인데, 유지보수가 너무 어려운 상황이라 Express로 다시 짜고 있습니다. solved.ac를 처음 만들 시절엔 이렇게 커질 줄 몰랐으니까 어쩔 수 없는 것 같습니다. 프로젝트를 시작할 때부터 기반을 잘 닦읍시다.