[아이든든] 신한투자증권 프로디지털 아카데미 최종 프로젝트 회고
드디어 최종 발표가 끝났다...
프로젝트를 진행하는 동안에는 구현, 배포, 발표 준비를 동시에 하느라 정신없이 지나갔는데, 끝나고 나니 우리가 어떤 문제를 해결하려고 했고, 그 과정에서 무엇을 배웠는지 정리해보고 싶어졌다.
신한투자증권 프로디지털아카데미 최종 프로젝트로 자녀 미래 자산 설계 서비스, 아이든든을 개발했다.
아이든든은 부모가 자녀의 미래 자금을 목표 기반으로 준비하고, 아동수당과 부모의 여유자금을 자녀 증권 계좌로 연결해 ETF 투자와 증여 관리까지 이어갈 수 있도록 돕는 증권 중심 금융 복합 서비스다.
이번 프로젝트에서 내가 맡은 역할은 크게 다음과 같았다.
- 프론트, 백엔드 프로젝트 초기설정
- 백엔드 API 설계 및 구현
- 자녀 관련 기능, 증여 관련 기능, 회원, SPRING SECURITY 인증 기능, 아동수당 기능
- 아동수당, 증여세, ETF 증여 기준 리서치
- 사용자 가이드탭, 가이드 디자인,
- 인프라 리드 및 인프라 구축
- FULL SCAN을 인덱스를 사용하여 성능 개선
- 전반적안 UIUX 개선
- 최종 발표
이번 글에서는 주간 로그와 프로젝트를 진행하며 느낀 점을 KPT 방식으로 정리해보려고 한다.
주간 로그
1.사용자 가이드 탭을 제안
|
|
|
|
|
|
프로젝트를 진행하면서 문득 이런 생각이 들었다.
“우리 서비스를 처음 쓰는 사용자가 과연 바로 이해할 수 있을까?”
아이든든은 ETF를 사고파는 서비스에서 끝나는 것이 아니라, 목표 설정, 자녀 계좌, 아동수당, 증여, ETF 투자까지 이어지는 서비스다.
기능이 많은 만큼 처음 접하는 사용자에게는 흐름이 어렵게 느껴질 수 있다고 생각했다.
특히 증여 기능은 용어 자체도 어렵고, 유기정기금 증여나 ETF 증여처럼 사용자가 평소에 접하기 어려운 개념도 포함되어 있었다.
그래서 사용자가 서비스를 더 쉽게 이해할 수 있도록 사용자 가이드 탭을 만들자는 의견을 제안했다.
가이드에는 간단한 사용법뿐만 아니라, 사용자가 헷갈릴 수 있는 내용을 함께 담았다.
서비스 이용 흐름
목표 설정 방법
ETF 투자 연결 방법
증여 방식별 차이
자주 묻는 질문
아동수당 연결 안내또한 아이든든의 캐릭터와 서비스 정체성을 함께 보여주면서, 딱딱한 금융 서비스가 아니라 자녀의 미래 자산을 함께 키워가는 느낌을 전달하고자 했다.
이 아이디어는 팀원들도 긍정적으로 봐주었고, 실제 서비스 완성도를 높이는 데 도움이 되었다고 생각한다.
기능을 많이 만드는 것도 중요하지만, 사용자가 그 기능을 이해하고 사용할 수 있게 만드는 것도 서비스의 중요한 일부라는 것을 느꼈다.
2.QA
프로젝트 후반에는 기능이 많아지면서 작은 오류가 다른 흐름에 영향을 주는 경우가 많았다.
그래서 노션에 QA 목록을 만들어 계속 점검했다.
특히 발표 전에는 로컬이 아니라 실제 배포 환경에서 같은 흐름이 동작하는지 확인하는 것이 중요했다.로컬에서는 정상적으로 보이던 기능도 배포 환경에서는 포트, Gateway 라우팅, Redis 연결, API 응답 형식 문제로 다르게 동작할 수 있었기 때문이다.
이 과정이 최종 시연 흐름을 안정화하는 데 도움이 되었다.
3. 디테일 살리기
바텀시트를 쓰는 입력창과 안쓰는 창이 혼재할 만큼 ui가 통일성이 없었었다.
이 부분이 문제가 된다고 생각하여 ui의 통일성을 맞추는데에도 시간을 많이 썼던 것 같다.. 또한 lucid-react 기반이 아닌 운영체제 이모지가 쓰여진 부분들이 다양한 사람들이 협업을 하다보니 생기게 되었다... 그래서 이 부분을 통일 시켰다..!
또한 달력 ui를 fullcanlendar라는 라이브러리를 사용하는 것이 좋을 것 같다는 생각이 들어서 이 부분도 개선을 하였다! 실제로도 현업에서는 이 라이브러리를 많이 쓴다하여 채택했다...
프론트에서 입력 검증이 안되어있는 부분들이 있어 이 부분도 보완을 하였다..
또한 사용자 입장에서의 버튼 위치와 흐름을 생각하면서 컴포넌트 위치들도 조정을 하는 시간을 가지게 되었다...
4. 캐릭터 정체성 더하기
우리 서비스에는 크게 두가지 캐릭터가 존재한다.
1. 쑥쑥이
쑥쑥이의 경우는 목표 달성률이 채워질때마다 자라나는 나무이다!
쑥쑥이를 통해서 부모님들이 시각적으로 달성률을 확인하고 점점 자라나는 쑥쑥이를 통해 불안감을 해소할 수 있도록 의도하였다.
2. 든든이
든든이는 목표 탐색 기능을 담당하는 캐릭터이다.
쑥쑥이 즉 나무가 자라기 위해서는 조력자 같은 존재인 햇빛이 필요하다 생각을 하여
이 부분을 모티브하였다! 그래서 햇빛이 캐릭터가 되었다!
5. ls 토큰 재발급이 안되는 이슈
ls증권에서는 토큰을 매일 오전 7시마다 초기화를 시킨다.
이 부분이 로직이 없어 배포 환경에서 오류가 나는 것을 확인하고 스케줄러를 사용하여 오전 7시 1분마다 토큰을 재발급 받도록 로직을 변경하였다.
KPT 회고
Keep: 잘한 점
1. 서비스 아이디어를 정책과 세무 근거로 구체화한 점
초기에는 단순히 “자녀를 위한 ETF 투자 서비스”로 접근했다.
이때 자녀 명의 계좌로 돈이 이동하는 순간 증여 이슈가 발생하고, 부모가 실제로 활용할 수 있는 아동수당과 부모급여 같은 정책도 서비스 흐름과 연결될 수 있다는 점을 다양한 증권사와 은행을 분석하면서 알게 되었다.
그리고 자녀를 위한 서비스를 조사하다보니 증여에 대한 많은 니즈가 있다는 것을 파악하게 되었다.
그래서 아동수당과 증여 부분을 넣는 것이 좋을 것 같다고 생각하여 왜 중요할 것 같은지를 노션에 적어 팀원들에게 공유를 하여 서비스에 적용할 수 있었다!
그래서 아동수당, 부모급여, 증여 비과세 한도, ETF 증여 평가 방식 등을 조사했다.
그 결과로 우리 서비스의 흐름과 기획이 명확해지면서 부모의 불안감 해소를 위한 것이라는 서비스의 정체성을 찾을 수 있었던 것 같다.
정부지원금
→ 은행 계좌
→ 증권 계좌
→ ETF 투자
→ 증여 관리
→ 자녀 미래 자산이때 이러한 정책과 세무 근거를 바탕으로 서비스 설득력을 높일 수 있었다.
처음에는 처음보는 세무법이어서 막막했지만 하나하나 공부를 하고 여러 조건에 따른 증여세법이 다른 것을 파고들어 공부를 해보았다. 그 결과 개발을 진행시 예외처리를 다양하게 할 수 있었고 이로 인해 좀 더 신뢰성 있는 서비스로 만들어 낼 수 있었던 것 같다!
힘들기도 했지만 나름 예외처리를 하고 각 경계값에 맞게 잘 동작하는지 테스트 하는 과정이 재미있었던 것 같다......!🥹
또한 한화생명과 한화투자증권에서 출시한 pi라는 앱을 참고하고, 왜 입력값을 제한을 하고, 왜 입력 형식을 이렇게 받으며, 가격 보정의 이유, 기간 선택의 제한 등을 보면서 고민하는 과정들이 디테일을 살리는 부분에서 도움이 많이 되었던 것 같다..!
이와 관련하여 조사하고 적용한 부분에 대해 쓴 블로그를 아래에 첨부해두겠다.
https://velog.io/@ye_sir0605/1vco92fg
https://velog.io/@ye_sir0605/8yhn602z
2. 기능을 개별적으로 보지 않고 전체 흐름으로 정리한 점
프로젝트 후반으로 갈수록 단일 API 구현보다 전체 사용자 flow를 맞추는 일이 더 중요했다.
아이든든은 목표 설정, ETF 투자, 증여 관리, 아동수당 연결이 각각 따로 존재하는 서비스가 아니었다.
사용자는 자녀를 등록하고, 목표를 탐색하고, ETF를 매수하고, 증여 현황을 확인하는 흐름을 자연스럽게 경험해야 했다.
자녀 등록
→ 목표 탐색
→ 목표 설정
→ ETF 투자
→ 증여 관리
→ 자녀 자산 확인이 흐름을 기준으로 기능을 정리하니 프론트 화면, 백엔드 API, 발표 시나리오를 같은 방향으로 맞출 수 있었다.
3. 증여 도메인을 간단한 입금이 아니라 상태 흐름으로 바라본 점
증여 기능은 처음 생각보다 훨씬 복잡했다. 앞에서 말했다시피 엄청난 아이였다.. 알고볼수록 까다로워 개발시 머리가 터질듯이 고민이 많았던 파트였다..... 특히 국세청 자료에는 어려운 용어들이 너무 많아 이 부분을 하나하나 뜯어보는게 힘들었던 것 같다
일시금 증여, 유기정기금 증여, ETF 증여는 모두 “증여”라는 이름을 가지지만 필요한 검증과 상태 흐름이 달랐다.
일시금 증여
→ 부모 계좌 잔액 확인
→ 즉시 완료
유기정기금 증여
→ 회차별 이체 생성
→ 스케줄러 처리
→ 진행 상태 관리
ETF 증여
→ 부모 ETF 보유 수량 확인
→ ETF 평가금액 계산
→ 증여 계약 생성아래는 증여 관련 기능을 개발한 흐름을 나타낸 흐름도이다!
특히 ETF 증여는 아래와 같이 증여일 전후 2개월 평균가를 고려해야 했기 때문에, 등록 시점의 예상금액과 이후 확정금액을 구분하는 방식도 고민했다.
이 과정에서 금융 도메인은 상태와 기준을 명확히 정의해야 한다는 것을 배웠다.
4. 백엔드와 인프라 이슈 파악을 잘한 점
전반적으로 백,인프라쪽을 주도적으로 리드를 하면서 많은 것을 배웠던 것 같다..!
특히 FE, BE(gateway/Core / MTS / Stats) 이렇게 각각 인프라를 설계를 하면서 msa구조를 고민하게 되었고 배포를 하면서 지금까지 해온 배포 중 가장 어려움이 있었던 것 같다...
여러 서버를 쓰다보니 포트 문제나 설정 문제가 잦아 이 부분을 해결을 하면서 이슈 파악을 잘했던 것 같다..!
특히 인프라 및 배포 전략을 짜 팀원들도 다른 서버를 배포할 수 있도록 문서화하여 제공한 점이 잘했던 점인것 같다!
이 과정에서 로컬에서 API가 성공하는 것과 실제 배포 환경에서 서비스가 안정적으로 동작하는 것은 다른 문제라는 것을 깨달았다
[트러블 슈팅 및 이슈 정리 내용]
https://velog.io/@ye_sir0605/8yhn602z
https://velog.io/@ye_sir0605/vyjvby4c
5. Full Scan 문제 해결
증여 계약 조회에서는 child_id, parent_id 컬럼에 인덱스를 추가해 Full Scan 문제를 개선했다.
처음에는 이 부분을 고려하지 않고 개발을 진행했었다. 프로젝트 막바지로 가니 성능 문제도 생각을 해야하는 타이밍이 왔었던 것 같다... 그래서 이 참에 이 부분을 개선하는 것이 좋을 것 같다 판단을 하여 진행을 해보았었다.
이 부분을 진행하면서 k6테스트를 진행하였다!
그 결과 다음과 같은 결과로 성능을 높일 수 있었다..!
p95 응답시간: 4.50초에서 3.63초로 19% 감소
처리량: 6.48 req/s에서 9.27 req/s로 43% 증가
이를 통해서 데이터가 많아졌을 때도 안정적으로 조회될 수 있는 구조를 고민할 수 있었다.
Problem: 아쉬운 점
1. 기능 범위가 커지면서 우선순위 정리가 늦어진 점
프로젝트를 진행하면서 넣고 싶은 기능이 계속 늘어났다.
아동수당, 부모급여, 출산지원금, 증여세, ETF 평가, 홈택스 신고 가이드, 목표 탐색 개인화 등 확장할 수 있는 방향이 많았다.
하지만 최종 프로젝트 기간 안에 모든 기능을 완성도 있게 구현하기는 어려웠다.
MVP에서 반드시 필요한 기능과 고도화 기능을 더 빠르게 나누었다면 개발 우선순위를 잡는 데 더 도움이 되었을 것이다.
2. 프론트와 백엔드 응답 기준을 더 일찍 맞추지 못한 점
백엔드와 인프라 작업에 집중하다 보니 프론트에서 필요한 응답 형식, enum 값, 날짜 포맷을 더 일찍 맞추지 못한 부분이 있었다.
이 문제는 API 설계서를 꼼꼼하게 설계하지 못해 발생한 것 같다는 생각이 든다..
개발을 하면서 느낀 것은 바로....
금융 서비스에서는 상태값과 날짜가 중요하다!
SCHEDULED
COMPLETED
FAILED
CANCELLED프론트와 백엔드가 같은 상태값을 기준으로 화면을 그려야 하는데, 이 기준을 늦게 맞추면 연동 오류가 쉽게 발생한다.
다음에는 API 명세, 응답 예시, enum, 날짜 포맷을 초기에 먼저 고정해야겠다고 느꼈다.
3. 발표 준비와 트러블슈팅 정리를 더 일찍 병행하지 못한 점
프로젝트 후반까지 기능 구현과 오류 대응이 이어지면서 발표 자료와 트러블슈팅 정리가 뒤로 밀렸다.
그래서 발표준비를 급하게 준비를 하게 된 것 같아 아쉬운 점이 존재한다...
또한 성능 개선을 더 해보지 못한 것이 아쉬운 것 같다...
Try: 다음에 시도할 점
1. MVP와 고도화 기능을 초기에 나누기
금융 도메인 서비스는 확장할 수 있는 기능이 많다.
그래서 다음에는 기획 초기에 기능을 다음처럼 나누고 시작하려고 한다.
MVP에서 반드시 필요한 기능
최종 시연에서 보여줄 기능
시간이 남으면 추가할 기능
고도화 아이디어로 남길 기능이 기준이 있어야 프로젝트 후반에 기능 범위가 커지는 것을 막을 수 있다.
2. API 명세와 상태값을 먼저 맞추기
프론트와 백엔드 연동에서 자주 문제가 되는 부분은 응답 구조, enum, 날짜 포맷이다.
다음에는 기능 구현 초기에 다음 내용을 먼저 맞추려고 한다.
API 경로
request body
response body
enum 값
날짜 포맷
에러 코드
빈 상태 응답특히 금융 서비스에서는 예정값, 확정값, 실패 상태, 취소 상태를 명확히 구분해야 한다는 것을 깨달았다...
3. 성능 개선하기
ERD 설계 부분이 아쉬운 점이 많아서 개발을 진행하면서 꼬인 적이 많았던 것 같다.
그래서 시간이 된다면 ERD를 개선하여 join 테스트나 다양한 시간 측정을 해보고 싶다.
특히 우리 서비스 테이블에는 한 테이블에 너무 많은 정보를 갖고 있는 경우도 많아, 한 테이블에 null값이 많이 존재한다.
이 부분이 아쉬운 점이 많았던 것 같아서 나중에 테이블을 분리하면서 개선해보고 싶다.
또한 불필요한 참조가 일어나는 경우도 있었어서 이 부분도 함께 개선해보고 싶다.
4. 모니터링 구축 & 정적 코드 분석
중간 프로젝트에서는 시간의 여유가 있어 grafana와 prometheus로 모니터링 환경을 구축했었다.
이런 모니터링을 기말 프로젝트에서도 구축해보고 싶었지만 시간이 부족하여 진행하지 못했다.
그래서 이 부분을 고도화 해보고 싶고 소나큐브 같은 정적 코드 분석기를 통해서도 미리 사전에 코드가 망가지는 것을 예방하는 식으로 개선해나가고 싶다!
배운 점
이번 프로젝트에서 가장 크게 배운 점은 소프트 스킬과 협업 능력인 것 같다.
서로의 의견을 조율하는 과정에서 소프트 스킬이 중요하다는 것을 다시 한번 깨닫게 되었던 것 같다.
이 과정에서 서로 의견(온보딩 건너띄기 기능, 어느 기능을 우선순위에 둘 것인지 등등) 을 주고 받다보니 더 나은 절충안을 내어 프로젝트를 성공적으로 마무리 할 수 있었던 것 같다.
그리고 완전한 msa는 아니지만 인프라 부분을 리드하면서 비슷하게라도 따라가보면서 특히 msa 구조에서 중요한 통신을 생각하면서 인프라를 설계하였는데 이 점이 네트워크까지 생각을 하다보니 많은 성장을 일으켰던 것 같다.
또한 증여세법이란 법 도메인과 증권 도메인을 결합하여 개발을 진행하는 과정에서 각 도메인들에 대해 이해하는 것이 얼마나 중요한지 다시 한번깨닫게 되었고 왜 예외처리를 자세히 해야하고 검증을 제대로 해야하는지에 대해 깨달았던 것 같다.
마무리
아이든든은 자녀의 미래 자산을 준비한다는 문제를 중심으로 시작한 프로젝트다.
완벽하게 모든 기능을 구현했다고 말하기는 어렵지만, 자녀 등록부터 목표 탐색, 목표 설정, ETF 투자, 증여 관리까지 이어지는 flow를 끝까지 연결하려고 노력했다.
이번 프로젝트를 통해 금융 도메인의 정책 리서치, 증여 로직 설계, 백엔드 API 구현, 배포 환경 대응, 프론트 연동, 발표 준비까지 폭넓게 경험할 수 있었다.
결국 좋은 서비스는 성공 케이스만 잘 처리하는 것이 아니라,
사용자가 헷갈리거나 실패했을 때도 자연스럽게 다음 행동으로 이어질 수 있어야 한다고 느꼈다.
아이든든이라는 이름처럼, 부모가 자녀의 미래를 막연히 걱정하는 대신 조금 더 든든하게 준비할 수 있는 서비스를 만들고 싶었다.
이 경험을 통해서 기술로 신뢰성을 높이는 개발자가 되고 싶다는 생각을 하게 된 것 같다.
추가적으로 최종 발표 피드백과 질문을 받으면서 내가 중요하게 생각하여 고려한 증여, 아동수당 부분들과 내거 직접 성능 개선한 FULL SCAN 해결, 그리고 팀원들과 함께 고생한 부분에 대해 칭찬을 받아 기분이 좋았던 것 같다!
같이 한달동안 진짜 많이 고생하고,,, 항상 열심히 해준 소중한 파프리카 팀원들에게도 진심으로 고마웠다는 말을 함께 전하며 블로그를 마무리를 할 예정이다...!🥹
진짜로 🐥파프리카 팀원들과 거의 가족처럼 한달동안 꼭 붙어 다녔던 것 같다..주말도..평일도...밤에도...새벽에도...
약 6개월간 함께했던 프디아가 마지막 날이라 생각하니 진짜 슬펐다는 사실........
