[Floney] 카테고리 리팩토링 일대기

🍀 기존 상황

도메인

우리 가계부에서 하나의 가계부 내역은 지출/수입/이체로 구분되고, 자산과 분류 항목으로 세부적으로 다시 구분된다.

이 세 가지를 편의상 카테고리로 통칭한다.

가계부 내역 추가 화면

• 지출/수입/이체 (이후 상위 카테고리라 칭함): 가계부 내역의 종류
• 분류 (이후 하위 카테고리라 칭함): 위 지출/수입/이체의 하위 분류 (ex. 식비, 월급 등)
• 자산 (이후 하위 자산 카테고리라 칭함): 가계부 내역의 자산 출처 (ex. 현금, 카드 등)

이를 계층적으로 정리하면 다음과 같다.

 

 

이 카테고리들은 가계부 별로 관리된다.

분류 항목 (하위 카테고리) 관리 화면

 

이 때 하위 카테고리는 가계부 생성 시 기본적으로 N개가 주어진다. 이를 기본 카테고리라고 부르겠다. 기본 카테고리는 사용자가 임의로 삭제 및 수정을 할 수 없다. 위 화면에 보이는 자산의 현금~은행 하위 카테고리가 그러하다.

다만 사용자가 직접 카테고리를 추가할 수 있다. 이를 커스텀 카테고리라고 부르겠다. 화면의 추가항목1 하위 카테고리가 그러하다.

 

 

구현

나와 서버를 담당하는 팀원 분은 이 도메인을 구현하기 위해 여러 고민을 했고(그 때의 고민 과정은 이 포스팅에서 확인할 수 있다), 최종적으로 다음과 같이 구현했다.

 

✅ 카테고리

@Inheritance(strategy = SINGLE_TABLE)
public abstract class Category {

    @Column
    private String name;
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "parent_id")
    private Category parent;
}

// 상위 카테고리
@DiscriminatorValue("DefaultRoot")
public class RootCategory extends Category {
}

// 기본 하위 카테고리
@DiscriminatorValue("Default")
public class DefaultCategory extends Category {
}

// 커스텀 하위 카테고리
@DiscriminatorValue("Book")
public class BookCategory extends Category {

    @ManyToOne
    private Book book;
}

기본적으로 카테고리라는 도메인에 속해 있기 때문에 Category 추상 클래스를 생성했다. 그리고 상위 카테고리, 하위 기본 카테고리, 하위 커스텀 카테고리를 상속(@Inheritance)을 이용해 각각의 객체로 나눴다.

 

id	dtype	name	parent_id	book_id
1	DefaultRoot	지출	null	null
2	Default	식비	1	null
3	Book	내가 만든 카테고리	1	1

상속 전략은 SINGLE_TABLE 을 사용했다. 따라서 세 개의 Category 객체가 DB에서 하나의 테이블에 저장된다. 대신 각 객체는 dType으로 구분된다.

 

✅ 가계부 내역 - 카테고리 연결

하나의 가계부 내역은 세 개의 카테고리를 참조한다. 하나의 카테고리는 여러 가계부 내역들을 참조한다.

서로가 다대다 관계를 맺고 있으므로 DB에서 두 테이블을 참조하는 연결 테이블을 생성했다. 이 때 내역이 참조하는 세 개의 카테고리는 각자 자신의 속성이 있으므로, 이를 category_type 컬럼으로 구분한다.

id	book_id (연결 가계부)	category_id (연결 카테고리)	category_type (카테고리 종류)
1	1	1	FLOW (상위 카테고리 - 지/수/이)
2	1	2	ASSET (자산 하위 카테고리)
3	1	3	FLOW_LINE (하위 카테고리)

 

어플리케이션에서는 가계부 내역이 EnumMap으로 세 개의 카테고리 연결 객체를 참조한다. 내역을 조회할 때 거의 연관 카테고리까지 조회하고, 논리적으로도 내역에 카테고리 정보가 포함된다고 판단했다.

// 가계부 내역
@Entity
public class BookLine {

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "bookLine")
    @MapKeyEnumerated(EnumType.STRING)
    private final Map<CategoryEnum, BookLineCategory> bookLineCategories = new EnumMap<>(CategoryEnum.class);
}

// 한 가계부 내역과 연관된 카테고리 종류
public enum CategoryEnum {

    FLOW, 
    ASSET, 
    FLOW_LINE; 
}

 

 

 

 

 

💩 변화가 필요하다

이후 여러 기능을 구현하면서 기존 설계 및 코드에 대해 많은 불편함을 느꼈다.

QueryDSL의 projection

가계부 내역을 조회할 때 연관된 카테고리들을 JOIN 하면 일대다로 참조한 bookLineCategories 에 알맞게 연결된다.

// QueryDSL 사용
public BookLine getBookLine() {
    return jpaQueryFactory.from(bookLine)
        .innerJoin(bookLine.bookLineCategories, bookLineCategory)
        .fetchOne();
}

 

문제는 QueryProjection, 즉 조회용 객체를 사용할 때다.

// QueryProjection 사용
public CustomBookLine getBookLine() {
    return jpaQueryFactory
    	.select(new QCustomBookLine(bookLineCategory.name)) // X
    	.from(bookLine)
        .innerJoin(bookLine.bookLineCategories, bookLineCategory)
        .fetchOne();
}

 

하나의 가계부 내역에 세 개의 카테고리가 연결될 때 이 정보를 bookLineCategories 로 모으지 않으므로 각각 따로 조회된다.

 

당시에는 마땅한 해결책을 못 찾아 3개의 행을 따로 불러오되, 어플리케이션에서 직접 합쳐줬다.

// 안 읽어도 됨
// 가계부 내역에 여러 개의 카테고리를 하나의 객체로 합치는 함수
public List<DayLines> transfer(List<CustomBookLine> dayLines) {
    Map<Long, DayLineInfo> dayLineWithCategories = new HashMap<>();

    dayLines.forEach((dayLine) ->
    {
        DayLineInfo dayLineInfo = dayLineWithCategories.get(dayLine.getId());

        // 카테고리 외의 데이터 최초 등록
        if (dayLineInfo == null) {
            dayLineWithCategories.put(dayLine.getId(), DayLineInfo.toDayViewInfos(dayLine));
        } else {
            dayLineInfo.addCategory(dayLine.getCategories());
        }
    });

    return;
}

대충 봐도 복잡하다. 

 

 

SINGLE_TABLE 상속 전략과 유니크 인덱스

DB의 Category 테이블은 다음과 같이 dtype 으로 카테고리를 구별한다.

id	dtype	name	parent_id	book_id
1	DefaultRoot	지출	null	null
2	Default	식비	1	null
3	Book	내가 만든 카테고리	1	1

 

이 때 dtype 에 따라 constraints 도 달라진다.

DefaultRoot 는 상위 카테고리며 모든 가계부가 공유한다. 따라서 parent_id 와 book_id 가 모두 null 이다.

Default 는 기본 하위 카테고리라 모든 가계부가 공유한다. 따라서 book_id 가 null 이다.

Book 은 커스텀 하위 카테고리라 가계부 마다 생성 가능하다. 따라서 모든 컬럼에 null 이 허용되지 않는다.

 

논리적으로는 위와 같지만, 모두 하나의 테이블을 사용하므로 parent_id 와 book_id 는 null 을 무조건 허용해야 한다.

 

이 때 도메인 상 커스텀 카테고리는 (이름, 가계부, 상위 카테고리) 조합이 유일하다. 기본 카테고리와도 이름이 겹치면 안 된다.

분류 항목 (하위 카테고리) 관리 화면

즉 여기서 자산의 분류 항목을 추가할 때 현금부터 추가항목1 까지 이름이 겹치면 안 된다. 

 

이를 어플리케이션에서 조건에 맞는 하위 카테고리를 먼저 조회하고, 있으면 예외를 던지고 없으면 추가하는 방식으로 구현했다.

...뭔가 익숙한 방식이다.

맞다. 자산 이슈에서 똑같이 '조회 후 데이터 삽입'을 하다가 동시성 문제가 발생했었다.

 

이 때 해당 이슈에서는 MySQL의 upsert 문법(INSERT ... ON DUPLICATE KEY UPDATE)을 사용한 Atomic Query로 문제를 해결했다. 그래서 똑같이 적용하려고 했으나, 안타깝게도 MySQL에서는 특정 컬럼에 null 값이 포함되면 unique index가 의도대로 작동하지 않는다. MySQL에서 null은 '알 수 없는 값'으로 취급되기 때문이다.

The concept of the NULL value is a common source of confusion for newcomers to SQL, who often think that NULL is the same thing as an empty string ''. This is not the case. 
Conceptually, NULL means “a missing unknown value” and it is treated somewhat differently from other values.
NULL 값의 개념은 SQL을 처음 접하는 사람들이 흔히 혼동하는 부분으로, NULL이 빈 문자열 ''과 같은 의미라고 생각하는 경우가 많으나 그렇지 않다. 개념적으로 NULL은 "알 수 없는 누락된 값"을 의미하며 다른 값과 다소 다르게 취급된다.

- MySQL 8.0 references 중

따라서 nullable 컬럼에 unique 제약 조건을 추가하는 경우 null 값인 행은 여러 개가 될 수 있다. 기존의 null 값과 새로 추가된 null 값이 같다고 판단할 수 없기 때문이다.

 

Atomic Query로 동시성 문제를 해결할 수 없으면 상황이 복잡해진다. MySQL의 Named Lock 혹은 Redis 락 등을 사용해야 한다. 고작 카테고리 중복 방지에 이만한 시간을 들여야하나 싶어진다.

 

 

두 종류의 하위 카테고리 - 기본과 커스텀

하위 카테고리는 특성에 따라 다시 기본과 커스텀 카테고리로 나뉜다. 이를 어플리케이션에서도 각각의 객체(DefaultCategory, BookCategory)로 구분했다.

 

하지만 대부분의 조회 쿼리에서 그 둘을 구분하지 않고 조회한다. 하위 카테고리를 생성한 이상, 해당 카테고리를 조회할 때는 둘을 구별하는 게 무의미하기 때문이다. 하지만 객체로는 엄연히 구분되어 있고 조건도 다르게 주어야 하므로 쿼리를 두 번 날려야 한다. 불편하다.

public Optional<Category> findFlowLineCategory() {
    // 기본 카테고리 먼저 조회
    Optional<Category> target = Optional.ofNullable(jpaQueryFactory.selectFrom(category)
        .where(
            category.name.eq(name),
            category.parent.eq(parentFlowCategory),
            category.instanceOf(DefaultCategory.class)
        )
        .fetchOne());

    // 기본 카테고리에서 원하는 카테고리를 찾지 못한 경우, 커스텀 카테고리 조회
    if (target.isEmpty()) {
        target = Optional.ofNullable(jpaQueryFactory
            .selectFrom(bookCategory)
            .innerJoin(bookCategory.book, book)
            .where(
                book.bookKey.eq(bookKey),
                bookCategory.name.eq(name),
                bookCategory.parent.eq(parentFlowCategory),
            )
            .fetchOne());
    }
    return target;
}

 

 

도메인 용어

외에도 코드 내에 쓰인 용어들이 헷갈리는 경우가 많았다. 한글로 된 도메인 용어를 영어로 번역하는 과정에서 다른 용어와 겹치는 경우도 있었고, 이름만 봤을 때 무슨 도메인인지 헷갈리는 경우도 있었다.

 

예를 들어 가계부 내역과 관련된 카테고리를 관리하는 CategoryEnum 이 있었다.

// 한 가계부 내역과 연관된 카테고리 종류
public enum CategoryEnum {

    FLOW("내역"), 
    ASSET("자산"), 
    FLOW_LINE("내역 분류"); 
}

여기서는 FLOW 가 내역이다. 하지만 가계부 내역은 Book'Line' 이다.

또 이 객체의 ASSET 은 자산 분류 항목을 의미한다. 하지만 우리는 가계부 수입 및 지출 내역으로 계산하는 자산 도메인이 따로 있고, DB에서 asset 테이블에 저장한다. 

 

이렇게 용어가 헷갈리는 게 개발하면서 생각보다 큰 장애물이 되었다.

 

 

 

💦 재설계

고려사항

그동안 겪은 불편함을 바탕으로 생긴 조건은 다음과 같다.

• 기본 하위 카테고리와 커스텀 하위 카테고리는 조회될 때 하나로 취급되어야 한다.
• 하나의 테이블로 묶인 카테고리들을 나누어 유니크 인덱스를 추가한다.
• 하나의 가계부 내역을 참조하는 세 개의 카테고리 연결 데이터는 하나로 묶는다.
• 변경하는 김에 용어들 또한 가독성 좋게 수정한다.

마침 기본 카테고리도 편집하게 해달라는 요청이 많아져 커스텀 카테고리와 똑같이 편집이 가능하도록 기획이 추가되었다. 따라서 첫 번째 조건을 해결할 수 있게 되었다.

 

또 여러 고민 끝에 어플리케이션에서 카테고리 간의 상속 관계를 없애기로 했다. 우리는 두 번째 조건을 위해 상속 전략 중 TABLE_PER_CLASS 를 사용하고 싶었다. 하지만 이 전략과 식별자(id) 생성 방식 중 IDENTITY 를 같이 사용하면 오류가 발생한다(참고). 논리적으로도 굳이 각 엔티티들이 묶여 있을 필요가 없다고 판단했다.

 

 

최종 설계

고민 끝에 다음과 같은 설계를 완성했다.

 

✅ 카테고리

 

• Category 테이블: 상위 카테고리 (지출/수입/이체/자산)
• Subcategory 테이블: 하위 카테고리
• DefaultSubcategory 테이블: 기본 하위 카테고리
  (가계부를 생성할 때만 해당 테이블의 데이터를 불러와 Subcategory 데이터로 저장한다.)

 

✅ 가계부 내역-카테고리

 

세 개의 카테고리를 세 개의 행으로 저장하지 않고, 세 개의 column 을 통해 하나의 행으로 저장한다.

 

 

 

 

 

🧐 테스트 없는 리팩토링

설계는 완성했다. 이제 구현이 필요하다.

기존 상황

안타깝게도 출시 일정에 치여 개발하느라 테스트가 매우 부족했다. 더 안타까운 점은 그 적은 테스트는 모두 단위 테스트라, 객체 자체가 변하면서 단위 테스트들이 모두 사라져야했다. 그래서 테스트가 없는 리팩토링을 진행해야 했다.

또한 가계부 내역과 카테고리는 매우 비중이 높은 하위 도메인이라 프로덕션 코드의 대부분이 바뀌었다.

 

우리는 리팩토링 중 혹여나 잘못 변경한 코드가 있을 지 매우 불안했다. 이미 테스트 없이 급하게 오류를 수정하다가 밤을 새며 운영 데이터를 수정한 전적이 있기 때문이다.

가계부 200개의 내역들을 불러와 엑셀 함수로 일일히 계산하고 확인한 눈물의 흔적

 

그래서 시간이 걸리더라도 테스트를 최대한 추가하기로 했다.

 

 

DCI 패턴 도입

기존에 테스트 코드를 작성하면서 불편했던 점은, 하나의 기능에 대해 여러 성공 및 실패 테스트가 존재하는 데 이를 확인하기 쉽지 않았다. 일렬로 나열된 테스트 결과창을 보고 어떤 테스트를 빼먹었는지 혹은 어떤 테스트가 중복되었는지 바로 파악할 수 없었다.

 

그래서 구조화 된 테스트 코드를 위해 DCI 패턴(참고)을 제안해 도입했다.

 

패턴에 맞추어 코드를 작성하면서 코드 양이 늘어난다는 단점이 있지만, class 단위로 테스트 대상(Describe) 및 환경(Context)을 분리하니 케이스 구별이 쉬워 만족스럽다.

무엇보다도 실행 창이 매우 아름답다. 🎨

 

 

새로운 팀원 영입

DCI 패턴과 별개로 추가해야 할 테스트가 많았다. 하지만 새로 구현해야 할 기능도 있어 인력이 부족하다고 판단했다. 그래서 운영팀에게 서버 개발자 충원을 요청했고, 한 분이 새로 들어와서 같이 200여 개의 테스트를 추가했다. 지금도 추가하는 중이다.

 

 

 

 

 

☠️ 데이터 마이그레이션

새로운 설계를 바탕으로 코드 작성도 끝났다. 이제 DB에 저장된 기존 데이터들을 새 테이블로 알맞게 이동하면 된다.

문제 상황

예상하긴 했지만 간단한 작업이 아니었다. id가 1인 한 가계부 내역이 있다고 가정하자.

 

✅ 기존 카테고리 테이블 (old_category)

id	dType (종류)	parent_id (상위 카테고리)	book_id (연결 가계부)	name (이름)
1	DefaultRoot	null	null	수입
2	DefaultRoot	null	null	지출
3	DefaultRoot	null	null	이체
4	DefaultRoot	null	null	자산
5	Default	1	null	월급
6	Book	4	1	새 자산 분류

 

✅ 기존 가계부 내역-카테고리 연결 테이블 (old_book_line_category)

id	book_id (연결 가계부)	category_id (연결 카테고리)	category_type (카테고리 종류)
1	1	1	FLOW (지출/수입/이체)
2	1	5	ASSET (자산 분류)
3	1	6	FLOW_LINE (지/수/이 분류)

이 상황에서 세 개의 행으로 쪼개져있던 가계부 내역-카테고리 연결 데이터를 하나의 행으로 합쳐야 한다.

 

Q. 연결된 카테고리 정보를(category_id = 1, 5, 6)을 새로운 행의 각 컬럼에 넣어주면 되는 거 아닌가요?
A. 그거 아니야...

 

✅ 새 상위 카테고리 테이블 (category)

id	name (이름)
1	수입
2	지출
3	이체
4	자산

✅ 새 하위 카테고리 테이블 (subcategory)

id	parent_id (상위 카테고리)	book_id (연결 가계부)	name (이름)
1	1	1	월급
2	4	1	새 자산 분류

 

✅ 새 가계부 내역-카테고리 연결 테이블 (book_line_category)

id	flow_category_id (상위 카테고리)	asset_category_id (자산 하위 카테고리)	flow_line_category_id (하위 카테고리)
1	1	2	1

 

기존에 하나만 생성되던 기본 카테고리가 각 가계부 마다 생성되도록 변경되며 카테고리 id도 바뀌었다. 즉 기존 카테고리의 정보로 새 카테고리 테이블에서 id 를 찾아야하는 것이다. 다행인 점은 카테고리에서 (이름, 상위 카테고리, 가계부) 조합이 유일해야 하므로 이 세 가지를 이용해 id를 찾으면 된다.

 

 

마이그레이션 스크립트 생성

마이그레이션 조건이 복잡하기 때문에 처음에는 이를 담당하는 어플리케이션을 생성하려고 했다. 하지만 새 어플리케이션을 생성하기 위해 작성해야 할 코드가 길고, 이미 운영 중인 서비스기 때문에 마이그레이션 시간을 최소화하고 싶었다. 추가로 현재 데이터베이스 스키마를 flyway 를 통해 관리하고 있어 마이그레이션 sql 스크립트를 작성하기로 결심했다.

 

기본적으로 flyway는 스크립트를 버전 별로 실행하고, 각 스크립트 마다 트랜잭션이 적용된다. 중간에 에러가 발생하면 이후 스크립트는 실행하지 않는다. 이를 이용해 다음과 같이 스크립트를 작성했다.

 

✅ 스크립트 1 - 테이블 생성

1. 기존 category & book_line_category 테이블 이름 변경 (새로운 테이블과 이름이 겹친다.)
2. 새 category & subcategory & book_line_category 테이블 생성

✅ 스크립트 2 - 데이터 이동

1. 새 category 테이블에 지출/수입/이체/자산 데이터 생성
2. 새 subcategory 테이블에 기본 하위 카테고리를 가계부 별로 생성
3. 기존 category 테이블에서 새 subcategory 테이블로 커스텀 하위 카테고리를 이동
4. 기존 book_line_category 테이블의 데이터들을 새 book_line_category 테이블로 이동
5. 기존 테이블 삭제

이 때 book_line_category 마이그레이션 쿼리는 복잡하기 때문에 제대로 동작할 지 확신이 없었다.

-- 스포일러: 실패할 쿼리이므로 따로 설명을 달지 않았다
INSERT INTO `book_line_category`(book_line_id,
                                 line_category_id,
                                 line_subcategory_id,
                                 asset_subcategory_id,
                                 created_at)
    (SELECT oblc.book_line_id,
            linesub.parent_id,
            linesub.id,
            assetsub.id,
            oblc.created_at

     FROM `subcategory` linesub
              INNER JOIN `old_category` old_linesub
                         ON old_linesub.name = linesub.name
                             AND
                            old_linesub.book_id = linesub.book_id
                             AND
                            old_linesub.parent_id = linesub.parent_id
                            
              INNER JOIN `old_book_line_category` oblc
                         ON oblc.category_id = old_linesub.id
                         
              INNER JOIN `old_book_line_category` oblc_asset
                         ON oblc_asset.book_line_id = oblc.book_line_id
                         
              INNER JOIN `old_category` old_assetsub
                         ON old_assetsub.id = oblc_asset.category_id
                         
              INNER JOIN `subcategory` assetsub
                         ON assetsub.name = old_assetsub.name
                             AND
                            assetsub.book_id = old_assetsub.book_id
                             AND assetsub.parent_id =
                                 old_assetsub.parent_id
                                 
     WHERE old_linesub.dtype = 'Book'
       AND old_linesub.parent_id < 4
       AND old_assetsub.dtype = 'Book'
       AND old_assetsub.parent_id = 4);

 

실패에 대비해 스크립트가 실행되기 직전 DB를 백업했다. RDS를 사용하고 있어서 제공하는 백업 기능을 사용했다.

 

 

마이그레이션 실패와 재시도

전체 팀원들에게 개발 앱이 잠깐 제대로 작동하지 않을 수 있다고 알리고 스크립트를 실행했다. flyway 로그를 살피니 다행히 중간에 에러가 나지는 않았다. 그래서 성공했나? 싶었는데 문제의 쿼리가 잘못 작성되어 book_line_category 데이터가 제대로 이전되지 않았다.

어디로 갔니...

백업한 DB에서 데이터만 따와(mysqldump 이용) 로컬에서 다시 테스트해보며 새 쿼리를 작성했다.

 

insert into `book_line_category` (book_line_id,
                                  line_category_id,
                                  line_subcategory_id,
                                  asset_subcategory_id,
                                  created_at)
    (select bl.id,
            line_sub.parent_id,
            line_sub.id,
            asset_sub.id,
            old_line_sub_blc.created_at

     from old_book_line_category old_line_blc

              -- 3개의 행으로 나뉜 기존 book_line_category를 하나의 행으로 JOIN
              inner join old_book_line_category old_line_sub_blc
                         on old_line_sub_blc.book_line_id = old_line_blc.book_line_id
              inner join old_book_line_category old_asset_sub_blc
                         on old_asset_sub_blc.book_line_id = old_line_sub_blc.book_line_id

         -- book의 id를 찾기 위한 JOIN
              inner join book_line bl
                         on bl.id = old_line_blc.book_line_id

         -- 기존 category의 id를 찾기 위한 JOIN
              inner join old_category old_line_sub
                         on old_line_sub.id = old_line_sub_blc.category_id
              inner join old_category old_asset_sub
                         on old_asset_sub.id = old_asset_sub_blc.category_id

         -- (이름, 속한 가계부, 부모 카테고리)를 바탕으로 새로운 category의 id 를 찾기 위한 JOIN
              inner join subcategory line_sub
                         on line_sub.name = old_line_sub_blc.name
                             and line_sub.parent_id = old_line_blc.category_id
                             and line_sub.book_id = bl.book_id
              inner join subcategory asset_sub
                         on asset_sub.name = old_asset_sub_blc.name
                             and asset_sub.parent_id = 4
                             and asset_sub.book_id = bl.book_id

          -- 3개의 행으로 나뉜 기존 book_line_category를 하나의 행으로 JOIN 하는 조건
     where old_line_blc.book_line_categories_key = 'FLOW'
       and old_line_sub_blc.book_line_categories_key = 'FLOW_LINE'
       and old_asset_sub_blc.book_line_categories_key = 'ASSET');

 

다행히 새 쿼리는 잘 동작했다.

 

 

 

 

 

🤯 소감

서버팀의 큰 이슈를 드디어 끝냈다. 코드만 해도 최소 9천줄이 변경된 대공사였다.

 

최선의 설계는 어떻게 할까?

지금 레거시로 취급하고 변경한 이전 설계는 그 당시에선 최선으로 여겼던 설계다. 그렇다면 지금 설계도 미래에 레거시가 되지 않을까? 

 

요즘은 장애 상황이 일어나지 않도록 100% 예방하는 건 불가능하니, 장애 상황이 일어났을 때 빠르게 복구되도록 서비스를 개발한다고 한다. 도메인이 어떻게 변경될 지 100% 예측하는 건 불가능하니 지금의 설계도 추후 레거시가 될 가능성이 있다. 그렇다면 그 때 최대한 안정적으로 변경할 수 있도록 대비하면 되지 않을까? 대비책으로는 아직 인수 테스트 추가만 생각나는데(개발 외에는 QA 시나리오 정리?)... 아직은 잘 모르겠다.

 

레거시는 빨리 치우자

사실 이번에는 알고도 일정에 맞추느라 못 치웠지만... 역시 개발하면서 걸리는 요소는 최대한 빨리 해결해야겠다. 변경할 코드가 많아지기도 하지만 서비스를 운영하니 손댈 데이터도 많아진다.