넷마블넥서스의 AI 코딩 도구 도입기 – 게임 개발팀의 Kiro 도입 및 활용 여정

생성형 AI는 현재 다양한 영역에서 활용되고 있습니다. 그 중 많은 조직에서 적극적으로 도입 및 활용하고 있는 것이 바로 AI 코딩 도구 또는 AI 코딩 어시스턴트라고 불리는 코드 작성을 돕는 AI 도구입니다.

이미 시장에는 다양한 제품들이 나와 있고, 더 이상 AI 코딩 도구를 사용하는 방법 자체가 어려운 시기는 아닙니다. 그러나 개인적으로 AI 코딩 도구를 사용하여 생산성을 향상시키는 것과, 이를 개발 조직 전체에 적용하는 것은 전혀 다른 문제입니다.

작년까지만 해도 게임 개발팀, 특히 프로그래머들 사이에서는 ‘복잡한 게임 코드를 AI가 분석해 쓸 만한 품질의 코드를 만들어 내기는 아직 어렵다’는 인식이 우세했습니다. 모델과 도구의 성능이 빠르게 올라간 지금은 옛말이 되었지만, 도입을 검토하던 당시에는 이 인식이 가장 큰 장벽이었습니다.

이 글에서는 이런 알려진 어려움들을 넘어 실제로 게임 개발 조직에 AI 코딩 도구를 성공적으로 도입하기 위해서 어떤 노력들이 필요한지, 넷마블넥서스 개발팀의 사례를 통해 알아보겠습니다.

많은 조직의 현실 – AI 코딩 도구 도입을 가로막는 장애물들

2026년 하반기 현재 많은 게임 개발팀들도 비슷한 상황이겠지만, 1년 전 넷마블넥서스의 상황은 다음과 같았습니다.

경영진은 생성형 AI를 활용한 생산성 향상에 많은 관심을 가지고 있음
개발자들 중 일부는 적극적으로 AI를 활용하나, 대부분의 개발자들은 단순한 AI 챗봇 서비스를 검색엔진 수준으로만 활용하고 있는 정도
- AI 코딩 도구를 어떻게 활용하여야 할지에 대해 잘 모르고 있는 상태
- 기존 AI 코딩 도구 사용 경험이 좋지 않았음
- 게임 개발 도메인의 특수성

이 중 AI 코딩 도구의 도입을 가로막는 결정적인 장애물이었던, 당시 개발자들의 상황에 대해 조금 더 자세히 알아보겠습니다.

사실 AI 코딩 도구를 잘 사용하기 위해서는 어느 정도 이상의 학습과 경험이 반드시 필요한데, 대부분의 조직에는 이를 위해 낼 수 있는 여유가 많지 않다 보니 ‘지금의 AI 코딩 도구는 어느 정도 수준의 결과물을 낼 수 있는가?’에 대해 충분히 경험할 시간이 없었습니다.

또한 실제로 호기심을 가지고 AI 코딩 도구를 사용해 보았을 때도, AI가 만들어내는 결과물의 품질이 좋지 않았던 경험이 있다 보니 부정적인 인식이 널리 퍼져 있었습니다. 당시만 해도 AI가 그럴듯해 보이는 코드를 내놓지만 실제로는 동작하지 않거나, 미묘하게 잘못된 답을 자신 있게 제시하는 경우를 개발자들이 자주 경험했기 때문입니다.

마지막으로, 게임 개발이라는 도메인의 특수성도 있습니다. 게임 서버, 클라이언트, 툴, 콘텐츠 등 팀마다 사용하는 기술 스택과 도메인 지식이 크게 달라서, 한 팀에서 통하던 활용 방식이 다른 팀에는 그대로 적용되지 않았습니다. 또한 웹이나 일반 업무용 소프트웨어에 비해 게임 산업은 상대적으로 폐쇄적이고 코드가 공개되는 경우가 드물어, AI가 학습할 수 있는 게임 특화 데이터 자체가 부족하다는 인식도 강했습니다.

이러한 이유들이 겹치면서 ‘우리 코드에는 AI가 별로 도움이 안 될 것’이라는 전반적인 믿음 부족으로 이어졌습니다. 즉 도입을 가로막은 것은 전체적인 AI에 대한 신뢰의 부족이기도 했던 것입니다.

조직 내 도입을 위해 중요한 선행 요소 – 내부 전파를 위한 챔피언 선정, 경영진의 후원

이런 개발팀에 AI 코딩 도구를 도입하기 위해, 먼저 경영진과 AWS 게임팀 SA들은 AI 코딩 도구가 ‘실제 내 업무에 얼마나 도움이 되는지’를 직관적으로 확인할 수 있는 다양한 Demo를 포함한 교육을 진행하였습니다.

하지만 이것만으로는 부족했습니다. 이런 교육만으로 끝났다면 여전히 관심을 가진 몇몇 개발자들만이 개인적으로 활용해 보는 정도에서 그쳤을 것입니다.

이를 극복하기 위해, 개발팀은 내부에서 AI 코딩 도구를 적극적으로 활용할 수 있는 개발자들을 ‘챔피언’으로 선정하여, 더 많은 시간을 들여 AI 코딩 도구를 활용하는 법을 익히도록 도왔습니다. 특히 이 과정에서 Kiro에서 작업 품질을 높이기 위해 반드시 필요한 Steering 파일을 작성하는 데 많은 노력을 기울였습니다. 특히 Kiro는 이런 Steering 파일들을 프로젝트 단위로 조직 내에서 공유하여 직관적으로 사용하기에 편리하게 되어 있으므로 이렇게 작성된 Steering 파일이 버전 컨트롤 도구를 통해 자동으로 개발팀 내에 공유됩니다.

이를 통해 도구 활용법을 잘 모르는 개발자들도 Steering 파일이 알아서 프로젝트에 관련된 지식 범위 안에서 보다 정확한 답변을 유도함으로써 코드를 더 잘 분석하고, 더 높은 품질의 코드를 작성할 수 있게 도왔습니다. 이런 경험을 통해 잘 모르던 개발자들도 AI 코딩 도구의 효용성을 보다 크게 체감할 수 있게 되었고, 이후 자발적으로 AI 코딩 도구를 적극 활용함으로써 전체 조직의 생산성이 올라가는 결과로 이어질 수 있었습니다.

실제로 이 과정에서 기존에 대부분의 게임 개발팀처럼 Visual Studio를 사용하던 개발자들의 대부분이 자연스럽게 Kiro IDE를 사용하게 된 것도 Steering을 통한 조직 단위의 생산성 향상이 실무자들의 자발적 참여를 이끌어낼 수 있다는 주장을 뒷받침합니다.

이런 전파 과정이 원활하게 이루어질 수 있도록 경영진 역시 챔피언의 AI 학습 및 팀을 위한 공유 활동을 업무로 인정해 주고, 별도의 시간을 할애하여 관심 있는 사람들이 정기적으로 만나서 사례를 공유할 수 있는 자리도 마련해 주는 등 자연스러운 확산이 가능하도록 지원하였습니다.

또한 AI 코딩 도구의 도입 순서도 중요한데요. 아무리 중요도가 높다고 해도 코딩 도구 도입이 기존 개발 작업보다 우선순위가 높을 수는 없습니다. 이 때문에 경영진은 Kiro의 첫 도입을 현재 라이브 서비스 중인 게임이 아닌 신규 개발중인 게임으로 정했습니다. 아무래도 신규 개발중인 게임은 외부 배포를 위한 마감의 압박이 덜하기 때문에 상대적으로 편안하게 새로운 도구를 실험하고 결과를 검증할 수 있었기 때문입니다.

실무자가 챔피언이어야 하는 이유 – 도메인 지식의 중요성

특히 많은 조직이 외부에서 AX(AI Transformation) 전문가를 영입하여 내부에 교육 및 전파를 통해 성공적인 도입을 기대하곤 하지만, 이 사례에서는 실무자가 챔피언이었던 것이 매우 중요한 성공 요인이었습니다.

실무자가 챔피언이어야 했던 이유는 분명했습니다. 많은 AX 관련 교육이 도구를 어떻게 잘 사용하는가에 집중하지만, 이것은 ‘어떻게’이지 ‘왜’는 아닙니다. AX 전문가가 게임 개발 전문가인 경우는 많지 않고, 내 업무의 생산성을 올리는 방법을 정확하게 제시할 확률도 낮습니다. 결국 지금 여기 있는 내 업무의 생산성을 올릴 수 있다는 기대가 없다면 호기심만으로는 모든 사람이 움직이기 어렵습니다.

실무자 챔피언은 AI 코딩 도구의 활용법에 대한 고민보다 실제 업무에서 불편했던 점들을 개선하는 것에 집중했고, 그 과정에 필요한 도메인 지식(게임 개발 관련 지식, 팀의 업무 프로세스 관련 지식)을 충분히 가지고 있었으므로 결과물의 ‘실효성’이 높았으며, 이런 결과물들이 실제로 업무 생산성을 올리는 것을 직접 경험한 팀원들이 AI 코딩 도구를 활용하는 것에 더 긍정적인 생각을 가지게 될 수 있었기 때문입니다. 실무자 눈높이에 맞는 교육 역시 챔피언이 진행하여, 학습의 어려움 역시 줄일 수 있었습니다.

실제로 개발자들의 인식이 결정적으로 바뀐 계기는, 같은 도구라도 사용하는 방식에 따라 실제 결과물의 품질이 크게 달라진다는 것을 직접 확인하면서부터 였습니다. 아무런 지침 없이 AI에게 맡겼을 때와, 프로젝트의 규칙과 맥락을 담은 룰(rules)을 정의해준 뒤 작업을 시켰을 때의 결과물 차이를 눈으로 비교해 보자, “AI가 못 하는 것”이 아니라 “제대로 알려주지 않아서 못 했던 것”이라는 쪽으로 생각이 옮겨갔습니다. 즉 결과물의 품질이 곧 사람이 AI에게 얼마나 잘 맥락을 제공하느냐에 달려 있다는 점을 체감하게 된 것입니다.

이렇게 한번 도구를 쓰기 시작하자 변화는 자연스럽게 번져 나갔습니다. 개발자들은 각자 겪은 문제와 잘 통했던 활용법, 개선하면 좋을 점들을 서로 공유하기 시작했고, 이런 경험이 쌓이면서 도구를 더 잘 쓰기 위한 노하우가 팀 안에서 빠르게 축적되었습니다. 반신반의하던 분위기가 “어떻게 하면 더 잘 쓸 수 있을까”를 함께 고민하는 분위기로 바뀐 것입니다.

그림 1. 챔피언이 직접 진행한 교육 자료 중 일부. AI가 왜 그런 결과를 내놓는지를 먼저 이해시키는 데 시간을 썼습니다.

그림 2. 챔피언이 직접 진행한 교육 자료 중 일부. Rule(Steering)을 작성해야 하는 이유와 작성하는 요령을 이해시켜, 지속적으로 팀이 실제로 필요한 내용을 정리해서 개선해 나갈 수 있도록 하였습니다.

교육에서 가장 반응이 좋았던 것은 개념 설명이 아니라 실제 작성된 코드를 놓고 만든 결과물이었습니다. 예를 들어 회원 탈퇴 시 클랜을 어떻게 처리해야 하는지는 API 서버와 게임서버, DB가 얽혀 있어서 말로 설명하기 번거로운 주제입니다. 마스터가 탈퇴하는 경우와 일반 클랜원이 탈퇴하는 경우의 처리 순서가 다르고, 어느 쪽이 DB를 건드리고 어느 쪽이 메모리만 건드리는지도 갈립니다.

이런 흐름을 AI가 코드에서 직접 읽어내 다이어그램으로 정리해 주자, “이건 나도 쓸 수 있겠다”는 반응이 바로 나왔습니다.

그림 3. AI가 만들어 주는 mermaid 다이어그램 예시. 이런 식으로 실제 코드의 이해를 빠르게 할 수 있다는 것을 알게 되면서 조직원들이 AI 코딩 도구의 유용성을 더 실감하게 되었습니다.

조직의 생산성을 향상시킨 열쇠, Steering 파일은 어떻게 만들어졌나 – AI 이전에 중요한 ‘개발 문화’의 힘

Steering 파일은 “우리 프로젝트에서는 이렇게 해줘”라는 규칙과 배경지식을 정리해 둔 문서로, AI가 실제 코드의 맥락에 맞는 결과물을 내놓게 해주는 핵심 장치입니다. 그런데 이 파일을 잘 만드는 일이 결코 간단하지는 않았습니다. 개발팀이 Steering 파일을 완성해 나간 과정에는 몇 가지 중요한 밑바탕이 있었습니다.

첫째, 그동안 잘 정리해 둔 레거시 문서들이 큰 도움이 되었습니다. 오랜 시간 쌓아온 개발 규칙, 아키텍처 설명, 시스템 정리 문서들이 이미 존재했기 때문에, 이를 AI가 이해하기 좋은 형태로 재구성하는 것만으로도 상당한 수준의 Steering 파일을 빠르게 갖출 수 있었습니다. 평소의 문서화 습관이 결국 AI 도입의 자산이 된 셈입니다.

둘째, 시니어 프로그래머들이 서로 교차 검증하며 규칙을 다듬었습니다. 한 사람이 작성한 규칙을 다른 시니어들이 함께 검토하면서, 표현이 모호하거나 팀마다 해석이 갈릴 수 있는 부분을 걸러냈습니다. 이 과정을 통해 특정 개인의 습관이 아니라 팀이 합의한 기준이 규칙에 담기게 되었고, 규칙 자체의 신뢰도도 높아졌습니다.

셋째, 실제로 적용해 쓰면서 끊임없이 다듬어 나갔습니다. Steering 파일은 한 번 만들고 끝나는 문서가 아니었습니다. 실무에서 AI와 함께 작업하다 보면 규칙이 부족하거나 어긋나는 지점이 드러났고, 그때마다 규칙을 보완했습니다. 이렇게 사용과 개선을 반복하면서 Steering 파일은 점점 더 개발 중인 프로젝트에 꼭 맞는 형태로 정교해졌습니다.

AI 도구의 활용도 중요하지만 기본적인 팀의 개발 문화가 받쳐줘야 그 효과가 더 커진다는 점은 중요하지만 실제로는 자주 간과되곤 합니다. 하지만 이런 요소들이 결국 실제 조직 단위의 AI 코딩 도구 도입 성공 및 생산성 향상에 결정적인 열쇠가 되었습니다.

규칙을 다듬는 일을 사람 기억에 맡기지 않았다

Steering 파일을 지속적으로 개선하겠다는 다짐은 쉽지만, 실제로는 잘 안 됩니다. 작업이 끝나면 다음 작업으로 넘어가지, “아까 AI가 뭘 틀렸더라”를 되짚어 규칙을 고치는 사람은 없습니다. 개선이 개인의 성실함에 달려 있으면 오래 못 갑니다.

그래서 이 회고를 자동화했습니다. 에이전트 작업이 끝나는 시점에 훅을 걸어, 그 세션에서 의미 있는 작업이 있었으면 AI가 스스로 세션 로그를 남기게 했습니다. 이때 “무엇을 했는가”만 적게 하지 않고, “어디서 틀렸는가”와 “규칙에 추가할 것은 무엇인가”를 반드시 적게 한 것이 핵심입니다.

{
  "name": "AI 세션 로그 취합",
  "when": { "type": "agentStop" },
  "then": {
    "type": "askAgent",
    "prompt": "이번 대화 세션을 분석하여 로그 파일 생성 여부를 판단해줘.
      - 코드 수정, 버그 수정, 기능 구현 등 의미 있는 작업이 있었으면 → 로그 생성
      - 단순 질문/답변, 설명 요청만 했으면 → 건너뛰기

      ### 발생한 문제 / 실수
      - 컴파일 에러, 타입 불일치, 로직 오류
      - AI가 잘못 생성한 코드 패턴 (CREATE 매크로 오용, 네이밍 규칙 위반 등)
      - 반복적으로 수정이 필요했던 부분

      ### 개선 포인트
      - steering 규칙에 추가하면 좋을 사항
      - 자주 실수하는 패턴에 대한 방지책"
  }
}

이 훅을 붙인 뒤 작업 로그가 50건 이상 쌓였고, 그중 “개선 포인트”에 적힌 항목들이 실제 규칙 변경으로 이어졌습니다. 함수 배치 원칙 추가, Validator 검증 체크리스트 추가, 조건부 로딩으로 변경, 중복 규칙 통합 정리 같은 변경들이 모두 이 로그에서 출발했습니다. 규칙 문서의 커밋 이력이 곧 개발팀이 AI와 부딪힌 지점의 기록이 된 셈입니다.

특히 재미있었던 것은 ‘함수 배치 원칙’입니다. AI에게 새 기능을 맡기면 자꾸 새로운 유틸리티 함수나 새 클래스를 만들어 냈습니다. 동작은 하지만 실제 코드베이스의 응집도를 갉아먹는 방향이었죠. 로그를 보니 같은 문제가 반복되고 있어서, 규칙을 이렇게 바꿨습니다.

* 새 함수 추가 시, 기존 코드에서 동일 도메인의 유사 함수가
  어디에 위치하는지 먼저 탐색할 것
* 기존 클래스에 같은 패턴의 멤버 함수가 있으면 해당 클래스에 추가
  (예: `Item::IsConsumable()` 패턴이 있으면 `Item` 클래스에 추가)
* 독립 유틸리티 함수는 기존 클래스에 넣기 부적절한 경우에만 사용

한 줄짜리 규칙 세 개지만, 이후 AI가 만들어내는 코드의 구조가 눈에 띄게 개발 팀의 코드에 가까워졌습니다.

Steering 파일은 어떻게 구성했나

처음에는 규칙을 한 파일에 몰아 넣었습니다. 그런데 파일이 커지자 AI가 앞부분 규칙을 놓치거나, 전투 작업 중인데 DB 규칙까지 함께 읽으면서 엉뚱한 맥락을 끌어오는 일이 생겼습니다. 그래서 역할에 따라 문서를 쪼개고, 각 문서가 언제 읽힐지를 명시하는 방식으로 정리했습니다.

Server/.kiro/
├── steering/
│   ├── server_dev_guideline.md      # 항상 로딩. 코딩 규칙·레거시 패턴·DB 패턴 (메인)
│   ├── battle_system.md             # 전투 시스템 구조
│   ├── battle_fsm.md                # 전투 상태 머신
│   ├── battle_skill_flow.md         # 스킬 처리 흐름
│   └── battle_table_relations.md    # 전투 관련 테이블 관계
├── docs/                            # steering이 참조하는 상세 문서
│   ├── database-guide.md
│   ├── server-architecture.md
│   ├── code-review-checklist.md
│   └── ...
├── specs/                           # 기능별 요구사항·설계·태스크
└── hooks/                           # 자동화 훅

문서를 나눌 때 기준으로 삼은 것은 “이 문서가 답하는 질문이 무엇인가”였습니다.

역할	답하는 질문	로딩 방식
메인 가이드라인	무엇을(What) 지켜야 하는가	항상
아키텍처 문서	왜(Why) 이렇게 설계했는가	필요할 때 참조
작업 가이드라인	어떻게(How) 진행할 것인가	필요할 때 참조
도메인 문서	이 시스템은 어떻게 동작하는가	해당 도메인 작업 시

메인 가이드라인은 항상 로딩되도록 front-matter에 명시하고, 나머지는 참조 링크로 연결해 필요할 때만 읽히게 했습니다. 이렇게 하면 항상 들어가는 컨텍스트의 양을 통제하면서도, 깊은 정보가 필요한 순간에는 AI가 스스로 상세 문서를 찾아갑니다.

---
inclusion: always
---

# 프로젝트 서버 개발 가이드라인

> 코딩 규칙, 레거시 패턴, 패킷/DB 개발 패턴을 통합한 메인 가이드라인

## 1. 필수 룰
* 한글로 대답할 것
* C++ XX 기준
* 수정 대상 파일은 VCS에서 체크아웃을 먼저 해줄 것
* 코드 수정이 있는 경우, 적용 여부 확인 물어볼 것
* 코드 개행문자는 CRLF, 기본 인코딩은 UTF-8 with BOM
  (기존 파일 수정 시 해당 파일의 인코딩 유지)

## 참조 문서
- `database-guide.md` - Database 개발 상세 가이드
- `server-architecture.md` - 서버 아키텍처 및 스레드 모델
- `code-review-checklist.md` - 코드 검토 및 컴파일 체크리스트

규칙은 ‘금지형 + 대비 예시’로 써야 통했다

가장 효과가 컸던 형식은 “이렇게 해라”가 아니라 “이건 틀렸고, 이게 맞다”를 나란히 보여주는 것이었습니다. 개발 중인 프로젝트는 20년 가까이 쌓인 레거시 관례가 많은데, AI는 일반적인 C++ 관용구를 자신 있게 써버립니다. 문법적으로는 맞지만 실제 코드에서는 컴파일이 안 되는 코드죠.

예를 들어, 프로젝트의 CREATE 매크로는 가변 인자 매크로라서 템플릿 문법이나 함수 호출 문법을 쓰면 안 됩니다. 그런데 AI는 std::make_shared에 익숙하니 계속 템플릿 문법으로 썼습니다. 싱글턴도 마찬가지로, 기존 코드에서는 GetInstance()가 포인터를 반환하는데 AI는 관성적으로 점 연산자를 붙였습니다. 이 두 가지는 AI가 가장 자주 틀리던 패턴이라, 아예 오답을 명시하는 형태로 규칙에 넣었습니다. (아래 예시의 매크로와 클래스 이름은 일반화한 것입니다.)

CREATE 매크로 (std::shared_ptr)

// 정의: #define CREATE(cls, ...) std::make_shared<cls>(__VA_ARGS__)
auto data = CREATE(ClassName);                    // ✓ 기본 생성자
auto data = CREATE(ClassName, arg1, arg2, arg3);  // ✓ 매개변수 생성자
auto data = CREATE<ClassName>();                  // ❌ 템플릿 문법
auto data = CREATE(ClassName)(arg1, arg2);        // ❌ 함수 호출 문법

싱글턴 패턴

GetInstance()는 포인터를 반환하므로 화살표 연산자 사용

SomeManager::GetInstance()->DoSomething();   // ✓ 화살표 연산자
SomeManager::GetInstance().DoSomething();    // ❌ 점 연산자

로깅 매크로

신규/수정 코드에서는 fmt 기반 FLOG_* 사용 (타입 안전)

LOG_INFO(hostID, uid, "groupID:% rank:%", groupID, rank);   // ❌ 레거시
FLOG_INFO(hostID, uid, "groupID:{} rank:{}", groupID, rank); // ✓ 신규

이 방식이 통한 이유는 명확합니다. 금지형만 있으면 AI가 대체 수단을 스스로 발명하고, 권장형만 있으면 기존 습관을 못 버립니다. 둘을 나란히 놓아야 판단 기준이 생깁니다.

위험한 작업에는 명시적 금지선을 그었다

규칙에는 코딩 스타일만 담지 않았습니다. 사고가 날 수 있는 영역에는 AI가 넘지 말아야 할 선을 분명히 적었습니다. 대표적인 것이 Stored Procedure입니다. DB 스키마와 SP는 여러 서비스가 공유하고 DBA 검수 대상이기도 해서, AI가 직접 손대면 파급이 큽니다.

* **SP 직접 수정 금지**: Stored Procedure는 절대 직접 수정하지 않음.
  변경 필요 시 변경 이유, 전/후 SQL 예시, 연관 C++ 코드 변경사항만 제공
* 작업 경로 제한: 현재 디렉토리 + 하위, ./../Common 밖은 참조하지 않음
* 수정 대상 파일은 VCS에서 체크아웃을 먼저 수행

덕분에 AI는 SP(Stored Procedure) 변경이 필요한 상황에서 파일을 고치는 대신 “이 SP를 이렇게 바꿔야 하고, 그러면 C++ 쪽 타입은 이렇게 바뀝니다”라는 제안서를 만들어 왔습니다. 사람이 검토하고 DBA에 전달하는 흐름이 자연스럽게 만들어졌고, 실제로 이 형태의 제안서가 여러 건 그대로 반영되었습니다.

컴파일 전 체크리스트 — AI에게 자기 검토를 시키기

규칙이 있어도 AI는 실수합니다. 그래서 자주 반복된 실수를 체크리스트로 만들어 규칙 안에 넣고, 코드를 넘기기 전에 스스로 훑게 했습니다. 이 목록은 처음부터 설계한 게 아니라, 실제로 컴파일이 깨졌던 사례가 쌓이면서 한 줄씩 늘어난 것입니다.

## 컴파일 전 체크리스트
- [ ] CREATE 매크로 문법 (`CREATE(Class, args)`)
- [ ] 싱글턴 접근 연산자 (`->`)
- [ ] 필요한 include 추가 / proto 메시지 정의 완료
- [ ] Holder 클래스에서 PlayerObject 멤버 제거
- [ ] 함수 시그니처 일치성: 선언(.h)/정의(.cpp)/호출부의 매개변수 수·타입·순서
- [ ] 함수 구현 완결성: find 결과를 end()와 비교 후 역참조,
      모든 분기에서 올바른 값 반환
- [ ] 새 메타데이터 필드 추가 시 해당 도메인 Validator에 정합성 검증 추가 여부

특히 마지막 항목은 규칙이 어떻게 진화하는지를 잘 보여줍니다. 조각형 소모 아이템 기능을 작업하다 메타데이터 필드를 추가했는데, 정합성 검증을 담당하는 Validator 클래스에 검증 함수를 넣는 것을 AI가 빠뜨렸습니다. 사람도 자주 빠뜨리는 부분이었죠. 그 자리에서 규칙에 한 줄을 추가했고, 이후 같은 작업에서는 AI가 먼저 “Validator에 검증 함수도 추가할까요?”라고 물어왔습니다.

검증된 규칙을 팀 전체로 배포하는 방법

Steering 파일은 프로젝트 디렉토리 안에 텍스트로 존재하므로 버전 관리 대상이 됩니다. 개발팀은 검증이 끝난 규칙 세트를 문서 디렉토리에 배포용으로 올려두고, 각자가 자신의 작업 공간에 가져다 쓰는 방식을 택했습니다.

Server/docs/
├── kiro_steering/          # Kiro 사용자용 배포 세트
│   ├── steering/           # 프로젝트 공통 규칙
│   ├── skills/             # 목적별로 분리한 지식 모듈
│   └── readme.txt          # "steering, skills 폴더를 Server/.kiro 에 복사해서 사용"
└── amazonq_rules/          # 기존 도구 사용자용 세트 (전환기 병행 운영)

핵심은 규칙이 코드와 같은 저장소에서 같은 리비전으로 흐른다는 점입니다. 브랜치를 받아오면 규칙도 함께 최신이 되고, 규칙 변경 이력도 코드 변경 이력과 같은 방식으로 추적됩니다. 규칙을 별도 위키나 사내 문서 시스템에 두었다면 절대 이렇게 되지 않았을 겁니다.

또 하나 중요했던 것은 전환기를 인정한 것입니다. 기존 도구용 규칙 세트와 Kiro용 세트를 한동안 함께 유지했습니다. 모든 사람이 같은 날 같은 도구로 옮겨갈 수는 없으니까요. 내용은 사실상 같고 담는 형식만 다르기 때문에, 병행 유지 비용은 크지 않았습니다.

Spec – 규칙 위에 올라간 작업 방식

규칙이 안정되자 그 다음 단계로 넘어갈 수 있었습니다. 복잡한 기능은 곧바로 구현하지 않고, 요구사항 → 설계 → 태스크 순서로 문서를 먼저 합의한 뒤 구현에 들어가는 방식(Spec)을 쓰기 시작했습니다.

※ Spec은 Spec-Driven-Development라는, Kiro에 통합하여 지원하는 개발 방식입니다. 실제 구현 전에 요구사항(requirements) → 설계 문서(design) → 작업 목록(tasks)을 만들어 나가는 과정에서 실제 구현의 정확도를 최대한 끌어올리는 방식입니다. 단순히 기획 문서를 상세하게 만드는 과정이 아니라, 스펙 문서를 작성하는 과정 전체를 AI와 함께 진행하기 때문에 작성하는 과정에서 의미없고 시간 소모적인 작업이 줄어들고, 먼저 작성된 스펙 문서들이 다음 스펙 문서와 코드의 정확도를 보조하는 context가 되어 줍니다.

Server/.kiro/specs/
├── login-reservation-race-condition/   # 로그인 예약 레이스 컨디션 수정
│   ├── requirements.md
│   ├── design.md
│   └── tasks.md
├── fragmented-consumable-item/         # 조각형 소모 아이템
├── clan-leader-auto-transfer/          # 클랜장 자동 위임
├── arena-db-withdrawal-filter/         # 탈퇴 계정 필터링
└── ...

효과는 두 가지였습니다. 첫째, 잘못된 방향으로 코드가 잔뜩 만들어지는 일이 줄었습니다. 이견은 코드가 아니라 요구사항 문서 단계에서 드러나니까요. 둘째, 나중에 “이거 왜 이렇게 만들었지”에 답할 문서가 자동으로 남았습니다. 레이스 컨디션 수정처럼 미묘한 작업은 이 기록의 가치가 특히 컸습니다.

한 가지 덧붙이면, 이 방식이 굴러간 것은 Steering 파일이 먼저 자리를 잡았기 때문입니다. 규칙이 없는 상태에서 Spec만 도입하면, 설계는 그럴듯한데 구현이 기존 코드와 어긋나는 결과가 나옵니다. 순서가 중요했습니다.

성공적인 도입의 결과 – 조직 내 추가적인 사용 사례들

MCP 연동으로 넓어진 활용 범위

Steering 파일로 코드 작업의 품질을 끌어올린 데 이어, 개발팀은 MCP(Model Context Protocol) 를 통해 AI가 코드 바깥의 도구들과도 직접 연결되도록 확장했습니다. 대표적인 것이 데이터베이스와 엑셀 연동입니다.

데이터베이스 MCP 연동

AI가 개발용 데이터베이스에 직접 연결되면서, 개발자가 SQL을 일일이 작성하지 않아도 “이 테이블 구조를 정리해줘”, “이 조건에 맞는 데이터를 확인해줘” 같은 요청을 자연어로 처리할 수 있게 되었습니다. 특히 서버 코드와 실제 데이터를 함께 놓고 분석할 수 있어, 코드 로직과 데이터가 서로 맞는지 검증하는 작업이 훨씬 빨라졌습니다.

이를 실제로 활용한 사례는 다음과 같습니다.

서버 로그에 “미션 ID 불일치” 에러가 반복해서 찍히는 상황이 있었습니다. 상점의 미션형 상품을 초기화하는 지점에서 특정 미션 ID들이 계속 실패하는데, 이런 문제는 코드만 들여다봐도 답이 안 나옵니다. 코드는 정상이고 데이터가 어긋난 경우일 수 있으니까요.

예전이라면 DB 툴을 열어 테이블을 찾고, 컬럼명을 확인하고, 기획자에게 시트를 받아 대조하는 왕복이 필요했습니다. MCP로 개발 DB가 연결된 뒤에는 이 과정이 한 대화 안에서 끝났습니다.

AI는 먼저 테이블이 어느 DB에 있는지부터 찾았습니다. 처음 몇 번은 조회 결과의 컬럼 헤더가 깨져 나와 쿼리를 고쳐 다시 시도했는데, 이런 시행착오도 사람이 개입하지 않고 스스로 정리했습니다. 기획 메타 데이터가 담긴 DB를 찾은 뒤 두 테이블을 각각 조회했습니다.

-- 미션형 상품이 참조하는 미션 ID
SELECT 상품ID, 연결미션ID FROM 상품테이블
WHERE 연결미션ID <> 0 ORDER BY 연결미션ID;
--> 51, 52, 53, 54, 69, 70, 71, 72

-- 실제로 정의된 미션
SELECT 미션ID, 미션그룹ID FROM 미션테이블 ORDER BY 미션ID;
--> 1~6, 51~54, 69~74

두 결과를 나란히 놓자 원인이 드러났습니다. 에러가 났던 미션 ID들은 미션 테이블에는 정의되어 있지만, 그 미션을 상품으로 연결하는 행이 상품 테이블에 없었습니다. 코드는 미션을 상품과 연결해 판매 기간을 판단해야 하는데 연결 대상이 없으니 실패한 것입니다. 서버 코드 버그가 아니라 기획 데이터의 정합성 문제였습니다.

여기서 그치지 않고, 같은 자리에서 재사용할 수 있는 진단 쿼리까지 정리되었습니다.

-- 정의는 되어 있지만 어떤 상품도 참조하지 않는 '고아' 미션
SELECT 미션.미션ID, 미션.미션그룹ID
FROM 미션테이블 AS 미션
LEFT JOIN 상품테이블 AS 상품 ON 상품.연결미션ID = 미션.미션ID
WHERE 상품.상품ID IS NULL
ORDER BY 미션.미션ID;

가장 값어치가 있었던 것은 그 다음에 나온 질문이었습니다. “그러면 왜 어떤 상품도 참조하지 않는 미션에 대해 초기화가 호출되었는가?” 데이터 쪽 원인을 확인했으니 이제 코드 쪽을 봐야 한다는 이야기인데, 코드와 데이터가 같은 자리에 있으니 경계를 넘는 추적이 자연스럽게 이어졌습니다. 예전에는 이 지점에서 흐름이 끊기고, DB를 보는 사람과 서버 코드를 보는 사람이 각자 자기 쪽만 확인한 뒤 다시 모여야 했습니다.

이 밖에 자주 쓴 것은 SP 반환 타입과 C++ 매퍼 클래스의 타입 대조입니다. 두 타입이 어긋나면 컴파일은 통과하고 런타임에 값만 조용히 깨지기 때문에 눈으로 찾기 어려운데, 실제 SP 정의를 조회해 필드별로 대조하면 한 번에 끝납니다. 이 경험도 규칙으로 남았습니다.

* 실제 SP를 확인한 후 정확한 타입 매핑, SQL-C++ 타입 일치성 보장
* SP 타입과 C++ 타입 일치 필수 (`int → int32_t`, `bigint → int64_t`)

Excel MCP 연동

기획 데이터나 각종 설정값이 담긴 엑셀 시트를 AI가 직접 읽고 쓸 수 있게 되면서, 데이터 누락이나 오류를 찾아내거나, 여러 시트에 흩어진 정보를 정리해 표로 만드는 작업을 자동화할 수 있었습니다.

개발팀에서 실제로 쓴 대표적인 예는 로그 정의서와 서버 코드의 대조입니다. 어떤 이벤트에 어떤 필드를 남겨야 하는지가 엑셀 시트로 관리되는데, 서버 코드가 실제로 그 필드를 다 채우고 있는지는 사람이 눈으로 맞춰볼 수밖에 없었습니다. 시트 행 수가 늘어나면 사실상 검증을 포기하게 되는 작업이죠.

엑셀 연동 이후에는 AI가 시트를 직접 읽어 정의된 필드 목록을 뽑고, 서버의 로그 기록 코드와 비교해 누락된 필드와 정의서에 없는 필드를 양방향으로 정리해 주었습니다. 스크립트를 따로 만들 필요도, 시트 포맷이 바뀔 때마다 스크립트를 고칠 필요도 없었습니다.

이런 사례 외에, 코드와 DB 스키마를 함께 분석해 정리한 시스템 구조 문서, 특정 기능의 데이터 흐름을 표로 정리한 검증 자료 작성 등 개발 중 다양한 상황에서 이런 MCP를 활용하고 있습니다. 이를 통해 개발자는 반복적인 조회·정리 작업에서 벗어나, 결과를 확인하고 판단하는 데 집중할 수 있게 되었습니다.

물론 이런 도구 연동은 접근 권한과 데이터 보안이 전제되어야 합니다. 개발팀은 실 서비스 데이터가 아닌 개발용 환경에 한정해 연결하고, 민감 정보가 결과물에 노출되지 않도록 관리하면서 활용 범위를 넓혀 갔습니다.

결론 – AI 코딩 도구를 조직의 표준으로 도입하기 위해 필요한 것들, 그리고 실제 활용 경험으로 느낀 것들

지금까지 넷마블넥서스가 개인적인 활용 수준에 그쳤던 AI 코딩 도구를 전체 스튜디오 수준으로 도입하게 된 과정과, 그 과정을 성공하기 위해 어떤 식으로 접근하였는지 알아보았습니다.

성공적인 도입에 필요한 것들

조직 내에 성공적인 AI 도입을 위해서는

팀 내 챔피언 선정을 통해 조직이 AI 코딩 도구를 잘 사용하기 위한 방법을 실제로 수행하고, 업무 개선 사례를 직접 경험함으로써 자발적인 도입 유도
팀의 좋은 개발 문화. 특히 지식 정리와 공유, 그리고 지속적인 개선의 힘
팀의 업무 방식, 코드베이스의 상태에 맞는 Steering 파일 구성
AI의 역량을 확장하기 위한 적절한 MCP 연결

과 같은 것들이 필요함을 알 수 있었습니다.

실제 도입 후 느낀 점

은 총알은 없다

여기까지만 보면 AI 코딩 도구가 모든 문제를 해결해 준 것처럼 보일 수 있지만, 실제로 써보며 가장 크게 느낀 점은 “만능 해결책(은 총알)은 없다” 는 것이었습니다. 생산성과 결과물의 품질이 눈에 띄게 좋아진 것은 분명한 사실이지만, 그와 함께 새로운 고민들도 따라왔습니다.

가장 대표적인 것이 리뷰 부담의 증가입니다. AI가 코드를 빠르게, 많이 만들어내다 보니 정작 사람이 검토해야 할 코드의 양도 함께 늘어났습니다. 생성 속도가 빨라진 만큼 리뷰가 병목이 되지 않도록 신경 써야 했습니다.

또한 AI가 만든 코드를 안심하고 쓰려면 유닛 테스트 도입이 사실상 필수라는 점도 체감했습니다. 다만 오랜 기간 쌓여온 레거시 코드베이스에서 테스트를 처음부터 붙여 나가는 일은 결코 쉽지 않았고, 이는 지금도 풀어가야 할 과제로 남아 있습니다.

흥미로운 변화도 있었습니다. 개발 생산 속도가 워낙 빨라지다 보니, 이제는 오히려 기획이 개발 속도를 따라잡지 못하는 듯한 느낌을 받는 순간까지 오게 된 것입니다. 예전에는 개발이 병목인 경우가 많았지만, 이제는 구현할 내용이 준비되는 속도가 새로운 관건이 되었습니다. 이는 뒤집어 보면 AI 도입으로 개발 생산성이 그만큼 크게 올라왔다는 방증이기도 하며, 앞으로는 기획을 포함한 개발 프로세스 전반을 함께 끌어올려야 한다는 새로운 숙제를 던져 주었습니다.

하지만 그래도 가야 할 이유는 명확하다

그럼에도 불구하고, AI 코딩 도구가 가져다 준 장점은 이런 부담을 감수할 만큼 분명했습니다.

방대한 레거시 코드를 빠르게 분석하고 이해하는 시간이 크게 줄었습니다.
반복적이고 단순한 작업에서 벗어나 핵심 작업에 집중할 수 있게 되었습니다.
도메인 지식이 규칙과 문서로 정리되면서, 팀 전체의 지식 수준이 상향 평준화되었습니다.
개발자들이 서로의 활용법과 개선점을 공유하는 문화가 자리 잡았습니다.

결국 AI 코딩 도구는 사람을 대체하는 것이 아니라, 사람이 더 중요한 일에 집중하도록 돕는 도구였습니다. 한계를 분명히 인식하고 그에 맞는 프로세스(리뷰 체계, 테스트 도입 등)를 함께 갖춰 나갈 때 비로소 제 가치를 발휘한다는 것이 도입 이후 가장 크게 얻은 교훈이었습니다.

앞으로 나아갈 방향

현재 넷마블넥서스는 Kiro 도입에서 그치지 않고, 개발자들이 이를 활용하여 게임 개발 프로세스를 개선하여 더 좋은 게임을 만들 수 있도록 노력 중입니다. AI 코딩 도구의 활용을 넘어서, 게임 개발 프로세스 자체에 AI를 활용한 프로토타이핑 및 업무 자동화를 적극 도입하게 되면 게임 개발자들은 그동안 발목 잡혀 왔던 단순 작업이나 복잡도 관리 등에서 벗어나 재미있는 게임을 만들기 위한 핵심 작업에만 집중할 수 있습니다. 성공적인 AI 코딩 도구 도입은 그 시작이 될 수 있는 만큼, 계획적인 도입을 통해 성공적으로 조직 내에서 AI를 활용한 생산성 향상을 고민하는 조직에 이 글이 도움이 되길 바랍니다.

AWS 기술 블로그