tkd0711 님의 블로그

앳코더 ABC 459 후기

tkd0711 — Sat, 23 May 2026 22:47:57 +0900

앳코더 ABC 459 후기

tkd0711 · 2026. 5. 23.

AtCoder Beginner Contest 459
https://atcoder.jp/contests/abc459

날짜: 2026-05-23 (Sat)
결과: A~D AC, 1000점
풀이 순서: A → B → D → C
A: 1:41
B: 15:28
D: 45:18
C: 91:01, 5틀

1. 전체 느낌

이번 대회는 여러모로 기억에 남을 것 같다.

일단 어제 취업했다.
그리고 그날 밤에 앳코더도 했다.

결과는 A~D AC, 1000점.
점수만 보면 나쁘지 않은데, 체감은 꽤 다산다난했다.

A, B를 풀고 D를 먼저 해결한 뒤,
마지막에 C로 돌아와서 오래 맞고 겨우 해결했다.
특히 C는 처음 보는 유형의 관리 문제라서 생각보다 많이 헤맸다.

그래도 끝까지 포기하지 않고 결국 AC까지 가져간 점은 좋았다.
오늘은 깔끔하게 푼 대회라기보다, 끝까지 물고 늘어져서 살아남은 대회였다.

2. A, B – 초반은 무난했지만 B에서 약간 아쉬움

A는 큰 문제 없이 해결했다.

B는 처음에 배열을 만들어서 일반적으로 처리하려고 했다.
그런데 경우가 4개짜리라서, 중간에 그냥 하드코딩으로 전환했다.

결과적으로 풀긴 했지만,
처음부터 “이 정도 경우의 수면 그냥 직접 처리하는 게 빠르다”고 판단했으면 조금 더 시간을 줄일 수 있었을 것 같다.

이번 B에서 느낀 점은 이거다.

작은 경우의 수 문제에서는 괜히 일반화하려다가 구현이 더 무거워질 수 있다.
제한이 작고 경우가 적으면, 빠르게 직접 처리하는 판단도 필요하다.

3. D – 생각보다 빠르게 푼 문제

D는 C보다 먼저 풀었다.

문제는 문자열을 재배열해서
인접한 두 문자가 같지 않게 만들 수 있는지 판별하고, 가능하면 실제 문자열을 출력하는 문제였다.

처음 봤을 때 느낌은 꽤 단순했다.

가장 많이 남은 문자를 우선적으로 배치하되,
직전에 쓴 문자와는 다른 문자를 고르면 되지 않을까?

그래서 각 문자 개수를 세고,
매번 직전 문자와 다른 것 중 남은 개수가 가장 많은 문자를 골랐다.

알파벳은 26개뿐이고,
모든 테스트 케이스 문자열 길이 합도 제한이 있어서
매번 26개를 훑는 방식으로 충분했다.

이 문제는 “한 문자가 너무 많으면 불가능하다”는 감각도 있었고,
구현도 크게 꼬이지 않았다.

오늘 D는 꽤 잘한 편이었다.
C에서 오래 고생한 것과 다르게, D는 구조가 빨리 보였다.

4. C – 오늘의 진짜 보스

문제 요약

N개의 칸이 있고, 처음에는 모든 칸에 블록이 없다.

쿼리는 두 종류다.

1 x: x번째 칸에 블록을 하나 놓는다. 그 결과 모든 칸에 블록이 1개 이상 있으면, 모든 칸에서 블록을 1개씩 제거한다.
2 y: 블록이 y개 이상 있는 칸의 개수를 출력한다.

처음에는 단순해 보였는데, 직접 생각해보니 꽤 까다로웠다.

처음 접근

처음에는 각 칸의 블록 개수를 배열로 관리하고,
전체에서 몇 번 1개씩 제거했는지를 minusidx 같은 변수로 관리하면 되겠다고 생각했다.

즉 실제 블록 수를 전부 직접 빼지 않고,
“전체 감소 횟수”만 따로 들고 가려는 방향이었다.
이 생각 자체는 맞는 쪽이었다.

하지만 문제는 2 y 쿼리였다.

블록이 y개 이상 있는 칸의 개수를 빠르게 구해야 하는데,
매번 모든 칸을 돌면 안 된다.

여기서 꽤 오래 고민했다.

핵심 관찰

결국 중요한 건
“현재 블록 수”를 직접 세는 게 아니라,
각 칸이 어떤 높이를 달성했는지를 세는 것이었다.

예를 들어 어떤 칸에 블록을 놓아서 누적 높이가 5가 되었다면,
그 칸은 “높이 5를 달성한 칸”이 된다.

그래서 cntarr[h]를

누적 높이 h를 달성한 칸의 개수

처럼 관리하면 된다.

그리고 전체에서 1개씩 제거된 횟수를 minusidx라고 하면,
현재 블록이 y개 이상인 칸은
누적 기준으로 y + minusidx를 달성한 칸이다.

이 관찰을 잡고 나서야 문제가 풀리기 시작했다.

처음 코드가 틀린 이유

처음에는 boolean 배열과 flag를 이용해서
“이번 기준에서 방문했는가”를 관리하려고 했다.

하지만 이 방식은 틀렸다.

왜냐하면 이 문제는 단순히
“이번 라운드에 방문했는가”를 보는 문제가 아니기 때문이다.

예를 들어 상태가

3 0 3

이고, 가운데에 하나를 놓으면

3 1 3

이 되어 전체 제거가 일어나고,

2 0 2

가 된다.

여기서 다시 가운데에 하나를 놓으면

2 1 2

가 되고 또 전체 제거가 가능해진다.

즉 같은 칸이 여러 기준에서 다시 “1 이상인 칸”이 될 수 있다.
단순 방문 체크로는 이걸 제대로 관리할 수 없었다.

수정한 핵심 코드

그래서 결국 다음처럼 바꿨다.

arr[b]++;
cntarr[arr[b]]++;

if (arr[b] == minusidx + 1) {
    cnt++;
}

if (cnt == n) {
    minusidx++;
    cnt = cntarr[minusidx + 1];
}

이 코드의 의미는 다음과 같다.

arr[b]는 b번째 칸에 지금까지 실제로 놓은 총 횟수
minusidx는 전체에서 1개씩 제거한 횟수
어떤 칸의 arr[b]가 minusidx + 1이 되면, 현재 기준에서 그 칸은 블록이 1개 이상 있는 칸이 된다.
모든 칸이 현재 기준을 달성하면 minusidx를 1 올린다.
다음 기준에서 이미 달성한 칸 수는 cntarr[minusidx + 1]로 바로 알 수 있다.

이걸 보고 나서야 문제가 정리됐다.

느낀 점

C는 정말 고생했다.

처음에는 방문 체크 문제처럼 봤는데,
실제로는 “기준 높이 달성 여부”를 관리하는 문제였다.

내가 이걸 “달성 카운트”라고 생각했는데,
그 표현이 딱 맞는 것 같다.

이번 C에서 얻은 교훈은 이거다.

전체 감소가 있는 문제에서는 실제 값을 계속 바꾸려 하지 말고,
기준값을 따로 두고 각 원소가 그 기준을 달성했는지로 보는 방법을 생각해보자.

5. 이번 대회에서 좋았던 점

1) D를 빠르게 해결했다

C에서 오래 막히기 전에 D를 먼저 풀었고,
재배열 문제를 남은 개수가 가장 많은 문자부터 고르는 방식으로 잘 해결했다.

2) C를 끝까지 포기하지 않았다

C에서 5번 틀렸고, 시간도 90분 넘게 걸렸다.
그래도 결국 관점을 바꿔서 AC까지 갔다.

이건 꽤 의미가 있다.
오늘 C는 그냥 구현 실수 하나 고친 문제가 아니라,
문제를 보는 관점을 바꿔서 해결한 문제였기 때문이다.

3) 취업한 날에도 루틴을 지켰다

어제는 취업한 날이었다.

기분도 붕 뜰 수 있었고,
그냥 쉬어도 이상하지 않은 날이었다.

그래도 평소처럼 앳코더를 했고,
결국 1000점까지 가져왔다.

이건 꽤 기억에 남을 것 같다.

6. 아쉬웠던 점

1) B에서 전환이 조금 늦었다

작은 경우의 수는 빠르게 직접 처리하는 판단도 필요하다.
처음에 너무 일반화하려고 하면서 시간이 조금 더 걸렸다.

2) C에서 방문 체크 관점에 오래 머물렀다

처음 boolean 방문 체크로 생각한 게 오래 발목을 잡았다.
이 문제는 방문 여부가 아니라, 현재 기준 높이 달성 여부를 봐야 했다.

3) C에 시간이 너무 많이 들었다

결과적으로 맞췄지만, C 하나에 90분 넘게 쓴 건 꽤 컸다.
조금 더 빨리 minusidx와 cntarr의 의미를 정리했으면 좋았을 것 같다.

7. 다음 목표

전체 감소가 있는 문제에서는 기준값을 따로 두는 관점을 떠올리기
방문 체크와 달성 여부를 구분하기
작은 경우의 수 문제에서는 하드코딩도 선택지로 두기
C에서 오래 맞아도 멘탈을 놓지 않는 건 유지하기
복잡한 관리 문제에서는 변수의 의미를 먼저 문장으로 정리하고 구현하기

한 줄 정리

ABC 459는 취업한 날에도 앳코더 루틴을 지켰고,
D는 빠르게 해결했지만, C에서 “방문 체크”가 아니라 “기준 높이 달성 카운트”가 필요하다는 걸 깨닫기까지 오래 걸린 대회였다.

앳코더 ABC 458 후기

tkd0711 — Fri, 22 May 2026 13:58:04 +0900

앳코더 ABC 458 후기

tkd0711 · 2026. 5. 16.

AtCoder Beginner Contest 458
https://atcoder.jp/contests/abc458

날짜: 2026-05-16 (Sat)
결과: A~D AC, 1000점
A: 1:25
B: 5:42
C: 13:25
D: 33:07
E: 미해결

1. 전체 느낌

이번 대회는 월요일 면접을 앞두고 참가했다.

사실 컨디션이나 일정상 너무 오래 붙잡고 있을 수는 없었고,
목표도 “끝까지 갈아 넣기”보다는 평소 루틴을 유지하는 쪽에 가까웠다.

결과는 A~D까지 해결해서 1000점.
시간도 D까지 33분 정도라 꽤 깔끔했다.

E는 끝까지 답이 떠오르지 않았지만,
면접 전날 무리해서 더 붙잡기보다는 적당히 끊는 게 맞다고 판단했다.

이번 대회는 전체적으로
A~D를 안정적으로 처리하고, E는 무리하지 않고 접은 대회였다.

2. A, B – 무난한 시작

A와 B는 크게 문제 없이 해결했다.

A는 1분대, B는 5분대에 처리했고,
초반 흐름은 괜찮았다.

최근 들어 A, B는 꽤 안정적으로 풀고 있고,
이번에도 큰 실수 없이 C로 넘어갈 수 있었다.

3. C – C Stands for Center: C를 가운데로 두고 세기

문제 요약

문자열 S가 주어지고,
다음 조건을 만족하는 부분문자열의 개수를 구하는 문제였다.

길이가 홀수
가운데 문자가 C

같은 문자열이라도 뽑힌 위치가 다르면 따로 센다.

접근

이 문제는 비교적 바로 보였다.

어떤 위치 i의 문자가 C라면,
그 문자를 가운데로 하는 홀수 길이 부분문자열을 세면 된다.

가운데가 C로 고정되어 있으므로
왼쪽과 오른쪽으로 같은 길이만큼 뻗을 수 있다.

즉,

왼쪽에 있는 문자 수: i
오른쪽에 있는 문자 수: len - i - 1
가능한 개수: min(왼쪽 개수, 오른쪽 개수) + 1

이다.

여기서 +1은 C 하나만 뽑는 경우다.

자료형

문자열 길이가 최대 50만이므로,
답이 커질 수 있다고 보고 long으로 처리했다.

요즘 계속 자료형에서 맞은 적이 있어서,
이번에는 처음부터 답 변수를 long으로 둔 점이 괜찮았다.

느낀 점

C는 조건을 직접 복잡하게 보지 않고,
“각 C를 가운데로 잡는다”로 바꿔서 보면 쉬운 문제였다.

이런 식으로 중심이 정해지는 문제는
각 위치를 기준으로 몇 개 만들 수 있는지를 세는 방향으로 보는 게 좋다는 걸 다시 확인했다.

4. D – Chalkboard Median: 예전에 푼 중앙값 문제가 도움이 됐다

문제 요약

처음 칠판에 정수 X가 하나 적혀 있고,
각 쿼리마다 정수 두 개를 추가한다.

그때마다 지금까지 칠판에 적힌 수들의 중앙값을 출력하는 문제였다.

항상 원소 개수는 홀수이므로 중앙값이 하나로 정해진다.

접근

이 문제는 예전에 백준에서 “중앙값 구하기” 유형을 풀어본 경험이 바로 떠올랐다.

매번 모든 수를 정렬하면 너무 느리다.
대신 우선순위 큐 두 개를 사용하면 된다.

작은 절반을 담는 큐
큰 절반을 담는 큐

작은 절반 쪽은 가장 큰 값이 위로 오게 하고,
큰 절반 쪽은 가장 작은 값이 위로 오게 한다.

그리고 작은 절반의 크기를 항상 큰 절반보다 하나 크게 유지하면,
작은 절반의 맨 위 값이 중앙값이 된다.

구현

내 코드에서는 이름이 조금 헷갈리긴 했지만, 역할은 다음과 같았다.

minpq: 작은 값들을 담는 쪽, 내림차순
maxpq: 큰 값들을 담는 쪽, 오름차순

새 값이 들어올 때마다
현재 중앙값과 비교해서 알맞은 큐에 넣고,
두 큐의 크기를 다시 맞췄다.

그 뒤 minpq.peek()을 출력했다.

느낀 점

D는 이번 대회에서 가장 기분 좋게 풀린 문제였다.

처음 보는 유형이었다면 조금 헤맸을 수도 있는데,
전에 풀어본 중앙값 유지 문제가 바로 떠올라서 빠르게 접근할 수 있었다.

역시 예전에 풀어본 문제가 실전에서 바로 연결될 때가 있다.

이번 D는
이전에 풀었던 문제 경험이 실전에서 제대로 도움이 된 문제였다.

5. E – Count 123: 재귀로는 안 되는 문제였다

문제 요약

1, 2, 3으로 이루어진 수열을 만든다.

1은 X1개
2는 X2개
3은 X3개

정확히 사용해야 하고,
인접한 두 원소의 차이가 1 이하가 되어야 한다.

즉 1과 3은 바로 붙을 수 없다.
그런 수열의 개수를 구하는 문제였다.

처음 생각

처음에는 재귀로 생각했다.

현재까지 놓은 마지막 숫자를 보고,
다음에 1, 2, 3 중 가능한 것을 선택하는 방식이다.

하지만 X1, X2, X3가 최대 100만이므로,
이런 식의 재귀나 단순 메모이제이션으로는 절대 안 된다.

핵심 관찰까지는 갔다

그래도 문제를 보면서 하나는 보였다.

1과 3은 서로 바로 붙을 수 없고,
2가 둘 사이를 이어주는 역할을 한다.

즉 2가 완충 역할을 한다는 점이다.

하지만 여기서 더 나아가
정확한 조합식이나 세는 구조까지는 만들지 못했다.

왜 접었는가

월요일 면접을 앞두고 있었고,
이미 A~D를 33분 정도에 해결한 상태였다.

E를 더 붙잡으면 한참 더 고민해야 할 것 같았고,
그게 오늘의 목적과는 조금 다르다고 생각했다.

그래서 E는
“재귀로는 안 되고, 1과 3 사이에 2를 어떻게 배치할지를 세는 문제였을 것이다”
정도까지만 정리하고 멈췄다.

느낀 점

E는 못 풀었지만,
완전히 손도 못 댄 문제는 아니었다.

적어도

재귀는 안 된다
1과 3이 바로 붙을 수 없다는 게 핵심이다
2의 배치가 중요하다

까지는 봤다.

다만 아직 이런 조합 세기 문제는
정확한 식으로 정리하는 힘이 부족하다고 느꼈다.

6. 이번 대회에서 좋았던 점

1) A~D를 빠르게 정리했다

D까지 33분 정도에 해결했다.
면접 전 컨디션을 생각하면 꽤 괜찮은 결과였다.

2) C에서 long을 자연스럽게 사용했다

최근 자료형 실수로 많이 맞았는데,
이번 C에서는 답이 커질 수 있다는 걸 보고 바로 long으로 처리했다.

3) D에서 예전 경험을 잘 활용했다

중앙값 유지 문제를 풀어본 경험이 바로 떠올랐고,
두 개의 우선순위 큐로 안정적으로 해결했다.

4) 무리하지 않고 끊었다

E가 안 보였지만,
면접을 앞두고 무리하게 뇌를 갈아 넣지 않고 적당히 멈췄다.

이번에는 이것도 중요한 판단이었다.

7. 아쉬웠던 점

1) E의 조합 구조를 끝까지 못 만들었다

1과 3이 붙을 수 없고 2가 중요하다는 관찰은 했지만,
그걸 식으로 정리하지는 못했다.

2) D 코드를 더 깔끔하게 만들 수는 있었다

우선순위 큐 두 개를 사용하는 구조는 맞았지만,
큐 이름이나 균형을 맞추는 부분은 조금 더 정리할 수 있었을 것 같다.

대회 중에는 맞추는 게 우선이었으니 큰 문제는 아니지만,
나중에 다시 보면 더 깔끔하게 쓸 수 있을 것 같다.

8. 다음 목표

조합 세기 문제에서 작은 관찰을 식으로 바꾸는 연습하기
“붙으면 안 되는 쌍”이 있는 문제를 배치 문제로 바꿔 보는 연습하기
우선순위 큐 두 개로 중앙값 유지하는 코드는 더 깔끔한 형태로 익혀두기
면접이나 다른 일정이 있을 때는 무리하지 않고 적당히 끊는 것도 실력으로 보기

한 줄 정리

ABC 458은 면접을 앞두고도 A~D를 33분에 정리했고,
E는 못 풀었지만 무리하지 않고 멈춘 대회였다.

앳코더 ABC 457 후기

tkd0711 — Sat, 9 May 2026 23:03:04 +0900

앳코더 ABC 457 후기

tkd0711 · 2026. 5. 9.

Polaris.AI Programming Contest 2026 (AtCoder Beginner Contest 457)
https://atcoder.jp/contests/abc457

날짜: 2026-05-09 (Sat)
결과: A~D AC, 1000점
A: 2:08
B: 5:01
C: 28:19, 3틀
D: 69:58, 1틀

1. 전체 느낌

이번 대회는 결과만 보면 A~D를 풀어서 1000점이었다.

A, B는 무난하게 처리했고,
C에서 크게 말렸다.
D는 한 번 틀렸지만, 방향 자체는 바로 잡아서 결국 해결했다.

체감상 가장 아쉬웠던 건 C였다.
예전에 cnt 변수를 long으로 안 둬서 틀린 적이 있어서,
그 뒤로 누적 변수는 꽤 신경 쓰고 있었다.

그런데 이번에는 아예 입력받는 K부터 long으로 처리하지 않아서 틀렸다.
즉, 누적 변수만 조심할 게 아니라
처음 변수 선언부터 자료형을 제대로 봐야 한다는 걸 다시 배운 대회였다.

2. A, B – 무난한 시작

A와 B는 크게 문제 없이 해결했다.

A는 2분대, B는 5분대에 처리했고,
초반 흐름은 나쁘지 않았다.

이번 대회가 아쉽게 느껴지는 건
초반 문제 때문이 아니라 C에서 자료형 문제로 시간을 크게 쓴 것 때문이다.

3. C – Long Sequence: K부터 long이어야 했다

문제 요약

여러 개의 수열 A_i가 있고,
각 수열을 C_i번 반복해서 하나의 긴 수열 B를 만든다.

이때 실제로 B를 만들 수는 없으므로,
K번째 원소가 어느 수열의 어느 위치에 해당하는지 찾아야 하는 문제였다.

접근

풀이 자체는 어렵지 않았다.

각 수열마다 기여하는 길이는

C_i * L_i

이고,
이 값을 앞에서부터 누적하다가 K가 들어가는 구간을 찾으면 된다.

해당 구간을 찾은 뒤에는
그 수열 안에서 몇 번째 원소인지 나머지 연산으로 구하면 된다.

즉 구조는:

각 수열의 길이 L_i 저장
반복 횟수 C_i 저장
C_i * L_i를 누적
K가 현재 구간 안에 들어오면 위치 계산
해당 원소 출력

이었다.

실수한 부분

문제는 자료형이었다.

C_i는 최대 10^9이고,
수열 길이와 곱한 값의 누적은 int 범위를 훨씬 넘을 수 있다.

따라서

K
현재까지 누적한 길이
C_i * L_i

는 전부 long이어야 했다.

그런데 처음에는 K를 int로 읽었다.
이 때문에 런타임 에러가 계속 났고,
나는 그 원인을 나머지 연산 쪽 문제라고 생각해서 식을 계속 고쳤다.

하지만 진짜 원인은 더 앞에 있었다.
입력받는 순간부터 자료형이 틀렸던 것이다.

교훈

예전에는 cnt 변수를 long으로 안 해서 틀린 적이 있었다.
그래서 이후로 누적 변수는 조심하려고 했다.

그런데 이번에는 그보다 더 앞단계인
입력 변수 선언부터 long이어야 하는 경우를 놓쳤다.

앞으로는 다음 조건이 보이면 처음부터 long을 의심해야 한다.

K가 위치를 뜻하는 경우
전체 길이가 반복 횟수와 곱해지는 경우
C_i * L_i 같은 곱셈이 있는 경우
실제 배열을 만들 수 없을 정도로 길이가 커지는 경우

이번 C는 풀이를 몰라서 틀린 문제가 아니라,
자료형 확인을 늦게 해서 시간을 잃은 문제였다.

4. D – Raise Minimum: 최소의 최대는 이분탐색

문제 요약

수열 A가 있고,
최대 K번 연산할 수 있다.

한 번의 연산에서는 인덱스 i를 골라
A_i에 i를 더할 수 있다.

이때 최종적으로 만들 수 있는
min(A_i)의 최댓값을 구하는 문제였다.

접근

문제를 보자마자
“최소값의 최대”라는 형태가 보였다.

이런 문제는 보통
정답을 직접 구하기보다,

어떤 값 X 이상으로 모든 원소를 만들 수 있는가?

를 판정하고,
그 X를 이분탐색하면 된다.

그래서 목표값 num을 정하고,
각 A_i를 num 이상으로 만들기 위해 필요한 연산 횟수를 계산했다.

A_i < num일 때 필요한 횟수는:

ceil((num - A_i) / i)

이다.

모든 원소에 대해 필요한 연산 횟수를 더해서
그 값이 K 이하이면 num은 가능하고,
아니면 불가능하다.

한 번 틀린 이유

처음 판정 함수에서는 필요한 연산 횟수 cnt를 끝까지 계속 더했다.

cnt += plz;

그런데 num이 매우 크면
필요한 연산 횟수의 합이 long 범위를 넘을 수 있다.

사실 판정 함수에서 필요한 건
정확한 총합이 아니라

K를 넘는지 아닌지

뿐이다.

그래서 정답 코드에서는 다음처럼 고쳤다.

cnt += plz;
if (cnt > k) break;

K를 넘는 순간 더 계산할 필요가 없고,
이렇게 하면 오버플로도 막을 수 있다.

느낀 점

D는 방향 자체는 좋았다.

“최소의 최대”를 보고 바로 이분탐색을 떠올렸고,
판정 함수도 거의 맞게 세웠다.

다만 누적값이 커질 수 있는 경우에는
끝까지 더하지 말고 기준을 넘는 순간 멈춰야 한다는 점을 다시 확인했다.

5. 이번 대회에서 좋았던 점

1) A, B는 무난했다

초반 문제에서 크게 흔들리지 않았다.

2) C에서 말렸지만 D까지 복구했다

C에서 자료형 문제로 시간을 크게 썼지만,
거기서 완전히 무너지지 않고 D를 해결했다.

3) D의 방향을 잘 잡았다

“최소의 최대”를 보고 이분탐색으로 들어간 판단은 좋았다.

6. 아쉬웠던 점

1) C에서 K를 int로 읽은 것

이번 대회에서 가장 큰 실수였다.

누적 변수는 조심하고 있었지만,
정작 입력받는 변수 자체를 long으로 봐야 한다는 걸 놓쳤다.

2) 자료형 문제를 나머지 연산 문제로 착각한 것

런타임 에러가 났을 때
원인을 잘못 짚어서 시간을 더 썼다.

앞으로는 나머지 식을 고치기 전에
입력 자료형과 누적 자료형부터 먼저 확인해야 한다.

3) D 판정 함수에서 누적합을 끝까지 더한 것

판정 함수에서는 필요한 기준을 넘는 순간 멈춰도 된다.
이걸 더 빨리 떠올렸으면 한 번 틀리지 않았을 것 같다.

7. 다음 목표

K가 위치나 길이를 뜻하면 처음부터 long으로 읽기
반복 횟수와 길이의 곱은 무조건 1L * 붙이기
누적 길이, 누적 횟수, 필요한 연산 수는 전부 long 의심하기
판정 함수에서는 기준을 넘는 순간 바로 중단하기
런타임 에러가 나면 나머지 식보다 먼저 자료형 확인하기

한 줄 정리

ABC 457은 C에서 K를 처음부터 long으로 처리하지 않아 크게 말렸지만,
D에서 이분탐색으로 복구해 1000점까지 가져온 대회였다.

앳코더 ABC 456 후기

tkd0711 — Sat, 2 May 2026 23:06:09 +0900

앳코더 ABC 456 후기

tkd0711 · 2026. 5. 2.

AtCoder Beginner Contest 456
https://atcoder.jp/contests/abc456

날짜: 2026-05-02 (Sat)
결과: A~D AC, E 도전
B: 1틀
C: 1틀
D: 비교적 빠르게 해결
E: 끝까지 고민해봄

1. 전체 느낌

이번 대회는 전체적으로 나쁘지 않았다.

A부터 D까지는 결국 다 풀었고,
E도 아예 손도 못 댄 게 아니라 끝까지 고민은 해봤다.

특히 이번 대회는

B에서 단순한 구현 실수
C에서 마지막 나머지 연산 실수
D는 구조가 빨리 보였음
E는 방향은 있었지만 끝까지 확신은 못 잡음

이런 식으로 정리할 수 있을 것 같다.

완벽한 대회는 아니었지만,
그래도 D까지 깔끔하게 마무리했고, E도 그냥 넘기지 않고 끝까지 붙잡아본 점은 괜찮았다.

2. A – 무난한 시작

A는 큰 문제 없이 넘어갔다.

요즘처럼 A는 초반 흐름을 잡는 문제라는 느낌이고,
이번에도 스타트 자체는 나쁘지 않았다.

3. B – 풀이 방향은 맞았는데, 단순한 인덱스 실수로 한 번 틀림

문제 요약

주사위 3개를 동시에 굴렸을 때,
나온 값이 4, 5, 6이 정확히 한 번씩 나올 확률을 구하는 문제였다.

접근

처음에는 각 주사위에서

4가 몇 면 있는지
5가 몇 면 있는지
6이 몇 면 있는지

를 세고,
(4,5,6)의 순서를 바꾼 6가지 경우를 전부 더하면 되겠다고 생각했다.

이 발상 자체는 맞았다.

왜 처음 틀렸는가

문제는 구현에서 있었다.

처음 코드에서는 세 주사위 값을 꺼낼 때

첫 번째 주사위
두 번째 주사위
세 번째 주사위

를 써야 하는데,
실수로 전부 첫 번째 주사위에서만 값을 꺼내고 있었다.

즉, 아이디어가 틀린 게 아니라
그냥 인덱스를 잘못 쓴 단순한 구현 실수였다.

느낀 점

이런 문제는 더 아쉽다.

풀이 방향은 맞았는데
배열 인덱스 하나 잘못 써서 틀리면 체감상 더 허무하다.

작은 문제일수록
오히려 “입력을 내가 제대로 읽고 있나?”를 더 조심해야겠다는 생각이 들었다.

4. C – 거의 다 맞았는데 마지막 mod 한 번을 빼먹음

문제 요약

문자열의 부분문자열 중에서
서로 이웃한 두 문자가 같은 경우가 없는 것의 개수를 구하는 문제였다.
정답은 998244353으로 나눈 나머지를 출력해야 했다.

접근

이 문제는 비교적 바로 보였다.

현재 위치에서 끝나는 좋은 부분문자열 개수를 plus라고 두고,

이전 문자와 다르면 plus++
이전 문자와 같으면 plus=1

이렇게 관리하면
각 위치에서 끝나는 경우의 수를 차례로 더할 수 있었다.

즉, 연속해서 다른 문자가 이어지는 길이를 세면서 누적하는 문제였다.

왜 처음 틀렸는가

처음 제출한 코드는 거의 맞았는데,
마지막에 전체 답을 mod로 한 번 더 줄이는 부분을 빼먹었다.

중간 계산에서 나머지 연산을 하고 있었더라도,
최종 출력값도 반드시 mod를 적용해야 했다.

느낀 점

이건 알고리즘 실수라기보다
마무리 점검 실수였다.

나머지 연산 문제에서는 항상

중간값에 mod 했는지
마지막 출력도 mod 했는지

이 두 개를 같이 확인해야 한다는 걸 다시 느꼈다.

5. D – 상태를 바로 잡아서 비교적 빠르게 해결

문제 요약

문자열의 부분수열 중에서
서로 이웃한 두 문자가 같은 경우가 없는 것의 개수를 구하는 문제였다.
역시 998244353으로 나눈 나머지를 출력해야 했다.

접근

C가 부분문자열이었다면,
D는 부분수열이라 접근이 달랐다.

여기서는 상태를

현재 위치 idx
직전에 선택한 문자 prv

로 두고,

현재 문자를 선택하는 경우
선택하지 않는 경우

로 나누면 되겠다고 바로 생각했다.

즉, 탑다운 메모이제이션으로

현재 문자가 이전 문자와 다르면 선택 가능
선택하지 않는 경우는 언제나 가능

이런 식으로 정리했다.

느낀 점

D는 문제를 보자마자 구조가 비교적 빨리 보인 편이었다.

현재 위치와 직전 문자 상태를 두는 방식이 바로 떠올랐고,
그 뒤에는 선택/비선택으로 무난하게 밀고 갈 수 있었다.

이번 대회에서 가장 편하게 풀린 문제는 D였던 것 같다.

6. E – 확신 있는 정답 구조까지는 못 갔지만, 끝까지 도전은 해봤다

문제 요약

도시마다 요일별 휴일 정보가 있고,
밤마다 이동하거나 머물면서
매일 정오에 있는 도시가 항상 휴일이 되도록 무한히 계속할 수 있는지 판별하는 문제였다.
요일 수 W는 최대 10이었다.

내가 본 방향

문제를 보면서
요일 수가 작으니까 상태를

현재 도시
현재 요일

정도로 두고 볼 수 있겠다고 생각했다.

즉 도시만 보는 게 아니라
(도시, 요일) 상태 그래프로 보려는 방향까지는 갔다.

왜 끝까지 확신을 못 잡았는가

문제는
무한히 계속 가능하다는 조건을 내가 완전히 짧고 확실하게 정리하지 못했다는 점이었다.

처음에는 시작 도시에서 한 바퀴 돌아서
다시 시작점으로 올 수 있는지 같은 식으로 생각했는데,
나중에 보니 핵심은 그게 아니라
상태 그래프 전체에 순환이 존재하는지를 보는 문제였다.

즉 방향은 어느 정도 맞았지만,
조건을 정확하게 끝까지 정리하지 못해서 확신 있는 정답으로 못 밀어붙였다.

그래도 의미 있었던 점

그래도 이번 E는
완전히 감도 못 잡은 문제는 아니었다.

도시만 보면 안 되고
요일까지 포함한 상태를 봐야 하고
결국 그래프의 순환 여부를 보는 문제라는 방향까지는 갔다

이런 점에서
다음에 비슷한 문제가 나오면 훨씬 빨리 접근할 수 있을 것 같다.

즉 이번 E는 못 풀긴 했지만,
그냥 손도 못 댄 문제와는 좀 달랐다.

7. 이번 대회에서 좋았던 점

1) B, C에서 틀렸지만 빠르게 복구했다

둘 다 큰 발상 실수는 아니었고,
구현/마무리 실수를 바로 잡았다.

2) D는 구조를 빨리 봤다

현재 위치와 이전 문자 상태를 두는 방식이 비교적 자연스럽게 떠올랐다.

3) E도 끝까지 붙잡아봤다

맞추진 못했지만, 상태 그래프 방향까지는 생각해봤다는 점에서 의미가 있었다.

8. 아쉬웠던 점

1) B는 너무 단순한 구현 실수였다

아이디어보다 구현에서 틀린 문제라 더 아쉽다.

2) C는 마지막 mod 한 번을 빼먹었다

이런 마무리 실수는 진짜 줄여야 한다.

3) E는 방향은 있었는데 끝까지 확신을 못 만들었다

이런 문제를 나중에는 더 짧고 명확하게 정리할 수 있어야 할 것 같다.
사이클 탐지 , SCC 키워드를 얻어갔다

9. 다음 목표

작은 문제일수록 구현 실수 줄이기
mod 문제에서는 마지막 출력까지 꼭 확인하기
상태 그래프 문제에서
“무한히 가능”이 결국 무엇을 뜻하는지 더 정확히 정리하기
못 푼 문제라도
방향까지는 잡아보는 연습 계속하기

한 줄 정리

ABC 456은 B와 C에서 구현 실수가 있었지만 빠르게 복구했고,
D는 구조를 잘 봤고, E도 맞추진 못했지만 끝까지 방향을 고민해본 대회였다.

앳코더 ABC 455 후기

tkd0711 — Sat, 25 Apr 2026 23:08:06 +0900

앳코더 ABC 455 후기

tkd0711 · 2026. 4. 25.

Ｓｋｙ Inc, Programming Contest 2026 (AtCoder Beginner Contest 455)
https://atcoder.jp/contests/abc455

날짜: 2026-04-25 (Sat)
B가 가장 오래 걸림
C는 비교적 바로 해결
D는 18분 정도 걸려 해결

1. 전체 느낌

이번 대회는 전체적으로 보면 A는 무난했고,
B에서 예상보다 크게 말렸다.
C는 문제를 보자마자 방향이 바로 보이는 편이었고,
D는 처음엔 조금 관찰이 필요했지만 구조를 본 뒤에는 비교적 빠르게 정리했다.

특히 이번 대회는
어려운 알고리즘을 몰라서 막혔다기보다는,

B에서 문제를 처음 잘못 읽은 것
단순 완전탐색을 의심하느라 시간을 더 쓴 것

이 두 가지가 가장 아쉬웠다.

2. A – 무난한 시작

A는 큰 문제 없이 넘어갔다.

이제 A는 예전처럼 긴장되는 구간이라기보다
초반 흐름을 잡는 문제라는 느낌이 더 강하다.
이번에도 스타트 자체는 나쁘지 않았다.

3. B – 문제를 잘못 읽고, 할 수 있는 완전탐색을 의심해서 시간 손해

문제 요약

격자에서 직사각형 구간을 하나 잡았을 때,
그 구간이 점대칭으로 같은 색 배치를 이루는지 확인하고
그런 직사각형 개수를 세는 문제였다.
제한은 H, W ≤ 10이었다.

처음 꼬인 이유

처음 문제를 잘못 읽었고,
그 뒤에 완전탐색으로 가면 될 것 같은데도
“이게 진짜 6중 반복문으로 되는 게 맞나?”를 의심하면서 시간이 더 갔다.

실제로는 제한이 매우 작아서,

직사각형의 위쪽
아래쪽
왼쪽
오른쪽

을 전부 정하고,
그 안의 각 칸이 점대칭 위치와 같은 색인지 확인하면 되는 문제였다.

즉, 구현은 길어 보여도
제한이 작기 때문에 그냥 밀어붙이면 되는 문제였다.

왜 더 아쉬웠는가

이 문제는 아이디어가 어려운 게 아니었다.

처음에 문제를 잘못 읽은 것
그 뒤에 할 수 있는 완전탐색을 스스로 의심한 것
디버깅하다가 흐름이 꼬인 것

이 세 가지가 겹쳐서 시간이 많이 들었다.

회고를 하면서 느낀 건,
이런 문제는 “이게 진짜 되나?”를 오래 고민할수록 손해라는 것이다.

제한이 충분히 작으면
애매하게 의심하기보다 그냥 구현하는 쪽이 나았다.

교훈

이번 B의 핵심 교훈은 이거였다.

제한이 아주 작을 때는
완전탐색을 괜히 불안해하지 말고 먼저 구현해보는 편이 낫다.

특히 이번처럼 H, W ≤ 10이면
반복문 개수가 많아 보여도 실제 연산량은 충분히 가능할 수 있다.

4. C – 바로 보이는 문제는 깔끔하게 처리하자

문제 요약

수열에서 값을 하나 골라,
그 값을 가진 모든 원소를 0으로 바꾸는 연산을 정확히 K번 했을 때
전체 합의 최솟값을 구하는 문제였다.
A_i의 값 범위는 최대 10^9라서 배열 대신 다른 구조가 필요했다.

접근

이 문제는 비교적 바로 보였다.

핵심은 같은 값을 한 번 고르면
그 값을 가진 원소들이 전부 0이 된다는 점이다.
즉 중요한 건 각 값이 몇 번 나왔는지가 아니라,
그 값이 전체 합에 얼마를 기여하는지였다.

그래서:

해시맵으로 각 값별 총합을 모은다.
그 총합이 큰 값부터 K개 없앤다.
나머지 총합을 더하면 답이 된다.

이 방식으로 해결했다.

느낀 점

이 문제는 숫자 범위가 크기 때문에
배열 대신 해시맵을 써야 한다는 점만 바로 잡으면 비교적 단순했다.

즉,

값 범위가 크다 → 배열 대신 해시맵
같은 값은 한 번에 사라진다 → 값별 총합만 보면 된다

이렇게 정리하면 금방 풀 수 있었다.

5. D – 관찰이 되자마자 구조가 보였던 문제

문제 요약

카드 더미들이 있고,
어떤 카드 C_i와 그 위의 카드 전부를
다른 카드 P_i 위로 옮기는 연산을 반복한 뒤,
최종적으로 각 더미의 카드 수를 구하는 문제였다.

처음 생각

처음엔 링크드 리스트처럼 구현하면 되겠다고 봤다.

왜냐하면 이 문제는 실제로 필요한 정보가:

내 위에 누가 있는지
내 아래에 누가 있는지
어떤 카드가 더미의 맨 위인지

이런 연결 정보였기 때문이다.

즉 배열 여러 개로

위쪽 연결
아래쪽 연결
머리 카드 여부

를 관리하면 될 것 같다고 생각했다.

핵심 관찰

문제를 조금 보고 나서
a와 b의 관계를 정리하니까 구조가 금방 보였다고 느꼈다.

카드를 옮긴다는 것은 결국
중간 연결을 끊고 다시 이어 붙이는 작업이다.
그래서 실제 카드 순서를 전부 시뮬레이션하는 것이 아니라,
연결만 바꾸면 된다고 볼 수 있었다.

구현

구현에서는 카드들의 위/아래 관계를 배열로 관리하고,
모든 연산이 끝난 뒤 각 더미의 머리 카드에서부터 아래로 따라가며 카드 수를 세는 방식으로 정리했다.

느낀 점

D는 처음엔 조금 관찰이 필요했지만,
핵심 구조를 본 뒤에는 비교적 빨리 해결할 수 있었다.

이번 D에서 좋았던 건
괜히 복잡한 자료구조를 찾기보다
“이건 연결 관계만 관리하면 된다”는 쪽으로 정리한 점이었다.

6. 이번 대회에서 좋았던 점

1) C, D는 비교적 잘 풀었다

C는 빠르게 구조를 잡았고,
D도 관찰 뒤에는 비교적 빨리 정리했다.

2) 값 범위가 큰 문제에서 해시맵을 자연스럽게 떠올렸다

C에서 배열 대신 해시맵으로 가는 판단은 좋았다.

3) D에서 연결 구조로 보는 감각이 있었다

카드 쌓기 문제를 순수 구현으로 보기보다
연결 관계 문제로 바꿔 본 게 괜찮았다.

7. 아쉬웠던 점

가장 아쉬운 건 역시 B였다.

처음 문제를 잘못 읽었고
완전탐색을 의심하다가 시간을 더 썼고
디버깅하다가 흐름까지 꼬였다.

즉 이번 대회는
문제를 몰라서 못 푼 느낌보다는,

할 수 있는 문제를 괜히 의심해서 시간을 더 쓴 대회

에 가까웠다.

8. 다음 목표

제한이 작은 문제에서는
반복문 개수가 많아 보여도 실제 연산량을 먼저 계산해보기
완전탐색이 가능하면
괜히 겁먹지 말고 바로 구현하기
문제를 처음 잘못 읽었을 때
코드만 고치지 말고 문제 모델부터 다시 보기
연결 관계 문제는
실제 시뮬레이션보다 포인터/배열 연결로 바꿔 볼 것

한 줄 정리

ABC 455는 B에서 괜히 완전탐색을 의심하며 시간을 쓴 것이 가장 아쉬웠고,
C와 D는 구조를 비교적 잘 잡아서 해결한 대회였다.

앳코더 ABC 454 후기 - 그린 달성!!!!!!!

tkd0711 — Sun, 19 Apr 2026 00:13:07 +0900

앳코더 ABC 454 후기

tkd0711 · 2026. 4. 18.

Keysight Technologies Programming Contest (AtCoder Beginner Contest 454)
https://atcoder.jp/contests/abc454

날짜: 2026-04-18 (Sat)
결과: A~D AC (1025점)
A: 0:48
B: 4:20
C: 18:21, 1틀
D: 56:07, 1트
레이팅: 821
드디어 그린 달성

1. 전체 느낌

이번 대회는 결과도 좋았고, 체감도 좋았다.

A, B를 빠르게 처리했고,
C는 한 번 삽질하긴 했지만 방향을 바로 고쳐서 해결했다.
그리고 D를 결국 원트로 끝냈다.

무엇보다 이번 대회의 가장 큰 의미는
레이팅 821로 그린에 진입했다는 점이다.

그동안 회고를 쓰면서
문제 독해 실수, 자료형 실수, D에서 끝까지 못 정리하던 문제들을 계속 복기해왔는데,
이번에는 그 흐름이 실제 결과로 이어진 느낌이었다.

2. A, B – 안정적인 시작

A와 B는 비교적 무난하게 풀었다.

최근 대회들처럼 초반 문제는 안정적으로 처리되고 있고,
이번에도 A/B에서 크게 말리지 않았다.

ABC에서 중요한 건 초반 문제를 빠르게 넘기고 C, D에 사고 시간을 확보하는 건데,
이번에는 그 부분이 잘 됐다.

3. C – Straw Millionaire: 최대값 문제가 아니라 도달 가능 문제였다

문제 요약

처음에는 아이템 1만 가지고 있다.
각 친구에게 특정 아이템 A_i를 주면 B_i를 받을 수 있다.
이 과정을 반복해서 얻을 수 있는 아이템 종류 수를 구하는 문제였다.

처음 접근

처음에는
“한 번에 얻을 수 있는 최대값”처럼 생각해서 DFS로 접근했다.

그런데 이건 최적화 문제가 아니라,
사실상 1번 아이템에서 출발해서 도달 가능한 정점 수를 세는 문제였다.

그래프처럼 보면:

아이템 = 정점
A_i -> B_i = 간선

이 되고,
1번에서 갈 수 있는 곳의 개수를 세면 끝이었다.

왜 처음 DFS가 별로였는가

첫 DFS 구현에서는 방문 배열을 재귀가 끝날 때 다시 false로 돌리는 식으로 짰다.

이렇게 하면
같은 정점을 여러 경로에서 계속 다시 방문하게 되고,
문제 구조상 필요 없는 탐색이 많아진다.

그래서 이 문제는 백트래킹 DFS가 아니라,

한 번 방문한 정점은 다시 안 보고
BFS나 일반 DFS로 퍼지는 식

으로 가야 했다.

최종 풀이

최종적으로는 BFS로 바꿨다.

시작점 1을 큐에 넣고
한 번 방문한 아이템은 다시 넣지 않고
도달 가능한 모든 정점을 탐색

이 방식으로 해결했다.

교훈

이번 C의 핵심은 이거였다.

“최대 몇 개를 얻을 수 있느냐”가 아니라
“1번에서 어디까지 갈 수 있느냐” 문제였다.

즉 경로를 따지는 문제로 보기보다,
그래프 탐색 문제로 보는 게 맞았다.

4. D – (xx): 막막했지만 형태를 줄여서 비교하는 문제였다

문제 요약

문자열 A와 B가 주어진다.
가능한 연산은:

(xx) -> xx
xx -> (xx)

이 두 가지다.

이 연산을 반복해서 A를 B로 만들 수 있는지 판별하는 문제였다.

처음 느낌

처음엔 꽤 막막했다.

괄호를 그냥 다 지우면 되나?
올바른 괄호쌍처럼 봐야 하나?
xx를 기준으로 양옆을 봐야 하나?

이런 식으로 생각이 여러 방향으로 퍼졌다.

핵심 관찰

결국 이 문제의 핵심은
xx를 중심으로 감싸진 괄호들은 있어도 되고 없어도 된다는 점이었다.

즉 (xx)는 xx와 같게 만들 수 있고,
그 바깥 괄호도 같은 식으로 계속 없앨 수 있다.

그래서 각 문자열에서

xx를 찾고
거기서 좌우로 (, )가 짝을 이루며 감싸는 부분을 전부 표시해서 제거한 뒤
마지막에 남는 문자열 모양이 같은지만 보면 된다.

내 풀이

구현에서는:

문자열 안에서 xx를 찾고
그 xx를 중심으로 좌우를 확장하면서
지울 수 있는 괄호를 표시한 다음
두 문자열에서 그런 괄호를 다 제거하고
남는 문자 배열을 비교했다.

왜 맞는가

결국 이 연산으로 바뀔 수 있는 건
xx를 둘러싼 괄호층뿐이다.

그래서 두 문자열이 같은 형태로 줄어들면 Yes,
아니면 No가 된다.

느낀 점

처음엔 막막했는데,
중간에

“괄호를 다 없애고 남는 모양을 보면 되는 거 아님?”

이 방향으로 간 게 핵심이었다.

완전히 정석 풀이를 처음부터 본 건 아니었지만,
구조를 잘 줄여서 원트로 마무리한 게 좋았다.

5. 이번 대회에서 좋았던 점

1) A/B가 안정적이었다

초반 문제에서 크게 흔들리지 않았다.

2) C에서 방향 교정이 빨랐다

처음엔 DFS로 잘못 접근했지만,
도달 가능 문제라는 걸 보고 바로 BFS로 바꿨다.

3) D를 원트로 끝냈다

시간은 56분 정도 걸렸지만,
방향을 잡은 뒤에는 한 번에 맞췄다.

4) 드디어 그린 달성

이번 대회의 가장 큰 성과는 결국 이거다.

레이팅 821로 그린에 진입했고,
그동안 쌓아온 회고와 복기가 실제 결과로 이어졌다는 점이 가장 만족스럽다.

6. 아쉬웠던 점

아쉬운 점이 아예 없는 대회는 아니었다.

1) C에서 처음 문제를 잘못 봤다

최대값 문제처럼 생각해서 DFS로 간 건 불필요한 우회였다.

2) D에 시간이 꽤 들었다

원트이긴 했지만, 막막한 구간이 길었다.
좀 더 빨리 구조를 정리했으면 더 좋았을 것 같다.

7. 다음 목표

그래프 문제에서
“최대/최적화”처럼 보여도 도달 가능 문제인지 먼저 보기
문자열 문제에서
직접 시뮬레이션하려 들기보다 줄였을 때 남는 핵심 형태가 무엇인지 먼저 생각하기
D를 맞추는 것에서 끝나지 않고,
D를 더 빨리 정리할 수 있는 단계로 가기
그린 진입에 만족하지 않고,
이제는 그린을 안정적으로 유지하기

한 줄 정리

ABC 454는 A~D를 모두 해결했고,
C에서 방향을 바로 고쳐 잡고 D를 원트로 끝내면서 결국 그린까지 달성한 대회였다.

앳코더 ABC 453 후기

tkd0711 — Sun, 12 Apr 2026 12:45:06 +0900

앳코더 ABC 453 후기

tkd0711 · 2026. 4. 11.

AtCoder Beginner Contest 453
https://atcoder.jp/contests/abc453

날짜: 2026-04-11 (Sat)
결과: A~D AC (1025점)
A: 2:29
B: 6:31
C: 13:45
D: 80:43, 1트

1. 전체 느낌

이번 대회는 결과만 보면 꽤 만족스러웠다.

A, B를 무난하게 처리했고,
C도 빠르게 정리했다.
무엇보다 D를 결국 풀었다는 점이 가장 크다.

시간은 오래 걸렸지만,
한 번 방향을 잡은 뒤 원트로 마무리했다는 점에서 의미가 있었다.

즉 이번 대회는

C까지는 꽤 깔끔했고
D에서 오래 고민했지만
끝까지 밀어붙여서 AC한 대회

였다.

2. A, B – 안정적인 시작

A와 B는 큰 문제 없이 해결했다.

최근처럼 초반 문제는 비교적 안정적으로 풀리고 있고,
이번에도 A/B에서 크게 흔들리지 않았다.

ABC에서 중요한 건
초반 문제를 빠르게 넘기고 C, D에 사고 시간을 확보하는 건데,
이번에는 그 흐름이 잘 나왔다.

3. C – 완전탐색으로 바로 내려온 판단이 좋았음

문제 요약

시작 위치가 0.5이고,
총 N번 이동하면서 매번 왼쪽 또는 오른쪽으로 L_i만큼 움직인다.
이때 좌표 0을 지나는 횟수의 최댓값을 구하는 문제였다.

제한은 N ≤ 20이었다.

접근

문제를 보자마자 핵심은 바로 보였다.

매 이동마다 선택지는 2개
N ≤ 20
그럼 경우의 수는 2^N

즉 완전탐색이 가능했다.

그래서 DFS로

현재 몇 번째 이동인지
현재 위치가 어디인지
지금까지 0을 지난 횟수가 몇 번인지

를 상태로 두고 전부 탐색했다.

구현

현재 위치를 x로 두고,

왼쪽으로 가는 경우
오른쪽으로 가는 경우

두 갈래를 전부 DFS로 내려가면서
0을 지나는 순간만 카운트했다.

문제에서
“좌표 0에서 끝나는 이동은 없다”고 보장되어 있어서,
부호만 비교해도 충분했다.

느낀 점

이 문제는 사실상
제한을 보고 바로 완전탐색으로 내려올 수 있느냐가 핵심이었다.

복잡한 DP나 수학으로 볼 필요 없이,
N ≤ 20이라는 제약을 보고 2^N이 가능하다는 판단을 빨리 한 게 좋았다.

조금 더 깔끔하게 하려면
시작점을 0.5 대신 전체를 2배 해서 정수로 처리하는 방법도 있었겠지만,
이번 구현도 충분히 맞는 방향이었다.

4. D – 상태 설계는 맞았고, 구현을 끝까지 밀어붙여서 AC

문제 요약

격자에서 상하좌우로 이동하는데,
칸의 종류에 따라 다음 이동 방향 제약이 달라진다.

.: 자유 이동
o: 직전 방향과 같은 방향으로만 이동
x: 직전 방향과 같은 방향으로는 이동 불가
#: 벽
S, G: 시작점과 도착점

도달 가능 여부를 판별하고,
가능하면 실제 경로를 출력하는 문제였다.

처음 생각한 핵심

처음 문제를 읽고 제일 먼저 든 생각은 이거였다.

단순 2차원 방문으로는 안 된다
이전에 어떤 방향으로 왔는지가 중요하다
즉 상태는 (i, j, lastDir) 이어야 한다

이 판단은 맞았다.

실제로 o, x 칸은
같은 칸이라도 “어느 방향으로 들어왔는지”에 따라 다음 이동 가능 여부가 달라지기 때문에,
3차원 방문 체크가 필요했다.

첫 구현과 TLE

처음에는 BFS 상태와 함께
경로 문자열 자체를 큐에 같이 넣는 식으로 구현했다.

즉 상태 하나마다 현재까지의 경로 문자열을 계속 들고 다니는 방식이었는데,
이건 상태 수가 많아지면 문자열 복사가 너무 많이 일어나서 무거울 수밖에 없었다.

그래서 여기서 TLE가 났고,
그 뒤에 “이걸 최적화하려면 역추적으로 가야겠다”는 생각으로 방향을 바꿨다.

정답 코드에서 바꾼 점

최종적으로는

BFS에서는 상태만 관리하고
각 상태가 어디서 왔는지 parent
어떤 문자로 들어왔는지 parr

를 따로 기록한 뒤,
도착점 G에 도달하면 부모를 따라가면서 역추적해서 경로를 복원했다.

즉 경로 문자열을 큐에 계속 넣는 대신,
그래프 탐색 + 부모 포인터 복원 형태로 바꾼 것이다.

이 판단이 맞았고,
결국 이 방식으로 AC가 났다.

아쉬웠던 점

아쉬운 점이 있다면 구현이 꽤 길어졌다는 것이다.

특히 o, x, ., S, G를 처리하는 전이 로직을
각각 if문으로 길게 분기해서 쓰다 보니 코드가 다소 무거워졌다.

대회 중에는 일단 AC가 중요하니까 그대로 밀어붙였지만,
나중에 다시 보면

방향 전이를 함수로 분리하거나
공통 로직을 정리하거나
방향 배열을 더 활용해서

좀 더 깔끔하게 정리할 수 있었을 것 같다.

그래도 좋았던 점

그럼에도 불구하고 이 문제에서 가장 의미 있었던 건:

상태 설계를 정확히 했고
TLE 원인을 파악해서
문자열 누적 대신 역추적으로 최적화 방향을 바꿨고
결국 원트 AC로 마무리했다

는 점이다.

즉, 이 문제는 단순히 “운 좋게 맞춘 문제”라기보다
상태 설계 + 구현 최적화 + 복원까지 제대로 처리한 문제였다.

5. 이번 대회에서 좋았던 점

1) C를 빠르게 정리했다

제한을 보고 바로 완전탐색으로 내려온 판단이 좋았다.

2) D 상태 모델링을 맞췄다

(좌표, 이전 방향)이 상태라는 핵심을 정확히 봤다.

3) TLE 이후 구현 방향을 바꿨다

경로 문자열을 직접 들고 다니는 대신,
부모 배열로 역추적하는 방식으로 고친 게 결정적이었다.

4) D를 끝까지 풀었다

시간은 오래 걸렸지만,
결국 400점을 AC했다는 건 분명 큰 성과였다.

6. 아쉬웠던 점

이번 대회에서 아쉬운 점은 크게 두 가지였다.

1) D 구현이 길고 무거웠다

상태 설계는 맞았지만, 전이 로직이 길어져서 코드가 지저분해졌다.

2) D에서 시간을 많이 썼다

80분 넘게 사용했기 때문에,
만약 다음 단계 문제를 보려 했다면 시간적으로는 거의 불가능했다.

즉 이번 대회는
풀긴 풀었지만, 더 깔끔하고 더 빨리 풀 수 있었을 것 같은 문제가 D였다.

7. 다음 목표

방향 의존 상태가 있는 격자 문제에서
(좌표, 방향) 상태를 더 자연스럽게 떠올리기
BFS 경로 복원 문제에서는
문자열 누적 대신 parent 역추적을 우선 생각하기
구현이 길어질 때는
전이 함수로 분리해서 코드 가독성을 챙기기
맞는 아이디어를 잡았으면
그다음은 “더 빨리, 더 깔끔하게” 구현하는 연습하기

한 줄 정리

ABC 453은 C를 빠르게 처리하고, D를 오래 걸렸지만 끝까지 밀어붙여 AC한 대회였다.

앳코더 ABC 452 후기

tkd0711 — Sat, 11 Apr 2026 20:58:31 +0900

앳코더 ABC 452 후기

tkd0711 · 2026. 4. 4.

AtCoder Beginner Contest 452
https://atcoder.jp/contests/abc452

날짜: 2026-04-04 (Sat)
결과: A~C AC, D 미해결
A: 1분대 AC
B: 4분대 AC
C: 23분대 AC
D: 미해결

1. 전체 느낌

이번 대회는 결과만 보면 A~C까지 풀고 600점이었다.

A, B는 비교적 빠르게 마무리했고,
C도 나쁘지 않은 시간 안에 원트로 해결했다.
문제는 D였는데, 거의 1시간 20분을 붙잡고도 끝내지 못했다.

이번 대회는 C까지는 흐름이 괜찮았는데,
D에서 문제를 끝까지 정리하지 못하면서 체감이 많이 안 좋았다.

즉 이번 대회는

초반 운영은 괜찮았고
C까지도 나쁘지 않았지만
D 한 문제에서 사고가 꼬이면서 멈춘 대회

라고 보는 게 맞다.

2. A, B – 비교적 깔끔한 출발

A는 2분 안쪽으로 해결했고,
B도 크게 흔들리지 않고 처리했다.

최근처럼 A, B는 어느 정도 안정권에 들어온 느낌이다.
예전처럼 초반부터 리듬이 무너지지는 않았고,
이번에도 C에 들어가기 전까지 흐름은 괜찮았다.

3. C – Fishbones: 조건을 잘 단순화해서 해결

문제 요약

척추에 길이 N짜리 문자열 하나를 쓰고,
각 갈비뼈 i에는 길이 A_i인 문자열을 쓰는데,
그 문자열의 B_i번째 문자가 척추 문자열의 i번째 문자와 같아야 한다.

사용할 수 있는 문자열 후보는 S_1 ... S_M이고,
각 후보 S_j가 척추 문자열로 가능하면 Yes, 아니면 No를 출력하는 문제였다.

접근

핵심은 각 갈비뼈가 서로 독립적이라는 점이었다.

어떤 척추 문자열이 가능하려면,
척추의 각 위치 i에 대해
“길이 A_i인 문자열들 중 B_i번째 문자가 무엇이 될 수 있는가”만 알면 된다.

그래서:

각 갈비뼈 위치마다 가능한 문자 집합을 만든다.
각 문자열 S_j가 길이 N인지 확인한다.
길이가 맞다면 각 위치 문자가 그 집합에 포함되는지 검사한다.

이 방식으로 풀었다.

왜 되는가

중요한 건 문자열 중복 사용이 가능하다는 점이다.

즉 갈비뼈 1에 어떤 문자열을 썼는지와
갈비뼈 2에 어떤 문자열을 썼는지가 서로 충돌하지 않는다.
그래서 백트래킹이나 매칭처럼 복잡하게 볼 필요가 없고,
각 위치별로 가능한 문자만 미리 모아두면 된다.

시간복잡도

N ≤ 10
M ≤ 200000
문자열 길이도 최대 10

이라서

각 위치마다 모든 문자열을 한 번씩 보는 것
그 뒤 각 후보 문자열을 검사하는 것

모두 합쳐도 O(NM) 수준이라 충분히 가능했다.

느낀 점

C는 “대충 한 것 같다”는 느낌이 들 수 있는데,
사실은 조건을 꽤 정확하게 잘 단순화한 문제였다.

괜히 더 어렵게 생각하지 않고,
“각 위치별 가능한 문자 집합만 만들면 된다”는 구조를 잘 잡은 편이었다.

4. D – No-Subsequence Substring: 최소 끝점 하나를 못 잡아서 꼬임

문제 요약

문자열 S의 부분문자열들 중에서,
문자열 T를 부분수열로 포함하지 않는 것의 개수를 세는 문제였다.

즉:

부분문자열은 연속이어야 하고
부분수열은 연속일 필요는 없다

이 차이를 잘 다뤄야 하는 문제였다.

처음 막힌 이유

문제 자체를 처음 읽었을 때부터 조금 헷갈렸다.

S의 부분문자열을 잡고
그 안에서 T가 부분수열이 되는지 본다

라는 구조인데,
처음엔 가능한 경우를 전부 세려고 하다 보니 사고가 많이 복잡해졌다.

특히 abrakadabra, T = aba 같은 예시를 가지고 손으로 세다가,
어느 순간부터 “가능한 subsequence 조합 개수”를 세는 쪽으로 생각이 꼬였다.

실제 핵심

이 문제의 핵심은 조합 수를 세는 게 아니었다.

시작점 l을 하나 고정했을 때,
그 시작점에서 T를 부분수열로 처음 만들 수 있는 가장 빠른 끝점 rmin 만 알면 된다.

그 이유는:

S[l..rmin]이 이미 T를 부분수열로 포함하면
그보다 더 긴 S[l..r]도 전부 T를 포함하게 되기 때문이다.

즉 시작점 l에서 나쁜 부분문자열 개수는
“가능한 subsequence 경우의 수”가 아니라

rmin부터 끝까지의 개수

딱 이거 하나였다.

내가 꼬인 지점

중간에 개수를 손으로 세면서
“19개인가?”, “15개가 넘나?” 이런 식으로 생각이 섞였던 부분이 있었는데,
그게 정확히 꼬인 지점이었다.

이 문제는

가능한 (a,b,a) 조합 개수를 세는 문제도 아니고
subsequence가 되는 모든 방법 수를 세는 문제도 아니다.

그냥

시작점마다 T를 처음 만들 수 있는 최소 끝점 하나

만 찾으면 되는 문제였는데,
그걸 조합 개수 문제처럼 바라보다가 사고가 복잡해졌다.

정답 구조

정답은 보통 이렇게 간다.

전체 부분문자열 개수 = N*(N+1)/2
T를 부분수열로 포함하는 “나쁜” 부분문자열 개수를 센다.
답 = 전체 - 나쁜 것

그리고 나쁜 부분문자열 개수는
각 시작점 l마다 T를 가장 빨리 완성하는 끝점 rmin을 찾고,
그 뒤 끝점들은 모두 나쁘다고 보고 더하면 된다.

왜 더 아쉬운가

이 문제는 “전혀 감이 없던 문제”는 아니었다.

중간에 네 메모에서도

“현재 부분수열이 T가 되면 그 뒤는 전부다 안 되는 거니까 그런식으로 가야하나?”

라고 적은 부분이 있었는데,
그 감각 자체는 정답에 굉장히 가까웠다.

즉 방향은 거의 근처까지 갔는데,
끝까지 “최소 끝점 하나만 찾으면 된다”로 정리하지 못한 게 아쉬운 문제였다.

5. 이번 대회에서 좋았던 점

1) A, B가 안정적이었다

초반 문제에서 크게 흔들리지 않았다.

2) C를 정확하게 단순화했다

조건이 꽤 많아 보였지만,
실제로 필요한 정보만 뽑아서 깔끔하게 해결했다.

3) D에서도 정답 방향 근처까지는 갔다

완전히 엉뚱한 길을 간 건 아니었고,
핵심 감각은 어느 정도 잡고 있었다.

6. 아쉬웠던 점

가장 큰 아쉬움은 역시 D였다.

조합 수를 세려는 쪽으로 생각이 샜고
시작점별 최소 끝점 하나만 보면 된다는 걸 끝까지 정리하지 못했다.

즉 이번 D는 알고리즘을 아예 몰랐다기보다,

문제를 끝까지 단순한 구조로 정리하지 못해서 멈춘 문제

였다.

이건 실력 부족과는 조금 다르다.
핵심은 보였는데,
그걸 짧고 단순한 식으로 끝까지 가져가지 못한 것이다.

7. 다음 목표

부분문자열/부분수열 문제가 나오면
“직접 세는 게 아니라 반대로 셀 수 있는가” 먼저 생각하기
시작점을 고정했을 때
“최소 끝점 하나만 찾으면 되는 구조”인지 의심하기
조합 수를 세는 문제인지,
경계점 하나를 찾는 문제인지 빨리 구분하기
감은 잡았는데 복잡해질 때
더 많은 경우를 세기보다 “진짜 필요한 정보가 하나인지” 다시 보기

한 줄 정리

ABC 452는 C까지는 흐름이 괜찮았지만, D에서 “가능한 방법 수”를 세는 쪽으로 사고가 꼬이면서 멈춘 대회였다.

앳코더 ABC 451 후기

tkd0711 — Tue, 31 Mar 2026 14:32:57 +0900

앳코더 ABC 451 후기

tkd0711 · 2026. 3. 28.

AtCoder Beginner Contest 451
https://atcoder.jp/contests/abc451

날짜: 2026-03-28 (Sat)
결과: A~D AC
C: 우선순위 큐로 해결
D: DFS 완전생성으로 해결

1. 전체 느낌

이번 대회는 전체적으로 A~D까지 해결했다.
특히 D는 처음에는 시간복잡도에 확신이 없어서 “이게 되나?” 싶은 상태로 제출했는데, 결과적으로는 통과했다.

이번 대회에서 인상적이었던 건 두 가지였다.

C는 아이디어가 직관적이어서 비교적 빠르게 정리된 문제
D는 브루트포스처럼 보이는 풀이를 실제로 밀어붙였는데, 생각보다 충분히 가능한 범위였던 문제

최근 회고들에서 자주 나왔던
문제 독해 실수, 자료형 실수, 구현 디테일 실수 같은 것보다는
이번엔 아이디어를 잡은 뒤 그걸 끝까지 밀어붙이는 감각이 조금 더 좋았던 대회였다.

2. A, B – 비교적 무난한 진행

A와 B는 큰 사고 없이 처리했다.

요즘은 A, B에서 시간을 많이 쓰는 경우는 많이 줄었고,
이번 대회도 초반 흐름 자체는 비교적 안정적이었다.

결국 ABC에서 중요한 건
A, B를 빠르게 넘기고 C, D에 사고 시간을 확보하는 건데,
이번에는 그 부분이 어느 정도 잘 됐다.

3. C – Understory: 우선순위 큐로 깔끔하게 처리

문제 요약

처음에는 정원에 나무가 하나도 없다.

쿼리는 두 종류:

1 h : 높이 h인 나무 하나 추가
2 h : 현재 정원에 있는 나무 중 높이가 h 이하인 나무를 전부 제거

그리고 매 쿼리 직후 정원에 남아 있는 나무 수를 출력하면 된다.

처음 생각

처음 문제를 읽고 나서 든 생각은 단순했다.

삽입이 있고
작은 값부터 한꺼번에 삭제해야 하니까
최소 힙(PriorityQueue)으로 관리하면 되지 않을까?

실제로도 그 방향이 맞았다.

풀이 아이디어

1 h가 들어오면 min-heap에 h를 넣는다.
2 h가 들어오면 heap의 top이 h 이하인 동안 계속 꺼낸다.
매 쿼리마다 heap의 size를 출력한다.

핵심은
삭제 쿼리에서 while이 들어가니까 느리지 않을까 싶을 수 있는데,
각 나무는:

한 번 삽입되고
많아야 한 번 삭제된다.

즉 전체적으로 poll() 횟수 총합이 최대 Q번이다.

그래서 시간복잡도는 전체 기준으로

삽입: O(Q log Q)
삭제: 총합 O(Q log Q)

정도로 충분히 통과 가능하다.

느낀 점

이 문제는 자료구조 선택만 바로 하면 깔끔하게 풀리는 문제였다.

괜히 TreeSet이나 복잡한 구조를 생각하기보다,
“현재 가장 작은 값부터 필요할 때 제거한다”는 문제 구조를 보고
우선순위 큐를 떠올리면 되는 유형이었다.

이런 문제에서 자료구조를 과하게 잡지 않고
가장 단순한 해법으로 가는 것도 중요하다고 느꼈다.

4. D – Concat Power of 2: 완전생성이 실제로 되는 문제

문제 요약

다음 조건을 만족하는 양의 정수를 good integer라고 한다.

2의 거듭제곱들 (1, 2, 4, 8, 16, 32, ...) 중 하나 이상을
중복 및 순서 자유롭게 골라
문자열로 이어붙인 뒤
그 결과를 정수로 본 것

이렇게 만들 수 있는 수들을 오름차순으로 나열했을 때,
N번째 수를 구하는 문제였다.

그리고 조건상 N번째 good integer는 10^9 이하임이 보장된다.

처음 생각

처음에는 이게 정렬/탐색/수학 중 어느 쪽 문제인지 잘 감이 안 왔다.

그런데 조건을 보면
정답 자체가 10^9 이하, 즉 최대 9자리라는 게 핵심이었다.

그래서 생각한 방식은:

사용할 수 있는 조각은 2의 거듭제곱 문자열들
길이 9를 넘기지 않는 범위에서
가능한 모든 연결 문자열을 DFS로 생성
정수로 바꿔 set에 넣고
정렬된 순서에서 N번째를 꺼내기

였다.

처음에는 솔직히 시간복잡도에 확신이 없었다.
“이거 너무 많이 나오는 거 아니야?” 싶었는데, 일단 밀어붙였다.

실제로 왜 되는가

겉으로 보면 DFS가:

매번 여러 개의 조각을 붙일 수 있고
길이 9까지 확장되니까

굉장히 큰 탐색처럼 보인다.

하지만 실제로는:

최종 수가 9자리 이하로 제한되고
각 조각 길이도 1자리, 2자리, 3자리... 식으로 다양해서
가능한 유효 문자열 수가 생각보다 그렇게 많지 않다.

즉 이 문제는
무식하게 보이는 완전생성이 실제로 가능한 범위 안에 들어오는 문제였다.

구현 방식

코드는 대략 이런 흐름이었다.

2^0 ~ 2^30 정도까지 미리 만들어둔다.
DFS로 문자열을 이어붙인다.
길이가 9를 넘으면 종료한다.
길이가 1 이상이면 정수로 바꿔 TreeSet에 넣는다.
마지막에 set을 리스트로 옮겨서 N번째를 출력한다.

코드상 특징

내 구현에서는 TreeSet<Integer>를 써서

자동으로 정렬되고
중복이 제거되도록 처리했다.

이 문제에서는 동일한 문자열 결과가 여러 방식으로 나와도
결국 같은 정수는 한 번만 세면 되므로 TreeSet이 자연스럽게 맞았다.

느낀 점

이 문제는 에디토리얼 없이 대회 중에 풀었을 때
“정말 이게 되는 건가?” 싶은 불안이 남는 유형이었다.

하지만 결국 중요한 건:

문제의 출력 범위가 실제로 얼마나 작은지
완전생성 후보가 진짜 몇 개나 되는지
제한이 브루트포스를 허용하는지

를 보는 것이다.

이번 D는 그 감각이 어느 정도 맞아떨어진 문제였다.

즉, 단순히 “브루트포스처럼 보인다 → 안 된다”가 아니라,
제한을 보고 실제 탐색 공간을 계산해보는 태도가 중요하다는 걸 다시 느꼈다.

5. 이번 대회에서 좋았던 점

1) C를 깔끔하게 처리

자료구조 선택이 빠르게 끝났고,
복잡한 방향으로 새지 않았다.

2) D를 끝까지 밀어붙인 것

처음엔 확신이 없었지만,
제한을 믿고 완전생성 방향을 끝까지 구현해서 해결했다.

3) 최근 자주 나오던 실수는 상대적으로 적었음

문제를 완전히 잘못 읽는 실수
long을 놓치는 실수
자료구조 선택을 완전히 잘못하는 실수

이런 종류의 사고는 이번엔 비교적 덜했다.

6. 아쉬웠던 점

아쉬운 점이 전혀 없는 대회는 아니었다.

특히 D는 맞추긴 했지만,
대회 중에는 시간복잡도에 대한 확신이 부족해서
약간 “될 것 같아서 찍은” 느낌이 있었다.

즉, 풀이를 맞추긴 했지만
왜 이게 되는지 수치적으로 설명할 수 있는 확신은 부족했다.

이건 나중에 비슷한 문제를 다시 만났을 때
정신적으로 흔들릴 수 있는 부분이라서,
풀이가 맞았더라도 한번쯤 복기해볼 필요가 있다.

7. 다음 목표

브루트포스/완전생성 문제를 볼 때
“무조건 안 된다”가 아니라
실제 후보 수가 얼마나 되는지 계산해보기
자료구조 문제에서
가장 단순한 자료구조(PQ 등)로 충분한지 먼저 생각하기
맞춘 문제도
“왜 통과되는지”를 시간복잡도 관점에서 다시 설명해보기

앳코더 ABC 450 후기

tkd0711 — Sun, 22 Mar 2026 18:56:57 +0900

앳코더 ABC 450 후기

tkd0711 · 2026. 3. 21.

AtCoder Beginner Contest 450
https://atcoder.jp/contests/abc450

날짜: 2026-03-21 (Sat)
결과: A~C AC, D 미해결
B: 6트
C: 1트
D: 런타임 에러 후 종료

1. 전체 느낌

이번 대회는 결과만 보면 A~C까지 풀고 600점이지만,
체감상은 최근 대회들 중 가장 아쉬운 편이었다.

A는 빠르게 해결했지만,
B에서 문제를 잘못 읽어서 6번이나 제출했고,
그 여파로 전체 흐름이 크게 꼬였다.
C는 다행히 원트로 풀었지만 문제 이해에 시간이 걸렸고,
D는 아이디어를 잡고 코드까지 썼는데 구현/자료구조 디테일 때문에 놓쳤다.

즉, 이번 대회는

문제를 못 봤다기보다는
문제 독해와 구현 디테일에서 계속 손실이 났던 대회

였다.

2. A – 빠른 시작

A는 큰 고민 없이 해결했다.

최근처럼 A는 비교적 안정적으로 처리되고 있고,
이번에도 초반 스타트 자체는 나쁘지 않았다.

3. B – Split Ticketing: 문제를 잘못 읽어서 크게 꼬임

문제 요약

정수 a < b < c를 골라서

a → b
b → c

로 나눠 타는 비용이
a → c로 한 번에 가는 비용보다 작은 경우가 존재하는지 판별하는 문제였다.

내가 처음 잘못 이해한 부분

처음에는 이걸

a = 1
c = N

처럼 양끝이 고정된 상태에서
중간의 b만 찾는 문제처럼 이해했다.

그래서 사실상 1차원 반복문처럼 접근했다.

하지만 실제 문제는

a, b, c 모두 자유롭게 고를 수 있는 존재 판별 문제

였다.

즉,

시작점도 아무 역이나 가능
끝점도 아무 역이나 가능
중간 역도 아무 역이나 가능

한 문제였는데,
내가 혼자 경우를 너무 좁게 해석하고 시작한 것이다.

왜 6트까지 갔는가

처음 문제 모델을 잘못 잡으니,
그 뒤에는 구현을 조금씩 고쳐도 계속 WA가 날 수밖에 없었다.

이 문제는 사실 N도 작아서
그냥 a, b, c를 전부 다 돌려보면 되는 문제였는데,
내가 처음부터 틀린 문제를 풀고 있었던 셈이다.

교훈

이번 B의 핵심 교훈은 아주 명확했다.

there exist
for some
any

같은 표현이 나오면
먼저 변수가 전부 자유로운지,
아니면 특정 값이 고정되는지를 정확히 읽어야 한다.

이번에는 존재형 문제를
내가 임의로 “양끝 고정” 문제로 바꿔서 읽은 것이 치명적이었다.

4. C – Puddles: 알고리즘보다 문제 해석에서 시간 사용

문제 요약

격자에서 흰색 칸들의 연결 요소 중,
가장 바깥 경계(1행, H행, 1열, W열)에 닿지 않는 것의 개수를 세는 문제였다.

처음 느낀 어려움

처음에는 “검은색에 둘러싸인 흰색 영역”이라는 표현 때문에
이걸 직접 판별해야 하나 싶어서 문제 이해에 시간이 걸렸다.

즉,

주변이 전부 #인지 봐야 하나?
각 칸별로 둘러싸였는지 따져야 하나?

이런 식으로 받아들여서 초반에 잠깐 헷갈렸다.

실제 핵심

실제로는 훨씬 단순했다.

흰색 연결 요소를 BFS/DFS로 구한 뒤,
그 연결 요소가 바깥 경계에 닿는지만 보면 된다.

즉 “검은색에 둘러싸였다”를 직접 검사하는 게 아니라,
바깥 경계에 닿지 않는 흰색 컴포넌트 수를 세는 문제였다.

이 구조를 파악한 뒤에는 원트로 해결했다.

교훈

이번 C는 아이디어가 어려웠던 문제는 아니었다.
오히려 핵심은

문제를 어떻게 번역하느냐
조건을 어떤 형태로 재해석하느냐

였다.

문장을 정확히 읽어서
“둘러싸였다”를 “바깥 경계에 닿지 않는다”로 바꿀 수 있느냐가 중요했다.

5. D – Minimize Range: 아이디어는 잡았지만 구현 디테일로 놓침

문제 요약

수열의 각 원소에 대해
원할 때마다 K를 더할 수 있을 때,
최종적으로 max(A) - min(A)의 최솟값을 구하는 문제였다.

대회 중 생각한 방향

대회 중에는 문제 구조를 어느 정도 이해했고,
그에 맞춰 코드를 작성했다.

TreeSet을 사용해서
현재 가능한 값들의 최소/최대를 관리하는 방식으로 접근했다.

코드의 핵심 부분은 대략 이런 식이었다.

long a = tree.pollFirst();
long b = tree.getLast();
ans = Math.min(ans, b-a);

tree.add(a+m);

그런데 이 코드에서 런타임 에러가 발생했다.

대회 끝나고 바로 보인 문제

대회가 끝난 뒤 다시 생각해보니
문제가 바로 보였다.

pollFirst()를 먼저 해버리면
set이 비는 순간 getLast()를 호출할 수 없게 된다.

그래서 최소/최대는 먼저 확인하고,
그 다음 갱신/삭제를 해야 했다.

즉 순서는 이렇게 되어야 했다.

long a = tree.getFirst();
long b = tree.getLast();
ans = Math.min(ans, b-a);

tree.add(a+m);
tree.pollFirst();

이걸 대회 중에 바로 못 본 게 너무 아쉬웠다.

추가로 놓친 점

사실 이 문제에서 TreeSet 자체도 조심해야 했다.

TreeSet은 중복 값을 보존하지 않기 때문에,
같은 값이 여러 번 등장할 수 있는 상황에서는
멀티셋처럼 쓰면 안 된다.

즉 이번 D는 단순히 런타임 에러뿐 아니라,

최소값을 꺼내는 순서 문제
TreeSet의 중복 미보존 문제

이 둘 다 잠재적으로 있었던 셈이다.

왜 더 아쉬웠는가

이 문제는 아예 방향을 못 잡은 건 아니었다.
오히려 아이디어를 어느 정도 잡고, 코드도 거의 다 쓴 상태였다.

그래서 더 아쉽다.

알고리즘을 못 떠올린 것도 아니고
문제를 못 읽은 것도 아니고
구현 디테일과 자료구조 감각에서 놓친 문제

였기 때문이다.

대회 끝난 뒤 몇 분 지나서
“어디가 틀렸는지 바로 보이는” 유형이라 더 아프게 남는다.

6. 이번 대회에서 느낀 점

이번 ABC 450은
A~C까지 풀었지만 만족감은 거의 없었다.

그 이유는 명확하다.

B: 문제를 잘못 읽어서 리듬이 무너짐
C: 다행히 원트했지만 해석에 시간 사용
D: 아이디어를 잡고도 구현 디테일로 놓침

즉 이번 대회는
실력이 전혀 없어서 못한 대회라기보다는,

문제 독해와 구현 디테일에서 계속 손해 본 대회

였다.

7. 다음 목표

존재 판별 문제에서
변수들이 전부 자유로운지 먼저 체크하기
문제 문장을 직접 구현하려 하지 말고,
더 간단한 조건으로 재해석할 수 있는지 보기
TreeSet을 멀티셋처럼 써도 되는지 항상 확인하기
최소/최대 자료구조를 쓸 때
갱신 순서와 비어 있는 경우를 한 번 더 점검하기

한 줄 정리

ABC 450은 알고리즘을 아예 못 봐서 망한 대회가 아니라,
문제를 잘못 읽고 구현 디테일에서 계속 손해 보면서 아쉬움이 크게 남은 대회였다.