채용공고 올리기

김도경님을 응원해보세요!

이직/구직 중이에요
성실함
책임감
학습 지향

미리보기

직업
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)는 성적 산출, 원서 접수, PDF 원서 출력, 지원자 목록 조회 등 다양한 기능을 제공하여 원서 접수 과정의 불편함을 해결하는 서비스입니다.

현재 121명 사용자를 보유하고 있습니다.

웹: Entry 웹사이트

백엔드 개발

기존 Java 모놀리스 시스템을 Kotlin 및 MSA로 마이그레이션
  • 상황: 기존의 Entry의 코드 베이스가 계속된 레거시 코드를 생성해 유지 보수성이 저하가 되었음.

  • 해결 방안: 모놀리스 시스템을 그대로 유지하며 개선하는 방안과 MSA로 마이그레이션하여 더 나은 구조로 만드는 방안이 있었다.

  • 선택한 이유: MSA를 직접 학습하고 경험해보고 싶었다.

  • 결과: 학교에서 경험하기 힘든 MSA로 마이그레이션을 해 특별한 경험을 쌓았고 서비스가 안정적으로 운영이 됐다.

  • 마이그레이션 중 발생한 이슈 해결

    • 분산 트랜잭션 해결

      1. 상황: 서비스가 서로 다른 데이터베이스와 통신하다 보니 트랜잭션이 일관되게 유지되지 않는 이슈가 발생했다.

      2. 해결 방안: SAGA 패턴 도입과 재시도 패턴과 롤백 로직 작성을 하는 방법이 있었다.

      3. 선택 이유: SAGA 패턴을 도입하면 기존에 작성한 로직을 변경해야 하다 보니 시간이 부족했다.

      4. 결과: 트랜잭션 실패 시 자동 재시도가 이루어지도록 하고 실패하더라도 롤백 로직이 실행되도록 해 데이터 일관성을 확보했고, 사용자는 트랜잭션 중단 없이 안정적인 서비스를 제공받을 수 있게 됐다.

    • 팀원과 의견 충돌

      1. 상황: 분산 트랜잭션 해결할 때 어떤 방법으로 구현할지에 대한 의견 충돌

      2. 의견: 내 의견은 SAGA패턴을 도입하자 라는 의견이었고 팀원의 의견은 재시도 패턴과 롤백 로직을 같이 작성하자라는 의견이었다

      3. 선택 이유: 재시도 패턴과 롤백 로직을 선택해 구현한다면 복잡한 비즈니스 로직이 여러 서비스 간의 연관된 데이터를 변경하는 경우 롤백 로직을 작성하는 것이 어려울 수 있다는 단점이 있었다. 하지만 SAGA 패턴을 적용하려면 Kafka와 관련된 코드를 다시 작성해야 해 개발 일정이 지연될 가능성이 높다고 판단해 재시도 패턴과 롤백 로직을 선택했다.

      4. 결과: 개발 일정내에 개발을 할 수 있었고 팀원과 소통을 통해 더 나은 의사결정을 할 수 있었던 기회가 되었다.

Kafka를 활용한 서비스 간 이벤트 발생 및 처리 기능 구현
  • 상황: MSA 환경에서 API 호출 시, 서로 다른 도메인에 직접 접근할 수 없어 이벤트를 통해 데이터를 변경하거나 다른 서비스에 영향을 미치는 API라면 다른 서비스가 장애로 중단되더라도 데이터 손실이 없도록 개발을 해야 했다.

  • 해결 방안: Redis Pub/Sub, RabbitMQ, Kafka 3가지 솔루션 중 한 개를 도입하는 방안이 있었다.

  • 선택 이유: Redis Pub/Sub과 RabbitMQ는 데이터를 메모리에 저장하므로, 서버 장애 시 데이터 손실 위험이 있다. 데이터 손실을 방지하는 것이 중요하기 때문에, 데이터를 디스크에 안전하게 저장하는 Kafka를 선택했다.

  • 결과: 데이터 손실 없이 안정적인 이벤트 처리가 가능해졌다.

  • 제한된 인프라에서는 Kafka보다 경량인 RabbitMQ나 Redis Pub/Sub으로 대체하여 구현할 수 있다.

API 문서화 자동구현
  • 상황: MSA환경에서 API 테스트를 하려면 API와 관련된 애플리케이션을 다 빌드 시켜야 하는 불편함과 API 개발하면 API 문서를 직접 작성해야한다는 불편함이 있었다.

  • 해결 방안: Spring RestDocs/ Swagger-UI를 사용해 테스트 코드 작성 후 API 문서화가 자동으로 작성되도록 하는 방안과 테스트코드 작성과 Swagger을 따로 사용하는 방안이 있었다.

  • 선택 이유: Spring RestDocs를 사용해 API 테스트와 문서화를 한 서비스로 통합함으로 API 문서의 일관성과 정확성을 높였다. 이로 인해 수동 문서화에 비해 효율적이며, 문서가 코드 변경에 따라 자동으로 업데이트되어 유지보수에 장점을 제공했다.

  • 결과: 문서화 과정에서 누락되기 쉬운 부분이 보완되었고, API 문서가 일관성 있게 유지되었다.
    또한, 테스트 코드를 작성함으로 다른 애플리케이션을 실행하지 않고도 API를 테스트할 수 있어 개발 효율이 향상되었다.
    개발자들은 문서화 작업에 소요되는 시간을 줄일 수 있었다.

서비스 이슈 해결

  1. 서비스 장애 확산 방지를 위해 서킷을 사용하고 Fallback 작성

    1. 상황: 서비스에 장애가 발생하면 다른 서비스까지 장애가 확산이 되어 서비스가 불안정해지는 이슈가 발생했다.

    2. 선택 이유: Hystrix를 알아보던 중, 2018년 이후로 개발이 중단되고 유지보수 상태로 전환되었다 라는 글을 확인했다. 그래서 장기적인 유지보수와 안정성을 고려하여, 더 최신 라이브러리인 Resilience4j를 선택하는 것이 적합하다고 판단했다.

    3. 결과: Resilience4j를 통해 서킷을 설정한 결과, 장애가 다른 서비스로 확산되는 것을 막을 수 있었고, 서비스 장애 발생 시 Fallback 메서드가 실행되도록 하여 시스템의 안정성을 높였다.

CodeRabbit 도입

  • CodeRabbit을 도입하여 팀원들이 발견하지 못한 문제점을 찾아내고 코드 품질을 향상.

프로젝트명
PiCK
소속/기관명
대덕SW마이스터고등학교
프로젝트 기간
2024.02. - 2024.05.
(4개월)
프로젝트 설명

대덕소프트웨어마이스터고등학교를 위한 출결 관리 서비스 (PiCK)는 외출 신청, 외출 수락/거절, 반별 출결 관리 조회 등 다양한 기능을 제공하여 학교생활의 불편함을 해결합니다.

현재 150명 사용자를 보유하고 있습니다.

웹: PiCK 웹사이트

iOS: App Store 링크

Android: Play Store 링크

백엔드 개발

앱 메인페이지 실시간 조회 기능 구현
  • 요구사항: 외출 등 승인 상태가 메인 페이지에 즉시 반영되지 않아 불편해요

  • 해결 방안: 폴링 방식을 사용하여 주기적으로 상태를 확인하거나, WebSocket을 도입해 실시간 상태 업데이트를 구현하는 두 가지 방안이 있었다.

  • 선택 이유: 폴링 방식은 서버에 불필요한 부하를 줄 수 있어 실시간성을 보장하는 WebSocket을 선택했다.

  • 결과: 승인 상태가 실시간으로 메인 페이지에 반영되어 사용자 경험이 향상되었다.

공지사항 등록 등 알림전송 기능 구현
  • 요구사항: 외출 승인/거절, 공지사항 등록되었을 때 알림이 전달되지 않아 빠르게 정보를 확인하기 불편해요

  • 해결 방안: 자체 알림 시스템을 구축하거나 FCM을 도입하는 두 가지 방안이 있었다.

  • 선택 이유: FCM은 여러 기기에서 푸시 알림을 효율적으로 관리할 수 있고, 자체 알림 시스템을 구축하는 것보다 빠른 시간 내에 도입할 수 있다.

  • 결과: FCM을 사용하여 사용자별로 알림 주제를 선택할 수 있는 기능을 제공했고, 알림이 실시간으로 전송되어 사용자의 편의성을 개선했다.

버그제보시 디스코드 서버로 내용이 전송되도록 구현
  • 요구사항: 버그가 발생할 경우, 사용자가 개발자에게 직접 알려줘야 해서 너무 불편해요

  • 해결 방안: 이메일을 통한 제보 시스템과 Webhook을 사용한 실시간 제보 알림 두 가지 방안이 있었다.

  • 선택 이유: Webhook을 사용하면 디스코드 팀 서버로 알림이 오기 때문에 모든 팀원들이 바로 확인할 수 있다는 장점이 있다.

  • 결과: Webhook을 사용하여 실시간 버그 제보 기능을 구현한 덕분에, 사용자는 더 이상 개발자에게 직접 버그를 알릴 필요가 없어졌고, 개발자들도 실시간으로 문제를 확인할 수 있어 효율이 크게 향상되었다.

요구사항 수집 후 분석
  • 상황: 서비스를 오픈했지만 초반에 사용자들의 요구사항이 너무 많았다.

  • 해결 방안: 설문을 돌려 요구사항을 수집후 분석을 해 우선순위를 만들어 반영하자 또는 실시간으로 급해보이는 것들을 바로 반영하자 라는 의견이 있었다

  • 선택 이유: 요구사항을 분석해 팀원들과 우선순위를 명확히 파악함으로써 실시간 반영에 따른 위험을 줄이고, 서비스의 안정성을 확보할 수 있을 것이라 판단했다.

  • 결과: 중복되는 요구사항과 핵심적인 요청 사항을 식별해 우선순위를 설정할 수 있었으며, 이를 통해 사용자 만족도를 높이면서도 서비스 안정성을 유지할 수 있었다.

리팩토링을 주도하며 코드 개선 작업 진행 중

기술 스택

기술 스택
Java
Kotlin
Spring Boot
spring-jpa
MySQL
Redis
AWS
Python
Django

포트폴리오

타입
URL

교육

소속/기관
대덕소프트웨어마이스터고등학교
종류 | 전공명/전공계열
고등학교 | 인공지능개발과
재학 기간 (재학 상태)
2023.03. - 재학 중
댓글