미리보기
기본 정보

낭만을 즐기는 개발자 이상원입니다.
자기소개
끊임없이 파고드는 사람
개발을 하다 보면 눈치 채지 못한 사이에 갑자기 새로운 경험을 마주하고는 합니다.
단순하게 직접 구글링을 하거나 AI한테 물어봐서 어느 정도는 해결할 수 있을 것입니다.
하지만 그것은 오로지 제 능력이라고 하긴 어렵습니다.
그래서 저의 능력 자체를 키우기 위해 "왜 이렇게 썼을까?", "어떻게 동작하는 걸까?"처럼
스스로에게 끊임 없이 질문합니다.
이를 통해 제가 얻게된 지식을 온전히 제 것으로 만들어 노력합니다.
배움에는 끝이 없다.
기술은 쉼없이 발전하고 있습니다.
기존 기술이 발전하기도 하고 필요에 의해 새로운 기술이 생기기도 합니다.
물론 배운다는 것이 마냥 쉬운 과정은 아닐 것입니다.
그래도 포기하지 않고 느리더라도 끊임없이 배우면 스스로의 전문성을 키우고, 획득한 다양한 기술 스택을 통해 더욱 다양한 문제를 해결할 수 있는 능력을 얻게 될 것입니다.
그래서 저는 조급해 하지 않고 스스로를 믿고 늘 배우며 살고 있습니다.
기술 스택
경력
크림하우스(주)
팀원 • 개발 3팀
HR 프로그램 개발
회의실 예약 기능 개발
Slack 및 Firebase API 연동을 통한 회의실 예약 알림 기능 개발
프로젝트 관리 기능 개발
모바일 보건소 시스템 기능 개발
대상자 정보 관리 서비스 기능 개선
중복 소스코드 모듈화를 통한 속도 개선 및 유지보수 간편화
축구팀 정보 관리 서비스 개발
비즈니스 업무 규칙 정의
중복 소스코드 모듈화를 통한 속도 개선 및 유지보수 간편화
정기적으로 K리그 공식 협회와 경기 기록을 동기화하는 기능 개발
개발자 커뮤니티 서비스 개발
정규화, 쿼리 튜닝, 데이터 조회 코드 모듈화 등을 통한 데이터 조회 속도 개선
이벤트 참여 관리 서비스 개발
(3년 7개월 | 정규직)
주식회사퀀텀에듀솔루션
팀원 • 개발팀
LMS 관리자 페이지 유지보수 담당
쿼리 개선을 통한 데이터 조회 속도 개선
자바/자바스크립트 리팩토링을 통한 애플리케이션 성능 향상
(4개월 | 정규직)
프로젝트
크림하우스(주)
크림웨어 (CreamWare)
[소개]
사내 RnD에서 시작된 사내 전용 HR 프로그램
[주 기술 스택]
Java, Spring Boot, JPA, QueryDSL, MariaDB
[기여한 부분]
1. 회의실 예약 기능 개발
조건에 맞는 예약 정보를 조회하는 쿼리를 실행하되,
하나의 쿼리를 @Lock 어노테이션의 PESSIMISTIC_WRITE 모드를 적용한 메소드와
적용하지 않은 메소드에서 모두 호출하여
사용자가 예약을 시도하는 도중 다른 사용자가 도중에 예약하였을 때 중복 데이터를 저장되는 상황을 방지예약 시작시간, 예약 종료시간, 회의실 ID의 3가지 컬럼에 대하여 유니크 키를 생성하여
만약에 너무 근소한 차이로 인해 중복 데이터 저장 시 예외를 발생시키도록 유도
2. 회의실 지각 및 노쇼 방지를 위한 회의 참석 여부 및 알람 메시지 전송 기능 개발
슬랙 API 연동
Firebase의 FCM API 연동
크림하우스(주)
모바일 보건소시스템 개선
[소개]
- 지역보건의료정보시스템 내부의 현장 지원 서비스 (모바일 전용)
[주 기술 스택]
- Java, Spring Framework, MyBatis, Oracle
[기여한 부분]
1. 대상자 정보 관리 서비스 기능 개선
실행 계획 확인을 통해 사용되지 않는 인덱스를 제거하고 신규 인덱스를 추가하여 대상자 목록 조회 API의 실행 속도를 개선함
개선 결과 : 3.5s → 263ms
2. 중복 소스코드 모듈화를 통한 속도 개선 및 유지보수 간편화
도메인 별로 공통되는 로직을 별도의 유틸리티로 분리하여 중복 코드를 제거함
현재 사용되지 않으며 서비스 개편을 통해 사용되지 않는 로직들을 제거함
크림하우스(주)
제주유나이티드FC 홈페이지/앱
[소개]
축구 팀 제주 유나이티드 FC의 홈페이지 및 앱
[주 기술 스택]
Java, Spring Boot, MyBatis, MySQL, Thymeleaf, JavaScript, Jquery
[기여한 부분]
1. 개발자가 공통적으로 사용하는 업무 규칙 정의
Enum을 통해 고정된 파라미터 값을 사용하는 방식
오타나 개발자 성향 차이로 인해서 같은 데이터를 처리하는 데 결과가 다른 현상 발생
도중에 properties 파일로 관리하려고 하였으나 실제로 빌드하기 전까지는 오류를 확인하기 어려운 케이스가 있어서 Enum 방식을 유지함
컨트롤러나 서비스 등에서 사용하는 공통 기능 개발
접근 로그 저장, 세션 관리 등의 이유로 AOP 기능을 관리
배치 서비스 관리 방식 정의
명명 규칙, 내부 로직 실행 순서 등에 대한 방식을 정의함
API가 반환하는 응답의 유형
정상, 쿼리 오류, 불일치 오류, 잘못된 접근 방식 등에 대한 응답 데이터를 정의함
2. 경기 기록 데이터를 주기적으로 갱신하는 스케쥴러 개발
JSOUP 라이브러리를 통해 KLeague에서 제공하는 XML 파일을 파싱하여 경기 기록을 저장하는 스케쥴러 개발
작업이 필요한 HTML 노드를 탐색하여 브라우저가 아닌 HTTP 통신을 통해 로그인을 진행한 뒤 XML을 파일을 다운로드
다운로드한 XML에 대해 파싱을 진행하여 데이터 추출 후 데이터베이스에 저장
3. 복수의 서버 인스턴스에서 스케쥴러를 동시에 호출하는 현상 수정
Shedlock 라이브러리 도입을 통해 스케쥴러 중복 호출 방지
다양한 락 방식이 존재하지만 데이터베이스 자체의 락 방식을 수정하게 되면 서비스 전반에 영향이 발생
synchronized 키워드는 동일한 서버 인스턴스에서만 동작하기 때문에 2대의 서버 인스턴스를 사용하는 해당 프로젝트에서는 사용할 수 없음
@Transactional 애노테이션이 존재하면 트랜잭션이 종료되기 전에 다른 스레드에서 메서드에 접근할 수 있음
배치 로직 앞뒤로 락을 획득하고 반환하는 쿼리를 실행하게 해도 되긴하지만 그렇게 될 경우 오히려 관리할 코드가 늘어남
관리할 코드의 양을 최소화하기 위해 간단한 설정만으로도 락을 구현하는 외부 라이브러리를 도입함
크림하우스(주)
데보션 (DEVOCEAN) 기능 개선
[소개]
개발자들을 위한 기술 블로그 및 커뮤니티 서비스
[주 기술 스택]
Java, Spring Framework, MyBatis, MySQL, Dart, Flutter, Firebase
[기여한 부분]
1. FCM 메시지 발송 서비스 개선
FCM 메시지 발송 데이터 보존 방식 변경
AS-IS : 단일 테이블에 FCM 메시지를 저장 후 발송 여부만 변경
TO-BE : 발송 완료된 데이터는 별도의 로그 용도의 테이블로 복사 후 기존 테이블에서는 삭제
1분에 1번씩 발송하는 스케쥴러를 분리
메시지 데이터는 실시간 발송과 추후 발송 2가지 성격이 존재하기 때문에 성격 기준으로 분리
DM, 이벤트 당첨 등 실시간으로 발송되어야 하는 메시지는 미리 발송 후 로그 테이블에 저장
댓글 등록, 좋아요 등 실시간으로 발송되지 않아도 되는 데이터는 메시지 큐 테이블에 저장 후 추후 발송
개선 결과 : 스케쥴러 실행 시간이 평균적으로 약 60% 이상 감소함 (평균값)
2. 커뮤니티 게시글 조회 API 개선
STRAIGHT_JOIN을 통한 조인 순서 변경
메인이 되는 게시글 테이블보다 보유한 데이터 양이 많은 다른 테이블과 조인하면서 옵티마이저가 효율적인 조인 순서를 정상적으로 정의하지 못 함
STRAIGHT_JOIN을 통해 조인 순서를 직접 정의하면서 반복적인 실행 계획 확인을 통해 효율적인 조인 순서를 찾아서 데이터 조회 속도를 개선함
실행 계획 확인을 통한 신규 인덱스 추가
실행 계획을 확인하여 서비스 개편을 통해 추가된 신규 컬럼이 사용도는 높으나 인덱스가 없는 것을 확인
사용되지 않으나 차지하는 용량이 큰 복합 키 인덱스를 삭제 후 신규 인덱스 추가
관련 파일 목록을 조회하는 로직 개선
AS-IS : 게시글 데이터 N건 조회 시 게시글 갯수만큼 관련 파일 목록을 조회
TO-BE : 게시글 목록 조회 후 PK 값만 취합하여 IN절을 통해 파일 목록을 일괄 조회함
개선 결과 : 6.7s → 350ms (평균 값, 조회한 모든 게시글에 이미지 파일이 존재하는 경우)
포트폴리오
교육
유한대학교
대학교(전문학사) | IT소프트웨어공학과
2016.03. ~ 2021.02.
졸업
자격증
정보처리기사
한국산업인력공단
2024.06.