개발 개맛집

비용 최적화를 위한 내부 로깅 시스템 설계와 시행착오 – Azure 로그 비용 80% 절감한 경험

foodev — Sun, 11 Jan 2026 14:07:52 +0900

배경

스타트업 환경에서 인프라 비용은 곧 생존과 직결됩니다.
당시 회사에서는 AWS와 Azure 크레딧을 제공받아 멀티 클라우드 환경으로 인프라를 운영하고 있었습니다.

초기에는 AWS 크레딧을 중심으로 전체 인프라를 구성했지만, 크레딧 소진 이후 데이터베이스를 포함한 일부 워크로드를 Azure로 이전하게 되었습니다. 이 과정에서 클라우드 로그 비용이 급격히 증가하는 문제를 마주하게 되었습니다.

목차
✅ 문제상황
✅ 1차 접근: 로그를 저렴하게 저장하고, 필요할 때 분석하자
✅ 2차 접근: 비용과 실시간성의 균형을 다시 설계하자
✅ 결과 및 성과
✅ 기술 회고

문제상황

Azure로 일부 인프라를 이전한 뒤 비용을 모니터링하던 중,

Azure 로그 저장 비용이 전체 인프라 비용의 약 30%를 차지하고 있다는 점을 발견했습니다.

원인을 분석해보니 다음과 같은 문제가 있었습니다.

Azure Log Analytics는 최소 30일 보관 정책을 강제
개발 단계에서 info/debug 레벨의 상세 로그를 대량 수집
로그 볼륨 증가 → 보관 기간 × 저장 비용이 누적

AWS CloudWatch Logs와 달리 Azure에서는 짧은 보관 기간으로 로그를 운영하기 어려웠고, 이 차이가 예상보다 큰 비용 문제로 이어졌습니다.

1차 접근: 로그를 저렴하게 저장하고, 필요할 때 분석하자

아키텍처

접근 전략

Winston
- 로그 레벨 분리
- JSON 기반 구조화 로그 설계
로그 포맷 개선
- NestJS Middleware에서 JWT 디코딩
- 사용자 식별 정보(email)를 로그에 포함
S3 기반 로그 저장
- 애플리케이션 로그를 1분 단위 파일로 변환
- Parquet 포맷으로 적재하여 저장 비용 최소화
분석 환경 구축
- AWS Glue Crawler를 통해 스키마 자동 추론
- Data Lake에서 누락 없이 로그 분석 가능

성과

Azure 로그 저장 비용 약 70% 절감

문제점

Glue Crawler 실행이 배치 기반
스키마 반영 및 적재까지 5~10분 지연
실시간 디버깅, 장애 대응에는 치명적인 사용성 문제

기술적으로는 비용 최적화에 성공했지만,
운영 관점에서는 “로그는 즉시 조회할 수 있어야 한다”는 기본 요구사항을 충족하지 못했습니다.

2차 접근: 비용과 실시간성의 균형을 다시 설계하자

아키텍처

개선 전략

1차 접근에서 추가 개선을 진행했습니다.

선별적 로그 보관
- error / warning 로그만 Azure Monitor에 저장
- info / debug 로그는 별도 저장소로 분리
실시간 분석 중심 설계
- KQL 기반 실시간 쿼리 가능
- 장애 발생 시 즉각적인 원인 파악
Azure RBAC 적용
- 팀원 역할에 따른 로그 접근 제어
모니터링 대시보드 구축
- API 호출량
- 응답 시간
- 에러율 등 핵심 지표를 실시간 시각화

결과 및 성과

2차 접근을 통해 다음과 같은 결과를 얻었습니다.

비용 절감
- Azure 로그 관련 비용 월 기준 약 80% 절감
운영 효율성 개선
- 실시간 로그 조회 가능
- 장애 대응 시간 대폭 단축
크레딧 활용 최적화
- 절감된 비용을 핵심 인프라에 재투자 가능

기술 회고

1차 접근에서는 AWS Glue, Data Lake 등 기술적으로 흥미로운 요소에 집중한 나머지,
실제 사용하는 팀원의 경험을 충분히 고려하지 못했습니다.

돌이켜보면 처음부터 Azure Log Analytics와 Data Explorer의 보관 정책, 쿼리 성능, 비용 옵션을 더 깊이 검토했다면 2차 접근으로 바로 갈 수 있었을 것입니다.

이 경험을 통해 다음을 명확히 깨달았습니다.

비용 절감만을 목표로 하면 개발 생산성이 오히려 떨어질 수 있다
인프라 설계에서는 기술적 설계보다 실용성과 지속가능성이 중요하다
“운영자가 매일 쓰는 도구”라는 관점이 "반드시" 필요하다

이후로는 인프라를 설계할 때
비용, 사용성, 운영 부담의 균형을 가장 먼저 고려하게 되었습니다.

글 잼나게 보셨으면 좋아요 눌러주고 가세요

관심받는 거 좋아합니다

TypeDI 내부 구조 분석: typeDI 코드 분석을 통한 의존성 주입(DI)이 되는 과정

foodev — Mon, 14 Apr 2025 09:38:55 +0900

의존성 주입(DI)에 대해 이론적으로는 알고 있지만,

실제로 내부에서 어떻게 동작하는지 이해하기는 쉽지 않았습니다.

이 글에서는 TypeDI 오픈소스 코드를 직접 분석하며

데코레이터와 컨테이너가 어떻게 의존성을 관리하는지 파헤쳐봅니다.

NestJS 팀에서 DI 개념을 TypeDI에서 아이디어를 얻었다고 하여 TypeDI를 분석하게 되었습니다.

소스코드를 10번 이상 직접 따라치며 얻은 내용을 공유합니다.

평소에 당연하게 사용하던 @Injectable(), @Service() 같은 데코레이터들이

실제로는 어떤 원리로 작동하는지 핵심 로직 위주로 설명했습니다.

잘못된 내용이 있다면 댓글 부탁드립니다. ‍♂️

이 글은 다음과 같은 분들에게 도움이 됩니다.
- TypeDI나 NestJS 같은 DI 프레임워크를 사용하지만 내부 동작을 이해하고 싶은 개발자
- JS/TS의 메타프로그래밍과 리플렉션에 관심 있는 개발자
- 직접 DI 컨테이너를 구현해보고 싶은 개발자

특히 "➡️ container.get(ServiceA) 실행 그리고 동작원리" 부분은 DI의 핵심 메커니즘을 다루므로 꼭 읽어보시기 바랍니다.

✅ 아래 코드는 어떻게 실행될까요?

import 'reflect-metadata';

if (!Reflect || !(Reflect as any).getMetadata) {
  throw new Error(
    'TypeDI requires "Reflect.getMetadata" to work. Please import the "reflect-metadata" package at the very first line of your application.'
  );
}

import { ContainerRegistry } from './container-registry';
import { ServiceA } from './serviceA';

function main() {
  console.log('start');

  const container = ContainerRegistry.getContainer('default');
  const serviceA = container.get(ServiceA);
  serviceA.serviceB.sayHello();
  serviceA.sayHello();
}

main();

✅ reflect-metadata로 초기 설정값 존재유무 체크

Reflect는 JS 내장 객체로 메타프로그래밍을 위한 메서드를 제공함
reflect-metadata는 Reflect API를 확장하여 메타데이터 관련 기능을 추가하는 폴리필 라이브러리
TS 컴파일러가 데코레이터와 함께 클래스 컴파일 시 생성자 매개변수의 "타입 정보"를 메타데이터로 저장
TS 컴파일시 타입 정보가 사라지는데, 이 라이브러리를 통해 타입 정보를 메타데이터로 보존함
런타임에서 Reflect.getMetadata로 정보 검증
tsconfig.json에 다음 설정이 필수적:

{ 
	"compilerOptions": { 
		"experimentalDecorators": true,
		"emitDecoratorMetadata": true,
    }
}

✅ ContainerRegistry.getContainer('default'); 실행 과정

TypeDI는 의존성 주입을 위한 컨테이너 개념을 중심으로 설계되어 있습니다.

컨테이너는 서비스 인스턴스들을 관리하고 제공하는 역할을 합니다.

[container-registry.ts 일부]

import { ContainerInstance } from './container-instance';
import { EMPTY_VALUE } from './empty-value';
import { ServiceMetadata } from './interfaces/service-metadata';
import { ContainerIdentifier } from './types/container-identifier';
import { ServiceIdentifier } from './types/service-identifier';
import { ServiceOptions } from './types/service-options';

export class ContainerRegistry {
  private static readonly containerMap: Map<ContainerIdentifier, ContainerInstance> = new Map();
  public static readonly defaultContainer: ContainerInstance = new ContainerInstance('default');

  public static registerContainer(container: ContainerInstance): void {
    if (container instanceof ContainerInstance === false) {
      throw new Error('error');
    }

    if (!!ContainerRegistry.defaultContainer && container.id === 'default') {
      throw new Error('errror');
    }

    if (ContainerRegistry.containerMap.has(container.id)) {
      throw new Error('error');
    }

    ContainerRegistry.containerMap.set(container.id, container);
  }

  public static getContainer(id: ContainerIdentifier): ContainerInstance {
    const registedContainer = this.containerMap.get(id);
    if (registedContainer === undefined) {
      throw new Error('error');
    }

    return registedContainer;
  }
}

[container-instance.ts 일부]

export class ContainerInstance {
  public readonly id!: ContainerIdentifier;
  private metadataMap: Map<ServiceIdentifier, ServiceMetadata<unknown>> = new Map();

  constructor(identifier: ContainerIdentifier) {
    this.id = identifier;
    ContainerRegistry.registerContainer(this);
  }
}

TypeDI가 초기화될 때 다음과 같은 과정이 발생합니다:

public static readonly defaultContainer: ContainerInstance = new ContainerInstance('default'); 실행
ContainerInstance 생성자에서 this.id = 'default' 설정
생성자 내부에서 ContainerRegistry.registerContainer(this) 호출
registerContainer 메서드에서 컨테이너 맵에 새 컨테이너 등록: containerMap.set('default', container)
ContainerRegistry.getContainer('default') 호출 시 이렇게 등록된 기본 컨테이너를 반환

✅ const serviceA = container.get(ServiceA); 실행

container.get(ServiceA)로 service 데코레이터(함수)로 등록된 ServiceA 클래스를 조회합니다.

import { Service } from './decorators/service-decorator';
import { ServiceB } from './serviceB';

@Service()
export class ServiceA {
  constructor(public serviceB: ServiceB) {}

  public sayHello() {
    console.log('Hello, serviceA!');
  }
}

조회를 하기 전에 등록을 해야 하는데요.

그렇다면 어떻게 service 데코레이터로 ServiceA가 등록될 수 있을지 알아보겠습니다.

service-decorator 등록

[service-decorator.ts]

export function service<T=unknown>(): Function;
export function service<T>(options: ServicOptions<T> ={}): ClassDecorator {
	return(targetConstructor) => {
    	const serviceMetadata: ServiceMetadata<T> = { 
            id: options.id || targetConstructor,
            type: targetConstructor as unknown as Constructable<T>,
            factory: undefined,
            eager: false,
            multiple: false,
            scope:'container',
            referencedBy: new Map().set(ContainerRegistry.defaultContainer.id, containerRegistry.defaultContainer),
            value: EMPTY_VALUE
		};
        ContainerRegistry.defaultContainer.set(serviceMetadata);
    };
};

TypeDI serviceDecorator는 많은 serviceOptions 타입을 제공하지만,

여기서는 자세히 다루지 않겠습니다.

[설명]

service() 데코레이터를 클래스에 적용하면 위 과정을 통해 serviceMetadata가 ContainerRegistry에 등록됩니다.

즉 defaultContainer에 ServiceA 클래스의 메타 정보들이 등록됩니다.

[service 함수 필드 역할]

id: 서비스로 등록할 클래스 (클래스 자체가 ID)
type: 서비스로 등록할 클래스의 생성자
factory: 팩토리 클래스 옵션 (여기서는 undefined 정의)
multiple: 다중 컨테이너 등록 유무 옵션 (여기서는 false)
eager: 즉시로딩 옵션 (여기서는 지연로딩)
scope: service의 스코프 옵션 설정('transient' | 'container' | 'singleton' 중 하나)
referencedBy: 어떤 컨테이너와 연결되어 있는지 정보를 저장
value: serviceMetadata 등록 전 초기값 (서비스 메타데이터가 등록되면 해당 value로 변경)

[등록과정]

Service() 실행 시 정의된 필드값 세팅 및 ContainerRegistry.defaultContainer.set(serviceMetadata); 실행

[container-instance.ts]

export class ContainerInstance {
    private metadataMap: Map<ServiceIdentifier, ServiceMetadata<unknown>> = new Map();
    
    public set<T>(serviceOptions: ServiceOptions<T>): this {
        const newMetadata: ServiceMetadata<T> = {
          id: ((serviceOptions as any).id || (serviceOptions as any).type) as ServiceIdentifier,
          type: (serviceOptions as ServiceMetadata<T>).type || null,
          factory: (serviceOptions as ServiceMetadata<T>).factory,
          value: (serviceOptions as ServiceMetadata<T>).value || EMPTY_VALUE,
          multiple: serviceOptions.multiple || false,
          eager: serviceOptions.eager || false,
          scope: serviceOptions.scope || 'container',
          ...serviceOptions,
          referencedBy: new Map().set(this.id, this),
        };
        
        const existingMetadata = this.metadataMap.get(newMetadata.id);
        
        if (existingMetadata) {
          Object.assign(existingMetadata, newMetadata);
        } else {
          this.metadataMap.set(newMetadata.id, newMetadata);
        }
        return this;
      }
  }

서비스 메타데이터를 재설정하고, 컨테이너에 등록하는 함수:

serviceOptions 매개변수를 ServiceMetadata 타입으로 재정의
metadataMap 존재 유무 체크
이미 존재하면 존재하는 값을 재정의한 메타데이터로 덮어쓰기
미존재하면 새로운 서비스 metadataData 정의

export type ServiceIdentifier<T = unknown> =
  | Constructable<T>
  | AbstractConstructable<T>
  | CallableFunction
  | Token<T>
  | string;


export interface ServiceMetadata<T = unknown> {
  id: ServiceIdentifier;
  scope: ContainerScope;
  type: Constructable<T> | null;
  factory: [Constructable<unknown>, string] | CallableFunction | undefined;
  value: unknown | Symbol;
  multiple: boolean;
  eager: boolean;
  referencedBy: Map<ContainerIdentifier, ContainerInstance>;
}

container.get(ServiceA) 실행 그리고 동작원리

위에서 어떻게 service 데코레이터로 클래스가 등록되는지 보았습니다.

이제 container.get을 통해 어떻게 조회되는지 알아보겠습니다.

[container-instance.ts - get()]

export class ContainerInstance {
    private metadataMap: Map<ServiceIdentifier, ServiceMetadata<unknown>> = new Map();
    public get<T = unknown>(identifier: ServiceIdentifier<T>): T {
        const global = ContainerRegistry.defaultContainer.metadataMap.get(identifier);
        const local = this.metadataMap.get(identifier);

        const metadata = global?.scope === 'singleton' ? global : local;

        if (metadata) {
          return this.getServiceValue(metadata);
        }

        throw new Error('서비스 반드시 존재해야함');
      }
  }

컨테이너 인스턴스에 등록된 서비스 메타데이터 정보를 조회하는 함수입니다:

매개변수로 ServiceA가 들어옵니다.
global = 싱글톤 패턴으로 전역에 적용된 defaultContainer의 서비스메타데이터를 조회합니다.
local = 해당 컨테이너의 인스턴스의 메타데이터 맵에 접근하여 데이터를 조회합니다.
getServiceValue를 호출합니다.

[container-instance.ts - getServiceValue()]

export class ContainerInstance {
    public getServiceValue(serviceMetadata: ServiceMetadata<unknown>): any {
        let value: unknown = EMPTY_VALUE;

        if (serviceMetadata.value !== EMPTY_VALUE) {
          return serviceMetadata.value;
        }

        if (!serviceMetadata.factory && serviceMetadata.type) {
          const constructableTargetType: Constructable<unknown> = serviceMetadata.type;
          const paramTypes: unknown[] = (Reflect as any)?.getMetadata('design:paramtypes', constructableTargetType) || [];
          const params = this.initializeParams(constructableTargetType, paramTypes);

          params.push(this);
          value = new constructableTargetType(...params);
        }

        if (serviceMetadata.scope !== 'transient' && value !== EMPTY_VALUE) {
          serviceMetadata.value = value;
        }

        if (value === EMPTY_VALUE) {
          throw new Error('not ');
        }

        return value;
      }
      
    private initializeParams(target: Function, paramtypes: any[]): unknown[] {
        return paramtypes.map((paramtype, index) => {
          if (paramtype && paramtype.name && !this.isPrimitiveTypes(paramtype.name)) {
            return this.get(paramtype);
          }
          return undefined;
        });
      }

    private isPrimitiveTypes(typeName: string) {
        return ['string', 'boolean', 'number', 'object'].includes(typeName.toLowerCase());
      }
  }

serviceValue를 조회하는 과정입니다.

즉, 서비스의 인스턴스 또는 실제 객체값을 나타냅니다.

TypeScript는 컴파일 시 타입 정보가 사라지지만,

해당 정보를 Reflect 메타데이터로 저장합니다.

design:paramtypes 키워드로 Reflect 메타데이터를 조회합니다.

과정

value 지역변수를 EMPTY_VALUE로 초기화합니다.
매개변수 서비스 메타데이터의 value가 EMPTY_VALUE가 아니면 serviceMetadata.value를 리턴합니다.
- 이미 초기화 과정을 거쳐 value가 등록되었다고 판단하기 때문입니다.
- 이를 통해 순환참조를 자동으로 처리합니다.
서비스의 생명주기
- 서비스 등록 시: value = EMPTY_VALUE (아직 미등록)
- 첫 요청 시: value 저장
- 이후 요청 시: 등록된 value 인스턴스 반환
serviceMetadata.factory가 정의되지 않았고, serviceMetadata.type(생성자)이 존재하기 때문에 조건문이 실행됩니다.
constructableTargetType 변수를 생성자 타입, serviceMetadata매개변수의 type으로 선언합니다.
Reflect 메타데이터 API를 이용하여 'design' key와 constructableTargetType value로 생성자 매개변수의 타입정보 배열을 반환합니다.
initializeParams() 메서드를 실행합니다.

initializeParams 함수의 작동 방식과 재귀적 의존성 해결

initializeParams 함수는 서비스 클래스의 생성자에 필요한 모든 의존성을 재귀적으로 해결합니다:

의존성 분석 과정:
- 함수는 생성자의 매개변수 타입(paramtypes)을 순회하며 각 타입을 검사합니다.
- 각 매개변수 타입에 대해 primitive 타입인지 확인합니다(isPrimitiveTypes 함수 사용).
재귀적 의존성 해결:
- 매개변수가 객체 타입(서비스)이면 this.get(paramtype)을 호출합니다.
- 이 호출은 재귀적으로 해당 의존성을 가져오는 과정을 시작합니다.
- 예를 들어, ServiceA가 ServiceB에 의존하면:
  1. ServiceA의 생성자 매개변수로 ServiceB가 필요함을 인식
  2. this.get(ServiceB) 호출 -> 재귀 시작
  3. ServiceB 인스턴스 생성 및 반환
  4. ServiceA 생성자에 ServiceB 주입하여 최종 인스턴스 생성
params.push(this)
value = new constructableTargetType(...params);
- this를 params에 추가함으로써, 현재 컨테이너 인스턴스를 생성자의 마지막 매개변수로 전달합니다.
의존성 주입의 형태
- params배열이 생성자 매개변수로 전달됩니다.
- 이 과정에서 this가 생성자의 매개변수로 전달되어 객체가 컨테이너에 접근할 수 있습니다.
인스턴스가 성공적으로 생성되었다면 serviceMetadata.value에 value 등록
value 반환

최종 정리

container.get(ServiceA) 호출 시 실행 과정:

컨테이너는 ServiceA의 서비스 메타데이터를 조회
getServiceValue() 함수 호출로 인스턴스 생성 과정 시작
getServiceValue() 내부에서:
- ServiceA의 생성자 매개변수 타입 정보를 Reflect API로 조회
- paramTypes = [ServiceB] 배열 가져옴
- initializeParams(ServiceA, [ServiceB]) 호출
initializeParams() 내부에서:
- 매개변수 타입 배열([ServiceB])을 순회
- ServiceB가 primitive 타입이 아니므로 재귀적으로 this.get(ServiceB) 호출
재귀적 this.get(ServiceB) 처리:
- ServiceB의 서비스 메타데이터 조회
- ServiceB에 대한 getServiceValue() 함수 호출
- ServiceB의 생성자 매개변수 타입 정보를 조회
- 만약 ServiceB에 의존성이 없다면 빈 배열 반환 ([])
- new ServiceB() 인스턴스 생성하여 반환
ServiceA 인스턴스 생성 완료:
- new ServiceA(serviceB) 형태로 의존성이 주입된 ServiceA 인스턴스 생성
- 완성된 ServiceA 인스턴스를 반환
결과적으로:
- const serviceA = container.get(ServiceA) 구문이 실행되면 ServiceA 인스턴스 생성
- 이 인스턴스의 serviceB 속성에는 이미 ServiceB 인스턴스가 주입되어 있음
- 따라서 serviceA.serviceB.sayHello() 함수 호출이 가능

코드 실행 최종 결과.

✅ serviceA와 serviceB의 순환참조가 발생하지 않는 이유

import { Service } from './decorators/service-decorators';
import { ServiceB } from './serviceB';

@Service()
export class ServiceA {
  constructor(public serviceB: ServiceB) {}

  public sayHello() {
    console.log('Hello, serviceA!');
  }
}

import { Service } from './decorators/service-decorators';
import { ServiceA } from './serviceA';

@Service()
export class ServiceB {
  constructor(public serviceA: ServiceA) {}
  public sayHello() {
    console.log('Hello, ServiceB');
  }
}

아래와 같이 호출해도 순환참조가 발생하지 않는 이유는 무엇일까요.

function main() {
  console.log('start');

  const container = ContainerRegistry.getContainer('default');
  const serviceA = container.get(ServiceA);
  serviceA.serviceB.sayHello();
  serviceA.sayHello();
}

main();

지연 초기화

  // container-instance.ts
   private getServiceValue(serviceMetadata: ServiceMetadata<unknown>): any {
     let value: unknown = EMPTY_VALUE;
     if (serviceMetadata.value !== EMPTY_VALUE) {
       return serviceMetadata.value;
     }
     // ...
   }

서비스 인스턴스는 실제로 container.get()이 호출되기 전까지 생성되지 않습니다.
serivceMetadata.value가 EMPTY_VALUE일 때만 인스턴스가 생성됩니다.

이를 통해 불필요한 초기화를 방지하고 순환참조를 예방합니다.

의존성 해결

   // container-instance.ts
   private initializeParams(paramTypes: any[]) {
     return paramTypes.map(type => {
       if (type && type.name && !this.isPrimitiveTypes(type.name)) {
         return this.get(type);
       }
       return undefined;
     });
   }

serviceA가 초기화될 때 serviceB를 의존성으로 요청합니다.
serviceB가 초기화될 때 serviceA를 의존성으로 요청하지만, 이미 serviceA는 초기화중이므로 EMPTY_VALUE가 아닌 serviceMetadata.value를 반환합니다.

흐름

index.ts에서 container.get(ServiceA) 호출
ServiceA 초기화 시작
ServiceA의 생성자에서 ServiceB 의존성 요청
ServiceB 초기화 시작
ServiceB의 생성자에서 ServiceA 의존성 요청
ServiceA는 이미 초기화 중이라 EMPTY_VALUE가 아닌 값을 반환
ServiceB 초기화 완료
ServiceA 초기화 완료

즉, TypeDI는 자동으로 의존성 주입을 관리하여 순환참조를 방지합니다.

결론

TypeDI는 프로토타입에서 주로 사용하고, 복잡한 설정 없이도 알아서 자동으로 처리하는 데 중점을 둡니다. 더 간단하고 유연한 의존성 주입을 제공합니다.

NestJS에서는 forwardRef()를 사용하여 명시적으로 의존성 주입 시스템에 순환참조가 있음을 알리고, 이를 처리하는 방법을 제공합니다. 개발자가 순환참조를 인식하고 명시하여 직접 처리하도록 하는 데 중점을 둡니다.

소스코드 본인 깃허브 계정

https://github.com/chlcken2/typedi

GitHub - chlcken2/typedi: typedi 구현

typedi 구현. Contribute to chlcken2/typedi development by creating an account on GitHub.

github.com

개발자 "잘" 말하고 "잘" 쓰기 + 꿀팁 추가

foodev — Tue, 18 Feb 2025 16:01:37 +0900

AI가 대두되는 요즘, 개발자에게는 코딩 실력만으로는 부족합니다.

비즈니스를 이해하고 효과적으로 소통하는 능력이 더욱 중요해졌습니다.

이런 종합적인 역량은 불필요한 의사소통 비용을 줄이고 효율적인 개발로 이어져,

결국 회사와 개발자 본인의 가치를 높이는 핵심 요소가 됩니다.

현대 개발자는 기술과 비즈니스의 균형을 맞추며, 이를 명확히 전달할 수 있어야 합니다.

아래의 글들을 통해 자신의 능력을 올리는데 도움이 되었으면 좋겠습니다.

⬇️ 꿀팁은 맨아래

목차
✅ SCQA를 생각하자
✅ 조사를 제거하자
✅ 듣는이를 고려하자

SCQA를 생각하자

SCQA란?

상황(Situation) - 현재 상황/배경 설명

ex: "AI 반환 실행 횟수 초과 에러 관련하여 문의 드립니다."

복잡성(Complication) - 문제점/이슈 설명

ex: "현재 개발팀 내부에서 해당 에러로 인한 노이즈가 있어..."

질문(Question) - 확인하고 싶은 내용

ex: "혹시 이 에러 현상을 모니터링하고 계신가요?"

행동(Action) - 제안/요청사항

ex: "비활성화를 고려 중입니다."

한 번 원본과 SCQA를 적용한 수정본을 비교해보자

SQCA 적용

원본:

"OO님 AI 결과값 반환 실행 횟수 초과 에러 보고 계신가요?
개발팀 내부에서 레시피 AI 반환 에러가 노이즈해서 끄고자 하는 니즈가 있어서 확인 차 말씀드립니다"

수정본:

"결과값 반환 실행 횟수 초과 에러 관련하여 문의 드립니다.
현재 개발팀 내부에서 해당 에러로 인한 노이즈가 있어 비활성화를 고려 중입니다.
혹시 이 에러 현상을 모니터링하고 계신가요?"

주요 차이점:

구조화
- 원본: 한 문장에 여러 내용이 혼재
- 수정본: 상황 설명 → 문제점 → 질문 순으로 구조화
전문성
- 원본: "니즈가 있어서", "노이즈해서" 등 구어체 사용
- 수정본: "비활성화를 고려 중입니다" 등 공식적인 표현 사용
명확성
- 원본: 의도가 간접적으로 표현됨
- 수정본: 문제 상황과 확인하고자 하는 내용이 명확히 구분됨

실제 적용 예시들:

단순 확인이 필요할 때:
OO 기능 배포 관련 문의드립니다.
현재 배포 가능한 상태인가요?
문제 해결이 필요할 때:
[상황] 프로덕션 환경의 API 응답 지연이 발생하고 있습니다.
[복잡성] 현재 평균 응답시간이 2초를 초과하고 있으며, 사용자 불만이 접수되고 있습니다.
[잘문] 혹시 이 현상을 인지하고 계신가요?
[행동] 긴급 대응이 필요할 것 같아 회의를 제안드립니다.

이런 구조로 작성하면:

메시지의 목적이 명확해집니다
받는 사람이 빠르게 이해할 수 있습니다
필요한 액션을 쉽게 파악할 수 있습니다

조사를 제거하자

수정전

OO님 AI 결과값을 반환하기위해 실행 횟수 초과 에러를 보고 계신가요?

개발팀 내부에서 AI의 반환 에러가 노이즈해서 끄고자 하는 니즈가 있어서 확인 차 말씀드립니다

수정후

OO님 AI 결과값 반환 실행 횟수 초과 에러를 보고 계신가요?

개발팀 내부에서 AI 반환 에러가 노이즈해서 끄고자 하는 니즈가 있습니다.

듣는이를 고려하자

상대가 비개발직군이거나, 해당 도메인에 대한 지식이 없다고 할 때

개발자의 언어로 말을 한다면 1도 이해할 수 없는 상황에 놓이게 될 것입니다.

기술적 용어보다는 현재 발생하고, 해결하고자 하는 "모두가 알 수 있는 단어"로 설명합니다.

ex:
QA에서 API에러가 발생해서 안되나봐요

다음과 같이 고쳐봅시다.

테스트환경에서 백엔드에 문제가 있어서 안되나봐요

(보통 이정도는 이해하겠지라는 생각을 할까봐 극적인 예시를 가져왔습니다.)

1. QA가 누군가한테는 테스트 환경, 브랜치, 검수 과정으로 해석될 수 있습니다. 정확한 의미를 전달합시다.

2. API에서 에러가 어떻게 발생했고, 무엇이 문제인지 "관심 없는 경우가 많습니다." 그래서 말하고자 하는바가 무엇인지에 집중하세요.

말을 하거나 글이 어려운게 결론부터 말을 하고 시작할지, 상황을 먼저 말해야할지, 결론이 2개인것 같기도합니다.

이런 경우들을 기술이 포함되어 있는 경우는 더 말을 복잡하게 만듭니다.

SCQA 구조를 꼭 기억하셔서 회사 생활에 도움이 되었으면 좋겠습니다!

항상 자연스러운 문맥구조와 듣는이를 고려해서 말해봐요~!

⭐️ 꿀팁

내가 글 쓰는게 너무 어렵다! 싶으면
gpt, claud, gemini등에 "SCQA 구조로 변경해줘" 프로젝트를 만들어둡시다.

알아서 우리의 문법을 듣기 좋게 수정해줍니다

글 잼나게 보셨으면 좋아요 눌러주고 가세요

관심받는 거 좋아합니다

(공식문서) NestJS Pipes와 queryString, Body가 데이터 처리하는 방법

foodev — Tue, 18 Feb 2025 13:51:05 +0900

파이프는 @Injectable() 데코레이터로 주석이 달린 클래스로, PipeTransform 인터페이스를 구현합니다.

관련된 링크 : https://docs.nestjs.com/pipes

목차
✅ 파이프의 일반적 사례
✅ 파이프 바인딩과 적용
✅ queryString과 body의 데이터 처리 차이점

파이프의 일반적 사례

transfromation: 입력 데이터를 원하는 형식(예: 문자열에서 정수로)으로 변환합니다.

validation: 입력 데이터를 평가하여 유효하면 변경 없이 통과하고, 그렇지 않으며 예외를 던집니다.

두 경우 모두 컨트롤러 경로 핸들러에서 처리 중인 인수에 대해 작동합니다

파이프 작동 방식

요청: 클라이언트가 서버로 요청을 보냅니다.
파이프 실행: NestJS는 요청 데이터를 파이프에 전달합니다.
변환 & 검사: 파이프는 데이터를 변환하고 유효성을 검사합니다.
결과 반환: 파이프는 변환되고 검증된 데이터를 컨트롤러에 전달합니다.
컨트롤러 실행: 컨트롤러는 파이프가 제공한 데이터를 사용하여 로직을 처리합니다.

파이프는 예외영역에서 실행됩니다.

파이프에서 예외가 발생하면 exception filters에서 처리됩니다

파이프 바인딩과 적용

queryString 에서 Pipe

@Get(':id') async findOne(@Param('id', ParseIntPipe) id: number) 
{ 
    return this.catsService.findOne(id); 
}

다음과 같은 ParseIntPipe를 사용했다고 가정합니다

그러면 id값은 number이거나 예외를 발생합니다.

GET localhost:3000/개발개맛집이 들어왔다면

typeof(id)의 결과는 string이 됩니다.

이에 따라 예외 필터에 걸려서 아래의 문구를 보게 됩니다.

{
  "statusCode": 400,
  "message": "Validation failed (numeric string is expected)",
  "error": "Bad Request"
}

이렇게 pipe가 예외를 던지는 이유는 findOne() 함수가 실행되지 않도록 함에 있습니다.

body에서 Pipe 적용은?

위에 내용은 쿼리스트링에서 pipe를 적용했습니다.

그렇다면 POST 메소드의 body 값에는 어떻게 적용할 수 있을까요?

아쉽게도 NestJS의 pipe를 이용하여 body 값을 체크할 수 없습니다.

보통 class-decorator를 import 하여 사용하거나 nestia의 typechecking 함수를 이용합니다.

uuId 체크 예시:

import { IsUUID } from 'class-validator';
export interface CreateEventBody {
  @IsUUID()
  uuid?: string;
  prevUrl?: string;
}

queryString과 body의 데이터 처리 차이점

데이터가 도착하는 시점

쿼리 스트링: 쿼리 스트링은 URL의 일부로, 요청이 서버에 도착하는 즉시 파싱되어 파이프에 전달됩니다.
본문(Body): 본문 데이터는 요청의 내용 부분으로, 서버에 도착한 후 별도의 처리를 거쳐야 파이프에 전달될 수 있습니다.

데이터 처리 방식

쿼리 스트링: 쿼리 스트링은 주로 문자열 형태로 전달됩니다. 파이프는 이 문자열을 원하는 타입(숫자, 날짜 등)으로 변환하거나 유효성을 검사합니다.
본문(Body): 본문 데이터는 다양한 형식(JSON, XML 등)으로 전달될 수 있습니다. 파이프는 이 데이터를 파싱 하고, 필요한 경우 변환하거나 유효성을 검사합니다.

파이프 적용 시점

쿼리 스트링: 쿼리 스트링은 요청과 함께 도착하므로, 파이프가 즉시 적용될 수 있습니다.
본문(Body): 본문 데이터는 파싱 과정을 거쳐야 하므로, 파이프는 파싱 후에 적용될 수 있습니다.

글 잼나게 보셨으면 좋아요 눌러주고 가세요

관심받는 거 좋아합니다

GitHub 라벨 또는 태그로 Azure API Container에 CI/CD 적용하기

foodev — Fri, 14 Feb 2025 00:37:36 +0900

브랜치를 푸시하거나, 라벨을 붙이거나, 태그를 추가할 경우
GitHub Action을 이용하여 Azure API Container에 자동으로 배포하는 방법을 공유합니다.

저희 팀에서는 변형된 Git flow 전략으로 버전 관리를 하고 있습니다

그중 QA 브랜치만 다루도록 하겠습니다.

목차
✅ CI/CD에서 원하는 동작
✅ GitHub Action workflow 생성
✅ Azure 배포 프로세스의 이해 ⭐️⭐️⭐️
✅ 만약 안되는 부분이 있다면
✅ 회고

CI/CD에서 원하는 동작

QA 브랜치에 PR을 만들고 "QA"라벨을 추가하면 자동 CI/CD가 되도록 구현하려고 한다.

GitHub Action workflow 생성

workflow 파일 코드

name: Trigger auto deployment for heroines-qa-api

# When this action will be executed
on:
  pull_request:                  #  Pull Request 이벤트에 대해 워크플로우가 트리거됨
    types: [labeled]             # 그중에서도 라벨이 추가될 때만

  # Automatically trigger it when detected changes in repo
  push:
    branches:                   # qa 브랜치에 푸시가 되었가나,  
      - qa
    tags:                       # QA 태그가 붙거나,
      - QA
    paths:
      - '**'
      - '.github/workflows/heroines-qa-api-AutoDeployTrigger-1cb86b57-8b3a-403e-8699-b788c8702b1b.yml'

  # Allow manual trigger
  workflow_dispatch:

jobs: # 작업을 실행할 때 라벨 중 QA 태그가 붙었거나, 푸시가 있거나, work_dispatch 실행했으면 조건 실행 
  build-and-deploy:
    if: |
      github.event_name == 'pull_request' && github.event.label.name == 'QA' ||
      github.event_name == 'push' ||
      github.event_name == 'workflow_dispatch' ||
      startsWith(github.ref, 'refs/tags/QA')
    runs-on: ubuntu-latest
    permissions:
      id-token: write # This is required for requesting the OIDC JWT Token
      contents: read # Required when GH token is used to authenticate with private repo

    steps:
      - name: Checkout to the branch
        uses: actions/checkout@v2

      - name: Azure Login
        uses: azure/login@v1
        with:
          client-id:
          tenant-id:
          subscription-id: 

      - name: Build and push container image to registry
        uses: azure/container-apps-deploy-action@v2
        with:
          appSourcePath:
          dockerfilePath: 
          registryUrl: 
          registryUsername: 
          registryPassword:
          containerAppName: 
          resourceGroup: 
          imageToBuild: 
          _buildArgumentsKey_: 

        if: always()

Azure 배포 프로세스의 이해

공식문서를 대충 읽어보고 구현에만 집중해서 정확하지 않을 수 있습니다. 잘못된 내용이라면 댓글 부탁드립니다.

Azure API container 배포 이용하기

Azure API Container 서비스에서 CD기능을 기본적으로 제공한다.

단, 푸시에 관련해서만 가능한 것으로 확인된다.

pull_request 방식은 다른 방식을 federated identity crdential Subject라면서 안된다.

이것 때문에 삽질을 열심히 했다..

복붙 아닙니다

또다른 방법 Azure Active Directory 앱 설정하기

1. 모든 서비스 검색: azure active directory

2. 좌측 탭: 앱등록 클릭

3. 상단 새 등록 버튼 클릭

4. 이름 할당 및 이 조직 디렉터리의 계정만(기본 디렉터리만 - 단일 테넌트) 생성
5. 리디렉션은 생략

6. 생성

아래 ID를 필히 기억하자!!

애플리케이션 ID : 깃헙 시크릿매니저 등록용
개체 ID : Azure 구독 등록용
디렉터리 ID: 깃헙 시크릿매니저 등록용

6. 좌측 API 사용권한 클릭

7. 권한추가 클릭

8. azure service Management 클릭

9. 권한추가

여기까지 따라오면 잘한 것!

10. 다시 모든 서비스 검색: 구독으로 이동

11. 마이크로 스폰서십 클릭

12. 좌측 액세스 제어(IAM) 클릭

13. 상단 추가 클릭 -> 역할 할당 추가

14. 권한 부여

⚠️ 여기서 정말 삽질한 부분 2가지가 있다. 삽질을 하다가 이글까지 흘러온 개발자라면 아래를 놓치지 말 것.

권한 부여를 위에 6번에서 생성한 앱을 등록해야 한다.

검색할 때 개체 ID로 검색해야 한다.(개체 아이디 없으면 애플리케이션 ID, 디렉터리 ID로 검색)

구성원 검색이라는 말이 Azure 사용자인 줄 알았는데 앱이라니

그리고 다른 곳에서는 개체 ID가 아닌 애플리케이션 ID를 넣으면 된다고 했는데,

계속 안 떠서 설마.. 하고 개체 ID 넣었는데 검색이 되었다...

15. 권한 부여 방법: 구성원 - "기여자" 선택 -> 구성원 선택 -> 개체 ID로 검색 -> 할당

결과 확인

만약 안 되는 부분이 있다면

올바른 디렉터리(테넌트) 확인

디렉터리 일치 여부:
서비스 프린시플(앱 등록)이 생성된 Azure Active Directory와 현재 역할 할당을 진행하는 디렉터리가 동일한지 확인
Azure Portal 오른쪽 상단에 표시되는 디렉터리 이름이 맞는지, 필요하다면 상단의 디렉터리 전환 메뉴에서 올바른 디렉터리로 전환

Enterprise Applications에서 Object ID 확인

Enterprise Applications에서 서비스 프린시플 찾기:
1. Azure Portal 좌측 메뉴에서 "Azure Active Directory" > "Enterprise Applications"로 이동
2. "모든 애플리케이션(All applications)" 목록에서 해당 서비스 프린시플을 찾기
Object ID 복사:
3. 해당 애플리케이션을 클릭한 후, 개요(Overview) 페이지에서 객체 ID(Object ID)를 복사

검색 필터 및 보기 옵션 조정

필터 확인:
역할 할당 선택 창 상단에 있는 필터(예: “모두 보기”, “서비스 주체”, “사용자”) 옵션을 “서비스 주체” 또는 “모두 보기”로 변경

권한 및 생성 상태 확인

앱 등록 상태 확인:
앱 등록에서 해당 애플리케이션이 정상적으로 생성되었는지, 그리고 Enterprise Applications에도 나타나는지 재확인
추가 생성:만약 계속 보이지 않는다면, 앱 등록을 다시 한번 확인하고, 필요시 새 앱 등록을 만들어 동일한 과정을 진행해 볼 수 있음

회고

당초 계획했던 기능 개발이 일정보다 빨리 완료되어,

CTO님의 업무를 자진해서 맡았다가 중간에 살짝 도전적이었던 순간들이 있었다.

이전 Azure DB 관련 이슈로 인해 인프라 작업에 대한 부담감이 있었지만,

이번 기회를 통해 Azure 시스템을 직접 다루면서 그동안의 심리적 장벽을 조금이나마 허물 수 있었다.

특히 새로운 방식으로 CI/CD를 구현하면서 기술적 성장을 체감할 수 있었다.

문제 해결 과정에서는 시스템 전반을 단계별로 분석하고 이슈 발생 지점을 추적하는 체계적인 접근 방식을 취했 다.

처음 세운 가설이 실제 원인과 일치하여 신속한 문제 해결이 가능했고,

이를 통해 기술적 직관력과 문제 해결 능력이 한층 성장했음을 느낄 수 있었다.

글 잼나게 보셨으면 좋아요 눌러주고 가세요

관심받는 거 좋아합니다

NestJS Exception Filters 완벽 정리 (라이프사이클부터 내부 동작까지)

foodev — Wed, 12 Feb 2025 10:36:49 +0900

NestJS Exception Filters 정리

NestJS에는 애플리케이션 전역에서 처리되지 않은 모든 예외를 담당하는 예외 계층(Exception Layer) 이 내장되어 있습니다.
애플리케이션 코드에서 예외가 처리되지 않고 발생하면, 이 계층이 이를 포착하여 사용자 친화적인 HTTP 응답을 자동으로 반환합니다.

공식 문서: https://docs.nestjs.com/exception-filters

NestJS 요청 라이프사이클

클라이언트 요청이 컨트롤러에 도달하기까지의 흐름은 다음과 같습니다.

클라이언트 요청
미들웨어 실행 (로깅, 인증 등)
가드 실행 (권한 체크: AuthGuard, AdminGuard 등)
인터셉터 시작
파이프 실행 (데이터 변환 / 유효성 검사)
컨트롤러 메서드 실행
서비스 로직 실행
인터셉터 종료
응답 반환

⚠️ 에러가 발생하면?

위 과정 중 어디에서든 예외가 발생하면

Exception Filter가 에러를 캐치
적절한 에러 응답을 클라이언트에 반환

Exception Filters의 주요 목적

1️⃣ 에러 캐치

요청 라이프사이클 전역에서 발생한 예외를 처리

2️⃣ 에러 커스텀

에러 응답 포맷을 프로젝트 기준에 맞게 통일
메시지, timestamp, path 등 추가 가능

Exception Filters가 에러를 잡을 수 있는 이유

핵심은 @Catch() 데코레이터입니다.

export declare function Catch(
  ...exceptions: Array<Type<any> | Abstract<any>>
): ClassDecorator;

의미 정리

...exceptions
- 여러 개의 예외 타입을 Rest Parameter로 전달 가능
Type
- 구체적인 클래스
Abstract
- 추상 클래스 또는 인터페이스
반환값
- ClassDecorator

// Type 예시
class HttpException {}

// Abstract 예시
abstract class BaseException {}
interface IException {}

즉, 특정 예외 타입만 골라서 필터링 가능합니다.

Node Modules 내부 동작 구조

BaseExceptionFilter

기본 예외 처리 로직을 담당하는 추상 필터 클래스입니다.

export declare class BaseExceptionFilter<T = any>
  implements ExceptionFilter<T> {
  catch(exception: T, host: ArgumentsHost): void;
}

기본 catch() 구현 제공
알 수 없는 에러 처리 로직 포함

BaseExceptionFilterContext

필터 인스턴스 생성 및 관리
DI 컨테이너와 연동

ExceptionsHandler

예외 처리 시스템의 중심

발생한 예외를 적절한 필터로 라우팅

export declare class ExceptionsHandler extends BaseExceptionFilter {
  next(exception: any, ctx: ArgumentsHost): void;
}

전체 흐름 요약

예외 발생
  ↓
Router / Middleware (최초 캐치)
  ↓
ExceptionsHandler
  ↓
BaseExceptionFilterContext
  ↓
BaseExceptionFilter or ExternalExceptionsFilter

예외 처리 방법들

기본 제공 방식

throw new HttpException('접근 금지!', HttpStatus.FORBIDDEN);

{
  "statusCode": 403,
  "message": "접근 금지!"
}

하지만 응답을 더 커스터마이징하고 싶다면?

➡️ Exception Filter를 사용합니다.

Exception Filters를 활용한 커스텀

@Catch(HttpException)
export class MyExceptionFilter implements ExceptionFilter {
  catch(exception: HttpException, host: ArgumentsHost) {
    const response = host.switchToHttp().getResponse();

    response.status(403).json({
      statusCode: 403,
      timestamp: new Date(),
      message: '죄송합니다. 접근 권한이 없습니다.',
      path: '/admin',
    });
  }
}

언제 쓰면 좋을까?

에러 로깅을 하고 싶을 때
에러 응답 포맷을 통일하고 싶을 때
특정 예외만 다르게 처리하고 싶을 때

여러 예외 처리

@Catch(HttpException, ValidationError)
export class AllExceptionsFilter implements ExceptionFilter {
  catch(exception: unknown, host: ArgumentsHost) {}
}

@Catch()
export class CatchAllFilter implements ExceptionFilter {}

Exception Filters vs Pipes

Exception Filters

발생한 예외를 처리
클라이언트에 반환할 응답을 결정

Pipes

컨트롤러 진입 이전에 실행
데이터 변환 / 유효성 검사

❗ Pipe에서 발생한 예외도 결국 Exception Filter에서 처리됩니다.

Interceptor 정리

역할

메서드 실행 전/후 로직 추가 (AOP)
응답 변환
예외 변환
캐싱, 로깅, 타임아웃 처리

구조

@Injectable()
export class LoggingInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const now = Date.now();
    console.log('Before...');

    return next.handle().pipe(
      tap(() => console.log(`After... ${Date.now() - now}ms`)),
    );
  }
}

Guard 정리

Guard란?

라우트 핸들러 실행 여부를 결정
권한, 인증, 역할 기반 제어

export interface CanActivate {
  canActivate(
    context: ExecutionContext,
  ): boolean | Promise<boolean> | Observable<boolean>;
}

Guard vs Middleware

구분GuardMiddleware

실행 시점	핸들러 직전	라우트 이전
역할	접근 허용 여부 결정	요청/응답 객체 수정
Context	ExecutionContext 접근 가능	핸들러 정보 접근 불가

Pipes와 Query / Body 처리

Query String

@Get(':id')
findOne(@Param('id', ParseIntPipe) id: number) {}

{
  "statusCode": 400,
  "message": "Validation failed (numeric string is expected)",
  "error": "Bad Request"
}

잘못된 값이면 컨트롤러 진입 자체를 막음

Body 처리

Pipe로 직접 검증 ❌
class-validator 사용 ⭕️

export class CreateEventBody {
  @IsUUID()
  uuid?: string;
}

마무리

Exception Filter는 에러 처리의 마지막 보루
Pipe / Guard / Interceptor와 함께 사용할 때 진짜 위력이 나옵니다

글이 도움이 됐다면 좋아요 한 번 눌러주세요

관심 받는 거 좋아합니다

테스트 코드 현실 적용기: Unit Testing 책을 통한 인사이트와 실무 경험

foodev — Wed, 29 Jan 2025 22:19:00 +0900

Unit Testing 책 리뷰와 실무 적용기

들어가며

"Unit Testing: Principles, Practices, and Patterns"(Vladimir Khorikov 저) 책을 읽고 실무에 적용하면서 느낀 점을 정리해보았습니다. 테스트 코드를 작성하는 여러 방법론과 실제 현장에서의 적용 과정에서 배운 점들을 공유하고자 합니다.
(실은 읽다가 어려워서 누락된 내용도 꽤 많아요 ㅎㅎ이해하고 넘어가주세요)

책의 핵심 내용

테스트의 기본 원칙

테스트는 비즈니스 시나리오를 반영해야 함
테스트 가독성이 중요
테스트가 구현이 아닌 동작을 검증해야 함

단위 테스트의 정의

작은 코드조각을 검증하고
빠르게 수행하고
격리된 방식으로 처리하는 자동화된 테스트

고전파 vs 런던파

격리 문제로 인한 두 학파의 차이

고전파: 실제 의존성을 사용
런던파: 모든 의존성을 mock으로 대체

// 고전파 예시
test('주문 생성', () => {
  // 실제 의존성 사용
  const db = new Database();
  const payment = new Payment();
  
  const order = new Order(db, payment);
  order.create();
  
  expect(db.findOrder()).toBeDefined();
});

// 런던파 예시
test('주문 생성', () => {
  // 모든 의존성을 mock으로 대체
  const mockDB = { save: jest.fn() };
  const mockPayment = { process: jest.fn() };
  
  const order = new Order(mockDB, mockPayment);
  order.create();
  
  expect(mockDB.save).toHaveBeenCalled();
});

두 학파의 주요 차이점

테스트 주도 개발을 통한 시스템 설계 방식
과도한 명세 문제

테스트 주도 개발(TDD)

TDD의 핵심 원칙

실패하는 테스트를 먼저 작성
코드가 완벽하지 않아도 됨
읽기 쉽고 유지보수가 용이하도록 작성

실무 적용 경험

프로젝트 진행 과정

기획 완료 후 프론트엔드/백엔드 동시 개발 시작
데이터 모델 설계
Swagger를 통한 API 문서화 및 소통
개발 완료 후 API 테스트 및 QA

실무에서 겪은 어려움과 해결책

Swagger 문서 작성이 TDD로 인해 지연되는 문제 발생
해결책: Swagger용 mock 객체 먼저 생성 후 TDD 진행
현재는 API 개발 후 AI 도움을 받아 테스트 케이스 작성

테스트 유형별 특징

통합 테스트와 E2E 테스트

통합 테스트: 여러 컴포넌트간 상호작용 검증
E2E 테스트: 전체 시스템 흐름 테스트

테스트 대역(Test Double)의 이해

더미(Dummy): 단순 전달용 객체
스텁(Stub): 미리 준비된 응답 제공
스파이(Spy): 메서드 호출 기록
목(Mock): 예상 동작 검증
페이크(Fake): 간소화된 실제 구현체

블랙박스/화이트박스 테스트

블랙박스: 내부 구조를 모르는 상태에서 테스트
화이트박스: 내부 구조를 아는 상태에서 테스트

테스트 피라미드

테스트 코드의 이상적인 구조

단위 테스트 >> 통합 테스트 >> E2E 테스트 순으로 작성 권장

피라미드 구조를 권장하는 이유

E2E 테스트의 한계
- 높은 유지보수 비용
- 긴 실행 시간
- 불안정성 (깨지기 쉬움)
단위 테스트의 장점
- 빠른 실행 속도
- 안정적인 결과
- 문제 발생 지점 특정 용이

테스트 유형별 코드 예시

1. 단위 테스트

// 독립적인 단위 기능 테스트
test('이메일 유효성 검사', () => {
  const validator = new EmailValidator();
  expect(validator.isValid('test@email.com')).toBe(true);
  expect(validator.isValid('invalid-email')).toBe(false);
});

2. 통합 테스트

// 여러 컴포넌트 연동 테스트
test('유저 생성 및 이메일 발송', async () => {
  const userService = new UserService(database, emailService);
  const user = await userService.createUser({
    email: 'test@email.com',
    name: 'John'
  });
  
  // 실제 DB 저장 및 이메일 발송 검증
  const savedUser = await database.findUser(user.id);
  expect(savedUser).toBeDefined();
});

3. E2E 테스트

// 전체 시스템 흐름 테스트
test('회원가입 프로세스', async () => {
  // 회원가입
  const signupRes = await request(app)
    .post('/api/signup')
    .send({
      email: 'test@email.com',
      password: 'password123'
    });
  
  // 로그인 및 토큰 발급
  const loginRes = await request(app)
    .post('/api/login')
    .send({
      email: 'test@email.com',
      password: 'password123'
    });
  
  // 인증이 필요한 API 호출
  const profileRes = await request(app)
    .get('/api/profile')
    .set('Authorization', loginRes.body.token);
  
  expect(profileRes.status).toBe(200);
});

테스트 접근 방식

블랙박스 테스트

내부 구현을 모르는 상태에서 테스트
What에 집중 (어떤 결과가 나와야 하는가)
명세와 요구사항 기반 테스트

화이트박스 테스트

내부 구현을 아는 상태에서 테스트
How까지 고려 (어떻게 동작하는가)
더 철저한 테스트 가능

테스트 대역의 활용

테스트 대역의 다섯 가지 유형과 특징:

더미(Dummy)
- 가장 단순한 형태
- 실제로 사용되지 않고 전달만 됨
스텁(Stub)
- 미리 준비된 응답 제공
- 상태 기반 테스트에 활용
스파이(Spy)
- 호출 정보를 기록
- 실제 객체처럼 동작하면서 정보 수집
목(Mock)
- 기대하는 동작 정의 및 검증
- 행위 검증에 중점
페이크(Fake)
- 실제 구현을 단순화한 대체제
- 실제와 유사하게 동작

각 대역의 선택은 테스트의 목적과 상황에 따라 결정해야 합니다.

실무 적용 사례

현재 팀의 테스트 전략

단위 테스트
- 서비스 레이어의 비즈니스 로직 검증
- DB 의존성 없는 순수 로직 테스트
E2E 테스트
- API 엔드포인트 검증
- 실제 사용자 시나리오 기반 테스트

테스트 작성 프로세스

API 설계 및 개발
시나리오 도출
테스트 케이스 작성
AI 도구를 활용한 테스트 보완

2024년 연말회고

foodev — Wed, 1 Jan 2025 13:34:20 +0900

자잘자잘하게 따져보면 flutter, JSP, 노코드 등등도 있다

완벽히 NestJS + TS 개발자가 되었다.

올해는 특히 TyepsScript 핸드북 Doc을 모두 정독하고,

사내 시험을 보면서 TS와 TS 모듈에 대한 더 깊은 이해를 가지게 되었다.

외부 시스템 연동

오퍼월과 기프티콘 시스템을 적용하기 위해 외부 업체와 협업한 일이 많았다.

소통 단계에서 요구해야할 사항들(ex: 개발계/운영계/테스트계 화이트리스트 IP등록)과

외부 업체와 메일 소통의 방법에 대해 많이 배우게 되었다.

또한 기프티콘 시스템을 도입하게 되면서 도메인에 대한 이해와 예외적으로 발생할 수 있는 상황들을 경험하게 되었다.

(ex: 업체의 문제로 상품 구매가 안될 경우가 존재 : 임시발급 단계 -> 발급과정을 거치고, try-catch로 상품 구매 에러가 발생할 경우

슬랙 알림 메시지 알림 + 상품 구매 시스템 점검으로 바꾸기 등)

성능 최적화

1. HardDelete를 SoftDelete로 바꾸고,

무거운 부하는 배치 작업으로 새벽에 돌리도록 바꾸었다.

2. 페이지네이션 방식을 Offest -> Cursor 방식으로 바꾸었다.

3. Index를 적용했다.

25년 현재 Redis와 MessageQueue를 이용하여 최적화 작업을 계속 진행 중에 있다.

주말근무와 야근으로 절대적인 시간이 많아졌다

2년 치 회사 DB 날려서 법원 갈 뻔한 사람이 기록하는 회고록

foodev — Sat, 10 Aug 2024 15:37:12 +0900

타노스도 우주의 절반만 날리는데...

'딸깍'
약 200GB 데이터가 84KB가 되었던 순간.
대략 99.99996%를 날려버린 나는, 타노스보다 더 한 악당이 되었다.

사건의 시작 - 부제: 앱 접속 시 회원가입이 되는데요?

2024 07.29 오전 11시 30분

욕 한마디 안 하시던 CTO님이

아침 회의 이후 화장실에 다녀오시더니 급히 문을 열고 들어오셨다.
평소엔 차분한 그분의 목소리가, 그날만은 달랐다.

'시x 다들 앱 실행해 보세요!'
나는 "응? 무슨 일이지" 하는 마음으로 앱을 열었는데, 회원가입이 되는 걸 보았고,

뭔가 단단히 잘못되었다고 느꼈다.
그 순간 운영 업무 하는 분이 '갑자기 고객문의가 계속 들어오고 있어요!'

말을 전해주면서 등에 식은땀이 나기 시작했다.

select * from users limit 10; result = 0;

DB 유저 정보를 조회하는데 하나도 뜨지 않았다.
"응?",
"local DB에 쿼리를 날렸나?"
다시 한번 DB 이름을 확인했다.
"응...?"
main DB 이름이 맞았다.

.
"이건 꿈일 거야"

문제가 될 수 있는 부분들을 파악해 보았다.
그리고 곧바로 알아낼 수 있었다.

. env 파일에 main DB URL과 local DB URL 모두 주석이 해제되어 있었다.
(필자는 prisma orm을 사용한다)

정말 내가 한 실수 때문일까?
잘못된 DB 주소를 검색한 게 아닐까?

라는 생각들을 하며
내 실수로 발생한 게 아니길 바랐다.

그러나 나도 알았다.
내 실수로 일어난 일이란 것을...

이실직고

'제가 잘못한 것 같습니다.'
나는 이 말을 뱉을 수밖에 없었고

말하지 싫었던, 하지만 말할 수밖에 없던

그 순간의 감정과 심장박동을 잊을 수 없다.

prima ORM을 이용해서 테이블을 생성할 때

--create-only 옵션을 키지 않고, 실서버로 연결해 두어서 발생했다.

사내 모든 업무 중지

에어컨을 최저로 낮추고 있던 사무실이었는데도

온몸이 땀에 젖어 축축했다.
일단은 DB 복구가 제일 먼저다라는 생각이 들었다.
그러면서도

시간이 갈수록 점점 패닉상태가 되었다.
속으로 "하 xx x 됐다..."와 "개발자 인생은 이제 끝이다"라는 생각이 계속 맴돌었다.

우선 고객 대응을 위해

대표님 포함, 개발직군 외에 CS팀에 편성되어 고객응대를 하였고,

프런트 개발자와 디자이너분이
서비스에는 비상 전면 앱 공지 팝업을 띄웠다.

그리고 백엔드를 담당하는 CTO님과 나는
계속 해결법을 찾았다.

속으로 "하 xx..."이라는 말이 계속 나왔다...

한 줄기의 빛 aurora DB... 사랑해...

CTO님과 붙어
초기화 됐던 시점, DB 스펙 점검, DB스펙에서 특정 시점으로 롤백하는 방법을 포함하여 쿼리 로그를 찾아보았다.

그러던 중 CTO님이 aurora DB에서 시점으로 롤백하는 기능이 있는 것을 알아내셨고,
사건이 터진 시점은 10시 37분이었지만 여러 가지를 고려해 2분 차이를 두고 10시 35분으로 롤백할 수 있었다.
(2분 차이를 둔 이유는 찰나의 순간으로 생성된 데이터 보존을 위함이었다)

DB upgrade내역을 찾아보니
약 3달 전인 24년 4월 DB lack이 있어서 aurora DB로 업그레이드했었는데,

aurora DB 스펙에서 롤백기능을 제공했고,

이전에 쓰던 DB에서는 롤백 기능을 제공하지 않았다.
만약 4월 이전에 이런 일이 있었다면...

하아.... 난 감방 가야 했다

새로운 auroraDB를 띄우고 proxy 서버와 연결을 해주고, proxy DB 설정도 다 해주고

3시간 정도 흐른

오후 2시 즈음이 되어야 DB를 복구를 할 수 있었다.

동료들과 CTO님께 감사하고 너무 죄송했다.

~~이때 끊었던 담배를 다시 피우게 되었고,~~
~~등과 바지가 흥건히 땀에 절어 있었다.~~

해결 이후

로그인이 되지 않아 해당 시간에 접속한 유저뿐 아니라 모든 유저에게 보상 금액을 지원했다.
대략 n천만 원의 포인트가 유저들에게 지급되었다.

다른 팀원들도 당일 해야 하는 업무가 있었는데 업무가 모두 밀렸다.

대표님께 면담을 요청했다.
이 회사에서 서버를 날린 이력도 있었는데,

이번엔 DB를 날려버렸다.
나의 개발자 인생은 "여기까지다"라고 생각했다.
암울했다. 죄송했다. 죽고 싶은 심정이었다.

대표님에게 책임지고 퇴사를 하겠다고 했다.

대표님은
"당연히 징계는 있다. 하지만 OO 씨의 퇴사를 생각한 건 아니다"라는 말과 함께
"퇴사는 책임지는 게 아니라 회피다"
"이 계기로 더 성장했으면 좋겠다."
"바빠서 인프라를 못 챙긴 회사 책임도 있다"
라고 해주셨다.

나는 대표님과 CTO님을 포함한 동료들이
누구보다 일찍 출근하고 늦게 퇴근하고,

고객에게 어떤 기쁨을 줄지 매일 고민하는 것을 보면서
어떤 마음으로 서비스를 키워가고 있는지 너무도 잘 아는 마음에

죄송함으로 며칠을 보낸 기억이 아직도 생생하다.

재발 방지 그리고 회고

이번 사건을 회고해 보았을 때 왜 이런 일이 발생했을까 생각해 보았다.

1. 바쁘다고 미루고 미루던 DB 계정 별 접근 권한을 주지 않았다.

너무도 당연한 이야기지만,

DB 접근 계정에 권한을 주지 않았다.

백엔드 개발은 CTO님과 나 둘이 담당하고

워낙 많은 업무를 처리하다 보니 넘어갔었다.

(~~귀찮음이 컸다.~~)

이 날 이후로
Main, QA DB 별 계정 권한에 read-only 계정과

create, update, read권한을 부여한 계정을 생성했다

그리고 모두 deleted, drop 권한은 주지 않았다.

2. 바쁘다고 업무 루틴을 지키지 않았다.

핑계라면 핑계지만,,, 전 날 노트북이 맛 가서 초기화를 진행했다.
그 이후로 키보드 배열 세팅등 사소한 부분들이 모두 초기화되었는데,
달라진 환경에서 prisma 배포하는 과정에서 체크하는 루틴이 있었는데
업무 루틴을 지키지 않았다.

싸함은 틀리지 않는다.

3. 컨디션 관리

아침부터 뇌가 멍했다.
과로로 인해 수면을 충분히 취하지 못했고,

카페인에 뇌가 절여진 것 같은 집중력이 한몫했던 것 같다.

앞으로는 절대, 어떤 회사를 가더라도 DB 권한 체크부터 할 것이다.
그리고 멘탈도 많이 나갔는데, 정신 다 잡고, 공부를 더 해야겠다고 느꼈다.
요즘은 아침 1-2시간 이른 출근 후 공부를 하고 있다.

To. 이 글을 보고 있는 친애하는 개발자 분들에게.
나의 이 당시 감정이 100% 전달될 순 없겠지만,
세상의 어떤 개발자에게 이런 비극적이고 참혹한 일이 일어났었습니다.
자신이 현재 겪고 있는 개발적인 어려움은 저의 일로 위안이 되시길 바랍니다.
일정에 쫓기고, 상사한테 욕을 먹을 때마다
"에이 그래... DB 날린 것도 아닌데 뭐~" 이런 마인드셋으로 이겨내시길 바랍니다.
그리고 권한 부여는 꼭 합시다...

백엔드 게시판 DB 스냅샷 구조 vs 히스토리 구조 차이점 및 정리

foodev — Sun, 21 Jul 2024 17:51:13 +0900

안녕하세요,

이번 포스팅에서는 NestJS 개발 중 알게 된 스냅샷과 히스토리 개념에 대해 이야기해보려고 합니다.

NestJS 개발 커뮤니티에서 유명한 '삼촌님'의 깃허브 레포지토리를 참고하면서 스냅샷 방식을 도입하게 되었습니다.

이전에는 히스토리성 로그 방식의 테이블을 사용했는데요,

이번 글에서는 두 방식의 차이점과 각각의 특징, 그리고 도입 예제에 대해 알아보겠습니다.

스냅샷과 히스토리성 테이블의 차이점

데이터 저장 방식

히스토리 테이블: 변경된 내용만 순차적으로 기록합니다.
"어제 뭐 했더라..." (매일매일 일기 쓰는 느낌)
스냅샷: 특정 시점의 전체 상태를 저장합니다.
"자, 여기 내 전재산!" (인생 통장 사진 찍기)

조회 성능

히스토리 테이블: 최신 상태를 얻기 위해 여러 레코드를 조회하고 계산해야 합니다.
스냅샷: 최신 스냅샷만 조회하면 되어 빠른 조회가 가능합니다.

저장 공간

히스토리 테이블: 변경 사항만 저장하여 공간 효율적입니다.
스냅샷: 전체 상태를 저장하므로 더 많은 공간이 필요합니다.

복원 용이성

히스토리 테이블: 특정 시점으로의 복원이 복잡할 수 있습니다.
스냅샷: 원하는 시점의 스냅샷을 선택하여 쉽게 복원이 가능합니다.

구현 복잡도

히스토리 테이블: 변경 추적 로직이 복잡할 수 있습니다.
스냅샷: 상대적으로 단순한 구현입니다.

다음은 삼촌님의 ERD 설계도 입니다.

다음 링크를 클릭하시면 상세히 보실 수 있습니다.

https://github.com/samchon/bbs-backend/blob/master/docs/ERD.md

bbs-backend/docs/ERD.md at master · samchon/bbs-backend

Simple Bullet-in Board System Backend. Contribute to samchon/bbs-backend development by creating an account on GitHub.

github.com

위 스냅샷 예제를 기반으로 prisma와 nestjs Repository는 어떻게 만들어야하는지 알아보겠습니다.

Prisma 예시 코드

model OnboardingGoal {
  id         String                   @id @default(uuid())
  user       User                     @relation(fields: [userId], references: [id])
  userId     String                   @unique @map("user_id")
  createdAt  DateTime                 @default(now()) @map("created_at") @db.Timestamptz(3)
  updatedAt  DateTime                 @updatedAt @map("updated_at") @db.Timestamptz(3)
  snapshots  OnboardingGoalSnapShot[] @relation("snapshots")
  snapshot   OnboardingGoalSnapShot?  @relation(fields: [snapshotId], references: [id])
  snapshotId String?

  @@map("onboarding_goal")
}

model OnboardingGoalSnapShot {
  id               String           @id @default(uuid())
  onBoardingGoal   OnboardingGoal   @relation("snapshots", fields: [onBoardingGoalId], references: [id])
  onBoardingGoalId String           @map("onboarding_goal_id")
  goalStartDate    DateTime         @map("goal_start_date") @db.Timestamptz(3)
  goalEndDate      DateTime         @map("goal_end_date") @db.Timestamptz(3)
  goalHours        Int              @map("goal_hours")
  goalSteps        Int              @map("goal_steps")
  createdAt        DateTime         @default(now()) @map("created_at") @db.Timestamptz(3)
  updatedAt        DateTime         @updatedAt @map("updated_at") @db.Timestamptz(3)
  OnboardingGoal   OnboardingGoal[]

  @@map("onboarding_goal_snapshot")
}

Repository 생성 예시 코드

export const createGoal = async ({
    goalEndDate,
    goalSteps,
    goalStartDate,
    goalHours,
    userId,
    tx,
  }: {
    goalEndDate: Date;
    goalSteps: number;
    goalStartDate: Date;
    goalHours: number;
  } & GlobalTypes.PrismaTransactionParams &
    GlobalTypes.UserIdParam) => {
    const goal = await getPrismaDB(tx).onboardingGoal.create({
      data: {
        userId,
        snapshots: {
          create: {
            goalEndDate,
            goalSteps,
            goalStartDate,
            goalHours,
          },
        },
      },
    });

    const snapshot = await getPrismaDB(tx).onboardingGoalSnapShot.findFirst({
      where: {
        onBoardingGoalId: goal.id,
      },
    });

    await getPrismaDB(tx).onboardingGoal.update({
      where: {
        id: goal.id,
      },
      data: {
        snapshotId: snapshot?.id,
      },
    });
    return goal;
  };

스냅샷 방식 도입 후 경험

스냅샷을 도입하면서 초기에는 원본 테이블과 스냅샷 테이블의 ID를 연결하는 과정에서 어려움을 겪었습니다.

그러나 Prisma Schema에서 snapshotId를 nullable하게 설정하여 문제를 해결했습니다.

서버 비용이 DB 비용보다 저렴합니다.

서버에서 UUID를 생성하여 주입하면 DB에서 UUID를 생성하는 비용을 줄이고 로직을 더 간단하게 처리할 수 있습니다.

수정된 Repository 예시 코드

import { v4 as uuidv4 } from 'uuid';

.
.
.
<생략>

    const uuid = uuidv4();
    const goal = await getPrismaDB(tx).onboardingGoal.create({
      data: {
        id: uuid,
        userId,
        snapshots: {
          create: {
            goalEndDate,
            goalSteps,
            goalStartDate,
            goalHours,
          },
        },
      },
    });

    await getPrismaDB(tx).onboardingGoal.update({
      where: {
        id: goal.id,
      },
      data: {
        snapshotId: uuid,
      },
    });
    return goal;
  };

스냅샷 방식을 도입한 후 실시간 데이터 분석이나 상태 복원이 필요한 상황에서 큰 도움을 받았습니다.

그러나 모든 상황에 적합한 방식은 아니므로, 프로젝트의 특성과 요구사항을 잘 고려하여 선택하는 것이 중요합니다.

이 글이 NestJS 개발을 하시는 분들께 조금이나마 도움이 되었으면 좋겠습니다.

질문이나 의견이 있으시면 댓글로 남겨주세요. 함께 고민하고 배우는 과정이 되었으면 합니다.

감사합니다!(좋아요는 큰 힘이 됩니다)

참고 자료

https://github.com/samchon/bbs-backend

https://github.com/samchon/bbs-backend/blob/master/docs/ERD.md

bbs-backend/docs/ERD.md at master · samchon/bbs-backend

Simple Bullet-in Board System Backend. Contribute to samchon/bbs-backend development by creating an account on GitHub.

github.com

GitHub - samchon/bbs-backend: Simple Bullet-in Board System Backend

Simple Bullet-in Board System Backend. Contribute to samchon/bbs-backend development by creating an account on GitHub.

github.com