미리보기

[역할 및 사용 기술]

• 주요 역할: 백엔드 설계 및 개발, 데이터 처리 시스템 구축, 실시간 환율 데이터 핸들링

• 기술 스택: Typescript, NestJS, PostgreSQL, Prisma, Redis, WebSocket, SSE, Jest

[주요 도전 과제]

• 도메인(환율, 주식) 특성 상 높은 외부 API의존도를 고려하여 적절하게 의존성을 격리하여 안정적인 서비스를 운영

• 실시간으로 수집하는(5초) 대량의 환율 데이터(31개의 통화쌍)를 효율적으로 처리하고 저장

• 사용자에게 지연 없이 실시간 환율 변동을 제공함과 동시에 데이터 정확성을 확보

[접근 방식과 해결 과정]

• 이벤트 기반 아키텍처

  • 외부 API Gateway를 직접 연결하는 방식과 중앙화된 데이터의 수집 방식의 트레이드오프를 분석한 결과, WebSocket연결로 데이터를 수집하고 변경된 환율 데이터를 직접 계산 후, Redis Pub/Sub으로 이벤트를 분산하는 구조를 채택하여 모듈 간 결합도를 감소하고 추후 추가될 기능에 대해 확장성을 확보하였습니다.

  • 이를통해 외부 데이터 수신 -> 내부 로직 처리 흐름이 단방향이 되도록 설계하였습니다.

• 환율 역산 원리를 통한 Redis채널 최적화 전략

  • 주요 31개 통화쌍의 모든 교차 통화쌍(31 * (31 - 1) = 930개)을 Redis채널에서 관리하는 대신, 메인 통화만을 기준으로 수집하여 환율 역산 원리 를 활용하여 필요 채널 수를 930개->30개로 감소시켜 메모리를 절약 뿐 아니라, Redis 트래픽 부하를 줄여 더 많은 클라이언트가 안정적으로 구독 가능하게 했습니다.

• 다양한 외부 API 조합

  • 환율 정보를 제공하는 다양한 API를 기능별로 유연하게 사용해야 했고,

    우리 서버에서 필요로하는 데이터 응답을 정확히 만족하는 외부 API가 존재하지 않아, 서버에서 필요한 공통 응답 인터페이스를 구축하고 각 외부API 서비스가 이를 구현하고, 해당 기능이 필요한 서비스에서 인터페이스 주입을 받음으로서, 외부 API에 대한 의존도를 배척하였습니다.

• 단위/통합 테스트

  • 중요한 비즈니스 로직을 담당하는 서비스 레이어를 정확히 테스트 하기 위해 Jest의 Mock을 사용해 외부 의존성을 모킹하여 핵심 비즈니스 로직을 테스트 하였습니다.

  • Docker-compose를 이용해서 프로덕션 환경과 동일한 테스트 환경을 구축하고 통합 테스트를 진행하였습니다.

  • 통합 테스트 실행 전 prisma migrate reset기능을 이용해 각 통합 테스트 실행 전 DB스키마를 초기화하여 각 통합 테스트들을 완전히 격리 시켜 독립적인 테스트가 가능하게 하였습니다.

  • NestJS의 모듈 시스템을 적극적으로 이용하여 통합 테스트 시 필요한 의존성들을 분리 구성하여, 유연하게 테스트 의존성들을 주입해줄수 있었습니다.

[역할 및 사용 기술]

• 주요 역할: 서버 구축, ERD 설계, API 설계, 영상 스트리밍 처리, 권한 시스템 구현 및 배포

• 기술 스택: Typescript, Express, PostgreSQL, Prisma, Redis

[주요 도전 과제]

• 관리자 / 선생님 / 학생 간 권한 별 분기 처리 및 데이터 관계 설계

• 대용량 강의 영상 스트리밍 처리 및 진도율 추적 시스템 구현

• 다양한 학습 콘텐츠(영상, 퀴즈, AR 등)를 유연하게 관리 가능한 DB 모델링

• 커리큘럼 진도율 산출 방식을 설계하며 정확성과 유연성 유지

[접근 방식과 해결 과정]

• 권한 구조 모델링 및 분기 처리

  • 관리자, 선생님, 학생으로 분기되는 구조에서 역할 간 데이터 접근/제어 제한이 명확히 구분되어야 했습니다. 이를 위해 권한 단위로 도메인 로직을 분리하여 역할 간 데이터 충돌 및 부정확한 권한 분기 로직 문제를 해결하며 추후 확장될 수 있는 기능에 대해 유지보수성을 높였습니다

• 영상 스트리밍 최적화(HLS + ffmpeg)

  • 초기에는 대용량 영상(강의) 파일을(500MB) HTTP방식으로 직접 전송하다, 브라우저에서 반복적으로 응답에 실패하는 현상이 나타났습니다. 이러한 문제 해결을 위해 HLS방식을 채택하고, ffmpeg를 통해 미디어를 청크 단위로 트랜스코딩하여 영상데이터를 관리하여 실시간 스트리밍 방식을 통한 영상 응답 속도를 완화하고 네트워크 부하를 크게 줄였습니다.

• 진도율 계산 구조 설계

  • 클라이언트와 지속적인 소통과 논의를 통해, 완전한 실시간 처리는 오버엔지니어링 이라는 판단 하에, 30초 주기 polling으로 진도율을 서버에 반영하는 방식으로 구현하였습니다. 또한, 커리큘럼/콘텐츠 구성이 선생님에 의해 동적으로 바뀌는 경우를 고려해 DB에 진도율을 정적으로 저장하지 않고, 테이블 정규화하여 매 요청 시 계산되도록 설계했습니다. 이를통해 정확성과 유연성을 동시에 만족하는 구조를 구축했고, 수업이나 커리큘럼 변경 시에도 일관된 진도율 계산이 가능하게 설계하였습니다

• Redis기반 세션 관리 및 TTL제어

  • 클라이언트 측 요구 사항에 중복 로그인과 일정 시간동안 활동이 감지되지 않을 시, 강제 로그아웃을 처리하는 요구사항을 만족하기 위하여 Stateful-login방식이 필요하다고 판단하여 Redis를 이용해 사용자 세션을 저장하고, TTL설정을 이용하여 세션 만료 시점 제어와 로그인 충돌 방지를 동시에 해결하였습니다.

• 데이터 모델링 (정규화 & 관계 모델)

  • 다양한 유형의 학습 콘텐츠를 유연하게 확장/변경 가능하도록, 상속형 테이블 구조를 이용하여 정규화 하였습니다. 반/커리큘럼/콘텐츠 간 N:M관계는 중간 테이블을 이용해 불필요한 중복 데이터를 줄였습니다. 이를통해 복잡한 교육 도메인을 데이터베이스 구조로 명확히 모델링하여 확장성과 데이터 무결성을 동시에 확보했습니다.

• Notion 기반 API 문서화 및 협업

  • 클라이언트 측/프론트엔드 와 실시간 협업을 위해 Notion에 API명세서를 작성, 주기적인 회의를 진행하고, 코드 변경사항은 Github을 이용하여 문서화하였습니다. 하지만 시시각각 변하는 데이터베이스 구조의 변경과, 클라이언트 요구사항등으로 인하여 일일히 수작업을 해야하는 과정에서 이러한 도구들의 한계를 느끼고, 이후 다른 프로젝트에서 사용하게 될 자동화된 API문서(Swagger)의 필요성을 크게 체감하였습니다.

[역할 및 사용 기술]

• 주요 역할: 백엔드 서버 구축, 데이터베이스 모델링, API 설계 및 구현

• 기술 스택: JavaScript, Express, PostgreSQL, pg , MongoDB, Redis, AWS EC2, AWS S3

[주요 도전 과제]

• 동아리 회장, 운영진, 일반 회원 간 권한 별 접근 제어

• 동아리 및 각 동아리의 게시판, 공지사항, 부원 관리. 각 동아리장, 매니저의 고유 기능

• 동아리 가입 신청/승인/거부/블랙리스트 프로세스

[기술적 도전 및 시행착오]

• ORM없이 Raw SQL을 이용하여 100여개 API 작성

  • 이론적으로만 알고있던 SQL지식들을 직접 한땀한땀 작성하며 복잡한 어떤 상황에서는 어떤 상황에 어떤 쿼리를 날려야 하고, 이 쿼리가 어떤 결과를 나타내는지, 서브쿼리는 어떠한 순서로 실행되고 조인이 내부적으로 어떻게 동작 하는지 몸으로 터득하는 경험이 되었습니다.

• 레이어드 아키텍쳐 없이 라우터에서 모든 로직을 처리

  • 비즈니스 로직과 데이터 접근 로직을 분리하지 않고 모든 처리를 라우터에서 수행한 결과, API가 늘어날 수록 코드 복잡도는 기하급수적으로 증가했고, 작은 수정이 전체 시스템에 영향을 주는 구조적 한계를 직접 겪었습니다. 해당 프로젝트에서 이러한 경험은 유지보수 가능한 구조란 무엇인가에 대한 진지한 고민의 출발점이 되었습니다.

• 타입 시스템 미도입으로 인한 런타임 오류

  • 당시엔 익숙했던 Javascript로 개발을 진행했지만, 타입 시스템이 없는 상황에서 IDE의 자동완성, 타입 추론, 에러 탐지 등의 이점을 누리지 못한 채 런타임에서 불필요한 디버깅 시간을 반복했습니다. 이 경험은 이후 프로젝트에서 Typescript를 도입하게 된 결정적인 계기가 되었습니다.

• PM2 기반 배포를 통한 서버 운영 경험

  • PM2를 이용해 프로세스 관리를 하며 배포 경험을 처음 쌓았고, 로그 관찰이나 장애 대응 등 운영의 복잡함을 체감했습니다. 이 과정을 통해 Docker나 CI/CD 와 같은 가상화 도구의 필요성과 운영 환경의 일관성 확보가 개발 효율성과 얼마나 직결되는지 깊이 인식하게 되었습니다.

Clog프로젝트는..

• 저에게 개발자로서의 첫 실전 경험이었습니다.

  기술적 완성도는 비록 낮았지만, 지금 생각해보면 제가 진행했던 모든 프로젝트를 통틀어서 가장 어렵고 오래 걸렸지만, 동시에 가장 얻은게 많은 프로젝트기도 하였습니다. 무수히 많은 시행착오 속에서 개발자로서의 방향성과 문제 해결 태도를 스스로 정립할 수 있었던 값진 프로젝트였습니다.