Contact & Channels
•
성명 | 전대홍
•
생년월일 | 1996.09.12
•
휴대전화 | 010-6275-2889
•
•
•
•
•
병역 사항 | 육군 중위 만기 전역
Self-Introduction
•
안녕하세요! 기초를 중요시 여기며, 꾸준히 성장하는 개발자 전대홍입니다.
•
장교로 군 복무를 하며 팀워크의 중요성과, 함께 발전하는 것의 가치를 직접 경험 하였습니다.
•
커뮤니케이션 능력을 중요시 여기고, 개인의 발전과 함께, 팀 전체의 발전을 위해 노력합니다.
•
단순 구현만을 위한 얕은 접근이 아닌, 완성도 있고 좋은 성능의 애플리케이션 개발을 위한 CS지식과, 기초 지식을 기반으로한 깊은 접근을 하기 위해 노력합니다.
•
대규모 데이터, 대용량 트래픽 환경에서의 애플리케이션 성능 향상을 고민합니다.
Career
(주)디세이코리아
( 2022.04.06 ~ 2023.08.31 )
•
이커머스 플랫폼 서비스 개발
◦
이커머스 플랫폼 서비스를 개발하여 고객에게 제공하는데에 기여함.
◦
AOP 적용, JSTL 도입 등 기존의 레거시한 개발 방식에서 벗어나기 위해 주도적으로 노력하였고, 해당 내용의 교육 담당을 맡으며 팀 전체의 실력 향상을 위해 기여함.
◦
고객과의 원활한 커뮤니케이션을 통해 요구사항을 분석하고, 문제 발생 시 해결 하는데에 기여함.
◦
느린 조회 속도 이슈, 동시성 이슈와 같은 트러블 슈팅에 적극 대응하여 문제를 해결하는데에 기여함.
•
사내 솔루션의 레거시한 코드 유지보수
◦
사내에서 사용하는 솔루션의 기존 코드 일부를 유지 보수하여, 성능 및 코드 가독성 향상에 기여함.
◦
중복되는 코드를 최소화 하였으며, 성능과 가독성에 문제가 생기지 않는 선에서 불필요한 코드를 최대한 제거하도록 노력함.
◦
UI 개선을 위한 소프트웨어 수정에도 기여하였으며, 수정한 부분이나 새로 개발한 부분에 대해서는 문서화를 통해 임직원들에게 공유하므로, 이력을 남겼음.
•
사내 솔루션을 홍보하기 위한 노력
◦
평소 사내 솔루션을 대학원에서 학생 및 타사 직원들에게 소개하고 강의해야 하는 일에 강사 역할로서 기여함.
◦
주 강의를 맡던 직원이 회사 사정으로 강의에 참석할 수 없게 되자, 평소 사내 솔루션에 관심을 갖고 공부하였던 경험을 토대로 강의를 주도함. 이를 통해 회사 솔루션 홍보 활동에 기여함.
◦
사내 솔루션에 필요한 대용량 데이터를 샘플링하여, 솔루션 테스트 및 영업 활동에 기여함.
Major Achievements
1. 이커머스 플랫폼 서비스 개발 ( 회사 프로젝트 )
•
프로젝트 링크
공통 관심사 분리를 통한 가독성, 유지보수성 향상
◦
프로젝트 개발 당시 로그인, Logging 등 Controller 내에서 중복되는 여러 로직들이 존재하였음.
◦
로그인을 체크하는 로직에 수정이 필요하게 되었고, 모든 Controller 에 있는 동일한 로직을 전부 수정해야 하는 일이 발생하였음.
◦
팀 전체가 레거시한 코드 밖에 작성할 줄 몰랐기에, 이렇게 중복되는 로직을 어떻게 분리할 수 있을까 고민하게 되었음.
◦
Spring AOP 를 활용하여 해당 로직을 포함한, 중복되는 인프라 로직들을 분리 할 수 있었고, 이를 통해 코드의 가독성과, 유지보수성이 크게 향상 되었음.
◦
또한 AOP 를 모르는 팀원들에게 AOP 에 대해 설명해주었고, 팀의 능률이 향상될 수 있는 계기가 되었음.
Self-Invocation 문제 해결
◦
Transaction 의 격리 수준이 REQUIRES_NEW 였던 메서드가 있었고, 해당 트랜잭션이 정상적으로 동작하지 않는 문제를 발견하였음.
◦
REQUIRES_NEW 에 대하여 알아보다보니, 논리적 트랜잭션과 물리적 트랜잭션에 대하여 알 수 있었고, 더 나아가 프록시 객체와 Self-invocation 문제에 대하여 알게 되었음. ( 그리고 현재의 문제가 Self-invocation 문제임을 알게 되었음. )
◦
같은 Service 내에서 불러오던 메서드를 별도의 Service 를 만들어 분리하였고, 트랜잭션이 정상적으로 동작할 수 있게 되어 문제를 해결하였음.
레거시한 개발 방식을 벗어나기 위한 노력
◦
스스로의 발전을 위해 공부하다 보니 팀의 개발 방식과 코드가 상당히 레거시 하다는 것을 알게 되었고, 팀을 위해서도 개발하고 있는 서비스를 위해서도 변화가 필요함을 깨닫게 되었음.
◦
그러나 팀 전체가 코드를 구현하는 방식을 통일 할 필요성이 있었기 때문에, 조심스러우면서도 적극적으로 변화를 시도하였음.
◦
JSP 에서 <% %> 방식을 사용하던 부분이 인덴트, 중괄호 위치 문제 등으로 가독성과 유지보수성이 떨어지는 것을 느꼈고, 적극적인 건의를 통하여 JSTL 을 도입하기로 결정하였음.
◦
또한 Optional, 람다, Stream 과 같이 Java 8 버전 이상에서 사용할 수 있는 기능들을 도입하기 위해 노력하였으며, 이를 통해 팀원 모두가 본인의 의견을 스스럼없이 제시하는 분위기를 조성할 수 있고, 함께 발전 할 수 있게 노력하는 분위기가 조성되었음.
Syncronized 를 활용한 재고 수량 동시성 문제 해결
◦
재고 수량이 1개일 때, 동시에 여러 스레드가 접근하면, 재고 수량이 마이너스가 되고 주문도 모두 가능했던 동시성 문제가 발견되었음.
◦
해당 문제의 원인과 해결 할 수 있는 방법을 찾기 시작하였고, Race-Condition 문제임과 동시에, Syncronized, Lock 등 여러가지 방법이 해결 방법이 있음으로 알게 되었음.
◦
당시 WAS 서버를 한 대만 운영하였고, 문제를 빠르게 해결해야 했기 때문에 syncronized 를 활용하여 해당 동시성 문제를 우선 해결하였음. 이후 서버 확장을 고려하여 문제 해결 방법을 토의하였음.
JOIN 과 인덱스를 활용한 페이지 성능 개선
◦
메인 페이지 상품 조회 시 로딩이 지나치게 오래 걸리는 문제가 발생하였음.
◦
응답에 필요한 데이터를 가져올 때 DB에 여러 번 접근하던 부분을 JOIN을 활용하여 한 번만 접근하게끔 수정 하였음
◦
추가로 테이블 인덱스를 수정하여 제품 조회 성능을 올림.
▪
성능 개선을 위해 방법을 찾아보니, LIKE ‘%상품명%’을 활용하여 검색을 하면, 인덱스를 타지 않는다는 것을 알게 되었음.
▪
ngram 방식의 Full Text Index 를 적용하여 문제를 해결 할 수 있었으며, 상품 검색 외에 LIKE 를 굳이 사용하지 않아도 되는 기능은 LIKE 를 제거하거나, ‘검색명%’ 방식으로 수정하여 문제를 해결하였음.
◦
이를 통하여 최대 5~7초이상 걸리던 페이지 로딩시간을 1~2초까지 단축하였음.
2. 음식 주문 배달 서비스 ( 토이 프로젝트 )
•
프로젝트 링크
Redisson Lock을 활용한 포인트 전환 기능 구현
◦
동시성 문제로 인해 포인트 전환이 예상했던 것보다 많이 될 수 있는 문제점을 파악하였음.
◦
다중 서버를 사용하므로 Syncronized 로는 해결 할 수 없었으며, 이러한 악의적인 상황이 아닐 경우 잘 발생하지 않을 이슈이기 때문에 비관적 락도 적절하지 않다고 판단하였음.
◦
싱글 스레드 사용으로 Atomic 함을 보장하는 Redis 를 사용하기로 하였고, 그 중 타임아웃 설정으로 인한 데드락 방지와, 스핀락을 사용하지 않고 pub/sub 방식을 이용하여 좋은 성능을 낼 수 있는 Redisson 을 사용하여 해당 문제를 해결하였음.
◦
Redis 성능 향상을 위한 노력 ( Scan 활용, Server 분리 )
◦
Global 하게 Session 을 관리하기 위해서, 그리고 In-Memory 방식으로 조회 성능을 올리기 위해 Redis 를 사용하던 중, 유저가 많아지거나 캐시되는 데이터가 많아질 경우 추가적인 성능 문제가 발생 할 수 있는 문제점을 파악하였음.
◦
먼저 조회 성능을 올리기 위하여 Key 값을 가져오는 코드를 Keys 대신 Scan 을 활용하기로 수정하였음.
▪
Keys 는 시간 복잡도가 O(n) 이다. 그런데 Redis 는 Single Thread 이므로 Key 값이 많아지면, 해당 Key 값들을 모두 불러오는 동안 다른 요청을 처리하는데에 병목이 생길 수 있음.
▪
그러나, Scan 을 활용하면 원하는 설정한 count 에 따라, 중간 중간 다른 요청들을 처리해 줄 수 있기 때문에 성능이 올라가게 된다.
◦
다음은, Redis 의 Session Server 와 Cache Server 를 분리하여 물리적 메모리 사용량을 줄여, 성능을 개선하였음.
▪
메모리 사용량이 한계를 초과함에 따라 Swap 공간을 사용하게 될 수도 있는 문제를 방지하기 위함
Redis INCR 을 활용한, 선착순 쿠폰 발급 기능 개발
◦
동시성 문제로 인해 지정된 쿠폰 개수보다 많은 양의 쿠폰이 발급되는 문제가 발생하였음.
◦
이를 해결하기 위해 Redis 의 INCR ( increment )를 활용하였음.
▪
Redis 는 Single Thread 이므로, 내부적으로 숫자를 증가시키는 INCR 을 활용한다면 동시성 문제 없이 숫자를 증가 시킬 수 있고, Lock 개념도 아니기 때문에 좋은 성능도 낼 수 있음.
◦
또한 한정 쿠폰 발급 특성상, 트래픽이 한 번에 몰릴 수 있기 때문에 쿠폰 발급이 정상적으로 이루어지지 않을 경우를 대비하였음.
▪
try catch 를 통해 정상적인 처리가 되지 않은 데이터는 Exception_Coupon 테이블에 입력되도록 하였고, 배치 처리를 통하여 Exception_Coupon 테이블에 있는 데이터를 본래 쿠폰 테이블로 이동 시키는 로직을 추가하여 해결하였음.
◦
해당 문제 해결 과정을 정리한 포스팅 링크
JMeter 로 성능 테스트를 하며 적절한 서버 구축
◦
NaverCloud 로 서버를 구축하며, 목표했던 TPS 를 맞추기 위해 JMeter 라는 프로그램을 활용하여 성능을 테스트하였음.
◦
기존에 WAS 서버 2대로 가능 할 거라 판단했지만, JMeter 로 성능 테스트를 한 끝에 3대로 늘리게 되었으며, 이를 통하여 서버 성능을 개선할 수 있었음.
◦
About Me
팀 전체의 발전을 위한 커뮤니케이션 능력
•
스스로 성장은 당연히 중요하지만, 아무리 공부하고 성장해도 팀 전체가 발전할 수 있도록 노력하지 않으면 스스로 성장이 팀 자체에 영향을 미치는 부분은 미미할 수 있다고 생각합니다.
•
저는 군대에서 소대장으로 지내던 시절 이 부분을 크게 경험하였습니다. 소대 대항 모의전투 훈련에서 모든 소대원이 죽고, 혼자 살아남았던 적이 있습니다. 그때 소대가 강해지려면, 소대장만 강해서 되는 게 아니라 모든 소대원이 성장해야 함을 느꼈습니다. 그 심리를 가지고 저는 소대 전체가 발전할 수 있도록 부단히 노력하였고, 끝내 대대 최우수 소대를 만들 수 있었습니다.
•
이 경험은 사회로 나와 첫 회사에서도 좋은 발판이 되었습니다. 최초 4명이 한 팀이 되어 이커머스 플랫폼 개발 프로젝트에 투입되었습니다.
•
저는 프로젝트 중간마다 어떻게 하면 성능과 유지보수 면에서 효율성 있게 개발할 수 있을까를 고민하였습니다. 당시 JSP에서 스크립틀릿을 활용한 개발을 진행하고 있었는데, 가독성이 너무 좋지 않아 추후 유지보수가 어려워질 것이라는 생각이 들었습니다.
•
저는 팀에 적극 건의하였고, 모두가 JSTL을 사용하는 방향으로 가게 되었습니다, 그리고 저는 팀원들에게 JSTL에 대해 교육을 하는 역할을 맡게 되었습니다. 그 결과 JSTL을 사용한 개발 방식으로 코드의 가독성이 올라갔고, 프로젝트 종료 후 유지보수 시간 비용을 절약할 수 있게 되었습니다.
•
이러한 경험은 건전한 소통을 위해 노력했을 때, 모두가 본인의 의견을 스스럼없이 제시하는 분위기를 조성할 수 있고, 함께 발전해 나갈 수 있다는 것을 느꼈습니다. 결과적으로 이는 분명 팀 전체의 방향성 통일과 긍정적인 분위기 조성, 그리고 나아가 팀 전체의 능률 상승으로 이어졌다고 생각합니다.
기초를 탄탄하게, 한 걸음씩 꾸준하게
•
저는 항상 Why? 를 습관화 하기 위해 노력하였습니다. 단순한 상명하복을 중요시하는 군대에서도 이 임무가 왜 하달되었는지, 더 효율적이고 안전하게 하기 위해서는 어떻게 해야하는지를 끊임없이 고민하였고, 그 결과 생각지도 못한 부분에서 발생하는 문제도 유연하게 대처할 수 있었으며, 창의적이고 좋은 결과를 만들어 내었습니다.
•
IT 첫 직장에서도 프로젝트에 투입하고부터 우리가 이커머스 프로젝트를 하는데 왜 언어를 java로 선택했고, spring이라는 프레임워크는 왜 사용할까라는 근본적인 질문부터 공부하기 시작했습니다. 그렇게 야근과 주말 출근 속에서도 하루에 2시간씩, 주말에는 그것보다 더 스스로에게 투자하게 되었습니다. 그렇게 몇 달이 지나자 안보이던 것들이 보이기 시작하였고, 프로젝트와 팀 발전에 기여할 수 있는 사람이 되었습니다.
•
지금의 저는 그저 굴러만 돌아가기만 하면 되는 프로그램을 만드는 것이 아니라, 어떻게 하면 더 좋은 성능을 낼 수 있을 지를 고민하고, 어떻게 하면 가장 효율적인 코드를 작성할 수 있을까를 고민합니다. 그리고 끊임없이 why라는 질문을 스스로에게 던지며 그 답을 찾고자 공부하고 있습니다.
•
예전에는 구글링을 하여도 알 수 없던 문제를 지금은 기초 지식에 근거하여 답을 찾아갈 수 있습니다. 저는 앞으로도 끊임없이 고민하고 탐구하며 도전하는 개발자가 될 것이고, 지금의 마인드를 잃지 않는다면 앞으로도 끊임없이 개발자로서 성장할 수 있다고 생각합니다.
기록은 곧 자산이다
•
우리의 머리는 PC를 종료하면 데이터가 지워지는 RAM과 같습니다. 머리로만 기억하는 것은 금방 잊어버리기 쉽습니다. 이걸 보완하기 위해서는 기록하는 습관을 들여야 합니다. 저는 과거의 기록들을 보면 부족한 점을 스스로 발견하고 고쳐 발전할 수 있다고 생각해왔기에 일상 속에서 일어나는 크고 작은 일들을 기록해왔습니다.
•
소대장 시절에는 품에 늘 손바닥만 한 수첩을 가지고 다녔고, 필요한 것은 메모하고 기록하였습니다. 기록은 대부분은 유연하게 대처할 수 있는 나침반이 되어주기도 하였고, 자기 발전을 위한 발자취가 되기도 하였습니다.
•
개발에서도 이러한 습관은 저에게 많은 도움을 주었습니다. 먼저 공부한 것을 기록함으로써 회사 업무나, 개인 프로젝트 개발 시에 적용할 수 있었습니다. 단순히 머리로만 기억했다면 공부했던 내용을 50%도 적용하기 어려웠을 수도 있습니다. 하지만 기록했던 내용을 확인하며 완성에 가깝게 적용할 수 있었습니다.
•
또한 사내 프로젝트를 진행하며, 벌어지는 수많은 에러와 문제들이 있습니다. 이때 발생한 에러들을 엑셀로 문서화 하여, 팀원들과 공유하였습니다. 그 덕분에 에러를 해결하기 위해 발생하는 시간적 비용을 줄일 수 있었고, 제가 먼저 공유를 하기 시작함으로써 다른 팀원들도 해당 파일에 본인들의 경험을 기록하기 시작하여 개발 성과를 높일 수 있었습니다.
•
기록하는 습관은 지금도 유지하고 있습니다. 이전에는 공부한 내용을 문서로 기록했다면 지금은 블로그에 기록하고 있습니다. 사내에서 공유할만한 기록을 하게 된다면 이제는 구글 독스와 Notion도 활용할 수 있게 되어서 이것들을 활용하여 기록하고 공유할 계획입니다. 이는 위에서 말씀드린 스스로와 팀의 발전에도 크게 이바지할 수 있는 좋은 습관이라고 생각합니다.
Projects
한눈에 보기
표로 보기
Search
Education & Military Service
병역 사항
( 2019.03 ~ 2021.06 )
•
육군 중위 만기 전역 ( ROTC 57기 )
강남 대학교
( 2015.03 ~ 2019.02 )
•
국어국문학과 졸업
Stacks
Back-End
Java
Mybatis
Spring Boot
JPA
DevOps
MySQL
Naver Cloud
Redis
Docker
Certification
•
정보처리기사 ( 2023. 11. 15 )
•
운전면허증 1종 ( 2019. 03. 04 )