[AI/개발] Codex기반 AI 성능 개선 스터디

<aside> ✨ 스터디 신청 바로가기(링크) 신청기간: 9/1(화)~9/17(목) 선발결과: 9/30(수) 개별 안내

</aside>

스터디 리더:
- 이름: 이로움
- 소개: 4년차 Frontend 개발자로 HR 도메인에서 일하고 있습니다. 만드는 것만큼 동작 이론에 흥미를 느끼는지라, 그동안 여러 스터디를 조직하고, 운영하고, 참여해왔습니다. 대 AI 시대에 느닷없이 인프라와 컴퓨터 구조에 빠졌습니다. AI를 잘 쓰는 법은 많지만, AI가 어떻게 클라우드 위에서 구동되는가에 대한 주제는 적어보여, 스스로 배워보자는 마음으로 리더로 참여하게 되었습니다.
스터디 주제: 각자 자기 AI 서비스 하나를 AWS(Lambda / API Gateway / CloudWatch)에 올립니다. 이후 자신의 서비스를 운영으로 놓고 성능을 개선해봅니다. 구현과 성능 개선의 전 과정은 Codex와 함께합니다 — 어디에 썼고, 어디서 유용했고, 어디서 틀렸는지를 매주 기록해 "AI 도구로 인프라 작업이 어디까지 되는가"도 함께 검증합니다.
목표: 8주 뒤에 자기 서비스의 콜드/웜 p95, 요청당 비용, 첫 실패 지점과 원인을 숫자로 말할 수 있기를 바랍니다. 나아가서는, AI 서비스와 AWS 인프라 리소스의 연관관계를 더 깊게 이해하고, 스스로 설명할 수 있다면 좋겠습니다.
프로젝트 결과물 계획:

결과물	내용
AWS에 배포된 각자의 AI 서비스	실제 호출 가능한 엔드포인트. 발표회에서 자기 것을 시연합니다
개인 발표자료	예시) 내 서비스 / 성능 개선지점 전후 비교 / 제일 아팠던 벽 / 권고
아키텍처 문서	freeze 시점 → 최종. 변경마다 근거 숫자
GitHub 공개 저장소	팀 공용(템플릿·하네스·측정/부하 스크립트) + 개인 저장소
Codex 활용 기록	어디에 썼고, 어디서 유용했고, 어디서 틀렸는지
발표 자료 + 데모	12/16 성과공유회용

대상:
- 이런 열정이 있다면 정말 환영합니다.
  - 자기가 만든 서비스가 왜 느린지, 왜 비싼지 궁금했던 분
  - 인프라가 궁금한데 어디서 시작할지 몰랐던 분
  - LLM 서비스에 대한 아이디어가 있는 분
- 이 정도면 충분합니다.
  - 실제로 돌아가는 웹 서비스를 개발해 본 경험이 있으신 분
  - git 기반 협업이 익숙하신 분
  - HTTP 통신에 대한 기본 이해가 있으신 분
  - 배포를 한 번 이상 경험해보셨거나 AWS에 대한 기본적인 이해가 있으신 분
- 없어도 괜찮습니다. (같이 배워봐요)
  - AWS 실무 및 DevOps 경험
  - 부하 테스트, 모니터링, 성능 측정 경험
- 이런 분들은 어렵습니다.
  - 주 1회 스터디 모임에 참여가 어렵거나 과제에 집중할 시간이 없으신 분
  - 바이브 코딩으로만 코딩을 접해보신 분
  - 스스로 개발환경 세팅이 어려우신 분
모집정원: 리더 포함 6명 이내
진행방식: 주 1회(수) 90분 (요일 협의 가능) / 디스코드 온라인 회의
사전 준비물 / 개발환경:
- 필수
  - gitHub 계정, AWS 계정
  - Node.js 22 LTS 이상 + npm
  - git
  - ide 혹은 ade (자유)
  - Codex
  - 디스코드 계정
- 참고 자료(선택)
  - Google SRE Book — 4장(SLO) · 6장(모니터링) · 21장(과부하) · 22장(연쇄 장애). 온라인 무료
  - 『Release의 모든 것』 한빛미디어, 2023
  - 가상 면접 사례로 배우는 대규모 시스템 설계 기초 (Alex Xu)
진행일정:
- 팀 오리엔테이션: 10/7(수) 22:00 — 1주차 모임을 겸합니다
- 활동기간: 10/3(토) ~ 11/30(월)
- 정규모임: 매주 수요일 22:00 – 23:30 (90분) · 온라인 (구성원들의 협의에 따라 요일 변경 가능) / 10/7(수) OT, 11/25(수) 마지막 스터디 오프라인 진행 (강남역 인근)
- 최종 성과공유회: 12/16(수) · 오프라인

1~3주차 · 자신의 llm 서비스 만들기

주차 (수 22:00)	주제	이번 주에 하는 일	최소 통과선	도전
1주차 (10/7) 팀 OT	팀 OT · 템플릿 배포 · 비용 가드레일	모임: 팀 소개, GitHub·Issue·PR 규칙 합의 · 리더 라이브 데모(템플릿 → deploy → 실 모델 호출 → CloudWatch 레코드 확인) · 전원 `npm run deploy`로 최소 엔드포인트(LLM 호출 1개) 배포 · AWS Budgets 알림 공동 설정 / 주중: 가드레일 마무리 — Lambda 동시성 상한 · API Gateway 스로틀 · 제공 키 사용량 확인 · (권장) 엔드포인트 API 키 · 내 서비스 확정(Issue 등록)	배포된 URL이 응답하고, AWS 예산 알림 메일을 받아봤다	템플릿의 "기본값 그대로" 목록을 읽고 어느 주에 벽이 될지 예측해오기
2주차 (10/14)	만들기 ① · 하네스 · 데이터셋	배포된 엔드포인트 위에서 기능 만들기 (매주 deploy) · 하네스 붙이고 로컬/Lambda 동일 레코드 확인 · 자기 입력 20건 / 품질 검사 하나 정하기	배포된 내 서비스가 하네스 레코드를 남기고, 입력 20건이 있다	도구 호출 하나 넣어보기
3주차 (10/21)	만들기 ② · 동결 · 기준선	기능 마무리 및 프리징 · 네 가지 황금 신호에 하네스 필드 매핑 (SRE 6장) · 모임 마지막 20분: 전원 freeze 태그 + 기준선 측정(콜드 5 · 웜 5)	freeze 태그가 있고, 내 기준선 행이 팀 표에 들어갔다	기준선에서 제일 나쁜 숫자를 미리 짚어오기

4~7주차 · 성능 개선해보기

주차 (수 22:00)	벽	재는 것	손잡이 메뉴 (하나 고름) · 자료	최소 통과선
4주차 (10/28)	지연 — Lambda · API Gateway	콜드/웜 분리 p50·p95 · 긴 입력으로 29초 재현	메모리 올리기 · esbuild 번들 · 웜 유지/프로비저닝 · 스트리밍(Function URL) 우회 · max_tokens (자료: SRE 4장 SLO)	콜드/웜 p95를 쟀고, 손잡이 하나로 전후 비교했다
5주차 (11/4)	비용 — 요금	요청당 비용 = 모델 토큰 + Lambda GB-초 + API GW + 로그 수집 · 4주차 손잡이가 비용에 미친 영향	작은 모델 라우팅 · 프롬프트/도구 결과 다이어트 · 프롬프트 캐싱 · 로그 본문 줄이기 · 메모리 내리기 (자료: AWS 요금 페이지 · OpenAI 프롬프트 캐싱)	요청당 비용을 항목별로 합산했고, 손잡이 하나로 전후 비교했다
6주차 (11/11)	동시성 — 모델 API	동시 1→5→10→20에서 첫 실패 지점과 원인 (429 / Lambda 스로틀 / 타임아웃) · 모임 시간에 전원이 동시에 부하를 겁니다	이 주는 벽 찾기. 클라이언트 동시성 상한 · 1주차 가드레일(Lambda 상한 · 스로틀) 조정 (자료: SRE 21장 과부하)	첫 실패 지점과 원인을 찾았고, 429를 내 눈으로 봤다
7주차 (11/18)	안정성 — 벽에서의 행동	6주차와 같은 부하에서 실패율 · p95	지수 백오프+지터 · 모델 호출 타임아웃 · fail-fast · (도전) SQS 비동기 (자료: SRE 22장 재시도 증폭 · 선택: Release It! 5장)	실패율 전후와 p95가 얼마나 나빠졌는지를 같이 적었다

8주차 · 합치기

주차	주제	이번 주에 하는 일	최소 통과선
8주차 (11/25) 결과공유회	개인 리포트 · 팀 표 · 리허설	개인 성과 발표	내 리포트가 완성됐고, 팀 표에 내 행이 있다