Kim Seung Hyeon

🧩 프로젝트 개요

블록체인 기반 투명 기부 플랫폼입니다.
기부 → 분배 → 소비 → 정산 전체 흐름을 온체인에 기록하며,
AI 기반 FDS(Fraud Detection System)가 이상 거래를 탐지합니다.

⚙️ 핵심 로직

KRW 결제 → RLF(ERC20) 민팅 → 지역 풀 기부 → 관리자 확정 → 월말 분배/이월 → 수혜자 소비 → 가맹점 정산 후 토큰 소각으로 이어지는 토큰 순환 구조가 핵심입니다.
Spring Batch + Quartz 스케줄러가 월 1회 FastAPI FDS 서버에 배치 요청을 보내고, DQN 모델이 17개 피처를 기반으로 이상 거래를 탐지합니다.

👨‍💻 주요 기여도

Backend

1. BlockchainManagerService 설계 및 구현 — 컨트랙트의 모든 기능을 REST API
2. Web3j 기반 Spring Boot ↔ Hardhat, 테스트넷 RPC 연동
3. 수탁형 지갑 방식 채택 — 서버가 어드민 지갑으로 트랜잭션 대행 서명

DevOps

1. Traefik 리버스 프록시 구성 — 경로 기반 라우팅으로 단일 도메인 멀티 서비스 운영 + Let's Encrypt TLS 자동 발급
2. Docker Compose 3단계 분리 — 로컬 인프라 / 서버 인프라 / 애플리케이션 컨테이너 환경별 독립 관리
3. Jenkins CI/CD 파이프라인 — GitLab Webhook + 15개 환경변수 + Gradle 빌드/배포/헬스체크 자동화
4. Dozzle(실시간 로그), Redis Commander 등 운영 관측 도구 통합

BlockChain

1. DonationToken.sol — ERC20 + Ownable 기반 커스텀 토큰, 소유권 DonationPlatform 컨트랙트로 이전
2. DonationPlatform.sol — 5개 역할, 6개 데이터 구조, 14개 이벤트 설계, ReentrancyGuard 적용으로 재진입 공격 차단
3. 배포 자동화 스크립트(deploy.js) — 배포 후 .env를 컨트랙트 주소로 자동 갱신, Hardhat 로컬 및 Sepolia 테스트넷 검증 완료

🧯 트러블 슈팅

컨트랙트 재배포 시 백엔드/프론트엔드 주소 불일치 문제 문제: 스마트 컨트랙트를 수정·재배포할 때마다 새 컨트랙트 주소를 각 .env 파일에 수동으로 복사해야 했고, 팀원 간 주소 불일치로 트랜잭션 실패가 반복됐습니다. 해결: deploy.js에 배포 완료 후 두 .env 파일을 Node.js fs로 정규식 치환해 자동 업데이트하는 로직을 추가했습니다. Docker 볼륨 마운트로 컨테이너 내 배포 시에도 호스트 파일이 갱신되도록 설정했습니다. 배운점: 반복되는 수동 설정 작업은 실수의 온상입니다. 배포 스크립트가 환경 설정까지 자동으로 갱신하도록 자동화 범위를 넓히면 팀 전체의 개발 사이클 신뢰도가 높아진다는 것을 체감했습니다.

Traefik 경로 기반 라우팅에서 /rpc 접두사 미제거 이슈 문제: Hardhat JSON-RPC 노드는 루트(/) 경로로 요청을 수신하는데, Traefik이 /rpc 접두사를 그대로 전달해 Web3j 및 프론트엔드의 모든 RPC 호출이 404로 실패했습니다. 해결: Traefik 라우터에 stripprefix 미들웨어를 적용해 /rpc 접두사를 제거한 후 Hardhat에 전달했습니다. 동일한 패턴을 /api, /ai 경로에도 적용해 각 서비스가 자체 루트 기준 경로만 처리하도록 통일했습니다. 배운점: 리버스 프록시 경로 설계 시 업스트림 서비스가 기대하는 경로를 먼저 파악하고 접두사 strip 여부를 명시적으로 결정해야 한다는 것을 배웠습니다.

블록체인 트랜잭션 처리 지연 및 장애 대응 문제: 기부 건수가 많아질수록 개별 확정 호출이 N번 직렬 실행되어 처리 시간이 선형 증가했고, 실패 시 DB와 온체인 상태 불일치 위험이 있었습니다. 해결: confirmRegionDonationBatch API로 N개 기부 ID를 한 트랜잭션에 묶어 트랜잭션 발생 횟수를 최소화했습니다. Web3j의 PollingTransactionReceiptProcessor로 마이닝 완료를 보장하고, Spring Batch의 faultTolerant 설정으로 최대 3회 재시도 및 스킵 로그를 구성했습니다. 배운점: 블록체인은 단건 요청도 수백 ms~수 초가 소요되는 외부 시스템입니다. 처음부터 호출 횟수를 최소화하는 배치 설계과 재시도·폴링 전략을 함께 고려해야 안정적인 운영이 가능하다는 것을 실감했습니다.

🧩 프로젝트 개요

AI 판사 기반 몰입형 SF 서바이벌 마피아 게임 프로젝트입니다.

⚙️ 핵심 로직

WebRTC를 활용한 화상 채팅과, WebSocket 기반의 이벤트 처리, 게임 룸 매니저, 상태 동기화와 기존 마피아 게임에 AI 판사 시스템을 이용한 판결이 핵심입니다.

👨‍💻 주요 기여도

Backend

1. 백엔드 아키텍처 가이드 및 코드 리뷰 리딩
2. Livekit 기반 WebRTC 권한 제어 구현
3. WebSocket 기반 실시간 게임 엔진 설계/구현

DevOps

1. Docker Compose 기반 개발·운영 인프라 구성
2. GitLab + Jenkins CI/CD 구축 및 배포 자동화
3. 서버 네트워크 / 도메인 / TLS 인증 구성

🧯 트러블 슈팅

Livekit 권한 제어 과정에서의 버전 호환 이슈 해결 문제: Livekit v3 기반 권한 제어 구현 과정에서, AI가 생성한 예제 코드가 최신 서버와 호환되지 않아 메서드 호출 및 권한 적용이 정상 동작하지 않았습니다. 해결: 공식 문서를 기반으로 권한 관련 메서드와 토큰 발급 방식을 재검증하고, 최신 버전에 맞게 권한 제어 로직을 수정하여 화상/음성 권한을 정상적으로 제어했습니다. 배운점: AI 생성 코드는 참고용일 뿐이며, 실제 적용 전에는 공식 문서 기반 검증과 버전 호환 확인이 필수라고 느꼈습니다.

Jenkins 기반 CI/CD 구축 중 배포 실패 원인 찾기 문제: Jenkins 파이프라인을 통해 빌드 흐름을 구성했지만, 서버 배포 단계에서의 문제로 인해 배포가 정상 수행되지 않았습니다. 해결: Jenkins 로그를 분석해 권한 미설정 이슈를 확인했고, 필요한 실행/접근 권한을 부여하여 Git → Docker → Jenkins → Server 흐름을 안정화했습니다. 배운점: 툴을 단순히 “사용”하는 수준이 아니라, 장애 상황에서 로그 기반으로 원인을 추적하고 복구할 수 있는 운영 관점이 중요하다고 생각하게 되었습니다.

REST 기반 설계의 실시간성 한계로 WebSocket 전환 문제: 초기에는 REST로 게임을 구현하려 했으나, 특정 역할(예: 낮 시간 임의로 스킬 사용)의 특성상 실시간성 부족 문제가 발생했습니다. 해결: 서버 타이머 기반 진행 구조로 전환하고 WebSocket을 도입해 실시간 이벤트를 처리하도록 개선했습니다. 또한 Pub/Sub 패턴으로 프론트-백 메시지 규격을 정리해 통신 복잡도를 낮췄습니다. 배운점: 실시간 게임은 요청 기반이 아니라 상태 기반/이벤트 기반으로 설계해야 안정적이라는 점을 체감했습니다.

팀원 이탈로 인한 레거시 코드 정리 및 리팩토링 문제: 팀원 2명이 중도 이탈하며 코드 정리가 되지 않은 채 MR/커밋이 남았고, 최신 코드와 괴리로 충돌이 발생했습니다. 해결: 기존 코드를 리팩토링하여 구조를 정리하고, 이후에는 팀원이 코드 최신화를 유지할 수 있도록 브랜치/협업 가이드라인을 제시해야겠다고 정리했습니다. 배운점: 협업 프로젝트에서는 기술 구현 과정에서 코드 최신화 규칙과 협업 프로세스 설계가 서비스의 품질을 좌우한다고 생각하게 되었습니다.

🧩 프로젝트 개요

Newstagram은 사용자의 활동 로그를 분석하여 RSS 뉴스 피드를 선별 제공하고, 개인화된 기사를 추천하는 지능형 뉴스 서비스입니다.

⚙️ 핵심 로직

RSS 뉴스 수집·정제, 핫 이슈 뉴스 피드, 개인 맞춤 뉴스 피드, 사용자 문장을 통한 나만의 뉴스 피드 제공이 핵심입니다.

👨‍💻 주요 기여도

Backend

1. 사용자 문장 기반 백터 기사 검색 파이프라인 구축

DevOps

1. Docker 기반 개발 환경 통합 및 초기 가이드 수립
2. GitHub Actions 기반 CI/CD 구축
3. AWS 기반 MSA 환경 구축 및 모니터링 체계 설계

🧯 트러블 슈팅

운영 환경 로그 메트릭 수집 문제 해결 문제: 배포 이후 서버 상태 및 로그 흐름을 실시간으로 파악하기 어려웠습니다. 해결: CloudWatch Agent를 EC2에 설치하고 로그 및 메트릭 수집 설정을 구성해, 관리자용 대시보드를 구축했습니다. 배운점: 배포는 끝이 아니라 시작이며, 운영 환경에서는 모니터링 및 로그 확보가 필수라고 느꼈습니다.

MSA 환경에서 도메인 모델 공유 문제 해결 문제: MSA로 서버를 분리하면서, 서로 다른 서비스 간 동일한 도메인 모델을 사용해야 하는 상황이 발생했습니다. 해결: 공통 도메인 모델을 라이브러리 형태로 분리하여 각 서비스가 동일한 모델을 참조하도록 구조를 개선했습니다. 배운점: MSA는 단순히 서버를 나누는 것이 아니라, 의존성과 책임을 명확히 분리하는 설계 작업이라는 것을 체감했습니다.

사용자 검색 프롬프트 기반 기사 검색 성능 최적화 문제: 초기에는 한국어 형태소 분석기(Komoran)를 도입했지만, 단어 분석은 가능해도 사용자 의도까지 파악하지 못했습니다, GPT 모델 적용 시 응답 시간이 길어지는 문제가 발생했습니다. 해결: 단순 형태소 분석 대신 GPT 기반 의미 분석으로 전환, 프롬프트 길이와 출력 토큰 수를 조정하여 응답 시간 최적화, 성능과 비용을 고려해 GPT-4o mini 모델을 채택 배운점: AI 모델 선택은 정확도뿐 아니라 응답 속도와 비용을 함께 고려한 균형 설계가 중요하다고 느꼈습니다.

클라우드 비용 과다 청구 (Kafka 설정 오류) 문제: Confluent Cloud Kafka 설정을 잘못 구성하여 예상치 못한 약 300달러 비용이 발생했습니다. 해결: 사용하지 않는 리소스 즉시 정리, 공식 이메일 및 고객센터를 통해 환불 절차 진행 배운점: 클라우드 환경에서는 기능 구현보다 리소스 설정과 과금 구조 이해가 더 중요할 수 있다는 것을 체감했습니다. 이후 비용 모니터링의 중요성을 인지하고 관리 체계를 점검하게 되었습니다.

🧩 프로젝트 개요

Lime (Live In Media Encoder) 다양한 동영상 업로드 및 라이브 스트리밍 서비스를 제공하는 웹 기반 미디어 플랫폼

⚙️ 핵심 로직

HLS 기반 VOD 스트리밍과 WebRTC 기반 실시간 방송 기능을 모두 구현한 하이브리드 미디어 플랫폼

👨‍💻 주요 기여도

Backend

1. Azure 기반 인프라 설계 및 클라우드 환경 구축
2. WebSocket 기반 실시간 채팅 시스템 구현
3. JWT 기반 사용자 인증 및 REST API 개발

PM

1. 프로젝트 리딩 및 일정 관리

🧯 트러블 슈팅

팀 프로젝트 리딩 과정에서의 일정/역할 불명확 문제 개선 문제: 낯선 팀원들과 협업하며 일정과 역할 분배가 명확하지 않아 초기 개발 속도가 지연되었습니다. 해결: 주간 회의 및 이슈 공유 체계 도입, 기술 격차가 있는 팀원을 위한 스터디 세션 진행 배운점: 좋은 프로젝트는 기술보다 구조화된 일정 관리와 명확한 역할 정의에서 시작된다고 느꼈습니다.

실시간 채팅(WebSocket) 구현 방식 결정 문제: 실시간 채팅 기능 구현 시 REST, Polling, WebSocket 중 어떤 방식을 선택해야 할지 판단이 필요했습니다. 또한 테스트 환경 구축에도 어려움이 있었습니다. 해결: WebSocket 기반 구조로 설계해 저지연 실시간 통신 구현 배운점: 실시간 서비스는 단순 API 설계가 아니라, 통신 구조에 대한 이해가 핵심이라는 것을 체감했습니다.

Azure 기반 인프라 학습 및 구축 문제: Azure, VM, Blob Storage, DB 등 클라우드 환경에 대한 경험이 부족했습니다. 해결: 공식 문서 및 강의를 병행 학습, 네트워크 및 클라우드 구조 이해 후 서비스 배포 성공 배운점: 클라우드는 단순 배포 환경이 아니라, 네트워크·보안·스토리지 이해가 함께 요구되는 종합 기술 영역임을 깨달았습니다.