개발 히스토리#

코드배틀은 “한 번에 크게 만들기”보다는 MVP를 올리고, 느린 지점을 고치고, 행사를 지원하면서 확장하는 방식으로 성장해 왔습니다. 특히 초창기에는 회사 일과 공부 사이에서 시간을 쪼개며 진행했고, 그 과정에서 “개발 히스토리를 문서로 남겨 컨텍스트를 유지하는 습관”이 큰 도움이 되었습니다.

2017년 5월 21일 — 가위바위보 게임 MVP로 사이트 오픈#

코드배틀의 1st MVP는 가위바위보 게임이었습니다. 처음에는 웹페이지 하나와 API 하나로 시작했고, 사용자는 onGameStart(), onRoundStart() 같은 콜백 함수를 코드 영역에 작성해 “내 전략”을 주입하는 방식이었습니다.

기술 스택: Node.js + Express 기반으로 라우터 / 뷰를 분리했고, 코드 작성 영역은 모나코 에디터를 적용했습니다. 디자인은 Bootstrap을 얹고, 모바일 / 데스크탑 반응형 레이아웃을 최소한으로 맞췄습니다.
게임 설계 포인트: 단순 가위바위보 룰만으로는 “랜덤을 대부분 이길 수 있는 전략”을 만들기 어려워서, 이길 때 선택에 따라 점수가 달라지도록(가위 1점/바위 2점/보 3점) 룰을 바꿔 전략 설계의 여지를 만들었습니다.
동시 실행 이슈: 서버가 클라이언트를 구분하지 못하면 여러 사용자가 동시에 실행할 때 결과가 섞일 수 있어서, trans_id를 도입해 트랜잭션 단위를 분리하는 방식으로 안정성을 확보했습니다.
운영 오픈: AWS(서울 리전) 인스턴스에 Nginx/Node 환경을 올리고, codebattle.online 도메인을 붙여 첫 오픈을 마쳤습니다.

2017년 8월 3일 — AJAX 통신에서 Socket.io 기반으로 전환#

초기에는 턴 / 라운드 단위로 요청이 많이 발생하다 보니, 동시 실행이 조금만 늘어도 서버 입장에서는 “거의 DDOS처럼” 부담이 커지는 느낌이 있었습니다. 그래서 게임 진행 중의 요청 / 응답 흐름을 Socket 기반으로 전환했습니다.

체감 성능: Socket으로 바꾸면 극적으로 빨라질 것이라 기대했지만, 실제로는 “엄청 빨라졌다”기보다는 구조가 더 명확해진 쪽이 더 컸습니다.
의미: 이후 사용자 간 실시간 대전(1:1) 확장에 필요한 기반을 미리 깔아 둔 셈이었습니다.

2017년 8월 14일 — 원격 사용자 1:1 온라인 대결 릴리즈#

기존에는 서버에 구현된 상대 로직(RANDOM / LEVEL 등)과만 대결할 수 있었는데, 대기실(닉네임), 매칭 / 대결 신청 등 사용자끼리 1:1로 붙는 온라인 대전을 오픈했습니다.

개발 난이도: 소켓 프로그래밍이 익숙하지 않은 상태에서 시작해 삽질이 많았고, “돌아가긴 하는데 코드가 엉켜 있는” 상태로 기능이 먼저 완성된 후에 정리해야 하는 숙제가 남기도 했습니다.
운영의 현실: 기능은 열었지만, “나 말고는 아무도 들어오지 않는” 현실도 마주했습니다. 그래도 이 경험은 이후 행사 운영(토너먼트/대진표) 관점에서 큰 자산이 됐습니다.

2017년 9월 6일 — 검색엔진최적화(SEO) 작업#

구글 / 네이버 서치콘솔(또는 웹마스터 도구) 기준으로 사이트 인증, 사이트맵 제출, 메타태그 보강 등 기본적인 SEO 작업을 진행했습니다. “내가 할 수 있는 건 대강 다 했다”는 느낌으로, 이후에는 검색엔진이 잘 반영해 주기를 기다리는 단계였습니다.

2017년 11월 1일 — 오목(Five in a Row) 게임 추가#

두 번째 게임은 오목으로 정했고, 이때부터 “게임이 늘어나는 구조”를 본격적으로 고민하게 됐습니다.

구조 변화: 게임별로 소켓 포트 / 컨트롤러 / 게임 파일을 분리하는 방식으로 구조를 잡았습니다.
운영 이슈: 게임을 추가할 때마다 포트 오픈을 위한 AWS Security Group 설정을 손봐야 하는 번거로움이 있어, “게임을 쉽게 추가하는 구조”까지는 아직 갈 길이 남아 있었습니다.
알고리즘: RANDOM / LEVEL1부터 시작해, LEVEL2, LEVEL3(미니맥스 등)까지 단계별로 고도화하는 흐름으로 가져갔습니다. 특히 LEVEL3는 디버깅에 시간이 많이 들었고, LEVEL2에게 지는 상태를 그냥 둘 수 없어서 끝까지 붙잡고 개선했습니다.

2018년 8월 10일 — 숫자야구(Bulls and Cows) 게임 추가#

오랜 공백 이후 추가한 게임이 숫자야구였습니다. 이 게임은 매 턴마다 “볼 / 스트라이크” 같은 피드백을 받아서 가능한 정답 후보를 계속 줄여 나가는 것(필터링) 이 핵심입니다. 그런데 후보를 줄이고 나면, 남아 있는 후보들 중에서 “다음에 어떤 숫자를 던질지”를 정하는 기준이 애매해지기 쉬워, 결과적으로 선택이 무작위에 가까워지는 문제가 있었습니다. 그래서 LEVEL 간(예: LEVEL1과 LEVEL2)의 실력 차이를 분명하게 만들기가 어려웠습니다.

룰 보강: 동시 정답(비김) 상황에서 더 큰 수가 승리하도록 규칙을 추가해, LEVEL1 / 2 / 3를 의미 있게 나눌 수 있도록 설계를 보강했습니다.

2019년 8월 20일 — 섯다(Sutda) 게임 추가#

타짜 명장면을 다시 본 뒤 섯다를 추가하기로 결정했고, 결과적으로는 “게임 프로토콜을 단순화하기가 가장 어려웠던 게임” 중 하나였습니다.

복잡했던 이유: 턴의 의미가 다른 게임들보다 복잡했고, 라운드마다 선이 바뀌는 요소가 구현 난이도를 올렸습니다.
범위 조절: 규칙을 전부 넣기엔 과해질 수 있어, 끗 / 땡 / 광땡(38, 18, 13) 중심으로 룰을 설계해 게임성을 확보했습니다.

2021년 9월 24일 — SK플래닛 행사 지원용 “1:1 무술대회” 컨셉 게임 추가#

코드배틀은 네오위즈 재직 시절 개발자 행사에서 마지막 세션이자 분위기의 피크를 찍던 주인공 같은 세션이었습니다. 그래서 추억을 가진 사람이 저뿐만이 아니었고, SK플래닛에서 개발자 행사를 기획하던 지인이 우연히 검색을 통해 제 글을 보고 연락이 닿으면서, 코드배틀로 행사를 지원하게 됐습니다.

지원 범위: 단순히 웹페이지를 만드는 수준이 아니라, “어떤 게임이 행사에 맞는가”, “예선 / 본선 진행 방식은 어떻게 할 것인가”, “운영을 위해 무엇이 필요한가” 같은 제안까지 포함된 형태였습니다.
핵심 가치 재확인: 코드배틀이 “서비스”로서도 의미가 있지만, 특히 개발자 행사에서 사람들을 몰입시키는 장치로 강하다는 걸 다시 체감한 시기였습니다.

2022년 11월 24일 — SK플래닛 행사 지원용 “진짜 야구” 게임 추가#

지인이 처음엔 “숫자야구인가?” 하고 살짝 실망한 듯했지만, “진짜 야구” 컨셉임을 설명하자 이내 반응이 좋아졌던 기억이 있습니다. 이때부터는 행사 맥락에 맞게, 규칙을 ‘직관적이면서도 관전 재미가 있는 방향’으로 더 신경 쓰게 됐습니다.

2023년 12월 2일 — SK플래닛 행사 지원용 “숫자 카드 배틀” 게임 추가#

홀덤/오목/섯다 중에 고민하다가 섯다로 하려고 했는데, 지인이 도박 종류는 리스키하다고 하여, 섯다 룰에 기반한 “숫자 카드 배틀” 을 고안했습니다.

피드백: 이전 게임들에 비해 컨셉이 어렵다는 피드백들이 있었지만, 그래도 다행히 행사를 성황리에 잘 마쳤다고 하여 안심했던 기억이 있습니다.

2026년 1월 30일 — 트래픽 구조 개선 및 디자인 리뉴얼 릴리즈#

코드배틀 사이트를 오픈한지 어느덧 9년이 다 되어 가는 시점이었습니다. 이때까지 마케팅을 하지 않았었고, 디자인도 처음 그대로였습니다.

미뤄진 이유: 회사 일 때문에 바쁜 것도 있었지만 더 중요한 것은, 게임 특성상 게임 실행시 서버와의 통신량이 많아서 동시 접속자가 늘어날 경우 버티기 어려운 구조였기 때문입니다.
전환점: SK플래닛 지원용 게임을 추가하면서 서버 통신 없이 게임을 실행하는 방식을 고안해냈고, 어떻게 개선해야할지를 정할 수 있었습니다.
실행: 다만 그 생각을 하고 나서도 몇년간 미뤄오다가, Ted Factory 기획을 하면서 이제는 해야한다는 사명감과 함께 트래픽 관련 기능 개선 및 디자인 리뉴얼을 진행하여 릴리즈했습니다.

2026년 7월 — 배포 자동화, 브라우저 실행, Google 로그인#

리뉴얼 뒤 반년은 “기능을 더하는 시간"이 아니라 운영과 확장의 체질을 바꾸는 시간이었습니다. 이때부터는 Claude Code 같은 코딩 에이전트를 주 도구로 썼고, 계획과 결정을 저장소 안 문서로 남기며 진행했습니다.

7월 18일, 배포 자동화: GitHub Actions가 master의 검증된 커밋만 Lightsail에 자동 배포하도록 바꿨습니다. 이후 모든 배포는 문법 검사, 화면이 주장하는 숫자의 검증, sitemap 검사, 빌드 산출물 대조, 테스트, 런타임 스모크 테스트, 의존성 취약점 검사를 차례로 통과해야 합니다. 운영 의존성의 취약점도 0건으로 줄였습니다.
7월 20일, 사용자 코드를 브라우저 안에서 실행: 사용자 코드를 서버가 아니라 각자의 브라우저 Worker(별도 스레드)에서 콜백당 2초 제한으로 돌리고 네트워크를 차단했습니다. 2026년 1월에 일부 게임에서 검증한 “서버 통신 없는 실행"이 전 게임의 기본이 됐습니다.
7월 26일, Google 로그인과 회원 기반: SQLite 회원·세션, 탈퇴 시 개인정보 익명화와 세션 폐기, 개인정보처리방침과 이용약관, 사업자 정보 푸터, 문의 메일 주소까지 한 번에 갖췄습니다.
7월 30일~8월 1일, 메시지와 측정: 홈 메시지를 “코딩 학습"에서 “코드 전략 대전"으로 바꿨고, 게임 퍼널(대전 시작·종료·중단, 대기실 입퇴장, 코드 저장)을 GA4(Google Analytics 4) 이벤트로 측정하기 시작했습니다. 화면 알림 56곳을 네이티브 alert에서 오버레이 다이얼로그로 교체했습니다.

2026년 8월 2일 — 계정 코드 저장과 공개 아이디#

전략 코드를 계정에 저장할 수 있게 했습니다. 게임당 대표 코드 하나와 이름 붙인 버전 열 개를 두고, 충돌은 revision 비교로 해결합니다. 서버는 코드를 실행하지 않고 JSON으로만 주고받습니다. 공개 신원은 아이디 하나로 정했고(가입 시 자동 발급, 30일에 한 번 변경, 반납된 아이디는 재사용 금지), 배포 전에 회원 DB를 자동 백업하도록 했습니다.

2026년 8월 6일 — 온라인 대전을 회원 전용으로#

온라인 1:1 대전의 표시 이름을 서버가 계정에서 정하고, 같은 계정은 한 게임 대기실에 하나만 들어가게 했습니다. 다만 실시간 매칭은 사용자 수가 임계값을 넘기 전에는 어떤 방식으로도 성립하지 않는다고 판단해 더 공을 들이지 않기로 했습니다. 상대를 “사람"이 아니라 “코드"로 바꾸는 쪽, 즉 아레나가 다음 단계가 됐습니다.

2026년 8월 9일 — 코드 아레나 오픈 (8월 11일 오목 확장)#

내 코드를 출전시키면 다른 회원이 도전하고, 결과가 공개 전적으로 쌓이는 코드 아레나를 열었습니다. 기술적으로 세 가지가 핵심입니다.

결정론: 같은 두 코드와 같은 seed(난수 씨앗)면 같은 리플레이가 나옵니다. Math.random과 Date.now()를 결정론적으로 바꿔 넣습니다.
두 Worker 대전: 두 코드가 도전자의 브라우저 안에서 각자 별도의 Worker로 실행됩니다. 서버는 사용자 코드를 실행하지 않습니다.
서버 재계산: 서버는 기록된 수만 받아 규칙 엔진으로 다시 계산해 결과를 검증합니다. 조작된 결과는 거부됩니다.

가위바위보로 시작해 8월 11일 오목까지 넓혔습니다. 숫자야구와 섯다는 보류했습니다. 숫자야구는 관전 화면에 양쪽의 비밀 숫자가 노출되는 문제를, 섯다는 카드를 난수로 뽑아 서버가 재계산할 수 없는 문제를 먼저 풀어야 합니다.

2026년 8월 13일~21일 — 검색 정본 한국어 전환과 전략 해설#

검색 정본 언어를 영어에서 한국어로 바꿨습니다. 정본(canonical)은 검색엔진이 여러 언어판 가운데 대표로 색인하는 페이지입니다. 기본 언어가 영어였던 동안 검색엔진이 색인한 모든 페이지가 영어판이라, 가장 참여도가 높은 한국 사용자의 검색 유입이 90일 내내 사실상 없었습니다. 영어 브라우저는 Accept-Language 헤더로 계속 영어를 받으므로 바뀌는 것은 사실상 크롤러뿐입니다. 전환 6주 뒤부터 “오목 코드” 검색 유입이 생기기 시작했습니다.
게임 화면 네 곳에 전략 해설을 붙였습니다. 해설이 말하는 성적은 전부 실제 규칙 엔진으로 측정했고, 그 숫자는 저장소의 테스트가 배포 때마다 다시 확인합니다. 측정 과정에서 몇 가지를 발견했습니다. 오목은 “열린 줄과 막힌 줄의 구분” 하나를 넣자 LEVEL 1 전패가 전승이 됐고, 섯다는 더 정교하게 만든 쪽이 더 나빴습니다(너무 자주 죽으면 상대가 그 틈을 파고듭니다).
홈의 “게임 방식” 섹션을 글 설명 대신 실제로 도는 가위바위보 코드와 검증된 성적으로 바꿨습니다.
마케팅 선행 정비: 정적 파일 압축(게임 화면 첫 방문 약 3.2MB가 912KB로), 게임별 공유 카드, 브랜드가 보이는 404 화면.

2026년 8월 23일 — 개발자 행사 문의 동선#

행사 활용을 설명하는 안내 화면(/events)과, 내용이 미리 채워진 문의 메일 양식을 만들었습니다. 과거 행사 아카이브 화면의 색인·공유·모바일 결함(잘못된 canonical, 빈 공유 카드, viewport 누락)도 이때 고쳤습니다.

2026년 8월 30일 — 코딩 에이전트용 스펙#

게임별 스펙이 /specs/omok 같은 고정 주소에서 markdown으로 제공되고, /llms.txt가 네 스펙을 나열합니다. 스펙은 사람이 보는 화면과 같은 출처(locale 키, 샘플 코드 파일)에서 만들어지므로 어긋나지 않습니다. 검증 기준은 하나였습니다. 스펙만 받은 에이전트가 실격 없는 코드를 한 번에 내는가. 네 게임 모두에서 확인했습니다. 홈과 행사 안내의 메시지도 “직접 코딩 전제"에서 “에이전트 환영"으로 바꿨습니다.

2026년 9월 6일 — 마케팅 계획과 운영 준비#

9년 만에 처음으로 마케팅 계획을 세웠습니다. 목적은 매출이 아니라 노출, 매력 검증, 그리고 마케팅이라는 행위를 직접 해 보는 훈련입니다. 이날 한 일은 준비까지입니다. 지표 기준선을 기록하고, 주 1회 운영 루프와 기록 구조를 만들었으며, 첫 캠페인으로 “코딩 에이전트에게 오목 스펙만 주고 받은 코드를, 사람이 화면에서 배우는 최선의 전략과 붙여 보는” 실험을 정했습니다. 실험 코드와 측정도 다음 날까지 마쳤지만, 외부에 글을 올리는 실제 마케팅은 아직 시작하지 않았습니다.