ISUCON2026에 솔로 참가하고, 경기는 거의 Claude Code에게 맡겼습니다 (여행 중 스마트폰으로 지켜본 기록)

서론

저는 2026년 10월 31일 ISUCON2026에 팀명 '어떻게든 되겠지'로 솔로 참가했습니다.

경쟁 시간(10:00~18:00) 동안의 작업은 거의 전부 AI 에이전트인 Claude Code에게 맡겼습니다. 집의 Windows 데스크톱에서 구동되는 Claude Code가 매뉴얼을 읽고, 스택을 생성하며, 측정하고, 코드를 수정하고, 벤치마크를 돌리고, 재부팅 테스트까지 스스로 진행했습니다. 저는 그날 여행 중이라 이동하는 틈틈이 스마트폰으로 알림을 확인만 했습니다.

물론 완전히 무인(無人)은 아니었습니다. 전날 밤의 기동 및 아침 로그인(AWS・Discord) 외에 제가 직접 개입한 부분은 다음 세 가지입니다.

• 경쟁 중 Remote Control (스마트폰 앱에서 현재 작동하는 Claude Code에게 지시를 보내는 기능)을 이용해 보충 지시 3회와 주의사항 전달 1회
• 17:05의 동결 해제
• 경쟁 후 스택 삭제

결과

상위 30개 팀(인증서 대상)까지는 약 9,606점이 부족했습니다 (30위가 218,589점). 공식 결과는 'ISUCON2026 수상팀 및 전 팀 점수'에서 확인할 수 있습니다.

운영 측이 공개하는 리포지토리 링크는 공개되는 대로 여기에 기재할 예정입니다.

① AI에게 맡기기로 한 이유

당초에는 AI를 활용하면서도 직접 참여할 계획이었습니다. 그런데 같은 날 여행 일정이 잡히면서, AI가 자율적으로 진행하도록 방침을 변경했습니다. 당일은 이동이 계속되어 키보드를 만질 시간이 거의 없었기 때문에, 그날 사람의 판단이 필요하지 않도록 사전에 규칙을 정했습니다.

• 마감 시간 설정: 16:45에 동결, 17:00에 측정 중지, 17:10에 재부팅 테스트, 17:20~17:45에 최종 벤치, 17:50 이후에는 건드리지 않기
• 점수가 하락한 변경 사항은 사람에게 물어보지 않고 되돌리기
• 장애로 멈추면, 가장 좋았던 상태 그대로 대기하며 알림 보내기 (재구축하지 않음)
• 제가 보낼 지시는 '멈춰', '빨리 동결' 두 가지뿐이었습니다.

에이전트 절차서(CLAUDE.md)의 서두에는 '사람에게 묻지 않고, 여기에 적힌 정해진 움직임대로 끝까지 진행해 주세요'라고 작성했습니다. 내용이 상충될 경우, 당일 매뉴얼 > 규정 > 절차서 순으로 따르도록 명시했습니다.

② 구성

전체적인 구조는 다음과 같습니다.

작업기는 집의 Windows 데스크톱

작업기를 EC2로 사용하지 않은 이유는, 규정상 '매뉴얼에 따라 작성된 EC2 인스턴스를 제외한 이용'이 금지되어 있기 때문입니다. 개인 PC를 개발이나 모니터링에 사용하는 것은 허용됩니다.

Claude Code는 Windows 버전을 그대로 사용했습니다 (당시 2.1.310). WSL 버전으로 하지 않은 이유는, Chrome 연동 기능이 WSL에서는 사용할 수 없기 때문입니다.

브라우저에서의 작업(벤치 실행, 스택 생성, Discord 공지 확인)은 Claude in Chrome을 이용해 데스크톱의 Chrome을 조작하게 했습니다. 같은 계정에 여러 개의 Chrome이 연결되어 있었기 때문에, 사용하는 Chrome은 절차서에 지정했습니다.

서버로의 SSH는 WSL에서 진행합니다. GitHub에 등록된 키가 WSL 쪽에 있기 때문이며, 허용한 형태만 wsl.exe -e bash ./bin/r.sh <호스트> '<명령어>'와 같은 형태입니다. 배포는 put.sh로 보내 서버 위에서 빌드하고 재부팅합니다.

/loop으로 계속 돌리기

시작은 데스크톱에 둔 .cmd 파일을 더블클릭하는 것만으로 했습니다.

cd /d "%USERPROFILE%\isucon2026"
claude --chrome --remote-control --permission-mode auto

시작 후, /loop에 'prompts/loop-contest.md를 읽고, 그 절차대로 한 단위씩 진행해 주세요'라는 문구를 전달합니다. 한 단위로 처리할 내용은 다음과 같습니다.

• 시간을 확인한다
• STATE.md를 읽는다
• 해당 시간대의 절차를 하나 진행한다
• 기록을 업데이트한다
• 생존 감시(health check)에 ping을 보내고, 다음 기상을 예약한다.

깨어나는 간격은 대기 중에는 20~30분마다, 경주 중에는 1분마다입니다.

/loop는 다음 기상 예약이 연속으로 두 번 없으면 종료됩니다. 그래서 15분 간격의 반복 작업을 '보험 기상'으로 별도로 만들었습니다. /loop 예약이 남아 있으면 아무것도 하지 않고, 멈춰 있다면(사용 제한 등) 한 구간 진행하여 재개시킵니다.

문맥이 압축되어도 복구할 수 있도록, 상태는 STATE.md, LOG.md, NOTES.md와 로컬의 git에 기록하도록 했습니다.

확인 대기 중 멈추지 않도록 하기

무인 운전에서 가장 무서운 것은 확인 대기 상태로 8시간 동안 멈추는 것입니다.

당초에는 설정의 dontAsk로 허가되지 않은 작업을 거부시키려고 했습니다. 그런데 Remote Control 세션에서 사용할 수 있는 모드에 dontAsk 기능이 없습니다. 그래서 실제 운영 환경은 auto mode(허가 목록에 없는 작업을 분류기가 안전한지 판단하여 진행하는 모드)로 설정하고, 그럼에도 사람의 확인이나 질문이 나오는 상황은 훅(hook)으로 기다리지 않고 거부하며 ntfy로 알리도록 했습니다.

"PermissionRequest": [{ "matcher": "*", "hooks": [{
"type": "command", "shell": "bash",
"command": "bash \"$CLAUDE_PROJECT_DIR/bin/hook-deny.sh\" permission",
...

질문(AskUserQuestion) 역시 같은 형태로 PreToolUse에 걸었습니다. hook-deny.sh는 거부 JSON을 반환하며, "동일한 작업이나 다른 표현을 반복하지 말고, 허가된 다른 방법으로 전환해 주십시오"라는 이유를 첨부합니다. onFailure: "block"이므로, 훅 자체가 실패해도 거부 쪽으로 기울어집니다.

auto mode는 분류기에 연속 3회 저지당하면 확인 대기 상태로 돌아갑니다. 따라서 절차서에도, 저지당했을 경우 동일한 작업을 하거나 다른 표현을 반복하지 말고, 다른 방법으로 전환하도록 작성했습니다.

허가 목록(Allowlist)과 거부 목록(Denylist)

Claude Code에는 명령어를 격리하여 실행하는 샌드박스 기능이 있지만, Windows에서는 사용할 수 없습니다. 그래서 분류기를 거치지 않고 허용하는 작업은 허가 목록으로 최소화하고, 위험한 작업은 거부 목록으로 막았습니다.

• 허용:
  wsl.exe -e bash ./bin/*,
  로컬 git(push 제외), 작업 폴더 편집, Chrome 연동
• 거부:
  git push,
  aws,
  curl,
  ssh,
  rm,
  웹 검색, 웹 가져오기(web fetch), 절차서나 bin 수정(ssh와 curl은 bin/ 스크립트 내에서만 사용)

사용 제한이나 로그인 오류로 멈췄을 때는 StopFailure 훅으로 ntfy에 알립니다.

알림, 생존 감시(Health Check), 모니터링

• ntfy: 시작, 벤치별 점수, 실패, 동결, 최종 결과를 스마트폰으로 전송. 본문은 시간/점수/성패/상태만 포함시키고, 문제의 내용(API 이름이나 테이블명)은 작성하지 않도록 했습니다. 토픽명은 무작위로 긴 문자열을 사용합니다.
• healthchecks.io: 에이전트가 깨어날 때마다 ping을 보냅니다. 30분 동안 수신되지 않으면(간격 15분 + 유예 15분) 스마트폰으로 알림이 오기 때문에, 데스크톱 전체가 다운되어도 인지할 수 있습니다.
• Remote Control: Android의 Claude 앱에서 세션을 확인하고 지시를 보냅니다.
• 클라우드에서의 모니터링: ntfy와 동일한 본문을 모니터링용 토픽에도 전송합니다. 클라우드의 Claude가 07:35, 11:15, 13:30, 16:30, 18:10에 읽으면서 제가 도움이 필요할 때만 알려줍니다(11:15와 18:10은 도움이 필요하지 않아도 상황을 알림). 당일, 클라우드의 Claude로부터 도움이 필요하다는 알림은 단 한 번도 없었습니다.
• 비상용: MacBook Pro에서 Tailscale 경유 원격 데스크톱

③ 규정과의 맞추기

ISUCON2026 규정에서는 AI를 사용한 코드 분석 및 생성이 허용됩니다. 그 위에서, 규정의 각 항목을 다음과 같이 설계에 반영했습니다.

⚠️ [IMG:N]

④ 연습 중 막혔던 부분과 해결 방법

본전(실제 대회) 전에, 연습을 2회 진행했습니다.

리허설 (10/26 밤 ~ 10/27 새벽)

다음 두 가지를 진행했습니다.

• A: 환경 확인용 스택을 구성하고, SSH를 시도함
• B: private-isu (ISUCON 연습용으로 공개된 문제)를 1대 구성하고, 개선 루프를 돌림

B의 점수는 996 → 27,482로, 재부팅 후 2회의 벤치마크도 통과했습니다. auto mode로 전환한 이후로는 사람의 손이 필요하지 않았습니다.

실전 연습 (10/27 23:05 ~ 10/28 09:14)

본전과 마찬가지로 '전날 밤 대기 → 아침 사전 점검 → 부하 테스트'를 순차적으로 시도했습니다. 부하 테스트에서는 private-isu에서 개선 루프를 돌렸습니다.

• 밤 대기: 23:05~06:31까지는 약 25분 간격으로 예정대로 깨어남. Chrome 확장 프로그램은 약 30분 간격으로 자동 재연결되었으나, 사용하는 Chrome은 선택된 상태를 유지함. 거부나 확인 대기는 0건이었고, 비상용 기상 알람도 필요 없었음.
• AWS 로그인 지연: 나의 로그인이 08:03 이후가 되었기 때문에, 07:31에 '준비 NG', 08:07에 '준비 OK'로 바뀌면서 부하 테스트 시작이 37분 지연됨.
• 서버 OS 자동 업데이트: 기동 약 20분 후에 unattended-upgrades가 MySQL을 교체하고 재부팅하면서, 벤치마크가 500에서 1회 실패함. 본전에서는 준비 시작 시 모든 대장에서 자동 업데이트를 확인하고, 완료될 때까지 기다린 후 타이머와 unattended-upgrades를 중지하는 절차를 추가했습니다.

부하 테스트 점수는 940 → 305,016이었습니다. 재부팅 후 2회의 벤치마크도 통과했습니다.

⑤ 본전 타임라인 및 점수 변화 추이

시간대별 사건 기록

경기 진행 과정 및 주요 개선점 분석

점수 변화 추이(주요 내용)

제가 보낸 보충 설명 (원격 제어)

• 보충 설명1 (11:20): 후반부 처리를 보완함 - 17:00 측정 중단 시, PostgreSQL 로그나 측정값도 중지해야 함 (절차서는 MySQL 기반으로 작성되어 있었음)

• 최종 벤치가 최고 기록의 85% 이상이라면 그대로 최종값으로 확정. 85% 미만이거나 실패했다면, 마지막에 좋았던 커밋으로 되돌림

• 17:35를 넘기면 성공한 상태는 되돌리지 않음

• 재부팅 테스트에서 작동하지 않는 것이 있다면, 그 수정만 우선함

• 보충 설명2 (11:41): 구조적 막힘을 찾기 위해 한 바퀴 돌기를 요청함 - 리더보드의 상위 점수도 1시간마다 기록함 (수정할 부분은 측정으로 결정)

• 선두가 제가 가진 값의 약 8배였기 때문에, 한 바퀴를 사용하여 매뉴얼의 부하와 채점 부분을 다시 읽어봄

• 전체 장치의 CPU와 오류나 타임아웃으로 인해 부하가 줄지 않은 부분이 있는지 확인함

• 보충 설명3 (12:07〜12:08): 문제 설정과 관련된 보충 설명을 보냄. 12:07분 내용은 도착했을 때 글자가 깨져서 읽을 수 없었기 때문에, 12:08에 재전송함

그 외에도 13:01경 포털 질문 답변을 바탕으로 주의 사항을 한 번 더 보냄. 17:05에는 동결 해제를 지시했음.

가장 효과적이었던 것은 보충 설명2입니다. 다시 읽어본 결과, 알림 지연 때문에 일부 지역 이용자가 증가하지 않았다는 것을 알게 되었습니다. 알림을 직접 배포로 바꾼 #18에서는 해당 지역의 인원이 18명에서 544명으로 늘어났습니다.

17:05 동결 해제는 절차서의 기본 지침(동결 후에는 개선되지 않음)에서 벗어난 지시였습니다. 절차서에는 '멈추게', '조기에 동결' 외에도 '이 파일의 금지 사항에 위배되지 않는 범위 내에서 따름'이라고 적혀 있습니다. 에이전트는 해제된 지시에 따라 #66~#70 실험을 진행했고, 17:40에 다시 재부팅 테스트를 통과했습니다. #65(206,400)와 비교했을 때, 최고 기록은 +5,005, 최종값은 +2,583이었습니다.

경기 후 스택 삭제

18:00 이후 제가 스택 삭제를 요청하자, 에이전트는 절차서의 금지 사항(추가 테스트에 사용하므로 본방 스택은 지우지 않기/18:00 이후에는 서버와 포털 모두 아무것도 하지 않기)을 이유로 거절했습니다. 운영 측에서 삭제해도 좋다는 안내가 나온 것은 20:20이었고, 그 후에 제가 직접 삭제했습니다.

⑥ 효과적 개선 및 비효과적 개선

효과적 개선

• 구조적 막힘을 찾아 고친 것: 알림의 직접 배포(#18. 보충 설명2에서 매뉴얼을 다시 읽어 발견), 이미지 서명 사전 계산(#20. 서명 계산이 asia1 CPU의 71%를 사용하고 있었음), 수신량의 66%를 차지하던 거대한 부정확한 이미지 거부(#53. 로그에 본문 크기를 추가해야 보일 수 있었음) -
• I/O 형태를 바꾼 것: 신규 이미지를 DB에서 파일로 옮기고, 초기 이미지 182만 건을 하나의 파일과 인덱스로 통합함(#26・#31). 처음에는 약 180만 개의 파일을 쓰면서 IOPS 상한으로 인해 악화됨(#27〜29) -
• 지역 간 우선순위: asia의 동시 실행 수를 32로 제한하고, 유럽/미국으로부터의 요청을 우선함(#57. 181,292 → 207,439)

비효과적 개선 또는 되돌린 것

어려웠던 점 (경기가 끝난 후 에이전트가 직접 작성한 회고록에서)

• 점수 편차가 큼: 동일한 구성임에도 불구하고 195,198~206,400점을 기록했습니다. 초반에도 동일 구성으로 43,377점과 27,292점이 나왔습니다. 작은 개선 효과를 단 한 번의 벤치 테스트로는 판별할 수 없었습니다.
• 병목 지점이 계속 이동함: 알림(Notification) → 서명(Signature) → 이미지 IOPS → 비정상적인 이미지 → 지역 간 우선순위 순으로 병목 지점이 옮겨갔습니다.
• 지역 간 회선: 하강 속도는 약 21MB/s에서 정체되었고, 부하 시 RTT는 최대 935ms에 달했습니다. 마지막 페이스 제어(Pacing Control)를 통해 101~135ms까지 낮추었지만, 점수 차이는 편차 범위 내였습니다.

⑦ 상위권과의 격차 분석

순위는 579팀 중 38위였으나, 점수에서는 상위권과 큰 차이가 발생했습니다. 1위의 625,857점은 본인의 약 3배, 10위의 311,396점 역시 약 1.5배에 달합니다.

격차가 벌어진 시간

에이전트가 경기 중에 기록한 리더보드와 최종 결과입니다.

1위와의 격차는 점심 전에는 거의 결정되었습니다. 그 이후 12시부터 16시 사이에 10~30위권 팀들에게 추월당했습니다.

1위와의 격차는 어디서 발생했나?

1위의 Typing Bears 역시 1인 참가였고, 경기 중에는 사람의 입력 없이 Claude Code에게 맡겼습니다 (ISUCON2026에서 우승했습니다(당일 편)). 사용한 AI는 본인과 동일합니다 (Claude Code와 Claude Opus 5.5).

참가기에 따르면, 1위 에이전트는 10:10에 지역 간 왕복 시간이 약 100ms라는 것을 측정했습니다. 서구권 앱은 SQL을 던질 때마다 약 100ms가 소요되므로, 10:35에 읽기는 데이터베이스에 쿼리하지 않고 각 서버의 메모리 복사본에서 반환하고, 쓰기는 asia2에 모아서 순서를 정한 후 같은 순서로 다른 서버에 분배하는 방식으로 수정한다는 방침을 확정했습니다. 10:55에 배포하여 11:22에는 506,241점에 도달했습니다.

본인의 에이전트 역시 10:34에 서구권에서 DB로의 왕복 시간을 줄이는 변경을 했습니다(#3). 같은 문제점을 비슷한 시기에 인지하고 있었습니다. 다만 방향은 반대로 선택하여, 11:09부터는 서구 서버에 대한 요청(읽기 포함)을 asia1으로 전송하여 처리를 한 곳에 모았습니다(#10~#14).

15:40에는 서구권의 읽기를 서구권 서버에서 처리하는 방식도 시도했습니다(#50). 하지만 DB는 asia2에 있기 때문에 100ms 왕복 시간은 남아 있었고, 작성 직후 내용을 다른 지역에서도 바로 읽을 수 있도록 할 필요가 있었습니다. 서구권 인원이 절반으로 줄어들자 이 방식을 되돌렸습니다. 그 후에는 한 곳에 모은 상태를 유지하며 동시 실행 수 제한 및 응답 페이스 제어로 점수를 끌어올렸습니다. 마지막에는 지역 간 회선이 병목 지점이 되었고, 이곳이 이 구성의 최대치였다고 생각합니다.

다른 팀의 참가기에서도 지역별 데이터 배치 방식이 점수에 영향을 미쳤다는 이야기가 나옵니다.

• 6위 팀은 DB를 지역별로 분리하여 71,407점에서 138,223점으로 거의 두 배로 늘렸습니다(12:20. ISUCON2026에서 Agent의 하네스를 만들어 6위를 차지했습니다).
• 18위 팀은 이미지를 각 지역에 배치하여 서구권 게시물을 지역 내에서 완결시키며 120,540점까지 끌어올렸습니다(13:42. ISUCON2026 참가기(18위)).
• 본인과 비슷한 198,146점의 팀은 초반(10:36)에 쓰기를 asia1에 모았던 변경을 '가장 치명적인 실수'라고 회고했습니다(ISUCON2026에 도구를 버리고 이기고 싶었다).

쓰기를 한 곳으로 모으는 것 자체는 1위도 동일합니다. 차이는 읽기를 각 지역에서 처리할 수 있었는지 여부에 있었다고 생각합니다.

왜 재구축하지 않았는가

경기 중 기록(LOG・STATE・NOTES)에 대해서는, #15~#16(각 지역 서버로 제출하는 경우)과 #50(유럽/미국 읽기 처리를 유럽/미국 서버에서 처리하는 경우)와 같은 부분적인 시도 외에는, 읽기 데이터를 각 지역의 로컬 데이터로부터 반환하는 형태를 검토한 흔적이 없습니다. 읽기 전용 복제본과 같은 아이디어가 나온 것은, 경기가 끝난 후 NOTES에 작성한 회고가 처음입니다. 원인은 제가 사전에 준비했던 절차서에 있다고 생각합니다.

• 개선 루프(Improvement Loop)는 가장 시간이 많이 소요되는 부분을 하나 선택하여, 1 변경 = 1 커밋(commit)으로 수정하고 실패하면 이전의 최적 상태로 되돌리는 방식으로, 구성 전체를 다시 짜는 선택지가 없었습니다.
• '효과적인 순서'는 일반적인 정석(인덱스 → N+1 → ...)이며, DB를 다른 장치로 분리하는 것 역시 'DB CPU가 막히기 전'의 이야기입니다. 지역별로 나누자는 이야기는 절차서에 없었습니다. 신선도가 필요한 데이터는 캐시하지 않는다거나, 데이터를 '메모리에만' 두지 않는다는 내용도 적혀 있었습니다.
• 멈췄을 때의 규정에도 '크게 재구성하거나 스택(stack)을 다시 짜지는 않는다'고 명시되어 있었습니다.

이러한 규칙들은 대부분 감점이나 실격품을 피하기 위한 안전장치였으며, 8시간 동안 멈추지 않고 진행하는 데는 효과적이었다고 생각합니다. 하지만 지역을 넘나드는 왕복 이동이 전제인 이번 문제에서는, 재구성을 선택하지 못하게 한 방향으로 작용한 것이라 생각합니다.

구성 자체를 크게 변경하는 논의가 뒤로 밀렸다는 이야기는 다른 참가기에서도 나옵니다. 6위에 오른 팀은 에이전트를 메모리에 복제할 방침을 세웠고, DB 지역 분리는 '위험도가 높은 선택지'로 미뤄두었습니다. 사람이 이를 최우선으로 끌어올리면서 점수가 거의 두 배가 되었습니다. 198,146점을 기록한 팀은 에이전트의 구현 시간을 8시간 이상으로 예상하여 수정하는 것을 포기했다고 합니다.

또 다른 원인은 준비량의 차이라고 생각합니다. 1위는 3개월에 걸쳐 평가 환경에서 100회 이상 문제를 풀게 했고, 하네스(Harness: 에이전트를 구동하는 시스템 구조. 여기서 말하자면 ② 구성)를 수정했다고 합니다. 저희의 준비 기간은 5일이었고, 점수를 연습한 두 번 모두 단일 구성의 private-isu 환경에서 확인했으며, 주로 '멈추지 않는 것'에 초점을 맞췄습니다.

30위와의 차이점

30위(218,589점)와의 차이는 9,606점(4.6%)으로, 같은 구성을 사용했을 때 저희 점수의 변동폭(195,198206,400)과 비슷한 수준입니다. 막판에는 예정 시간(16:45)보다 빠른 16:34에 동결되었고, 재시작 테스트도 예정 시간(17:10)보다 이른 16:4416:48에 완료했습니다(17:05에 동결 해제). 순위는 17:00 기준 임시 29위에서 최종 38위로 하락했습니다. 하지만 경기 중 최고 기록인 211,405점만 해도 35위권 수준이므로, 막판 진행 방식보다는 위에서 언급한 구성의 차이가 훨씬 컸다고 보고 있습니다.

⑧ 지출 비용 및 Claude 사용량

AWS

Claude

추가 과금(사용 크레딧) 기능은 꺼두고, 계약된 Max 플랜(20x・월 $200)의 범위 내에서만 사용했습니다.

• 리허설: 1시간에 주간 할당량의 약 2%를 사용했습니다.
• 실전 연습: 부하 테스트 후반부(5시간 할당량이 돌아온 후 약 35분)에 5시간 할당량의 2%를 사용했습니다. 주간 할당량은 07:33~09:14 사이에 58% → 60%였습니다.
• 본 경기: 14:36 시점에 5시간 할당량 10%, 주간 할당량 24%를 사용했습니다. 종료 시점의 값은 기록하지 않았습니다.

⑨ 다음에 할 일

에이전트의 회고와, ⑦에서 본 상위권과의 차이를 바탕으로 다음번에 바꾸고 싶은 부분들입니다.

초기 1시간 동안 구성 방침 결정하기: 지역을 넘나드는 왕복 테스트를 측정하고, 각 지역에서 읽기를 반환할 수 있는 형태(메모리 복제 및 지역별 DB)로 할지 여부를 초기 1시간 내에 결정해야 합니다 (1위는 10:35에 결정했습니다). 절차서에는 '변경 = 커밋'이라는 규칙 외에 재구축을 위한 틀도 마련하고, 안전한 결정을 내릴 수 있는 조건(메모리에만 두지 않기/크게 재구성하지 않기)도 명시해 두는 것이 좋습니다.

• 점수 획득 연습하기: 단순히 멈추지 않는 것 확인뿐 아니라, 여러 대의 장치와 여러 지역을 아우르는 과거 문제들을 통해 방침을 세우는 방법까지 연습해야 합니다.
• 초기 1시간 동안 측정 완료하기: 각 장치의 CPU, 대역폭(Bandwidth), RTT 외에도 수신 및 전송 본문 크기의 내역을 오전에 로그에 기록합니다. 거대한 부정 이미지에気づ은 것은 15:47이었는데, 너무 늦었습니다.
• 매뉴얼의 부하와 채점 부분을 초기에 읽기: 이번에는 저의 보충 자료2 덕분이었습니다. 절차서의 10:00 순서(매뉴얼 읽기)에 부하가 증가하는 방식과 채점 부분을 명시적으로 추가해야 합니다.
• 오차를 전제로 판단하기: 효과가 작은 변경 사항은 동일한 구성으로 여러 번 측정해봅니다.
• git에서 되돌리기 전에 기록을 커밋하기: #45와 같은 실수를 방지하는 절차를 추가합니다.
• 사람이 보완했던 부분을 연습 과정의 절차서에 포함시키기: 보충 자료1과 2 모두 절차서에 적어둘 수 있는 내용이었다고 생각합니다 (보충 자료3과 동결 해제는 당일 상황을 보고 판단한 것이었습니다). 연습 단계에서 미리 파악해 두어야 합니다.

맺음말

제가 이동하는 동안, 에이전트는 2,139부터 208,983까지 총 70회의 벤치마크를 돌렸습니다. 낮아진 변경 사항은 되돌리고, 재시작 테스트를 두 번 거쳤으며, 대회 후 삭제 요청은 거절했습니다.

한편, 점수를 크게 움직인 계기 중 하나는 사람이 한 바퀴를 돌아가며 매뉴얼을 다시 읽도록 부탁했기 때문이었습니다. 에이전트에게 맡긴 참가였음에도 불구하고, 사람이 무엇을 어느 타이밍에 말해주는지는 아직 결과에 영향을 미치는 것 같습니다.

하지만 같은 AI로 약 3배의 차이가 난 것을 보면, 당일 한마디보다는 사전에 하네스(Harness)와 절차서에 무엇을 넣어두는 것이 결과를 크게 갈랐던 것 같습니다.

마지막으로, ISUCON2026 운영과 문제 출제에 참여해주신 모든 분들께 감사드립니다. AI 사용이 규정상 명확하게 인정되었기 때문에 에이전트에게 맡기는 형태로 참가할 수 있었습니다. 상위권과의 차이를 알아보는 과정에서 성능 개선의 이해도 향상뿐만 아니라, 저만의 방식에서의 AI 구동 개발 현황과 다른 사람들의 AI 활용법을 알게 되어 앞으로의 AI 사용에 참고가 되었습니다.

토론