네이버의 실시간 거래 리포트 시스템은 대규모 데이터를 다양한 조건으로 빠르게 조회하기 위해 Apache Iceberg와 StarRocks의 Materialized View를 핵심 기술로 활용합니다. 단순히 데이터를 적재하는 수준을 넘어, 데이터의 최신성(Freshness)과 저지연(Low-Latency) 응답 속도, 그리고 시스템 확장성을 동시에 확보하는 것이 이번 기술 여정의 핵심 결론입니다. 이를 통해 복잡한 다차원 필터링이 필요한 비즈니스 환경에서도 사용자에게 즉각적인 분석 결과를 제공하는 데이터 레이크하우스 아키텍처를 구현했습니다.
**실시간 거래 리포트의 기술적 도전 과제**
* 대규모로 발생하는 거래 데이터를 실시간에 가깝게 수집하면서도, 사용자가 원하는 다양한 검색 조건에 즉각 응답해야 하는 성능적 요구사항이 있었습니다.
* 데이터의 양이 방대해짐에 따라 기존의 단순 조회 방식으로는 응답 속도가 저하되는 문제가 발생했으며, 데이터의 신선도와 쿼리 성능 사이의 트레이드오프를 해결해야 했습니다.
* 다차원 필터링과 집계 연산이 빈번한 리포트 특성상, 인덱싱 최적화와 리소스 효율성을 동시에 고려한 설계가 필요했습니다.
**Iceberg와 StarRocks를 활용한 저지연 쿼리 전략**
* **Apache Iceberg 기반 데이터 관리**: 데이터 레이크의 스토리지 포맷으로 Iceberg를 채택하여 ACID 트랜잭션을 보장하고, 대규모 데이터셋에 대한 효율적인 스키마 진화와 파티션 관리를 수행합니다.
* **StarRocks의 구체화 뷰(Materialized View) 도입**: Iceberg에 저장된 원본 데이터를 직접 조회하는 대신, StarRocks의 Materialized View를 활용해 자주 사용되는 쿼리 결과를 미리 연산하여 저장함으로써 조회 속도를 비약적으로 향상시켰습니다.
* **증분 업데이트 및 동기화**: 실시간으로 유입되는 데이터를 Materialized View에 효율적으로 반영하기 위해 Spark와 StarRocks 간의 연동 최적화를 진행하여 데이터의 최신성을 유지합니다.
**아키텍처 구성 요소 및 운영 최적화**
* **Spark**: 대용량 거래 데이터의 가공 및 Iceberg 테이블로의 수집을 담당하는 컴퓨팅 엔진으로 활용됩니다.
* **StarRocks**: 고성능 OLAP 엔진으로서 Iceberg 외부에 위치하며, Materialized View를 통해 복잡한 조인(Join)과 집계(Aggregation) 쿼리를 가속화합니다.
* **확장성 확보**: 데이터 노드와 컴퓨팅 리소스를 분리하여 운영함으로써 트래픽 증가에 유연하게 대응할 수 있는 구조를 설계했습니다.
대용량 실시간 분석 시스템을 구축할 때 Apache Iceberg만으로는 쿼리 성능의 한계가 있을 수 있으므로, StarRocks와 같은 고성능 OLAP 엔진의 구체화 뷰를 결합하는 레이크하우스 전략이 효과적입니다. 특히 데이터의 최신성이 중요한 금융 및 거래 리포트 분야에서 이와 같은 기술 조합은 인프라 비용을 절감하면서도 사용자 경험을 극대화할 수 있는 강력한 대안이 됩니다.
네이버웹툰은 창작 생태계를 위협하는 콘텐츠 불법 유출과 생성형 AI의 무단 저작권 학습에 대응하기 위해 AI 기반의 보호 기술을 연구하고 실무에 도입하고 있습니다. 특히 독자적인 워터마킹 기술인 'TOONRADAR'와 학습 방지 기술인 'IMPASTO'를 통해 창작자의 권리를 보호하고 플랫폼의 신뢰성을 유지하는 데 주력하고 있습니다. 이러한 기술적 대응은 단순한 차단을 넘어 불법 유출자의 사후 추적과 AI 모델의 악의적 모방을 원천적으로 방지함으로써 지속 가능한 창작 환경을 조성하는 것을 목표로 합니다.
**AI 기반 워터마킹을 통한 불법 유출 추적**
* **사후 추적 시스템**: DRM-free 환경에서도 저작권을 보호할 수 있도록 육안으로 식별이 불가능한 미세 신호를 콘텐츠에 삽입하여 유출 경로를 추적합니다.
* **기술적 요구 사항**: 사용자의 시청 경험을 해치지 않는 '비가시성', 이미지 압축이나 편집 공격에도 신호가 유지되는 '강인성', 그리고 충분한 정보를 담을 수 있는 '삽입량'을 동시에 확보했습니다.
* **네트워크 구조**: 삽입기(Embedder), 공격 레이어(Attack Layer), 추출기(Extractor)로 구성된 AI 모델을 구축했습니다. 특히 미분 가능한 네트워크 레이어로 구현된 공격 레이어를 통해 다양한 이미지 변형 공격에 대응하도록 학습되었습니다.
* **성능 지표**: PSNR 46dB 이상의 높은 화질 유지 성능을 달성했으며, 10종 이상의 강도 높은 공격(Level 5) 상황에서도 1% 미만의 낮은 오류율로 워터마크를 추출하는 데 성공했습니다.
**생성형 AI 무단 학습 방지 기술 (IMPASTO)**
* **보호 왜곡(Protective Perturbation)**: 이미지에 미세한 변형을 가해 생성형 AI 모델이 해당 이미지를 학습할 때 스타일이나 콘텐츠를 제대로 모방하지 못하도록 방해합니다.
* **학습 방해 원리**: 디퓨전 모델의 노이즈 제거 과정을 교란하거나 잠재 표현(Latent code) 간의 거리를 조절하여, 무단 학습(LoRA, Dreambooth 등) 결과물이 원작의 의도와 다르게 나오도록 유도합니다.
* **차별화된 연구 방향**: 기존의 학습 방지 도구들이 가졌던 시각적 품질 저하(화질 열화) 문제를 해결하고, 실제 창작 환경에서 빠르게 적용할 수 있도록 처리 속도를 개선하는 데 초점을 맞추고 있습니다.
**유해 콘텐츠 차단 및 플랫폼 건전성 확보 (XPIDER)**
* **자동 탐지 및 차단**: UGC 공간에 업로드되는 선정적·폭력적 콘텐츠를 실시간으로 탐지하여 플랫폼의 대외 신뢰도를 높입니다.
* **도메인 특화 모델**: 일반적인 실사 이미지와는 다른 웹툰 특유의 만화 도메인 데이터를 학습하여 검수 정확도를 극대화하고 운영 리소스를 절감하고 있습니다.
웹툰 창작자는 자신의 작품이 무단으로 유출되거나 AI 학습에 악용되는 것을 방지하기 위해, 플랫폼에서 제공하는 보호 기술을 적극적으로 활용할 필요가 있습니다. 특히 TOONRADAR와 같은 기술은 이미 실무에서 강력한 억제력을 발휘하고 있으므로, 기술적 보안이 강화된 공식 플랫폼을 통해 콘텐츠를 발행하는 것이 창작 생태계 보호의 첫걸음이 될 것입니다.
Slack 보안 엔지니어링 팀은 수십억 건의 이벤트를 처리하는 보안 탐지 시스템의 알림 조사를 AI 에이전트로 효율화했다. 단일 프롬프트에 복잡한 조사 절차를 모두 맡기는 대신, 목적과 출력 형식이 명확한 여러 모델 호출을 연결해 조사 과정을 통제하는 구조를 택했다. Director·Expert·Critic 에이전트가 협력하고 서로의 결과를 검증함으로써 조사 품질의 일관성, 근거 교차검증, 환각 완화를 달성하려는 접근이다.
## 단일 프롬프트 프로토타입의 한계
- 초기 프로토타입은 약 300단어의 프롬프트와 MCP 서버, 코딩 에이전트 CLI를 실행 환경으로 사용했다.
- 프롬프트는 다음 다섯 부분으로 구성됐다.
- **Orientation**: 보안 분석가 역할 정의
- **Manifest**: 사용할 데이터 소스 설명
- **Methodology**: 조사 절차 지시
- **Formatting**: 조사 결과를 Markdown 보고서로 출력
- **Classification**: 대응 등급 분류
- MCP의 stdio 모드 서버를 통해 일부 보안 데이터 소스를 안전하게 도구 호출 방식으로 노출했다.
- 어떤 경우에는 여러 데이터 소스의 증거를 훌륭하게 연결했지만, 다른 경우에는 충분한 검증 없이 편리하거나 잘못된 결론으로 빠르게 진행했다.
- “가정을 의심하라”, “여러 출처로 검증하라”와 같은 지침을 프롬프트에 추가했지만, 프롬프트는 가이드라인일 뿐 세부적인 실행 흐름을 강제하기에는 한계가 있었다.
## 단계별 모델 호출과 구조화된 출력
- 복잡한 조사 전체를 하나의 프롬프트로 처리하지 않고, 조사 과정을 여러 개의 단순한 작업으로 분해했다.
- 각 작업은 다음 요소를 갖는다.
- 명확하게 정의된 단일 목적
- 애플리케이션이 해석하기 쉬운 구조화된 출력
- 다음 단계로 전달할 제한된 컨텍스트
- 각 모델 호출 결과는 JSON 스키마로 제한할 수 있는 구조화된 출력 형식으로 생성된다.
- 구조화된 출력은 작업 간 계약 역할을 하므로, “증거를 의심하라” 같은 추상적인 지침도 독립적인 검토 작업으로 분리할 수 있다.
- 다만 구조화된 출력에도 주의점이 있다.
- 스키마가 지나치게 복잡하면 모델 실행 자체가 실패할 수 있다.
- 모델이 형식을 형식적으로만 충족하거나, 여전히 환각을 포함할 수 있다.
- 이 방식의 핵심 효과는 모델의 행동을 프롬프트 수준이 아니라 애플리케이션의 워크플로 수준에서 통제할 수 있다는 점이다.
## 페르소나 기반 조사 설계
- Slack은 메타 프롬프트와 다중 페르소나 자기협업 관련 연구, 보안 테이블톱 훈련에서 설계 아이디어를 얻었다.
- 하나의 모델 호출 안에서 여러 페르소나를 연기하게 하는 대신, 각 페르소나를 독립적인 모델 호출로 구현했다.
- 각 에이전트와 작업의 조합은 별도의 구조화된 출력 형식을 가지며, 애플리케이션이 호출 순서와 컨텍스트 전달을 orchestration한다.
- 독립 호출 구조에서는 에이전트별로 모델 버전, 프롬프트, 지시사항, 도구, 출력 형식을 다르게 설정할 수 있다.
## Director·Expert·Critic 협업 구조
### Director 에이전트
- 조사 전체를 시작부터 끝까지 진행하는 조사 책임자다.
- 조사에 필요한 질문을 만들고 이를 도메인 전문가에게 전달한다.
- 조사 진행 상황을 계획하고 정리하기 위해 저널링 도구를 사용한다.
- 전문가의 결과와 Critic의 평가를 바탕으로 다음 조사 단계를 결정한다.
### Expert 에이전트
- 특정 도메인 지식과 데이터 소스를 담당한다.
- Director의 질문에 답하기 위해 관련 도구를 호출하고 조사 결과를 생성한다.
- 현재 네 종류의 전문가가 있다.
- **Access**: 인증, 권한 부여, 경계 보안 서비스
- **Cloud**: 인프라, 컴퓨트, 오케스트레이션, 네트워킹
- **Code**: 소스 코드 및 구성 관리 분석
- **Threat**: 위협 분석과 위협 인텔리전스 데이터
- 각 전문가는 자신에게 필요한 데이터 소스에 집중하므로, 하나의 에이전트가 모든 영역을 무분별하게 조사하는 문제를 줄인다.
### Critic 에이전트
- 전문가 결과를 검토하는 메타 전문가다.
- 사전에 정의한 평가 기준에 따라 각 발견 사항의 품질을 평가하고 정량화한다.
- 전문가의 주장에 분석 내용을 추가하고, 각 발견 사항에 신뢰도 점수를 부여한다.
- 가장 신뢰할 수 있는 결과를 바탕으로 타임라인을 구성해 Director에게 전달한다.
- 전문가 그룹과 약한 적대적 관계를 형성함으로써 증거 해석의 편차와 환각을 완화한다.
## 반복형 조사 루프
- Director가 조사 질문을 제시한다.
- 관련 Expert들이 각자의 데이터 소스를 조사해 발견 사항을 생성한다.
- Critic이 발견 사항을 검토하고 신뢰도와 품질을 평가한다.
- Critic은 중요한 결과를 선별하고 신뢰할 수 있는 증거를 이용해 사건 타임라인을 만든다.
- Director는 검증된 발견 사항과 타임라인을 이용해 추가 조사가 필요한지, 다음 질문은 무엇인지 결정한다.
- 이 루프를 통해 한 번의 응답으로 결론을 내리기보다, 질문·조사·검증·진행 결정이 반복되는 조사 프로세스를 구현한다.
## 지식 피라미드와 모델 비용 최적화
- 하위 단계에서는 도메인 전문가가 복잡한 데이터 소스를 직접 조회한다.
- 이 과정은 도구 호출이 많고 반환된 데이터를 분석하는 데 많은 토큰이 필요하므로 상대적으로 비용이 높을 수 있다.
- Critic은 전문가가 생성한 많은 결과를 검토해 중요하고 신뢰할 만한 발견 사항을 추린다.
- 이후 상위 단계의 에이전트는 정제된 결과와 타임라인만 전달받아 더 높은 수준의 판단을 수행한다.
- 이를 통해 모든 단계에서 가장 크고 비싼 모델을 사용하는 대신, 조사 단계별 요구 사항에 맞춰 모델을 선택할 수 있다.
- 즉, 많은 원시 데이터를 처리하는 단계와 최종 판단을 내리는 단계를 분리해 비용과 성능을 함께 조정하는 구조다.
## 실용적인 설계 시사점
- 복잡한 보안 조사를 하나의 거대한 프롬프트에 담기보다, 목적이 명확한 작업과 구조화된 출력으로 분해하는 것이 안정적이다.
- 에이전트 간 역할을 분리하고 독립적인 검토자를 두면 증거 검증과 환각 완화에 도움이 된다.
- 데이터 소스별 전문 에이전트를 두면 각 모델이 불필요한 도구를 사용하거나 모든 영역을 피상적으로 조사하는 문제를 줄일 수 있다.
- 모델 호출을 독립적으로 설계하면 작업별로 모델 크기, 도구, 프롬프트, 출력 스키마를 최적화할 수 있다.
- 다만 구조화된 출력만으로 정확성이 보장되지는 않으므로, 다중 출처 검증과 별도 Critic 단계, 신뢰도 평가를 함께 구성하는 것이 중요하다.
토스가 오프라인 시장으로 확장하며 브랜드 인지도를 높이기 위해 사용자의 무의식 속에 자리 잡은 '진짜 얼굴'을 탐색한 과정을 다룹니다. UX 리서치를 통해 파란색 로고 자체보다 '흰 배경의 앱 아이콘' 형태와 '검정 영문 폰트'의 조합이 브랜드 정체성의 핵심임을 발견했습니다. 이를 통해 추상적인 브랜드 이미지를 구체적인 디자인 원칙으로 정립하여 오프라인 접점과 제품 디자인에 성공적으로 적용한 사례를 제시합니다.
**오프라인 확장을 위한 브랜드 심볼의 재정의**
* 온라인과 달리 맥락이 부족한 오프라인 환경(편의점 댕글러, POS 단말기 등)에서 사용자가 토스를 즉각적으로 인지할 수 있는 시각적 단서를 찾는 것이 과제였습니다.
* 단순히 '어떤 로고가 예쁜가'를 넘어, 사용자가 낯선 환경에서도 토스를 토스로 인식하게 만드는 핵심 자산이 무엇인지 파악하기 위해 리서치를 시작했습니다.
**심층 인터뷰를 통한 브랜드 이미지 탐색**
* 브랜드에 대한 추상적인 인상을 명확한 언어로 표현할 수 있는 사용자를 선별하여 심층 인터뷰를 진행했습니다.
* 사용자들이 느끼는 토스의 핵심은 시각적 요소가 아닌 '군더더기 없는 실용성'과 '편리한 경험'에 집중되어 있음을 확인했습니다.
* 구체적인 시각적 심볼이 부족하다는 문제점을 발견하고, 이를 해결하기 위해 폰트, 컬러, 로고라는 세 가지 요소로 나누어 분석했습니다.
**데이터로 찾아낸 세 가지 핵심 단서**
* **폰트:** 사용자는 앱 내부의 국문 폰트보다 뉴스나 광고 등 외부 매체에서 자주 접한 '검정색 영문 toss'를 브랜드의 대표 폰트로 인지하고 있었습니다.
* **컬러:** 사용자에게 각인된 토스의 컬러는 단일 '파란색'이 아니라, '흰 배경과 파란 로고'가 만나는 조합 그 자체였습니다.
* **로고:** 로고를 직접 그려보게 한 결과, 사용자는 로고 단독 형태가 아니라 스마트폰 화면 속 '네모난 앱 아이콘(흰 바탕 + 파란 로고 + 사각 배경)' 구성을 브랜드의 얼굴로 기억하고 있었습니다.
**리서치 인사이트의 실전 적용**
* 리서치로 정의한 '진짜 심볼(앱 아이콘 형태 + 검정 영문 폰트 + 흰/파/검 조합)'을 실제 디자인에 반영했습니다.
* **토스 10주년 캠페인:** 파란 배경 대신 사용자가 가장 토스답다고 느끼는 흰 바탕에 검정 글씨와 파란 로고 조합을 메인으로 사용했습니다.
* **토스페이 결제 화면:** 전면 파란색 배경 시안을 걷어내고, 리서치로 검증된 시각적 공식을 적용하여 브랜드 인지도를 높였습니다.
브랜드 리서치는 추상적인 감각과 인식을 다루기에 결과물이 모호해질 위험이 있지만, 이를 구체적인 시각적 요소로 분해하여 분석함으로써 실질적인 프로덕트 개선과 일관된 브랜드 경험을 설계할 수 있습니다.
토스페이먼츠는 20년 된 레거시 결제 원장의 구조적 한계와 도메인 간 강한 결합을 해결하기 위해 MySQL 기반의 신규 원장 시스템을 구축했습니다. 데이터 불변성을 보장하는 INSERT-only 원칙과 이벤트 기반 아키텍처를 도입하여 복합 결제 지원 등 비즈니스 확장성을 확보했습니다. 이 과정에서 발생한 데이터 불일치와 타임아웃 문제를 해결하며 시스템의 자가 회복 능력을 강화하고 안정적인 운영 환경을 마련했습니다.
### 레거시 원장 시스템의 한계와 과제
- **데이터 구조의 불일치:** 결제수단별로 테이블 구조가 다르고, 동일한 성격의 데이터가 서로 다른 테이블에 저장되어 유지보수와 온보딩에 큰 비용이 발생했습니다.
- **도메인 간 강한 결합:** 결제, 정산, 회계 등 여러 서비스가 하나의 원장 테이블과 컬럼을 공유하여, 작은 기능 수정 시에도 전사적인 영향도 분석이 필요했습니다.
- **구조적 확장성 부족:** 결제와 결제수단이 1:1 관계로 묶여 있어, 더치페이나 복합 결제(카드+포인트)와 같은 현대적인 결제 시나리오를 지원할 수 없었습니다.
### 신규 원장 설계의 3가지 전략
- **데이터 불변성과 일관성:** 모든 승인 내역을 공통 테이블(`approve`)에 저장하고, 수정 대신 INSERT-only 방식을 채택하여 데이터의 정합성을 높이고 데드락을 방지했습니다.
- **이벤트 기반의 도메인 분리:** 각 도메인이 직접 DB를 조회하는 대신 Kafka 이벤트를 구독하여 데이터를 처리하게 함으로써 도메인 간 의존성을 제거했습니다.
- **결제와 승인 개념의 분리:** '결제'는 주문의 상태를, '승인'은 실제 결제수단의 실행을 의미하도록 분리하여 하나의 결제에 여러 승인 수단이 연결될 수 있는 유연한 구조를 만들었습니다.
### 무중단 마이그레이션 및 정합성 검증
- **비동기 점진적 적재:** 실서비스 장애를 방지하기 위해 기존 원장에 먼저 저장한 후, 신규 원장에는 별도의 ThreadPool을 통한 비동기 방식으로 데이터를 적재했습니다.
- **검증 배치 운영:** 비동기 적재 중 발생할 수 있는 누락을 방지하기 위해, 매 5분마다 Read-Only DB를 기반으로 기존 원장과 신규 원장의 데이터를 비교하고 보정하는 배치를 실행했습니다.
- **고성능 이관 작업:** 수억 건의 데이터 이관을 위해 Bulk Insert를 도입하고, 네트워크 지연 최소화를 위해 마이그레이션 서버를 DB와 동일한 가용 영역(AZ)에 배치했습니다.
### 운영 중 장애 대응과 시스템 고도화
- **쿼리 최적화:** 옵티마이저의 판단 오류로 발생한 풀 스캔(Full Scan) 문제를 인덱스 힌트(Index Hint) 추가와 롤백 시스템을 통해 빠르게 해결했습니다.
- **타임아웃 및 정합성 관리:** MSA 구조에서 서버 간 타임아웃 설정을 일치시키고, 외부 원천사와의 상태 불일치를 해결하기 위한 망취소(Network Cancellation) 로직을 강화했습니다.
- **이벤트 처리의 신뢰성:** 아웃박스(Outbox) 패턴과 로그 기반 복구를 통해 이벤트 누락을 방지하고, 헤더에 멱등키를 포함해 중복 이벤트 처리 문제를 해결했습니다.
신규 시스템으로의 전환은 단순한 DB 교체가 아니라 시스템의 지속 가능성을 확보하는 과정입니다. 초기 설계의 완벽함보다 중요한 것은 운영 중 발생하는 예외 상황에 시스템이 스스로 대응하고 회복할 수 있는 '자가 회복 구조'를 갖추는 것이며, 이를 위해 데이터 보정 배치와 로깅 시스템 같은 안전장치를 반드시 고려해야 합니다.
카카오는 복잡해지는 외부 공격 표면을 체계적으로 관리하기 위해 통합 ASM(Attack Surface Management) 도구인 'YEYE'를 개발하여 운영 중입니다. YEYE는 자산 식별부터 취약점 스캐닝, 데이터 연관 분석까지 자동화하며, 이를 'DSR(Daily Security Review)'이라는 매일의 보안 프로세스와 결합해 실질적인 리스크를 선제적으로 제거합니다. 이를 통해 기술적 자동화와 인적 리뷰가 유기적으로 연결된 견고한 보안 방어 체계를 구축하고 있습니다.
### 공격 표면 관리의 핵심, YEYE와 DSR
* 2023년 탄생한 YEYE는 산재된 보안 도구를 통합하여 외부 접점이 있는 IP, 도메인, 포트, 모바일 앱 등 모든 디지털 자산을 가시화합니다.
* 단순한 도구 도입에 그치지 않고, 매일 오전 외부 피드와 공개 취약점을 검토하는 DSR(Daily Security Review) 프로세스를 통해 사람에 의한 심층 분석을 병행합니다.
* 이를 통해 보안 검수를 받지 않은 자산 노출이나 최신 CVE 이슈에 대해 공격자보다 한발 앞선 대응 체계를 유지합니다.
### 자산의 체계적 정의와 데이터 모델링
* 자산을 범위(In/Out), 타입(Domain/IP/Port 등), 식별 여부(Known/Unknown)로 분류하여 자산이 확장되더라도 일관된 관리 규칙을 적용합니다.
* 다양한 소스에서 수집된 정보를 표준화하고 레이블링(Labeling)하여 데이터의 근본적인 성격을 정의하고 활용도를 높입니다.
* 자산과 취약점, CVE, 담당자 정보를 다형성 구조로 연결하여 특정 보안 이슈 발생 시 영향 범위를 즉각적으로 파악하고 조치 이력을 추적할 수 있습니다.
### 대규모 스캔 환경의 기술적 최적화
* **네트워크 병목 해소:** 내부 물리 서버의 대역폭 한계를 극복하기 위해 퍼블릭 클라우드를 병행 운영함으로써 대규모 동시 요청 시 발생하는 지연 문제를 해결했습니다.
* **병렬 스캔 구조 구현:** 오픈소스 스캐너의 단일 프로세스 한계를 넘기 위해 스케줄러와 큐, 다수의 워커가 독립적으로 작동하는 분산 병렬 처리 구조를 직접 설계했습니다.
* **비용 및 성능 균형:** 고사양 서버를 무조건 투입하기보다 스캔 특성에 맞는 최소 스펙을 도출하고, 적정 스펙의 서버를 효율적으로 분산 확장하는 가성비 기반 인프라를 구축했습니다.
* **서비스 영향 최소화:** 스캔 트래픽을 공격으로 오해하지 않도록 고정 IP와 전용 User-Agent 정보를 제공하며, 초당 호출 수와 타임아웃 등 핵심 파라미터를 정밀하게 튜닝했습니다.
공격 표면 관리는 단순히 자산을 찾는 기술을 넘어, 수집된 데이터를 자산 중심으로 연결하고 매일 반복되는 리뷰 프로세스를 내재화할 때 완성됩니다. 대규모 인프라를 운영하는 조직이라면 네트워크 병목과 비용 효율을 고려한 분산 스캔 구조를 설계하고, 서비스 부하를 고려한 정밀한 튜닝을 통해 공격자보다 먼저 약점을 찾아내는 체계를 갖출 것을 권장합니다.
토스페이먼츠는 Open API를 단순한 통신 수단을 넘어 수십 년간 안정적으로 운영되어야 할 핵심 인프라로 정의합니다. 20만 개 이상의 가맹점이 사용하는 환경에서 개발자의 인지 부하를 줄이고 연동 신뢰성을 높이기 위해, 리소스 중심의 인터페이스 설계와 자동화된 생태계 구축을 최우선 과제로 삼고 있습니다. 이러한 철학은 기술적 완성도를 넘어 가맹점 개발자가 겪는 전반적인 경험(DX)의 질을 결정짓는 근간이 됩니다.
### 리소스 중심의 일관된 인터페이스 설계
* **직관적인 경로 규칙**: 가맹점이 URL 구조만 보고도 기능을 예측할 수 있도록 `버전/도메인/리소스 고유 ID` 순서의 일관된 경로 체계를 사용합니다. 특정 리소스 지정 외의 조건은 쿼리 파라미터나 JSON 필드로 분리하여 명확성을 높였습니다.
* **중첩 객체를 활용한 모듈화**: 카드 정보나 현금영수증 내역처럼 여러 API에서 반복되는 데이터는 JSON의 계층 구조를 활용해 객체 형태로 모듈화합니다. 이는 데이터 중복을 줄이고 응답의 의미를 명확하게 전달하며, null 체크 등 가맹점의 코드 로직을 간소화합니다.
* **도메인별 객체 재사용**: 승인, 조회, 취소 등 연관된 도메인의 API들이 동일한 응답 객체를 공유하도록 설계하여, 개발자가 새로운 API를 연동할 때 추가적인 학습 없이 결과를 예측할 수 있게 합니다.
* **자연어 기반 데이터 표현**: 시스템 효율을 위한 코드 값(예: SC0010) 대신 "현대", "국민"과 같은 직관적인 한글 데이터를 제공합니다. 또한 `Accept-Language` 헤더에 따라 영문 등으로 응답을 자동 전환하는 로컬라이제이션(Localization)을 지원합니다.
* **표준화된 오류 처리**: HTTP 상태 코드로 큰 틀의 성공/실패를 구분하고, 상세한 에러 코드와 메시지를 담은 표준 객체를 응답 바디에 포함하여 가맹점이 상황에 맞춰 유연하게 대응할 수 있도록 돕습니다.
### 비동기 처리를 위한 안정적인 웹훅 체계
* **이벤트 기반 처리**: 즉각적인 응답이 어려운 비동기 결제 상황에서 서버가 클라이언트에 처리 완료를 알리는 웹훅 인터페이스를 API와 함께 제공합니다.
* **데이터 구조의 일관성**: 웹훅을 통해 전달되는 데이터 페이로드를 일반 API 응답과 동일한 리소스 객체 구조로 설계하여 가맹점의 파싱 로직 중복을 방지합니다.
* **지수 백오프(Exponential Backoff) 재전송**: 네트워크 이슈나 가맹점 서버 장애로 인한 웹훅 전송 실패 시, 수신 서비스의 회복 시간을 고려하여 점진적으로 재시도 간격을 늘리는 전략을 사용합니다.
* **자가 조치 도구 제공**: 개발자가 직접 웹훅 전송 내역을 조회하고 필요 시 수동으로 재전송할 수 있는 기능을 개발자 센터를 통해 지원하여 운영 편의성을 높였습니다.
### 개발자 경험(DX) 강화를 위한 문서 자동화
* **OAS 기반 실시간 동기화**: 수동 문서 작성의 한계를 극복하기 위해 OpenAPI Specification(OAS)과 Springdoc 라이브러리를 활용하여 서버 코드와 문서가 실시간으로 동기화되는 시스템을 구축했습니다.
* **문서의 신뢰성 확보**: API 스펙이 변경될 때마다 연동 문서가 즉시 업데이트되므로, 가맹점 개발자는 항상 실제 동작하는 서버와 일치하는 최신 명세를 바탕으로 안심하고 개발할 수 있습니다.
토스페이먼츠의 사례처럼 좋은 Open API는 단순히 기능의 유무를 넘어, 개발자가 '설명 없이도 이해할 수 있는' 직관적인 구조와 자동화된 지원 환경을 갖추어야 합니다. 특히 리소스 중심 설계와 API-웹훅 간 데이터 일관성은 가맹점의 연동 비용을 획기적으로 낮추는 실용적인 전략이 될 수 있습니다.
네이버 통합검색은 서비스 복잡도가 급증함에 따라 발생하는 장애 대응의 한계를 극복하기 위해 LLM 기반의 DevOps 에이전트를 도입했습니다. 이 에이전트는 단순히 장애 알람을 전달하는 수준을 넘어, 시스템 메트릭과 로그를 스스로 분석하고 최적의 조치 방안을 추천하며 경험을 통해 지속적으로 진화합니다. 결과적으로 복잡한 검색 인프라 운영의 효율성을 극대화하고 장애 복구 시간(MTTR)을 단축하는 것을 목표로 합니다.
**기존 장애 대응 프로세스의 한계**
* 네이버 검색은 수많은 마이크로서비스가 복잡하게 얽혀 있어, 장애 발생 시 원인을 파악하기 위해 확인해야 할 메트릭과 로그의 양이 방대합니다.
* 기존의 룰 기반(Rule-based) 시스템은 정해진 규칙 외의 변칙적인 장애 상황에 유연하게 대응하기 어렵고, 운영자의 숙련도에 따라 대응 속도 차이가 크게 발생했습니다.
* 장애 상황마다 산재한 데이터를 수동으로 취합하고 분석하는 과정에서 발생하는 인지적 부하와 시간 지연이 주요 해결 과제로 대두되었습니다.
**Devops Agent의 구조적 진화 (v1에서 v2로)**
* **v1 설계 및 한계:** 초기 버전은 기본적인 데이터 수집과 리포팅 자동화에 집중했으나, 다양한 인프라 환경에서 발생하는 복합적인 컨텍스트를 LLM이 완벽히 이해하고 추론하기에는 한계가 있었습니다.
* **v2 구조 개선:** v1의 한계를 극복하기 위해 Agentic Workflow를 강화하여, 에이전트가 상황에 따라 필요한 도구(Tools)를 스스로 선택하고 분석 단계를 세분화하여 실행하도록 재설계했습니다.
* **SW Stack 고도화:** 최신 LLM 프레임워크와 네이버의 인프라 데이터를 효율적으로 결합하여, 실시간으로 변화하는 시스템 상태를 에이전트가 즉각적으로 파악할 수 있는 기반을 마련했습니다.
**시스템 동작과 이상 탐지 메커니즘**
* **Trigger Queue:** 모든 장애 징후와 알람을 큐(Queue) 시스템으로 관리하여 분석의 우선순위를 정하고, 누락 없는 대응이 가능하도록 설계했습니다.
* **이상 탐지(Anomaly Detection):** 단순 임계치 기반 알람이 아니라, 통계적 모델과 AI를 활용해 평상시 패턴에서 벗어나는 이상 현상을 정교하게 포착합니다.
* **평가 체계:** 에이전트가 내놓은 분석 결과와 추천 액션의 정확도를 지속적으로 평가하며, 실제 엔지니어의 피드백을 학습 데이터로 환류시켜 분석 품질을 높입니다.
**지속 가능한 DevOps를 위한 향후 과제**
* **컨텍스트 확대:** 장애 당시의 로그뿐만 아니라 배포 이력, 설정 변경 내역 등 더 넓은 범위의 데이터를 연동하여 분석의 정확도를 높이고 있습니다.
* **액션 추천 및 자동화:** 장애 원인 분석을 넘어 "특정 서버 그룹의 트래픽을 차단하라"와 같이 구체적인 실행 코드를 생성하거나 직접 조치하는 단계로 확장 중입니다.
* **지속 가능한 학습:** 새로운 유형의 장애가 발생할 때마다 이를 지식화하여 에이전트가 다음번 유사 사례에서 더 똑똑하게 대응할 수 있는 선순환 구조를 구축하고 있습니다.
이 시스템은 인프라 운영자가 반복적인 데이터 취합 업무에서 벗어나 의사결정과 문제 해결에만 집중할 수 있는 환경을 제공합니다. LLM 에이전트의 도입은 단순한 도구 활용을 넘어, 대규모 시스템 운영 노하우를 데이터화하고 지능화된 자동화로 전환하는 중요한 기술적 이정표가 될 것입니다.
효과적인 코드 리뷰를 위해서는 리뷰 코멘트를 작성할 때 결론인 제안이나 요청 사항을 가장 먼저 제시하고, 그에 따른 근거와 이유는 뒤에 덧붙이는 구조를 취해야 합니다. 이러한 방식은 리뷰 요청자가 코멘트의 핵심을 즉각적으로 파악하게 하여 전체적인 리뷰 프로세스의 효율성을 높여줍니다. 명확한 구조로 작성된 코멘트는 불필요한 재독을 줄이고 제안된 의견의 타당성을 더 빠르게 검증할 수 있게 돕습니다.
**불명확한 리뷰 코멘트의 예시와 문제점**
* **가변 객체 사용의 위험성**: Kotlin의 `data class`에서 속성을 `var`로 선언하면 외부에서 객체의 상태를 직접 변경할 수 있어, 의도치 않은 시점에 데이터가 수정되는 버그를 유발할 수 있습니다.
* **불필요한 인스턴스 공유**: 상태를 업데이트할 때 새로운 불변 인스턴스를 생성하는 대신 동일한 가변 객체를 공유하면 시스템의 견고함이 떨어집니다.
* **정보 전달의 지연**: 제안 사항(모든 속성을 `val`로 변경하고 클래스를 분리할 것)이 코멘트의 마지막에 위치하면, 작성자는 긴 설명을 다 읽은 후에야 무엇을 고쳐야 하는지 알게 되어 인지적 부담이 커집니다.
**제안 사항 우선 방식의 코멘트 구조화**
* **핵심 제안 선행**: 코멘트의 첫머리에 "데이터 업데이트 빈도에 따라 클래스를 분리하고 속성을 `val`로 선언하세요"와 같이 구체적인 액션을 명시합니다.
* **근거의 범주화**: 제안 뒤에 붙는 이유는 '객체의 불변성'과 '값의 라이프사이클'처럼 논리적인 항목으로 나누어 설명합니다.
* **가독성 향상 기법**: 설명해야 할 항목이 몇 개인지 미리 밝히고(예: "다음 두 가지 측면에 기반합니다"), 각 항목에 제목을 붙여 구조화하면 전달력이 극대화됩니다.
**데이터 모델링의 기술적 개선 방향**
* **불변성 유지**: `data class`에서는 `var` 대신 `val`을 사용하여 `copy` 함수를 통한 예측 가능한 상태 업데이트를 지향해야 합니다.
* **라이프사이클에 따른 분리**: 사용자 ID와 같이 거의 변하지 않는 속성과, 온라인 상태나 상태 메시지처럼 자주 변하는 속성을 별도의 클래스(예: `UserModel`과 `UserStatus`)로 분리하면 잘못된 업데이트를 방지하기 쉬워집니다.
리뷰 코멘트를 작성할 때는 '빠른 이해'를 목표로 결론부터 쓰는 것이 기본입니다. 다만, 상대방이 스스로 답을 찾아보게 하거나 깊은 고민을 유도하고 싶을 때는 의도적으로 중요한 부분을 뒤에 배치하는 전략을 취할 수도 있습니다. 상황에 맞는 적절한 설명 순서가 코드 품질과 팀의 개발 문화를 결정짓는 중요한 요소가 됩니다.
드롭박스는 2025년 여름 인턴십 프로그램을 통해 43명의 인턴과 함께 AI 기반 통합 검색 도구인 '드롭박스 대시(Dropbox Dash)'를 비롯한 핵심 서비스의 성능과 인프라를 혁신했습니다. 엔지니어링 중심의 이번 기수들은 12주간 멘토링과 실무 프로젝트에 참여하며, 특히 AI 모델의 신뢰성 강화와 다국어 검색 지원 등 드롭박스의 차세대 기술 역량을 끌어올리는 데 기여했습니다. 결과적으로 이번 프로그램은 인턴들에게는 실질적인 기술적 성장을, 기업에는 레거시 시스템 현대화와 운영 효율화라는 실용적 성과를 동시에 안겨주었습니다.
### 드롭박스 대시와 AI 기술 고도화
* **다국어 검색 지원 확대**: 통합 검색 플랫폼(USP)에 언어 감지 파이프라인을 통합하여 리플레이(Replay) 등 드롭박스 제품 전반에 걸쳐 20개 이상의 언어를 지원하는 네이티브 검색 환경을 구축했습니다.
* **ML 모델 모니터링 시스템(AI Sentinel)**: 머신러닝 엔지니어가 수동으로 확인하던 모델 배포 상태를 실시간으로 가시화하는 시스템을 개발하여 배포의 신뢰성을 높이고 반복 주기를 단축했습니다.
* **커넥터 플랫폼 최적화**: 대시의 데이터 저장소에서 최신 정보에 직접 접근할 수 있는 도구를 빌드하여, 외부 시스템의 데이터를 매번 다시 다운로드하지 않고도 최신 메타데이터 기반으로 모델을 학습시킬 수 있게 했습니다.
* **문서 미리보기 및 웹 자동화**: 대시 내에서 문서를 즉시 미리 볼 수 있는 UI와 대화형 AI 기능을 통합하고, 폼 채우기나 교정 등의 반복 업무를 자동화하는 모듈형 AI 에이전트를 개발했습니다.
### 인프라 성능 및 데이터 효율화
* **스토리지 코어(Magic Pocket) 지연 시간 단축**: 디스크 재시작 시 발생하는 쓰기 지연 문제를 해결하기 위해 스토리지 상태를 추적하는 캐시와 성능이 저하된 볼륨을 제외하는 필터링 옵션을 추가하여 검색 결과의 정확도를 높였습니다.
* **파일 시스템 메타데이터 리팩토링**: 레거시 파일 이력 추적 시스템을 현대화하여 메타데이터 인프라를 단순화하고 운영 비용을 대폭 절감했습니다.
* **대규모 데이터 분석 최적화**: Databricks 쿼리와 ETL 파이프라인의 고비용 패턴을 식별하는 추천 시스템을 구축하고, 500TB 규모의 모바일 이벤트 로그를 최신 데이터 레이아웃 기술인 '리퀴드 클러스터링(Liquid Clustering)'으로 마이그레이션했습니다.
### 개발자 경험 및 운영 도구 개선
* **AI 기반 코드 마이그레이션**: 특정 폴더나 유형에 대해 코드 마이그레이션을 자동화하고 결과가 성공적일 경우 자동으로 Pull Request를 생성하는 도구를 제작하여 대규모 마이그레이션 작업을 효율화했습니다.
* **지능형 지표 감지 시스템(Vortex2)**: 고정된 임계값 대신 데이터의 계절성과 변화 패턴을 학습하는 적응형 이상 탐지 기법을 도입하여 알림 피로도를 줄이고 장애 대응 속도를 개선했습니다.
이러한 인턴들의 성과는 드롭박스가 단순한 파일 저장소를 넘어 AI 중심의 워크플로우 플랫폼으로 진화하고 있음을 보여줍니다. 특히 대규모 마이그레이션 자동화나 인프라 수준의 지연 시간 최적화와 같은 실무적인 기술 해결책은 엔지니어링 팀의 생산성을 직접적으로 높이는 실용적인 결론을 도출했습니다.
AI와 비전문가도 리서치를 수행할 수 있는 시대에 UX 리서처의 진정한 역할은 단순히 데이터를 수집하는 기술적 숙련도를 넘어, 제품의 방향성을 설정하고 팀의 시야를 하나로 모으는 'UX 리더십'에 있습니다. 리서처는 제품 개발의 각 단계에서 사용자의 본질적인 문제를 정의하고, 복잡한 비즈니스 맥락 속에서 팀이 길을 잃지 않도록 돕는 나침반 역할을 수행해야 합니다.
## 아이디어 단계: 사용자 중심의 '퍼즐 테두리' 맞추기
- 기획 초기 단계에서 팀의 관점을 '우리가 무엇을 만들 수 있는가'에서 '유저의 어떤 문제를 해결할 것인가'로 전환시킵니다.
- 비즈니스 지표(재방문율, 체류시간 등)에만 매몰될 경우 발생할 수 있는 UX 저해 요소들을 사용자 관점의 가치 정의를 통해 방어합니다.
- **사례(AI 시그널):** 단순한 정보 요약 기능을 넘어, 유저가 시장 변화의 이유를 빠르게 파악하여 투자 판단을 돕는다는 '북극성(핵심 가치)'을 설정해 제품의 윤곽을 잡았습니다.
## 개선 단계: 사용자 목표 중심의 구조화와 기준 수립
- 흩어져 있는 피드백과 문제점들을 나열하기보다, 사용자가 해당 기능을 통해 달성하려는 최종 '목표'를 먼저 정의합니다.
- 목표 달성을 가로막는 방해 요인을 파악하고, 팀 전체가 동의할 수 있는 '서비스를 잘 쓴다는 것'에 대한 합의된 기준을 만듭니다.
- **사례(증시 캘린더):** 단순한 일정 나열을 넘어 '인지-이해-준비'라는 3단계 사용자 여정을 설정함으로써, UI 수정을 넘어 투자자가 시장을 스스로 판단하게 돕는 도구로 제품을 고도화했습니다.
## 성장 및 정체 단계: 제품의 정체성과 환경적 맥락 재정의
- 제품의 성장이 정체되었을 때, 기능적 결함이 아닌 '제품의 정체성'과 '사용 환경(맥락)'의 불일치를 분석합니다.
- 데이터, 인터뷰, 시장 트렌드를 입체적으로 결합하여 제품이 시장 내에서 차지해야 할 최적의 위치를 다시 찾습니다.
- **사례(토스증권 PC):** 모바일의 '심플함'이 깊이 있는 분석이 필요한 PC 환경에서는 오히려 한계가 될 수 있음을 발견하고, PC라는 맥락에 맞는 새로운 가치와 제품의 지향점을 재정립했습니다.
## 리서처를 위한 실용적 제언
UX 리서처는 인터뷰를 잘하는 '기술적 장인'에 머물기보다, 제품과 산업 전체를 조망하는 넓은 시야를 갖추어야 합니다. 특히 팀원들의 흩어진 생각을 구조화하고, 의사결정의 근거가 되는 기준을 마련하여 **실질적으로 팀을 움직이게 만드는 'UX 리더십'**을 발휘하는 것이 AI 시대 리서처의 핵심 경쟁력입니다.
LINE CTF는 글로벌 보안 전문가들이 최신 공격 및 방어 기법을 공유하며 기술적으로 성장하는 장으로, 2025년 대회는 AI 시대에 맞춘 고도화된 문제 설계와 다국적 협업을 통해 성공적으로 운영되었습니다. LY Corporation은 단순한 경쟁을 넘어 보안 커뮤니티의 발전을 도모하며, 참가자들이 실전적인 취약점 분석 역량을 기를 수 있도록 대회를 매년 정교화하고 있습니다. 올해 대회는 개인정보 보호를 강화한 시스템 운영과 완성도 높은 문제를 통해 아시아를 대표하는 보안 이벤트로서의 입지를 공고히 했습니다.
**AI 시대의 공정성을 고려한 문제 설계**
* AI 도구(LLM 등)를 이용한 코드 분석이나 자동화 연산이 활발해진 환경을 반영하여, 도구 사용 여부와 관계없이 문제의 핵심 논리를 이해해야만 해결할 수 있도록 설계했습니다.
* 일부 문제에는 AI가 의도적으로 잘못된 분석 결과를 내놓도록 유도하는 요소를 포함하여, 참가자의 순수한 분석력과 사고력을 검증했습니다.
* 웹(6), 포너블(4), 역공학(3) 등 총 13개의 문제를 통해 최신 기술 트렌드와 실무 보안 상황을 결합한 고난도 콘텐츠를 제공했습니다.
**다국적 협업과 체계적인 운영 프로세스**
* 한국 보안 팀이 기획을 주도하고, 베트남 엔지니어들이 가장 많은 문제를 출제했으며, 일본 팀이 검수와 자문을 맡는 등 긴밀한 글로벌 협업 구조를 구축했습니다.
* LY Corporation 통합 이후 처음으로 적용된 내부 행정 및 승인 프로세스를 통해 출제, 운영, 검토 단계를 세밀하게 관리하며 대회의 안정성을 높였습니다.
* CTFtime 평점이 3년 연속 상승(35.0 → 66.5)하며 문제의 깊이와 운영 품질에 대해 글로벌 커뮤니티로부터 높은 신뢰를 얻었습니다.
**Jeopardy 형식 기반의 기술적 탐구**
* 참가자가 독립된 문제를 자유롭게 선택해 플래그(Flag)를 찾는 Jeopardy 방식을 채택하여 24시간 동안 순수한 문제 해결 능력에 집중할 수 있게 했습니다.
* 오픈소스 CTF 프레임워크인 CTFd를 커스터마이징하여 사용했으며, Discord를 통해 전 세계 참가자들과 실시간으로 소통하며 건강한 기술 공유 문화를 형성했습니다.
* 한국의 'The Duck' 팀이 3년 연속 우승을 차지한 가운데, 종료 직전까지 2, 3위 순위가 뒤바뀌는 긴박한 경쟁 환경을 제공했습니다.
**보안성과 편의성을 모두 잡은 플랫폼 운영**
* 개인정보 보호를 최우선으로 하여 이메일 등록 없이 '복구 코드(Recovery Code)'만으로 계정을 관리할 수 있는 시스템을 설계하여 개인정보 유출 리스크를 원천 차단했습니다.
* 수백 명의 동시 접속에도 견딜 수 있는 안정적인 서버 인프라를 구축하여 대회 기간 중 기술적 장애 없는 쾌적한 환경을 유지했습니다.
* 비정상적인 플래그 거래나 부정행위 없이 성숙한 커뮤니티 매너 속에서 대회가 진행되어 운영 안정성을 확보했습니다.
보안 엔지니어로서 실무 감각을 익히고 취약점 분석 역량을 한 단계 높이고 싶다면, 매년 정교한 난이도와 최신 트렌드를 반영하는 LINE CTF에 도전해 보기를 추천합니다. 직접 문제를 해결하며 얻는 논리적 사고력과 성취감은 실무 현장에서 강력한 자산이 될 것입니다.
네이버 엔지니어링 데이에서 발표된 이 내용은 로컬 LLM인 Ollama와 오픈소스 mcp-agent를 활용하여 프로젝트 자동화의 수준을 한 단계 높인 실무 사례를 다룹니다. 빌드 실패 분석부터 크래시 로그 요약, Slack 알림까지의 과정을 AI가 스스로 판단하고 수행하는 '협력자'로서의 모델을 제시하며, 이를 통해 개발자가 반복적인 모니터링 업무에서 벗어나 고차원적인 문제 해결에 집중할 수 있음을 보여줍니다.
**로컬 기반 LLM 및 에이전트 활용 아키텍처**
- Ollama를 활용하여 로컬 환경에 LLM을 구축함으로써 사내 보안 문제를 해결하고 데이터 유출 걱정 없이 분석 환경을 조성합니다.
- 오픈소스인 mcp-agent(Model Context Protocol)를 도입하여 AI 모델이 단순한 텍스트 생성을 넘어 외부 도구 및 데이터와 실시간으로 상호작용하도록 설계합니다.
- 단순 스크립트 기반 자동화와 달리, AI 에이전트가 상황을 인지하고 적절한 도구를 선택해 작업을 수행하는 유연한 워크플로우를 구현합니다.
**지능형 빌드 실패 분석 및 크래시 모니터링**
- 빌드 과정에서 발생하는 방대한 양의 에러 로그를 AI가 즉시 분석하여 실패의 근본 원인을 파악하고 요약합니다.
- 앱 실행 중 발생하는 크래시 로그를 실시간으로 모니터링하고, 코드 변경 이력 등을 대조하여 해당 문제를 해결하기에 가장 적합한 담당자(Assignee)를 자동으로 매칭합니다.
- 비정형 데이터인 로그 메시지를 의미론적으로 해석함으로써 기존 키워드 매칭 방식의 한계를 극복합니다.
**Slack 연동을 통한 자동화된 리포팅 체계**
- AI가 분석한 빌드 결과와 크래시 요약 내용을 Slack API를 통해 개발 팀 채널에 실시간으로 공유합니다.
- 리포트에는 단순히 에러 메시지만 전달하는 것이 아니라, AI가 제안하는 해결 방안과 우선순위 등을 포함하여 팀의 의사결정 속도를 높입니다.
- Slack 내에서 LLM과 대화하며 추가적인 로그 분석이나 세부 사항을 질의할 수 있는 대화형 자동화 환경을 제공합니다.
**AI 자동화 도입 시 고려사항 및 한계**
- LLM과 MCP의 조합이 강력하지만 모든 문제를 해결하는 만능 도구는 아니며, 결과값의 할루시네이션(환각 현상)에 대한 검증 프로세스가 병행되어야 합니다.
- 자동화가 복잡해질수록 AI가 도구를 잘못 선택하거나 잘못된 분석을 내놓을 가능성이 있으므로, 단계적인 도입과 신뢰도 테스트가 필수적입니다.
**실용적인 제언**
로컬 LLM을 활용한 자동화는 보안이 중요한 사내 프로젝트에서 비정형 데이터 분석 업무를 획기적으로 줄여줍니다. 특히 MCP와 같은 최신 프로토콜을 적극적으로 활용하여 LLM이 실제 개발 도구들과 긴밀하게 연결될 수 있도록 설계하는 것이 성공적인 AI 자동화 도입의 핵심입니다.
웹 애플리케이션에서 하나의 HTTP 요청 내에 발생하는 중복된 API 호출은 성능 저하와 리소스 낭비를 초래하며, 이를 해결하기 위해 요청 범위(Request Scope) 내에서 결과를 캐싱하는 `@RequestCache` 커스텀 애너테이션을 개발했습니다. 이 기능은 Spring의 `RequestAttribute`를 활용해 요청별로 독립적인 캐시 공간을 보장하며, 요청 종료 시 자동으로 메모리가 정리되는 효율적인 생명주기 관리 구조를 가집니다. 이를 통해 복잡한 파라미터 전달이나 부적절한 TTL 설정 문제를 해결하고 시스템의 전반적인 응답 속도를 개선할 수 있습니다.
### 파라미터 전달 및 범용 캐시의 한계
* **응답 객체 전달 방식의 복잡성**: 데이터를 실제 사용하는 말단 서비스까지 객체를 넘기기 위해 중간 계층의 모든 메서드 시그니처를 수정해야 하며, 이는 코드 가독성을 떨어뜨리고 관리를 어렵게 만듭니다.
* **전략 패턴의 유연성 저하**: 공통 인터페이스를 사용하는 경우, 특정 구현체에서만 필요한 데이터를 파라미터에 포함해야 하므로 인터페이스의 범용성이 훼손됩니다.
* **TTL(Time To Live) 설정의 딜레마**: Redis나 로컬 캐시 사용 시 TTL이 너무 짧으면 동일 요청 내 중복 호출을 막지 못하고, 너무 길면 서로 다른 요청 간에 의도치 않은 데이터 공유가 발생하여 데이터 정합성 문제가 생길 수 있습니다.
### @RequestCache의 특징과 동작 원리
* **RequestAttribute 기반 저장소**: 내부적으로 `ThreadLocal`을 사용하는 `RequestAttribute`에 데이터를 저장하여, 스레드 간 격리를 보장하고 각 HTTP 요청마다 독립적인 캐시 인스턴스를 유지합니다.
* **자동 생명주기 관리**: 캐시의 수명이 HTTP 요청의 생명주기와 일치하므로 별도의 만료 시간을 계산할 필요가 없으며, 요청 완료 시 Spring의 `FrameworkServlet`에 의해 자동으로 정리되어 메모리 누수를 방지합니다.
* **AOP 기반의 간편한 적용**: 비즈니스 로직을 수정할 필요 없이 캐싱이 필요한 메서드에 `@RequestCache` 애너테이션을 선언하는 것만으로 손쉽게 중복 호출을 제거할 수 있습니다.
### @RequestScope와 프록시 메커니즘
* **프록시 패턴 활용**: `@RequestScope`로 선언된 빈은 Spring 컨테이너에 프록시 객체로 등록되며, 실제 메서드 호출 시점에 현재 요청에 해당하는 실제 인스턴스를 찾아 호출을 위임합니다.
* **상태 저장 방식**: `AbstractRequestAttributesScope` 클래스를 통해 실제 객체가 `RequestAttributes` 내에 저장되며, 이를 통해 동일 요청 내에서는 같은 인스턴스를 공유하게 됩니다.
동일 요청 내에서 외부 API 호출이 잦거나 복잡한 연산이 반복되는 서비스라면, 전역 캐시를 도입하기 전 `@RequestCache`와 같은 요청 범위 캐싱을 통해 코드 순수성을 유지하면서도 성능을 최적화할 것을 권장합니다.
브리티시컬럼비아의 소규모 농가가 생산물 판매와 유통 과정에서 겪는 문제를 해결하기 위해, 창업자 Aaron Veale은 Figma Make로 농가와 밴쿠버 레스토랑을 연결하는 마켓플레이스 앱 Planet Food를 3주 이내에 구축했다. 약 20개의 프롬프트만으로 첫 프로토타입을 만들고, 농부와 셰프의 피드백을 즉시 반영하며 제품을 발전시켰다. 이 사례는 AI 도구가 개발 속도를 높이는 동시에, 창업자가 고객 문제와 사용자 경험에 더 집중하도록 돕는 과정을 보여준다.
## 소규모 농가가 직면한 구조적 문제
- 브리티시컬럼비아에서는 매주 한 곳의 농가가 폐업할 정도로 상황이 심각하다고 소개된다.
- 농가들은 다음과 같은 문제를 겪고 있다.
- 생산 비용 상승
- 불안정한 공급망
- 변화하는 정부 규정
- 대형 유통업체에 대한 의존
- 마케팅과 판매 역량 부족
- BC 농가의 순손실은 지난해 4억 5,700만 캐나다달러에 달했으며, 농업 부문은 2017년부터 순손실 상태였다.
- Veale은 수십 명의 농부와 대화한 뒤, 농가가 생산에는 강하지만 직접 판매와 시장 접근에는 취약하다는 점을 파악했다.
- 이에 따라 지역 농가와 고품질 식재료를 찾는 밴쿠버 레스토랑을 직접 연결하는 마켓플레이스를 구상했다.
## Figma Make로 빠르게 만든 Planet Food
- 일반적인 스타트업 방식이라면 투자 유치, 팀 구성, 제품 개발에 상당한 시간이 필요하다.
- Veale은 문제의 긴급성을 고려해 Figma Make의 프롬프트 기반 앱 제작 기능을 활용했다.
- 하루 동안 약 20개의 프롬프트를 입력해 초기 프로토타입을 만들었다.
- Planet Food는 다음 두 운영체계로 구성됐다.
- **Farm OS**: 농부가 수확한 농산물을 기록하고 분류하는 기능
- **Restaurant OS**: 셰프가 식재료를 검색하고 주문하는 기능
- 초기 제품을 실제 고객에게 빠르게 보여줌으로써 다음을 확인할 수 있었다.
- 고객이 어떤 기능을 필요로 하는지
- 실제 사용 가능성이 있는지
- 투자자에게 제품 사용성과 시장 신호를 제시할 수 있는지
## 버전 1: 대화를 시작하기 위한 프로토타입
- Veale은 Farm OS와 Restaurant OS를 별도의 Figma Make 작업으로 동시에 개발했다.
- 한쪽 시스템을 생성하는 동안 다른 쪽에 기능과 화면을 계속 추가하는 방식으로 작업했다.
- 10~20개의 프롬프트만으로 여러 화면으로 구성된 시스템을 만들고, 다음 날 농부나 레스토랑에 직접 시연했다.
- 초기 제품은 완성품이라기보다 고객과 문제를 논의하기 위한 대화 도구로 사용됐다.
- 현장 인터뷰를 바탕으로 농부의 실제 업무 환경에 맞춰 UX를 조정했다.
- 야외에서 햇빛 반사를 줄이기 위해 기본값을 다크 모드로 설정
- 하루 12~16시간 일하는 농부를 고려해 행정·판매 업무를 최소화
- 앱 내 작업을 세 번 이하의 클릭으로 완료하도록 설계
- 불필요한 정보와 클릭 수를 줄여 업무 흐름을 단순화
- 익숙한 앱의 스와이프, 슬라이드업 같은 마이크로 인터랙션을 캡처해 프롬프트에 입력하고, 이를 하나의 모바일 중심 UI로 통합했다.
## 버전 2: 사용자 경험과 브랜드 강화
- 초기 기능이 검증된 뒤에는 앱의 시각적 완성도와 감정적 경험을 개선하는 데 집중했다.
- Veale은 과거에는 자신의 디자인 아이디어를 구현하기 위해 여러 개발자에게 의존해야 했고, 그 과정에서 타협이 발생했다고 설명한다.
- Figma Make를 통해 디자이너가 직접 구현 과정에 참여하면서 다음 요소에 더 집중할 수 있게 됐다고 평가한다.
- 브랜딩
- 인터랙션
- 온보딩 경험
- 고객 경험 전반
- 영화감독 경험을 바탕으로 프롬프트를 단순한 명령이 아니라 사용자의 관점에서 작성하는 이야기로 접근했다.
- 농부와 셰프에 대한 구체적인 페르소나를 작성해 프롬프트의 맥락으로 활용했다.
- 소규모 팀으로 농장을 운영하며 계절별 업무량이 많은 농장주
- 기술에 호기심은 있지만 기술 중심적이지 않은 사용자
- 공정한 가격과 안정적인 수입을 원하는 사용자
- 재배, 수확, 물류, 판매, 청구를 동시에 처리해야 하는 사용자
- 주요 페인 포인트도 명시적으로 정리했다.
- 스프레드시트와 문서를 수동으로 업데이트하는 업무
- 매주 레스토랑의 수요를 예측하기 어려운 문제
- 실시간 재고 동기화 부족으로 인한 과잉 판매·판매 부족
- ChatGPT로 사용자 페르소나와 온보딩 흐름을 분석하고, Figma Make에 입력할 프롬프트를 다시 생성하는 방식으로 AI 도구를 연계했다.
- 앱에 커스텀 아이콘을 추가해 기능 중심의 도구에 색상과 개성을 더했다.
## 빠른 반복 개발과 고객 중심 설계
- Veale은 먼저 완벽한 제품을 만들기보다, 빠르게 작동하는 버전을 만들어 실제 사용자와 대화하는 방식을 택했다.
- 고객 피드백은 단순한 기능 요청이 아니라 다음 설계 결정의 근거로 활용됐다.
- 농부의 작업 환경
- 업무 시간과 행정 부담
- 디지털 도구에 대한 숙련도
- 레스토랑의 주문 및 재고 관리 방식
- Figma Make는 프롬프트를 반복 수정하면서 화면, 기능, 인터랙션을 점진적으로 쌓는 개발 방식에 적합했다.
- AI가 구현 속도를 높여주면서 창업자와 디자이너는 코드 작성보다 문제 정의와 사용자 경험에 더 많은 시간을 쓸 수 있었다.
실무적으로는 AI 앱 제작 도구를 사용할 때 처음부터 완성도를 높이려 하기보다, 핵심 사용자와 문제를 구체적인 페르소나로 정의한 뒤 작은 프로토타입을 빠르게 만들고 실제 고객 피드백으로 반복 개선하는 접근이 효과적이다.
naver원문
