| 역할 | Team Leader(PM), Backend Developer, 최종 발표 |
| 담당 파트 | 금융 API 연동 아키텍처 설계(Adapter Pattern 적용), 계좌 조회·이체·인증 등 핵심 비즈니스 로직 구현, 프로젝트 일정 관리 및 최종 발표 |
| Backend | Java, Spring Boot |
| Frontend | React Native |
| Database & Messaging |
| MySQL |
| Infrastructure | AWS |
| 구분 | 상세 내용 |
|---|---|
| 🛑 문제 : | 외부 금융 API별 규격 차이와 기능 추가 요청 발생 |
| 수시입출금, 예적금 등 API마다 규격이 달랐고, 개발 중간에 1원 송금 인증 기능 추가 요청이 들어와 기존 로직 수정 위험이 있었음 | |
| 🔍 원인 : | 외부 API 의존성이 비즈니스 로직에 직접 영향을 주는 구조 |
| API 명세 변경이나 신규 기능 추가가 기존 서비스 로직 수정으로 이어질 가능성이 컸음 | |
| 🛠️ 해결 : | Adapter Pattern 적용 |
| 외부 API 호출부를 별도 패키지로 격리하고 표준화된 인터페이스를 설계하여 금융 기능을 일관된 방식으로 사용할 수 있도록 구성 | |
| ✨ 결과 : | 기존 비즈니스 로직 수정 없이 기능 확장 |
| Adapter 구현체만 추가해 1원 송금 인증 기능을 확장했고, 동료 개발자들이 복잡한 명세 확인 없이 메서드 호출 한 줄로 금융 기능을 사용할 수 있어 개발 생산성이 향상됨 |
| 구분 | 상세 내용 |
|---|---|
| 🛑 문제 : | 계좌 조회 로직 구현 방식에 대한 팀 내 이견 발생 |
| 대회 당일 사용자 경험과 데이터 처리 효율성을 두고 팀원 간 의견 충돌이 발생해 개발이 지연됨 | |
| 🔍 원인 : | 로직 흐름과 장단점에 대한 공통 이해 부족 |
| 구두 설명만으로는 각 방식의 흐름과 영향도를 명확히 공유하기 어려웠음 | |
| 🛠️ 해결 : | Flowchart 기반 시각적 설명 |
| 순서도를 그려 로직 흐름과 각 방식의 장단점을 시각화하여 팀원들에게 설명 | |
| ✨ 결과 : | 합의점 도출 및 제한 시간 내 기능 구현 |
| 팀원 모두가 납득하는 방향으로 의사결정을 마쳤고, 갈등 해소 후 기능을 성공적으로 구현 |
| 구분 | 내용 |
|---|---|
| 유연한 아키텍처의 힘 | 외부 의존성이 높은 프로젝트에서 Adapter Pattern을 적절히 활용하는 것이 유지보수성과 협업 속도에 결정적인 영향을 미친다는 것을 체감함. |
| 시각적 소통의 중요성 | 복잡한 로직은 말보다 도표로 시각화했을 때 커뮤니케이션 비용을 줄이고 팀의 의사결정 속도를 높일 수 있음을 배움. |
| 구분 | 내용 |
|---|---|
| 해커톤 Top 7 선정 | 20개 참가 팀 중 Top 7 선정 및 본선 진출 |
| 금융 어댑터 모듈 구축 | API 변경에 유연한 금융 어댑터 모듈 구축 |