협업을 위한 더러운 코드

Posted Dec 21, 2024

By Chanwoo Kim

56 min read

협업을 위한 더러운 코드

문제 상황

스터디 세션을 리팩토링 과정에서 코드가 길어져서 고민을 했었습니다. 특히나 비즈니스 로직과 레포지토리 코드가 혼재 해 있었고, 그 부분에서 하나의 핸들러가 호출하는 로직에서 서비스.. 레포지토리.. 이렇게 다양한 계층을 따라 로직이 퍼져있었습니다.

예를 들면, 레포지토리에서는 데이터 베이스 (혹은 자료 저장소) 에 관해서 어떤 정보가 저장되어 있어야하는지

그래서 해당 부분을 리팩토링을 시도했으나, 오히려 팀의 성장에 방해가 되었습니다. 그 부분에 있어서는 조금 더 깔끔한 코드와 프로토콜을 만들고자 하는 욕심 이 1순위로 작용했던 것이 아닐까 하고 회고하면서 판단해봅니다.

협업의 본질을 잊어버리고 스터디 기능 자체를 1일만에 개발한 건 분명 좋은 발전이었으나, 그만큼 3일을 팀 입장에서는 허비시키게 만들었습니다.

사실 이벤트 명을 바꾼건 크게 문제가 되지 않았습니다. 그냥 바꾸면 되니까요. 그런데 문제는 이런 점이었습니다.

위 내용은 제 리팩토링(이라는 이름의 리워크)에 영향받은, 저희 팀원의 스크럼 내용입니다. 이게 과연 협업일까요..? 이때 스스로 많이 반성하게 되었습니다. 스스로 협업을 위한 코드랍시고 나만을 위한 깔끔한 코드를 짜려고 했던 것 같았습니다.

해결 시도 과정

결국 잘 모르겠어서 멘토님께 여쭤보았습니다. 부스트캠프에서 주어진 팀 멘토링 시간을 활용하였고, 글로 남겨서 정리하여 멘토님께 질문드려봤습니다. 이때까지만 해도 저는 나만을 위한 깔끔한 코드 에 집착하고 있었고, 이에 아래와 같이 질문하게 되었습니다.

질문
스터디 세션 부분을 리팩토링하면서 고민을 많이했었습니다.. 아예 구조 자체를 바꿔버리는 스펙이 변경되는 규모에서 100줄 이상 길어지는 코드를 여러 파일로 나누어 관리하다보니 아예 함수 (방을 나가는 로직) 만을 위한 서비스 클래스를 작성하게 되었고, 구별하게 되었는데 결론적으로는 예전보다는 보기가 쉽다고 팀 내부적으로 결론이 났었습니다.
그런데 이게 나중에 가서 최적화 측면에서 문제가 될 지 궁금합니다. 실제로 클래스 기반으로 함수를 짜실 때 멘토님께서는 어떤 방식으로 길어지는 로직을 분리하시거나 관리하시는지 궁금합니다.

멘토님의 답변
가독성은 사실 주관적인 것입니다. 그래서 저는 클래스 기반으로 함수를 짜는 것은 개인적으로 추천하지 않습니다. 보통 재사용성이 높은 코드를 분리하는게 가독성이 좋다고 합니다. 그렇다고 두세번 쓰인다고 무조건 분리하는 것은 추천하지 않습니다.
보통 코드의 줄수를 줄이기만을 위해 고치려고 하지는 않습니다. 코드가 길어져도 분명한 역할이 있다면 그대로 두는게 맞다고 생각합니다. 많이 쓰이는 오픈소스 라이브러리들 중에서도 한 파일에 천 줄이 넘는 코드가 많습니다. 물론 구조화가 잘 되어서 나눠지면 좋지만, 그럴 수 없는 경우도 많으며 이때 코드가 길기 때문에 분리해야한다!는 곤란하다고 생각합니다. 오히려 한 파일에 긴 코드가 있는게 더 가독성이 높을 때도 많습니다. 코드의 길이보다도 구조에 중점을 두는게 더 좋을 때도 있습니다. 그러니, 확장 가능성을 고려해서 구조화를 하고, 분리를 해보세요

멘토님께서는 실제로 클린코드와 같은 개념에 대해 의식하고 계신 것 같았습니다. 저도 실제로 클린 코드의 위험성에 대해 인지는 하고 있었지만, 멘토님께서는 많이 우려스러운 답변을 주셔서 저도 속으로는 의아했습니다.

  
import { RoomDto } from "@/room/dto/room.dto";
import { RoomRepository } from "@/room/room.repository";
import { Injectable } from "@nestjs/common";

@Injectable()
export class RoomHostService {
    public constructor(private readonly roomRepository: RoomRepository) {}

    private getNewHost(room: RoomDto) {
        return Object.values(room.connectionMap).sort((a, b) => a.createAt - b.createAt)[0];
    }

    public async delegateHost(roomId: string) {
        const room = await this.roomRepository.getRoom(roomId);
        if (!room) throw new Error("Invalid room Id");

        const newHost = this.getNewHost(room);

        const found = room.connectionMap[newHost.socketId];
        if (!found) throw new Error("invalid new host id");

        room.host = newHost;

        await this.roomRepository.setRoom(room);
        return newHost;
    }
}

위 방식도 Nest.js 에서 각각의 의존성이 어떻게 관리되고 있는지 생각해봐야합니다.

Nest.js 에서 의존성을 관리하는 방법

기본적으로 Nest.js 에서는 의존성을 하나의 인스턴스(싱글턴 객체)로 생성하여 관리하고 있습니다. 그렇게 될 경우, 서비스를 마구잡이로 나눌 경우, 제아무리 싱글턴 객체라도 메모리를 차지하는 것은 어쩔 수 없는 사실입니다.

물론, 멘토님께서도 완벽히 위와같은 코드를 분리하는 것에 반대를 하지 않으셨고, 애매한 상황이라고 말씀해주시긴 하셨습니다. 무엇이든 정답이 없습니다. 하나의 방법이 정답이라고 생각했던 것이 잘못되었다고 생각했습니다. 이번 케이스에서는 프론트엔드 개발자분의 스펙 변경에 대해서 고려하지 않고, 단순히 코드의 가독성만을 위해서 구조를 나눈 것이 주객전도됨을 깨달았습니다.

특히나, 확장성을 고려하여 roomService 의 인터페이스를 맞추지 않았어서 문제가 되었습니다. 실제로 이렇게 편하게 보기위해 코드를 짰을 경우, 외부 모듈에서 참조를 하게 되는 경우 roomService가 아니라 roomHostService를 불러와야하는지 어떤걸 불러와야 적용할 수 있는지 확인할 수 없었습니다. 처음 적용할 때 roomService 에 없는 것을 보고 엥? 싶을 것이다 생각이 들었습니다.

특히나 리턴되는 값을 마구잡이로 바꿔가면서 테스트 코드의 중요성을 깨닫게 되었습니다. 리팩토링을 할 때 테스트 코드를 통해 스펙을 고정하고 리팩토링을 하게 되어야함을 깨달았습니다.

코드가 500줄이 되던 400줄이 되던, 실제 오픈 소스 코드는 1000줄이 되더라도, 특정 클래스가 수행하는 역할을 잘 수행한다면 상관없다라는 부분에서 깨달음을 얻었습니다. 확실히, 방을 생성하는 것만 roomService 가 아닌, roomCreateService 에서 불러오는 게 확실히 이상하다고 생각이 들었습니다.

리팩토링을 올바르게 하기 위한 과제

확장성을 염두에 두고 설계하기

사실 제가 생각하기에 서비스를 나눌 때 과하게 나누었다고 생각은 들었습니다.

현재 제가 리팩토링한 서비스들을 폴더로 depth를 두어, 각각의 기능은 각각의 서비스에서 하는 식으로 함수 하나가 길어지는 경우를 나누어서 관리하기 편하도록 만들었습니다. 그리고, 아래 코드는 실제 room-create.service.ts 코드입니다.

  
import { Injectable } from "@nestjs/common";
import { CreateRoomInternalDto } from "@/room/dto/create-room.dto";
import { EMIT_EVENT } from "@/room/room.events";
import { WebsocketService } from "@/websocket/websocket.service";
import { RoomRepository } from "@/room/room.repository";
import { QuestionListRepository } from "@/question-list/question-list.repository";
import { RoomJoinService } from "@/room/services/room-join.service";
import { createHash } from "node:crypto";
import "dotenv/config";

@Injectable()
export class RoomCreateService {
    private static ROOM_ID_CREATE_KEY = "room_id";

    public constructor(
        private readonly roomRepository: RoomRepository,
        private readonly socketService: WebsocketService,
        private readonly questionListRepository: QuestionListRepository,
        private readonly roomJoinService: RoomJoinService
    ) {}

    public async createRoom(dto: CreateRoomInternalDto) {
        const { socketId, nickname } = dto;
        const id = await this.generateRoomId();
        const socket = this.socketService.getSocket(socketId);
        const currentTime = Date.now();
        const questionListContents = await this.questionListRepository.getContentsByQuestionListId(
            dto.questionListId
        );

        const roomDto = {
            ...dto,
            id,
            inProgress: false,
            connectionMap: {},
            participants: 0,
            questionListContents,
            createdAt: currentTime,
            host: {
                socketId: dto.socketId,
                nickname,
                createAt: currentTime,
            },
        };

        await this.roomRepository.setRoom(roomDto);

        socket.emit(EMIT_EVENT.CREATE, roomDto);
    }

    // TODO: 동시성 고려해봐야하지 않을까?
    private async generateRoomId() {
        const client = this.socketService.getRedisClient();

        const idString = await client.get(RoomCreateService.ROOM_ID_CREATE_KEY);

        let id: number;
        if (idString && !isNaN(parseInt(idString))) {
            id = await client.incr(RoomCreateService.ROOM_ID_CREATE_KEY);
        } else {
            id = parseInt(await client.set(RoomCreateService.ROOM_ID_CREATE_KEY, "1"));
        }

        return createHash("sha256")
            .update(id + process.env.SESSION_HASH)
            .digest("base64url");
    }
}

코드의 줄 수에 연연하지 않고, 객체의 책임을 생각해보기

코드의 줄 수가 많으면 읽기 힘드신 분이 많으신가요, 아니면 코드가 길어도 인터페이스만 깔끔하면 선호하시나요? 저는 저만의 방법을 많이 생각을 많이했고, 특히 DTO 와 엔티티 의 형태가 조잡하게 변환이 되고 있었음을 깨달았습니다. 그래서 형태를 일관적으로 유지하는 것에 대해서 신경쓰는게 중요하다는 것을 파악했습니다.

일단 첫번째로, API 의 입출력 형태를 맞추기 위한 DTO를 설정했습니다.

  
import {
    ArrayMaxSize,
    ArrayMinSize,
    IsArray,
    IsEnum,
    IsNotEmpty,
    IsNumber,
    Max,
    Min,
} from "class-validator";
import { Connection, RoomStatus } from "@/room/domain/room";
import { Question } from "@/question-list/entity/question.entity";

export class CreateRoomDto {
    private static MAX_CATEGORY_SIZE = 3;
    private static MIN_CATEGORY_SIZE = 1;
    private static MAX_PARTICIPANT_SIZE = 5;
    private static MIN_PARTICIPANT_SIZE = 1;
    @IsNotEmpty()
    title: string;

    @IsEnum(RoomStatus, {
        message: "Status must be either PUBLIC or PRIVATE",
    })
    status: RoomStatus;

    @IsNotEmpty()
    nickname: string;

    @IsNotEmpty()
    @IsArray()
    @ArrayMaxSize(CreateRoomDto.MAX_CATEGORY_SIZE)
    @ArrayMinSize(CreateRoomDto.MIN_CATEGORY_SIZE)
    category: string[];

    @IsNumber()
    @Min(CreateRoomDto.MIN_PARTICIPANT_SIZE)
    @Max(CreateRoomDto.MAX_PARTICIPANT_SIZE)
    maxParticipants: number;

    @IsNumber()
    questionListId: number;
}

export interface CreateRoomResponseDto {
    title: string;
    status: RoomStatus;
    nickname: string;
    maxParticipants: number;
    category: string[];
    questionListId: number;
    socketId: string;
    id: string;
    inProgress: boolean;
    connectionMap: Record<string, Connection>;
    participants: number;
    questionListContents: Question[];
    createdAt: number;
    host: Connection;
}

이렇게 반환 값을 정해버리는 순간, 리팩토링을 하면서 API를 변경할 일이 없어졌습니다. 어쨌거나 타입스크립트 컴파일러 단에서 잡아주니까, 보다 안정적으로 리팩토링할 수 있었습니다.

두번째로, 이런 DTO들을 통해 레포지토리에 연관되고 있음을 깨달았습니다.

  
import { Injectable } from "@nestjs/common";
import { InjectRepository } from "@moozeh/nestjs-redis-om";
import { Repository } from "redis-om";
import { RoomEntity } from "@/room/room.entity";
import { RoomDto } from "@/room/dto/room.dto";

@Injectable()
export class RoomRepository {
    public constructor(
        @InjectRepository(RoomEntity)
        private readonly roomRepository: Repository<RoomEntity>
    ) {}

    // TODO : .from 메서드 구현 필요?
    public async getAllRoom(): Promise<RoomDto[]> {
        const allRooms = await this.roomRepository.search().return.all();
        return allRooms.map((room: RoomEntity) => {
            const connectionMap = JSON.parse(room.connectionMap || "{}");
            return {
                connectionMap: JSON.parse(room.connectionMap || "{}"),
                createdAt: room.createdAt,
                host: JSON.parse(room.host),
                maxParticipants: room.maxParticipants,
                maxQuestionListLength: room.maxQuestionListLength,
                questionListId: room.questionListId,
                questionListTitle: room.questionListTitle,
                currentIndex: room.currentIndex,
                status: room.status,
                title: room.title,
                id: room.id,
                category: room.category,
                inProgress: room.inProgress,
                participants: Object.keys(connectionMap).length,
            };
        });
    }

    public async getRoom(id: string): Promise<RoomDto> {
        const room = await this.roomRepository.search().where("id").eq(id).return.first();

        if (!room) return null;

        const connectionMap = JSON.parse(room.connectionMap || "{}");

        return {
            category: room.category,
            inProgress: room.inProgress,
            connectionMap,
            createdAt: room.createdAt,
            currentIndex: room.currentIndex,
            maxQuestionListLength: room.maxQuestionListLength,
            questionListId: room.questionListId,
            questionListTitle: room.questionListTitle,
            host: JSON.parse(room.host),
            participants: Object.keys(connectionMap).length,
            maxParticipants: room.maxParticipants,
            status: room.status,
            title: room.title,
            id: room.id,
        };
    }

    public async setRoom(dto: RoomDto): Promise<void> {
        const room = new RoomEntity();
        room.id = dto.id;
        room.category = dto.category;
        room.inProgress = dto.inProgress;
        room.title = dto.title;
        room.status = dto.status;
        room.currentIndex = dto.currentIndex;
        room.connectionMap = JSON.stringify(dto.connectionMap);
        room.maxParticipants = dto.maxParticipants;
        room.maxQuestionListLength = dto.maxQuestionListLength;
        room.questionListId = dto.questionListId;
        room.questionListTitle = dto.questionListTitle;
        room.createdAt = Date.now();
        room.host = JSON.stringify(dto.host);

        await this.roomRepository.save(room.id, room);
    }

    public async removeRoom(id: string): Promise<void> {
        const entities = await this.roomRepository.search().where("id").equals(id).return.all();

        for await (const entity of entities) {
            await this.roomRepository.remove(entity.id);
        }
    }
}

보시면 redis-om 으로 인해 객체의 직렬화를 일일이 해주고 있었습니다. 레포지토리는 순전히 엔티티를 반영하고 가져오기만을 해야한다고 생각했습니다. 그것이 명확한 책임의 경계선이라고 생각했고, 각자의 도메인마다 필요한 객체의 직렬화가 필요한 프로퍼티를 어떻게 할지 기술적으로 어려움에 직면했습니다.

문제 해결 과정 1. Facade 패턴으로 redis-om 엔티티에 도메인 로직 결합하기

확장성 있는 설계를 하라는 멘토님의 말씀을 듣고 고민을 하게 되었습니다. 그래서 현재 제가 리팩토링했던 세션 백엔드 코드 부분(room)에서 어떤 문제가 있는지 고민해본 결과, 현재 redis entity 로 매번 변환 과정을 거치고, 서비스나 레포지토리에서 형변환을 하여 엔티티에 넣는게 과연 맞는지 의문이 들었습니다.

이후 최근에 다른 부캠에서 수료한 친구와 논의도 해보며 Claude 로도 검색을 해서 찾아보았고, 그 과정에서 DDD 라는 용어가 있음을 알게 됐고, 당연히 앞서 언급된 클린코드처럼 해당 개발방법론에 대해서도 주의할 필요가 있었습니다.

DDD 의 정의..?

DDD를 적용했다는 의미가 아닙니다.
사실 넓은 의미에서 DDD가 어떤건지도 잘 모를 뿐더러, 지금 적용하기에는 시간이 많이 부족하다고 생각이 들었습니다. 정의 자체에 대한 내용은 많이 나와있습니다. 간략하게 얘기하면, DDD는 복잡한 소프트웨어를 개발할 때 비즈니스 도메인을 중심으로 설계하고 개발하는 방법론입니다.

저는 DDD가 제공하는 모든 개념을 사용하진 않았고, 단지 비즈니스 도메인의 역할에 집중하자 라는 문장 한마디로 시작했습니다.

여태까지 서비스, 컨트롤러 등 데이터보다는 사실 로직에 중심을 두었습니다. 모델의 경우도 단순 interface 로 두고 이 객체의 실제 세상에서의 역할 보다, 그저 컴퓨터 세상에서의 자료형 에 집중했던 것 같습니다.

DDD 라는 개념을 도입하면서 또 클린 코드에 집착하는 것 아니냐 할 수 있겠습니다. 하지만 DDD에서 나온 도메인 로직에 대한 관심분리는 현재 제 프로젝트에 있어서 필요하다고 판단을 했습니다. 또한, 실제로 프론트엔드에서 변경요청이 잦기도 하고, 앞서 겪었던 스펙 변경에 따른 변경과 소통의 혼선이 잦았습니다.

특히나, DTO 를 변환하는 로직이 중복되고 있음을 확인했고, 객체의 형변환이나 검증 로직이 자주 사용되거나, 역할의 책임이 결합되어있으므로 분리되어야함을 깨달았습니다.

이때 다만 실제로 DDD를 적용하지 않고, 마냥 받아들이는 것이 좋지 않다는 경험을 이전에 클린코드와 관련해 멘토님과 논의해봤던 것을 다시 회상하였고, DDD 에서 쓰이는 개념을 가져오기로 했습니다.

첫번째 해결 시도 : `redis-om` 엔티티를 상속받기

첫번째 시도는 바로 현재 사용중인 redis-om 에 접근 제한자와 setter,getter 를 넣자는 생각이었습니다. 저는 여태까지 모델에 로직을 넣으면 안돼! 라는 틀에 박힌 생각을 해왔었습니다만, 이번엔 그냥 제가 편하고 관리가 편하면 되지라는 마인드로 도전해보았습니다.

하지만 이때 첫번째 문제가 생겼습니다. 바로 nestjs-edis-om 라는 외부라이브러리에서 Schema 에서는 함수 프로퍼티를 무시해서 보내주지 않았습니다.

redisom 어댑터를 쓰기엔 기능 확장이 부족했다..

해당 라이브러리인 nestjs-redis-om 라이브러리를 직접 고치기 위해 제가 포크도 하였지만, 시간과 비용이 많이 발생할 것이라고 예측했습니다.

Redis 에서 데이터를 저장하는 방식

Redis 에서 데이터를 저장할 때, 객체를 저장할 수 있습니다. 하지만, 각 객체의 프로퍼티는 직렬화가 필수인데요.

실제로 저는 복잡한 객체를 바로바로 제공할 수 있도록 하려고 했고, 연결 정보 자체에 대한 메타데이터들을 room 객체 하위에 connectionMap 이라는 JSON 객체로 저장하고 있습니다.

사실 지금 보면 이를 별도의 도메인으로 만들어 따로 저장해야한다고 생각합니다. 하지만 결국, 이를 따로 키로써 저장하게 되면 키를 조회를 많이 하게 됩니다. 싱글스레드인 레디스에서는 최대한 키를 검색하는 과정을 줄여야한다고 생각했습니다.

그렇기에 결국 키를 하나로 저장하려면 직렬화는 필수였습니다. 그래서 이를 위해서는 해당 room 객체의 직렬화 와 역직렬화만을 위한 별도의 로직 함수들이 자주 사용될 것이라고 생각했습니다.

그래서 이렇게 자주 사용되는 도메인 로직을 직접 분리해보기로 했고, 이게 진정한 확장성 있는 설계라고 생각이 들었습니다.

두번째 해결 시도 : 엔티티와 도메인을 넘나드는 도메인 서비스

그러면 일단 가장 간단하게 자주 사용되는 로직을 분리하는 방법은 뭘까요? 그것은 바로 도메인 로직만을 담은 roomDomainService 를 만드는 방법입니다.

이 방법도 괜찮은 방법이라고 생각했습니다. 아래와 같은 repository 코드를 보면, 실제로 직렬화와 역직렬화를 같이 맡고 있어서 자주 사용되고 있습니다.

  
import { Injectable } from "@nestjs/common";
import { InjectRepository } from "@moozeh/nestjs-redis-om";
import { Repository } from "redis-om";
import { RoomEntity } from "@/room/room.entity";
import { RoomDto } from "@/room/dto/room.dto";

@Injectable()
export class RoomRepository {
    public constructor(
        @InjectRepository(RoomEntity)
        private readonly roomRepository: Repository<RoomEntity>
    ) {}

    // TODO : .from 메서드 구현 필요?
    public async getAllRoom(): Promise<RoomDto[]> {
        const allRooms = await this.roomRepository.search().return.all();
        return allRooms.map((room: RoomEntity) => {
            const connectionMap = JSON.parse(room.connectionMap || "{}");
            return {
                connectionMap: JSON.parse(room.connectionMap || "{}"),
                createdAt: room.createdAt,
                host: JSON.parse(room.host),
                maxParticipants: room.maxParticipants,
                maxQuestionListLength: room.maxQuestionListLength,
                questionListId: room.questionListId,
                questionListTitle: room.questionListTitle,
                currentIndex: room.currentIndex,
                status: room.status,
                title: room.title,
                id: room.id,
                category: room.category,
                inProgress: room.inProgress,
                participants: Object.keys(connectionMap).length,
            };
        });
    }

    public async getRoom(id: string): Promise<RoomDto> {
        const room = await this.roomRepository.search().where("id").eq(id).return.first();

        if (!room) return null;

        const connectionMap = JSON.parse(room.connectionMap || "{}");

        return {
            category: room.category,
            inProgress: room.inProgress,
            connectionMap,
            createdAt: room.createdAt,
            currentIndex: room.currentIndex,
            maxQuestionListLength: room.maxQuestionListLength,
            questionListId: room.questionListId,
            questionListTitle: room.questionListTitle,
            host: JSON.parse(room.host),
            participants: Object.keys(connectionMap).length,
            maxParticipants: room.maxParticipants,
            status: room.status,
            title: room.title,
            id: room.id,
        };
    }

    public async setRoom(dto: RoomDto): Promise<void> {
        const room = new RoomEntity();
        room.id = dto.id;
        room.category = dto.category;
        room.inProgress = dto.inProgress;
        room.title = dto.title;
        room.status = dto.status;
        room.currentIndex = dto.currentIndex;
        room.connectionMap = JSON.stringify(dto.connectionMap);
        room.maxParticipants = dto.maxParticipants;
        room.maxQuestionListLength = dto.maxQuestionListLength;
        room.questionListId = dto.questionListId;
        room.questionListTitle = dto.questionListTitle;
        room.createdAt = Date.now();
        room.host = JSON.stringify(dto.host);

        await this.roomRepository.save(room.id, room);
    }

    public async removeRoom(id: string): Promise<void> {
        const entities = await this.roomRepository.search().where("id").equals(id).return.all();

        for await (const entity of entities) {
            await this.roomRepository.remove(entity.id);
        }
    }
}

하지만 이런 상황을 생각해봅시다.

가장 간단한 방법이라곤 해도, 매번 엔티티의 상태 를 업데이트해서 넘겨주는게 불편하다고 생각했습니다. 또한, 포함관계 가 명확하지 않아서, 어쩔 때는 entity 만을 가지고 모든 걸 수행해야한다는 것에서 통일성이 없을 것 같다고 생각이 들었습니다.

두번째 해결 시도의 문제점

가장 무엇보다 명확한 문제는 역직렬화를 한번만 해서 정보를 가지고 있고, 필요할 때 직렬화를 하게 해주는 작업을 위한 메소드를 사용할 때 매번 엔티티를 필요로 하기 때문에 역직렬화 상태를 저장할 수 없다는 점입니다.

이를 생각하게 되면, 역직렬화 상태와 직렬화 상태의 객체를 동시에 가지고 다루어야한다는 문제가 생깁니다. 이렇게 되면 헷갈리게 되어 생산성에 방해가 되었습니다.

예를 들면, RoomEntity 객체와 RoomDomain 객체를 매번 순환하여 저장하는 식으로 변수에 저장하게 되는 상황인 것이죠. 이렇게 되면 실제로 기능 확장 시 RoomDomain 을 쓸 지, RoomEntity 를 쓸 지 헷갈리게 됩니다.

의존성에 관한 문제도 있을 것입니다. Room 도메인이 사용되는 상황에서는 매번 RoomService 가 따라오겠지요. 하지만 이는 Nest 생태계에서의 의존성 관리 덕분에 큰 문제는 아니라고 판단했습니다.

가장 간단한 방법이 무엇일까?

이전에는 가장 깔끔한 방법을 찾았지만, 이제는 가장 손이 안가는 방법 을 찾는 데에 집중하게 되었습니다. 결국 제가 생각해본 도메인 로직 코드는 아래와 같았습니다.

그리고, 가장 하고 싶었던 건 도메인(단순 할당 등)의 작업 단위 를 한 데 묶고 싶었고, 경우에 따라 로직으로 처리해야할 것은 로직으로 처리하고 싶었습니다.

실제로 위 코드의 Repository 코드에서 수행하던 변환 로직을 이쪽에서 수행하여, 매번 역직렬화 과정을 거치지 않도록 만들었습니다.

  
import { RoomEntity } from "@/room/room.entity";

export interface Connection {
    socketId: string;
    nickname: string;
    createAt: number;
}

export enum RoomStatus {
    PUBLIC = "PUBLIC",
    PRIVATE = "PRIVATE",
}

export interface IRoom {
    id: string;
    title: string;
    category: string[];
    inProgress: boolean;
    currentIndex: number;
    host: Connection;
    status: RoomStatus;
    maxParticipants: number;
    maxQuestionListLength: number;
    questionListId: number;
    questionListTitle: string;
    createdAt: number;
    connectionMap: Record<string, Connection>;
}

export class Room {
    public entity: RoomEntity;

    constructor(entity?: IRoom) {
        if (!entity) {
            this.entity = null;
            return this;
        }
        this.entity = new RoomEntity();
        this.entity.id = entity.id;
        this.entity.status = entity.status;
        this.setConnection(entity.connectionMap);
        this.entity.title = entity.title;
        this.entity.createdAt = entity.createdAt;
        this.entity.questionListId = entity.questionListId;
        this.entity.questionListTitle = entity.questionListTitle;
        this.entity.inProgress = entity.inProgress;
        this.entity.maxParticipants = entity.maxParticipants;
        this.entity.currentIndex = entity.currentIndex;
        this.entity.category = entity.category;
        this.entity.maxQuestionListLength = entity.maxQuestionListLength;
        this.entity.host = JSON.stringify(entity.host);
    }

    static fromEntity(entity: RoomEntity) {
        const room = new Room();
        room.entity = entity;
        return room;
    }

    build() {
        return this.entity;
    }

    toObject(): IRoom {
        return {
            id: this.entity.id,
            status: this.entity.status,
            connectionMap: this.getConnection(),
            title: this.entity.title,
            createdAt: this.entity.createdAt,
            questionListId: this.entity.questionListId,
            questionListTitle: this.entity.questionListTitle,
            inProgress: this.entity.inProgress,
            maxParticipants: this.entity.maxParticipants,
            currentIndex: this.entity.currentIndex,
            category: this.entity.category,
            maxQuestionListLength: this.entity.maxQuestionListLength,
            host: this.getHost(),
        };
    }

    setHost(connection: Connection) {
        this.entity.host = JSON.stringify(connection);
        return this;
    }

    getHost(): Connection {
        return JSON.parse(this.entity.host);
    }

    setConnection(connectionMap: Record<string, Connection>) {
        this.entity.connectionMap = JSON.stringify(connectionMap);
        return this;
    }

    getConnection(): Record<string, Connection> {
        return JSON.parse(this.entity.connectionMap);
    }

    getParticipants(): number {
        return Object.keys(this.getConnection()).length;
    }

    addConnection(connection: Connection) {
        const connectionMap = this.getConnection();
        connectionMap[connection.socketId] = connection;
        return this.setConnection(connectionMap);
    }

    removeConnection(socketId: string) {
        const connectionMap = this.getConnection();
        delete connectionMap[socketId];
        return this.setConnection(connectionMap);
    }
}

촉박한 시간관계상 직렬화 역직렬화 등의 필수적인 도메인 로직만을 구현했고, 엔티티를 캡슐화를 일부러 풀어서 다른 프로퍼티의 경우 getter setter 구현 없이 직접 접근하도록 만들었습니다. 이렇게 리팩토링했을 경우 부캠이 끝나고 천천히 리팩토링할 때 도메인 클래스로 마이그레이션 하기 쉽다고 판단했습니다.

그리고 알고보니, 해당 구현 방식은 실제로 존재하는 디자인 패턴이었고, Facade 디자인 패턴을 제가 완전히 활용하고 있었습니다!

Facade 패턴이란?

Facade 디자인 패턴이란 복잡한 서브 시스템에 대한 간단한 인터페이스를 제공하는 구조적 디자인 패턴입니다.

  
# 복잡한 서브시스템 클래스들
class CPU:
    def freeze(self): 
        print("CPU 동결")
    
    def execute(self): 
        print("CPU 실행")

class Memory:
    def load(self): 
        print("메모리 로드")

class HardDrive:
    def read(self): 
        print("하드드라이브 읽기")

# Facade 클래스
class ComputerFacade:
    def __init__(self):
        self.cpu = CPU()
        self.memory = Memory()
        self.hard_drive = HardDrive()
    
    def start(self):
        # 복잡한 시작 과정을 단순화
        self.cpu.freeze()
        self.memory.load()
        self.hard_drive.read()
        self.cpu.execute()

# 클라이언트 코드
computer = ComputerFacade()
computer.start()  # 단순히 start() 메서드만 호출하면 됨

프랑스어로 건물의 외벽 이라고 부르는 Facade 는 복잡한 시스템(엔티티의 직렬화) 를 간단한 인터페이스로 만들어서 사용하기 쉽게 만들 수 있습니다.

그 결과 서비스 코드

그 이후 서비스 코드들이 도메인 설정에 관한 로직이 간단해졌습니다.

첫번째 예시 : 캡슐화를 통한 서비스에서의 도메인 관심 분리

  
// 바뀐 서비스 코드 

public async setProgress(roomId: string, socketId: string, status: boolean) {
    const room = Room.fromEntity(await this.roomRepository.getRoom(roomId));

    if (!room.entity) throw new Error("cannot set progress");
    if (room.getHost().socketId !== socketId) throw new Error("only host can set process");

    room.entity.inProgress = status;
    if (!room.entity.inProgress) room.entity.currentIndex = 0;
    await this.roomRepository.setRoom(room.build());
    return status;
}

명시적으로 직렬화 하는 과정을 캡슐화함으로써, 로직 수행에만 집중할 수 있도록 만들었던 것 같습니다. 이전보다 할당문이 많이 줄었습니다. 이부분은 getter setter 를 두어서, 보다 일관되게 처리할 수 있습니다.

  
// 이전 코드

public async setProgress(roomId: string, socketId: string, status: boolean) {
    const room = await this.roomRepository.getRoom(roomId);

    if (!room) throw new Error("cannot set progress");
    if (room.host.socketId !== socketId) throw new Error("only host can set process");

    room.inProgress = status;
    if (!room.inProgress) room.currentIndex = 0;
    await this.roomRepository.setRoom(room);
    return status;
}

두번째 예시 : 확장 가능한 DTO 변환 로직의 생성 가능

두번째 예시입니다. 이는 room-create.service.ts 로 나누었던 함수입니다. 실제로 dto를 받고 객체로써 새로운 방을 레포지토리에 바로 엔티티로써 보내줄 수 없었던 단점을 해결할 수 있었습니다.

현재 보시면, 아래 코드의 큰 차이는 엔티티로 넘겨주는 지에 대한 여부의 차이입니다. 그냥 객체로 쓰면 안될까? 라고 할 수 있겠지만, 실제로 제가 원하는 시점에 언제 엔티티로 만들 수 있는지도 중요합니다.

최적화 여부도 있겠습니다. repository 에 업데이트를 자주해야하는 상황이 온다면, 이미 도메인 객체가 갖고 있는 엔티티를 리턴하면 됩니다. 이전 코드대로라면 repository 에 참조할 때마다 변환 과정이 무조건 일어나는 상황이 생깁니다.

또한 각각의 DTO는 동일한 역직렬화된 도메인으로부터 필요한 데이터를 꺼내올 수 있도록 만들 수 있었습니다. 적어도 직렬화와 역직렬화 라는 관심에서는 벗어난거죠. DTO 변환만을 위한 작업을 수행할 수 있게된 것입니다.

  
@Transactional()
    public async createRoom(dto: CreateRoomInternalDto) {
        const { socketId, nickname } = dto;
        const id = await this.generateRoomId();
        const socket = this.socketService.getSocket(socketId);
        const currentTime = Date.now();
        const questionList = await this.questionListRepository.findOne({
            where: { id: dto.questionListId },
        });
        const questionListContent = await this.questionRepository.getContentsByQuestionListId(
            dto.questionListId
        );
        questionList.usage += 1;
        await this.questionListRepository.save(questionList);

        const roomDto = {
            ...dto,
            id,
            inProgress: false,
            connectionMap: {},
            participants: 0,
            questionListContents: questionListContent,
            createdAt: currentTime,
            maxQuestionListLength: questionListContent.length,
            questionListTitle: questionList.title,
            currentIndex: 0,
            host: {
                socketId: dto.socketId,
                nickname,
                createAt: currentTime,
            },
        };

        await this.roomRepository.setRoom(roomDto);

        socket.emit(EMIT_EVENT.CREATE, roomDto);
    }

  
@Transactional()
public async createRoom(
    createRoomDto: CreateRoomDto,
    socket: Socket
): Promise<CreateRoomResponseDto> {
    const currentTime = Date.now();
    const questionData = await this.useQuestionList(createRoomDto.questionListId);
    const roomObj = {
        ...createRoomDto,
        id: await this.generateRoomId(),
        inProgress: false,
        connectionMap: {},
        participants: 0,
        createdAt: currentTime,
        maxQuestionListLength: questionData.content.length,
        questionListTitle: questionData.title,
        currentIndex: 0,
        host: {
            socketId: socket.id,
            nickname: createRoomDto.nickname,
            createAt: currentTime,
        },
    };

    const room = new Room(roomObj).build(); // 바뀐 코드에서는 굳이 엔티티를 변환하는 작업을 구현할 필요 없음

    await this.roomRepository.setRoom(room);

    socket.emit(EMIT_EVENT.CREATE, room);

    return CreateRoomInternalDto.from(room); // 리턴값을 엄밀히 설정
}

세번째 예시 : 역직렬화 상태를 유동적으로 저장 가능

마지막으로, 받아온 엔티티를 언제든 역직렬화해서 하는 문법에 대한 책임이 분리될 수 있었습니다.

  
public async getPublicRoom(inProgress?: boolean): Promise<RoomListResponseDto[]> {
    const rooms = await this.roomRepository.getAllRoom();

    const filterFunction = (room: RoomEntity) =>
        room.status === RoomStatus.PUBLIC &&
        (inProgress === undefined || room.inProgress === inProgress);

    return rooms
        .filter(filterFunction)
        .sort((a, b) => b.createdAt - a.createdAt)
        .map((room) => Room.fromEntity(room))
        .map((room) => ({
            ...room.toObject(),
            host: room.getHost(),
            participants: room.getParticipants(),
            connectionMap: undefined,
        }));
}

심지어 이전 코드에서는 엔티티에 존재하지 않는 정보를 레포지토리에서 가공하여 객체로 제공하고 있었습니다. 이런 부분에서 책임 분리가 확실하게 될 수 있었던 것 같습니다.

  
public async getPublicRoom(inProgress?: boolean): Promise<RoomListResponseDto> {
    const rooms = await this.roomRepository.getAllRoom();
    return rooms
        .filter(
            (room) =>
                room.status === RoomStatus.PUBLIC &&
                (inProgress === undefined || room.inProgress === inProgress)
        )
        .sort((a, b) => b.createdAt - a.createdAt)
        .map((room) => ({
            createdAt: room.createdAt,
            host: room.host,
            maxParticipants: room.maxParticipants,
            status: room.status,
            title: room.title,
            id: room.id,
            category: room.category,
            inProgress: room.inProgress,
            questionListTitle: room.questionListTitle,
            participants: room.participants, // 엔티티에는 없는 정보를 레포지토리가 가공하고 있었다!
        }));
}

아직 남은 점

Entity 프로퍼티를 public으로 열어두었다.

이렇게 보면, 도메인 객체의 상태가 언제든지 바뀔 수 있다는 위험이 있었습니다.

해당 부분의 경우 일일이 setter, getter 를 도입하고, entity 객체 자체를 캡슐화하여 해결할 수 있었을 것이라고 생각합니다.

다만, 현재 리팩토링 대상인 도메인 객체의 프로퍼티 값이 13개 나 되어.. 차라리 구조적으로 개편하고 setter getter 를 적게 설정하는 방향도 좋을 것 같다고 생각이 들었습니다.

외부 라이브러리를 수정해서 개선해보기

@moozeh/nestjs-redis-om 라이브러리를 제가 직접 포크해온 만큼, 제가 편하게 쓸 수 있도록 개선할 수 있었을 것입니다. 시간과 비용을 생각해서 제가 편하게 쓸 수 없어서 아쉬울 따름입니다..

참고자료

https://appleg1226.tistory.com/40

문제 해결 과정 2. 클린코드에 대해서 : 어떤게 문제인지 확실히 파악하기

클린코드에 대해서 경계 할 것이 아니라, 어떤게 문제인지 확실히 아는 프로그래머가 되는 게 중요하다고 생각하게된 영상을 보았습니다.

포프님의 영상에 달린 댓글에 이런 내용이 눈에 들어왔고, 스스로 어떻게 해야 협업할 수 있는 개발자인지 생각해보려고 합니다.

어떤 업무건 업의 본질이라는 게 있습니다.
프로그래밍 또한 업의 본질을 이해해야 한다고 생각합니다.
효율적인 업무 진행을 위한 서로간의 조율이 필요합니다. TDD를 써야하면 그렇게 해야하고, 다른 방법론이 있다면 그것을 적용하고..

따라서 앞서 제가 진행했던 스터디 세션 부분 리팩토링과 같은 부분은 팀을 위한 조율이 아니라고 생각했습니다. 그 후부터는 최대한 팀의 가치 에 집중했고, 이것이 진정한 본질이 아닐까 한번 생각을 해보게 됐습니다.

아직 많이 부족하지만, 아래 글에서 처럼, 협업의 가치를 조금씩 깨달아가고 있음을 스스로 느끼고 있습니다.

JWT 토큰 파싱 변경 과정과 협업의 가치에 대한 고민