[Inner Circle] 패스트캠퍼스 4기 팀 프로젝트 1차 후기

안녕하세요 패스트캠퍼스 이너서클 4기 이직대비반 을 수강하고 있는 개발자 던킨입니다.

2번째 프로젝트 글 이후 오랜만에 글을 쓰게 되었습니다.

2번째 프로젝트였던 라이브러리 만들기는 아쉽게도 완성도가 높지 않습니다.

그 이유는 일단 제가 만들고자 했던 방향으로 가려면 좀 많은 선학습이 필요한 부분들이 있었습니다. 가령 kafka, Redis 등등

하지만 이런거 없이 라이브러리를 만들어서 간단하게 만들어서 사용할수있는 수준으로만 개발이 되어 있습니다.

https://github.com/ukukdin/FlinkAPI

GitHub - ukukdin/FlinkAPI: Flink 라이브러리

 

 

팀프로젝트 2주차 후기

 

핀테크 송금 서비스 개발 프로젝트에 팀원으로 참여하게 되었다. 프로젝트를 진행하면서 겪은 팀 내 상황, 기술적 고민, 그리고 개발 과정의 경험을 블로그에 정리해본다.

 

 

MVP 개발 일정을 따라가며 생긴 소통의 어려움

팀 프로젝트 초반, 패캠 리더의 제안으로 빠른 MVP 릴리즈를 목표로 일정이 설정되었다. 일정의 속도를 중시하다 보니, 세션에 참석하지 못한 팀원들에게 충분한 맥락을 설명하지 못한 채 ‘시간이 촉박하니 서둘러야 한다’는 식으로 설명하게 됐고, 프로젝트의 본질적 방향성이 일부 팀원들에게 잘 전달되지 않아 오해가 발생했다.

팀 프로젝트에서 속도와 소통의 균형이 얼마나 중요한지 직접 체감한 경험이었다. 일정 관리뿐 아니라 각 팀원의 이해와 공감이 원활하게 이루어져야 협업이 잘 진행된다.

• 특히 비대면 상황에서 목소리만으로 의견을 전달하려다 보니 다소 오해에 소지를 ....

맡은 역할과 로그인/보안 구현의 고민

이번 프로젝트에서 나는 로그인/로그아웃, 대시보드 개발을 담당했다. 금융 서비스 특성상, 단순 로그인 기능만으로는 충분치 않았고 아래와 같은 보안 이슈들을 깊이 고민해야 했다.

 

토큰 인증 체계: JWT, Refresh Token을 통해 인증 및 세션 만료 관리
데이터 암복호화: SHA-256, AES256.key 등 암호화 알고리즘을 적용하여 개인정보와 거래 정보를 보호
보안 강화: 돈이 오가는 서비스라는 점을 감안해 인증 절차를 강화하고, 토큰 관리와 데이터 보호 방식을 설계

처음에는 로그인 기능만 단순히 구현하면 될 줄 알았으나, 실제로는 보안 요구사항이 높고 다양한 위협 시나리오에 대비해야 했다. 이런 보안 요소들은 개발에 추가적인 검토와 테스트를 필요로 했고, 직접 구현하면서 금융 관련 서비스가 왜 까다로운지 실감하게 되었다.

 

많은 자료를 바탕으로 생각하고 의견을 묻기도 하며, 리더에게 조언을 여러차레 구하게 되었다

이부분에서 다시한번 태양 리더님께 감사드립니다.

 

팀 상황과 역할 재분배

 

중간에 한 팀원이 개인 사정으로 프로젝트에서 하차하게 되어 4명이 남았다. 팀원들이 역할을 재분배하며 개발 효율성과 일정 준수에 집중하게 됐다.
남은 인원만으로도 협업의 동력을 잃지 않기 위해 기존 과정을 되짚고, 커뮤니케이션 방식도 재정비했다.

 

 

2주차의 느낀점

속도와 소통의 균형이 프로젝트의 성공을 좌우한다.
보안이 중요한 서비스는 예상보다 훨씬 많은 사항을 고려해야 한다.
팀원이 줄어드는 등 예기치 않은 상황에서도 유연하게 대처하는 경험을 얻었다.
앞으로 남은 기간 동안, 주요 기능 완성과 더불어 팀 내 소통 강화와 보안 개선이라는 두 축에 집중해 완성도 있는 서비스를 만들어가고자 한다.

아직도 로그인 관련과 송금 시 회원의 보안인증에서는 더 깊게 고민을 해봐야할거같다.

회원 관리 기능 협업 경험과 느낀 점
핀테크 송금 프로젝트를 진행하며 회원가입, 로그인·로그아웃, 회원정보 수정, 탈퇴 등 핵심 사용자 관리 업무를 다른 한 분과 함께 담당하게 되었다. 이처럼 중요한 영역을 2인 1조로 맡다 보니, 자연스럽게 기능 설계와 코드 품질, 그리고 커뮤니케이션에 한층 더 신중을 기하게 된다.

 

비대면 팀원과의 협업이 주는 고민

회사 동료처럼 빈번하게 보고 대화하는 사이가 아니라, 한 번 오프라인(혹은 온라인)에 얼굴을 본 뒤 각자 원격에서 개발을 이어가는 구성이었다. 이런 관계에서는 다음과 같은 어려움과 고민이 생겼다.

소통의 어려움

직접 마주 않은 팀원과의 협업이므로, 사소한 오해나 맥락 전달 누락이 생기기 쉽다.
자리에서 바로 물어보거나 피드백 주고받는 것이 아니라, 일정 간격으로 메시지나 문서를 통해 의견을 주고받아야 한다.
합의와 기준의 명확화 필요
회원 정보 구조나 인증·보안 설계에 대해 세밀하게 합의하지 않으면, 코드가 불일치하거나 예상치 못한 충돌이 생길 수 있다.
각자 맡은 영역이 경계선에서 겹칠 때 책임소재와 작업범위를 분명히 해둬야 한다.
코드 리뷰와 문서화의 중요성
서로의 코드와 구현 로직을 이해하기 위해 상세한 주석, 문서, 정기 코드 리뷰가 효과적이었다.
단순히 기능을 나누는 것에서 끝내지 않고, 예외 처리나 인증 흐름 등 세부 설계도 공유하며 협업해야 퀄리티가 유지되었다.