📚

AWS Dev:Flow를 다녀와서

1. 밋업 후기

AWS에서 이전에 본 적 없는 구성이라 기대 반, 궁금증 반으로 참석했다. 식사 공지가 없어 간단한 요깃거리를 챙겨 갔는데, 현장에는 수준 높은 케이터링과 와인·맥주·음료까지 준비돼 있었다. 이번 행사에 AWS가 상당한 공을 들였다는 인상을 받았다.

밋업은 세 개의 발표로 구성됐고, 이후에는 ‘소셜 나이트’라는 이름의 네트워킹 시간으로 마무리됐다. 첫 번째 발표(아마존의 개발문화)는 오프닝 세션답게 비교적 가볍게 시작했지만, 사내에 문서 중심 개발 문화가 깊게 뿌리내려 있다는 점이 특히 인상적이었다. 리뷰 미팅에서 문서를 출력해 정독하는 시간을 갖고, 팀 단계 리뷰를 거쳐 조직 차원 리뷰로 확장하는 2단계 절차가 품질 유지에 큰 도움이 되겠다는 생각이 들었다. 다만 스타트업 환경에서 이 과정을 현실적으로 적용하는 일이 가능할지에 대해서는 의문도 남았다.

두 번째 발표에서는 Amazon Q를 활용한 실시간 라이브 코딩을 선보였다. 평소 Cursor나 Kiro 같은 에이전틱 IDE를 주로 쓰는 편이라, CLI를 통해 개발 전 과정을 밀어붙이는 흐름이 새로웠다. 클로드 코드는 써 본 적 없지만 맥락은 비슷해 보였다. 리허설 때는 잘 되던 부분이 발표 중 갑자기 에러를 일으켜 약 5분간 모델과 주고받으며 트러블슈팅하는 순간이 있었는데, 오히려 라이브 코딩 특유의 긴장감과 재미가 있었다. AWS에서 만든 서비스답게 AWS CLI와의 호환성이 뛰어나 사용자의 한두 번의 명령으로 인프라 코드가 생성되고 배포까지 이어지는 장면이 인상적이었다. AI Ops라는 말이 구체적으로 피부에 와닿았다.

세 번째 발표는 사내 AI 챗봇 구축 사례였다. 제일 재밌고 기억에 남는 발표였다. 구성원들의 불편을 줄이고 생산성을 높인 경험을 공유했는데, 사실 “AI로 챗봇을 만드는 일은 마음만 먹으면 누구나 할 수 있다”는 말이 익숙한 만큼, 실제로 시간을 들여 실행하고 문제 해결까지 마무리한 점이 더욱 돋보였다. 개발자는 현실 세계의 문제를 소프트웨어로 해결하는 사람이라는 데 많은 이들이 동의할 것이다. 발표자는 여기에 더해, 문제를 ‘해결’하는 능력뿐 아니라 ‘발견’하는 능력의 중요성을 강조했고, 그 메시지가 오래 남았다. 최근 나는 어떤 문제를 주도적으로 발견하고 해결하려 했는가를 자연스럽게 돌아보게 됐다.

자세한 내용은 아래 요약 정리를 참고하면 된다.(덧붙여, 본 글은 현장 메모를 바탕으로 정리한 요약이라 일부 내용이 실제 발표와 다를 수 있습니다. 양해 부탁드립니다)

2. 밋업 내용 요약

2.1. Amazon의 개발 문화

•

발표자

◦

제이콥님

◦

Ex-Amazon SDE/SA, Vibers AI - Head of AX Tech

•

요약

◦

작고 자율적인 팀이 문서 중심 설계와 철저한 자동화·관측·데이터 기반 의사결정으로 고객 가치에 집착하며 빠르게 학습·전개함

◦

작은 팀의 강한 소유권, 문서 기반 합의, 실패를 전제한 배포 전략, 관측과 데이터 중심 운영, 고객에서 시작하는 개발의 다섯 축이 맞물리는 체계임

2.1.1. 팀 구조: 작지만 끝까지 책임지는 Two-Pizza Team

•

서비스가 MicroService로 잘게 분리되어 각 서비스가 독립적으로 개발·배포·운영 가능함

•

MicroService 구조에 맞춰 팀도 도메인 단위로 분화되어 Two-Pizza 규모(약 8~10명)로 구성

•

각 팀이 해당 서비스의 개발→배포→운영 전 라이프사이클을 소유

•

온콜(주 단위 로테이션)로 24/7 장애 대응과 사후 학습을 팀이 직접 수행

2.1.2. 문서 중심 개발과 디자인 리뷰

•

슬라이드 대신 내러티브 문서로 제안·아키텍처·비용·리스크를 서술

•

디자인 문서(Design Doc)에 스코프, 이해관계자, 아키텍처, 비용 고려 등을 상세 기재하고, 팀→조직 순 리뷰 후 개발 시작

•

리뷰 리추얼(90분)

◦

30분 정독 → 코멘트 작성 → 코멘트 수집·경청 → 필요 시 반복

•

과정 전반이 안티패턴 식별과 개발자 성장으로 직결

2.1.3. Delivery: 실패를 전제로 설계하는 안전한 배포

•

마이크로서비스별 전용 CI/CD 파이프라인으로 자동 배포 운영

•

Pessimistic Deployments

◦

배포 실패 가능성을 전제로 원박스→점진 롤아웃→신속 롤백 설계

•

자동화 테스트를 게이트로 강제하여 단위·통합·부하 테스트를 빌드·스테이징·프로덕션 전 단계에 삽입

•

ECT(Edit–Compile–Test) 루프 최적화로 가능한 이른 단계·로컬 근접에서 오류 탐지

◦

local ECT Loop → Code Review → Staging → Production  

2.1.4. 운영과 관측: 모니터링 없이는 배포 없음

•

메트릭·로그·트레이싱 등 관측가능성(Observability) 확보를 배포 요건으로 설정

•

Ops 문화

◦

온콜 담당이 주간 Ops 미팅을 주도하고 대시보드 기반으로 이상 징후·원인·우선순위를 공유

2.1.5. 데이터와 고객: WBR & Working Backwards

•

데이터 중심 의사결정

◦

WBR(Weekly Business Review)에서 기능 채택률, 세그먼트 성장, 퍼널 등 핵심 지표로 우선순위 결정

•

Listens to Customers (고객 집착)

◦

고객 피드백이 개발팀에 직접 연결되어 백로그→스프린트로 신속 반영

◦

그들이 원하는 것이 무엇인지 묻기

◦

구축한 서비스에 대한 피드백 받기

◦

필요한 경우 적극적으로 피드백 반영

•

Working Backwards

◦

우리가 원하는 것보다 고객이 원하는 것에서 출발해 설계·구현

2.2. AI Co-Developer와 함께 하는 Live Coding

•

발표자

◦

한정호님, 안효빈님

◦

Senior Solutions Architect, AWS Korea

•

요약

◦

AWS Q Developer / CLI를 활용하여 실시간 커머스 서비스를 라이브 코딩

2.2.1. 라이브 코딩 진행 흐름

•

개발 명세서 자동 생성

◦

단순히 “코드 작성” 요청 대신 개발 명세서를 먼저 생성하도록 지시

◦

명세서에는 아키텍처, 인프라, 기술 스택(ECS Fargate, DocumentDB 등)이 포함됨

◦

원하는 경우 채팅으로 스펙을 변경해 맞춤화 가능

•

Task 리스트 기반 개발

◦

명세서를 기반으로 작업(Task) 리스트를 자동 생성

◦

작업 진행 상황이 체크박스로 관리되어, 중단 후 재개가 용이

◦

개발 도중 콘텍스트가 꽉 차도 Task 리스트와 명세서를 기준으로 이어서 작업 가능

•

프론트엔드 → 백엔드 순차 개발

•

인프라 및 배포

◦

AWS CLI와의 높은 호환성과 연동이 잘되어있어서 배포에 용이 (AI Ops)

•

콘텍스트 관리 & 가이드라인 적용

◦

Q Developer는 대규모 콘텍스트를 유지하지만 한계가 있어, 주기적 요약 필요

◦

회사별 코딩 가이드라인을 콘텍스트에 주입해 일관된 코드 스타일 유지 가능

◦

AWS 자원 사용 시 비용 폭주 방지를 위해 “인프라 변경 전 확인” 같은 룰 설정 가능

•

문제 해결 & 디버깅

◦

실시간 개발 중 오류 발생 시 AI에 디버깅 요청 → 코드 수정안 및 설명 제공

◦

실행 오류(예: 타입 에러, 서버 실행 문제)도 Q가 스스로 수정 시도 후 재배포

2.3. 촤비스로 동료들의 생산성을 높여보자

•

발표자

◦

하수종님

◦

글로벌 개발팀, 무신사

•

요약

◦

차비스는 슬랙을 배회하며 질문에 답하는 사내 AI 비서로, 대화 요약, 실시간 번역,  사내 문서 내용 검색 등을 제공함

◦

UI는 슬랙이 담당하고, Spring AI + Amazon Bedrock이 백엔드에서 모델 호출과 툴 실행을 담당함

2.3.1. 아키텍처 개요

•

기본 흐름

◦

Slack → Spring AI → Retrieval → LLM 응답 → Slack 흐름으로 동작함

•

1차 버전

◦

Amazon Kendra + Confluence로 문서 검색을 수행하고, 검색 결과와 사용자 질문을 함께 LLM에 주입해 답변을 생성함

flowchart LR
  U[Users] --> S[Slack]
  S --> A[Spring AI]

  subgraph "Retrieval v1"
    K[Amazon Kendra]
    C[Confluence]
    K <-- "크롤링/연동" --> C
  end

  A -- "위키 검색 Tool 호출" --> K
  K -- "검색 결과 컨텍스트" --> A

  subgraph Generation
    B[Amazon BedrockLLM]
  end

  A -- "컨텍스트+프롬프트" --> B
  B -- "답변" --> A
  A --> S --> U
Mermaid
복사

•

최종 버전

◦

비용 이슈로 Typesense로 전환하여 자체 임베딩·색인 파이프라인을 운영함

◦

Confluence 문서 분할·임베딩 후 Typesense에 색인, 검색 결과를 Bedrock 답변에 활용함

flowchart LR
  U[Users] --> S[Slack]
  S --> A[Spring AI]

  %% 실시간 검색
  subgraph "Retrieval v2"
    TS[Typesense with Hybrid]
    KW[NOVA LITE v1: 질문 키워드 추출]
  end

  A -- "질문" --> KW
  KW -- "키워드" --> TS
  A -- "질의 임베딩" --> TS
  TS -- "벡터+키워드 혼합 결과" --> A

  subgraph Generation
    B[Amazon Bedrock:LLM]
  end

  A -- "컨텍스트+프롬프트" --> B
  B -- "답변" --> A
  A --> S --> U
Mermaid
복사

flowchart LR
  %% 배치 임베딩 파이프라인
  subgraph "Nightly Embedding Pipeline"
    C[Confluence] --> E[문서 청킹:1024자 & 메타데이터 추출]
    E --> TEmbed[Amazon Titan Embeddings]
    TEmbed --> IDX[Typesense 색인:벡터+키워드]
  end
Mermaid
복사

2.3.2. Spring AI의 Tool Calling 전략

•

사용자는 자연어로 요청하고, Spring AI가 등록된 Tool들 중 적합한 Tool을 선택·실행함

◦

프롬프트만 전달하면 프롬프트 분석을 해서, 적절한 툴을 선택하여 실행하여 결과 가공 후 응답

•

Tool에는 설명과 출력 형식, 내부 파라미터를 명시하여 모델이 올바르게 선택·호출하도록 유도함

•

예시 흐름

◦

“대화 요약해줘” 요청 → 요약 Tool 선택 → 슬랙 스레드 조회 → 요약 결과 반환

◦

“회사 규정 질문” 요청 → 위키 검색 Tool 선택 → 검색 결과 포맷팅 후 반환

•

예시 코드

@Tool(
    name = "search_wiki",
    description =
    """
    사내 위키(Confluence)에서 질문과 연관 높은 문서를 검색해 정형 포맷으로 반환하는 툴임

    입력
    - userQuery: 사용자의 자연어 질문 문자열
    - channelId: 메시지가 입력된 Slack 채널 ID (권한·호출 정책에 활용)

    동작 개요
    - Spring AI Tool Calling을 통해 호출됨
    - 백엔드 검색 엔진은 구성에 따라 Amazon Kendra 또는 Typesense 하이브리드 검색을 사용함
    - Typesense 사용 시 질의 전 NOVA LITE v1로 핵심 키워드를 추출하고, 질의 임베딩과 함께 하이브리드 검색을 수행함
    - 문서 임베딩 파이프라인은 야간 배치로 동작하며, Confluence 문서를 약 1024자 단위로 청킹 후 Amazon Titan Embeddings로 벡터화해 색인함
    - 최신 수정 문서와 높은 관련도 문서를 우선 반환함

    출력 포맷 (JSON Lines)
    - 각 라인은 아래 스키마를 따름
      {"title":"문서 제목","snippet":["발췌1","발췌2","발췌3"],"url":"원문 링크","source":"confluence","score":0.0~1.0}
    - 문서별 snippet은 최대 3문장까지 포함하며, 질문 의도와 직접 관련된 구절을 우선 선택함
    - 최대 5개 문서를 반환함
    - 검색 결과가 없으면 "관련 문서를 찾지 못했음" 문자열을 반환함

    가드레일
    - 고유명사·코드·버전명은 변형 없이 그대로 유지함
    - 생성형 답변은 본 툴에서 생성하지 않음, 본 툴은 검색 결과만 반환함
    - 민감정보는 검색·노출 정책을 준수함
    - 반환 스키마를 임의로 변경하지 않음
    """
)
open fun search(
    @ToolParam(description = "검색에 사용할 사용자의 질문입니다.")
    userQuery: String,
    @ToolParam(description = "메시지가 입력된 slack channelId입니다.")
    channelId: String,
): String {
    ...
}
Kotlin
복사

// KendraClient를 사용하여 Confluence에서 검색 수행
val searchResults = kendraClient.searchContent( question = userQuery)

// 검색 결과를 응답한다. 답변 생성은 AI가!!
return formatSearchResults( searchResponse = searchResults)
Kotlin
복사

2.3.3. Kendra → Typesense 전환 배경과 구현

•

문제

◦

Kendra 사용 시 트래픽·서브스크립션 비용 급증 이슈가 발생함

◦

자체 운영 대안으로 오픈소스 Typesense 채택을 검토함

•

해결

◦

야간 배치 파이프라인 구성

▪

매일 00시 Confluence 문서 수집

▪

문서를 약 2,000–2,500자 수준으로 청킹하여 임베딩 생성

▪

Amazon Titan Embeddings Text v2로 임베딩 생성 후 Typesense에 색인

▪

메타데이터와 함께 저장하여 출처·링크 제공 가능하게 설계함

•

검색

◦

질의 문장도 임베딩하여 벡터 검색 수행

◦

초기에는 긴 청킹으로 인해 핵심 키워드가 벡터에 희석되어 재현율 저하가 관찰됨

◦

이를 보완하기 위해 키워드 기반 검색과 벡터 검색을 혼합한 Hybrid Search를 적용함

2.3.4. Hybrid Search 세부 전략

•

질문 키워드 추출

◦

경량 모델 NOVA LITE v1로 질의에서 핵심 키워드를 추출함

◦

프롬프트에 “고유명사는 번역·변형 금지”, 출력 형식 고정 등 지침을 넣어 일관성 확보함

•

혼합 검색 실행

◦

Typesense의 hybrid 질의 옵션에 추출 키워드를 함께 전달하여 키워드 + 벡터 동시 검색을 수행함

◦

실제 내부 검색 질문들에서 정확도와 재현율이 유의미하게 개선됨

2.3.5. 운영 인사이트

•

사람 대신 기계가 응답한다는 인식이 생기자 질문량이 증가하고 응답 대기 병목이 완화됨

•

사내 위키에 이미 답이 있어도 찾기 귀찮아 질문하는 패턴을 차비스가 흡수하여 전사 생산성 향상에 기여함

•

도메인별로 확산되어 대외 서비스 FAQ·정책 Q&A 등에서도 활용 범위가 확대됨

•

구현 팁 요약

◦

Tool 설명을 상세히 작성해 모델이 올바른 Tool을 고르게 함

◦

출력 포맷을 엄격히 고정해 환각과 서식 흔들림을 줄임

◦

임베딩 청킹은 짧게, 필요 시 Hybrid Search로 보완함

◦

경량 키워드 모델 + 강력한 생성 모델의 Two-Model 패턴으로 비용 대비 품질 최적화함