드디어 최종 발표가 끝났다...

프로젝트를 진행하는 동안에는 구현, 배포, 발표 준비를 동시에 하느라 정신없이 지나갔는데, 끝나고 나니 우리가 어떤 문제를 해결하려고 했고, 그 과정에서 무엇을 배웠는지 정리해보고 싶어졌다.

신한투자증권 프로디지털아카데미 최종 프로젝트로 자녀 미래 자산 설계 서비스, 아이든든을 개발했다.

아이든든은 부모가 자녀의 미래 자금을 목표 기반으로 준비하고, 아동수당과 부모의 여유자금을 자녀 증권 계좌로 연결해 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개월간 함께했던 프디아가 마지막 날이라 생각하니 진짜 슬펐다는 사실........

+ 이전에 개발을 진행하며 고민했던 부분에 대해 썼던 블로그도 아래에 달아두었다!!

아이든든_개발 블로그 시리즈

이번에는 아이디어를 더 구체화하면서 조사했던 증권사, 은행, 자녀 금융 서비스들을 정리해보려고 한다.

서비스 방향을 잡는 과정에서 가장 중요하게 본 것은 다음 세 가지였다.

• 자녀 명의 계좌 관리가 실제로 가능한가
• 아동수당이나 증여를 자녀 자산 형성과 연결할 수 있는가
• 단순 계좌 개설을 넘어 목표 기반 자산 관리로 확장할 수 있는가

1. 서비스 방향 재정리

처음 잡은 서비스 목표는 다음과 같았다.

우리 아이, 부끄럽지 않게 키우자!!!

처음에는 이 문구를 내뱉고 나서는 무언가 웃겼지만 우리가 해결하고 싶은 문제를 잘 담고 있다고 생각했다. 귀에 쏙쏙 들어와서 정체성을 잃지 않았던 것 같다..!

부모는 아이가 태어난 이후부터 막연한 금융 불안감을 갖게 된다.

• 교육비
• 입학 준비금
• 대학 등록금
• 독립 자금
• 증여 문제
• 투자 손실에 대한 걱정

이러한 걱정들 때문에 고려할 것이 많다고 생각하였다...

그래서 우리 서비스는 단순히 자녀 계좌를 만들어주는 서비스가 아니라, 부모가 아이의 미래 자산을 장기적으로 준비하고 기록할 수 있도록 돕는 서비스가 되어야 한다고 생각했다.

2. 우리 서비스의 목적

우리 서비스의 목적은 다음과 같이 정리했다.

즉, 우리 서비스는 다음과 같은 방향을 가진다.

고객의 금융 니즈를 발견하고 금융상품과 연결하는 서비스

조금 더 구체적으로는,

아이 미래 자산을 부모가 장기적으로 준비하고 기록하는 서비스

라고 정의할 수 있었다.

3. 고객 사이클

부모가 자녀의 미래 자산을 준비하는 과정을 하나의 사이클로 정리했다.

이 흐름을 기준으로 기능을 정리하니, 서비스의 역할이 조금 더 명확해졌다.

4. 타겟 고객

우리가 생각한 주요 타겟은 다음과 같다.

페르소나는 다음과 같이 정리할 수 있었다.

아이가 태어난 뒤 자녀의 미래 자금을 준비하고 싶지만, 어디서부터 시작해야 할지 막막한 주식 초보 부모

이 고객은 단순히 투자 상품을 추천받고 싶은 것이 아니다.

• 얼마를 목표로 잡아야 하는지
• 매달 얼마를 준비해야 하는지
• ETF 투자가 괜찮은지
• 손실 위험은 어떻게 봐야 하는지
• 증여세는 어떻게 관리해야 하는지
• 아동수당을 어떻게 활용할 수 있는지

이런 질문에 대한 답이 필요하다고 생각했다.

5. 자녀 금융 서비스 분석

서비스를 구체화하면서 자녀 투자, 자녀 계좌, 증여, 아동수당과 관련된 서비스를 조사가 필요하다 생각하여 팀원들에게 각자 조사하는게 어떨지 물어보았고 팀원들이 동의를 해주어서 분석을 해보았다.

그래서 나는 자녀 금융 서비스를 뉴스와 앱스토어, 구글링, 증권,금융사 홈페이지를 통해서 조사를 하고 팀원들에게 공유를 하였다.

이 과정에서 전에 조사했던 어플도 말고도 더 많은 서비스들이 존재하고 니즈에 대한 파악을 할 수 있었다.

이 과정에서 꼼곰하게 조사를 하면서 기획적인 능력을 키울 수 있었던 것 같아 힘들긴했지만 뿌듯했다.

다시 한번 알게 된 점!

서비스가 존재하는데에는 이유가 있고 없는데에도 이유가 있다...

조사를 하면서 우리 서비스에서의 한계점도 발견하게 되고, 보완과 논의가 필요한 점도 찾아가게 되었다.. 그래서 이 부분들을 따로 정리해 팀원들에게 이야기해 점차 완성도를 높여갈 수 있었다.

내가 조사한 내용들을 이제 적어보면 다음과 같다...

크게 다음 서비스들을 참고했다.

6. 주주부모

https://www.funetf.co.kr/investInfo/investLibrary/premium/26943

참고 포인트

• 자녀 투자 콘텐츠
• ETF 중심 투자 정보
• 장기 투자 관점
• 부모 대상 금융 콘텐츠
• 투자 교육형 접근

주주부모 관련 자료를 보면서, 자녀 금융 서비스에서 ETF 콘텐츠가 중요한 역할을 할 수 있다고 느꼈다.

우리 서비스에서도 단순히 “ETF를 사세요”가 아니라, 부모가 이해할 수 있는 방식으로 ETF의 역할과 장기 투자 관점을 설명해주는 구조가 필요하다고 생각했다.

7. 퍼핀 & 신한투자증권

https://besuccess.com/?p=180562

위 내용은 뉴스 내용을 캡쳐했던 부분이다.. 언제가는 도움이 되지 않을까 해서...

내용

• 가족금융 플랫폼
• 자녀 주식계좌 개설
• 대리 주식매매
• 증여 설계
• 홈택스 셀프 신고
• 신한투자증권 협력
• 부모/자녀 금융 경험 통합

참고 포인트

• 자녀 주식 투자
• 증여 관리
• 홈택스 신고 가이드
• 가족 단위 금융 플랫폼
• 자녀 금융 교육
• 실제 투자 경험 연결

이 사례를 보면서 자녀 금융 서비스에서 증여가 거의 필수 요소에 가깝다는 생각이 들었다.

자녀 명의로 투자하거나 자산을 쌓는 순간, 부모 입장에서는 자연스럽게 다음 질문을 하게 된다.

• 이 돈은 증여인가?
• 얼마까지 비과세인가?
• 신고는 해야 하는가?
• 홈택스에서 어떻게 신고하는가?
• 부모 돈과 자녀 돈은 어떻게 구분해야 하는가?

그래서 우리 서비스에도 증여 관련 가이드나 Q&A 기능이 필요하다고 판단했다.

8. KB증권 & 든든

https://www.dndn.io/notice/618

내용

• KB증권 자녀 계좌 개설
• 든든 앱 계좌 연동
• 든든 주니어 투자 시작
• 자녀 정보 입력
• 법정대리인 확인
• 투자 성향 확인
• 포트폴리오 제공
• 자동투자 구조
• 증여 비과세 안내
• 증여 신고 안내

참고 포인트

• 부모 명의 로그인
• 자녀 계좌 연결
• 법정대리인 확인
• 자녀 투자 성향 확인
• 투자원금,평가금,수익률 확인
• 자녀 계좌 운용 상세 화면
• 증여 가이드
• Q&A 구조

든든 사례를 보면서 부모가 자녀 계좌를 등록하고 관리하는 흐름이 서비스적으로 충분히 가능하다는 점을 확인할 수 있었다.

또한 자녀 자산 관리 화면에서는 단순히 잔고만 보여주는 것이 아니라, 다음 정보들이 함께 필요하다고 생각했다.

우리 서비스도 자녀 자산 대시보드에서 이런 정보를 직관적으로 보여주는 것이 중요하다고 느꼈다.

9. 삼성증권 mPOP

https://www.instagram.com/p/DX6Faw3EXBh/
https://www.samsungpop.com/ux/kor/customer/guide/eventguide/eventViewContent.do?menuNo=01010900&MenuSeqNo=3803

삼성증권 주요 기능

• 자녀자산모으기
• 자녀잔고관리
• 아동수당계좌변경
• 자녀 명의 계좌 개설
• 자녀 자산 모의 시뮬레이션
• 투자손익 확인
• 수익률 관리
• 성년까지 남은 기간 확인
• 증여 공제 활용
• 아동수당 증권계좌 수령

참고 포인트

• 아동수당 활용
• 증권계좌로 수당 수령
• 자녀 자산 시뮬레이션
• 잔고 통합 관리
• 투자손익 관리
• 목표 기간 기반 관리
• 증여 공제 안내

삼성증권 사례를 보면서 우리가 생각했던 아동수당 자동 굴리기 아이디어가 충분히 설득력 있는 방향이라는 생각이 들었다.

특히 아동수당을 생활비로 자연스럽게 써버리는 것이 아니라, 자녀 명의 계좌로 받고 장기 자산으로 전환하는 흐름은 우리 서비스와 잘 맞는다고 느꼈다.

10. 신한투자증권 자료

https://www.shinhangroup.com/kr/archive/press/detail/743

내용

• 미성년자 계좌 개설 증가
• 모바일 비대면 계좌 개설 확대
• 미성년자 ETF 투자 선호
• S&P500·QQQ ETF 선호
• 장기·분산 투자 흐름
• 자녀 명의 계좌의 자산관리 활용
• 우리아이 자산관리 서비스 추진

참고 포인트

• 미성년자 투자 수요 증가
• 비대면 자녀 계좌 개설 흐름
• ETF 중심 장기 투자
• 부모와 자녀가 함께하는 투자 경험
• 신한투자증권 서비스 확장 가능성

신한투자증권 자료를 보면서 우리가 잡은 방향이 시장 흐름과 크게 벗어나지 않는다고 느꼈다.

특히 미성년자 계좌가 단순 투자 체험을 넘어, 중장기 자산 관리와 금융 교육 수단으로 활용되고 있다는 점이 인상적이었다.

11. 서비스 분석 종합

조사한 서비스들을 종합해보면, 자녀 금융 서비스에서 반복적으로 등장하는 요소들이 있었다.

공통적으로 등장한 요소

• 자녀 계좌 개설
• 부모의 법정대리인 인증
• 자녀 명의 투자
• ETF 중심 장기 투자
• 자녀 잔고 관리
• 투자손익 확인
• 수익률 확인
• 아동수당 활용
• 증여 비과세 안내
• 홈택스 신고 가이드
• 자녀 금융 교육
• 장기 자산 시뮬레이션

이 중에서 우리 서비스에 꼭 필요하다고 생각한 것은 다음 네 가지였다.

12. 우리 서비스에 반영할 기능

조사 내용을 바탕으로 우리 서비스에 반영할 기능을 다시 정리했다.

1. 자녀 프로필 등록

• 자녀 이름
• 생년월일
• 목표 나이
• 목표 금액
• 자녀 증권 계좌
• 보호자 정보

2. 현재 자산 입력 또는 연동

• 현금
• 주식
• ETF
• 안전자산
• 자녀 계좌 잔고
• Mock 데이터 활용 가능
• 추후 증권 API 연동 가능

3. 목표 달성 시뮬레이션

• 월 적립액
• 예상 수익률
• 목표 기간
• 목표 달성 가능성
• 안전자산 비율
• 위험자산 비율

4. 포트폴리오 분석

• 종목 담기
• 비중 조절
• 예상 수익률
• 변동성 비교
• 최선 시나리오
• 보통 시나리오
• 최악 시나리오

5. 증여 가이드

• 미성년 자녀 증여 한도 안내
• 최근 증여 내역 입력
• 남은 비과세 가능 금액 계산
• 매월 적립식 증여 시뮬레이션
• 증여 신고 필요 여부 안내
• 홈택스 신고 가이드
• 부모 명의 돈과 자녀 명의 돈 구분 설명

6. 차트

• 자산 성장 예상 그래프
• 자산 비중 파이차트
• 목표 달성률 그래프
• 보유 종목 수익률 그래프
• 투자손익 그래프

13. 자녀 자산 관리 대시보드

우리 서비스에서 가장 중요한 화면 중 하나는 자녀 자산 관리 대시보드라고 생각했다.

삼성증권이나 든든의 자녀 잔고 관리 기능을 참고하되, 우리는 목표 금액과 목표 달성률을 더 강조하면 차별화될 수 있다고 보았다.

이 화면에서는 단순히 현재 자산을 보여주는 것이 아니라, 부모가 바로 다음 행동을 할 수 있도록 안내해야 한다고 생각했다.

예를 들면 다음과 같은 문구를 넣을 수 있다.

현재 목표의 35%를 달성했어요.
남은 기간 동안 매달 12만 원씩 투자하면 목표 금액에 가까워질 수 있어요.

14. 아동수당 자동 굴리기

조사 과정에서 가장 괜찮다고 느낀 아이디어는 아동수당 자동 굴리기였다.

전에도 이 생각을 하여 팀원들에게 공유를 했었었다. 하지만 이 부분에서 팀원들과의 의견 차이가 있어 기각이 되어 나중에 고도화로 넣기로 했었다.

매월 지급되는 아동수당이나 부모급여를 생활비로 자연스럽게 써버리는 것이 아니라, 자녀의 장기 자산으로 전환하는 구조다.

서비스 문구 예시

이번 달 아동수당 10만 원이 아이의 미래 자산으로 투자되었어요.
지금까지 모은 아동수당은 목표 금액의 4%예요.

이 기능은 부모가 별도로 신경 쓰지 않아도 자녀 자산이 자동으로 쌓인다는 점에서 강점이 있다.

또한 신한은행과 신한투자증권을 연결하는 복합 금융 시나리오로도 적합하다고 생각했다.

15. 인앱 범위에 대한 고민

조사를 하면서 한 가지 고민도 생겼다.

우리 서비스가 정확히 어디에 위치하는지에 따라 제공해야 할 정보량이 달라질 수 있기 때문이다.

고민 지점

• 슈퍼쏠 안의 서비스인가
• 신한투자증권 앱 안의 서비스인가
• 슈퍼쏠의 신투 탭 안에 들어가는 서비스인가
• 매수·매도까지 우리 서비스에서 하는가
• 아니면 신한투자증권으로 연결만 하는가
• 실시간 시세를 보여줄 필요가 있는가
• 코스피·ETF 차트까지 제공해야 하는가

만약 신한투자증권 앱 내부 서비스라면, 이미 시세나 종목 정보가 제공되기 때문에 중복된 정보를 많이 보여줄 필요는 없을 수 있다.

반면 슈퍼쏠 안의 인앱 서비스라면, 신한투자증권 앱으로 계속 이동하는 것이 번거로울 수 있기 때문에 최소한의 자산 현황, 수익률, 차트 정보는 제공하는 것이 좋을 수 있다.

그래서 MVP에서는 매수·매도 기능보다는 다음 정보에 집중하는 것이 적절하다고 생각했다.

• 자녀 자산 현황
• 목표 달성률
• 투자손익
• 수익률
• 자산 성장 그래프
• 증여 한도
• 신한투자증권 연결

18. 최종적으로 정리한 서비스 구조

조사 후 우리 서비스는 다음 흐름으로 정리할 수 있었다.

자녀 등록
→ 목표 금액 설정
→ 현재 자산 확인
→ 부족 금액 계산
→ 월 적립액 제안
→ ETF 투자 시뮬레이션
→ 증여 한도 확인
→ 자녀 자산 대시보드 관리
→ 성장 기록과 함께 자산 전달

이 흐름에서 가장 중요한 것은 목표 기반 관리라고 생각했다.

기존 서비스들이 자녀 계좌 개설, 잔고 확인, 증여 기능을 제공한다면, 우리 서비스는 여기에 목표 금액과 부족분 계산을 더해 부모의 불안감을 줄이는 방향으로 차별화할 수 있다.

19. 회고

이번 조사를 하면서 느낀 점은, 자녀 금융 서비스에서 증권, 증여, 아동수당은 거의 분리해서 보기 어렵다는 것이었다.

자녀 명의 계좌를 만들면 자연스럽게 투자와 증여 문제가 따라오고, 아이가 어릴수록 아동수당이나 부모급여를 어떻게 활용할지에 대한 고민도 함께 생긴다.

또한 단순히 “자녀 계좌를 만들어주세요”에서 끝나는 서비스는 이미 많이 존재했다.

그래서 우리 서비스는 다음 질문에 더 집중해야 한다고 생각했다.

부모가 아이의 미래 자산을 준비할 때, 가장 불안해하는 지점은 무엇인가?

그 답은 다음과 같았다.

• 얼마를 모아야 하는지 모름
• 지금 준비가 충분한지 모름
• 투자 손실이 두려움
• 증여세가 어려움
• 아동수당을 어떻게 활용할지 모름
• 자녀 자산을 장기적으로 관리하는 방법을 모름

결국 우리 서비스의 핵심은 단순한 계좌 개설이나 금융상품 추천이 아니라,

부모가 아이의 미래 자산을 목표 기반으로 준비하고, 투자와 증여를 기록하며, 장기적으로 관리할 수 있도록 돕는 것

이라고 정리할 수 있었다.

지난 글에서는 기말 프로젝트 팀빌딩 과정에서 여러 아이디어 중 아이 미래 자산 구축 서비스를 선택하게 된 과정을 정리했다.

이번 글에서는 선택한 아이디어를 바탕으로 서비스를 어떻게 구체화했는지, 그리고 은행·증권사·육아 서비스 분석을 통해 어떤 방향을 잡았는지 정리해보려고 한다.

1. 서비스 방향

아이디어를 구체화하면서 가장 먼저 잡은 목표는 다음과 같았다.

우리 아이, 부끄럽지 않게 키우자

처음에는 감성적인 문장이었지만, 우리가 해결하고 싶은 문제를 잘 담고 있다고 생각했다.

부모는 아이가 태어난 순간부터 미래를 걱정한다.
교육비, 입학 준비금, 대학 등록금, 독립 자금처럼 당장은 보이지 않지만 언젠가 반드시 필요한 돈이 있기 때문이다.

그래서 우리 서비스는 단순히 돈을 모아주는 서비스가 아니라, 부모가 느끼는 막연한 불안감을 줄이고 자녀의 미래 자산을 장기적으로 준비할 수 있도록 돕는 서비스로 방향을 잡았다.

2. 서비스 목적

우리 서비스의 목적은 크게 두 가지였다.

정리하면 다음과 같다.

고객의 금융 니즈를 발견하고 금융상품과 연결하는 서비스

조금 더 구체적으로는,

아이 미래 자산을 부모가 장기적으로 준비하고 기록하는 서비스

라고 정의할 수 있었다.

기존 육아 서비스들은 임신, 출산, 육아 기록, 성장 정보 제공에 강점이 있었다.
하지만 아기가 태어난 이후 아이의 미래 자산을 어떻게 준비할지에 대한 금융 흐름은 상대적으로 부족하다고 느꼈다.

우리는 이 지점에서 기회를 발견했다.

3. 고객 사이클

부모가 자녀의 미래 자산을 준비하는 과정을 하나의 사이클로 정리했다.

예측한다
→ 부족분을 발견한다
→ 준비 방법을 계획한다
→ 실행한다
→ 기록한다
→ 아이에게 넘긴다

각 단계는 다음과 같이 정의했다.

이 흐름을 바탕으로 우리 서비스는 단순한 투자 앱이 아니라, 부모가 아이의 미래를 준비하는 과정을 함께 관리하는 서비스가 되어야 한다고 생각했다.

4. 타겟 고객

우리가 생각한 핵심 타겟은 다음과 같았다.

페르소나는 다음과 같이 정리했다.

아이가 태어난 뒤 자녀의 미래 자금을 준비하고 싶지만, 어디서부터 시작해야 할지 막막한 주식 초보 부모

이 고객은 다음과 같은 고민을 가지고 있다고 보았다.

• 아이를 위해 얼마를 모아야 할까?
• 매달 얼마씩 준비해야 할까?
• 저축만 해도 괜찮을까?
• ETF 투자를 해도 괜찮을까?
• 증여세는 어떻게 관리해야 할까?
• 다른 부모들은 어느 정도 준비하고 있을까?

5. 은행 서비스 분석

아이디어를 구체화하기 위해 먼저 은행 앱의 자산 관리, 소비 분석, 목표 설정 기능을 분석했다.

은행 앱들은 이미 자산과 소비를 잘 보여주고 있었다.
하지만 대부분은 나의 자산과 나의 소비 중심이었다.

우리가 만들고 싶은 서비스처럼 자녀의 미래 자산을 중심으로 목표 설정, 투자, 증여까지 연결하는 흐름은 상대적으로 부족하다고 느꼈다.

6. 은행별 분석 정리

하나은행

• 자산 현황 분석
• 월별 자산 변동
• 금융자산 구성
• 실물자산 구성
• 대출 현황
• 계좌별 자금 흐름
• 입출금 요약
• 잔액 변화
• 예상 고정비

우리은행

• 자산 관리
• 소비 관리
• 달력형 지출 확인
• 지출 목표 설정
• 예산 관리
• 소비 카테고리 분석
• 소비 리포트
• 스파이더맵 기반 소비 비교

신한은행

• 총자산 확인
• 쓸 수 있는 돈
• 페이·포인트
• 모으는 돈
• 불리는 돈
• 또래 자산 비교
• 기관별 자산 확인
• 가계부 기능

농협은행

• 예산으로 한 달 살기
• 자산 목표 설정
• 목적별 목표 설계
• 자녀 교육비 목표
• 자녀 등록금 목표
• 정기지출 확인
• 구독 서비스 확인
• 투자 밸런스 진단
• 또래 비교

7. 은행 서비스에서 참고한 점

은행 서비스 분석을 통해 우리 서비스에 적용할 수 있는 요소를 정리했다.

특히 중요하다고 생각한 부분은 소비 분석과 목표 설정의 연결이었다.

부모가 막연히 돈을 모으는 것이 아니라, 실제 소비 패턴을 보고 매달 얼마를 투자할 수 있을지 안내하는 구조가 필요하다고 보았다.

8. 증권사 및 금융 서비스 분석

다음으로 증권사와 관련 금융 서비스를 분석했다.

기존 서비스들은 대부분 미성년 계좌 개설, 자녀 대상 금융상품, 적립식 증여, 투자 정보 제공에 집중되어 있었다.

우리가 만들고 싶은 서비스는 단순히 계좌를 개설하거나 상품을 추천하는 것이 아니었다.
부모가 목표를 세우고, 아이의 성장 과정에 맞춰 자산을 준비하고, 투자 이유와 기록까지 남길 수 있는 구조를 만들고 싶었다.

9. 증권사별 분석 정리

한화생명 파이

• 자녀 중심 금융 서비스
• 육아 고객 타겟
• 보험·금융 결합
• 아이 성장 기반 금융 경험
• 가족 단위 금융 관리

나무증권

• 우리아이 주식계좌
• 미성년 자녀 계좌 개설
• 자녀 명의 투자 시작
• 계좌 개설 중심 서비스
• 주식 투자 진입 지원

삼성증권

• 적립식 증여 서비스
• 정기 증여 관리
• 증여 절차 간소화
• 세금 부담 완화
• 장기 증여 구조

미래에셋증권

• 자산관리 콘텐츠
• 투자 정보 제공
• 장기 투자 안내
• 리치 서비스
• 투자 교육 콘텐츠

신한투자증권

• 미성년 계좌 개설
• 자녀 고객 유입
• 증권 계좌 개설 이벤트
• 신한은행 연계 가능성
• 신한금융그룹 내 확장 가능성

우체국 마미든든 적금

• 육아 고객 대상 적금
• 금리 혜택
• 안정형 상품
• 저축 중심 서비스
• 부모 타겟 금융상품

10. 증권사 분석을 통해 느낀 점

증권사와 금융 서비스들을 분석해보니 기존 서비스들은 대부분 다음 중 하나에 가까웠다.

• 미성년 계좌 개설
• 계좌 개설 이벤트
• 금융상품 가입
• 적립식 증여
• 투자 정보 제공
• 자녀 대상 적금
• 자녀 대상 펀드

하지만 우리가 만들고 싶은 서비스는 조금 달랐다.

단순히 계좌를 만들게 하는 것이 아니라, 부모가 아이의 미래 목표를 설정하고 그 목표를 달성하기 위해 은행 계좌, 증권 계좌, ETF 투자, 증여 관리를 하나의 흐름으로 경험하게 만드는 것이 핵심이었다.

11. 육아 서비스 분석

육아 서비스도 함께 분석했다.

마미톡이나 토스의 육아 관련 서비스들은 임신, 출산, 육아 기록, 성장 정보 제공에 강점이 있었다.

육아 서비스 기능 유형

• 수유 기록
• 배변 기록
• 수면 기록
• 성장일기
• 발달 체크
• 아이 성장 확인
• 어린이집 찾기
• 응급실 정보
• 대기질 리포트
• 성장 앨범
• 아이 사진관
• 아이 얼굴 예측
• 자녀 지원금 확인
• 바우처 계산
• 육아 상담
• 부모 감정 기록

육아 서비스들은 아이의 현재를 기록하는 데 강점이 있었다.

하지만 아이가 태어난 뒤 발생하는 아동수당, 부모급여, 자녀 명의 자산을 어떻게 관리하고 장기 자산으로 전환할지에 대한 금융 흐름은 부족하다고 느꼈다.

그래서 우리는 다음과 같이 차별점을 잡았다.

육아 서비스가 아이의 오늘을 기록한다면,
우리의 서비스는 아이의 미래 자산을 기록한다.

12. 핵심 기능 정리

경쟁사 분석을 바탕으로 핵심 기능을 세 가지로 나누었다.

핵심 기능 1. 목표 설정

가장 먼저 필요한 기능은 목표 설정이었다.

부모는 아이를 위해 돈을 모아야 한다는 것은 알지만, 얼마를 목표로 잡아야 할지 모르는 경우가 많다.

그래서 온보딩에서 다음 정보를 입력받는 구조를 생각했다.

• 아이 정보
• 목표 자금
• 목표 시점
• 현재 준비 금액
• 월 적립 가능 금액
• 투자 성향
• 부모 자산 정보
• 부모 소비 정보

이를 바탕으로 다음 정보를 제공할 수 있다.

예상 문구는 다음과 같다.

현재 목표의 27%를 준비했어요.
매달 10만 원씩 투자하면 목표 시점에 가까워질 수 있어요.

핵심 기능 2. 지출 관리

두 번째 핵심 기능은 지출 관리였다.

아이 미래 자산을 준비하려면 부모가 매달 얼마를 투자할 수 있는지 알아야 한다.

그래서 마이데이터 API 또는 Mock 데이터를 활용해 소비 패턴을 분석하고, 투자 가능 금액을 추천하는 구조를 생각했다.

지출 관리 기능

• 월별 소비금액 동향
• 소비 카테고리 Top 5
• 분야별 소비 내역
• 고정비 확인
• 과소비 내역 점검
• 소비 성향 분석
• 이번 달 소비 평가
• 투자 가능 금액 추천

예를 들어 다음과 같은 피드백을 줄 수 있다.

최근 3개월 동안 외식비가 꾸준히 증가했어요.
이번 달 외식비를 3만 원만 줄이면 아이 목표 자금에 추가로 투자할 수 있어요.

이 기능은 단순한 가계부가 아니라, 부모의 소비를 아이의 미래 자산 준비와 연결하는 역할을 한다.

핵심 기능 3. 자녀 미래 자산 로드맵

세 번째 핵심 기능은 자녀 미래 자산 로드맵이었다.

로드맵은 단기, 중기, 장기 목표를 나누어 관리하는 방식으로 생각했다.

이렇게 나누면 부모가 모든 돈을 한 번에 준비해야 한다는 부담을 줄일 수 있다.

또한 목표 기간에 따라 안전자산과 위험자산 비율을 다르게 안내할 수 있다.

13. 투자 관련 기능

아이 미래 자산 서비스에서 증권은 핵심 역할을 한다.

투자 기능은 크게 두 가지로 나누어 생각했다.

14. 목표 달성 포트폴리오

주식이나 ETF 투자가 익숙하지 않은 부모에게 가장 큰 걱정은 손실 가능성이다.

그래서 상품을 단순 추천하는 것이 아니라, 목표 달성을 위한 포트폴리오 시뮬레이션 기능을 생각했다.

주요 기능

• 주식·ETF 검색
• 관심 종목 담기
• 안전자산·위험자산 비율 조정
• 목표 기간별 예상 수익률 확인
• 최고·최저 예상 결과 비교
• 변동성 리포트 제공
• 투자 위험성 안내

이 기능의 목적은 높은 수익률을 약속하는 것이 아니다.

부모가 투자 위험을 이해하고, 자신의 목표와 성향에 맞는 장기 투자 방식을 선택할 수 있도록 돕는 것이다.

15. 아기 주식 수첩

감성적으로 가장 중요하다고 생각한 기능은 아기 주식 수첩이었다.

부모가 아이를 위해 주식이나 ETF를 매수할 때, 단순히 거래 내역만 남기는 것이 아니라 왜 이 주식을 샀는지, 어떤 마음으로 샀는지를 함께 기록하는 기능이다.

주요 기능

• 투자 메시지 작성
• 아이 성장 사진 첨부
• 매수 종목 자동 기록
• 매수 수량 자동 기록
• 매수 금액 자동 기록
• 메시지 없는 거래 알림
• 양육자 공동 확인

예시 기록은 다음과 같다.

2026년 5월, 첫 걸음마 기념
오늘은 네가 처음으로 걸은 날이야.
이 순간을 기억하고 싶어서 10,000원을 투자했어.

이 기능은 투자 기록을 넘어, 아이가 성장했을 때 부모의 마음과 금융 기록을 함께 볼 수 있게 해준다.

16. 증여 비과세 한도 자동 추적

자녀 명의로 돈을 모으거나 투자할 때 중요한 문제 중 하나는 증여다.

부모 입장에서는 아이에게 돈을 모아주고 싶지만, 증여세나 신고 절차가 어렵게 느껴질 수 있다.

그래서 증여 비과세 한도를 자동으로 추적하는 기능을 생각했다.

주요 기능

• 10년 단위 누적 증여액 추적
• 미성년 자녀 기준 비과세 한도 게이지
• 한도 80% 도달 시 사전 알림
• 증여세 신고 기간 안내
• 증여세 신고 방법 안내
• 세무사 연결 옵션
• 연간 투자 내역 PDF 생성

이 기능은 부모가 느끼는 세금에 대한 불안감을 줄이는 데 도움이 될 수 있다고 생각했다.

17. 아동수당 자동 굴리기

아이 미래 자산 서비스에서 가장 매력적인 시나리오 중 하나는 아동수당 자동 굴리기였다.

매월 들어오는 아동수당이나 부모급여를 생활비로 자연스럽게 써버리는 것이 아니라, 아이의 장기 자산으로 전환하는 구조다.

아동수당 입금
→ 신한은행 계좌 감지
→ 신한투자증권 계좌로 이동
→ ETF 자동 투자
→ 누적 자산 리포트 제공

예상 문구는 다음과 같다.

이번 달 아동수당 10만 원이 아이의 미래 자산으로 투자되었어요.
지금까지 모은 아동수당은 목표 금액의 4%예요.

이 기능은 부모가 따로 신경 쓰지 않아도 아이의 미래 자금이 자동으로 쌓이는 구조라는 점에서 의미가 있었다.

18. 후순위 기능

아이디어를 구체화하다 보니 하고 싶은 기능이 많아졌다.

하지만 프로젝트 기간이 제한되어 있기 때문에 우선순위를 나누는 것이 필요했다.

후순위 기능

• 정부 지원금 리스트
• 육아휴직 월급 계산기
• 금융상품 추천
• 신용카드 혜택 추천
• 보험상품 추천
• 공동 육아 펀드
• 익명 부모 코호트 비교
• 증여 관련 QnA
• 생애주기별 금융 팁
• 감성 알림 시스템
• AI 미래 이미지 생성
• 아이 용품 중고거래
• 아이 용품 쇼핑몰
• 과소비 탐지
• 가계부 기능

이 중 일부 기능은 매력적이었지만, MVP에는 적합하지 않다고 판단했다.

특히 커뮤니티, 중고거래, 쇼핑몰 기능은 서비스 범위가 너무 넓어질 수 있어 후순위로 두었다.

19. MVP 방향

최종적으로 MVP에서는 가장 핵심적인 흐름만 남기기로 했다.

온보딩
→ 아이 정보 등록
→ 목표 자금 설정
→ 월 적립 금액 계산
→ ETF 투자 계획 확인
→ 증여 한도 확인
→ 자산 성장 기록

MVP에서 중요한 것은 모든 기능을 구현하는 것이 아니라, 부모가 자녀 미래 자산을 준비하는 핵심 경험을 완성하는 것이라고 생각했다.

20. 우리 서비스의 차별점

경쟁사 분석을 통해 우리 서비스의 차별점도 정리할 수 있었다.

결국 우리가 만들고 싶은 서비스는 단순한 금융상품 추천 앱이 아니었다.

아이의 미래 자산을 부모가 장기적으로 준비하고 기록하는 서비스

이 문장이 가장 잘 맞는다고 생각했다.

21. 회고

아이디어를 구체화하면서 느낀 점은, 서비스 기획은 하고 싶은 기능을 많이 떠올리는 것보다 무엇을 하지 않을지 정하는 과정이 더 어렵다는 것이다.

처음에는 목표 설정, 소비 분석, 투자 시뮬레이션, 아기 주식 수첩, 증여 관리, 정부 지원금, 공동 펀드, QnA, 중고거래까지 다양한 기능을 떠올렸다.

하지만 모든 기능을 한 번에 담으면 서비스의 핵심이 흐려질 수 있다고 생각했다.

그래서 다시 처음 질문으로 돌아갔다.

이 서비스는 누구의 어떤 불안을 해결하는가?

우리의 답은 부모의 불안감이었다.

부모는 아이의 미래를 위해 무언가를 준비해야 한다는 것을 알지만, 얼마를 모아야 하는지, 어떻게 투자해야 하는지, 세금은 어떻게 관리해야 하는지 막막함을 느낀다.

우리는 이 불안감을 줄이기 위해 목표를 설정하고, 부족분을 발견하고, 실행 방법을 제안하고, 투자와 증여를 기록하는 서비스를 만들고자 했다.

앞으로는 이 방향을 바탕으로 실제 페르소나를 더 구체화하고, 사용자가 처음 서비스를 접했을 때 어떤 흐름으로 목표 설정까지 도달하게 할지 고민해보려고 한다.

기능은 정상적으로 동작했지만,
사용자가 실패했을 때 다시 시도할 수 있는지는 따로 고민해야 했다.

아이든든 프로젝트를 진행하면서 가장 많이 느낀 점은
실제 서비스 개발은 단순히 API가 성공하는지만 확인해서는 부족하다는 것이었다.

회원가입, 온보딩, 자녀 등록, 아동수당 연결, 증여 계약, ETF 증여, 배포 환경까지
각 기능은 따로 존재하는 것처럼 보이지만 실제 사용자 흐름에서는 모두 연결되어 있었다.

회원가입
→ 온보딩
→ 자녀 등록
→ 아동수당 연결
→ 증여 계약 생성
→ ETF 투자 관리
→ 목표 달성률 확인

그래서 하나의 기능에서 예외가 발생하면, 단순히 “에러 메시지를 보여준다”로 끝나지 않았다.
사용자가 다시 시도할 수 있는지, 어디서부터 이어갈 수 있는지, 이미 저장된 데이터와 충돌하지 않는지를 함께 고민해야 했다.

이번 글에서는 아이든든 프로젝트를 진행하면서 마주했던 트러블슈팅 중
사용자 흐름, 예약 데이터, 금융성 데이터, 성능 측정과 관련된 이슈들을 정리해보려고 한다.

1. 회원가입 중 자녀 등록 실패 시 재시도할 수 없었던 문제

문제 상황

초기 온보딩 흐름은 부모 계정 생성과 자녀 등록이 하나의 흐름으로 이어져 있었다.

부모 정보 입력
→ 자녀 정보 입력
→ 회원가입 API 호출
→ 자녀 등록 API 호출

겉으로 보기에는 자연스러운 흐름이었다.

부모가 서비스를 이용하려면 자녀 정보가 필요하고,
아이든든은 자녀의 미래 자금을 관리하는 서비스이기 때문에 회원가입 과정에서 자녀 정보까지 받는 것이 당연해 보였다.

하지만 실제 테스트를 하면서 문제가 발생했다.

부모 계정 생성은 성공했는데, 이후 자녀 등록 API에서 실패하는 경우였다.

부모 계정 생성 성공
→ 자녀 등록 실패
→ 사용자가 처음부터 다시 시도
→ 이미 생성된 이메일이라 중복 오류 발생

사용자 입장에서는 회원가입이 실패한 것처럼 보이지만,
서버에는 이미 부모 계정이 생성되어 있었다.

그래서 다시 처음부터 시도하면 이메일 중복 오류가 발생했다.

원인

문제의 핵심은 부모 계정 생성과 자녀 등록을 하나의 필수 흐름처럼 처리했다는 점이었다.

하지만 실제로 두 작업은 성격이 다르다.

부모 계정 생성은 반드시 필요하지만,
자녀 등록은 실패하더라도 나중에 다시 등록할 수 있어야 했다.

즉, 자녀 등록 실패가 회원가입 전체 실패로 이어지면 안 되는 구조였다.

검토한 선택지

A안. 부모 정보 입력 완료 시점에 회원가입 처리

부모 정보 입력
→ 회원가입 성공
→ 자동 로그인
→ 자녀 등록

이 방식의 장점은 부모 계정이 생성된 이후 자녀 등록에 실패하더라도 다시 시도할 수 있다는 점이다.

하지만 단점도 있었다.

자녀가 없는 상태로 앱에 진입할 수 있기 때문에,
앱 전체에서 자녀 미등록 상태를 고려해야 한다.

홈 화면
→ 등록된 자녀 없음

증여 화면
→ 자녀 등록 필요

목표 설정
→ 자녀 등록 후 이용 가능

즉, 프론트와 백엔드 모두 “자녀가 아직 없는 사용자”를 정상 상태로 처리해야 했다.

B안. 자녀 등록 실패를 허용하고 앱 진입

회원가입 성공
→ 자녀 등록 시도
→ 실패해도 앱 진입
→ 자녀는 나중에 등록

이 방식은 자녀 등록 실패 때문에 회원가입 전체가 막히지 않는다.

회원가입은 성공한 것으로 보고,
자녀 정보는 앱 내부에서 다시 등록할 수 있게 하는 방식이다.

해결 방향

최종적으로는 B안이 더 현실적이라고 판단했다.

자녀 정보 화면에 나중에 하기 버튼을 추가하고,
자녀 등록 실패 시에도 앱 진입이 가능하도록 설계하는 방향이 더 자연스러웠다.

signup 성공
→ 자동 로그인
→ 자녀 등록 시도
→ 성공 또는 실패
→ 다음 단계 진행
→ 자녀는 앱 내에서 추가 가능

이 구조에서는 자녀 등록이 실패하더라도 사용자는 서비스를 완전히 다시 시작하지 않아도 된다.

정리

회원가입 과정에서 모든 정보를 반드시 한 번에 받으려고 하면 실패 복구가 어려워진다.

필수 정보와 나중에 입력해도 되는 정보를 구분해야 한다.

특히 온보딩처럼 여러 단계를 거치는 흐름에서는
각 단계가 실패했을 때 사용자가 어디서부터 다시 시작할 수 있는지 설계하는 것이 중요했다.

2. 온보딩 중 새로고침 시 입력값이 사라지는 문제

문제 상황

온보딩 단계에서 부모 정보, 자녀 정보 등을 입력하던 중 새로고침하면 입력값이 모두 사라지는 문제가 있었다.

사용자는 여러 단계를 거쳐 정보를 입력하고 있었는데,
중간에 새로고침이 발생하면 처음부터 다시 입력해야 했다.

부모 정보 입력
→ 자녀 정보 입력 중
→ 새로고침
→ 입력값 초기화

원인

온보딩 데이터가 React 메모리 상태로만 관리되고 있었기 때문이다.

React state는 페이지가 유지되는 동안에는 값을 보관하지만,
새로고침이 발생하면 초기화된다.

React state
→ 페이지 새로고침 시 초기화

고민했던 선택지

처음에는 sessionStorage에 온보딩 입력값을 저장하는 방법을 고려했다.

부모 정보 입력
→ sessionStorage 저장
→ 새로고침
→ 저장된 값 복구

이 방식은 사용자 경험 측면에서는 좋다.

하지만 민감한 정보나 계좌 관련 정보가 포함될 수 있기 때문에
브라우저 저장소에 어떤 데이터를 저장할지 신중히 정해야 했다.

해결 방향

MVP에서는 온보딩 중 새로고침 시 처음부터 다시 입력하는 것으로 두되,
이미 로그인 토큰이 있는 경우에는 홈으로 이동하도록 가드 처리하는 방향이 더 단순하다고 판단했다.

새로고침 발생
→ 토큰 있음
→ 이미 가입된 사용자로 판단
→ 홈으로 이동

토큰 없음
→ 온보딩 처음부터 시작

즉, 모든 입력값을 복구하기보다는
현재 서비스 단계에서는 흐름을 단순하게 유지하는 쪽을 선택했다.

정리

온보딩처럼 여러 페이지를 거치는 흐름은 새로고침과 중간 이탈 상황을 반드시 고려해야 한다.

입력값을 유지할지, 다시 시작하게 할지 정책을 명확히 정해야 한다.

특히 브라우저 저장소를 사용할 경우, 편의성과 보안 사이의 균형도 함께 고려해야 했다.

3. 아동수당 연결과 해지 흐름은 같은 화면에 있어야 할까?

문제 상황

아이든든에는 아동수당을 자녀 계좌와 연결하는 흐름이 있었다.

초기에는 아동수당 “연결”만 고려했다.

하지만 이미 연결된 자녀가 있는 경우,
사용자가 연결을 해지할 수 있어야 하는지도 고민이 생겼다.

아동수당 연결 가능
→ 이미 연결된 상태
→ 해지는 어디서 하지?

초기 설계에는 해지 API나 해지 UI가 없었다.

연결과 해지는 같은 기능일까?

처음에는 연결 화면에서 해지도 같이 제공하면 되지 않을까 생각했다.

하지만 사용자 흐름을 다시 생각해보니 연결과 해지는 성격이 달랐다.

연결은 사용자가 서비스를 시작하는 과정에서 자연스럽게 유도할 수 있다.

반면 해지는 이미 연결된 설정을 끊는 행위이므로,
온보딩 화면보다는 마이페이지나 설정 화면에서 관리하는 것이 더 자연스럽다고 판단했다.

검토한 선택지

A안. 아동수당 연결 페이지에서 해지까지 제공

아동수당 연결 페이지
→ 연결된 자녀 표시
→ 해지 버튼
→ 확인 모달
→ 해지 API 호출

이 방식은 사용자가 연결 상태를 바로 관리할 수 있다는 장점이 있다.

하지만 연결을 유도하는 페이지 안에 해지 액션까지 있으면 화면 목적이 흐려질 수 있다.

B안. 해지는 마이페이지에서 관리

아동수당 연결 페이지
→ 연결만 가능

마이페이지
→ 자녀 정보
→ 아동수당 연결 관리
→ 해지

이 방식은 화면의 역할이 더 명확하다.

연결 페이지는 연결을 돕고,
마이페이지는 이미 연결된 정보를 관리한다.

해결 방향

최종적으로는 해지를 마이페이지에서 처리하는 것이 더 자연스럽다고 판단했다.

다만 백엔드에는 추후 다음과 같은 API가 필요하다고 정리했다.

DELETE /children/{childId}/allowance

또는 상태 변경의 의미를 더 명확히 하려면 다음 방식도 가능하다.

PATCH /children/{childId}/allowance/disconnect

정리

연결과 해지는 같은 기능처럼 보이지만, 사용자 흐름은 다르다.

연결은 온보딩에서 자연스럽지만,
해지는 설정이나 마이페이지에서 관리하는 것이 더 적절할 수 있다.

4. 다자녀 상황을 고려한 아동수당 연결 UI

문제 상황

초기에는 단일 자녀를 기준으로 아동수당 연결 화면을 생각했다.

하지만 실제 서비스에서는 자녀가 여러 명일 수 있다.

첫째
둘째
셋째

이 경우 아동수당을 어떤 자녀에게 연결할지 선택할 수 있어야 했다.

해결 방향

아동수당 연결 화면에서 자녀 목록을 카드 형태로 보여주고,
사용자가 연결할 자녀를 선택할 수 있도록 설계했다.

[선택됨] 자녀 1 카드
[선택됨] 자녀 2 카드

→ 연결하기

기본값은 모든 자녀 선택으로 두었다.

이유는 아동수당 연결 흐름에서 사용자가 특정 자녀만 제외해야 하는 경우보다,
등록된 자녀 전체를 연결하려는 경우가 더 일반적이라고 판단했기 때문이다.

정리

자녀 관련 서비스는 다자녀 케이스를 초기에 고려해야 한다.

단일 자녀 기준으로 설계하면 나중에 UI와 API 흐름을 다시 수정해야 한다.

특히 자녀를 기준으로 계좌, 증여, 목표, 아동수당이 모두 연결되는 서비스에서는
처음부터 다자녀 구조를 고려하는 것이 중요했다.

5. 예약된 증여 계약을 볼 수 없었던 문제

문제 상황

적립식 증여를 등록하면 예약된 이체가 생성된다.

하지만 화면에서는 완료된 증여 내역만 보여주고 있었다.

const completed = all.filter((t) => t.status === 'COMPLETED');
setGiftTransfers(completed);

이 때문에 적립식 증여를 등록해도
실제 이체가 완료되기 전까지 사용자가 어디에서도 확인할 수 없었다.

적립식 증여 등록 완료
→ 예약된 이체 생성
→ 화면에는 완료 내역만 표시
→ 사용자는 등록이 제대로 되었는지 확인하기 어려움

원인

문제는 증여 내역과 증여 계약을 구분하지 않았다는 점이었다.

GiftTransfer
→ 실제 이체 내역

GiftContract
→ 증여 계약 또는 예약

완료된 이체만 보여주면 사용자는 이미 끝난 내역만 확인할 수 있다.

하지만 금융 서비스에서는 완료된 내역만큼이나
앞으로 발생할 예약 내역도 중요하다.

해결 방향

화면에서 완료된 이체 내역과 진행 중인 증여 계약을 분리해서 보여줄 필요가 있었다.

1안. 증여 현황 섹션에 탭 추가

[완료 내역] [예약/진행 중]

완료된 이체와 예약된 이체를 같은 화면 안에서 탭으로 구분하는 방식이다.

2안. 진행 중인 증여 계약 별도 섹션 추가

진행 중인 증여 계약

- 매달 용돈
- 매월 15일
- 다음 이체일: 2026-07-15
- 취소 버튼

홈 화면이나 증여 현황 화면에서 진행 중인 계약을 따로 보여주는 방식이다.

3안. 별도 증여 계약 관리 페이지 생성

내 증여 계약 관리
→ 진행 중
→ 완료
→ 취소됨

계약 단위로 관리할 수 있는 별도 페이지를 두는 방식이다.

API 방향

이미 백엔드에서는 다음 형태의 API를 사용할 수 있었다.

GET /children/{childId}/gift-contracts
PATCH /gifts/contracts/{contractId}/cancel

따라서 프론트에서는 GiftTransfer만 조회하는 것이 아니라,
GiftContract 목록도 함께 보여주는 구조가 필요했다.

정리

예약/진행 중인 데이터와 완료된 히스토리는 다른 성격의 데이터다.

금융 서비스에서는 사용자가 앞으로 발생할 예약 내역을 반드시 확인할 수 있어야 한다.

특히 적립식 증여처럼 미래에 실행될 계약은
“등록 완료” 이후에도 사용자가 상태를 확인하고 취소할 수 있어야 했다.

6. ETF 증여 예상금액과 최종금액 계산 방식

문제 상황

ETF 증여에서는 증여 금액을 어떻게 계산할지 고민이 필요했다.

현금 증여는 금액이 명확하다.

현금 500,000원 증여
→ 증여 금액 500,000원

하지만 ETF는 가격이 계속 변한다.

ETF 5주 증여
→ 1주당 가격이 매일 변동
→ 어떤 가격을 기준으로 증여 금액을 계산할까?

현재 구현 방식

ETF 증여는 국세청 상장주식 평가 방식에 맞춰 다음 기준을 따르도록 설계했다.

평가기준일 = 증여일
예상금액 = 증여일 전후 2개월 종가 평균 × 수량
최종금액 = 증여일 이후 2개월 데이터까지 확보된 뒤 확정

다만 증여 직후에는 미래 2개월 데이터가 없다.

따라서 바로 최종금액을 확정할 수 없고,
우선 예상금액만 제공한다.

증여 직후
→ estimatedGiftAmount 표시

증여일 + 2개월 이후
→ finalGiftAmount 확정 가능

Lazy 계산 방식

현재는 스케줄러가 아니라 lazy 방식으로 구현되어 있다.

사용자가 계약 상세 조회
→ valuationBaseDate + 2개월 <= 오늘인지 확인
→ 확정 가능하면 최종금액 계산
→ DB 저장

즉, 누군가 상세 화면을 열어봐야 최종금액이 계산된다.

이 방식은 구현이 단순하다.

하지만 단점도 있다.

사용자가 상세 화면을 보지 않음
→ finalGiftAmount가 계속 미확정 상태로 남을 수 있음

개선 방향

금융 데이터처럼 확정 시점이 중요한 값은
스케줄러를 통해 자동으로 갱신하는 방식도 고려해야 한다.

예를 들어 매일 새벽 1시에 미확정 ETF 증여 계약을 조회하고,
최종금액 확정이 가능한 계약을 처리할 수 있다.

@Scheduled(cron = "0 0 1 * * *")
public void resolveFinalGiftAmounts() {
    ...
}

흐름은 다음과 같다.

매일 01:00 스케줄러 실행
→ finalGiftAmount가 null인 ETF 증여 계약 조회
→ valuationBaseDate + 2개월 <= 오늘인지 확인
→ 종가 데이터 조회
→ 최종 증여 금액 계산
→ finalGiftAmount 저장

정리

Lazy 계산은 구현이 단순하지만, 사용자가 조회하지 않으면 데이터가 갱신되지 않는다.

확정 시점이 중요한 금융 데이터는
사용자 조회와 관계없이 스케줄러로 자동 확정하는 방식도 고려해야 했다.

전체 회고

이번 트러블슈팅을 정리하면서 느낀 점은,
실제 서비스 개발은 코드만 잘 짜는 것으로 끝나지 않는다는 것이다.

아이든든은 프론트, 백엔드, MTS, API Gateway, S3, Redis, CloudFront, EC2가 모두 연결된 프로젝트였다.

Frontend
→ API Gateway
→ Core Service
→ ETF Service
→ MTS Service
→ Redis / S3 / RDS
→ CloudFront / EC2

이런 구조에서는 한 곳의 작은 설정 누락이나 흐름 설계 부족이
전체 사용자 경험에 영향을 줄 수 있었다.

프로젝트 후반으로 갈수록 단순 기능 구현보다 중요한 것은
서비스 흐름 전체를 안정적으로 연결하는 것이었다.

회원가입에서 온보딩으로,
온보딩에서 자녀 등록으로,
자녀 등록에서 아동수당과 증여로,
증여에서 ETF 투자와 목표 달성률로 이어지는 흐름이 모두 맞아야
사용자는 서비스를 자연스럽게 사용할 수 있다.

이번 과정에서 가장 많이 배운 것은 다음과 같다.

1. 프론트와 백엔드의 enum, 날짜 포맷, 응답 구조는 반드시 문서화해야 한다.
2. Gateway 라우팅은 prefix 순서와 누락 여부를 계속 확인해야 한다.
3. Redis, S3, CloudFront 같은 외부 인프라는 timeout, CORS, 권한 설정이 중요하다.
4. 배포 환경에서는 GitHub Secret이 실제 설정의 기준이 된다.
5. 금융 서비스 화면에서는 확정값과 예정값을 반드시 구분해야 한다.
6. 민감 정보는 절대 코드나 문서에 남기면 안 된다.

앞으로는 기능을 구현할 때마다 다음 질문을 먼저 확인해야겠다고 느꼈다.

이 요청은 실제 배포 환경에서도 같은 경로로 가는가?
프론트와 백엔드가 같은 enum과 날짜 포맷을 쓰고 있는가?
이 데이터는 확정값인가, 예정값인가?
이 설정은 서버에만 있는가, GitHub Secret에도 반영되어 있는가?
사용자가 실패했을 때 다시 시도할 수 있는가?

결국 서비스의 완성도는
성공 케이스를 얼마나 잘 처리하는지뿐만 아니라,
실패했을 때 얼마나 자연스럽게 복구할 수 있는지에서 결정된다고 느꼈다.

“API 하나 만들면 끝나는 줄 알았는데,
막상 구현해보니 도메인 하나를 수정할 때마다 다른 도메인까지 같이 흔들렸다.”

아이든든 프로젝트를 진행하면서도메인 설계, 인증 구조, 예외 처리, 증여 로직, 계좌 연동, 스케줄러 처리 등 다양한 문제를 마주했다.

특히 증여세법을 적용시키면서 예외처리를 할 것이 많아 조건이 까다로웠지만 그만큼 예외처리를 하기위해 경계값을 생각하고 설계하는 과정이 나름 재밌었던 것 같다....

사실 이 내용들은 개발을 진행하면서 개인 노션에 계속 정리해두고 있었는데,
프로젝트 진행 중에는 블로그로 옮길 시간이 도저히 나지 않았다.

그래서 이제서라도 많고 많은 이슈 중 일부를 정리해보려고 한다.

들어가며

아이든든은 부모가 자녀의 미래 자금을 준비할 수 있도록 돕는 서비스다.

서비스 안에는 다음과 같은 도메인이 연결되어 있었다.

부모
 └── 자녀
      ├── 계좌
      ├── 증여 계약
      ├── 증여 이체 내역
      └── ETF 투자

처음에는 각각의 기능을 독립적으로 구현하면 된다고 생각했다.

하지만 실제로는 그렇지 않았다.

예를 들어 증여 계약 하나를 만들기 위해서도 단순히 gift_contracts 테이블에 데이터를 저장하는 것으로 끝나지 않았다.

증여 계약 생성
→ 인증된 부모 확인
→ 자녀가 해당 부모의 자녀인지 검증
→ 부모 계좌 조회
→ 자녀 계좌 조회
→ 증여 타입 확인
→ 현금 잔액 또는 ETF 보유 수량 검증
→ 증여 계약 생성
→ 이체 내역 생성

즉, 하나의 기능 안에 여러 도메인이 얽혀 있었다.

이번 글에서는 아이든든 백엔드 개발 과정에서 고민했던 트러블슈팅을 정리해보려고 한다.

1. 자녀 생년월일 검증은 프론트에서만 하면 충분할까?

문제 상황

자녀 등록 기능을 만들 때 생년월일을 입력받아야 했다.

이때 자녀의 생년월일은 현재 날짜 이후가 될 수 없다.

현재 날짜 이후의 생년월일은 선택 불가

처음에는 프론트에서 DatePicker의 선택 가능 범위를 제한하면 충분하다고 생각했다.

사용자가 미래 날짜를 선택하지 못하게 막으면 UX도 좋고, 잘못된 입력도 줄일 수 있기 때문이다.

그런데 정말 프론트 검증만으로 충분할까?

프론트 검증은 사용자가 정상적인 화면 흐름을 따라올 때는 효과적이다.

하지만 사용자가 반드시 우리가 만든 화면을 통해서만 요청을 보내는 것은 아니다.

Postman
Swagger
curl
브라우저 개발자 도구

이런 방식으로 API를 직접 호출하면 프론트 검증은 우회될 수 있다.

즉, 프론트 검증은 사용자 경험을 위한 장치이지, 데이터 무결성을 보장하는 최종 방어선은 아니었다.

해결 방향

결국 생년월일 검증은 프론트와 백엔드 양쪽에서 모두 처리하는 방향으로 정리했다.

백엔드에서는 @PastOrPresent 사용을 고려했다.

@PastOrPresent(message = "생년월일은 오늘 또는 과거 날짜여야 합니다.")
private LocalDate birthDate;

정리

프론트 검증은 UX를 위한 장치이고,
백엔드 검증은 신뢰성과 보안을 위한 장치다.

입력 검증은 프론트와 백엔드 중 하나만 선택하는 문제가 아니었다.
둘의 목적이 다르기 때문에 둘 다 필요했다.

2. 자녀 나이 계산은 DTO, Service, Entity 중 어디에 두어야 할까?

문제 상황

자녀 목록 조회 API에서는 자녀의 만나이를 내려줘야 했다.

처음에는 DTO의 정적 팩토리 메서드에서 생년월일을 기준으로 나이를 계산했다.

public static ChildItem from(Children child) {
    int age = Period.between(child.getBirthDate(), LocalDate.now()).getYears();

    return new ChildItem(
        child.getId(),
        child.getName(),
        age
    );
}

동작은 문제없었다.

하지만 코드를 보면서 한 가지 의문이 생겼다.

DTO가 나이를 계산해도 될까?

DTO에 계산 로직을 두는 것이 어색했던 이유

DTO는 데이터를 전달하기 위한 객체다.

그런데 DTO 안에서 birthDate를 기준으로 만나이를 계산하면, DTO가 도메인 지식을 가지게 된다.

DTO의 역할
→ 데이터를 담아서 전달

나이 계산
→ birthDate라는 도메인 값에서 파생되는 규칙

처음에는 Service에서 계산하는 것도 고려했다.

int age = Period.between(child.getBirthDate(), LocalDate.now()).getYears();
ChildItem.from(child, age);

이 방식은 DTO에서 계산 로직을 제거할 수 있다는 장점이 있었다.

하지만 나이 계산은 여러 엔티티를 조합하는 유스케이스라기보다는, Children 엔티티 자신의 상태인 birthDate에서 파생되는 값이었다.

그래서 Entity에 두는 것이 더 자연스럽다고 판단했다.

해결 방향

Children 엔티티에 getAge() 메서드를 추가했다.

public int getAge() {
    return Period.between(this.birthDate, LocalDate.now()).getYears();
}

DTO는 엔티티의 메서드를 호출해 값을 담기만 하도록 변경했다.

public static ChildItem from(Children child) {
    return new ChildItem(
        child.getId(),
        child.getName(),
        child.getAge()
    );
}

계층별 책임 정리

정리

단순 계산이라도 어디에 둘지 고민해야 한다.

엔티티 자신의 상태만으로 계산할 수 있는 값이라면,
DTO나 Service보다 Entity에 두는 것이 더 자연스러울 수 있다.

3. 증여 계약 테이블에 nullable 필드가 많아진 문제

문제 상황

증여 계약에는 여러 유형이 있었다.

INSTALLMENT  적립식 현금 증여
ONE_TIME     일시금 현금 증여
ETF          ETF 직접 이전

처음에는 이 세 가지 증여 타입을 하나의 gift_contracts 테이블에 모두 담으려고 했다.

gift_contracts
- id
- child_id
- gift_type
- cash_amount
- transfer_day
- end_month
- external_etf_id
- qty

구현은 단순했다.

하지만 타입별로 필요한 데이터가 다르다 보니 사용하지 않는 컬럼이 많아졌다.

예를 들어 ETF 증여에는 cash_amount가 필요 없다.
반대로 일시금 증여에는 transfer_day, end_month가 필요 없다.

결국 테이블에는 nullable 필드가 많아졌다.

왜 문제가 될까?

nullable 필드가 많아지면 당장 구현은 편하다.

하지만 데이터 의미가 흐려진다.

예를 들어 ETF 증여에서 cash_amount = 0으로 저장된다면, 이 값은 정말 0원을 의미하는 것일까?
아니면 해당 타입에서는 사용하지 않는 값이라는 뜻일까?

0원이라는 의미
vs
사용하지 않는 필드라서 임시로 넣은 값

이 둘은 완전히 다르다.

고민했던 설계

1안. Single Table 방식

gift_contracts
- id
- child_id
- gift_type
- cash_amount
- transfer_day
- end_month
- external_etf_id
- qty

2안. 타입별 상세 테이블 분리

gift_contracts
- id
- child_id
- gift_type
- status
- start_date

gift_contract_cash_details
- contract_id
- cash_amount
- transfer_day
- end_month

gift_contract_etf_details
- contract_id
- external_etf_id
- qty

최종 선택

프로젝트 규모와 기간을 고려해 MVP에서는 Single Table 구조를 유지했다.

대신 타입별 검증을 Service에서 명확히 처리하는 방향으로 정리했다.

gift_type = INSTALLMENT
→ cash_amount, transfer_day, end_month 필수

gift_type = ONE_TIME
→ cash_amount, start_date 필수

gift_type = ETF
→ external_etf_id, qty, start_date 필수

정리

DB 정규화와 구현 단순성 사이에는 항상 trade-off가 있다.

MVP에서는 단순한 구조로 빠르게 구현하되,
확장 시점에 어떤 구조로 분리할 수 있을지 알고 있는 것이 중요했다.

4. 증여 계약 상태값은 타입마다 다르게 흘러가야 했다

문제 상황

증여 계약 상태로 다음 값들을 고려했다.

DRAFT
ACTIVE
COMPLETED
CANCELLED
FAILED

처음에는 모든 증여 타입이 같은 상태 흐름을 가진다고 생각했다.

하지만 실제로는 그렇지 않았다.

일시금 증여와 ETF 증여는 생성 즉시 처리되는 구조에 가까웠다.
그런데 이런 계약을 DRAFT나 ACTIVE 상태로 오래 두는 것은 어색했다.

타입별 상태 흐름 정리

적립식 증여

적립식 증여는 여러 회차에 걸쳐 진행된다.

DRAFT 또는 ACTIVE
→ 회차별 이체 진행
→ COMPLETED

시작일이 미래라면 DRAFT 또는 예약 상태로 볼 수 있고,
실제로 이체가 진행 중이면 ACTIVE 상태가 자연스럽다.

일시금 증여

일시금 증여는 한 번 실행되면 끝난다.

생성 즉시 COMPLETED

ETF 증여

ETF 증여도 수량 확인 후 즉시 이전되는 구조에 가깝다.

보유 수량 확인
→ 즉시 이전
→ COMPLETED

정리

상태값은 단순히 많이 만들어두는 것이 중요한 게 아니었다.

중요한 것은 각 상태가 실제 업무 흐름에서 언제 발생하는지 명확해야 한다는 점이었다.

이 상태는 언제 시작되는가?
이 상태에서 다음 상태는 무엇인가?
실패하면 어디로 이동하는가?
완료 조건은 무엇인가?

상태 전이가 불명확하면 백엔드 로직뿐만 아니라 프론트 화면에서도 혼란이 생긴다.

5. 적립식 증여 회차 생성 로직에서 mutable 상태 줄이기

문제 상황

적립식 증여 계약을 생성하면 매월 이체될 GiftTransfer 목록을 미리 만들어야 했다.

처음에는 while문으로 현재 월과 회차 번호를 계속 변경하는 방식이었다.

YearMonth current = startMonth;
int seq = 1;

while (!current.isAfter(endMonth)) {
    transfers.add(...);
    current = current.plusMonths(1);
    seq++;
}

이 방식도 동작은 했다.

하지만 반복문 안에서 변경되는 값이 많았다.

current
seq
transfers

특히 회차 번호와 월 계산이 따로 움직이다 보니, 둘 사이가 어긋날 가능성이 있었다.

개선 방향

회차 번호를 기준으로 해당 월을 계산하도록 바꿨다.

int totalMonths = (int) startMonth.until(endMonth, ChronoUnit.MONTHS) + 1;

List<GiftTransfer> transfers = IntStream.rangeClosed(1, totalMonths)
    .mapToObj(seq -> {
        YearMonth month = startMonth.plusMonths(seq - 1);
        return GiftTransfer.create(seq, month);
    })
    .toList();

이 방식에서는 seq 하나로 회차 번호와 해당 월을 모두 계산할 수 있다.

sequenceNo = seq
month = startMonth.plusMonths(seq - 1)

변경 전후 비교

정리

반복문이 항상 나쁜 것은 아니다.

하지만 값이 계속 변하는 상태가 많아지면 실수 가능성이 커진다.
회차처럼 범위가 명확한 경우에는 IntStream으로 기준을 단순화하는 것도 좋은 선택이었다.

6. ETF 증여는 요청값만 믿으면 안 된다

문제 상황

ETF 증여 요청은 다음과 같이 들어온다.

{
  "gift_type": "ETF",
  "external_etf_id": 1,
  "qty": 5,
  "start_date": "2026-06-19"
}

하지만 요청값만 보고 증여 계약을 생성하면 안 된다.

부모가 실제로 해당 ETF를 5주 이상 보유하고 있는지 확인해야 하기 때문이다.

왜 서버 검증이 필요할까?

현금 증여에서는 부모 계좌의 현금 잔액을 확인해야 한다.

ETF 증여에서는 부모 계좌의 ETF 보유 수량을 확인해야 한다.

현금 증여
→ 부모 계좌 잔액 확인

ETF 증여
→ 부모 ETF 보유 수량 확인

검증 없이 계약을 생성하면 실제로 보유하지 않은 ETF를 자녀에게 증여하는 잘못된 상태가 생긴다.

타입별 검증 기준

잔액 부족과 ETF 수량 부족은 다른 의미의 오류이기 때문에 에러 코드도 분리했다.

GIFT_400_01 → 잔액 부족
GIFT_400_02 → ETF 수량 부족

정리

금융 거래성 기능은 요청값만으로 처리하면 안 된다.

클라이언트가 보낸 값은 요청일 뿐이고,
실제 처리 가능 여부는 서버가 계좌 상태와 보유 수량을 기준으로 검증해야 한다.

7. 적립식 증여 자동이체 실패 시 계약 상태는 어떻게 해야 할까?

문제 상황

적립식 증여는 스케줄러가 매일 0시에 오늘 이체할 건을 조회해 처리하는 구조였다.

@Scheduled(cron = "0 0 0 * * *")
public void processInstallmentTransfers() {
    ...
}

잔액이 부족하면 해당 이체를 실패 처리했다.

transfer.fail("잔액 부족");
return;

그런데 테스트 과정에서 문제가 보였다.

마지막 회차가 실패하면 남은 SCHEDULED 이체가 없는데도 계약이 ACTIVE 상태로 계속 남을 수 있었다.

원인

기존 로직에서는 성공한 경우에만 남은 이체가 있는지 확인하고 계약을 완료 처리했다.

반면 실패한 경우에는 return으로 빠져나가면서 계약 완료 여부를 확인하지 않았다.

성공
→ 남은 회차 확인
→ 없으면 계약 COMPLETED

실패
→ transfer FAILED
→ return
→ 계약 완료 여부 확인 안 함

즉, 실패도 하나의 회차 종료로 봐야 하는데, 실패 시 완료 체크가 실행되지 않는 것이 문제였다.

개선 방향

실제 자동이체 흐름을 생각하면, 한 번 실패했다고 계약 전체가 실패하는 것은 어색하다.

이번 달 잔액 부족으로 이체가 실패할 수는 있지만, 다음 달 회차는 정상적으로 진행될 수도 있다.

그래서 다음과 같은 방향으로 정리했다.

1차 시도 실패
→ 당일 재시도
→ 재시도 횟수 초과 시 해당 회차 FAILED
→ 계약은 ACTIVE 유지
→ 다음 달 회차는 계속 시도
→ 모든 회차가 SUCCESS 또는 FAILED 상태가 되면 계약 COMPLETED

이를 위해 다음 개선을 고려했다.

retryCount 컬럼 추가
실패 시 바로 FAILED 확정하지 않고 SCHEDULED 유지
09:00, 14:00 재시도
재시도 횟수 초과 시 FAILED 처리
성공/실패와 관계없이 남은 SCHEDULED가 없으면 계약 COMPLETED

정리

스케줄러는 성공 케이스보다 실패 케이스 설계가 더 중요했다.

특히 마지막 회차 실패처럼 경계 조건을 고려하지 않으면 계약 상태가 비정상적으로 남을 수 있다.

회차 실패와 계약 실패는 다르다.
마지막 회차 실패도 계약 종료 조건에 포함되어야 한다.
스케줄러는 중간 return 때문에 상태 변경이 누락되지 않도록 설계해야 한다.

8. MSA 구조에서 서비스 간 DB 참조를 어떻게 할까?

문제 상황

아이든든은 Core Service, ETF Service, MTS Service처럼 역할을 나누는 구조를 고려했다.

Core Service
→ 부모, 자녀, 목표, 증여

ETF Service
→ ETF 정보, 시세, 포트폴리오

MTS Service
→ 계좌, 주문, 잔고

증여 계약을 만들 때는 부모 계좌와 자녀 계좌 정보가 필요했다.
그런데 계좌 정보는 MTS 쪽 도메인에 가까웠다.

이때 고민이 생겼다.

Core Service에서 Account 테이블을 직접 읽어도 될까?
아니면 MTS Service API를 호출해야 할까?

원칙과 현실 사이

원칙적인 MSA에서는 각 서비스가 자기 DB만 소유한다.

따라서 Core Service가 MTS Service의 Account 테이블을 직접 읽는 것은 MSA 원칙에 맞지 않는다.

하지만 우리 프로젝트는 실제로는 단일 DB를 공유하고 있었고, 코드만 서비스별로 분리된 구조에 가까웠다.

그래서 완전한 MSA라기보다는, 모듈을 서비스 단위로 나눈 구조에 가까웠다.

고민했던 선택지

MVP 단계에서는 단일 DB 공유 구조였기 때문에 Core Service에서 읽기 전용 AccountRepository를 두는 방식을 고려했다.

다만 장기적으로 서비스 경계가 명확해진다면, 계좌 상세 정보는 MTS API를 호출하는 구조가 더 바람직하다고 판단했다.

정리

MSA는 이름만 서비스가 나뉘었다고 완성되는 것이 아니다.

DB 소유권, 서비스 간 통신, 장애 격리까지 함께 고려해야 진짜 MSA라고 할 수 있다.

이번 프로젝트에서는 현실적인 단순함을 선택했지만,
장기적으로는 서비스별 데이터 소유권을 분리하는 방향이 더 적절하다고 느꼈다.

전체 회고

이번 백엔드 트러블슈팅을 정리하면서 가장 크게 느낀 점은,
백엔드 개발은 단순히 API를 만드는 일이 아니라는 것이다.

하나의 API를 만들기 위해서도 다음 요소를 함께 고민해야 했다.

도메인 의미
DB 정규화
API 경로 설계
인증 구조
예외 처리
보안
세무 기준
프론트 협업
스케줄러 실패 처리
서비스 확장 가능성

특히 증여 기능은 단순 입금 기능처럼 보였지만,
실제로는 계좌, 세무, 자녀, 부모, ETF, 스케줄러가 모두 연결된 복합 도메인이었다.

이번 프로젝트를 통해 기능 구현 전에 도메인 기준을 먼저 정리하는 것이 얼마나 중요한지 배웠다.

앞으로 백엔드 기능을 설계할 때는 다음 질문을 먼저 던져야겠다고 생각했다.

이 값은 정말 DB에 저장해야 하는가?
이 로직은 어느 계층의 책임인가?
클라이언트가 이 값을 보내야 하는가, 서버가 알 수 있는가?
상태값은 실제 흐름과 맞는가?
실패했을 때 다음 상태는 무엇인가?

이 질문들을 기준으로 설계하면,
단순히 동작하는 코드가 아니라 유지보수 가능한 코드를 만들 수 있다고 느꼈다.

마무리

아이든든 프로젝트를 하면서 기능을 하나씩 구현하는 것보다 어려웠던 것은
각 기능이 어떤 도메인 책임을 가지는지 정리하는 일이었다.

처음부터 완벽한 설계를 한 것은 아니었지만,
문제를 마주할 때마다 기준을 세우고 구조를 다듬어가면서 백엔드 설계에 대해 많이 배울 수 있었다.

다음 프로젝트에서는 기능 구현 전에 도메인 흐름, 상태 전이, 실패 케이스를 더 먼저 정리해보고 싶다.

자녀 금융 서비스를 만들려면
단순히 “투자 기능”만 잘 만들면 되는 줄 알았다.

그런데 실제로는 정부지원금, 부모의 현금 흐름, 자녀 계좌, 증여세, ETF 평가 기준까지 모두 연결되어 있었다.

아이든든 서비스를 구체화하면서 아동수당, 부모급여, 첫만남이용권, 양육수당, 다자녀 정책, 증여세 기준 등을 조사했다.

처음에는 단순히 “자녀에게 들어오는 지원금이 어떤 게 있나?” 정도를 확인하려고 했다.
하지만 리서치를 진행할수록 이 정보들이 서비스의 핵심 기능과 직접 연결된다는 것을 알게 되었다.

아이든든은 부모가 자녀의 미래 자금을 목표 기반으로 준비하도록 돕는 서비스다.

이를 위해서는 다음 질문에 답할 수 있어야 했다.

부모가 매월 받을 수 있는 지원금은 얼마인가?
그 돈을 자녀 계좌로 연결할 수 있는가?
자녀 계좌로 돈을 넣으면 증여세 이슈는 없는가?
ETF로 투자하면 증여 금액은 어떻게 평가해야 하는가?
정책 지원금은 목표 금액 계산에 어떻게 반영할 수 있는가?

이번 글에서는 아이든든 프로젝트에서 진행했던 정책·세무 리서치를 정리하고,
이 리서치가 실제 서비스 기능 설계로 어떻게 이어졌는지 기록해보려고 한다.

1. 왜 정책 리서치가 필요했을까?

아이든든은 단순 투자 서비스가 아니라,
부모가 자녀의 미래 자금을 계획적으로 준비할 수 있도록 돕는 서비스다.

따라서 투자 기능만으로는 부족했다.

부모가 실제로 받을 수 있는 지원금,
자녀 명의 계좌로 자금이 이동할 때 발생하는 증여 이슈,
자녀가 성장하면서 필요한 목표 금액까지 함께 고려해야 했다.

이번 리서치의 목적은 단순히 정책 정보를 모으는 것이 아니었다.

정책 정보 수집
→ 부모의 현금 흐름 파악
→ 자녀 미래 자금 목표 설정
→ 아동수당 기반 투자 시나리오 설계
→ 증여 관리 기능 설계

즉, 정책과 세무 기준을 서비스 기능으로 연결하기 위한 근거를 확보하는 것이 목적이었다.

조사한 주요 내용

아동수당 기반 투자 시나리오
부모급여와 아동수당의 중복 수령 가능성
첫만남이용권 등 출산 초기 지원금
가정양육수당 적용 시점
다자녀 정책의 목표 금액 반영 가능성
증여세 비과세 한도
주식·ETF 증여 평가 기준

정책 정보는 여러 사이트에 흩어져 있었기 때문에,
공식 출처를 중심으로 확인했다.

2. 아이든든에서 가장 중요하게 본 정책: 아동수당

여러 정책 중 아이든든에서 가장 중요하게 본 것은 아동수당이었다.

이유는 단순하다.

아동수당은 매월 현금성으로 지급되기 때문에,
은행 계좌에서 자녀 증권 계좌로 연결하기 좋은 출발점이 될 수 있다.

아이든든이 생각한 핵심 흐름은 다음과 같았다.

아동수당 지급
→ 부모 또는 자녀 은행 계좌 입금
→ 자녀 증권 계좌 연결
→ ETF 적립식 투자
→ 목표 달성률 반영
→ 증여 한도 관리

아동수당은 단순한 복지 정보가 아니라,
서비스의 첫 번째 투자 재원이 될 수 있었다.

아동수당 기본 구조

아동수당은 만 9세 미만 아동을 대상으로 지급되는 지원금이다.

신청은 복지로, 정부24, 행정복지센터 등을 통해 가능하고,
출생 후 60일 이내 신청하면 출생월분까지 소급 적용될 수 있다.

지급일은 일반적으로 매월 25일이며,
주말이나 공휴일이면 직전 영업일에 지급된다.

서비스 관점에서는 이 지급일이 중요했다.

왜냐하면 매월 25일을 기준으로 다음과 같은 기능을 설계할 수 있기 때문이다.

아동수당 입금 알림
→ 투자 제안
→ 자녀 증권 계좌 이체
→ ETF 적립식 매수
→ 목표 달성률 업데이트

2026년 아동수당 지급액 변화 고려

리서치 과정에서 2026년에는 지역과 지급 방식에 따라 아동수당 금액이 달라질 수 있다는 점도 확인했다.

이를 서비스에 반영한다면,
단순히 “아동수당 10만 원”으로 고정하기보다 사용자의 거주 지역에 따라 금액을 다르게 보여줄 수 있다.

수도권 거주
→ 월 10만 원 기준

비수도권 거주
→ 월 10.5만 원 기준

인구감소지역 거주
→ 월 11만 원 이상 기준

서비스 문구 예시

아동수당은 단순 안내보다,
목표 달성률과 연결했을 때 더 서비스 가치가 커진다.

이번 달 아동수당 10만 원이 입금되었어요.

이 금액을 아이의 미래 자산으로 투자하면
20세까지 목표 달성률이 3% 높아질 수 있어요.

이런 방식으로 정책 지원금을 투자 행동으로 자연스럽게 연결할 수 있다.

3. 부모급여와 첫만남이용권은 목표 설정에 반영하기

아동수당 외에도 부모급여와 첫만남이용권은 자녀 미래 자금 설계에서 중요한 정책이었다.

다만 두 정책은 서비스에서 활용하는 방식이 조금 다르다.

부모급여

부모급여는 0~23개월 아동을 실제로 양육하는 보호자에게 지급되는 현금성 지원이다.

부모급여는 아동수당보다 금액이 크기 때문에,
0~23개월 자녀를 둔 부모에게는 중요한 현금 흐름이다.

특히 부모급여는 아동수당과 중복 수령이 가능하다는 점에서
서비스 내 월별 지원금 흐름을 보여주기 좋다고 판단했다.

아동수당
+ 부모급여
= 월별 지원금 흐름

다만 어린이집을 이용하는 경우에는 보육료 바우처를 제외한 차액만 현금으로 지급될 수 있다.

따라서 서비스에서는 어린이집 이용 여부에 따라
실제 투자 가능 금액을 다르게 계산해야 한다.

첫만남이용권

첫만남이용권은 출생 초기 경제적 부담을 줄이기 위한 지원금이다.

다만 첫만남이용권은 현금 투자로 바로 연결되기보다는
국민행복카드 바우처 형태로 지급된다.

따라서 아이든든에서는 이를 직접 투자 재원으로 보기보다,
출생 초기 지출 부담을 줄이는 정책으로 반영하는 것이 적절하다고 판단했다.

출생 초기 예상 지출
- 첫만남이용권
= 실제 준비 필요 금액

즉, 첫만남이용권은 “투자 가능 금액”보다는
“목표 금액 설정 도우미”에 반영하기 좋은 정책이었다.

4. 가정양육수당과 지원금 흐름 정리

가정양육수당은 어린이집, 유치원, 종일제 아이돌봄서비스 등을 이용하지 않고
가정에서 양육되는 아동에게 지급되는 지원금이다.

부모급여 도입 이후에는 일반적으로 다음 흐름으로 볼 수 있다.

0~23개월
→ 부모급여

24개월~86개월 미만
→ 가정양육수당

만 9세 미만
→ 아동수당

이 흐름은 서비스에서 자녀 생년월일을 기준으로
받을 수 있는 지원금을 자동 안내하는 데 활용할 수 있다.

자녀 생년월일 입력
→ 현재 받을 수 있는 정책 확인
→ 향후 종료되는 지원금 안내
→ 월 투자 가능 금액 참고

이렇게 정책을 시간 흐름으로 정리하면
사용자에게 “지금 받을 수 있는 지원금”과 “앞으로 받을 수 있는 지원금”을 함께 보여줄 수 있다.

5. 다자녀 정책은 목표 금액 보정에 활용하기

다자녀 정책은 전기요금 감면, 세제 혜택, 국가장학금 등 다양한 형태로 제공된다.

하지만 모든 다자녀 정책을 아이든든의 투자 가능 금액으로 직접 연결하기는 어렵다.

그중 서비스에 반영하기 가장 좋은 것은 다자녀 국가장학금이었다.

다자녀 국가장학금은 자녀의 대학 등록금 목표 금액을 계산할 때
실질 부담액을 줄이는 요소로 활용할 수 있다.

예상 대학 등록금
- 다자녀 국가장학금 예상 지원액
= 실제 준비 필요 금액

특히 셋째 이상 자녀의 경우 지원 혜택이 커질 수 있으므로,
자녀 수와 출생 순서를 목표 금액 설정에 반영할 수 있다.

6. 정책 데이터는 서비스에서 어떻게 쓸 수 있을까?

정책 데이터는 크게 두 가지 방식으로 활용할 수 있다고 판단했다.

6-1. 목표 금액 설정 도우미

부모가 자녀의 미래 자금을 준비할 때 가장 어려운 것은
“얼마를 목표로 잡아야 하는지”를 모른다는 점이다.

정책 지원금은 이 목표 금액을 조금 더 현실적으로 만들어준다.

예상 필요 금액
- 받을 수 있는 지원금
= 실질 준비 필요 금액

예를 들어 출생 초기에는 첫만남이용권을 반영하고,
대학 등록금 목표에는 다자녀 국가장학금을 반영할 수 있다.

6-2. 월 투자 가능 금액 제안

아동수당과 부모급여처럼 현금성으로 들어오는 지원금은
투자 가능 금액을 제안하는 데 활용할 수 있다.

아동수당 10만 원
+ 부모급여 일부
= 자녀 미래 자금 투자 후보 금액

이렇게 하면 사용자는 막연히 “투자해야 한다”가 아니라,
실제로 매월 들어오는 지원금 중 일부를 기준으로 투자 계획을 세울 수 있다.

7. 왜 ETF를 핵심 투자 수단으로 보았을까?

아이든든은 자녀 미래 자금을 준비하는 서비스이기 때문에
투자 수단도 장기 투자에 적합해야 했다.

ETF는 다음 이유로 서비스 방향과 잘 맞는다고 판단했다.

소액 적립식 투자 가능
장기 투자에 적합
개별 종목보다 분산 효과
자녀 독립 자금 목표와 연결 가능
아동수당 자동 투자와 결합하기 쉬움
목표 기반 포트폴리오 구성 가능

특히 아동수당처럼 매월 일정하게 들어오는 금액은
ETF 적립식 투자와 연결하기 좋다.

매월 아동수당 입금
→ 정해진 비율만큼 ETF 매수
→ 장기 보유
→ 목표 달성률 반영

자녀 계좌에서는 단기 매매보다 장기 보유 중심의 투자 방식이 더 적합하다고 보았다.

8. 자녀 계좌로 돈을 넣으면 증여세를 고려해야 한다

정책 리서치와 함께 중요하게 본 것이 증여세였다.

자녀 명의 계좌로 돈을 넣거나,
부모가 보유한 ETF를 자녀에게 이전하는 경우 증여 이슈가 발생할 수 있기 때문이다.

아이든든에서 증여세를 고려한 이유는 단순하다.

부모가 자녀 미래 자금을 준비하는 순간,
그 돈이 자녀 명의로 이동하면 증여 관리가 필요해진다.

미성년 자녀 증여공제

미성년 자녀에게 증여하는 경우
10년 단위로 2,000만 원까지 증여재산공제를 활용할 수 있다.

서비스에서는 이를 다음 기능으로 연결할 수 있다.

10년 누적 증여액 계산
남은 비과세 한도 계산
한도 임박 알림
한도 초과 시 신고 가능성 안내
과거 증여 이력 입력

예를 들어 화면에서는 다음과 같이 보여줄 수 있다.

최근 10년간 우리 서비스 내 증여액

1,200만 원 / 2,000만 원

남은 한도: 800만 원

다만 서비스가 모든 기관의 증여 내역을 자동으로 알 수 있는 것은 아니기 때문에,
“우리 서비스 내 누적 증여액”과 “사용자가 입력한 과거 증여액”을 구분해야 한다.

9. 현금 입금과 ETF 직접 이전은 다르게 봐야 한다

증여 관리에서 중요한 것은
현금 입금과 ETF 매수를 구분하는 것이다.

자녀 계좌에 현금을 넣고 그 돈으로 ETF를 사는 경우라면,
증여는 일반적으로 현금 입금 시점을 기준으로 관리하는 것이 자연스럽다.

반면 부모가 이미 보유한 ETF를 자녀에게 직접 이전하는 경우에는
ETF 평가액 계산이 필요하다.

ETF 직접 이전 평가

상장주식이나 ETF를 직접 증여하는 경우
증여일 하루의 가격만으로 증여 금액을 계산하지 않는다.

일반적으로 증여일 전후 각 2개월 동안의 최종시세가액 평균을 기준으로 평가한다.

1주당 증여 평가액
= 증여일 이전 2개월 + 증여일 이후 2개월
  동안의 매일 최종시세가액 평균

문제는 증여 직후에는 아직 “증여일 이후 2개월” 데이터가 없다는 점이다.

따라서 서비스에서는 다음처럼 예상 금액과 최종 금액을 나누어 관리하는 것이 필요하다.

증여 직후
→ 예상 증여 금액 제공

증여일 + 2개월 이후
→ 최종 증여 금액 확정

이 구조는 이후 ETF 증여 기능 설계에도 직접 반영되었다.

10. 증여 관리 로직은 어떻게 설계할 수 있을까?

리서치를 바탕으로 아이든든의 증여 관리 흐름을 다음과 같이 정리했다.

1. 자녀 명의 계좌에 자금이 들어왔는가?

- 아니오
  → 부모 목표자금 관리

- 예
  → 증여 관리 대상으로 분류

2. 증여 방식은 무엇인가?

- 현금 입금
  → 입금액을 증여 누적액에 반영

- ETF/주식 직접 이전
  → 증여일 전후 2개월 평균가 기준 안내

3. 최근 10년 부모 합산 증여액은 얼마인가?

- 2,000만 원 미만
  → 한도 내

- 2,000만 원 근접
  → 한도 임박 알림

- 2,000만 원 초과
  → 신고 가능성 안내

4. 한도 초과 또는 불명확한 내역이 있는가?

- 예
  → 세무 확인 또는 신고 안내

- 아니오
  → 목표 달성률 및 ETF 투자 관리 제공

이 흐름을 기준으로 증여 관리 기능을 설계하면,
단순히 이체 내역을 보여주는 것을 넘어
사용자가 자신의 증여 한도 사용 현황을 이해할 수 있다.

11. 부모 합산 증여액을 관리해야 하는 이유

증여 한도를 계산할 때 아빠가 보낸 돈과 엄마가 보낸 돈을 따로 보면 안 된다.

직계존속으로부터의 증여는 부모를 합산해 관리하는 방향으로 설계하는 것이 안전하다고 보았다.

서비스에서는 이를 다음처럼 안내할 수 있다.

부모님이 각각 입금한 금액도 합산하여
최근 10년 증여 한도를 계산합니다.

이 문구는 사용자가 “아빠 2,000만 원, 엄마 2,000만 원까지 각각 가능한 것 아닌가?”라고 오해하지 않도록 돕는 역할을 한다.

12. 자녀 계좌에서 잦은 매매가 문제될 수 있는 이유

자녀 명의 계좌에 돈을 넣은 뒤,
그 돈으로 장기 보유 중심의 ETF 투자를 한다면 비교적 단순하게 관리할 수 있다.

하지만 부모가 자녀 명의 계좌에서 적극적이고 빈번하게 매매를 한다면 문제가 복잡해질 수 있다.

시세차익이 단순히 자녀 재산에서 발생한 운용 수익인지,
부모의 적극적인 노력으로 발생한 이익인지 해석이 달라질 수 있기 때문이다.

그래서 아이든든의 투자 방향은 다음처럼 잡는 것이 적절하다고 판단했다.

단기 매매 지양
장기 보유 중심
ETF 중심
적립식 투자 중심
잦은 매매 리스크 안내
투자 운용 리스크 고지

이는 서비스가 단순히 수익률만 강조하기보다,
자녀 계좌의 성격에 맞는 투자 방식을 안내해야 한다는 의미이기도 하다.

13. 증여 기능은 MVP와 고도화 기능으로 나누기

증여 관련 기능은 생각보다 범위가 컸다.

현금 입금 관리, ETF 이전 평가, 신고기한 알림, 홈택스 신고 보조, 세무사 연결까지 생각하면
한 번에 모두 구현하기 어렵다.

그래서 MVP와 고도화 기능을 나누어 정리했다.

MVP 기능

증여 내역 관리
현금 입금 내역 기록
ETF 이전 내역 기록
10년 증여 한도 자동 계산
남은 비과세 한도 계산
한도 사용률 시각화
과거 증여 이력 입력
증여 방식 선택
신고 상태 관리

MVP에서는 사용자가 현재 자신의 증여 한도 사용 현황을 이해하고,
현금 증여와 ETF 이전을 구분해 기록할 수 있도록 하는 데 집중한다.

고도화 기능

ETF 직접 이전 평가액 계산
증여 후 2개월 확정 평가 업데이트
일시금 증여와 적립식 증여 비교
유기정기금 안내
증여 신고 체크리스트
홈택스 신고 보조
세무 리스크 알림
세무사 연결

고도화 단계에서는 세무 판단이 필요한 영역까지 확장할 수 있다.

다만 세금 계산은 민감한 영역이기 때문에,
서비스에서 확정적으로 판단하기보다는 신고 가능성 안내와 전문가 확인 연결을 포함하는 것이 안전하다고 보았다.

14. 경쟁 서비스 리서치

정책과 세무 기준뿐만 아니라,
유사한 방향의 서비스들도 함께 살펴봤다.

한화생명 파이

한화생명 파이는 자녀 금융과 증여 기능을 잘 연결하고 있었다.

참고할 수 있었던 부분은 다음과 같다.

자녀 금융 서비스
증여 한도 계산
홈택스 신고 연결
자녀 자산 관리
부모 대상 가이드
증여 신고 흐름 단순화

아이든든에서 홈택스 직접 연결까지 구현하기는 어렵지만,
증여 한도 계산, 증여 내역 관리, 신고 필요 여부 안내, 홈택스 신고 가이드 등은 참고할 수 있다고 판단했다.

마미톡

마미톡은 임신·출산 정보와 육아 커뮤니티에 강점이 있는 서비스다.

참고할 수 있었던 부분은 다음과 같다.

임신·출산 정보
육아 기록
부모 커뮤니티
자녀 성장 정보
부모의 실제 고민 확인

다만 금융 기능은 상대적으로 제한적이다.

그래서 아이든든은 육아 정보 제공보다는
자녀의 미래 자산 준비와 금융 관리에 집중하는 방향으로 차별화할 수 있다고 보았다.

15. 리서치를 통해 정리한 서비스 방향

이번 리서치를 통해 아이든든에 반영할 기능 방향은 크게 세 가지로 정리할 수 있었다.

정책 기반 기능

아동수당 자동 투자
부모급여 일부 투자 제안
첫만남이용권 기반 초기 지출 차감
가정양육수당 안내
다자녀 국가장학금 반영
지역별 출산지원금 안내

정책 기반 기능은 사용자가 받을 수 있는 지원금을 확인하고,
이를 목표 금액 설정이나 투자 가능 금액 제안에 활용하는 방향이다.

세무 기반 기능

10년 증여 한도 계산
부모 합산 증여액 관리
과거 증여 이력 입력
현금 입금과 ETF 이전 구분
ETF 이전 평가액 안내
신고기한 알림
세무 리스크 안내

세무 기반 기능은 자녀 계좌로 자금이 이동할 때
부모가 놓치기 쉬운 증여 이슈를 관리해주는 방향이다.

투자 기반 기능

ETF 중심 장기 투자
적립식 투자
목표 기반 포트폴리오
자녀 계좌 장기 보유 전략
잦은 매매 리스크 안내
자산 성장 시뮬레이션

투자 기반 기능은 아동수당과 부모의 여유자금을
자녀 미래 자산으로 연결하는 역할을 한다.

전체 회고

정책과 세무 리서치를 하면서 느낀 점은,
자녀 금융 서비스는 단순히 “아이 이름으로 투자하기”가 아니라는 것이다.

아이에게 들어오는 정부지원금,
부모가 대신 준비하는 자금,
자녀 계좌로 넘어가는 증여금,
그리고 그 돈으로 운용되는 ETF가 모두 연결되어 있었다.

특히 아동수당은 아이든든의 서비스 흐름을 설명하는 데 중요한 역할을 했다.

정부지원금
→ 은행 계좌
→ 증권 계좌
→ ETF 투자
→ 자녀 미래 자산

또한 증여세는 부모가 자녀 명의로 돈을 모을 때 반드시 마주하게 되는 문제였다.

서비스가 이 부분을 잘 풀어내면,
단순한 투자 서비스가 아니라 부모의 실질적인 불안을 줄여주는 금융 서비스가 될 수 있다고 생각했다.

결국 이번 리서치를 통해 아이든든의 핵심 방향은 더 명확해졌다.

아동수당과 부모의 여유자금을 자녀 증권 계좌로 연결하고,
ETF 장기 투자와 증여 관리를 통해
자녀 미래 자산을 목표 기반으로 준비하게 돕는 서비스

처음에는 정책과 세무 리서치가 기획 단계의 참고 자료라고 생각했다.

하지만 프로젝트를 진행하면서 이 리서치는 단순한 배경 자료가 아니라,
서비스의 기능 구조와 도메인 설계를 결정하는 중요한 근거가 되었다.

초기 기획안에 대한 피드백을 받은 뒤, 우리 서비스는 몇 가지 방향을 수정하게 되었다.

가장 큰 변화는 단순히 “자녀 계좌로 투자하는 서비스”가 아니라,
신한금융그룹 내 교차 고객 확대 구조를 가진 자녀 미래 자금 준비 서비스로 기획을 보완한 점이다.

잊지말자!! 우리의 근본적인 주제를!!

1. 교차 고객 구조 재정의

초기에는 신한은행 고객을 신한투자증권 고객으로 유도하는 흐름을 중심으로 생각했다.

하지만 피드백을 받은 뒤, 교차 고객 구조를 더 구체적으로 잡을 필요가 있다고 판단했다.

기존 생각

신한은행 고객
→ 자녀 증권 계좌 개설
→ ETF 투자
→ 자녀 미래 자금 마련

보완한 방향

신한라이프 태아보험 가입자
→ 자녀 출생
→ 아동수당 또는 육아수당 수령
→ 신한은행 계좌
→ 신한투자증권 자녀 계좌 개설
→ ETF 장기 투자
→ 자녀 미래 자금 관리

이렇게 바꾸면 신한라이프, 신한은행, 신한투자증권이 자연스럽게 연결된다.

단순히 증권 서비스 안에서 끝나는 것이 아니라,
자녀 출생 전후의 고객 여정을 따라 금융 계열사가 이어지는 구조가 된다.

2. 서비스 전체 구조

서비스는 크게 세 가지 축으로 정리했다.

정부지원금 / 아동수당
→ 부모 증권 계좌
→ 자녀 증권 계좌

각 영역의 역할은 다음과 같다.

3. 부모 증권 계좌 기능

부모 증권 계좌에서는 아이에게 사용할 돈과 아이에게 물려줄 돈을 구분해 목표를 관리한다.

주요 기능

• 목표 설정 도우미
• 아이에게 사용할 목표 금액 설정
• 아이에게 물려줄 목표 금액 설정
• 달성률 시각화
• 달성 가능성 시각화
• ETF MTS 기능
• 투자 리포트
• 또래 기반 ETF 순위
• 유사 고객군 통계

부모 계좌의 핵심 역할

자녀 생애주기별 목표 설정
→ 월 납입액 계산
→ ETF 투자 실행
→ 목표 달성률 확인
→ 필요 시 자녀 계좌로 증여

부모 계좌는 단순한 투자 계좌가 아니라,
자녀의 성장 과정에서 필요한 자금을 계획하고 관리하는 공간으로 정의했다.

4. 자녀 증권 계좌 기능

자녀 증권 계좌는 증여와 장기 자산 관리를 중심으로 설계했다.

주요 기능

• 증여 현황 대시보드
• 증여 금액 시각화
• 증여세 시각화
• 증여 내역 관리
• ETF MTS 기능
• 달성률 시각화
• 달성 가능성 시각화
• 또래 기반 ETF 순위
• 2024년생 등 출생연도 기반 비교
• 적립식 투자

자녀 계좌의 핵심 역할

부모로부터 증여 수령
→ 자녀 명의 자산 관리
→ ETF 장기 투자
→ 증여 한도 확인
→ 성년 이후 자산 전달

자녀 계좌는 단순히 돈을 받는 계좌가 아니라,
아이의 독립 자금을 장기적으로 관리하는 계좌로 정의했다.

5. 가져가야 할 핵심 기능

피드백 이후 반드시 가져가야 할 기능을 부모 계좌와 자녀 계좌로 나누어 정리했다.

부모 계좌

• 개인화된 목표 설정 지원
• 온보딩 데이터 기반 목표 추천
• 다자녀 여부 반영
• 소득분위 반영
• 지역 정보 반영
• 임신·출산 관련 제도 반영
• 장애 장려금 등 지원 제도 반영
• RAG 기반 AI 활용
• 목표 달성률 시각화
• 목표 달성 가능성 시각화
• ETF MTS 기능
• 또래 탭
• 유사 고객군 통계
• 목표별 ETF 상품 탐색

자녀 계좌

• 증여 현황 대시보드
• 증여 내역 관리
• 증여 금액 시각화
• 증여세 시각화
• ETF MTS 기능
• 달성률 시각화
• 달성 가능성 시각화
• 또래 탭
• 출생연도 기반 비교
• 목표별 ETF 상품 탐색
• 적립식 투자
• 아동수당 기반 투자

6. 증여 관련 기능 정리

자녀 금융 서비스에서 증여는 거의 필수에 가까운 기능이라고 판단했다.

부모가 자녀 명의 계좌로 돈을 이전하는 순간,
증여 한도와 신고 여부에 대한 불안이 생기기 때문이다.

증여 기능 후보

• 적립식 펀드 증여
• 적립식 투자
• 아동수당 기반 증여
• 증여 내역 관리
• 증여 금액 시각화
• 증여세 시각화
• 10년 증여 한도 자동 계산
• 증여 방식 선택
• 과거 증여 이력 입력
• 증여 계획 시뮬레이션
• 신고 상태 관리
• 신고기한 알림
• ETF 직접 이전 예상 평가액 계산
• 일시금 증여와 적립식 증여 비교
• 유기정기금 가능성 안내
• 증여 절세 가이드
• 홈택스 신고 보조
• 세무 리스크 알림

7. 증여 기능 우선순위

증여 기능은 한 번에 모두 구현하기 어렵기 때문에 MVP와 고도화 기능으로 나누었다.

고도화 기능

8. 리서치가 필요한 부분

기획을 더 설득력 있게 만들기 위해 추가 리서치가 필요했다.

조사해야 할 것

• ETF 니즈 관련 객관적 자료
• 미성년자 증권 계좌 증가 자료
• 아동수당 활용 사례
• 증여세 기준
• 미성년 자녀 계좌 개설 정보
• 자금 출처 관리 기준
• 미성년 자녀 계좌 운용 리스크
• 개인 목표 설정을 위한 국가 통계 데이터
• 생애주기별 양육비 데이터
• 교육비 관련 통계
• 증여 관련 공공 데이터

9. 목표 달성률 계산 예시

여러 목표를 동시에 관리할 때, 자금이 어떤 목표에 배분되는지 보여주는 예시도 정리했다.

예를 들어 초기 씨드머니가 700만 원이고, 목표가 세 개 있다고 가정했다.

이 예시는 사용자가 여러 목표를 동시에 설정했을 때,
현재 자금으로 어떤 목표까지 달성 가능한지 보여주는 데 활용할 수 있다.

** -> 하지만 초기 고민했던 달성률 계산법이었고 서비스를 완성한 지금 시점은 다르다.. 전에는 생애주기별이어서 순차적 목표 달성이었지만 지금은 병렬적이기에 이 로직과는 다르다!**

10. 계좌 종류 검토

서비스에서 활용 가능한 계좌 종류도 검토했다.

후보 계좌

• CMA
• SOL-lite
• 주식종합계좌
• 연금저축계좌

각 계좌의 성격이 다르기 때문에,
부모 계좌와 자녀 계좌에서 어떤 계좌를 사용할지 구분해야 한다고 판단했다.

11. 증여 흐름 검토

증여 방식은 크게 두 가지로 나누어 생각했다.

1. 부모 은행 계좌에서 자녀 주식 계좌로 이전

• 현금 증여
• 적립식 펀드 증여
• 아동수당 기반 이체
• 자녀 계좌 내 ETF 투자

2. 부모 주식 또는 ETF를 자녀에게 이전

• ETF 직접 이전
• 평가액 계산 필요
• 기준일 전후 기간 평균가 고려
• 공휴일, 매매거래정지, 납회기간 고려
• 추후 확정 평가 필요

증여 판단 흐름

성년 / 미성년 여부 확인
→ 증여일 기준 전 10년 공제 금액 확인
→ 현재 적용 가능한 한도 계산
→ 이미 사용한 공제액 차감
→ 남은 비과세 가능 금액 산출

이렇게 계속 계속 기획에 시간을 투자하다가.. 중간발표날이 와버렸다...

중간 발표 정리

중간 발표에서는 우리 서비스의 방향과 핵심 기능을 다음과 같이 설명했다.

중간 발표 피드백 정리

내용이 너무 겹쳐 여기서는 피드백만 적어보자면 다음과 같다...

발표 흐름 관련 피드백

발표에서는 부모가 처한 상황을 더 명확히 설명해야 한다는 피드백을 받았다.

정리한 발표 흐름

부모는 자녀의 성장 자금과 증여 자금을 동시에 준비해야 함
→ 미래 자금 준비에 대한 부담감 발생
→ 부담감의 원인은 목표 금액 설정의 어려움과 달성 불안
→ 이를 해소하기 위한 목표 기반 투자 서비스

부모의 불안 원인

구현 관련 피드백

구현 범위에 대한 질문도 있었다.

MTS 구현

• 실시간 시세 조회 필요
• 매수·매도 거래 처리 필요
• 계좌 변동 히스토리 저장 필요
• 주문 관련 흐름 신경 필요
• 체결·미체결은 MVP에서 단순화 가능

인프라 및 보안

• 가족관계증명서 등 개인정보는 S3 업로드 지양
• 실제 서비스에서는 개인정보 저장 방식 신중히 설계 필요
• AWS 사용 시 권한과 보안 고민을 발표에서 어필 가능
• 발표에서는 “보안상 민감한 파일은 별도 관리한다”는 식으로 설명 필요

목표 설정 관련 피드백

목표 설정 기능에 대해서는 좋은 평가와 함께 보완 의견을 받았다.

받은 피드백

• 타겟이 명확해서 좋음
• 부모 상황에 맞는 목표 설정 방식 필요
• 온보딩 데이터 기반 개인화 필요
• 국가 통계 데이터 기반 유사군집 제공은 좋음
• 다만 군집유형별 데이터를 구하기 쉽지 않을 수 있음
• 데이터 출처와 확보 방법을 명확히 해야 함

표현 관련 피드백

• “하위 25%” 같은 표현은 부정적으로 느껴질 수 있음
• “상위 75%”처럼 긍정적이고 중립적인 표현 필요
• 금액 단위와 연도 단위 디테일 필요
• 그래프 위에 수치를 직접 표시하는 것이 좋음
• 차트 아래에 짧은 해설 문구를 추가하면 좋음

ETF 관련 피드백

ETF와 MTS 관련해서도 구체적인 피드백을 받았다.

받은 피드백

• 왜 ETF인지 근거 필요
• ETF 매수까지 이어지는 고객 여정 보강 필요
• 신한투자증권에서도 ETF 추천 기능은 존재할 수 있음
• 우리 서비스만의 차별점은 목표 기반 연결성
• ETF 선택 이후 바로 매수까지 이어지도록 플로우 보강 필요
• 캔들차트는 실제 서비스 참고해서 개선 필요
• 차트가 촘촘하지 않으면 이질감이 생김

UI 관련 피드백

UI 측면에서는 데이터 가시성에 대한 피드백을 받았다.

받은 피드백

• 금액 단위 표시 필요
• 연도 단위 표시 필요
• 그래프 위에 데이터 표시 필요
• 차트 아래 LLM 해설 2줄 정도 추가 가능
• 바 그래프는 적합하지 않을 수 있음
• 실제 MTS 화면을 참고한 차트 개선 필요
• ETF 매수 여정이 자연스럽게 이어져야 함

이젠 다시 피드백을 반영하러....

목표 도우미 구체화

중간 발표 이후 목표 도우미 기능을 더 구체화했다.

목표 금액 설정 도우미는 자녀를 키우는 부모가 특정 양육 목표를 위해 얼마를 준비해야 하는지 개인 맞춤형 목표 금액 분포를 제시해주는 기능이다.

사용자는 단일 금액을 추천받는 것이 아니라,
자신과 비슷한 조건의 부모들이 어느 정도 금액을 목표로 설정했는지 분포 형태로 확인할 수 있다. 또한 어떤 목표를 설정했는지도 보여주기로 했다...

회고

기획을 보완하면서 느낀 점은, 금융 서비스는 기능보다 흐름이 중요하다는 것이다.

처음에는 목표 설정, ETF 투자, 증여 관리처럼 개별 기능에 집중했다.

하지만 피드백을 받고 나니, 중요한 것은 이 기능들이 어떤 고객 여정 안에서 연결되는지였다.

최종적으로 우리 서비스의 흐름은 다음과 같이 정리할 수 있었다.

신한라이프 태아보험 고객
→ 자녀 출생
→ 아동수당 수령
→ 신한은행 계좌
→ 신한투자증권 자녀 계좌
→ ETF 장기 투자
→ 목표 달성 관리
→ 증여 한도 관리

이 흐름이 명확해지면서 우리 서비스가 단순한 ETF 투자 서비스가 아니라,
부모의 자녀 미래 자금 준비를 돕는 복합 금융 서비스라는 점도 더 분명해졌다.

앞으로는 목표 도우미에 활용할 데이터 근거를 더 보강하고,
ETF 매수까지 자연스럽게 이어지는 사용자 여정을 더 구체화해야겠다고 생각했다.

기획 단계에서는 서비스 방향이 어느 정도 잡혔다고 생각했지만, 피드백을 받으면서 우리가 더 구체화해야 할 부분이 많다는 것을 알게 되었다.

특히 다음 세 가지가 중요했다.

• 은행에서 증권으로 이어지는 교차 고객 확대 구조
• ETF와 증여를 서비스 핵심으로 가져가는 이유
• AI 추천 기능의 표현 방식과 규제 리스크

프로젝트 기본 정보

프로젝트 주제

우리가 정의한 프로젝트 주제는 다음과 같다.

자녀의 성장 자금과 독립 자금 준비를 돕는 목표 기반 증권 중심 금융 복합 서비스

부모는 자녀가 성장하는 과정에서 다양한 지출을 마주하게 된다.

• 초등학교 입학
• 학원비
• 교육비
• 여행
• 유학
• 대학 등록금
• 독립 자금
• 주거비
• 결혼 지원금

이러한 지출은 한 번에 준비하기 어렵기 때문에, 부모는 아이가 어릴 때부터 장기적으로 자금을 준비하고 싶어 한다.

우리 서비스는 이 과정에서 목표 기간과 목표 금액을 설정하고, ETF 중심의 장기 투자와 증여 관리를 통해 자녀의 미래 자산 형성을 돕는 것을 목표로 했다.

서비스 개요

초기 기획에서는 부모 계좌와 자녀 계좌를 역할별로 나누어 생각했다.

부모 계좌에서는 비교적 가까운 시점에 필요한 자금을 준비하고, 자녀 계좌에서는 성인이 되었을 때 사용할 수 있는 장기 자금을 마련하는 구조를 생각했다.

이를 통해 부모는 다음 정보를 확인할 수 있다.

• 현재 목표 달성률
• 미래 목표 달성 가능성
• 월 필요 납입액
• ETF 포트폴리오 현황
• 증여 비과세 한도 사용률
• 월간 투자 및 소비 리포트

타겟 고객과 니즈

타겟 고객

우리가 설정한 타겟 고객은 다음과 같았다.

자녀 계획이 있거나 자녀를 둔 부모 중, 신한은행과 신한투자증권을 함께 이용할 가능성이 있는 고객

특히 다음과 같은 고객을 중심으로 생각했다.

• 자녀의 미래 자금을 준비하고 싶은 부모
• 주식이나 ETF 투자가 익숙하지 않은 부모
• 신한은행을 이미 이용하고 있는 부모
• 아동수당이나 육아수당을 받고 있는 부모
• 자녀 명의 계좌 개설을 고민하는 부모

타겟 고객의 니즈

결국 이 서비스가 전달하고자 하는 핵심 가치는 다음과 같았다.

자녀의 미래 준비에 대한 부모의 불안감 해소

기술 스택

초기 기획안에서 정리한 기술 스택은 다음과 같다.

주요 기능

초기 기획에서 정리한 프로젝트 흐름은 다음과 같았다.

온보딩
→ 자녀 등록
→ 투자 성향 확인
→ 목표 설정
→ ETF 추천 및 포트폴리오 구성
→ 목표 달성률 확인
→ ETF 매수·매도
→ 월간 리포트 제공
→ 증여 비과세 한도 관리

주요 기능은 다음과 같이 정리했다.

수익 모델

초기 수익 모델은 직접 수익과 간접 수익을 함께 고려했다.

특히 미성년 자녀 계좌를 개설하고 장기적으로 유지하게 되면, 금융사 입장에서는 장기 고객을 확보할 수 있다는 점에서 의미가 있다고 보았다.

초기 일정

10. 우리가 묻고 싶었던 질문

기획을 구체화하면서 몇 가지 고민이 생겼다.

특히 복합 금융 서비스로서 자연스러운지, AI 추천 기능이 규제 측면에서 괜찮은지, 수익 모델이 충분한지에 대한 확신이 필요했다.

10-1. 복합 금융 서비스와 교차 고객 확대 구조

첫 번째 질문은 은행에서 증권으로 이어지는 흐름이 복합 금융 서비스로 자연스러운지였다.

우리가 생각한 흐름은 다음과 같았다.

마이데이터 기반 자산 관리
→ 목표 기반 여유자금 확보
→ 자녀 증권 계좌로 증여
→ ETF 장기 투자

이때 궁금했던 점은 다음과 같았다.

• 은행 고객을 증권 고객으로 유도하는 구조가 자연스러운가?
• 신한투자증권의 마이데이터를 사용해도 복합 금융 서비스라고 볼 수 있는가?
• 교차 고객 확대는 어느 수준에서 인정될 수 있는가?
• ETF 상품 구매 유도만으로도 계열사 연계라고 볼 수 있는가?
• 신한은행 고객의 자녀를 신한투자증권 고객으로 유도하는 것도 교차 고객 확대인가?

10-2. 마이데이터 활용 범위

두 번째 질문은 마이데이터 활용 범위였다.

우리는 부모의 소득, 지출, 저축 여력을 분석해 목표 납입 가능성을 제안하려고 했다.

이때 궁금했던 점은 다음과 같았다.

• 현업에서는 고객 데이터를 어느 수준까지 활용하는가?
• 고객에게 거부감이 적은 데이터 활용 방식은 무엇인가?
• 목표 설정 보조에 마이데이터가 꼭 필요한가?
• 소비 데이터 기반 추천이 자연스러운가?

10-3. AI ETF 추천 기능

세 번째 질문은 AI ETF 추천 기능이었다.

우리는 투자 성향과 목표를 기반으로 ETF를 추천하거나 포트폴리오를 제안하는 기능을 생각했다.

하지만 금융 서비스에서 추천이라는 표현은 투자자문이나 투자권유로 보일 수 있어 조심해야 한다고 생각했다.

그래서 다음을 질문했다.

• AI ETF 추천 기능을 제공할 때 투자자문처럼 보이지 않으려면 어떻게 해야 하는가?
• “참고용입니다”라는 문구만으로 충분한가?
• 알고리즘 기준을 어떻게 설명해야 하는가?
• 개별 ETF 추천이 가능한가?
• 투자 수익률 예측을 제공해도 되는가?

10-4. 수익 모델

네 번째 질문은 수익 모델이었다.

우리가 생각한 수익 모델은 다음과 같았다.

• ETF 거래 수수료
• 신한은행 고객의 신한투자증권 유입
• 자녀 계좌 개설을 통한 신규 고객 확보
• 장기 락인 효과

이 구조가 현업 관점에서 충분히 설득력 있는지 궁금했다.

10-5. 로그인과 자녀 인증

마지막으로 개발 관점에서 로그인과 자녀 인증 로직도 고민이었다.

일반 금융 앱과 동일한 인증 구조를 구현하기에는 프로젝트 상황상 제약이 있었다.

초기에는 다음 흐름을 생각했다.

이메일 회원가입
→ 이메일 로그인
→ 자녀 등록
→ 가족관계증명서 진위 확인
→ 자녀 계좌 연결

관련해서 다음 방식을 고려했다.

• 정부24 API
• 온라인 발급 주민등록 등초본 진위확인 API
• 가족관계증명서 기반 자녀 확인
• 증권 앱 내부 서비스라는 전제

11. 받은 피드백 정리

피드백을 통해 초기 기획에서 보완해야 할 부분이 명확해졌다.

핵심 피드백은 다음과 같았다.

11-1. 교차 고객 확대 구조를 더 명확히 해야 한다

처음에는 신한은행 고객을 신한투자증권 고객으로 유도하는 흐름만 생각했다.

하지만 피드백을 통해 단순히 “은행 고객을 증권으로 데려온다”는 설명만으로는 부족하다는 것을 알게 되었다.

받은 피드백

• 마이데이터를 사용하는 것만으로는 그룹사 연계라고 보기 어렵다.
• 교차 고객 확대는 실제 상품 가입이나 서비스 이용으로 이어져야 한다.
• 신한은행 고객이 신한투자증권 계좌를 개설하거나 ETF를 매수해야 고객 확대라고 볼 수 있다.
• 자녀가 새로 계좌를 개설하는 것은 신규 고객 유치에 가깝다.
• 부모 고객을 중심으로 계열사 이동 흐름을 더 명확히 해야 한다.

보완 방향

교차 고객 확대 구조는 다음과 같이 보완할 수 있다고 판단했다.

신한라이프 태아보험 가입자
→ 자녀 출생 후 아동수당 수령
→ 신한은행 아동수당 계좌 등록
→ 신한투자증권 자녀 계좌 개설
→ 아동수당 일부 ETF 투자
→ 자녀 장기 자산 관리

이 구조는 단순히 증권 앱 안에서 끝나는 것이 아니라, 보험, 은행, 증권이 연결되는 흐름이기 때문에 복합 금융 서비스로 더 설득력 있어 보였다.

11-2. 아동수당을 증권 계좌로 연결하는 흐름이 좋다

가장 인상적이었던 피드백은 아동수당이었다.

처음에는 부모의 여유자금을 마이데이터로 분석하고, 이를 자녀 증권 계좌로 증여하는 흐름을 생각했다.

하지만 피드백에서는 국가에서 지급되는 아동수당이나 육아수당을 증권 계좌로 끌어오는 기획이 더 자연스러울 수 있다고 했다.

받은 피드백

• 아동수당은 보통 은행 계좌로 지급된다.
• 이 돈을 증권 계좌로 이동시켜 투자에 활용하는 흐름이 좋다.
• 증권 계좌로 받으면 락인 효과가 생긴다.
• 해당 자금을 ETF 투자에 활용하면 거래 수수료 수익도 기대할 수 있다.
• 은행에서 증권으로 자금이 이동하는 구조가 명확해진다.

보완 방향

기존 흐름을 다음과 같이 바꿀 수 있다.

아동수당 입금
→ 신한은행 계좌 확인
→ 자녀 증권 계좌 개설 유도
→ 아동수당 일부 자동 이체
→ ETF 장기 투자
→ 목표 달성률 관리

이 흐름은 “은행에서 증권으로 이어지는 복합 금융 서비스”라는 설명에 더 적합하다고 느꼈다.

11-3. 마이데이터가 꼭 필요한지 다시 고민해야 한다

초기 기획에서는 목표 설정을 돕기 위해 마이데이터를 적극적으로 활용하려고 했다.

하지만 피드백에서는 마이데이터 사용 자체보다, 왜 필요한지 명확해야 한다는 의견을 받았다.

받은 피드백

• 마이데이터 활용이 꼭 필요한지 고민해야 한다.
• 목표 설정은 부모의 자산 규모와 반드시 일치하지 않을 수 있다.
• 고객의 목표는 자산 규모보다 의지와 우선순위에 따라 달라질 수 있다.
• 고객 동의를 받는다면 데이터 활용 자체가 거부감을 주지는 않는다.
• 토스처럼 정보를 잘 보여주면 오히려 긍정적으로 느낄 수 있다.
• 소비 데이터는 목표 납입 가능성을 제안하는 데 활용 가능하다.

보완 방향

마이데이터는 목표 금액을 대신 정해주는 용도보다는, 다음 기능에 활용하는 것이 더 적절하다고 판단했다.

• 월 납입 가능 금액 참고
• 소비 패턴 분석
• 고정비 확인
• 여유자금 계산
• 목표 달성 가능성 보정
• 월말 소비 리포트

즉, 목표를 대신 정해주는 AI가 아니라, 사용자가 정한 목표를 현실적으로 유지할 수 있는지 도와주는 보조 도구로 쓰는 것이 더 적절하다.

11-4. AI가 꼭 필요한 기능인지 검토해야 한다

초기에는 AI ETF 추천, 목표 설정 보조, 투자 시뮬레이션 등을 생각했다.

하지만 피드백에서는 일반적인 계산식으로 가능한 기능까지 AI로 처리할 필요는 없다는 의견을 받았다.

받은 피드백

• AI가 꼭 필요한지 고민해야 한다.
• 수식으로 가능한 기능은 수식 기반이 더 안정적이다.
• 목표 달성률, 월 납입액, 복리 계산은 AI보다 수식이 적합하다.
• AI 추천 알고리즘은 검증이 필요하다.
• 타사 사례를 확인하고 안정성을 확보해야 한다.
• 투자성향 기반 개별 종목 추천은 적합하지 않을 수 있다.

보완 방향

AI 기능과 수식 기반 기능을 분리해야 한다고 판단했다.

즉, AI는 계산 자체를 담당하기보다는 계산 결과를 이해하기 쉽게 설명하는 역할로 쓰는 것이 더 적절하다.

11-5. ETF 추천은 투자권유처럼 보이지 않도록 조심해야 한다

AI ETF 추천 기능에 대해서는 특히 신중한 피드백을 받았다.

받은 피드백

• 추천 알고리즘의 객관적인 기준을 설명해야 한다.
• 단순히 “참고용” 문구만으로 충분하지 않을 수 있다.
• 리스팅 기준을 명확히 해야 한다.
• 투자성향 기반 개별 종목 추천은 위험할 수 있다.
• 금융투자협회 가이드라인은 참고할 수 있지만, 개별 ETF 추천에는 추가 기준이 필요하다.
• 별도의 스코어링 체계를 만드는 것이 좋다.
• 투자 수익률 예측은 위험하므로 피하는 것이 좋다.

보완 방향

ETF 추천이라는 표현보다는 다음 표현이 더 적절하다고 판단했다.

• ETF 후보 리스트
• 목표 기반 ETF 탐색
• 포트폴리오 구성 참고
• 위험도 기반 자산 비중 안내
• 장기 투자 성향별 ETF 분류
• 목표 달성 시뮬레이션

또한 개별 ETF를 직접 추천하기보다, 객관적인 기준에 따라 정렬하거나 분류하는 방식이 더 안전하다고 보았다.

예를 들어 다음 기준을 사용할 수 있다.

• 운용 규모
• 거래량
• 총보수
• 추적 지수
• 변동성
• 과거 수익률
• 분배금 여부
• 위험 등급
• 자산군 분류

11-6. 왜 ETF인지 명확히 해야 한다

멘토님 피드백 중 하나는 “꼭 ETF여야 하는 이유가 무엇인가?”였다.

초기에는 ETF가 장기투자에 적합하다는 생각으로 기획했지만, 더 설득력 있는 근거가 필요했다.

받은 피드백

• ETF 선택의 당위성을 명확히 해야 한다.
• 개별 주식과의 차별점을 설명해야 한다.
• ETF는 수익을 기대하는 상품이므로 위험성도 설명해야 한다.
• 자녀 계좌에서는 잦은 매매보다 장기 보유 전략이 더 적합할 수 있다.
• 미성년 자녀 계좌에서 사고팔고 하는 것 자체가 세금 이슈와 연결될 수 있다.

보완 방향

ETF를 선택한 이유는 다음과 같이 정리할 수 있다.

• 소액 분산 투자 가능
• 장기 투자에 적합
• 개별 종목보다 분산 효과
• 지수 기반 투자 가능
• 정기 적립식 투자와의 결합 용이
• 자녀 독립 자금처럼 장기 목표와 적합
• 매수 후 장기 보유 전략과 연결 가능

다만 ETF도 원금 손실 가능성이 있는 투자상품이므로, 서비스 내에서 위험성을 충분히 안내해야 한다.

11-7. 증여 비과세 기준을 정확히 확인해야 한다

증여 관련 피드백도 중요했다.

우리는 미성년자 10년 2,000만 원 비과세 한도를 기준으로 증여 관리 기능을 생각하고 있었다.

하지만 실제로는 단순히 “2,000만 원까지 괜찮다”라고 말하기 어렵다.

받은 피드백

• 비과세 기준이 투자금액 기준인지 원금 기준인지 확인해야 한다.
• 분할 납입 시 평가금액이 영향을 줄 수 있다.
• 매월 10만 원씩 입금해서 2,000만 원을 만드는 방식이 항상 유리하지 않을 수 있다.
• 2,000만 원을 먼저 증여하고 신고해두는 방식과 차이가 있을 수 있다.
• 증여 신고 시점과 평가 기준을 명확히 파악해야 한다.
• 비과세 한도 기능을 잘 풀어내면 서비스 설득력이 커질 수 있다.

보완 방향

증여 기능은 단순 계산기가 아니라, 정확한 기준을 확인한 뒤 설계해야 한다.

서비스에서는 다음 기능을 고려할 수 있다.

• 최근 증여 내역 입력
• 10년 누적 증여액 계산
• 남은 비과세 가능 금액 확인
• 적립식 증여 시뮬레이션
• 증여 신고 필요 여부 안내
• 홈택스 신고 가이드
• 세무사 상담 연결
• 투자금과 평가금액 기준 구분 설명

11-8. 로그인과 자녀 계좌 개설 흐름을 명확히 해야 한다

개발 관점에서는 자녀 계좌 개설 흐름이 빠져 있다는 피드백을 받았다.

받은 피드백

• 증권 앱 안의 서비스라고 생각하고 가도 괜찮다.
• 이메일 로그인은 프로젝트 상황상 가능하다.
• 하지만 자녀 계좌 개설 흐름은 서비스 단계에 포함되어야 한다.
• 가족관계증명서, 주민등록등본 등 자녀 확인 절차를 고려해야 한다.
• 온보딩과 목표 설정 사이에 계좌 개설 단계가 필요하다.

보완 방향

서비스 흐름은 다음과 같이 보완할 수 있다.

회원가입 / 로그인
→ 자녀 등록
→ 가족관계 확인
→ 자녀 증권 계좌 개설 또는 연결
→ 목표 설정
→ 아동수당 계좌 연결
→ ETF 투자 계획 설정

MVP에서는 실제 금융 인증을 완벽히 구현하기 어렵기 때문에, mock 인증이나 간소화된 흐름으로 구현하되, 발표에서는 실제 서비스 기준 흐름을 함께 설명하는 것이 좋다고 판단했다.

12. 피드백 이후 보완한 서비스 방향

피드백을 반영하면 서비스 방향은 다음과 같이 더 명확해진다.

기존 방향

부모 자산 분석
→ 목표 설정
→ 자녀 계좌 증여
→ ETF 투자

보완 방향

신한라이프 태아보험 고객
→ 자녀 출생
→ 신한은행 아동수당 계좌
→ 신한투자증권 자녀 계좌 개설
→ 아동수당 및 여유자금 투자
→ 목표 기반 자산 관리
→ 증여 한도 관리

이렇게 바꾸면 보험, 은행, 증권이 연결되고, 자금 흐름도 더 자연스러워진다.

13. Action Items

피드백을 받은 뒤 앞으로 해야 할 일을 정리했다.

13-1. 세무 및 법적 리스크 검토

• 미성년 자녀 증여 비과세 기준 확인
• 10년 2,000만 원 한도 기준 확인
• 분할 증여 시 평가 기준 확인
• 투자금 기준과 평가금액 기준 차이 확인
• 증여 신고 시점 확인
• 자녀 계좌 내 잦은 매매의 리스크 확인
• 장기 보유 전략의 타당성 확인

13-2. AI 기능 범위 재정의

• AI가 필요한 기능과 필요하지 않은 기능 분리
• 수식 기반 계산 우선 적용
• AI는 설명과 리포트 중심으로 활용
• ETF 추천 표현 재검토
• 투자권유로 보이지 않는 문구 설계
• 알고리즘 기준 명확화
• 타사 AI 투자 서비스 사례 조사

13-3. ETF 선택 이유 보강

• ETF와 개별주식 차이 정리
• ETF의 장기투자 적합성 정리
• 소액 분산투자 장점 정리
• 정기 적립식 투자와의 연결성 정리
• 원금 손실 가능성 안내
• 목표 기간별 위험도 안내

13-4. 교차 고객 확대 구조 보완

• 신한은행 고객을 신한투자증권 고객으로 유도하는 구체적 흐름 정리
• 신한라이프 태아보험 고객 활용 시나리오 검토
• 아동수당 계좌를 증권 계좌로 연결하는 흐름 구체화
• 자녀 계좌 개설 유도 방식 정리
• ETF 매수까지 이어지는 고객 전환 구조 정리

13-5. UX 및 계좌 개설 흐름 보완

• 자녀 등록 단계 구체화
• 가족관계 확인 절차 정리
• 자녀 증권 계좌 개설 단계 추가
• 아동수당 계좌 변경 또는 연결 흐름 검토
• 목표 설정 온보딩 개선
• 투자 위험 고지 화면 추가
• 증여 가이드 화면 추가

13-6. 객관적 시장 근거 보완

• 미성년자 증권 계좌 증가 자료
• 자녀 ETF 투자 관련 기사
• 아동수당 활용 사례
• 증권사 자녀 자산관리 서비스 사례
• 삼성증권, 신한투자증권 등 경쟁사 사례
• 마미톡 등 커뮤니티 반응은 보조 자료로 활용

14. 피드백을 통해 느낀 점

이번 피드백을 통해 가장 크게 느낀 점은, 아이디어가 좋아 보이는 것과 실제 금융 서비스로 설득력 있는 것은 다르다는 점이었다.

처음에는 “부모의 불안감을 해소하는 자녀 미래 자산 서비스”라는 방향이 충분히 명확하다고 생각했다.

하지만 현업 관점에서는 다음 질문에 더 구체적으로 답해야 했다.

• 왜 은행에서 증권으로 연결되어야 하는가?
• 왜 ETF여야 하는가?
• AI가 꼭 필요한가?
• 투자 추천으로 오해받지 않으려면 어떻게 해야 하는가?
• 증여세 기준은 정확한가?
• 실제 고객 유입은 어디에서 시작되는가?
• 상품 가입까지 이어지는 구조가 있는가?

피드백을 받고 나니, 우리 서비스의 핵심은 단순히 목표 설정이나 ETF 매수가 아니라는 것이 더 분명해졌다.

진짜 중요한 것은 다음 흐름이었다.

부모의 불안
→ 자녀 미래 목표 설정
→ 아동수당 및 여유자금 활용
→ 자녀 증권 계좌 연결
→ ETF 장기 투자
→ 증여 한도 관리
→ 장기 고객 확보

즉, 우리 서비스는 그냥 투자 서비스가 아니라, 부모의 자녀 미래 준비를 계열사 금융 서비스와 연결하는 복합 금융 서비스가 되어야 한다.

앞으로는 이 피드백을 바탕으로 교차 고객 확대 구조를 더 명확히 하고, ETF와 증여, 아동수당을 중심으로 서비스 흐름을 다시 정리해야겠다고 생각했다.

그래도 내가 전에 팀원들에게 제시했던 아동수당, 증여에 대한 긍정적인 평가를 받아서 기분이 좋았던 것 같다 ㅎㅎ 그래서 이전에는 mvp에서 빠지고 후순위가 되었던 이 기능들이 우선순위가 올라갔다!!

프로젝트 초반에는 기획을 구체화하느라 정신없이 시간이 지나갔다.
조금 늦은 감은 있지만, 프로젝트가 시작된 지 약 2주가 지난 지금 시점에서 팀빌딩 당시로 돌아가 우리가 어떤 과정을 통해 주제를 정했는지 회고해보려고 한다.

1. 기말 프로젝트 주제

우리가 받은 기말 프로젝트 주제는 다음과 같았다.

특정 고객군을 위한 증권 중심 복합 금융 서비스

이번 주제에서 중요한 것은 단순히 하나의 금융 기능을 만드는 것이 아니었다.

팀이 직접 특정 고객군을 정의하고, 그 고객이 실제로 어떤 금융 니즈를 가지고 있는지 파악해야 했다.
또한 증권을 중심으로 은행, 카드, 보험 등 여러 금융 서비스가 자연스럽게 연결되는 흐름을 설계해야 했다.

그래서 우리는 주제를 정할 때 다음 질문을 계속 고민했다.

우리는 누구를 위한 서비스를 만들 것인가?
그 고객에게 왜 증권 서비스가 필요한가?
복합 금융 서비스가 어떤 흐름으로 연결될 수 있는가?

2. 첫 번째 브레인스토밍

주제를 받은 뒤 팀원들과 먼저 브레인스토밍을 진행했다.

처음부터 하나의 주제를 바로 정하기보다는, 각자 생각나는 아이디어를 자유롭게 공유하고 다음날까지 더 고민해온 뒤 다시 이야기해보기로 했다.

이때 나왔던 아이디어는 다음과 같았다.

여러 아이디어가 나왔지만 바로 하나로 정하기는 어려웠다.
팀원들마다 관심 있는 고객군과 서비스 방향이 달랐고, 어떤 주제가 프로젝트 목적에 더 잘 맞는지에 대한 의견도 조금씩 달랐다.

그래서 각자 관심 있는 아이디어를 더 분석해오고, 다음 회의에서 근거를 바탕으로 다시 논의하기로 했다.

나는 이 중에서 1번 아이 미래 자산 투자와 5번 시니어 대상 금융 서비스에 관심이 갔다.

3. 내가 처음 관심을 가졌던 주제

3-1. 아이 미래 자산 투자

먼저 아이 미래 자산 투자 아이디어는 프로젝트 주제와 잘 맞는다고 생각했다.

최근 주식 시장에 대한 관심이 높아지면서 자녀 명의 증권 계좌를 개설하거나, 자녀의 미래 자금을 투자로 준비하려는 부모들이 늘어나고 있다는 점이 눈에 들어왔다.

또한 육아 서비스나 커뮤니티에서도 자녀 자산 투자에 대한 니즈를 확인할 수 있었다.
부모 입장에서는 아이의 교육비, 독립 자금 등 미래에 필요한 큰돈을 어떻게 준비해야 할지 고민할 수밖에 없다.

이 주제는 단순히 “투자 서비스”가 아니라, 부모의 생애 단계와 자녀의 성장 흐름을 함께 다룰 수 있다는 점에서 매력적이었다.

예를 들어 아이의 출생, 입학, 성년 등 성장 단계에 맞춰 목표 자금을 설정하고, 매달 소액을 ETF나 안정적인 금융상품에 투자하는 구조를 만들 수 있다고 생각했다.

또한 조부모나 친척이 현금 대신 투자금 형태로 선물하는 기능까지 확장할 수 있어, 가족형 금융 서비스로 발전시킬 수 있을 것 같았다.

3-2. 시니어 대상 금융 서비스

두 번째로 관심을 가졌던 주제는 시니어 대상 금융 서비스였다.

은퇴 이후 자산 관리에 대한 막막함을 느끼는 시니어층을 대상으로 하면 타겟 고객군이 명확할 것 같다고 생각했다.

출퇴근길 지하철에서도 아버지 나이대의 직장인들이 주식 화면을 자주 보고 있는 모습을 보며, 시니어층 역시 증권 서비스에 관심이 크다는 생각을 한 적이 있었다.

다만 추가로 조사해보니 이미 시니어를 대상으로 한 금융 서비스나 증권사 서비스가 다양하게 존재하고 있었다.
그래서 “우리 서비스만의 차별점이 무엇인가?”를 고민했을 때 뚜렷한 방향을 잡기가 쉽지 않았다.

팀원들과 논의하는 과정에서도 시니어 대상 금융 서비스는 너무 흔할 수 있다는 의견이 있었다.
또한 은퇴자금이나 노후자산 설계에 대한 금융 지식이 부족하면 기획 과정에서 어려움이 클 수 있다는 의견도 나왔다.

이 의견에 공감하면서 자연스럽게 시니어 주제는 우선순위에서 멀어지게 되었다.

4. 최종 후보로 좁혀진 두 가지 아이디어

여러 아이디어를 두고 팀원들과 논의한 결과, 최종적으로는 다음 두 가지 방향으로 주제가 좁혀졌다.

• 1번. 아이 미래 자산 구축 서비스
• 2번. POS 기반 소상공인 현금흐름 분석 서비스

두 아이디어 모두 특정 고객군이 명확했고, 금융 서비스로 확장할 수 있는 가능성이 있었다.

그래서 단순히 아이디어 이름만 보고 결정하기보다는 다음 기준으로 비교해보기로 했다.

• 타겟 고객군이 명확한가
• 실제 니즈가 존재하는가
• 증권 서비스와 자연스럽게 연결되는가
• 복합 금융 서비스로 확장 가능한가
• 제한된 기간 안에 구현 가능한가
• 데이터 확보가 현실적인가

5. 1번과 2번 아이디어 비교

이렇게 비교해보니 두 주제의 성격이 조금 더 명확해졌다.

1번 아이디어는 부모와 자녀라는 고객군이 분명했다.
또한 자녀 증권계좌, ETF 투자, 증여, 아동수당 등으로 자연스럽게 확장할 수 있었다.

반면 2번 아이디어는 데이터 기반 서비스라는 점에서 설득력이 있었다.
POS 매출, 카드 매출, 계좌 입금 데이터를 기반으로 소상공인의 영업 안정성과 현금흐름을 분석하고, 이를 금융기관이 참고할 수 있는 리포트로 제공할 수 있기 때문이다.

하지만 2번은 실제 데이터를 어떻게 확보할 것인지가 가장 큰 고민이었다.

6. 후보 1. 아이 미래 자산 구축 서비스

1번 아이디어는 아이의 미래를 위해 저축 대신 장기 투자로 자산을 모으는 가족형 증권 서비스였다.

서비스의 핵심 타겟은 젊은 부모였다.
특히 자녀의 미래 자금, 교육비, 독립 자금 등에 관심은 있지만 어디서부터 준비해야 할지 막막한 부모를 대상으로 할 수 있다고 보았다.

이 서비스의 핵심 가치는 다음과 같았다.

아이가 성장하는 동안
부모가 작은 금액을 꾸준히 투자하며
자녀의 미래 자산을 준비할 수 있도록 돕는 서비스

단순히 큰돈을 한 번에 투자하는 구조가 아니라, 매달 3만 원, 5만 원, 10만 원처럼 부담 없는 금액을 장기적으로 투자하는 구조를 생각했다.

주요 기능

예를 들어 “민준이 성장펀드”처럼 자녀의 이름이 들어간 목표를 만들면, 부모 입장에서도 단순한 투자 계좌가 아니라 아이의 미래를 준비하는 공간처럼 느껴질 수 있다고 생각했다.

또한 아이가 초등학교에 입학할 때, 중학교에 들어갈 때, 성인이 될 때 예상 자산이 얼마나 되는지 보여줄 수 있다면 부모가 장기 목표를 더 직관적으로 이해할 수 있을 것 같았다.

7. 후보 2. POS 기반 소상공인 현금흐름 분석 서비스

2번 아이디어는 소상공인의 POS, 카드 매출, 계좌 데이터를 기반으로 현금흐름과 영업 안정성을 분석하는 서비스였다.

소상공인은 매출 변동성이 크고 수입이 불규칙한 경우가 많다.
그래서 기존 신용평가 방식만으로 실제 상환능력이나 영업 안정성을 판단하기 어려울 수 있다.

이 서비스는 POS 매출 데이터, 카드 매출 데이터, 계좌 입금 데이터 등을 기반으로 소상공인의 매출 안정성, 추정 영업이익, 환불률, 성장률, 현금흐름 안정성 등을 분석하는 방향이었다.

분석 결과는 소상공인에게는 경영 현황 대시보드로 제공하고, 금융기관에는 참고 리포트로 제공할 수 있다고 생각했다.

주요 기능

이 아이디어는 데이터 기반이라는 점에서 설득력이 있었다.

소상공인에게는 경영 현황을 한눈에 보여주는 도구가 될 수 있고, 은행이나 증권사 입장에서는 대출 심사 보조 자료나 금융상품 추천에 활용할 수 있었다.

다만 우리가 산출하는 점수를 “신용점수”라고 표현하면 실제 신용평가처럼 보일 수 있기 때문에, “금융건강 리포트”나 “영업 안정성 지표”처럼 참고 자료의 성격으로 표현하는 것이 더 적절하다고 보았다.

8. 내가 1번 아이디어에 더 마음이 갔던 이유

두 아이디어 모두 장점이 있었지만, 개인적으로는 1번 아이 미래 자산 구축 서비스에 더 마음이 갔다.

가장 큰 이유는 프로젝트 주제와의 적합성이었다.

이번 프로젝트는 특정 고객군을 정의하고, 증권을 중심으로 복수의 금융 서비스를 연결하는 것이 중요했다.

아이 미래 자산 구축 서비스는 부모와 자녀라는 고객군이 명확했다.
또한 증권 계좌, ETF 투자, 증여, 아동수당, 가족 참여 등 다양한 금융 서비스로 자연스럽게 확장할 수 있었다.

반면 POS 기반 소상공인 서비스도 흥미로운 아이디어였지만, 실제 데이터 확보가 가장 큰 고민이었다.

팀원 중에는 땡겨요 데이터를 활용해보자는 의견도 있었다.
하지만 실제 프로젝트에서 해당 데이터를 얻기는 어렵다고 판단했다.

물론 MVP 단계에서는 CSV 업로드 방식으로 구현할 수 있다.
하지만 서비스의 설득력을 높이려면 데이터 흐름이 현실적이어야 한다고 생각했다.

이런 점에서 1번 아이디어가 구현 가능성과 확장성 측면에서 더 적합하다고 보았다.

그래서 나는 팀원들에게 아이 미래 자산 구축 서비스가 이번 프로젝트 주제와 더 잘 맞고, 실제 구현 가능성도 높을 것 같다는 의견을 냈다.

9. 의견 조율을 통해 정해진 방향

팀원들과 여러 차례 의견을 나누면서 최종적으로는 1번 아이디어를 중심으로 가기로 했다.

처음부터 모두가 같은 의견이었던 것은 아니었다.
각자 관심 있는 주제가 달랐고, 어떤 주제가 더 차별성 있는지, 어떤 주제가 구현 가능성이 높은지, 프로젝트 주제와 더 잘 맞는지에 대한 생각도 조금씩 달랐다.

하지만 오히려 그 과정에서 주제를 더 깊이 바라볼 수 있었다.

단순히 “재미있어 보이는 아이디어”를 고르는 것이 아니라, 다음 기준을 함께 고려하게 되었다.

• 타겟 고객군이 명확한가
• 실제 니즈가 존재하는가
• 증권이 서비스의 중심에 자연스럽게 들어가는가
• 복수의 금융 서비스로 확장할 수 있는가
• 제한된 기간 안에 구현할 수 있는가
• 데이터 확보와 서비스 흐름이 현실적인가

결국 우리는 아이 미래 자산 구축 서비스를 중심으로 각자 더 구체화해보고, 타겟층과 핵심 기능을 정리하기로 했다.

10. 팀빌딩 회고

이번 팀빌딩 과정에서 느낀 점은 좋은 주제는 단순히 아이디어가 좋아 보이는 것만으로 정해지지 않는다는 것이다.

특히 금융 서비스 기획과 개발이 함께 필요한 프로젝트에서는 고객군, 니즈, 금융 흐름, 구현 가능성, 데이터 확보 가능성을 함께 봐야 했다.

처음에는 여러 아이디어가 흩어져 있었지만, 팀원들과 논의하고 각자 조사한 내용을 공유하면서 점점 하나의 방향으로 좁혀갈 수 있었다.

돌아보면 이 과정은 단순히 주제를 정하는 시간이 아니었다.
우리가 앞으로 어떤 고객의 문제를 해결하고 싶은지 정리하는 시간이었다.

앞으로는 아이 미래 자산 구축이라는 큰 방향 안에서 타겟 고객군을 더 구체화하고, 실제 부모가 느끼는 불안과 니즈를 서비스 기능으로 어떻게 풀어낼 수 있을지 고민해보려고 한다.

0602

• 사용자는 자신이 보유한 주식을 시장가로 매도할 수 있습니다.
• 최대한 실제 금융 환경을 충분히 고려하여 api를 설계하세요.

AI를 활용하여 프롬프트를 작성하고 API를 해결해볼 것이다.

AI에게는 다음과 같은 상황을 고려하여 물어보았다.

• 주식을 매도를 할때는 동시성 문제가 발생을 할 수 있다고 생각을 하였다.

• 또한 매도를 할때 매도를 하려는 수량이 원래 가지고 있던 수량보다 많은 양을 택했을때도 문제가 생길 수 있다.

• 그리고 장외 시간인 경우 등 매도 자체가 불가능한 상황이 있을 수가 있다.

  그래서 다음과 같이 API를 만들기 앞서 평소에 쓰던 프롬프트 설계를 사용하여 프롬프트를 작성후 지피티를 활용하여 작성을 하였다.

> 너는 “증권/금융 백엔드 시니어(API 설계 + 동시성 + 정합성 + 운영 전문가)”다.

이후 API가 다뤄야 할 도메인 상황을 설명했다.

> 사용자는 본인이 보유한 주식을 시장가로 매도한다.  
> 주문은 즉시 체결되지 않을 수 있으며, 주문 접수와 체결은 분리될 수 있다.  
> 중복 매도, 중복 잔고 감소 방지, 감사/추적 가능성, 실패 케이스를 충분히 고려해야 한다.

또한 결과물이 과제 요구사항에 맞게 나오도록 필수 항목을 지정했다.

- URL
- Method
- Request
- Response
- 상태코드
- 정책

특히 금융 API에서는 정상 응답보다 실패 상황과 정합성 처리가 중요하다고 판단해 다음 내용도 함께 요청했다.

- 보유 수량 부족
- 중복 요청
- 다중 탭 요청
- 네트워크 재시도
- 멱등성 처리
- 동시성 제어
- 부분 체결
- 거래정지 및 장외 시간
- 장애 상황 대응

처음에는 AI가 상태조회 API, 취소 API, 체결내역 조회 API까지 함께 제안했다.  
하지만 과제의 핵심은 “주식 매도 API 하나를 설계하는 것”이었기 때문에, 이후 프롬프트를 수정해 시장가 매도 주문 접수 API 하나에 집중하도록 다시 요청했다.

최종적으로는 다음과 같은 방향으로 프롬프트를 보완했다.

> 주식 매도 API는 하나만 설계한다.  
> 단, 실제 금융 환경을 고려해 주문 접수와 체결은 분리해서 설명한다.  
> 필수 항목인 URL, Method, Request, Response, 상태코드, 정책이 반드시 포함되도록 한다.

이 과정을 통해 AI의 초안을 그대로 사용하지 않고, 과제 조건에 맞게 범위를 조정하고 필요한 내용을 선별했다.

URL

/api/v1/accounts/{accountId}/orders/sell/market

Method

POST

Request

Header

Authorization: Bearer {accessToken}
Idempotency-Key: 7b8e4c1a-5c9d-4a2b-91fd-11b7f0d2a901
Content-Type: application/json

• Authorization: 로그인 사용자를 확인하기 위한 JWT
• Idempotency-Key: 중복 매도 요청을 막기 위한 키
• Content-Type: application/json

Body

{

  "instrumentId": "005930",  //종목 식별자
  "quantity": 10,  //매도 수량
  "orderType": "MARKET",  //주문 유형
  "side": "SELL"  //매도주문

}

Request Validation

성공 응답

HTTP Status

201 Created

Response Body

{
  "orderId": "ord-20260519-000001",
  "accountId": "acc-10001",
  "instrumentId": "005930",
  "side": "SELL",
  "orderType": "MARKET",
  "requestedQuantity": 10,
  "filledQuantity": 0,
  "remainingQuantity": 10,
  "status": "ACCEPTED",
  "message": "시장가 매도 주문이 접수되었습니다.",
  "riskNotice": "시장가 주문은 시장 상황에 따라 예상 가격과 실제 체결 가격이 달라질 수 있으며, 부분 체결 또는 미체결될 수 있습니다.",
  "createdAt": "2026-05-19T16:20:00+09:00",
  "traceId": "trc-01HX9ZK8W3Q2"
}

실패 응답

실패 응답은 다음과 같이 반환한다.

{
  "timestamp": "2026-05-19T16:20:00+09:00",
  "errorCode": "HOLDING_001",
  "message": "매도 가능 수량이 부족합니다.",
  "reason": "보유 수량 10주 중 7주가 이미 다른 매도 주문에 예약되어 있어 현재 매도 가능 수량은 3주입니다.",
  "clientAction": "주문 수량을 줄이거나 기존 미체결 매도 주문을 취소한 뒤 다시 시도하세요.",
  "retryable": false,
  "traceId": "trc-01HX9ZK8W3Q2"
}

상태코드

성공 상태코드

실패 상태코드

정책은 잔고와 같이사용자의 자산과 직접 연결되기 때문에 중복 주문 방지, 보유 수량 정합성, 체결 지연, 장애 상황까지 고려하여 짜도록 설계하였다.

정책

주문 접수/체결 분리

API 성공은 체결 완료가 아니라 접수 완료를 의미한다.

시장가 위험 고지

실제 체결 가격은 접수 시점에 확정되지 않는다.

보유 수량 예약

주문 접수 시 보유 수량을 바로 차감하지 않고 예약한다.

멱등성

같은 주문 요청이 중복 처리되지 않도록 Idempotency-Key를 사용한다.

동시성 제어

동일 계좌/종목 동시 매도 요청을 락과 트랜잭션으로 제어한다.

거래 가능 시간

정규장 장중에만 시장가 매도를 허용한다.

부분체결

일부만 체결될 수 있으며 잔여 수량은 계속 관리한다.

취소 정책

이미 체결된 수량은 취소할 수 없고 잔여 수량만 취소 가능하다.

재시도

같은 주문 재시도는 반드시 같은 멱등성 키를 사용한다.

Rate Limit

과도한 주문 요청을 제한한다.

감사 로그

주문 요청과 상태 변경 이력을 추적 가능하게 남긴다.

장애 대응

외부 시스템 지연과 내부 장애를 고려해 상태를 관리한다.

AI 사용 로그

AI가 잘해준 점은 생각보다 더욱 더 실패 상황을 자세히 설계해준 부분이다. 또한 내가 고려하지 못했던 거래정지 상태라던지 다영한 상황에 대해 고려하여 실패코드를 작성을 한 것 같다. AI를 활용하면서 API를 작성하는 과정에서 처음에는 주문 매도를 위해 조회를 해야하는 다른 로직들 API까지 작성을 해주었다. 이 부분을 제외하고 매도 부분만 집중하고 싶어서 매도 부분 로직에만 집중을 하도록 프롬프트를 수정을 하였다.

또한 처음에는 단순히 요구 사항만 적고 요청을 했지만 추후에는 맨 위에 적은것과 같이 좀 더 구체화하여 프롬프트를 작성하였다.

초기 버전은 아래와 같다.

초기:

사용자는 자신이 보유한 주식을 시장가로 매도할 수 있습니다.
최대한 실제 금융 환경을 고려하여 API를 설계해주세요.

필수로 포함해야 하는 내용은 다음과 같습니다.

1. URL
2. Method
3. Request
4. Response
5. 실패 응답
   - 인증 실패
   - 계좌 권한 실패
   - 보유 수량 부족
   - 존재하지 않는 종목
   - 거래 정지 종목
   - 시장가 주문 불가능 시간
   - 중복 요청
   - 동시성 문제
   - 외부 시스템 오류
6. 상태 코드
7. 이 API를 사용할 때 고려해야 할 정책
8. 동시성 이슈

이외에도 AI가 작성해준 실패응답에는 타임스탬프가 없어 추가를 하였다.

내가 중요하게 생각하는 객체 지향의 중요한 특징

내가 생각하는 객체 지향의 가장 중요한 특징은 상속이라고 생각한다.

이에 대해 말하기 앞서 상속에 대해 간단히 정의를 하겠다.

상속은 간단하게 말을 하면 부모 클래스를 자식 클래스가 상속을 받는 개념이다. 즉 부모가 가진 클래스를 재사용하여 자식 클래스를 생성하는 것이다.

상속의 중요성

상속이 왜 중요하고 필요한가에 대해 알아보기 위해 예시를 들어서 설명을 해볼 것이다.

폰으로 예시를 들어보자면 폰은 삼성폰, 아이폰 이 두가지로 나누어질 수 있다.

이 두가지 삼성폰, 아이폰에는 폰이라는 공통된 기능을 하는 객체이다.

폰에는 크게 브랜드, 배터리라는 속성을 가질 수 있다. 이 폰들은 기본적으로 켜고 끄고, 충전하고 결제를 할 수 있다.

상속을 사용하지 않는다면?

만약 이 두 객체를 자바로 설계할때 상속을 사용을 안하게 된다면 다음과 같이 될 것이다.

class SamsungPhone {
    String brand;
    int battery;

    public SamsungPhone(String brand, int battery) {
        this.brand = brand;
        this.battery = battery;
    }

    public void pay() {
        System.out.println("삼성페이로 결제합니다.");
    }

    public void turnOn() {
        System.out.println(brand + " 폰 전원을 켭니다.");
    }

    public void turnOff() {
        System.out.println(brand + " 폰 전원을 끕니다.");
    }

    public void charge() {
        battery = 80;
        System.out.println(brand + " 폰을 충전했습니다.");
    }


}

class IPhone {
    String brand;
    int battery;

    public IPhone(String brand, int battery) {
        this.brand = brand;
        this.battery = battery;
    }

    public void pay() {
        System.out.println("애플페이로 결제합니다");
    }

    public void turnOn() {
        System.out.println(brand + " 폰 전원을 켭니다.");
    }

    public void turnOff() {
        System.out.println(brand + " 폰 전원을 끕니다.");
    }

    public void charge() {
        battery = 100;
        System.out.println(brand + " 폰을 충전했습니다.");
    }


}

위와 같이 쓰일 것이다.

이때 이 두 클래스를 보면 공통된 속성과 기능들이 존재한다. 지금은 폰이 두 종류지만 더 많은 브랜드를 만들게 되면 같은 코드가 중복이 될 것이다.

상속을 사용한다면?

이 문제점을 해결하기 위해 객체지향의 특징인 상속을 사용한다.

상속을 사용을 할때 폰이라는 공통된 속성, 기능을 가진 클래스를 만들고 이를 상속 받는 구조로 만들어질 것 이다.

class Phone {
    String brand;
    int battery;

    public Phone(String brand, int battery) {
        this.brand = brand;
        this.battery = battery;
    }

    public void turnOn() {
        System.out.println(brand + " 폰 전원을 켭니다.");
    }

    public void turnOff() {
        System.out.println(brand + " 폰 전원을 끕니다.");
    }


    public void charge() {
        battery = 100;
        System.out.println(brand + " 폰을 충전했습니다.");
    }


    public void pay() {
        System.out.println("휴대전화로 결제합니다.");
    }
}

이런식으로 부모 클래스를 만들고 다음과 같이 부모 클래스를 상속받는 자식 클래스를 만들 것이다.

class SamsungPhone extends Phone {

    public SamsungPhone(String brand, int battery) {
        super(brand, battery);
    }

    public void pay() {
        System.out.println("삼성페이를 사용합니다.");
    }
}

이런식으로 extends를 사용해서 상속을 받고 pay()를 보면 오버라이딩을 한다.

아이폰도 위와 같이 구현할 수 있고 자식 클래스에서 기능도 추가할 수 있다.

class IPhone extends Phone {

    public IPhone(String brand, int battery) {
        super(brand, battery);
    }

    public void pay() {
        System.out.println(애플페이를 사용합니다.");
    }

     public void sendImessage() {
        System.out.println("아이메세지를 보냅니다");
    }
}

상속의 장점

이런 식으로 객체지향을 설계하다보면 코드의 중복성을 줄일 수 있는 장점이 있다. 또한 필요한 기능을 유연하게 추가할 수 있다.

이때 상속이 중요하다고 해서 상속을 무분별하게 사용하는 것이 좋다고 생각하는 것이 아니다.

상속을 무분별하게 사용을 하다보면 결합도가 높아지기에 유지보수가 어려워질 수도 있다.

나의 생각

내가 상속을 중요하다 생각하는 것은 이러한 상속의 개념으로부터 객체지향의 다른 특징들인 다형성, 추상화 등 다른 특징들이 탄생한다고 생각하기 때문이다. 위 예제로 살펴보았을때 삼성페이, 애플페이 등 다양한 pay()형태로 나타낼 수 있고, 상속을 고민하는 과정에서 공통된 기능을 뽑아내며 추상화를 할 수 있다. 또한 여기서 battery라는 필드를 다른 클래스에서 접근을 못하게 막으며 캡슐화를 할 수 있다.

이러한 객체 지향 특징들을 보면 상속이라는 개념은 다른 객체 지향 특징들이 나타날 수 있게 해준 기반이라고 생각한다. 이 개념을 기반으로 적절하게 나머지 특징을 쓰는것이 좋지 않을까..

그래서 이번 글에서는 추상화가 무엇인지, 그리고 추상클래스와 인터페이스가 어떤 차이를 가지는지 Phone 예시를 통해 정리해보려고 한다.

추상화란?

추상화는 여러 대상의 공통점을 뽑아내어 공통만 남기는 것이다.

수업시간에 실습으로 진행한 phone으로 예시를 들어볼 것이다. 예를 들어 삼성폰, 아이폰, 샤오미폰은 다 다르게 생겼고 기능도 조금씩 다르다.

이 폰들에 공통적으로 들어가는 것은 다음과 같다.

• 브랜드
• 배터리
• 전원 켜기
• 배터리 확인

이때 결제 방식은 다음과 같이 다를 수 있다.

• 삼성폰 → 삼성페이
• 애플폰 → 애플페이

이때 pay()는 폰마다 다르니까 자식이 구현을 한다.

위와 같이 애플폰도 같은 형식으로 만들어주었다.

인터페이스란?

인터페이스에 적은 기능이 꼭 존재하여야한다.

예를 들어 결제 기능은 폰만 가질 수 있는 것이 아니다.

• 삼성폰도 결제할 수 있다
• 스마트워치도 결제할 수 있다
• 카드도 결제할 수 있다

이럴 때 중요한 것은 “이 객체가 어떤 종류인가?”보다 “이 기능을 할 수 있는가?” 이다.

그래서 인터페이스는 보통 클래스가 반드시 구현해야 하는 기능의 약속이라고 말할 수 있다.

추상화와 인터페이스

이 두 가지에 대한 생각을 정리해보겠다.

추상화는 복잡한 대상을 있는 그대로 전부 다루는 것이 아니라, 그중에서 공통된 핵심만 뽑아 하나의 개념으로 정리하는 과정이라고 생각한다. 예를 들어 삼성폰과 아이폰은 서로 다른 제품이지만, 전원을 켜고 배터리를 가지는 phone이라고 정의할 수 있다.

인터페이스는 기능에 더욱 초점을 맞춘다. 인터페이스는 특정 기능을 반드시 제공해야 한다는 규칙에 가깝다. 예를 들어 pay()처럼 결제 기능은 폰뿐 아니라 카드,애플워치 등 다른 디바이스나 기기도 가질 수 있다. 이런 경우 인터페이스는 “무엇인가”보다 “무엇을 할 수 있는가”를 표현하는 데에 더 적합하다.

이번 장은 가상 면접 사례로 배우는 대규모 시스템 설계 기초 10장 알림 시스템 설계에 대한 내용이다.

고객에게 중요한 정보를 비동기적으로 제공한다.

✅ 1단계 문제 이해 및 설계 범위 확정

- 모바일 Push 알림, 이메일, SMS 모두 지원
- 연성 실시간(실시간이지만, 어느 정도 지연은 허용)
- IOS, Android, Desktop, Laptop 모두 지원
- 알림 생성의 주체는, 프로그램이 생성할 수도 있고 스케줄링 작업으로 처리할 수도 있다.
- 하루 천만 건의 모바일 Push 알림
- 백만 건의 SMS 메세지
- 5백만 건의 이메일

✅ 2단계 개략적 설계안 제시 및 동의 구하기

알림 유형별 지원 방안

• iOS 푸시 알림

1. 알림 제공자(Provider)

   • 알림 요청을 만들어, Apple Push 알림 서비스로 보내는 주체
   • 단말 토큰 : 알림 요청을 보내기 위한 고유 식별자
   • 페이로드 : 알림 내용을 담은 JSON Dictionary

2. APNS : 애플이 제공하는 원격 서비스로, 푸시 알림을 기기로 보내는 역할을 담당

3. iOS 단말

• 안드로이드

  • APNS 대신 FCM 사용

• SMS 메시지

  • 메시지를 보낼 때는 Twilio, Nexmo 같은 제3 사업자의 서비스를 많이 이용

• 이메일

  • 고유 이메일 서버를 구축할 역랑은 갖추고 있지만 대부분은 이메일 서비스를 사용

• 연락처 정보 수집 절차

  • 회원가입시 수집

• 알림 전송 및 수신 절차

  • 알림을 요청하는 N개의 서비스 존재 -> MSA, 크론잡 또는 분산 시스템 컴포넌트일 수 있음
  • 알림 시스템은 알림 전송을 위한 API을 제공해야 하며, 서드 파티 서비스에게 전달할 payload를 만들어 낼 수 있어야 함

• 서드 파티 서비스 선택 시 확장성과 중국과 같은 폐쇄적인 시장도 고려하여 선택해야 함

• 문제점

  • SPOF, 규모 확장성, 성능 병목과 같은 이슈도 고려해야 함

• 사용자 단말 정보를 캐시에 저장

• 알림 유형별 Message Queue 를 두어 알림 시스템과 worker의 결합을 느슨하게 함

• 알림 전송 API -> 스팸 방지를 위한 Authentication과 Authorization 이 필요함

• 알림 validation, DB/cahce query, 알림 전송

✅ 3단계 상세 설계

안정성

• 데이터 손실 방지
• 알림 중복 전송 방지

추가적으로 필요한 컴포넌트 및 고려사항

• 알림 템플릿
• 알림 설정
• 전송률 제한
• 재사도 방법
• 푸시 알림과 보안
• 큐 모니터링
• 이벤트 추적
  • 알림 확인율, 클릭율, 실제 앱으로 이어지는 비율

수정된 설계안

• 알람 서버에 인증과 전송률 제한 기능 추가
• 재시도 기능 추가
• 전송 템플릿 사용으로 일관성 확보
• 모니터링, 추적 시스템 추가

✅ 크롤러 사용 용도

• 검색 엔진 인덱싱
• 웹 아카이빙
• 웹 마이닝
• 웹 모니터링

✅ 1단계 - 문제 이해 및 설계 범위 확정

절차

1. url 집합이 주어지면 해당 url들이 가리키는 모든 웹 페이지 다운로드
2. 다운받은 웹페이지에서 url들을 추출
3. 추출된 url들을 다운로드할 url 목록에 추가하고 위 과정 반복

1. 검색 인덱스 용 크롤러를 설계
2. 매달 10억 개의 웹 페이지를 수집
3. 새로 만들어진 웹이나 수정된 웹도 고려
4. 수집한 웹은 5년간 저장
5. 중복된 컨텐츠는 무시

주의해야할 속성

• 규모 확장성
• 안정성(robustness)
• 예절(politeness)
• 확장성(extensibility)

✅ 개략적 설계안 제시 및 동의 구하기

시작 URL 집합

• 웹 크롤러가 크롤링을 시작하는 출발점
• 전체 웹을 크롤링해야하는 경우에는 크롤러가 가능한 한 많은 링크를 탐색할 수 있도록 하는 URL을 고르는 것이 바람직
• 일반적으로 전체 URL 공간을 작은 부분집합으로 나누거나 주제별로 다른 URL을 사용하는 전략을 사용

미수집 URL 저장소

• 크롤링 상태는 다운로드할 URL, 다운로드된 URL의 두 가지로 나눠 관리
• 미수집 URL 저장소는 다운로드할 URL을 관리하는 컴포넌트이고, FIFO 큐로 구현

HTML 다운로더

• 인터넷에서 웹 페이지를 다운로드하는 컴포넌트

도메인 이름 변환기

• 웹 페이지를 다운받으려면 URL을 IP 주소로 변환하는 절차가 필요

콘텐츠 파서

• 웹페이지를 다운로드하면 저장 공간 낭비를 방지하기 위해 파싱과 검증 절차를 거쳐야 함

중복 컨텐츠 검증

• 웹 페이지의 해시 값을 비교하여 데이터 중복을 줄이고 데이터 처리에 소요되는 시간을 줄임

콘텐츠 저장소

• 콘텐츠 저장소는 HTML 문서를 보관하는 시스템

-> 저장소를 구현하기 위해 데이터 유형, 크기, 저장소 접근 빈도, 데이터의 유효 기간 등을 종합적으로 고려

URL 추출기

• URL 추출기는 HTML 페이지를 파싱하여 링크를 골라내는 역할

URL 필터

• URL 필터는 특정한 콘텐츠 타입이나 파일 확장자를 갖는 URL, 접속 시 오류가 발생하는 URL, 접근 제외 목록에 포함된 URL 등을 크롤링 대상에서 배제하는 역할

이미 방문한 URL

• 이미 방문한 URL이나 미수집 URL 저장소에 보관된 URL을 추적할 수 있도록 하는 자료 구조(블룸 필터, 해시 테이블) 사용

URL 저장소

• URL 저장소는 이미 방문한 URL을 보관하는 저장소

웹 크롤러 작업 흐름

1. 시작 URL을 미수집 URL 저장소에 저장
2. HTML 다운로더는 미수집 URL 저장소에서 URL 목록을 가져옴
3. HTML 다운로더는 도메인 이름 변환기를 사용하여 URL의 IP 주소를 알아내고, 접속하여 다운받음
4. 콘텐츠 파서는 다운된 HTML 페이지를 파싱하여 올바른 형식을 갖춘 페이지 검증
5. 콘텐츠 파싱과 검증이 끝난후 중복 콘텐츠인지 확인
   • 이미 저장소에 있는 콘텐츠인 경우 처리하지않고 버림
   • 저장소에 없는 콘텐츠인 경우 저장소에 저장한 뒤 URL 추출기로 전달
6. URL 추출기는 해당 HTML페이지에서 링크를 골라내고 URL 필터로 전달
7. 남은 URL만 중복 URL 판별 단계로 전달
8. 이미 처리한 URL인지 확인
9. 저장소에 없는 URL은 URL 저장소와 미수집 URL 저장소에 저장

✅ 3단계 상세 설계

DFS vs BFS

• 페이지: 노드

• 하이퍼링크: 엣지

• 유향 그래프 탐색 과정

• DFS은 좋은 선택이 아닐 가능성 높음

• 그래프 크기가 클 경우 어느 정도로 깊숙이 가게 될지 가늠하기 어렵기 때문에 DFS를 사용하지 않고 주로 BFS를 사용

• BFS: FIFO

문제점

• 한 페이지에서 나오는 링크 상당수는 같은 서버로 되돌아감

• 크롤러는 같은 호스트에 속한 많은 링크를 받기 위해 바빠지는데, 링크들을 병렬로 처리하게 되면 서버는 과부하로 죽어버림

• 예의 없는 크롤러(impolite)

• 표준적 BFS 알고리즘은 URL 간에 우선순위를 두지 않음

• 모든 페이지가 같은 중요도를 갖지 않기 때문에 트래픽의 양, 업데이트 빈도 등 기준에 따라 차등적으로 구별하는 것이 맞을 것

미수집 URL 저장소

URL 사이의 우선순위와 신선도를 구별하는 예의 있는 크롤러를 구현 가능

예의

• 웹 크롤러는 수집 대상 서버로 짧은 시간 안에 너무 많은 요청을 보내는 것을 삼가야 함

• 너무 많은 요청을 보내는 것은 무례한 일이며 때로는 DoS 공격으로 간주

• 위 내용을 만족하기 위해 웹 사이트의 호스트명과 다운로드를 수행하는 워커 스레드 사이의 관계를 유지해야함!

• 큐 라우터(queue router)

  • 같은 호스트에 속한 URL은 언제나 같은 큐로 가도록 보장하는 역할

• 매핑 테이블(mapping table)

  • 호스트 이름과 큐 사이의 관계를 보관하는 테이블

• FIFO 큐

  • 같은 호스트에 속한 URL은 언제나 같은 큐에 보관

• 큐 선택기(queue selector)

  • 큐들을 순회하면서 큐에서 URL을 꺼낸후 다운로드하도록 지정된 워커 스레드에 전달하는 역할

• 워커 스레드(worker thread)

  • 전달된 URL을 순차적으로 다운로드하며, 작업들 사이에 delay를 둘 수 있음

우선순위

유용성에 따라 URL의 우선순위를 나눌 때는 페이지 랭크, 트래픽 양, 갱신 빈도 등 다양한 척도를 사용할 수 있음

• 순위결정장치(prioritizer): URL 우선순위를 정하는 컴포넌트
• 큐에 URL을 저장하기 전에 prioritizer 를 거치도록 설계
• prioritizer
  • 입력받은 URL을 우선순위 계산
• queue
  • 우선순위별로 큐가 하나씩 할당됨
• queue selector
  • 임의 큐에서 처리할 URL을 꺼내는 역할, 순위가 높은 큐에서 더 자주 꺼내도록 프로그래밍되어 있음
• front queue
  • 우선순위 결정 과정을 처리
• back queue
  • 크롤러가 예의 바르게 동작하도록 보증

신선도

• 웹 페이지의 변경 이력 활용
• 우선순위를 활용하여, 중요 페이지 자주 재수집

미수집 URL 저장소를 위한 지속성 저장장치

• 대부분 URL은 디스크에 두지만 I/O 비용을 줄이기 위해 메모리 버퍼에 큐를 두는 것
• 버퍼에 있는 데이터는 디스크에 주기적으로 저장

HTML 다운로더

• Robots.txt
  • 로봇 제외 프로토콜이라고 부르는 robots.txt는 웹 사이트가 크롤러와 소통하는 표준 방법
  • robots.txt 파일들은 거푸 다운로드하는 것을 피하기 위해, 이 파일은 주기적으로 다시 다운받아 캐시에 보관

성능 최적화

• 분산 크롤링

  • 성능을 높이기 위해 크롤링 작업을 여러 서버에 분산

• 도메인 이름 변환 결과 캐시

  • DNS 조회 결과로 얻어진 도메인 이름과 IP 주소 사이의 관계를 캐시에 보관하여 cron job 등을 돌려 주기적으로 갱신

• 지역성

  • 서버를 지역별로 분산

• 짧은 타임아웃

  • 응답이 느리거나 응답하지 않는 서버를 대비하기 위해 wait time 을 설정

안정성

• 안정 해시(consistent hashing)
  • 크롤링 서버을 분산할 때 적용
• 크롤링 상태 및 수집 데이터 저장
  • 서버 장애를 대비하여 수집된 데이터를 지속적으로 저장장치에 기록
• exception handling
• data validation

확장성

시스템은 항상 진화하기 때문에 새로운 형태의 콘텐츠를 쉽게 지원할 수 있도록 설계해야 함

문제 있는 콘텐츠 감지 및 회피

• 중복 컨텐츠
  • 해시나 체크섬을 사용하여 중복 콘텐츠 탐지
• 거미 덫(크롤러를 무한 루프에 빠지도록 설계한 웹 페이지)
  • URL 최대 길이를 제한 -> 완벽히 회피하기 어렵기 때문에 URL 필터 목록 활용
• 데이터 노이즈
  • 가치없는 데이터 제외

✅ 4단계 마무리

• 서버 측 렌더링
  • 많은 웹 사이트는 자바스크립트, AJAX 등의 기술을 사용해서 링크를 즉석으로 만들기 때문에 페이지를 파싱하기 전에 서버측 렌더링을 적용
• 원치 않는 페이지 필터링
  • 스팸성 걸러내기
• 데이터베이스 다중화 및 샤딩
• 수평적 규모 확장성
  • 무상태 서버 유지 중요
• 가용성, 일관성, 안정성
• 데이터 분석 솔루션

✅ 1단계 - 문제 이해 및 설계 범위 확정

URL 단축
URL redirection
0-9,A-Z
높은 가용성과 규모 확장성, 그리고 장애 감내가 요구 됨
단축 URL에는 숫자와 영문자를 사용할 수 있음
단축된 URL은 삭제나 갱신을 할 수 없움

✅ 2단계 - 개략적 설계안 제시 및 동의 구하기

API 엔드포인트

• URL 단축용 엔드포인트
  • 새 단축 URL을 생성하고자 하는 클라이언트는 이 엔드포인트에 단축할 URL을 인자로 실어서 POST 요청을 보내야 함

• URL 리디렉션용 엔드포인트
  • 원래 URL로 보내주기 위한 용도

URL 리디렉션

• 원래 url로 변경 후 301 응답의 Location 헤더에 넣어 반환

• 서버 부하를 줄이는 것이 중요: 301 Permanent moved 사용
• 트래픽 분석이 중요 (클릭 발생률, 발생위치 추적): 302 Found

• 서버 로그에 찍히므로

URL 단축

www.tinyurl.com/[해시값]

• 어떻게 해시값을 결정하는가
• 해시함수 조건
  1. 입력으로 주어지는 긴 URL이 다른 값이면 해시 값도 달라야한다.
  2. 계산된 해시 값은 원래 입력으로 주어졌던 긴 URL로 복원될 수 있어야한다.

✅ 3단계 - 상세 설계

데이터 모델

• 모든걸 해시 테이블( 메모리 비용 ) -> <단축URL, 원래 URL>의 순서쌍을 관계형 데이터베이스에 저장삭

해시 함수

• 원래 URL을 단축 URL로 변환

해시 값 길이

[0-9] → 10개 [a-z] → 26개 [A-Z] → 26개 -> 총 62개 문자

• 3650억 개: 단축해서 저장해야 할 URL 총 개수
  • hashValue의 길이: n이라고 할때: n을 정하기 위해서는 62 n≥3650 억인 n의 최솟값을 찾아야 함
• n=7 이면 3.5조개의 URL을 만들 수 있음

1) 해시 후 충돌 해소

• 7글자만 사용하면 -> 서로 다른 URL이 같은 hashValue를 갖는 충돌 발생 가능성이 증가

• 해결법: 충돌이 해소될 때까지 특정 문자열을 뒤에 덧붙여 재생성

• 예시 과정:

  1. 기본 해시값: abc1234
  2. 이미 존재하는 값이면 충돌 발생
  3. 사전 정의된 추가 문자열 붙여 재시도
  • abc1234 + "0" → 충돌?
  • abc1234 + "1" → 충돌 해소될 때까지 반복

• 충돌 감지 법

  • db조회 -> 오버헤드 큼
  • 데이터베이스 대신 블룸 필터를 사용해서 성능을 높일 수 있음

2) base-62 변환

• 단축 URL 구현 시, 긴 숫자를 짧은 문자열로 표현하기 위해

• 진법 변환(Base Conversion)* 방식을 사용하는 것이 일반적

  • Base62 = 한 자리에 표현 가능한 문자가 총 62개

  • 숫자: 0-9 → 10개

  • 소문자: a-z → 26개

  • 대문자: A-Z → 26개

    총 10 + 26 + 26 = 62개 문자

    따라서 Base62 한 자리는 다음을 의미한다:

    10진수	Base62 문자
    0 ~ 9	0 ~ 9
    10 ~ 35	a ~ z
    36 ~ 61	A ~ Z

• 사용 이유

  이유	설명
  문자 1개당 정보량 ↑	62가지 표현 가능 → 매우 효율적
  URL에 안전한 문자 구성	특수문자 없음 → 인코딩 필요 X
  더 짧은 URL을 제공	예: 10진수 8자리 숫자 → Base62 숫자 5자리 가능

• ex) 11157 = 2 × 62² + 55 × 62¹ + 59 × 62⁰ = [2, 55, 59] = =[2,T,X]=2TX

즉, 숫자를 Base62 문자로 치환해 짧고 충돌 없는 단축 URL key를 만든다.

해시 후 충돌 해소 vs base62

✅ URL 단축기 상세 설계

Base62 진법 변환 기법을 기반으로 단축 URL을 생성

처리 흐름

1. 긴 URL 입력
2. DB 조회
- 동일한 URL이 이미 저장되어 있다면?  
→ 기존 단축 URL 반환
3. 신규 URL이면
   - 전역적으로 유일한 ID 생성
     (DB 기본 키로 사용)
   - 생성된 ID를 Base62로 변환 → 단축 URL 생성
   - (ID, 단축URL, 원본URL) DB에 저장
4. 단축 URL 반환

✅ URL 리디렉션 상세 설계

URL 단축기는 읽기(redirect)가 쓰기보다 훨씬 많은 시스템 -> 따라서 성능 향상을 위해 <단축 URL, 원본 URL> 매핑을 캐시에 저장

처리 흐름

1. 사용자가 단축 URL을 클릭
2. 로드밸런서가 해당 요청을 웹 서버에 전달
3. 웹 서버는 캐시에서 단축 URL을 조회
   - 캐시에 있으면 → 원본 URL 반환
4. 캐시에 없다면 DB 조회
   - DB에도 없으면 → 404 Not Found(잘못된 url 입력)
5. DB에서 가져온 URL을 캐시에 저장한 뒤 사용자에게 반환

이번 장에서는 분산 시스템을 위한 유일 ID 생성기 설계에 대해 알아볼 예정이다.

분산 시스템에서 유일한 id 생성기를 어떻게 설계할 것인가.

✅ 1단계: 문제 이해 및 설계 범위 확정

ID는 유일해야 한다. (unique)
ID는 숫자로만 구성되어있어야 한다.
ID는 발급 날짜에 따라 정렬 가능해야한다.
ID는 64비트로 표현될 수 있는 값이어야한다.
ID는 발급 날짜에 따라 정렬 가능해야 한다.
초당 10,000개의 ID를 만들 수 있어야 한다.

✅ 2단계 - 개략적 설계안 제시 및 동의 구하기

다중 마스터 복제 (multi-master replication)
UUID(Universally Unique Identifier)
티켓 서버(ticket server)
트위터 스노플레이크 접근법

다중 마스터 복제 (multi-master replication)

• auto_increment 기능을 활용

• k = 서버의 수

• 다음 키 = 이전 키 + k

• 장점

  • 데이터베이스 수를 늘리면 초당 생산 가능 ID 수도 늘어난다,

• 한계

  • 여러 데이터 센터에 걸쳐 규모를 늘리기 어렵다.
  • ID의 유일성은 보장되겠지만 그 값이 시간 흐름에 맞추어 커지도록 보장할 수는 없다.
  • 서버를 추가하거나 삭제할 때도 잘 동작하도록 만들기 어렵다.

UUID(Universally Unique Identifier)

• UUID: 컴퓨터 시스템에 저장되는 정보를 유일하게 식별하기 위한 128비트 짜리 수

• 각 웹서버는 별도의 id 생성기 사용하여 독립적인 id 생성

• 장점

  • 생성이 단순, 서버 사이의 조율이 필요없어 동기화 이슈 없음
  • 규모 확장 쉬움

• 한계

  • 길다
  • 시간순 정렬 불가능
  • 숫자가 아닌 값

티켓 서버(ticket server)

• 티켓서버: auto_increment 기능을 갖춘 데이터베이스 서버, 중앙집중형으로 하나만 사용

• 장점

  • 숫자로만 구성된 ID를 쉽게 생성, 구현하기 쉬움

• 한계

  • 단일장애지점

트위터 스노플레이크 접근법

• 각개격파전략(divide and conque): 생성해야하는 id의 구조를 여러 section으로 분할

  ~

• sign bit: 1비트, 음수와 양수를 구별하는데 사용

• timestamp: 41비트, 기원 시각(epoch) 이후로 몇 밀리초가 경과했는지를 나타내는 값

• 데이터센터 ID: 5비트, 2^5 =32개의 데이터센터를 지원

• 서버 ID: 5비트, 데이터 센터 당 32개의 서버를 사용할 수 있음

• 일련번호(sequence): 12비트, 각 서버에서는 ID를 생성할 때마다 이 일련번호를 1만큼 증가, 이 값은 1밀리초가 경과할 때마다 0으로 초기화

✅ 3단게 상세 설계

데이터 센터 ID와 서버 ID

사전에 시스템이 시작되기 전에 결정, 운영중 바뀌지 않음

타임스탬프, 일련번호

ID 생성기가 돌아가는 중에 만들어짐

타임스탬프

• 41비트
• 시간 순서대로 정렬 가능

일련번호

• 12비트 이므로 4096개의 값을 가질 수 있음
• 어떤 서버가 같은 밀리초 동안 하나 이상의 ID를 만들어 낸 경우에만 0보타 큰 값을 갖게 됨

✅ 4단계 마무리

시계 동기화(clock synchronization)

• Snowflake 방식은 시간 기반 ID를 사용하기 때문에 서버마다 시간이 다르면 문제가 발생함
• NTP로 해결

각 섹션의 길이 최적화

• 동시성이 낮고 수명이 긴 애플리케이션: 일련번호 절의 길이를 줄이고 타임스탬프 절의 길이를 늘리는 것이 효과적

고가용성(high availability)

• ID 생성기는 필수 불가결(mission critical) 컴포넌트 이므로 아주 높은 가용성을 제공해야 할 것

다음은 키 값 저장소 설계에 대한 내용을 정리한 것이다.

• 키 값 저장소: 키 값 데이터 베이스라고도 불리는 비 관계형 데이터 베이스

• 고유한 식별자를 키로 가져야 한다.

• 키와 값 사이의 연결 관계를 키 값 쌍이라고 부른다.

• put(key, value): 저장

• get(key): 조회

- 키-값 쌍의 크기는 10KB이하이다.
- 큰 데이터를 저장할 수 있어야 한다.
- 높은 가용성을 제공해야 한다. 따라서 시스템은 설사 장애가 있더라도 빨리 응답해야 한다.
- 높은 규모 확장성을 제공해야 한다. 따라서 트래픽 양에 따라 자동적으로 
서버 증설/삭제가 이루어져야 한다.
- 데이터 일관성 수준은 조정이 가능해야 한다.
- 응답 지연시간이 짧아야 한다.

단일 서버 키-값 저장소

• 빠른 속도 보장하지만 모든 데이터를 메모리 안에 두는 것은 불가능

• 해결법: 데이터 압축, 자주 쓰이는 데이터는 메모리에, 나머지는 디스크에 저장

분산 키-값 저장소(= 분산 해시 테이블)

cap 정리

데이터 일관성, 가용성, 파티션 감내 라는 세 가지 요구사항을 동시에 만족하는 분산 시스템을 설계하는 것은 불가능하다는 정리

• 데이터 일관성(C)

  • 분산 시스템에 접속하는 모든 클라이언트는 어떤 노드에 접속했느냐와 관계 없이 언제나 같은 데이터를 보게 되어야 한다.

• 가용성(A)

  • 분산 시스템에 접속하는 클라이언트는 일부 노드에 장애가 발생하더라도 항상 응답을 받을 수 있어야 한다.

• 파티션 감내(P)

  • 파티션은 두 노드 사이에 통신 장애가 발생하였음을 의미한다. 즉, 파티션 감내는 네트워크에 파티션이 생기더라도 시스템이 계속 동작해야 한다는 것을 뜻한다.

• CP시스템

• AP시스템

• CA시스템

• 통상 네트워크 장애는 피할 수 없는 것으로 여겨지기 때문에 분산시스템은 반드시 파티션 문제를 감내할 수 있도록 설계되어야 한다.

  -> 따라서 CA시스템은 실질 존재하지 않는다.

분산 시스템에서 대부분 데이터는 여러 노드에 복제되어 보관

이상적 상태

: 네트워크가 파티견되는 상황이 절대로 안일어날 것 n1에 기록된 데이터는 n2, n3에 복제 -> 데이터 일관성과 가용성 만족

실세계

파티션 문제는 불가피함. 파티션 문제 발생시, 일관성과 가용성 사이에서 하나를 선택해야한다.

• 가용성 대신 일관성을 선택(CP시스템)

  • 세 서버 사이에 생길 수 있는 데이터 불일치 문제를 피하기 위해 n1과 n2에 대해 쓰기 연산을 중단시켜야 하는데, 그렇게 하면 가용성이 깨진다.
  • 만약에 일관성이 깨질 수 있는 상황이 발생하면 이런 시스템인 상황이 해결될 때 까지는 오류를 반환해야 한다.

• 인관성 대신 가용성을 선택(AP시스템)

  • 낡은 데이터를 반환할 위험이 있다고 해도 계속 읽기 연산을 허용해야 한다.
  • 그리고 n1과 n2에서는 계속 쓰기 연산을 허용할 것이고, 파티션 문제가 해결된 후에 새 데이터를 n3에 전송할 것이다.

시스템 컴포넌트

데이터 파티션

• 데이터를 여러 서버에 고르게 분산할 수 있는가
• 노드가 추가되거나 삭제될 때 데이터의 이동을 최소화 할 수 있는가
• 장점
  • 규모 확장 자동화
  • 다양성

데이터 다중화

• 높은 가용성과 안정성을 확보하기 위해서는 데이터를 N개 서버에 비동기적으로 다중화할 필요가 있다.
• 여기서 N은 튜닝 가능한 값이다.

• 가상 노드를 사용한다면 위와 같이 선택한 N개의 노드가 대응될 실제 물리 서버의 개수가 N보다 작아질 수 있다.

  • 이를 해결하기 위해서는 같은 물리 서버를 중복 선택하지 않도록 해야 한다.

• 같은 데이터 센터에 속한 노드는 정전, 네트워크 이슈 등의 문제를 동시에 겪을 가능성이 있다.

-> 데이터의 사본은 다른 센터의 서버에 보관하고, 센터들은 고속 네트워크로 연결한다.

데이터 일관성

• 여러 노드에 다중화된 데이터는 적절히 동기화 되어야한다
• 정족수 합의 프로토콜을 사용해 일관성 보장

- N=사본 개수
- W=쓰기 연산에 대한 정족수
    쓰기 연산이 성공한 것으로 간주되려면 적어도 W개의 서버로부터 쓰기 연산이 성공했다는 응답을 받아야 한다.
- R=읽기 연산에 대한 정족수
    읽기 연산이 성공한 것으로 간주되려면 적어도 R개의 서버로부터 응답을 받아야 한다.

W+N>N: 강한 일관성이 보장

일관성을 보증할 최신 데이터를 가진 노드가 최소 하나는 겹칠 것이기 때문이다.

- R=1, W=N : 빠른 읽기 연산에 최적화된 시스템
- W=1, R=N : 빠른 쓰기 연산에 최적화된 시스템
- W+R>N : 강한 일관성 보장
- W+R<=N : 강한 일관성의 보장이 없다.

요구되는 일관성 수준에 따라 조정하면 된다.

일관성 모델

• 강한 일관성:

  • 모든 읽기 연산은 가장 최근에 갱신된 결과를 반환한다. 다시 말해서 클라이언트는 절대로 낡은 데이터를 보지 못한다.

• 약한 일관성

  • 읽기 연산은 가장 최근에 갱신된 결과를 반환하지 못할 수 있다.

• 최종 일관성

  • 약한 일관성의 한 형태로, 갱신 결과가 결국에는 모든 사본에 반영(==동기화) 되는 모델이다.

비 일관성 해소 기법 : 데이터 버저닝

데이터를 다중화하면 가용성은 높아지지만 사본 간 일관성이 깨질 가능성이 높다.

-> 해결법: 버저닝, 벡터 시계

• 버저닝: 데이터를 변경할 때마다 해당 데이터의 새로운 버전을 만드는 것

• 벡터 시계:

  • [서버, 버전]의 순서쌍을 데이터에 매단 것이다.
  • 어떤 버전이 선행 버전인지, 후행 버전인지, 아니면 다른 버전과 충돌이 있는지 판별하는 데에 쓰인다.
  • D([S1, v1], [S2, v2] ... [Sn, vn])
    • D는 데이터, vi는 카운터, si는 서버 번호
    • [Si, vi]가 있다면 vi를 증가시킨다.
    • 그렇지 않으면 새 항목[Si, 1]를 만든다.

• 단점

  • 충돌 감지 및 해소 로직이 클라이언트에 들어가야 하므로, 클라이언트 구현이 복잡해진다.
    • [서버:버전] 의 순서쌍 개수가 굉장히 빨리 늘어난다

장애 감지

두대 이상 서버에서 장애를 감지해야 장애가 발생했다고 판단한다.

• 모든 노드 사이에 멀티캐스팅 채널 구축하는 것이 가장 쉬움

• 하지만 노드가 많으면 비효율적

• 가십 프로토콜

  • 각 노드는 멤버십 목록을 유지한다. 멤버십 목록은 각 멤버 Id와 그 박동 카운터 쌍의 목록이다.
  • 각 노드는 주기적으로 자신의 박동 카운터를 증가시킨다.
  • 각 노드는 무작위로 선정된 노드들에게 주기적으로 자기 박동 카운터 목록을 보낸다.
  • 박동 카운터 목록을 받은 노드는 멤버십 목록을 최신 값으로 갱신한다
  • 어떤 멤버의 박동 카운터 값이 지정된 시간 동안 갱신되지 않으면 해당 멤버는 장애 상태인 것으로 간주한다.

일시적 장애 처리

• 엄격한 정족수 접근법 -> 읽기와 쓰기 연산을 금지

• 느슨한 정족수 접근법 -> 이 조건을 완화하여 가용성을 높인다

영구 장애 처리

머클트리 사용

• 머클트리:
  • 해시 트리라고도 불리며 각 노드에 그 자식 노드들에 보관된 값의 해시, 또는 자식 노드들의 레이블로부터 계산된 해시 값을 레이블로 붙여두든 트리

데이터 센터 장애 처리

정전, 네트워크 장애, 자연재해

• 여러 데이터 센터에 다중화하는 것이 중요

시스템 아키텍쳐 다이어그램

• 클라이언트: 키-값 저장소가 제공하는 두 가지 단순한 API, 즉 get(key) 및 put(key, value)와 통신
• 중재자: 클라이언트에게 키-값 저장소에 대한 프락시 역할
• 노드: 안정 해시의 해시 링 위에 분포
• 노드를 자동으로 추가/삭제할 수 있도록 시스템은 완전히 분산된다.
• 데이터는 여러 노드에 다중화된다.
• 모든 노드가 같은 책임을 지므로, SPOF(Single Point of Failure)는 존재하지 않는다.

쓰기 경로

1. 쓰기 요청이 커밋 로그 파일에 기록
2. 데이터가 메모리 캐시에 기록
3. 메모리 캐시가 가득차거나 사전에 정의된 어떤 임계치에 도달하면 데이터는 디스크에 있는 SSTable에 기록
   • SSTable: Sorted-String Table의 약어, <키, 값>의 순서쌍을 정렬된 리스트 형태로 관리하는 테이블

읽기 경로

1. 데이터가 메모리 캐시에 있는지 부터 확인
2. 없는 경우 디스크에서 가져옴

• 블룸 필터

1. 데이터가 메모리 있는지 검사-> 없으면 2
2. 데이터가 메모리에 없으므로 블룸 필터를 검사
3. 블룸 필터를 통해 어떤 SSTable에 키가 보관되어 있는지 확인
4. SSTable에서 데이터를 가져옴
5. 해당 데이터를 클라이언트에 반환

요약

이번 내용은 가상면접 사례로 배우는 대규모 시스템 설계 5장 안정 해시 설계에 대한 내용이다.

• 수평적 규모 확장을 위해서는 요청 또는 데이터를 서버에 균등하게 나누는 것이 중요하다.

→ 이를 위해 안정 해시를 설계

해시 키 재배치(rebase) 문제

serverIndex = hash % 4

서버 풀의 크기가 고정되어 있고, 데이터 분포가 균등할때는 잘 작동한다.

but. 서버가 늘어나거나 기존 서버가 삭제 된다면 문제가 생긴다.

→ 키에 대한 해시값은 변하지 않지만 서버 인덱스는 서버 크기가 달라지기에 달라진다.

즉 키가 재분재 되어 대부분 캐시 클라이언트가 데이터가 없는 엉뚱한 서버에 접속한다.

→ 대규모 케시 미스 문제 발생

어떻게 해결하는가?

→ 안정 해시

안정 해시

해시 테이블 크기가 조정될때 평균적으로 k/n 개의 키만 재배치 하는 해시 기술

k: 키의 개수

n: 슬롯의 개수

해시 공간과 해시 링

✏️ 동작 원리

• 해시 함수: SHA-1 사용한다고 가정
  • 출력 범위: x0,x1…..xn
  • 해시 공간 범위: 0~ 2^160 -1

해시 서버

해시 함수 f 를 사용하면 서버 ip나 이름으 링 위의 어떤 위치에 대응시킬 수 있다.

해시 키

서버 조회

어떤 키가 저장된 서버는 해당 키의 위치로부터 시계 방향으로 링을 탐색해 나가면서 만나는 첫번째 서버이다

서버 추가

서버를 추가하더라고 가운데 키 일부만 재배치 하면 된다.

서버 제거

키 일부만 재배치

기존 구현법의 문제점

1) 서버와 키를 균등 분포 해시 함수를 사용해 해시 링에 재배치 2) 키의 위치에서 링을 시계 방향으로 탐색하다 처음으로 만나는 서버에 키가 저장

-> 두가지 문제점 존재

1. 서버가 추가, 삭제될때 상황을 감안하면 파티션의 크기를 균등하게 유지하는 것이 불가능

• 파티션: 인접한 서버 사이의 해시 공간

-> 어떻게 해결하는가? 가상 노드 or 복제 기법

가상 노드

• 가상노드: 실제 노드 또는 서버를 가리키는 노드
• 하나의 서버는 링 위의 여러 가상 노드를 가질 수 있다.

가상 노드의 개수 ⬆️ -> 키의 분포 균등 -> 표준 편차가 작아져서 데이터가 고르게 분포되기 때문

• 표준 편차: 데이터가 어떻게 퍼져 나갔는지 보이는 척도
• 100~200개의 가상 노드를 사용했을 경우 표준 편차의 값은 평균 5% 사이라고 한다.
• 가상 노드를 늘리면 표준 편차의 값은 더 떨어지나, 가상 노드 데이터를 저장할 공간은 더 많이 필요하게 된다.

재배치할 키 결정

어느 범위의 키들을 재배치 해야하는가.

안정 해시의 이점

• 서버가 추가, 삭데 될때 재배치 되는 키의 수 최소화
• 데이터가 보다 균등하게 분포하게 되므로 수평적 규모 확장에 유리
• 핫스팟 키 문제를 줄인다.

📒 4장 - 처리율 제한 장치의 설계

✅ 처리율 제한 장치

• 개념: 클라이언트 또는 서비스가 보내는 트레픽의 처리율을 제어하기 위한 장치
• 장점:
  1. dos 공격에 의한 자원 고갈 방지
  2. 비용 절감
  3. 서버 과부하를 막음

1️⃣ 1단계: 문제 이해 및 설계 범위 확정

2️⃣ 2단계: 개략적 설계안 제시 및 동의 구하기

• 처리율 제한 장치를 어디에 둘 것인가( 클라이언트 vs 서버)
  • 클라이언트는 일반적으로 안정적으로 처리율 제한을 두지 못함
  • 서버
    • api 서버에 두기
    • 처리율 제한 미들웨어 생성
    • → 어디에 두어야하나? 상황에 따라 다름

✅ 처리율 제한 알고리즘

✅  어디에 둘 것인가.

1. 레디스
   • INCR: 메모리에 저장된 카운터 값 +1
   • EXPIRE: 카운터에 타임아웃 값 설정

3️⃣ 3단계: 상세 설계

✅  처리율 제한 규칙

• 처리율 한도 초과 트래픽 처리
• HTTP 429 응답 (Too many requests): 어떤 요청이 한도 제한에 걸릴때 응답경우에 따라서 한도 제한에 걸린 메시지를 나중에 처리하기 위해 큐에 보관할 수 있음
• 처리율 제한 장치가 사용하는 HTTP 헤더클라이언트가 자기 요청이 처리율 제한에 걸리고 있는지에 대한 정보를 아래 HTTP 헤더를 통해 전달

✅ 분산 환경에서의 처리율 제한 장치의 구현

1. 경쟁 조건 (race condition)

   • 문제
     • 경쟁 이슈가 발생하는 동작
   • 해결 방법
     1. 레디스에서 카운터의 값을 읽음
     2. counter +1 의 값이 임계치를 넘는지 봄
     3. 넘지 않는다면 레디스에 보관된 카운터 값을 1만큼 증가시킴

2. 동기화 이슈

   • 문제
     • 여러대의 처리율 제한 장치를 사용할 경우 요청이 분산될 수 있음
   • 해결 방법
     • Sticky session 을 사용하여 같은 클라이언트로부터의 요청은 항상 같은 처리율 제한 장치로 보낼 수 있도록 할 수 있음

3. 성능 최적화

   • 문제
     • 지연시간
   • 해결 방법
     • 지연시간을 줄이기 위해 사용자의 트래픽을 가장 가까운 Edge 서버로 전달하여 지연시간을 줄임

4. 모니터링

   • 처리율 제한 장치를 설치 후 효과적으로 동작하는지 확인해야함

📒 1장 - 사용자 규모에 따른 확장성

✅ 단일서버

웹 - 앱 - 데이터베이스 - 캐시 등이 한 서버에서 동작

✅ 데이터베이스

웹/모바일 트래픽 처리용도의 서버(웹 계층)와 데이터베이스용 서버(데이터 계층)를 분리

• 독립적 확장 추구
• 비-관계형(NoSQL) 데이터베이스가 좋은 선택일 수 있는 경우
  • 아주 낮은 응답 지연시간 필요
  • 다루는 데이터가 비정형 데이터인 경우
  • 데이터를 직렬화/역직렬화 할 수만 있으면 되는 경우
  • 아주 많은 양의 데이터를 저장할 필요가 있는 경우

✅ 수직적 규모 확장 / 수평적 규모 확장

스케일 업 / 스케일 아웃

• 수직적 규모 확장(스케일 업)은 장애에 대한 자동복구 방안이나 다중화 방안을 제시하지 않음

✅ 로드 밸런서

• 부하 분산 집합에 속한 웹서버에게 트래픽 부하 고르게 분산
• 로드밸런서를 public ip로 두고 내부에선 private ip로 이용 → 보안 위함
• 자동복구 문제 해결 및 웹 계층 가용성 향상

✅ 데이터베이스 다중화

• 서버 사이에 주 - 부 관계를 설정하고 데이터 원본은 주 서버에, 사본은 부 서버에 저장하는 방식
• 부 데이터베이스는 읽기 연산만을 지원 → 일반적으로 읽기 연산이 트래픽이 대다수이므로 주 데이터베이스보다 수가 많아야 함
• 주/부 데이터베이스 둘 다 정상인 경우 역할이 나뉘어져 있지만, 한 측의 데이터베이스가 사용 불가능하다면 다른 측의 데이터베이스가 다 커버하도록 설계됨

✅ 캐시

• 캐시계층:

  • 데이터가 잠시 보관되는 곳
  • 데이터 베이스보다 빠름 → 성능 개선, 데이터베이스 부화 줄임, 독립적 확장 가능

• 캐시 사용시 유의 할 점

  • 갱신은 자주 일어나지 않지만 참조 빈번할때

  • 어땬 데이터를?

    • 휘발성 메모리에 두므로, 영속적으로 보관할 데이터를 캐시에 두는 것은 바람직하지 않음
    • 캐시서버가 재시작시 데이터는 다 날아감
    • 즉 중요 데이터는 지속적 저장서에

  • 어떻게 만료?

    • 만료 정책

  • 일관성 유지

    • 데이터 원본과 캐시의 정보가 일치하는가

  • 장애 대처

    • 캐시 서버를 한대만 주는경우
      • 당일 장애 지점 가능성( 어떤 특정 지점에서의 장애가 전체 시스템의 동작을 중간시켜버릴 수 있는 경우) → 서버 분산 필요

  • 캐시 크기

  • 데이터 방출 정책

    • LRU
    • LFU

    ✅ CDN

  • 개념: 정적 콘텐츠를 전송하는데 쓰이는 지리적으로 분산된 서버의 네트워크

  • 동작 방법

    • 사용자가 웹사이트 방문 → 가까운 cdn 서버가 정적 콘텐츠 전딜

  • 고려해야할 사항

    • 비용
    • 적절한 만료 시한 설정
    • cdn 장애에 대한 대처 방안
    • 콘텐츠 무효화 방법

✅ 무상태 웹 계층

수평적으로 확장하는 밥 → 상태 정보를 웹계층에서 제거

강태 정보를 db에 저장히고 필요할때 불려오는 거

• 상태 웹사이트의 문제점: 같은 클라이언트는 같은 서버로 전송되어야하는 문제점
• 로드밸런서가 이 역할을 해주는데 주담으 주고, 로드 밸런서 뒷단에 서버를 추가하거나 제거ㅏ기 까다롭다.

✅ 데이터 센터

• 지리적 라우팅: 가장 가까운 데이터 센터로 안내 되는 것
• 다중 데티러센터 아키텍쳐 설계시 해결해야하는 기술적 난제
  • 트래픽 우회
  • 데이터 동기화
  • 테스트와 배포

✅ 메세지 큐

개념: 메세지의 무손실을 보장하는 비동기 통신을 지원하는 컴포넌트

메세지의 버퍼 역할을 하며 비동기적으로 전송

• 장점:
  • 서비스 또는 서버 간 결합이 느슨해져 규모 학장성이 보장

✅ 로그

• 에러 로그 관리 중요

✅ 매트릭

• 호스트 단위 매트릭: cpu, 메모리..
• 종합 매트릭: 데이터 베이스 계층의 성능, 캐시 계층의 성능
• 핵심 비즈니스 매트릭: 재방믄, 수익, 일별 능동 사용자

✅ 데이터베이스 규모 확장

1. 수직적 확장
   1. 고성능 자원 증설
   2. 문제점:
      1. 한계존제
      2. spof 발생 가능성
      3. 고비용
2. 수평적 확장(샤딩)
   1. 많은 서버 추가
   2. 데이터베이스를 샤드라는 작은 다위로 분할
   3. 모든 샤드는 같은 스키마를 사용하지만 샤드에 보관이 돠는 데이터 사이 중복 없음
   4. 고려해야할 점:
      1. 샤깅키를 어떻게 정하는지
      • 데이터의 재샤딩
      • 유명인사 문제(핫스핏 키 문제)
      • 조인과 비정규화