
미리보기
- 직업
- Back-End Engineer
- 이름
- 김도경
- 간단소개
- Kotlin / Java, Spring Boot를 이용한 백엔드 애플리케이션을 개발합니다. - Java / 모놀리스 서비스를 Kotlin / MSA 환경으로 마이그레이션하고 Kafka를 사용해 기능 구현한 경험이 있습니다 - OpenAPI / Spring RestDocs/ Swagger-UI를 사용해 테스트 코드 작성 후 API 문서화가 자동으로 되도록 구현한 경험이 있습니다 - 서비스를 운영하며 사용자들의 요구사항을 수집해 분석한 후 기능을 개선한 경험이 있습니다.
프로젝트
- 프로젝트명
- Entry
- 소속/기관명
- 대덕SW마이스터고등학교
- 프로젝트 기간
- 2023.10. - 2024.10.
- (1년 1개월)
- 프로젝트 설명
상황: 기존의 Entry의 코드 베이스가 계속된 레거시 코드를 생성해 유지 보수성이 저하가 되었음.
해결 방안: 모놀리스 시스템을 그대로 유지하며 개선하는 방안과 MSA로 마이그레이션하여 더 나은 구조로 만드는 방안이 있었다.
선택한 이유: MSA를 직접 학습하고 경험해보고 싶었다.
결과: 학교에서 경험하기 힘든 MSA로 마이그레이션을 해 특별한 경험을 쌓았고 서비스가 안정적으로 운영이 됐다.
마이그레이션 중 발생한 이슈 해결
분산 트랜잭션 해결
상황: 서비스가 서로 다른 데이터베이스와 통신하다 보니 트랜잭션이 일관되게 유지되지 않는 이슈가 발생했다.
해결 방안: SAGA 패턴 도입과 재시도 패턴과 롤백 로직 작성을 하는 방법이 있었다.
선택 이유: SAGA 패턴을 도입하면 기존에 작성한 로직을 변경해야 하다 보니 시간이 부족했다.
결과: 트랜잭션 실패 시 자동 재시도가 이루어지도록 하고 실패하더라도 롤백 로직이 실행되도록 해 데이터 일관성을 확보했고, 사용자는 트랜잭션 중단 없이 안정적인 서비스를 제공받을 수 있게 됐다.
팀원과 의견 충돌
상황: 분산 트랜잭션 해결할 때 어떤 방법으로 구현할지에 대한 의견 충돌
의견: 내 의견은 SAGA패턴을 도입하자 라는 의견이었고 팀원의 의견은 재시도 패턴과 롤백 로직을 같이 작성하자라는 의견이었다
선택 이유: 재시도 패턴과 롤백 로직을 선택해 구현한다면 복잡한 비즈니스 로직이 여러 서비스 간의 연관된 데이터를 변경하는 경우 롤백 로직을 작성하는 것이 어려울 수 있다는 단점이 있었다. 하지만 SAGA 패턴을 적용하려면 Kafka와 관련된 코드를 다시 작성해야 해 개발 일정이 지연될 가능성이 높다고 판단해 재시도 패턴과 롤백 로직을 선택했다.
결과: 개발 일정내에 개발을 할 수 있었고 팀원과 소통을 통해 더 나은 의사결정을 할 수 있었던 기회가 되었다.
상황: MSA 환경에서 API 호출 시, 서로 다른 도메인에 직접 접근할 수 없어 이벤트를 통해 데이터를 변경하거나 다른 서비스에 영향을 미치는 API라면 다른 서비스가 장애로 중단되더라도 데이터 손실이 없도록 개발을 해야 했다.
해결 방안: Redis Pub/Sub, RabbitMQ, Kafka 3가지 솔루션 중 한 개를 도입하는 방안이 있었다.
선택 이유: Redis Pub/Sub과 RabbitMQ는 데이터를 메모리에 저장하므로, 서버 장애 시 데이터 손실 위험이 있다. 데이터 손실을 방지하는 것이 중요하기 때문에, 데이터를 디스크에 안전하게 저장하는 Kafka를 선택했다.
결과: 데이터 손실 없이 안정적인 이벤트 처리가 가능해졌다.
제한된 인프라에서는 Kafka보다 경량인 RabbitMQ나 Redis Pub/Sub으로 대체하여 구현할 수 있다.
상황: MSA환경에서 API 테스트를 하려면 API와 관련된 애플리케이션을 다 빌드 시켜야 하는 불편함과 API 개발하면 API 문서를 직접 작성해야한다는 불편함이 있었다.
해결 방안: Spring RestDocs/ Swagger-UI를 사용해 테스트 코드 작성 후 API 문서화가 자동으로 작성되도록 하는 방안과 테스트코드 작성과 Swagger을 따로 사용하는 방안이 있었다.
선택 이유: Spring RestDocs를 사용해 API 테스트와 문서화를 한 서비스로 통합함으로 API 문서의 일관성과 정확성을 높였다. 이로 인해 수동 문서화에 비해 효율적이며, 문서가 코드 변경에 따라 자동으로 업데이트되어 유지보수에 장점을 제공했다.
결과: 문서화 과정에서 누락되기 쉬운 부분이 보완되었고, API 문서가 일관성 있게 유지되었다.
또한, 테스트 코드를 작성함으로 다른 애플리케이션을 실행하지 않고도 API를 테스트할 수 있어 개발 효율이 향상되었다.
개발자들은 문서화 작업에 소요되는 시간을 줄일 수 있었다.서비스 장애 확산 방지를 위해 서킷을 사용하고 Fallback 작성
상황: 서비스에 장애가 발생하면 다른 서비스까지 장애가 확산이 되어 서비스가 불안정해지는 이슈가 발생했다.
선택 이유: Hystrix를 알아보던 중, 2018년 이후로 개발이 중단되고 유지보수 상태로 전환되었다 라는 글을 확인했다. 그래서 장기적인 유지보수와 안정성을 고려하여, 더 최신 라이브러리인 Resilience4j를 선택하는 것이 적합하다고 판단했다.
결과: Resilience4j를 통해 서킷을 설정한 결과, 장애가 다른 서비스로 확산되는 것을 막을 수 있었고, 서비스 장애 발생 시 Fallback 메서드가 실행되도록 하여 시스템의 안정성을 높였다.
CodeRabbit을 도입하여 팀원들이 발견하지 못한 문제점을 찾아내고 코드 품질을 향상.
대덕소프트웨어마이스터고등학교 입학전형 서비스 (Entry)는 성적 산출, 원서 접수, PDF 원서 출력, 지원자 목록 조회 등 다양한 기능을 제공하여 원서 접수 과정의 불편함을 해결하는 서비스입니다.
현재 121명 사용자를 보유하고 있습니다.
웹: Entry 웹사이트
백엔드 개발
기존 Java 모놀리스 시스템을 Kotlin 및 MSA로 마이그레이션
Kafka를 활용한 서비스 간 이벤트 발생 및 처리 기능 구현
API 문서화 자동구현
서비스 이슈 해결
CodeRabbit 도입
- 프로젝트명
- PiCK
- 소속/기관명
- 대덕SW마이스터고등학교
- 프로젝트 기간
- 2024.02. - 2024.05.
- (4개월)
- 프로젝트 설명
요구사항: 외출 등 승인 상태가 메인 페이지에 즉시 반영되지 않아 불편해요
해결 방안: 폴링 방식을 사용하여 주기적으로 상태를 확인하거나, WebSocket을 도입해 실시간 상태 업데이트를 구현하는 두 가지 방안이 있었다.
선택 이유: 폴링 방식은 서버에 불필요한 부하를 줄 수 있어 실시간성을 보장하는 WebSocket을 선택했다.
결과: 승인 상태가 실시간으로 메인 페이지에 반영되어 사용자 경험이 향상되었다.
요구사항: 외출 승인/거절, 공지사항 등록되었을 때 알림이 전달되지 않아 빠르게 정보를 확인하기 불편해요
해결 방안: 자체 알림 시스템을 구축하거나 FCM을 도입하는 두 가지 방안이 있었다.
선택 이유: FCM은 여러 기기에서 푸시 알림을 효율적으로 관리할 수 있고, 자체 알림 시스템을 구축하는 것보다 빠른 시간 내에 도입할 수 있다.
결과: FCM을 사용하여 사용자별로 알림 주제를 선택할 수 있는 기능을 제공했고, 알림이 실시간으로 전송되어 사용자의 편의성을 개선했다.
요구사항: 버그가 발생할 경우, 사용자가 개발자에게 직접 알려줘야 해서 너무 불편해요
해결 방안: 이메일을 통한 제보 시스템과 Webhook을 사용한 실시간 제보 알림 두 가지 방안이 있었다.
선택 이유: Webhook을 사용하면 디스코드 팀 서버로 알림이 오기 때문에 모든 팀원들이 바로 확인할 수 있다는 장점이 있다.
결과: Webhook을 사용하여 실시간 버그 제보 기능을 구현한 덕분에, 사용자는 더 이상 개발자에게 직접 버그를 알릴 필요가 없어졌고, 개발자들도 실시간으로 문제를 확인할 수 있어 효율이 크게 향상되었다.
상황: 서비스를 오픈했지만 초반에 사용자들의 요구사항이 너무 많았다.
해결 방안: 설문을 돌려 요구사항을 수집후 분석을 해 우선순위를 만들어 반영하자 또는 실시간으로 급해보이는 것들을 바로 반영하자 라는 의견이 있었다
선택 이유: 요구사항을 분석해 팀원들과 우선순위를 명확히 파악함으로써 실시간 반영에 따른 위험을 줄이고, 서비스의 안정성을 확보할 수 있을 것이라 판단했다.
결과: 중복되는 요구사항과 핵심적인 요청 사항을 식별해 우선순위를 설정할 수 있었으며, 이를 통해 사용자 만족도를 높이면서도 서비스 안정성을 유지할 수 있었다.
대덕소프트웨어마이스터고등학교를 위한 출결 관리 서비스 (PiCK)는 외출 신청, 외출 수락/거절, 반별 출결 관리 조회 등 다양한 기능을 제공하여 학교생활의 불편함을 해결합니다.
현재 150명 사용자를 보유하고 있습니다.
웹: PiCK 웹사이트
iOS: App Store 링크
Android: Play Store 링크
백엔드 개발
앱 메인페이지 실시간 조회 기능 구현
공지사항 등록 등 알림전송 기능 구현
버그제보시 디스코드 서버로 내용이 전송되도록 구현
요구사항 수집 후 분석
리팩토링을 주도하며 코드 개선 작업 진행 중
기술 스택
- 기술 스택
- Java
- Kotlin
- Spring Boot
- spring-jpa
- MySQL
- Redis
- AWS
- Python
- Django
포트폴리오
- 타입
- URL
교육
- 소속/기관
- 대덕소프트웨어마이스터고등학교
- 종류 | 전공명/전공계열
- 고등학교 | 인공지능개발과
- 재학 기간 (재학 상태)
- 2023.03. - 재학 중