AI 에이전트를 현장에 배치하는 FDE.
설계하고, 구축하고, 팀의 일하는 방식을 바꿉니다.

01 문제 정의

• Claude Code, Codex, Gemini CLI를 동시에 돌리면 어떤 에이전트가 작업 중이고 어떤 것이 끝났는지 한눈에 보이지 않았습니다.
• 에이전트 하나에 작업 하나씩 맡기는 방식은 너무 느립니다. 수십 개의 작업을 동시에 돌리고, 에이전트끼리 맥락을 주고받게 하고 싶었습니다.
• 메모와 스펙 문서가 에이전트가 읽을 수 있는 형태로 정리되어 있지 않았습니다.

02 해결 방법

• Agentty: 수십 개의 에이전트를 분할 화면에서 동시에 실행하고 각각의 상태를 보여주는 터미널입니다. 세션을 공유하면 한 작업의 맥락이 다음 작업으로 전파됩니다.
• Agentty의 핵심은 FDE 관점입니다. 팀과 업무 환경마다 필요한 에이전트가 다르기 때문에, 상황에 맞는 플러그인을 만들어 그 안에서 전용 에이전트를 실행합니다. 새로운 현장에는 도구를 다시 만드는 대신 플러그인 하나를 더하면 됩니다.
• Cosmica: 에이전트가 바로 읽을 수 있도록 모든 것을 Markdown으로 저장하는 노트 앱입니다. 음성 메모를 요약하고 지식 그래프로 연결합니다.

03 이뤄낸 성과

• 기능 개발, 테스트, 리뷰를 Claude Code와 Codex에 나눠 맡기고, 저는 작업을 설계하고 결과를 검토합니다. 혼자서도 여러 작업을 동시에 진행할 수 있게 됐습니다.
• 반복적인 개발과 운영 업무는 에이전트에 맡기고, 같은 방식을 회사 실무에도 적용하고 있습니다.
• 회의 기록과 메모를 Markdown으로 기록하고, 회의 녹음의 결과가 자동으로 맥락이 되어 업무로 즉시 이어집니다. Cosmica와 Agentty가 서로 연결되어 업무 효율을 높였습니다.

01 문제 정의

• 블랙프라이데이나 캠페인이 열리면 하루치 트래픽이 몇 분 안에 몰립니다.
• 트래픽이 몰려도 리워드 지급은 한 건도 어긋나면 안 됩니다.

02 해결 방법

• 요청이 집중되는 구간은 Redis로 처리하도록 설계했습니다. 카운터, 캐시, 짧게 유지되는 상태는 DB를 거치지 않습니다.
• 리워드 지급과 후속 처리 사이에 Kafka를 두는 구조로, 트래픽이 몰려도 다른 서비스로 번지지 않고 순서대로 처리되게 했습니다.
• AI 기반으로 코딩, 테스트, 리뷰, 운영 작업을 자동화하는 개발 체계를 만들어 팀 실무에 적용했습니다.

03 이뤄낸 성과

• 블랙프라이데이 규모의 트래픽에서도 서비스가 안정적으로 동작합니다.
• 개발과 운영 자동화가 팀의 일상적인 작업 방식으로 자리 잡았습니다.

01 문제 정의

• 30개국 이상의 사용자가 걸음 수로 WKM 토큰을 채굴하고, 채굴 내역이 몇 초 안에 공개 익스플로러에 보여야 합니다.
• 매시간 에너지가 충전되고 정해진 시각에 추첨이 열려 트래픽이 한꺼번에 몰리고, 걸음 수를 조작하려는 시도도 많습니다.
• 소규모 팀을 이끌며 기획, 개발, 운영을 한 방향으로 맞춰 굴려야 했습니다.

02 해결 방법

• AWS에 Elastic Beanstalk, RDS(Aurora MySQL, 읽기/쓰기 분리), ElastiCache Redis, Secrets Manager, S3로 인프라를 설계했습니다.
• 채굴이 발생하면 비동기 이벤트로 Redis를 갱신하고, Next.js 익스플로러가 이를 주기적으로 읽어 실시간 채굴 현황을 보여줍니다. 조회 트래픽은 MySQL에 닿지 않습니다.
• HMAC 체크섬, 재전송 탐지, IP 위험도 조회, 일일 보상 감소 곡선, 재고 비관적 락으로 조작과 중복 지급을 막았습니다.
• XPLA와 제휴하고 Solana 지갑 지급을 연동했으며, iOS와 Android 앱까지 전체 개발을 이끌었습니다.

03 이뤄낸 성과

• 30개국 이상에서 사용자를 확보했습니다.
• 평균 앱 사용 시간 3시간 이상을 달성했습니다. 사용자 비중은 일본, 한국, 미국, 유럽 순입니다.
• 평균 동시 접속 사용자 수백 명을 유지했습니다.
• 누적 걸음 710억 회, 마이닝 2,690만 건이 공개 익스플로러에 기록됐습니다.

01 문제 정의

• 실시간 호가와 차트가 있는 오더북 거래와 유동성 풀을 체인이 혼잡할 때도 끊김 없이 보여줘야 합니다.
• 온체인 데이터를 그대로 읽으면 느리고 비싸서, 거래 화면에 맞는 데이터 경로가 따로 필요했습니다.

02 해결 방법

• 오더북 거래, 자체 AMM 풀 프로그램, Jupiter 연동 스왑과 지정가 주문까지 거래소의 핵심 기능을 설계하고 개발했습니다.
• 자체 RPC 엔드포인트를 두고, 오더북은 폴링 주기를 조정해 가져오며, TradingView 차트에 직접 만든 데이터피드를 연결했습니다.
• AWS 인프라(ECS, RDS, ElastiCache, MSK, WAF)를 Pulumi 코드로 설계하고 마이크로서비스 8개로 구성했습니다.

03 이뤄낸 성과

• Solana 메인넷용 오더북 거래, 스왑, 유동성 풀, 런치패드, 스테이킹 기능을 개발했습니다.
• 거래소 프론트엔드부터 온체인 프로그램, 인프라까지 전체 구조를 설계했습니다.

01 문제 정의

• 예약 요청부터 최종 확정까지 여러 단계와 외부 업체를 거칩니다.
• 동기 방식으로 처리하면 한 단계만 느려져도 사용자가 기다려야 하고, 실패하면 예약이 중간 상태로 남습니다.

02 해결 방법

• 예약을 먼저 접수한 뒤 이후 단계는 Spring 애플리케이션 이벤트로 비동기 처리하도록 설계했습니다.
• 단계별 상태를 Redis에 저장해 재시도해도 중복 처리되지 않게 했습니다.

03 이뤄낸 성과

• 사용자는 바로 응답을 받고 확정은 뒤에서 처리되어, 예약 시스템을 안정적으로 운영할 수 있었습니다.