SYDESYDE
SYDESYDE
  • 피드
  • 쇼케이스
  • 블로그
  • 모임
SYDESYDE© 2026 SYDE. All rights reserved.
SYDE 소개문의하기
Kakao
SYDE 오픈채팅
Instagram
Instagram
Threads
Threads
커뮤니티 가이드라인협업문의이용약관개인정보처리방침
커뮤니티 가이드라인협업문의이용약관개인정보처리방침

© 2026 SYDE. All rights reserved.

0회차 | 프로젝트 주제 선정

a우재원· 2일 전
목차
  • 0회차 | 프로젝트 주제 선정
  • 1. 이번 프로젝트를 시작한 이유
  • 2. 처음에는 자산관리 서비스를 생각했다
  • 3. 자산관리에서 금융 상담으로
  • 4. 프로젝트 주제
  • 5. 핵심 흐름
  • 6. 금융 프로젝트로서 무엇을 구현할까?
  • 예금·적금
  • 주식
  • 7. 백엔드에서 중요하게 볼 것
  • Transaction
  • Idempotency
  • Batch / Scheduler
  • 상담 이력
  • 8. AI는 처음부터 넣지 않는다
  • 9. 이번 프로젝트에서 얻고 싶은 것
  • 10. 일단 여기까지 만든다
  • MVP
  • 이후 확장
  • 공부한 뒤 추후 적용을 위해 고려해 볼 것
  • 11. 앞으로의 계획
  • 마무리

목차

  • 0회차 | 프로젝트 주제 선정
  • 1. 이번 프로젝트를 시작한 이유
  • 2. 처음에는 자산관리 서비스를 생각했다
  • 3. 자산관리에서 금융 상담으로
  • 4. 프로젝트 주제
  • 5. 핵심 흐름
  • 6. 금융 프로젝트로서 무엇을 구현할까?
  • 예금·적금
  • 주식
  • 7. 백엔드에서 중요하게 볼 것
  • Transaction
  • Idempotency
  • Batch / Scheduler
  • 상담 이력
  • 8. AI는 처음부터 넣지 않는다
  • 9. 이번 프로젝트에서 얻고 싶은 것
  • 10. 일단 여기까지 만든다
  • MVP
  • 이후 확장
  • 공부한 뒤 추후 적용을 위해 고려해 볼 것
  • 11. 앞으로의 계획
  • 마무리

0회차 | 프로젝트 주제 선정

1. 이번 프로젝트를 시작한 이유

Java/Spring 기반 백엔드 개발을 공부하면서 한 가지 고민이 생겼다.

단순히 기능을 하나씩 구현하는 것에서 끝나는 것이 아니라,
하나의 서비스가 실제로 어떻게 설계되고 운영되는지 경험해보고 싶었다.

특히 최근에는 금융 IT와 AICC(Artificial Intelligence Contact Center)에 관심을 가지고 관련 내용을 공부하고 있다.

금융 시스템을 공부하면서는 Transaction, Idempotency, 정합성, 거래 이력과 같은 개념을 접했고,
å
고객의 요청을 받으면

고객 식별 → 데이터 조회 → 업무 처리 → 결과 반환 → 이력 관리

와 같은 여러 과정이 연결된다.

그래서 이번에는 이런 흐름을 작은 규모의 프로젝트로 직접 구현해보기로 했다.


2. 처음에는 자산관리 서비스를 생각했다

처음 생각했던 아이디어는 비교적 단순했다.

개인의 금융자산을 등록하고 관리하는 서비스였다.

예를 들어,

  • 예금·적금 계좌 등록

  • 주식 보유 내역 등록

  • 거래 내역 관리

  • 예금·적금 이자 계산

  • 주식 수익률 계산

  • 현재 자산 조회

  • 매일 자산 현황 알림

등을 구현하는 것이다.

여기에 Telegram을 연결하면 매일 정해진 시간에

현재 총 자산은 얼마이고, 어제보다 얼마나 변했는지

확인할 수도 있다.

백엔드 공부를 하기에는 충분히 좋은 주제라고 생각했다.

하지만 한 가지 의문이 있었다.

그런데 이 서비스를 굳이 내가 만들어야 하는 이유는 무엇일까?

단순 자산관리 기능만 구현한다면 이미 비슷한 서비스가 많다.

그래서 기능을 추가하는 대신 문제를 다시 정의해보기로 했다.


3. 자산관리에서 금융 상담으로

자산관리 서비스에서 사용자는 자신의 데이터를 직접 조회한다.

내 자산
  ↓
조회
  ↓
이자 / 수익률 계산
  ↓
결과 확인

하지만 금융 서비스에서 고객이 실제로 하는 요청은 조금 더 다양하다.

예를 들어,

이번 달 적금 이자는 얼마예요?

제가 가지고 있는 주식 수익률을 알려주세요.

지난달에 어떤 거래를 했는지 보여주세요.

이런 질문에는 단순히 미리 저장된 정보를 보여주는 것 이상의 처리가 필요하다.

고객의 금융 데이터를 조회하고,
필요한 계산을 수행하고,
그 결과를 고객에게 전달해야 한다.

그리고 상담 시스템의 관점에서는 여기서 끝나지 않는다.

고객 문의
   ↓
문의 유형 파악
   ↓
고객 데이터 조회
   ↓
금융 업무 처리
   ↓
결과 생성
   ↓
고객 응답
   ↓
상담 이력 저장

이 흐름을 직접 구현해보고 싶어졌다.

그래서 프로젝트의 방향을 개인 자산관리 서비스 → 금융 상담 백엔드로 변경했다.


4. 프로젝트 주제

이번 프로젝트의 주제는 다음과 같이 정의했다.

금융 고객의 상담 요청을 실제 금융 데이터 조회와 업무 처리까지 연결하는 작은 컨택센터 백엔드 시스템

처음부터 실제 금융기관 수준의 시스템을 만들겠다는 의미는 아니다.

오히려 작은 규모로 범위를 제한하고,

고객의 질문이 들어왔을 때 백엔드에서는 어떤 일이 일어나는가?

를 직접 구현해보는 것이 목표다.


5. 핵심 흐름

프로젝트의 핵심 흐름은 다음과 같다.

[고객]
   │
   │ 금융 문의
   ▼
[상담 채널]
   │
   ▼
[상담 요청 처리]
   │
   ├── 문의 유형 확인
   │
   ├── 금융 데이터 조회
   │
   ├── 계산 / 업무 처리
   │
   ▼
[응답 생성]
   │
   ▼
[고객에게 응답]
   │
   ▼
[상담 이력 저장]

처음에는 Telegram을 상담 채널로 사용한다.

Telegram을 사용하는 이유는 Telegram 자체가 프로젝트의 핵심이기 때문이 아니다.

웹 화면이나 별도의 프론트엔드를 처음부터 만드는 것보다
상담 요청을 보내고 결과를 받는 채널을 빠르게 구성할 수 있기 때문이다.

따라서 구조적으로는 다음과 같이 생각하고 있다.

                 ┌─ Telegram
                 │
고객 → 상담 채널 ┼─ Web
                 │
                 └─ AICC / Voice
                        │
                        ▼
                상담 업무 백엔드
                        │
             ┌──────────┼──────────┐
             ▼          ▼          ▼
          금융조회    계산/업무    상담이력

이번 프로젝트에서는 우선 Telegram만 구현하고,
나중에 다른 채널로 확장할 수 있도록 생각해볼 예정이다.


6. 금융 프로젝트로서 무엇을 구현할까?

MVP에서는 금융상품을 너무 많이 다루지 않기로 했다.

우선 다음 두 영역으로 제한한다.

예금·적금

  • 계좌 등록

  • 입금/출금 내역

  • 금리 등록

  • 이자 계산

  • 거래 내역 조회

주식

  • 보유 종목 등록

  • 매수/매도 내역

  • 평균 매수가 계산

  • 현재가 입력

  • 평가금액 계산

  • 수익률 계산

처음부터 증권사 API를 모두 연결하는 것도 목표로 하지 않는다.

우선은 직접 데이터를 등록하거나 테스트 데이터를 사용해
금융 업무 로직 자체를 먼저 구현한다.

이후 기본 기능이 완성되면 증권 API 연동을 검토할 예정이다.


7. 백엔드에서 중요하게 볼 것

이번 프로젝트에서 단순히 CRUD 기능만 만드는 것은 피하려고 한다.

특히 금융 시스템을 공부하면서 알게 된 개념들을 실제 코드에 적용해보고 싶다.

Transaction

예를 들어 거래를 처리할 때

거래 기록 저장
+
계좌 상태 변경

중 하나만 성공해서는 안 된다.

둘 다 성공하거나, 문제가 발생하면 함께 되돌아가야 한다.


Idempotency

동일한 요청이 네트워크 문제 등으로 여러 번 들어왔을 때

입금 요청 1회
입금 요청 1회
입금 요청 1회

가 실제로 3번 처리되는 문제가 발생하지 않도록
중복 요청을 어떻게 처리할지 고민해볼 예정이다.


Batch / Scheduler

매일 정해진 시간에 금융 데이터를 계산하고
Telegram으로 리포트를 보내는 작업도 구현한다.

매일 08:00
   ↓
자산 조회
   ↓
이자 / 수익률 계산
   ↓
Daily Report 생성
   ↓
Telegram 전송

단순히 @Scheduled를 사용하는 것에서 끝내지 않고,
중복 실행이나 실패가 발생했을 때 어떻게 처리할지도 생각해볼 예정이다.


상담 이력

고객의 요청과 응답을 저장한다.

RECEIVED
   ↓
PROCESSING
   ↓
RESOLVED

처리하지 못한 요청은 이후 확장 단계에서

ESCALATED

상태로 관리할 수 있도록 설계한다.

이 부분을 통해 단순 챗봇이 아니라 상담 업무의 상태를 관리하는 백엔드를 만들어보려고 한다.


8. AI는 처음부터 넣지 않는다

처음에는 AI를 사용하지 않을 예정이다.

이유는 단순하다.

이번 프로젝트에서 먼저 확인하고 싶은 것은

사용자의 요청이 실제 금융 업무 로직과 어떻게 연결되는가?

이기 때문이다.

예를 들어 처음에는

이번 달 이자 얼마야?
        ↓
이자 조회 명령
        ↓
InterestService
        ↓
DB 조회
        ↓
이자 계산
        ↓
응답

과 같이 명확한 구조로 만든다.

그 다음 자연어 처리를 추가한다면,

이번 달 적금에서 내가 받을 이자는?
        ↓
Intent Classification
        ↓
INTEREST_INQUIRY
        ↓
InterestService
        ↓
금융 데이터 조회
        ↓
응답

처럼 기존 업무 로직 위에 AI를 연결할 수 있다.

즉, AI가 금융 업무 로직 자체를 대신하는 구조가 아니라 고객의 자연어 요청을 기존 업무 API에 연결하는 구조를 생각하고 있다.


9. 이번 프로젝트에서 얻고 싶은 것

이 프로젝트의 목표를 단순히 금융 관련 서비스 하나 만들기라고 생각하지 않는다.

지금까지 공부한 내용을 하나의 흐름으로 연결해보는 것이 더 큰 목표다.

Java / Spring
      ↓
MyBatis / SQL
      ↓
금융 도메인
      ↓
Transaction / Idempotency
      ↓
상담 업무 Flow
      ↓
Contact Center
      ↓
AI 연계

그리고 프로젝트를 개발하면서 발생하는 오류나 설계상의 문제도 기록할 예정이다.

예를 들어

  • DB 정합성 문제

  • Transaction 처리

  • 중복 요청

  • Scheduler 중복 실행

  • 외부 API 실패

  • 데이터 불일치

  • 예외 처리

  • 로그를 통한 장애 추적

등을 직접 경험하고 해결해보려고 한다.

그래서 이 프로젝트는 단순한 결과물보다는

기획 → 설계 → 구현 → 장애 발생 → 원인 분석 → 개선

의 과정을 기록하는 프로젝트로 만들고 싶다.


10. 일단 여기까지 만든다

처음부터 너무 많은 것을 구현하지 않기 위해 범위를 다음과 같이 나눴다.

MVP

  • 금융 계좌/자산 등록

  • 거래 내역 관리

  • 이자 계산

  • 주식 수익률 계산

  • Transaction

  • Idempotency

  • 상담 이력

  • Telegram 상담

  • Daily Report

  • Scheduler

이후 확장

  • KIS API 연동

  • 실시간/자동 시세 조회

  • 자연어 Intent 분류

  • 상담원 이관

  • 상담 통계

  • 관리자 화면

공부한 뒤 추후 적용을 위해 고려해 볼 것

  • Kafka

  • Redis

  • CQRS

  • Event Sourcing

  • Saga

  • Transactional Outbox

  • STT/TTS

  • RAG

  • Voice AICC

  • Multi-region / DR

공부하고 싶은 기술을 전부 넣는 것이 아니라,
현재 구현할 수 있는 범위와 앞으로 공부할 범위를 분리하는 것도 이번 프로젝트의 중요한 목표다.


11. 앞으로의 계획

다음 회차부터는 서비스 기획 단계부터 시작해보고자 한다.

먼저

누가 이 서비스를 사용하고, 어떤 상황에서 어떤 요청을 하는가?

를 정의해보려고 한다.

다음 글에서는 금융 고객을 하나의 가상의 사용자로 설정하고,

고객 → 문의 → 상담 처리 → 금융 업무 → 응답

으로 이어지는 페르소나와 User Journey를 작성해볼 예정이다.

그 다음에는 이 흐름을 실제 시스템 구조로 옮겨서
IA, Flow Chart, DB, API 설계까지 단계적으로 연결해보려고 한다.


마무리

처음에는 단순한 자산관리 서비스를 만들려고 했다.

하지만 프로젝트를 시작하기 전에

이걸 왜 만드는가?

를 다시 생각해보면서 방향이 조금 달라졌다.

이번 프로젝트에서 만들고 싶은 것은 단순히 자산을 보여주는 서비스도,
처음부터 AI를 사용하는 금융 챗봇도 아니다.

고객의 금융 문의가 실제 데이터 조회와 업무 처리로 이어지고, 그 결과가 다시 고객에게 전달되는 작은 금융 컨택센터 백엔드를 만들어보려고 한다.

얼마나 실제 금융 시스템과 비슷하게 만들 수 있을지는 아직 모르겠다.

대신 하나씩 직접 구현하면서
금융 서비스의 데이터와 업무 흐름이 백엔드에서 어떻게 연결되는지 확인해보려고 한다.

7
우
우재원

우재원님의 다른 글

  • LLM은 어떻게 답을 만들까 (1편: 전체 흐름)2일 전
  • 2회차 | 구체적인 흐름과 설계2일 전
  • 1회차 | 문제 정의와 방향 수정2일 전

댓글 0

My avatar