전체 글
-
논문: Kubernetes 환경 ROS - Web 인터페이스 연동 포트폴리오카테고리 없음 2025. 8. 30. 16:45
개요Docker와 Kubernetes를 활용한 ROS 로봇 환경과 Web 인터페이스 통신 연구ROS Bridge와 WebSocket을 이용한 실시간 로봇 제어 시스템Kubernetes 환경에서 Spring Boot와 ROS 연동 및 Pod/트래픽 관리논문 설명Docker와 Kubernetes를 활용하여 ROS 로봇 환경과 Web 인터페이스 간 실시간 통신 구조를 연구하고, 이를 논문으로 구현하였습니다. Kubernetes 환경에서 ROS와 Spring Boot를 Pod로 운영하며, ROS Bridge 기반WebSocket 통신을 통해 두 환경을 연결했습니다. 사용자는 Web 인터페이스에서 로봇을 실시간으로 제어할 수 있으며, Deployment를 통한 Pod 관리와 Ingress 기반 네트워크 트래픽 제..
-
GoodByeGood 중고나라 프로젝트 포트폴리오카테고리 없음 2025. 8. 30. 16:36
프로젝트 설명중국 하얼빈 대학교의 학생들을 중심으로 한 중고마켓 애플리케이션을 개발하였습니다. 이 프로젝트는 학생들이 손쉽게 중고 물품을 거래할 수 있는 플랫폼을 제공하기 위해 시작되었습니다.Git 주소: https://github.com/jaeseonNamgung/joonggonara-app프로젝트 기간: 2024.03 ~ 2024.07기술 스택Backend: Java 17, Springboot, JPA, MySql, RedisInfra: AWS(EC2, RDS, Parameter Store, S3, SES)서버 아키텍처React Native에서는 기본적으로 보안상의 이유로 Https 통신을 사용하도록 강제하고 있습니다. GoodByeGood 프로젝트는 AWS에서 Certificate Manager(A..
-
실타래 데이팅 앱 프로젝트 포트폴리오카테고리 없음 2025. 8. 30. 16:04
개요실타래로 마음을 잇는 카드·채팅 기반 데이팅 앱랜덤 카드와 가상 재화로 연결되는 스토리형 데이팅 플랫폼실타래로 이어지는 질문-답변 기반 매칭 앱Git 주소: https://github.com/jaeseonNamgung/thred-be프로젝트 기간: 2024.09 ~ 2025.10 출시 예정프로젝트 설명오프라인 소개팅이나 모임이 줄어들고, 기존 데이팅 앱이 단순 매칭 위주로 흘러가는 상황에서, 보다 의미 있는 연결 과정을 제공하고자 Thred를 개발하게 되었습니다.Thred는 매일 랜덤으로 제공되는 카드를 상대방 질문에 답변해야만 오픈할 수 있는 방식으로, 대화를 시작하기 전 자연스러운 교감을 유도합니다.카드 오픈, 프로필 열람, 채팅 연결 등 주요 기능은 가상 재화 실타래를 통해 동작하며, 커뮤니티를..
-
싱글 스레드에서 멀티스레드 성능 최적화: 스레드 풀과 큐의 역할Spring 2025. 8. 29. 13:49
이번 프로젝트에서 결제 승인 처리 기능을 구현하게 되었습니다.승인 처리는 매번 실시간으로 API를 호출하는 방식이 아니라, 스케줄러가 주기적으로 배치로 실행되며 특정 조건을 만족한 카드들을 모아서 승인 처리를 진행합니다.승인 로직은 외부 결제망(예: Cybersource)과 직접 연동되기 때문에 네트워크 지연이나 타임아웃이 빈번하게 발생할 수 있습니다.초기에는 단순히 new Thread(...)를 통해 워커 스레드를 직접 띄워 처리했는데, 이 방식에는 다음과 같은 한계가 있었습니다.매 요청 마다 스레드를 생성 및 종료하는 작업은OS의 Kernel 레벨에서 이루어지기 때문에 성능에 매우 좋지 않음스레드를 만드는 과정은 단순한 객체 생성(new)과 달리, 커널에 진입해 스택 메모리 확보, TCB(Thread..
-
Jenkins 환경에서 Shell Script를 활용한 Spring Boot Health Check, Docker 롤백 자동화 및 Teams 알림 시스템 구현CICD 2025. 8. 28. 11:24
문제 상황개발 중인 서버에서 신규 기능을 배포할 때마다 다음과 같은 과정을 모두 수동으로 진행해야 했습니다.실행 중인 컨테이너 중단 및 삭제이전 버전의 Docker 이미지 삭제Maven 빌드 후 새로운 Docker 이미지 빌드빌드한 이미지를 푸시 후 배포 상태를 직접 확인 (수동 Health Check)이 과정은 단순 반복적인 작업이었지만 시간이 많이 소모되고 개발자가 개입하다 보니 오류 발생 가능성이 높았습니다.특히 배포 성공 여부를 개발자가 직접 로그를 확인해야 했기 때문에 불편함이 높았고, 문제가 발생하면 다시 처음 단계부터 반복해야 했습니다. 결과적으로 배포 과정이 팀 전체 개발 속도를 늦추는 병목 구간이 되었고, 다른 개발자들의 테스트 일정까지 지연시키는 문제가 잦았습니다.해결 방안현재 개발 서..
-
-
캐싱 최적화: Redis를 사용하지 않고 Local Cache로 캐싱하는 방법Spring 2025. 8. 25. 17:29
문제 배경현재 진행 중인 프로젝트는 카드, 파일, 암호화 키, 공급자 정보, 카드 상품 등 다양한 프로파일 데이터를 빈번하게 조회해야 합니다.기존 방식은 DAO를 통해 매번 DB에 접근하는 구조였는데, 이로 인해 다음과 같은 문제가 있었습니다.동일한 데이터라도 매번 DB I/O 발생대량 프로파일 조회 시 DB 부하 증가운영 환경에서 빠른 응답 속도 보장 어려움이를 해결하기 위해 데이터를 미리 캐싱하는 방법을 도입하기로 결정했습니다. 해결 전략1. Local Cache (In-Memory)Spring Service 내부에 Map 또는 CaffeineCacheManager와 같은 In-Memory 캐시를 두고, 애플리케이션 시작 시 필요한 데이터를 메모리에 로드하여 사용하는 방식입니다.장점O(1) 조회 속도..
-
성능 개선: 대량 데이터 Batch Insert 최적화와 MyBatis 캐시 문제 해결Spring 2025. 8. 24. 23:19
이번 프로젝트에서 기존 구현되어 있는 코드 성능을 개선하는 작업을 진행했습니다. 카드 발급은 단건부터 수십만 건까지 대량 데이터를 처리될 수 있습니다. 그러나 기존 방식은 데이터를 한 건씩 DB에 저장하는 구조라 10만 건 발급 시 843초가 걸릴 정도로 성능이 떨어지고, 모든 데이터를 한 번에 메모리에 적재하면 OOM(Out Of Memory) 예외까지 발생할 수 있었습니다. 이를 해결하기 위해 데이터를 1,000건 단위로 분할하여 MyBatis와 JDBC Batch를 활용한 배치 처리 방식을 적용했고, 각 배치 처리 후 캐시를 초기화하여 메모리 안정성을 확보했습니다. 그 결과, 10만 건 처리 시간이 약 843초에서 5초로 단축되며 약 99.4%의 성능 개선 효과를 얻었고, 기존 방식과 비교했을 때..