게임 서버 개발자가 실무에서 AI 코딩 도구를 써본 후기 (Kiro·Claude·DeepSeek)

AI DEVELOPMENT · 실무 후기

게임 서버 개발자가 실무에서
AI 코딩 도구를 써본 후기

Kiro · Claude · DeepSeek — 잘되는 것과 안 되는 것, 그리고 검증의 이유

#PHP #게임서버 #AI코딩 #백엔드

안녕하세요. PHP와 MySQL, Redis, AWS로 모바일 게임 서버를 개발·운영하는 개발자입니다.

요즘 "AI로 코딩한다"는 글은 많지만, 대부분 간단한 예제거나 체험기 수준이더군요. 그래서 저는 실제 운영 중인 게임 서버 코드에 AI를 써본 경험을 정리해보려 합니다. 잘되는 것뿐 아니라 안 되는 것, 그리고 "AI가 짠 코드를 왜 반드시 검증해야 하는지"까지 솔직하게 적겠습니다.

왜 AI를 개발에 쓰기 시작했나

반복적인 CRUD 코드, 비슷비슷한 SQL 쿼리, 로그 파싱 스크립트 같은 걸 매번 손으로 짜는 게 아까웠습니다. 핵심 로직에 집중하고 싶었고, 단순 작업은 AI에게 넘겨보기로 했습니다. 처음엔 "코드를 대신 짜주는 도구" 정도로 봤는데, 쓸수록 디버깅과 트러블슈팅의 동반자에 더 가깝다는 걸 알게 됐습니다.

제가 쓰는 AI 도구와 역할 분담

도구마다 잘하는 영역이 달라서, 상황에 따라 나눠서 씁니다.

DeepSeek

일상적인 PHP·SQL 코드 작성과 수정, 반복 작업

Claude

복잡한 설계, 리팩터링, 최종 검토

Codex

코드 수정·검증 등 Agent 작업

Kiro

코드베이스 전체 분석과 다중 파일 수정

한마디로 빠르고 가벼운 작업은 DeepSeek, 머리 아픈 설계·검토는 Claude로 나눕니다.

실제로 이렇게 썼습니다 — 트러블슈팅 사례

말로만 하면 체험기와 다를 게 없으니, 실제로 문제를 고칠 때 AI를 어떻게 썼는지 보여드리겠습니다. 모든 코드는 일반화된 예시입니다.

문제를 고칠 때 AI를 끼워 넣는 흐름

증상 포착 → AI로 원인 분석 → 수정안 작성 → 직접 검증 → 반영

사례 1 — 반복문 안에서 쿼리를 날리던 느린 API (N+1)

특정 목록 API의 응답이 유독 느렸습니다. 코드를 AI에게 주고 "이 로직에서 쿼리가 몇 번 나가는지, 느린 원인을 짚어줘"라고 물었더니, 반복문 안에서 매번 쿼리를 날리는 구조를 바로 지적해줬습니다.

Before — 유저 수만큼 쿼리가 나감

// 목록을 돌면서 매번 조회 → 100명이면 쿼리 100번
foreach ($user_ids as $uid) {
    $row = get_user_name($uid); // 내부에서 SELECT 1번
    $result[] = $row;
}

After — 한 번에 모아서 조회

// IN 절로 한 번에 조회 → 쿼리 1번
$ids  = implode(',', array_map('intval', $user_ids));
$rows = fetch_all("SELECT user_id, nickname FROM user WHERE user_id IN ({$ids})");

// user_id => nickname 형태로 매핑해서 사용
$map = [];
foreach ($rows as $r) { $map[$r['user_id']] = $r['nickname']; }

쿼리 횟수를 수십 번에서 한 번으로 줄이자 체감 응답 속도가 확연히 빨라졌습니다. 원인 자체는 전형적인 N+1이었지만, AI가 코드를 읽고 "어디서 몇 번 나가는지"를 빠르게 정리해준 덕에 진단 시간이 크게 줄었습니다.

사례 2 — 계속 늘어나던 Redis 메모리 (TTL 누락)

캐시로 쓰던 Redis 메모리가 시간이 지날수록 꾸준히 증가했습니다. 키 생성 코드를 AI에게 보여주고 "메모리가 계속 늘어나는 원인이 될 만한 부분을 찾아줘"라고 했더니, 만료 시간(TTL) 없이 키를 쌓고 있던 지점을 짚어줬습니다.

// Before: TTL 없이 저장 → 안 지워지고 계속 쌓임
$redis->set($key, $value);

// After: 만료 시간을 함께 지정
$redis->setex($key, 300, $value); // 5분 뒤 자동 만료

임시성 데이터인데도 TTL이 빠져 있던 게 원인이었습니다. 바로잡은 뒤 메모리 증가 곡선이 안정됐습니다. 이런 "코드만 보면 멀쩡한데 운영에서 서서히 문제되는" 패턴을 찾을 때 AI가 꽤 쓸모 있었습니다.

사례 3 — 인덱스를 안 타던 날짜 조건

조회가 느린 쿼리가 있어서 AI에게 EXPLAIN 관점으로 봐달라고 했더니, 컬럼을 함수로 가공해서 인덱스를 못 타는 조건을 지적해줬습니다.

-- Before: 컬럼을 가공 → 인덱스 사용 불가
WHERE DATE(created_at) = '2026-01-01'

-- After: 범위 조건으로 변경 → 인덱스 활용
WHERE created_at >= '2026-01-01 00:00:00'
  AND created_at <  '2026-01-02 00:00:00'

다만 AI의 제안을 그대로 반영하진 않았습니다. 실제 데이터로 EXPLAIN을 확인해 인덱스를 제대로 타는지 검증한 뒤에 적용했습니다.

AI가 잘하는 것 vs 못하는 것

✅ 잘하는 것

• 반복 코드 생성
• 초안 잡기 (함수 구조, 테스트 틀)
• 낯선 문법·라이브러리 빠르게 확인
• 긴 코드에서 의심 지점 빠르게 짚기

⚠️ 못하거나 위험한 것

• 서비스만의 도메인 맥락 (게임 경제, 지급 규칙)
• 운영 환경의 숨은 제약 (동시성, 트랜잭션 경계)
• 최종 책임 — 버그 책임은 AI가 아니라 개발자

그래서 AI 코드는 반드시 검증합니다

한번은 AI가 짜준 쿼리가 문법은 완벽했는데, 서비스 특유의 DB 구성 규칙을 몰라서 특정 조건에서 잘못된 대상을 조회하는 코드였습니다. 테스트에서 바로 걸렸지만, 그대로 올렸다면 큰일 날 뻔했죠.

AI는 문맥을 모르는 아주 빠른 주니어에 가깝습니다. 방향은 잘 잡아주지만, 결과물은 반드시 사람이 리뷰해야 합니다.

개발 시간은 실제로 얼마나 줄었나

30~40%

반복 작업·초기 원인 분석 기준 체감 시간 단축

특히 "원인이 어디쯤인지 좁히는" 초반 단계가 빨라져서, 그만큼 설계와 검증에 더 집중할 수 있게 됐습니다.

결론 — AI는 대체가 아니라 증폭기

개발자 × AI = 생산성 증폭

• 단순 작업·원인 분석은 AI가 → 개발자는 핵심 로직·설계에 집중
• AI 결과물은 반드시 사람이 검증
• 중요한 건 "AI를 얼마나 잘 쓰느냐"가 아니라 "AI가 짠 걸 판단할 수 있는 실력"

앞으로도 게임 서버 개발·운영에서 AI를 실제로 써본 경험을 계속 정리해 올리겠습니다. PHP, MySQL, Redis, AWS 관련 글도 이어질 예정이니 관심 있으시면 종종 들러주세요.

PHP · MySQL · Redis · AWS 개발 및 성능 개선 문의

댓글로 편하게 남겨주세요.