개발자들이 남긴 기록..

1. 결제 시스템 경험과 의견 💳

한 개발자는 결제 시스템 구현 경험이 있지만 재미는 크게 못 느꼈다고 함.
토스페이먼츠 문서가 잘 정리되어 있고, 문서대로 따라가면 디자인 패턴과 시스템 디자인을 적용할 수 있어 학습에 도움 됨.
결제 시스템은 복잡하고 다루기 어렵지만 경험으로서 쌓으면 좋다는 의견이 있음.
누구나 쉽게 접근하기 어렵기에 직접 경험해 보길 권장함.

설명
결제 시스템은 보안, 트랜잭션 관리, 다양한 결제 수단 지원 등 신경 써야 할 부분이 많음.
그리고 이 과정에서 견고한 소프트웨어 아키텍처 패턴(예: CQRS, 이벤트 기반 아키텍처)을 적용할 기회가 많음.
따라서 실무 경험이 있으면 시스템 설계 및 구현 능력이 크게 향상됨.

2. Prisma와 타입 정의 이슈 🛠️

Prisma 스키마가 자동 생성하는 타입 대신 프로젝트 내에서 직접 타입을 정의하려는 질문이 있었음.
보통 Prisma에서 생성하는 타입을 그대로 쓰지만, 코드 레이어에서 DB 의존성을 분리하고 싶으면 별도의 타입 정의와 활용이 가능함.
UserModel 등 추상화된 모델을 만들고 필요한 필드만 가져오는 타입 유틸리티(pick 등)를 활용하는 방식이 추천됨.
타입 네이밍은 UserDto, UserEntity 등 역할에 맞게 명확한 이름을 붙이는 것이 좋음.

설명
Prisma가 제공하는 타입은 데이터베이스 구조에 직접 연결되어 있어서 비즈니스 로직에 바로 쓰면 강한 의존성이 생김.
따라서 서비스 레이어나 컨트롤러에서 사용할 별도의 타입을 정의해 DB 레이어 분리, 테스트 용이성, 유연한 확장성을 확보할 수 있음.

3. BigInt 처리 방법과 고민 🧮

MySQL에서 BigInt 컬럼을 사용하는 경우 NestJS에서 number 타입으로 캐스팅해도 되는지 질문이 나옴.
일반적으로 JavaScript의 number 타입은 안전하게 표현 가능한 최대 숫자가 약 2^53-1 이기 때문에,
너무 큰 BigInt 값을 다루면 정확도가 깨질 수 있음.
현실적으로 유저 id나 게시글 id가 너무 커서 number 범위를 넘는 경우는 드물어 number로 캐스팅해서 관리하는 경우가 많음.
반면, 엄밀한 처리가 필요한 경우엔 문자열(string) 타입으로 받아서 서버 로직 내부에서 BigInt 타입으로 변환하거나, 외부 라이브러리를 활용해 다루기도 함.
복잡성을 줄이려면, validator 등 다른 데이터 처리 부분도 BigInt로 맞추는 작업이 필요해서 까다로움.

설명
JavaScript number는 64비트 부동소수점이며 정수 최대치가 제한적임.
BigInt 타입은 임의 크기의 정수를 다룰 수 있으나, JSON 직렬화나 외부 시스템과 호환 문제도 있으니 개발 상황에 맞는 방법을 선택해야 함.

4. 다양한 의존성 관리 및 타입 설계 🔄

Prisma만 쓰면 초기 개발은 빠르지만, 나중에 Redis, Raw Query 등이 섞이면 반환 타입 수작업 정의가 불가피하다는 경험 공유.
DB와 ORM 의존성을 서비스 계층에서 분리하는 게 유지보수와 테스트에 유리함.
타입스크립트 유틸 타입을 활용해 필요한 필드만 선택하거나 변경해 사용하는 방법이 효과적임.
개발 속도가 급할 때는 Prisma 기본 타입만 사용해도 되지만, 중장기 프로젝트에선 별도 타입 관리를 적극 고려해야 함.

5. 클라우드플레어와 Route53 DNS 이전 경험 🌐

클라우드플레어를 도입하면서 기존 AWS Route53에서 호스팅 존을 지워야 하는지 질문이 있었음.
클라우드플레어로 네임서버(NS)를 이전하면 Route53 쪽 DNS 레코드는 필요없어지고, 보통 삭제하거나 방치함.
일부러 완전히 제거하지 않고 레거시로 남겨두기도 함.
특정 2차 도메인(서브도메인)만 클라우드플레어로 옮기는 경우, 해당 도메인의 NS 레코드만 클라우드플레어로 지정하는 것이 편리함.
가비아 같은 도메인 등록기관에서 네임서버를 변경하는 걸 놓쳐 발생한 문제 사례도 공유됨.
DDoS 방어 목적이라면 클라우드플레어로 네임서버를 완전히 이전하는 게 효과적임.

설명
DNS 이전 시 네임서버 변경 주체는 도메인 등록기관(가비아, 후이즈 등)임.
AWS Route53은 DNS 서비스 역할만 하므로, 네임서버를 클라우드플레어로 변경 후엔 기존 AWS DNS 레코드는 의미가 없어짐.
서브도메인별로 NS 레코드를 개별 지정하는 것도 가능해 유연하게 운영할 수 있음.

면접팁⚡

Prisma 타입 분리:
단순히 ORM 생성 타입을 쓰는지, 아니면 서비스 레이어에서 별도 타입을 관리하는지 질문받을 수 있음.
- 답변 예시: "저는 DB 의존성을 줄이고 서비스 계층 독립성을 위해 별도로 DTO 타입을 정의하고, 필요 필드만 골라 사용하는 방식을 활용합니다."
BigInt 처리:
JS의 number 한계와 BigInt 타입의 차이점, 그리고 데이터 일관성을 위해 어떻게 처리하는지 설명 가능해야 함.
DNS 이전:
클라우드플레어와 AWS Route53 연동 시 DNS 이전 절차를 알면 네트워크 및 인프라 질문에 유리함.
- 특히, 네임서버 변경 주체와 레코드 관리 방법을 명확히 말할 수 있으면 좋음.

2025-01-17

목차