GS리테일 DX 블로그

Digital Transformation으로 고객 생활 가치의 이노베이션을 꿈꾸는 IT 사람들의 이야기

Culture

AI 코드 에디터에서 AI 파트너로: Cursor AI와의 협업 여정

DarionKim 2025. 3. 4. 08:32

안녕하세요! GS리테일 DX COE팀의 김헌기입니다.  
오늘은 제가 GenAI 기술을 접한 경험과, 그 중에서도 특히 AI 코드 에디터 활용 경험을 공유하고자 합니다.

1. GenAI 기술과의 첫 만남

GenAI와의 첫 인연
AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하던 중에 GenAI 관련 기술을 접하게 되었습니다.  
당시 회사 내 AI 도입에 대한 회의적인 분위기 속에서도, GenAI 관련 기술의 잠재력에 호기심을 가지고 지속적으로 관찰했습니다.  
LLM이 코딩에 특화되어 있다는 것을 알게 되었지만, 당시에는 성능이 아쉬워 큰 기대를 하지 않았습니다.

GenAI 기술의 발전
GPT-4의 등장으로 코드 생성 능력이 크게 향상되는 것을 목격했습니다.  
하지만 여전히 실제 프로덕션 환경에서의 활용에는 한계가 있다고 판단했습니다.

새로운 코드는 잘 작성해도 레거시 코드는 사람도 못고치는 AI도 못고친다고 생각했죠.

https://media.licdn.com/dms/image/v2/D5612AQGfeZ5ejNhA_Q/article-cover_image-shrink_720_1280/article-cover_image-shrink_720_1280/0/1704214538992?e=1746662400&v=beta&t=miBYSLHFZMG0rLf91UBdnerP3rBdByDcz-QGakPohqI
https://media.licdn.com/dms/image/v2/D5612AQGfeZ5ejNhA_Q/article-cover_image-shrink_720_1280/article-cover_image-shrink_720_1280/0/1704214538992?e=1746662400&v=beta&t=miBYSLHFZMG0rLf91UBdnerP3rBdByDcz-QGakPohqI


2. AI 코드 에디터와의 만남

Cursor AI와의 첫 만남
Claude-3.5-sonnet의 등장으로 상황이 급변했습니다.  
Cursor AI를 경험해보니 코드 어시스턴트로서의 생산성 효과가 매우 뛰어났습니다.  
특히 Auto Complete 기능은 제가 가장 애용하는 기능이 되었죠!
- 반복적인 코드 작성 시간 50% 감소
- 코드 리뷰 시간 40% 단축
- 버그 발견률 30% 향상

*그렇다고 Cursor를 찬양하는 것은 아닙니다. Cursor Business 플랜을 월 구독하고 있고
 더 좋은 툴이 나오면 언제든지 갈아 탈 준비가 되어 있습니다.

 

https://brianchristner.io/content/images/2024/09/Cursor-AI.png



3. 스폰서십 획득과 활용 범위 확장

스폰서십 획득
생산성 향상을 위해 AI 코드 에디터 활용에 대한 스폰서십을 받게 되었습니다. 

개인적으로 이부분이 중요하다고 생각합니다. 사용하고 싶다고 누구나 사용 할 수 있는 것은 아닙니다.

사용 할 수 있는 환경을 제공해주는 스폰서십이 중요합니다.
이를 통해 다양한 프로젝트에 AI 코드 에디터를 활용할 수 있게 되었죠.

활용 분야
- 기술 표준화를 위한 공통 라이브러리 및 보일러플레이트 제공
- 프로젝트 코드 리뷰 : 보안/품질과는 차원이 다른 코드리뷰 제공
- 오픈소스 기반 아키텍처 도입 검토
- GenAI 플랫폼 개발

팀 내 확산
팀 내 동료들의 호기심 어린 관심과 함께 점진적으로 수용되기 시작했습니다.  
AI 코드 에디터의 활용이 개인에서 팀으로 확장되는 계기가 되었죠.

그래도 여전히 관심이 없으신 개발자분들은 사용하지 않습니다.

4. AI 파트너로의 진화

협업 파트너로의 발전
단순한 코드 에디터로 활용하다가 Cursor Agent 모드가 출시되고 Cursor가 코드만 읽은 것이 아니라
터미널 콘솔 로그 및 마크다운 파일 그리고 웹 검색까지 할 수 있게 되니 진정한 협업 파트너로 발전했습니다.  

 

새로운 기회로 오픈소스 API Gateway 평가 프로젝트를 AI 파트너와 함께 진행하면서,  
AI와의 효과적인 협업 방법을 개발해 나갔습니다.

프로젝트 성과
- 초기 예상 기간: 5~7주 (바쁘다는 핑계로 우선순위에서 항상 밀렸습니다.)
- 실제 완료 기간: 3일
- 기간 단축률: 약 91~94%

5. 협업 방법론의 발전

정책 기반 소통
Cursor Rule과 프로젝트 단위의 .cursorrules 파일을 통해 소통 정책을 수립했습니다:

# Cursor Rule 예시
- 한국어 사용과 마크다운 문서로 소통함을 명시
- 역할 기반의 응답규칙을 작성하고 자동 역할 전환이 되게 명시
- 디버거 > 리뷰어 > 설계자 > 전문가 > 콘텐츠 크리에이터로 우선 순위 명시

# Cursor AI 사용자 정책

## 1. 문서 개요 및 기본 설정

- **목적:**  
  Cursor AI의 역할 전환 및 응답 규칙을 명확히 하여, 다양한 상황에서 일관된 품질의 답변을 제공하기 위함.

- **기본 언어 및 문서 형식:**  
  - **기본 언어:** 한국어  
  - **문서 형식:** Markdown (혹은 기타 구조화된 텍스트 형식)

---

## 2. 역할 기반 응답 규칙

### 자동 역할 전환
- **[리뷰어]**: 코드 관련 질문  
  *예: "이 파이썬 코드 리뷰해줘. 성능 개선할 부분 있을까?"*
- **[디버거]**: 오류 관련 질문  
  *예: "TypeError: unsupported operand type(s) for +: 'int' and 'str' 오류 해결법?"*
- **[설계자]**: 시스템 설계 및 아키텍처 관련 질문  
  *예: "현재 시스템 아키텍처 개선 방향 제시해줘."*
- **[전문가]**: 일반 프로그래밍 질문  
  *예: "자료구조 큐(Queue)에 대해 설명해줘."*
- **[도우미]**: 프로젝트 관련 일반 질문  
  *예: "최근 회의록 파일 위치 알려줘."*
- **[콘텐츠 크리에이터]**: SNS나 블로그 등에서 감각적이고 매력적인 글 작성  
  *예: "이번 주말에 가볼만한 힙한 카페를 소개하는 블로그 글 맛깔나게 작성해줘."*

### 역할 우선순위
1. **[디버거]**
2. **[리뷰어]**
3. **[설계자]**
4. **[전문가]**
5. **[도우미]**
6. **[콘텐츠 크리에이터]**

---

## 3. 역할별 응답 가이드 및 예제

### [리뷰어] – 코드 리뷰어
- **목표:** 코드 품질 향상 및 잠재적 문제점 식별
- **예시:**  
  **질문:** "이 파이썬 코드 리뷰해줘. 성능 개선할 부분 있을까?"  
  **응답:**  
  ```python
  # 변경 전
  for item in data:
      new_list = old_list[:]  # 매 반복마다 리스트 복사
      new_list.append(item)

  # 변경 후
  new_list = old_list[:]  # 반복문 밖에서 리스트 복사
  for item in data:
      new_list.append(item)
변수 명명 규칙과 주석 보강으로 가독성을 높일 수 있습니다.

[디버거] – 디버깅 전문가
목표: 오류 원인 진단 및 해결 방안 제시
절차:
오류 분석: 오류 메시지와 스택 트레이스 확인
원인 추론: 가능한 원인 2가지 이상 제시
해결 단계: 단계별 해결 가이드 제공
예시:
질문: "TypeError: unsupported operand type(s) for +: 'int'와 'str' 오류 해결법?"
응답:
python
복사
편집
# 1. 변수 타입 확인
print(type(a), type(b))

# 2. 형 변환 적용 (예시)
result = str(a) + b  # 또는 int(b) + a
변수 타입을 점검한 후 적절한 형 변환을 적용하면 오류를 해결할 수 있습니다.
[설계자] – 소프트웨어 아키텍처 전문가
목표: 확장 가능하고 유지보수하기 쉬운 시스템 설계 지원
예시:
질문: "현재 시스템 아키텍처 개선 방향 제시해줘."
응답:
css
복사
편집
[API Gateway] --> [서비스 A]
              --> [서비스 B]
              --> [서비스 C]
장점: 독립적 배포, 장애 격리
단점: 복잡한 관리 및 네트워킹 이슈
팀 역량과 현재 시스템 상황을 고려해 적절한 전환 전략을 선택하는 것이 중요합니다.
[전문가] – 프로그래밍 전문가
목표: 명확하고 실용적인 프로그래밍 지식 제공
예시:
질문: "자료구조 큐(Queue)에 대해 설명해줘."
응답:
python
복사
편집
from collections import deque

queue = deque()
queue.append('a')  # 요소 삽입
queue.append('b')
first_item = queue.popleft()  # 'a'가 제거됨
큐는 FIFO(First In First Out) 구조로, 작업 순서를 유지해야 할 때 유용합니다.
[도우미] – 프로젝트 도우미
목표: 프로젝트 관련 정보 및 일반 지원 제공
예시:
질문: "최근 회의록 파일 위치 알려줘."
응답:
go
복사
편집
프로젝트 문서 폴더 내 `회의록` 디렉토리에 최근 회의록 파일이 저장되어 있습니다.
파일명은 `YYYYMMDD_회의록.txt` 형식을 따릅니다.
예: 20250302_회의록.txt
[콘텐츠 크리에이터] – SNS/블로그 콘텐츠 제작 전문가
목표: SNS 및 블로그에서 독자들의 눈길을 사로잡는 감각적이고 매력적인 글 작성

주요 특징:

창의적 글쓰기: 이야기 형식이나 감성적 어조를 활용해 독자와 공감대 형성
트렌드 반영: 최신 유행어, 해시태그, 이모지 등을 적절히 활용
시각적 구성: 단락 구성, 강조 기법, 이모지 사용으로 가독성 및 시각적 매력 강화
다양한 콘텐츠: 주제(여행, 맛집, 일상, 리뷰 등)에 따라 유연한 문체 적용
예시:
질문: "이번 주말에 가볼만한 힙한 카페를 소개하는 블로그 글 맛깔나게 작성해줘."
응답:

"따스한 봄바람을 품은 어느 날, 감각적인 인테리어와 은은한 음악이 어우러진 **[카페 이름]**를 소개할게요.
문을 열고 들어서는 순간, 하루의 피로가 싹 사라지는 기분 좋은 여유가 시작됩니다.
☕️ 커피 한 잔의 여유와 함께 감성 충전을 경험해보세요! #힙카페 #감성충전"

활용 방안:

콘텐츠 전략: SNS 캠페인, 브랜드 스토리텔링, 이벤트 홍보 등 다양한 톤앤매너 적용
플랫폼 특성 고려: 인스타그램, 페이스북, 블로그 등 각 플랫폼에 맞춰 문체와 구성 조절
독자 참여 유도: 질문, 퀴즈, 해시태그 챌린지 등을 포함해 독자가 직접 반응하도록 유도
4. 추가 개선 사항 및 관리 전략
문서 구조 개선:

목차, 색인, 버전 정보, 업데이트 일자 등을 포함하여 지속적인 문서 관리 체계 확립
실시간 피드백 및 대화 흐름 가이드:

다중 턴 대화 시 역할 유지 및 전환을 위한 키워드(예: "역할 전환 요청", "힌트 모드") 명시
구체적 사용 사례와 예제 추가
보안 및 개인정보 보호:

코드/데이터 분석 시 민감 정보 보호 지침 및 데이터 폐기 정책 구체화
자동화 및 유연성 강화:

역할 전환 및 자동 처리 로직에 대한 설명과 예시 추가
사용자 피드백 반영 및 주기적 업데이트 프로세스 수립
최신 트렌드 반영:

AI 및 자연어 처리 최신 연구, 사례 반영하여 정기적 업데이트 계획 수립
사용자 피드백 수집 및 반영 방안 마련
5. 부록 및 참고 자료
관련 문서 및 외부 링크:
필요 시 관련 문서나 참고 자료의 URL 및 링크를 제공하여 사용자가 추가 정보를 쉽게 찾을 수 있도록 함

 

# .cursorrules 파일
- 프로젝트 마다 적용 되는 정책이라 프로젝트 루트에 위치하고 json 형식으로 작성 필요
- 코딩 컨벤션, 아키텍처 패턴, 기술 스택, 테스트 방식, 문서화, 커밋 규칙 명시

{
  "projectInfo": {
    "name": "API Gateway 평가 프로젝트",
    "type": "evaluation",
    "description": "다양한 오픈소스 API Gateway를 평가하여 특정 조건에 맞는 최적의 솔루션을 선정"
  },
  "codingConventions": {
    "naming": {
      "variables": "camelCase",
      "classes": "PascalCase",
      "constants": "UPPER_SNAKE_CASE",
      "files": "kebab-case.js"
    },
    "indentation": "2 spaces",
    "stringQuotes": "single",
    "semicolons": true,
    "maxLineLength": 100,
    "comments": "JSDoc style"
  },
  "architecturePatterns": [
    {
      "name": "API Gateway Pattern",
      "description": "모든 클라이언트 요청의 단일 진입점"
    },
    {
      "name": "Reverse Proxy Pattern",
      "description": "요청 라우팅 및 부하 분산"
    },
    {
      "name": "Circuit Breaker Pattern",
      "description": "장애 전파 방지"
    },
    {
      "name": "Authentication Pattern",
      "description": "JWT 기반 접근 제어"
    },
    {
      "name": "Rate Limiting Pattern",
      "description": "API 호출 제한"
    }
  ],
  "techStack": {
    "containerization": "Docker",
    "cicd": "BitBucket Bamboo",
    "monitoring": ["Prometheus", "Grafana"],
    "logging": {
      "name": "ELK Stack",
      "components": ["Elasticsearch", "Logstash", "Kibana"]
    },
    "testing": ["k6", "Postman", "Newman"],
    "deployment": "Docker Compose"
  },
  "testingApproach": {
    "functional": [
      "라우팅 테스트",
      "인증/인가 테스트",
      "속도 제한 테스트",
      "요청/응답 변환 테스트"
    ],
    "performance": [
      "k6를 사용한 부하 테스트",
      "점진적 부하 증가 시나리오",
      "임계치 기반 성능 검증"
    ],
    "security": [
      "SSL/TLS 설정 검증",
      "인증 토큰 검증",
      "접근 제어 검증"
    ]
  },
  "documentation": {
    "api": "OpenAPI(Swagger)",
    "changes": "변경 이유 포함 필수",
    "testResults": "표준화된 형식",
    "codeChanges": "상세한 커밋 메시지"
  },
  "commitRules": {
    "formats": {
      "gatewaySpecific": "[Gateway 이름]: [작업 내용]",
      "commonProject": "API Gateway 평가 프로젝트: [작업 내용]"
    },
    "examples": [
      "Kong API Gateway: 기본 설정 파일 추가",
      "APISIX API Gateway: JWT 인증 테스트 스크립트 추가",
      "API Gateway 평가 프로젝트: 비교 매트릭스 템플릿 추가"
    ]
  }
}



문서화와 버전 관리
- 마크다운 문서를 통한 지속적인 문서화

- AI가 방황하면 문서를 읽어보라고 지시하고 제안해 달라고 이야기 함

# API Gateway 평가 프로젝트 문서

## 프로젝트 구조

### 1. 핵심 컴포넌트 (`/`)
- **API Gateway 구현** (`/gateways`)
  - Kong Gateway
  - Gravitee Gateway
  - Tyk Gateway
  - KrakenD Gateway
  - APISIX Gateway

- **백엔드 서비스** (`/backend-services`)
  - Service A
  - Service B
  - Service C
  - Docker Compose 설정

- **테스트** (`/tests`)
  - 성능 테스트 (`/performance`)
  - 기능 테스트 (`/functional`)
  - Node.js 기반 테스트 환경

- **인프라스트럭처** (`/infrastructure`)
  - Docker 구성 (`/docker`)
  - 모니터링 설정 (`/monitoring`)
  - 보안 설정 (`/security`)
  - 테스트 서비스 환경 (`/test-services`)

- **공유 리소스** (`/shared`)
  - 공통 설정
  - 유틸리티 스크립트

### 2. 문서 (`/docs`)
- **아키텍처 문서** (`/architecture`)
  - 시스템 구성도
  - 컴포넌트 설명
  - 네트워크 구성
  
- **비교 분석** (`/comparison`)
  - 기능 비교 (`feature-comparison.md`)
  - 성능 비교 (`performance-comparison.md`)
  
- **보안 아키텍처** (`/security`)
  - 보안 구성 (`security-architecture.md`)

- **가이드 문서** (`/guides`)
  - 설치 가이드 (`/setup`)
  - 운영 가이드 (`/operations`)
  - 문제해결 (`/troubleshooting`)

## 문서 버전 관리

- 버전: 1.0.0
- 최종 수정일: 2024-03-03
- 작성자: Darion

## 문서 작성 규칙

1. **버전 관리**
   - 모든 문서는 버전 정보를 포함
   - 주요 변경사항은 변경 이력에 기록

2. **형식**
   - Markdown 형식 사용
   - 코드 블록은 언어 지정
   - 다이어그램은 Mermaid 사용

3. **상호 참조**
   - 관련 문서는 상대 경로로 링크
   - 외부 참조는 별도 섹션에 정리

4. **업데이트**
   - 정기적인 문서 리뷰 (분기별)
   - 주요 변경사항 발생 시 즉시 반영

## 문의

문서 관련 문의나 개선 제안은 프로젝트 관리자에게 연락 바랍니다.


- Git을 통한 작업 이력 관리

- AI가 작업 내역을 잃어버리면 git log를 확인하라고 지시함


- 큰 범위부터 설계하고 세부 내용을 채우는 방식

- 첫번째 README.md 문서를 만들때 가장 커다란 방향성을 지시하고 관련된 프로젝트 구조가 만들어지면 세부 내용을 채우는 방식으로 진행

- 커다란 방향성을 절대 벗어나지 말아야하며 벗어난 경우 방향성이 잘못된 것이며 그다음에는 AI는 안드로메다로 떠나버림

gsr-api-gateway-evaluation % tree
.
├── README.md
├── backend-services
│   ├── docker-compose.yml
│   ├── service-a
│   │   ├── Dockerfile
│   │   ├── node_modules
│   │   ├── package.json
│   │   └── server.js
│   ├── service-b
│   │   ├── Dockerfile
│   │   ├── node_modules
│   │   ├── package.json
│   │   └── server.js
│   └── service-c
│       ├── Dockerfile
│       ├── node_modules
│       ├── package.json
│       └── server.js
├── docs
│   ├── README.md
│   ├── _search-index.md
│   ├── _sidebar.md
│   ├── architecture
│   │   ├── api-gateway-architecture.md
│   │   ├── comparison
│   │   │   ├── feature-comparison.md
│   │   │   └── performance-comparison.md
│   │   └── security
│   │       └── security-policies.md
│   ├── assets
│   │   ├── diagrams
│   │   └── images
│   ├── document-index.md
│   ├── evaluation
│   │   ├── recommendations
│   │   │   └── final-recommendations.md
│   │   ├── reports
│   │   │   └── project-summary-report.md
│   │   └── results
│   │       ├── apisix-test-results.md
│   │       ├── gravitee-test-results.md
│   │       ├── kong-test-results.md
│   │       ├── krakend-test-results.md
│   │       └── tyk-test-results.md
│   ├── guides
│   │   ├── examples
│   │   │   ├── gravitee
│   │   │   └── tyk
│   │   ├── operations
│   │   │   ├── README.md
│   │   │   └── monitoring
│   │   │       └── dashboard-guide.md
│   │   ├── setup
│   │   │   ├── README.md
│   │   │   ├── apisix-setup.md
│   │   │   ├── configuration-templates
│   │   │   ├── gravitee-setup.md
│   │   │   ├── installation
│   │   │   │   └── prerequisites.md
│   │   │   ├── kong-setup.md
│   │   │   ├── krakend-setup.md
│   │   │   └── tyk-setup.md
│   │   ├── testing
│   │   │   ├── advanced-testing.md
│   │   │   ├── performance-testing.md
│   │   │   └── security-testing.md
│   │   └── troubleshooting
│   │       ├── README.md
│   │       └── common-issues
│   │           ├── configuration.md
│   │           ├── connectivity.md
│   │           └── performance.md
│   ├── monitoring
│   └── tags
│       └── README.md
├── gateways
│   ├── apisix
│   │   ├── config
│   │   │   └── config.yaml
│   │   ├── docker-compose.yml
│   │   └── routes
│   │       └── default.yaml
│   ├── gravitee
│   │   ├── config
│   │   │   ├── gravitee-management.yml
│   │   │   ├── gravitee.yml
│   │   │   └── nginx.conf
│   │   └── docker-compose.yml
│   ├── kong
│   │   ├── config
│   │   │   └── kong.conf
│   │   ├── docker-compose.yml
│   │   ├── plugins
│   │   └── routes
│   │       └── default.yaml
│   ├── krakend
│   │   ├── config
│   │   │   └── krakend.json
│   │   └── docker-compose.yml
│   └── tyk
│       ├── config
│       └── docker-compose.yml
├── infrastructure
│   ├── docker
│   │   └── docker-compose.yml
│   ├── monitoring
│   │   ├── alertmanager
│   │   │   └── alertmanager.yml
│   │   ├── backup
│   │   │   ├── grafana
│   │   │   └── prometheus
│   │   ├── docker-compose.yml
│   │   ├── filebeat
│   │   │   └── filebeat.yml
│   │   ├── grafana
│   │   │   ├── dashboards
│   │   │   │   ├── gateway-details.json
│   │   │   │   └── gateway-overview.json
│   │   │   └── provisioning
│   │   │       ├── dashboards
│   │   │       │   ├── dashboards.yml
│   │   │       │   └── kong-dashboard.json
│   │   │       └── datasources
│   │   │           ├── prometheus.yaml
│   │   │           └── prometheus.yml
│   │   ├── logstash
│   │   │   └── pipeline
│   │   │       └── gateway.conf
│   │   └── prometheus
│   │       ├── global-prometheus.yml
│   │       ├── prometheus.yml
│   │       └── rules
│   │           └── gateway_alerts.yml
│   ├── security
│   │   ├── auth
│   │   │   └── jwt-config.yaml
│   │   ├── monitoring
│   │   │   └── security-rules.yaml
│   │   └── ssl
│   │       ├── cert-renewal.sh
│   │       └── kong-ssl.conf
│   └── test-services
│       └── docker-compose.yml
├── scripts
│   ├── cleanup-docs-directory.sh
│   ├── deployment
│   │   └── create-test-token.sh
│   ├── generate_report.py
│   ├── maintenance
│   ├── monitoring
│   ├── run-evaluation.sh
│   ├── setup
│   │   ├── gateway-switch.sh
│   │   ├── setup-kong-prometheus.sh
│   │   └── setup-test-service.sh
│   ├── test
│   └── testing
│       └── load-test.sh
├── shared
│   ├── templates
│   └── test-services
│       └── docker-compose.yml
└── tests
    ├── functional
    │   ├── authentication
    │   │   └── jwt.test.js
    │   ├── config.js
    │   ├── rate-limiting
    │   │   └── basic.test.js
    │   └── routing
    │       └── basic.test.js
    ├── package.json
    └── performance
        └── scenarios
            └── load.yaml


6. 기술적 환경 구성

로컬 환경
- Docker 기반의 개발 환경을 구성했습니다: Docker는 개발자분들은 꼭 사용 할 줄 알아야 되는 도구입니다.

- 로컬환경이 무엇인지 이야기 해주어합니다. 예를 들어 나는 macbook pro m4 를 가지고 있다고 이야기해주어야 걸맞는 이미지로 환경을 구성해줍니다.

# kong docker-compose.yml 예시

version: '3'

networks:
  kong-net:
    driver: bridge

services:
  # Kong 데이터베이스
  kong-database:
    image: postgres:13
    container_name: kong-database
    networks:
      - kong-net
    ports:
      - "5432:5432"
    environment:
      POSTGRES_USER: kong
      POSTGRES_DB: kong
      POSTGRES_PASSWORD: kong
    volumes:
      - kong-database-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "kong"]
      interval: 5s
      timeout: 5s
      retries: 5

  # Kong 마이그레이션
  kong-migration:
    image: kong:3.3.1
    container_name: kong-migration
    networks:
      - kong-net
    depends_on:
      kong-database:
        condition: service_healthy
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-database
      KONG_PG_USER: kong
      KONG_PG_PASSWORD: kong
      KONG_PG_DATABASE: kong
    command: kong migrations bootstrap
    restart: on-failure

  # Kong API Gateway
  kong:
    image: kong:3.3.1
    container_name: kong
    networks:
      - kong-net
    depends_on:
      kong-migration:
        condition: service_completed_successfully
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-database
      KONG_PG_USER: kong
      KONG_PG_PASSWORD: kong
      KONG_PG_DATABASE: kong
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_ADMIN_LISTEN: 0.0.0.0:8001, 0.0.0.0:8444 ssl
      KONG_PROXY_LISTEN: 0.0.0.0:8000, 0.0.0.0:8443 ssl
    ports:
      - "8000:8000"
      - "8443:8443"
      - "8001:8001"
      - "8444:8444"
    healthcheck:
      test: ["CMD", "kong", "health"]
      interval: 10s
      timeout: 10s
      retries: 10
    restart: on-failure

  # Kong Prometheus 플러그인 활성화
  kong-prometheus-setup:
    image: curlimages/curl:7.83.1
    container_name: kong-prometheus-setup
    networks:
      - kong-net
    depends_on:
      kong:
        condition: service_healthy
    volumes:
      - ./setup-kong-prometheus.sh:/setup-kong-prometheus.sh
    command: sh -c "chmod +x /setup-kong-prometheus.sh && /setup-kong-prometheus.sh"
    restart: on-failure

  # 테스트 서비스 설정
  kong-test-service-setup:
    image: curlimages/curl:7.83.1
    container_name: kong-test-service-setup
    networks:
      - kong-net
    depends_on:
      kong-prometheus-setup:
        condition: service_completed_successfully
    volumes:
      - ./setup-test-service.sh:/setup-test-service.sh
    command: sh -c "chmod +x /setup-test-service.sh && /setup-test-service.sh"
    restart: on-failure

  # Prometheus
  prometheus:
    image: prom/prometheus:v2.42.0
    container_name: prometheus
    networks:
      - kong-net
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/etc/prometheus/console_libraries'
      - '--web.console.templates=/etc/prometheus/consoles'
      - '--web.enable-lifecycle'
    depends_on:
      kong:
        condition: service_healthy
    restart: on-failure

  # Grafana
  grafana:
    image: grafana/grafana:9.4.7
    container_name: grafana
    networks:
      - kong-net
    ports:
      - "3000:3000"
    environment:
      GF_SECURITY_ADMIN_USER: admin
      GF_SECURITY_ADMIN_PASSWORD: admin
      GF_USERS_ALLOW_SIGN_UP: 'false'
    volumes:
      - grafana-data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning
    depends_on:
      prometheus:
        condition: service_started
    restart: on-failure

volumes:
  kong-database-data:
  prometheus-data:
  grafana-data:



운영 환경
- Kubernetes 기반 구성
- 환경별 구성을 함께 설계하고 검토

7. 성과와 향후 계획

정량적 성과 (케바케)
- 코드 작성 시간 50% 단축
- 버그 발생률 30% 감소
- 문서화 효율성 40% 향상

정성적 성과
- AI와의 자연스러운 협업 경험
- 체계적인 프로젝트 진행 방식 확립
- 지속적인 학습과 개선

- 사람과 협업하는 것처럼 느껴짐

향후 계획
- Q2까지 사내 AI 코드 에디터 활용 가이드라인 수립
- 협업 방법론 개선 및 표준화

8. 도전과 극복

LLM 토큰 사용량 문제
- 초기: 슬로우 요청으로 인한 작업 지연, 중간 중간 High Load 발생
- 해결: Cursor Agent모드 활용으로 쉬지 않고 일하게 함 



Cursor UX 변화
- 초기: 빠른 UX 변화로 인한 혼란
- 해결: 정기적인 업데이트 확인

'25년 3/2 모델을 default로 적용

 

'25년 2/26 gpt-4.5-preview 가 생김
'25년 2/17 Agent Ask Edit를 하나로 합침

범위 관리
- 초기: AI 파트너의 범위 이탈
- 해결: 명확한 정책과 가이드라인 수립, AI를 안드로메다로 보내지 말자

9. 조직 문화 변화

개인에서 팀으로
- 개인적 경험에서 팀 전체로 확장
- 동료들의 피드백 수렴 및 반영
- AI 코드 에디터 활용에 대한 긍정적 인식 확산
- 지속적인 학습과 공유 문화 정착

마무리

AI 코드 에디터는 이제 단순한 도구가 아닌, 진정한 협업 파트너가 되었습니다.  
앞으로도 계속해서 AI와 함께 더 나은 코드를 작성하고, 더 효율적인 개발을 추구하고자 합니다.

 

경험적으로 말씀드릴 수 있는 건 AI 파트너가 잘하고 못하고는 지시를 내리는 사람에 달려있다고 생각하셔야 합니다.

코딩을 잘하고 못하고 판단하는 수준은 이미 지났고 제안받고 의사결정하고 개선하면 됩니다. 

여러분도 AI 파트너와 함께하는 여정을 시작해보시는 건 어떨까요?  
경험과 의견을 댓글로 공유해 주시면 감사하겠습니다.

*APIGateway 평가 프로젝트 내용도 별도의 콘텐츠로 공유드리겠습니다.

김헌기 Darion | DX본부 > DX COE부문 > DX COE팀
AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하고 있습니다.
동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.