The-Form Refactoring

저는 더폼(The-Form)이라는 서비스를 운영 중입니다. 더폼은 2021년 소프트웨어 마에스트로 교육과정을 연수하며 만든 설문조사 플랫폼입니다.

더폼을 개발하기로 결정하고 첫 커밋을 찍은 것이 21년 7월 8일입니다. 그 이후로 2년이 지났고, 더폼에는 많은 변화가 생겼습니다. 그러면서 더폼의 코드도 점점 복잡해지며 유지보수가 어려워졌습니다. 그래서 저는 더폼의 코드를 리팩토링하기로 결정했습니다.

이 글에서는 더폼의 리팩토링 과정을 소개하고, 리팩토링을 하면서 느꼈던 점들을 공유하려고 합니다.

왜 리팩토링을 하게 되었나?

더폼은 (신기하게도) 많은 유저분들이 사용해주시는 플랫폼으로, 다양한 기능 요청들이 항상 들어옵니다. 하루에 수 건씩 새로운 기능에 대한 요청이 들어올 때도 있습니다. 그런데 이런 기능들을 개발하려다 보니 코드가 너무 복잡하고 불안정해서 새 기능을 추가하기가 너무 어려워졌습니다. 물론 어떻게든 개발하려고 하면 못할 것은 없겠지만 그러다 일이 잘못되면 도저히 손댈 수 없게 될 것 같았습니다.

더폼의 문제점들

더폼의 가장 큰 문제는 타입스크립트가 아니라 자바스크립트로 개발됐다는 점입니다. 당시 프로덕트를 빠르게 개발하려는 욕심이 있었고, 저를 포함한 팀원들은 타입스크립트에 익숙하지 않았습니다. 그래서 자바스크립트를 사용하기로 의사결정을 내렸었습니다. 프로덕트 구조가 간단하고 항상 코드를 보고 있을 때는 별 문제가 없었는데, 프로덕트가 복잡해지고 한동안 코드를 보지 않다가 다시 코드를 보니 해석하기가 너무 어려웠습니다.

그리고 컴포넌트들이 별도의 리포지토리로 존재했고 각각 독립적인 배포 프로세스를 가지고 있었습니다. 더폼은 백엔드, 프론트엔드, 인증 서버, 이미지 서버 등 다양한 컴포넌트로 나뉘어져 있습니다. 그런데 이들이 별도의 리포지토리에 존재하다 보니 배포 관련 작업을 바꾸는 것이 너무 큰일이 되어버렸습니다. 특히 GitHub Action에 각종 시크릿을 비롯한 중요한 값들이 각 리포지토리마다 설정되어 있어 하나의 설정값을 바꾸려고 해도 모든 설정값을 전부 건드려야 했습니다. 또 GitHub Action에서는 보안상의 이유로 시크릿을 설정하는 것은 가능하나 시크릿을 다시 확인하는 것은 불가능해서 시크릿을 별도로 유지해야 했습니다. 특히 시크릿은 Git으로 추적할 수도 없어 실수로 유실할 때도 있었습니다.(물론 쿠버네티스 상에서 그 값을 확인 가능하므로 다시 가져오면 되기는 합니다.)

무엇보다 아키텍쳐가 깔끔하지 않았었습니다. 특히 더폼은 중요한 로직들이 프론트엔드에 많이 들어있습니다. 그런데 규모가 큰 프론트엔드 코드를 작성해본 경험이 부족했을 뿐만 아니라 아키텍쳐에 대한 이해도 부족해서, 프론트엔드에서 비즈니스 로직과 UI 코드가 많이 섞여버리고 말았습니다.

리팩토링 전략

리팩토링에 앞서 리팩토링 전략을 철저하게 짜고 점진적 배포를 목표로 리팩토링에 들어가기로 했습니다. 왜냐하면 이전에 리팩토링을 시도했다가 실패한 경험이 몇 번 있었기 때문입니다. 그때는 한 번에 리팩토링을 너무 많이 진행한 나머지 프로덕트가 이전과 너무 많이 달라져 기존 서비스에 저장되어있던 데이터를 이식해오는 것이 사실상 불가능해졌었습니다. 거기다 프론트엔드와 백엔드의 구조를 한번에 너무 많이 바꾸다 보니 데이터 이식이 가능하다 한들 사실상 프로덕트를 새로 만들어 배포하는 상황이었습니다. 완전히 새로운 코드베이스를 배포하는 것은 너무 위험한 결정입니다. 그래서 결국 리팩토링한 버전을 배포하지 못하고 원래대로 돌아왔었습니다.

이를 위해 가장 먼저 더폼의 모든 리포지토리를 전부 하나의 monorepo에 몰아 넣었습니다. 그리고 CI/CD 파이프라인을 다시 구축했습니다. monorepo로 리포지토리를 합치는 데는 여러 장점이 있습니다.

기존의 구조에서는 개발 서버를 로컬에서 띄우기가 힘들지만 monorepo로 프로젝트를 관리하면 서비스 전체를 하나의 docker-compose파일로 로컬에서 띄울 수 있습니다.
- 더폼은 그렇게 무거운 서비스가 아니며 팀 규모가 작기 때문에 다른 서비스를 mocking하기보다는 서비스 전체를 로컬에서 띄워 개발하는 편이 효율이 훨씬 좋습니다.
테스트가 편리합니다.
배포 관련 작업을 리포지토리마다 할 필요 없이 한 번만 하면 됩니다.
서비스 공통 설정값이나 kubernetes resource같은 애매모호한 자료들을 쉽게 관리할 수 있습니다.

그리고 이 작업을 시작하면서 기존의 모든 리포지토리를 archive했습니다. 기존의 코드베이스를 건드리지 못하게 강제하기 위함입니다. 전에 그렇게 하지 않았더니 사소한 오류 수정이나 디자인 개선을 이유로 기존의 코드베이스를 자꾸 건드리게 되고, 그러다 기존 코드베이스와 새 monorepo의 차이가 너무 커지면서 결국 monorepo로 이전하는 것이 불가능해진 적이 있습니다.

마지막으로 '어쨌든 프로덕션 배포'를 가장 우선의 목표로 삼았습니다. 코드베이스와 프로덕트의 차이를 최소화하기 위해서입니다.

monorepo 통합 및 배포 이후에는 억눌려있었던 다른 개발자, 디자이너, PM 분들의 프로덕트 개선 욕구를 반영하기 위해 리팩토링을 잠시 중지하고 디자인 개선과 각종 데이터 분석 툴 추가, 기능 개선 작업을 진행했습니다. 그러면서 백엔드의 아키텍쳐가 좀 더 견고하게 바뀌었고 메인 페이지의 디자인을 개선했으며 각종 자잘한 오류를 해결했습니다. 이로서 리팩토링을 시작할 최소한의 준비를 마쳤습니다.

리팩토링을 다시 시작하기에 앞서 백엔드와 프론트엔드 중 어떤 컴포넌트를 먼저 작업할지를 결정해야 했습니다. 두 컴포넌트를 동시에 리팩토링하는 것이 불가능하지는 않습니다. 그러나 그 경우 대단히 많은 코드가 수정된 후에야 배포가 가능합니다. 즉, 점진적인 배포가 불가능합니다. 그래서 고민 끝에 프론트엔드를 먼저 리팩토링하고 백엔드를 비롯한 나머지 컴포넌트를 리팩토링하기로 결정했습니다. 더폼은 설문조사라는 도메인 상 비즈니스 로직이 대부분 프론트엔드에 있기 때문입니다.

프론트엔드 리팩토링 [1] - Ts-fy

모든 구조적 리팩토링에 앞서 프론트엔드를 JS에서 TS로 리팩토링했습니다. 불확실한 부분에 전부 any를 넣는 한이 있더라도 일단 모든 파일을 타입스크립트로 변환했습니다. 그러면서 UI컴포넌트를 비롯하여 세부적인 부분들을 전부 안정적인 타입스크립트로 변환할 수 있었습니다.

프론트엔드 리팩토링 [2] - 아키텍쳐 설계

이후에는 클린 아키텍쳐에 기반한 설문 구조를 구현했습니다. 이 과정에서는 비즈니스 로직을 구현하기 위한 프로그래밍 방법론을 결정하는 것이 가장 힘들었습니다. 프로그래밍에는 절차지향형, 함수형, 객체지향형 등 다양한 패러다임이 있습니다. 이중 더폼의 비즈니스 로직을 구현하는 데는 객체지향형(Object Oriented Programming; OOP)와 자료지향형(Data Oriented Programming; DOP) 두 가지 방법론이 적당합니다. 그런데 두 방법론 모두 장단점이 있어서 어느 방법론을 선택할지 결정하기가 쉽지 않았습니다.

OOP를 택하면:

값을 숨기고 메서드만 노출함으로써 엔티티를 안정적으로 만들 수 있습니다.
그러나 값과 메서드가 섞인다는 단점이 있습니다.
그래서 프론트엔드 - 백엔드간 엔티티의 공유가 어렵습니다.

DOP를 택하면:

그 데이터를 다루는 함수가 잘 분리됩니다.
스키마만 잘 정의하면 서비스간, 즉 프론트엔드 - 백엔드간 엔티티 데이터의 공유가 쉽다는 장점이 있습니다. DOP가 언어에 구애받지 않도록 설계된 방법론이기 때문입니다.
그러나 데이터를 은닉하거나 직접 수정하지 못하도록 강제하는 것이 어렵다는 단점도 있습니다.
잘못 구현하면 비즈니스 로직이 분산될 수도 있습니다.

이 결정이 어려운 이유는 더폼의 비즈니스 로직이 프론트엔드와 백엔드에 걸쳐있기 때문입니다. 만약 더폼이 프론트엔드나 백엔드 둘 중 한쪽이 대부분의 비즈니스 로직을 차지하고 다른 쪽은 상대의 인프라, 혹은 표현 레이어에 불과하다면 이러한 고민을 할 필요가 없었을 것입니다.

사실 프론트엔드와 백엔드라는 관점은 애초에 아키텍쳐 설계 단계에서는 고려해서는 안 됩니다. 먼저 아키텍쳐를 설계하고 난 후, 구체적인 부분을 구현할 때 프론트와 백이라는 경계를 컴포넌트 사이에 그을 수 있을 뿐입니다.

물론 OOP와 DOP는 관점이 다를 뿐 상충하는 방법론이 아닙니다. 필요에 따라 두 방법론을 조화롭게 사용할 수 있습니다. 다만 그 과정에서 각 방법론의 장점이 희석돼서는 안됩니다. 그래서 저는 아래와 같은 방식으로 접근했습니다.

DOP의 관점에서:

데이터의 값과 분리되는 스키마를 정의합니다.
데이터를 클래스의 인스턴스가 아닌 범용 오브젝트로 다룹니다.
데이터는 불변성을 유지합니다.

OOP의 관점에서:

데이터를 조작할 때는 오브젝트를 직접 조작하지 않고 대신 오브젝트를 조작하는 클래스의 인스턴스를 사용합니다.
이 인스턴스 내에서는 데이터가 불변성을 유지하지 않습니다.
이러한 인스턴스는 필요에 따라 데이터 그 자체보다 조금 더 많은 state를 가질 수 있습니다.

아래는 이를 구현한 의사 코드입니다.

// 아래 코드는 pseduo code입니다.
import { Survey, SurveySchema } from 'entity';

class SurveyService{
    private surveyObject: Survey;

    constructor(surveyObject: Survey){
        const newSurveyObject = deepCopyObject(surveyObject); // 그러므로 SurveyService 외부에서 데이터는 불변입니다.
        this.surveyObject = SurveySchema.validateOrThrow(newSurveyObject); 
    }

    public getSurveyObject(): Survey{
        return deepCopyObject(this.surveyObject);
    }

    public setSurveyTitle(title:string){
        this.surveyObject.title = title;
    }

    // ... 하략
}

이러한 방법으로부터 얻을 수 있는 장점은 다음과 같습니다.

비즈니스 로직이 하나의 클래스로 집중됩니다.
인스턴스가 생성될 때 validation을 수행하며 이후에는 클래스의 메서드만을 사용해서 데이터를 조작합니다. 그러므로 (메서드에서 실수하지만 않는다면) 데이터의 무결성이 보장됩니다.
OOP의 장점을 그대로 살릴 수 있습니다. 예를 들어 인터페이스 등을 사용하여 의존성 역전 등을 용이하게 구현할 수 있습니다.

또 엔티티 스키마를 작성할 때 그것이 백엔드와 프론트엔드에 대한 single source of truth가 되기를 바랐습니다. 그러려면 언어 및 프레임워크에 대한 의존성을 최소화해야 합니다. 그래서 아래와 같은 방법을 택했습니다.

스키마는 JSON-Schema로 작성합니다.
zod를 사용하여 validation을 수행하고 타입스크립트 타입을 추출합니다.
JSON-Schema는 대부분의 언어와 호환되므로 백엔드나 프론트엔드 언어가 바뀌더라도 적절한 변환 라이브러리를 택해 스키마를 그대로 사용할 수 있습니다.

프론트엔드 리팩토링 [3] - 로직 마이그레이션

이후에는 기존의 프론트엔드를 새롭게 만들어진 깔끔한 비즈니스 로직을 사용하도록 마이그레이션했습니다. 이 과정에서는 새롭게 작성한 코드를 손상시키지 않으면서 리액트와 호환되게 만드는 것이 가장 어려웠습니다.

리액트에서는 상태를 state로 관리합니다. state는 setState에 의하여 값이 설정되고 그러면 리액트에 의해 자동으로 렌더링이 다시 이루어집니다. 그런데 새로 만든 아키텍쳐에서 상태는 오브젝트 혹은 이를 포함하는 클래스의 인스턴스일 뿐입니다. 그래서 메서드를 사용해서 내부적으로 값을 변경해도 렌더링이 발생하지 않습니다.

이 문제를 해결하기 위해 다양한 고민을 해보고 또 시도해봤습니다.

리액트의 state를 사용하여 상태 관리를 하는 것을 고려해봤습니다.
- 그러나 그 경우 엔티티나 유즈케이스처럼 추상적인 부분이 리액트 프레임워크라는 구체적인 부분에 의존합니다. 그러므로 이는 추상화를 위반합니다.
- 또 state는 새로운 값을 어디서나 즉시 참조할 수 있는 것이 아니라 UI가 한 번 렌더링된 후에야 참조할 수 있습니다. 그러므로 비동기나 UI와 무관한 로직을 구현하기에는 적합하지 않습니다.
- state는 setState와 useState를 포함하여 UI 내부에서만 사용할 수 있으므로 UI에 비즈니스 로직이 의존하게 됩니다.
Context API나 Redux를 사용하여 상태 관리를 할 수도 있습니다.
- 그러나 이것 역시 좀 더 쓰기 편하고 여러 컴포넌트에 걸쳐 있는 useState일 뿐입니다.
- 결과적으로 추상화를 위반합니다.
Javascript의 Proxy API를 사용하면 오브젝트의 변화를 감지할 수 있습니다.
- 이 방법은 너무 괜찮아 보여서 실제로 구현해보기도 했습니다.
- 그런데 실제로 해 보니 이 구현은 너무 환경에 의존적입니다. 어떤 브라우저에서는 이 API를 지원하지 않기도 합니다.
- 일반적으로 어떤 동작이 실행될 것이라고 예상하기 힘든 값 할당에서 동작이 발생하기 때문에 의도치 않은 실수를 유발할 수 있습니다.
- 경우에 따라 값이 변경되었지만 렌더링을 원하지 않을 수도 있습니다. 같은 값을 재할당하는 경우가 그렇습니다. 그러나 이 경우에도 렌더링이 발생합니다.
Service에서는 값의 변화를 관찰하는 로직을 전혀 넣지 않습니다. 대신 Service를 React에서 사용할 수 있도록 해주는 Adaptor를 만들고, 거기에서 service의 모든 함수를 wrapping하여 변화를 감지하도록 구현합니다.
- 아키텍쳐적으로는 가장 깔끔한 방법이라고 생각했습니다.
- 그러나 이 방법은 Adaptor에서 Service의 모든 함수를 wrapping해야 하므로 코드 중복이 과도하게 발생합니다.
- 특히 새로운 기능을 추가할 때마다 Adaptor를 수정해야 하므로 유지보수를 어렵게 만듭니다.

이러한 시도 끝에 결국은 가장 확실하고 안정적인 방법을 택하기로 했습니다. 데이터를 관리하는 Service object에는 listener를 등록할 수 있고, 데이터의 값을 변경하는 함수가 호출되면 값을 변경한 후 명시적으로 등록된 listener를 호출하는 방식입니다. 이 방식은 특별한 환경을 요구하지 않으므로 가장 안정적이고 확실한 방법이라고 생각했습니다. 이 방법은 대신 실수로 새로운 기능을 구현하고서 listener 함수를 호출하지 않으면 렌더링이 발생하지 않습니다.

// 아래 코드는 pseduo code입니다.
class SurveyService{
    // ... 상략
    private listeners: (()=>void)[] = [];
    public addListener(listener:()=>void){
        this.listeners.push(listener);
    }

    private notifyListeners(){
        this.listeners.forEach(listener=>listener());
    }

    public setTitle(title:string){
        this.surveyObject.title = title;
        this.notifyListeners();
    }
    // ... 하략
}

프론트엔드 리팩토링 [4] - 데이터 마이그레이션

이후에는 데이터를 마이그레이션했습니다. 먼저 백엔드를 호출해야 하는 작업들을 Repository라는 인터페이스에 정의하고 이 인터페이스를 구현하는 클래스를 작성했습니다. 이때 백엔드는 아직 전혀 손대지 않은 상태이므로 기존에 백엔드를 호출하던 함수들을 그대로 가져다 썼습니다. 그리고 백엔드에서 가져온 데이터들을 새롭게 바뀐 엔티티 구조로 마이그레이션하는 코드를 넣었습니다.

이때, 충격적이게도, 백엔드로 값을 집어넣을 때는 마이그레이션이 필요하지 않았습니다. 왜냐하면 백엔드에서 값 검사를 거의 하지 않았기 때문입니다. (그래서 사실 기존 더폼 데이터베이스에는 임의의 JSON 객체를 삽입하는 것이 가능했었습니다.)

마이그레이션 함수를 만들 때는 별로 고민할 것이 없었습니다. 값의 validation이나 parsing을 zod 라이브러리를 통해 쉽게 해결했기 때문입니다. 그러나 기존 설문 데이터 구조를 대충 적어만 놓고 그 스키마를 Typescript interface나 JSON-Schema 등의 구조적인 자료로 만들어두지 않았기 때문에 데이터베이스를 직접 확인하면서 기존 설문 구조를 파악해야만 했습니다. 특히 기존에는 Optinal한 필드가 너무 많았어서 기본값 처리를 하는 것 역시 꽤 난감한 작업이었습니다.

프론트엔드 리팩토링 [5] - 용어 정리

구조를 정리한 후에는 용어를 확실히 정리했습니다. 이전까지는 여러 용어를 사용하다 보니 혼란이 있었기 때문입니다. 예를 들어 설문의 응답을 나타내기 위해 국문으로 응답, 답변, 결과, 영문으로는 answer, response, result 등의 용어가 혼용되고 있었습니다. 특히 response, 혹은 응답은 일반적인 API 응답을 나타내기도 하고 설문 답변을 나타내기도 해서 대단히 혼란스러웠습니다. 그래서 아래와 같이 용어를 정리했습니다.

Survey: 설문
Question: 설문의 질문. Survey는 Question을 여러 개 가질 수 있다.
Answer: 한 개 Question에 대응하는 답변.
Submission: 응답자가 한 개 Survey에 대해 답한 결과. 그러므로 Submission은 여러 개의 Answer로 이루어진다.
Result: 한 Survey에 대한 모든 Submission의 집합. 그러므로 Result는 여러 개의 Submission으로 이루어진다.

백엔드 리팩토링 [1] - 아키텍쳐

이후에는 백엔드 리팩토링을 진행했습니다. 이전까지는 express router에 들어 있었던 비즈니스 로직을 단일 클래스로 모았습니다. 그리고 다양한 기능들의 의존성을 분리했습니다.

예를 들어 이메일을 보내는 기능을 리팩토링했습니다. 이전에는 메일을 보내는 과정이 비즈니스 로직에 직접 포함되어 있었습니다. 비즈니스 로직에서 EJS 템플릿 엔진을 실행하고, 직접 AWS SDK를 호출했습니다. 그러므로 이메일을 보내는 route하나가 라우팅, 파라매터 파싱, 템플릿 렌더링, 보내기까지 모든 과정을 수행했습니다. 그러나 리팩토링을 진행하며 이 기능을 EmailSender, TemplatedEmailSender라는 두 가지 인터페이스로 분리했습니다.

EmailSender는 sendEmail(src, dst, title, content)라는 메서드를 가집니다.
TemplatedEmailSender는 sendGreetingEmail(...), sendSurveyInfoEmail 등의 메서드를 가집니다. 각 메서드는 이메일을 보낼 때 필요한 값을 파라매터로 받아 내부적으로 이메일 제목과 내용을 생성합니다.
TemplatedEmailSender는 생성 시 EmailSender를 주입받아 메일을 보낼 때 사용합니다.

이후 이를 상속하는 SesEmailSender, TemplatedEmailSenderImpl 클래스를 실제로 구현했습니다. 이로부터 관심사의 분리가 이루어졌습니다.

비즈니스 로직을 전혀 건드리지 않고 템플릿을 추가하거나 업데이트할 수 있습니다.
이메일을 AWS SES대신 다른 방법으로 보내려는 경우에도 아주 쉽게 이식할 수 있습니다.
SesEmailSender를 제외하면 모두 로컬에서 mocking에 기반한 테스트가 가능합니다.

물론 백엔드에도 데이터베이스 접근을 위한 Repository 인터페이스를 만들고 실제로 접근하는 RepositoryImpl 클래스를 구현했습니다. 그러면서 프론트에 있었던 옛날 버전의 설문을 새롭게 마이그레이션하는 코드를 백엔드 RepositoryImpl로 옮겨왔습니다. 몇 가지 사소한 오류를 제외하면 (프론트에서와 다르게 백엔드에서는 Date 형식의 값이 문자열이 아니라 오브젝트였기 때문에 발생한) 문제 없이 잘 동작했습니다. 이로부터 백엔드에서도 타입 안전성이 확보되었습니다.

백엔드 리팩토링 [2] - API

비즈니스 로직을 리팩토링한 후에는 API 구현을 신경썼습니다. API는 테스트하기 어려울 뿐만 아니라 컴파일 타임에 오류를 잡기도 힘들기 때문입니다. 그래서 API 코드를 직접 구현하는 대신, tsoa 라이브러리를 사용하여 자동으로 API route와 OpenAPI Schema를 생성하도록 구현했습니다. 이후 프론트엔드에서 openapi-typescript-codegen 라이브러리를 사용하여 API 클라이언트를 자동으로 생성하도록 구현했습니다.

프론트와 백은 OpenAPI의 subset인 JSON Schema로 작성된 엔티티를 공유하기 때문에 타입은 자연스럽게 일치됐습니다. 프론트의 Repository는 API를 호출하고 migration을 수행하는 두꺼운 레이어에서 Request, Response 객체만 다뤄주는 얇은 레이어가 되었습니다.

또한 부가적인 이득으로 입력 데이터의 스키마 검증이 자동으로 이뤄지게 됐습니다. 예전에는 데이터의 값을 제대로 validation하지 않았기 때문에 사실상 임의의 JSON을 보내도 저장이 가능했습니다. 그러나 지금은 tsoa에서 자동으로 타입 검증을 해 주기 때문에 이런 문제가 발생하지 않습니다.

백엔드 리팩토링 [3] - 테스트

이후 드디어 테스트 스크립트를 도입하기로 했습니다. 기존에는 기능이 별로 많지 않아 수동으로 QA를 진행했었지만, 앞으로 기능을 더 추가할 예정인데다 배포도 잦아질 것이므로 수동 QA는 합리적이지 않다고 판단했기 때문입니다.

테스트 프레임워크로는 Puppeteer, Playwright를 고려했습니다. Postman, Jmeter 등 다양한 테스트 툴이 있지만 이들은 API나 백엔드 레이턴시 / 스루풋 측정에는 적합해도 UI를 테스트할 수 없다는 단점이 있었기 때문입니다. 더폼은 설문조사 플랫폼이기 때문에 UI 테스트가 필수적입니다.

이 둘 중 Playwright를 선택했습니다.

설치 및 환경설정이 편리합니다.
공식적으로 docker를 지원합니다.
Asynchronous / delay가 발생하는 작업에 대한 테스트가 자동화되어 있습니다.
여러 브라우저에서 한 번에 테스트할 수 있는 옵션을 제공합니다.

시크릿 관리

그리고 sealed-secret 기반으로 시크릿을 관리하도록 업데이트했습니다. 기존에는 GitHub Action을 동작시킬 때 환경 변수를 통해 시크릿을 주입했습니다. 이 방법은 시크릿 관리가 어려울 뿐만 아니라 시크릿이 포함된 Kubernetes resource를 git에 track하는 것이 불가능한 문제가 있었습니다.

Sealed-secret은 이러한 문제를 해결하기 위한 툴입니다. Sealed-secret은 쿠버네티스에 떠 있는 컨트롤러와 CLI로 구성되어 있습니다. CLI는 쿠버네티스의 public key로 시크릿을 암호화하여 YAML 파일로 출력합니다. 이 YAML 파일을 쿠버네티스에 배포하면 컨트롤러가 이를 감지하여 시크릿을 복호화하여 쿠버네티스에 저장합니다.

따라서 sealed-secret 리소스가 노출되더라도 컨트롤러가 가지는 private key가 없으면 그 값을 알 수 없습니다. 반면 원본 시크릿 없이 sealed-secret만을 가지고 있더라도 문제없이 시크릿을 배포할 수 있습니다. 이로부터 시크릿 및 다른 Kubernetes resource를 git에 track할 수 있게 되었습니다.

CI / CD 리팩토링

그와 함께 GitHub Action으로 구현되었던 CI / CD를 로컬에서 동작하는 Node.js 스크립트로 업데이트했습니다.

더폼은 팀 규모가 작기 때문에 굳이 무겁고 중앙화된 배포 환경을 사용할 필요가 없습니다.
로컬에서 빌드 및 배포를 수행하면 캐시 사용을 극대화하여 빌드 시간이 크게 단축됩니다.
필요에 따라 다시 GitHub Action 등으로 옮기는 것도 어렵지 않습니다.

이 Node.js 스크립트는 각 서비스에 대하여 아래 동작을 실행합니다.

node-modules 등을 제외한 리포지토리의 모든 파일의 목록을 얻습니다.
이를 정렬합니다.
순서에 따라 모든 파일을 읽으며 그 해시를 계산합니다.
파일시스템에 저장되어있는 해시와 비교, 다르다면 빌드를 수행합니다.
도커 이미지를 레지스트리에 푸시합니다. (더폼은 프라이빗 리포지토리를 사용하고 있습니다.)
kustomize를 실행하여 더폼 전체 서비스를 띄우는 단일 manifest.yaml 파일을 생성합니다.
이를 kubectl로 배포합니다.

이로부터 해당 manifest.yaml 파일만 가지고 있으면 더폼 전체 서비스를 배포할 수 있게 되었습니다. 이 파일은 git에 track되어 있으므로 만약 오류가 발견되어 서비스를 롤백해야 하는 경우, 가장 최근 배포한 커밋에서 해당 파일을 가져와서 배포하면 됩니다.

마무리하며

이렇게 더폼을 리팩토링해봤습니다. 어려운 부분도 많았지만 그만큼 배울 점도 많았습니다. 더폼은 아직도 많이 부족한 서비스이지만, 이번 리팩토링을 통해 더 나은 서비스를 만들 수 있을 것이라고 믿습니다.