Back to the Basics

개발을 시작하고 4년째가 된 개발자의 회고

9Jaeng — Sun, 29 Mar 2026 12:56:08 +0900

개발 4년, 그리고 2026년의 변화

2022년 4월에 개발을 시작했고, 2026년 4월이 되면 어느덧 딱 4년이 된다.
4년이라는 시간이 흘렀지만, 유독 2026년에 들어서면서 많은 것이 달라졌다고 느낀다. 이직을 했고, 생활 패턴도 바뀌었고, 무엇보다도 코드를 직접 작성하는 시간보다 프롬프트로 코드를 만들어 가는 시간이 훨씬 많아졌다.

개발을 처음 시작했을 때만 해도 AI는 딥러닝, 비전, 자연어처리처럼 하나의 기술 분야에 가까웠다. 그러다 개발을 시작한 지 1년에서 1년 반쯤 지났을 무렵, 처음으로 LLM이라는 개념을 접했다. 그리고 얼마 지나지 않아, 그 LLM은 어느새 내 일상과 업무 한가운데로 들어왔다.
지금 돌아보면, 개발자로서 보낸 지난 4년 중에서도 요즘이 가장 큰 변화의 시기인 것 같다.

첫 시작과 이직, 그리고 또 이직

첫 회사를 약 2년 4개월 다녔고, 두 번째 회사를 1년 정도 다닌 뒤 지금의 회사로 옮겼다. 그렇게 지난 4년 동안 두 번의 이직을 했다.

첫 번째 회사는 개발자로서의 커리어를 시작한 곳이었다. 믿음직스럽고 좋은 시니어분들이 많았고, 이것저것 배우기에 정말 좋은 환경이었다. 어느 정도 규모가 있는 프로젝트가 어떻게 돌아가는지, 일정 수준 이상의 인원이 있는 조직에서는 프로젝트 관리와 협업이 어떻게 이루어지는지 배울 수 있었던 곳이다.

하지만 경기가 나빠지면서, 시리즈 C 투자까지 받았던 회사도 결국 구조조정을 하게 되었고, 나 역시 이직을 하게 되었다.

두 번째 회사는 규모는 훨씬 작았지만 보다 단단한 회사였다. 공공부문 교육을 주로 다루는 에듀테크 회사였다. 첫 번째 회사보다 개발자 수는 적었지만, 자율성은 더 컸다. 첫 회사에서 쌓은 경험을 발판 삼아 이곳에서는 조금 더 주체적으로 일을 해나가야 했다. NCP도 이곳에서 처음 써봤고, 데브옵스 담당자가 나가면서 백엔드 개발자가 맡아야 할 역할도 자연스럽게 늘어났다. 첫 회사에서는 데브옵스 팀이 탄탄했기 때문에 인프라 영역까지 깊게 볼 일이 많지 않았는데, 개인적으로는 그런 점이 좋은 경험이 되었다.

다만 아쉬운 점도 있었다. 팀 내부의 분열, 잦은 인원 교체, 사람을 뽑기 위한 릴레이 면접, 인원 부족으로 인한 개발 일정 지연이 반복됐다. 게다가 공공부문 교육이라는 도메인 특성상 기술 스택도 다소 제한적이었고, 일을 하면서 재미를 느끼기 어려웠다. 무엇보다 개발을 하면서 점점 무기력해지는 내 모습이 싫었다. 결국 퇴사를 결심하게 되었고, 마침 이사로 인해 통근 거리까지 멀어진 것도 적지 않은 이유가 됐다.

그리고 지금의 세 번째 회사.
나는 원래부터 데이터에 관심이 많았고, AI를 많이 활용하거나 AI와 가까운 회사에서 일해보고 싶었다. 여기에 금융 도메인에 대한 관심도 늘 있었다. 그런 점에서 지금 회사가 하는 일은 내게 꽤 매력적으로 다가왔다. 게다가 재택근무가 가능하다는 점도 좋았다.

막상 와보니 함께 일하는 개발자분들도 첫 번째 회사 못지않게 좋은 분들이었고, 배울 점도 많았다. 동시에 두 번째 회사에서처럼 스스로 더 주도적으로 움직여야 하는 환경이기도 했다. 내게는 첫 번째 회사와 두 번째 회사의 장점이 함께 있는 곳처럼 느껴졌다. 아직 부족한 점은 많지만, 내가 원하던 분야에 더 가까운 만큼 오래 일하고 싶다는 생각이 든다.

재택근무가 내게 가져온 변화

나는 원래 재택근무를 하면 오히려 일을 더 많이 하게 되는 편이라고 생각했는데, 지금도 역시 그렇다. 주말에도, 새벽에도 일하고 있는 나를 발견하곤 한다.

내가 재택을 원했던 가장 큰 이유는 두 가지였다.
첫째는 통근 시간, 둘째는 효율성이다.

최근 천안으로 이사를 오면서 서울로 출퇴근하는 것이 쉬운 일이 아니게 되었다. 도어 투 도어로 편도 2시간이 걸리는데, 그 시간이 너무 아깝게 느껴졌다. 버스를 타기 위해 새벽에 일어나야 했고, 아무리 일찍 잠들려고 해도 퇴근 후 집에 돌아와 저녁을 먹고 조금 쉬다 보면 어느새 새벽이 되었다. 자는 시간은 점점 늦어지고, 피로는 계속 쌓였다. 다크서클은 눈 밑까지 내려오고, 체력도 점점 부족해진다는 생각이 들었다.

돌이켜보면 통근만으로도 하루에 써야 할 에너지의 절반 가까이를 쓰고 있었던 것 같다. 그러다 보니 주말에는 정말 잠만 자고 늘어져 있는 나를 자주 발견했다. 그런데 재택을 하면서 통근에 쓰이던 시간이 사라지자, 무기력했던 상태가 조금씩 회복되고 있다. 오히려 개발에 대해 더 많이 생각하게 되고, 생각 자체도 이전보다 훨씬 긍정적으로 바뀌는 느낌이 든다.

두 번째 이유는 효율성이다.
오피스에서 생활하다 보면 동료들과의 반쯤 강제적인 티타임이나, 업무 외적인 대화에 쓰이는 시간이 생각보다 많다. 물론 그런 시간들이 관계를 쌓는 데 도움이 되지 않는 것은 아니다. 하지만 일을 해야 하는 시간에 집중이 흐트러지는 순간들이 분명히 존재한다. 반면 집에서는 비교적 온전히 업무에만 집중할 수 있다. 그래서인지 퇴근 이후에도 자연스럽게 일을 이어가고 있는 나를 발견할 때가 많다.

물론 재택이 모두에게 정답이라고 생각하지는 않는다. 하지만 적어도 내게는 통근으로 소모되던 에너지를 줄여주고, 더 오래 집중할 수 있게 해주는 방식이다. 업무 시간을 줄이지 않으면서도 나름의 삶과 행복의 균형을 맞출 수 있게 해준다. 그래서 나는 재택이 정말 필요하다고 느낀다.
이 좋은 환경을 유지할 수 있도록 회사가 더 잘 성장했으면 좋겠고, 나도 그 안에서 더 열심히 일하고 싶다.

ADD(AI Driven Development)의 시대

2026년에 내 삶의 방식에서 제일 큰 변화가 아닐까싶다.
GPT가 처음 등장했을 때부터 꽤 열심히 사용해왔다. Cursor가 처음 나왔을 때도 주변 동료들보다 빠르게 써보면서 AI와 함께 개발하는 방식에 익숙해지려고 했다. 하지만 지금처럼 AI를 자주, 그리고 깊숙하게 사용하는 때는 없었던 것 같다.

지금 다니는 회사는 조직 차원에서도 AI 사용을 매우 강조하고 있고, 여러 종류의 AI 도구를 지원해준다. 그러다 보니 요즘의 나는 AI가 작성한 코드를 읽고, 이해하고, 프롬프트로 수정 요청을 하는 일을 계속 반복하고 있다. 내가 처음부터 끝까지 직접 코드를 작성하는 시간은 예전에 비해 확실히 줄어들었다.

그래서 요즘은 DDD도, TDD도, GDD도 아닌 ADD(AI Driven Development)를 하고 있는 것 같다는 생각이 든다. 가끔 인스타그램 릴스에서 “AI 이전의 개발자”와 “AI 이후의 개발자”를 비교하는 영상을 보면, 이후의 개발자는 AI가 코드를 써줄 때까지 기다리고 있는 모습으로 그려진다. 그걸 보면서 웃으면서도, 한편으로는 “어? 저거 난데?” 싶은 생각이 들었다.

실제로 AI는 내가 직접 짜는 것보다 훨씬 빠르게 코드를 작성하기도 하고, 때로는 더 나은 방법을 제안하기도 한다. 불과 반년 전까지만 해도 계속해서 수정 요청을 해야 하는 경우가 많았는데, 요즘은 그런 빈도도 꽤 줄었다. 어떤 날은 코드를 읽고 수정 요청만 하다가, 정작 내가 직접 한 줄도 작성하지 않는 날도 있다.

그럴 때면 한편으로는 불안해진다.
이렇게 하다 보면 나중에 직접 짜라고 했을 때 정말 잘 짤 수 있을까?
요즘은 간단한 작업조차 귀찮아서 AI에게 맡기곤 하는데, 이러다가 결국 내가 다 잊어버리는 건 아닐까 하는 생각도 든다.

하지만 또 생각해보면, 기술 혁명이 일어나는 과도기에는 늘 비슷한 걱정이 있었을 것이다. 컴퓨터가 처음 등장했을 때도, 계산기가 처음 보급되었을 때도 분명 사람들은 계산 능력이 떨어질까 걱정했을 것이다. 실제로 예전보다 암산이 느려졌을 수는 있어도, 그렇다고 계산 능력 자체가 완전히 사라진 것은 아니다. 필요하면 여전히 할 수 있다.

코딩도 비슷하지 않을까 싶다.
직접 코드를 빠르게 쳐내는 능력은 예전보다 조금 둔해질 수 있어도, 문제를 이해하고 구조를 파악하고 읽고 판단하는 능력까지 사라지는 것은 아닐 것이다. 오히려 중요한 것은 얼마나 빨리 코드를 타이핑하느냐보다, 무엇을 만들고 어떤 방식으로 검증할지를 판단하는 능력일지도 모른다.

그렇게 생각하다 보면 결국 이 변화는 받아들여야 하는 흐름이라는 생각이 든다. 사실상 AI가 완전히 없는 환경이 아니라면, 앞으로도 우리는 어디서든 AI와 함께 일하게 될 가능성이 높다. 자연재해로 데이터센터나 클라우드 시스템이 모두 멈추는 극단적인 상황이 아니라면 말이다.

요즘에는 글도 비슷하다.
대충 의미만 전달되도록 먼저 써놓고, AI로 교정하는 일이 정말 많아졌다. 거의 대부분 그렇다고 해도 과장이 아니다. 글쓰기 능력 역시 코딩과 비슷한 고민을 남긴다. 내가 직접 다듬는 힘이 줄어드는 건 아닐까 하는 생각. 하지만 이 역시 시대의 변화 속에서 자연스럽게 받아들여야 하는 부분일지도 모르겠다.

마치며

지난 4년 동안 두 번의 이직을 했고, 개발자로서의 환경도 많이 달라졌다.
함께 일하는 조직도 바뀌었고, 생활 방식도 바뀌었고, 일하는 도구 자체도 바뀌었다. 특히 2026년에 들어와서는 “개발을 한다”는 말의 의미가 예전과는 많이 달라졌다고 느낀다.

예전에는 내가 직접 얼마나 많이 구현하느냐가 더 중요하게 느껴졌다면, 지금은 AI와 함께 얼마나 잘 문제를 정의하고, 읽고, 판단하고, 수정해 나가느냐가 점점 더 중요해지고 있다.

아마도 앞으로의 개발자는, 코드를 잘 짜는 사람인 동시에 AI를 잘 활용하는 사람이어야 할 것이다.
나 역시 그 변화에 맞춰 조금씩 적응해 가는 중이다.

[python] Python의 비동기 동작과 event loop

9Jaeng — Sun, 15 Mar 2026 16:54:31 +0900

파이썬의 event loop에 대해 알아보자. Nodejs의 event loop 기반의 논블로킹 싱글 스레드 기반의 환경과 어떻게 다른 지도 간단하게 정리하였다

1. Python에서 비동기를 작성하는 방법(문법 레벨)

NodeJs나 Python이나 async await이라는 문법이 존재한다. 두 언어에서 각각 비동기 함수를 정의하고 실행하는 역할을 한다는 공통점이 있다. 문법은 같은데 무엇이 다를까?

일단 NodeJs는 non-blocking이 기본 실행 환경이고 Python은 기본적으로 synchronous 실행 모델 이라는 실행 철학에 차이가 있다.

1.1 async/ await 문법

python의 async/await은 구문은 파이썬 "언어 차원"에서 제공되는 문법이며(PEP492) 이를 기반으로 동시성 코드를 작성할 수 있도록 지원한다. 이를 지원하는 대표적인 라이브러리가 asyncio 모듈이다 Python의 asyncio 공식문서

async await은 python 3.5부터 도입되었다.

async
async def 를 사용하여 함수를 coroutine function(코루틴 함수)으로 정의한다. async def로 정의한 코루틴 함수를 실행하면 실제 실행이 즉시 호출되는 것이 아니라 coroutine object라는 것이 생성된다. 이 객체는 await 가능한 객체(awaitable)의 한 종류이다.

여기서 coroutine이란 실행 도중 await 지점에서 잠시 멈췄다가, event loop가 다른 작업을 처리한 뒤(event loop에 제어권을 넘기는 행위) 다시 이어서 실행될 수 있는 함수 실행 단위이다. 코루틴에 대해서는 다음 세션에서 조금 더 확인해 보자.

await

await 키워드(6.4. Await expression)는 awaitable 객체가 완료될 때까지 현재 coroutine의 실행을 일시 중단하며, coroutine function 내부에서만 사용할 수 있다.
await을 만나면 현재 실행 중인 coroutine은 중단되고, 실행 제어권이 event loop로 넘어간다. event loop는 실행 가능한 다른 작업을 스케줄링하여 실행한다. 이후 await 대상 작업이 완료되면, 중단되었던 coroutine은 다시 실행 가능한 상태가 되어 event loop에 의해 재개된다.

NodeJs와의 비교해 보자

NodeJs에서 async 키워드는 해당 함수가 Promise를 반환하는 비동기 함수임을 의미한다. await 키워드는 Promise가 resolve 될 때까지 현재 async 함수의 실행을 일시 중단한다. 문법적인 형태는 매우 유사하다.

하지만 실행 모델에는 차이가 있다.

NodeJs에서는 async 함수가 호출되는 순간 Promise가 생성되고 함수 실행이 바로 시작된다(eager execution) 된다. 즉, 함수 호출 자체가 실행의 시작이다.

반면 Python에서는 coroutine 함수를 호출해도 실제 실행은 바로 시작되지 않는다. 대신 couroutine object만 생성될 뿐이며, 이 객체는 await 되거나 event loop에 의해 스케줄링되기 전까지는 실행되지 않는다.

아래 예시 코드를 확인해 보자

NodeJs

async function hello() {
  console.log("start"); // 함수 호출 즉시 실행됨
  await Promise.resolve();
  console.log("end");
}

hello(); // 호출하는 순간 "start"가 바로 출력됨
// await은 실행을 시작하는 역할이 아니라 Promise 결과를 기다리는 역할

NodeJs에서는 async 함수를 호출하는 순간 함수 body가 실행되며, await을 만나면 Promise가 resolve 될 때까지 실행이 잠시 중단된다.

Python

import asyncio

async def hello():
    print("start")  # 아직 실행되지 않음
    await asyncio.sleep(0)
    print("end")

coro = hello()  # hello() 호출 시 coroutine object만 생성된다

# 실제 실행은 event loop에서 시작됨
asyncio.run(hello())

Python에서는 coroutine 함수 호출 시 실행이 시작되는 것이 아니라 coroutine object만 생성된다.
실제 실행은 await 하거나 asyncio.create_task() 등을 통해 event loop에 등록될 때 시작된다.

1.2 coroutine은?

coroutine(코루틴)은 실행 도중 중단되었다가 이후 다시 실행될 수 있는 함수 실행 단위이다.

일반적인 함수는 호출되면 끝까지 실행되지만, coroutine은 await 지점에서 실행을 잠시 멈추고 event loop에게 제어권을 넘길 수 있다.

coroutine의 특성을 정리해 보면 아래와 같다

1. coroutine은 "중단 가능한 함수"이다.

2. coroutine function은 호출하면 바로 실행되지 않는다.

3. 호출 결과로 coroutine object가 생성된다.

4. 이 coroutine object는 await 되거나 event loop에 의해 스케줄링될 때 실행이 시작된다.

async def fetch_data():
    print("start")
    return "data"

coro = fetch_data()  # 아직 실행되지 않음 (coroutine object 생성)

await coro           # 이 시점에 실제 실행 시작

즉, coroutine은 "실행 가능한 작업을 표현하는 객체"에 가깝다.

1.3 coroutine 실행 등록 (Task, gather)

앞서 설명한 것처럼 Python의 coroutine은 함수를 호출한다고 바로 실행되지 않는다. coroutine 함수 호출 시 coroutine object만 생성되며, 실제 실행을 위해서는 event loop에 의해 스케줄링되어야 한다.

asyncio.run()

asyncio.run()은 coorutine을 실행하기 위해 가장 기본적인 진입점이다. 내부적으로 event loop를 생성하고 coroutine을 실행한 뒤 event loop를 종료한다.

import asyncio

async def hello():
    print("start")
    await asyncio.sleep(1)
    print("end")

asyncio.run(hello())

위의 코드에서 hello()는 coorutine object를 생성하고, asyncio.run()이 이를 event loop에서 실행하도록 한다.

일반적으로 Python asyncio 프로그램의 최상위 실행 지점에서 사용된다.

asyncio.create_task()

create_task()는 coroutine을 Task로 감싸고 event loop에 등록하여 실행을 시작하게 한다.

Task는 event loop가 스케줄링할 수 있는 실행 단위이다.

import asyncio

async def work():
    print("start")
    await asyncio.sleep(5)
    print("end")

async def main():
    task = asyncio.create_task(work()) # coroutine을 task로 만들어 event loop에 등록
    await task

asyncio.run(main())

create_task()를 사용하면 coroutine이 event loop의 스케줄링 대상이 된다.

asyncio.gather

gather를 사용하여 여러 coroutine을 동시에 실행(concurrent execution) 하고 결과를 모으기 위해 사용할 수 있다.

"""
여러 coroutine을 동시에 실행하여 결과를 모으기 위해 aynsio.gather()를 사용할 수 있다.
work(1),work(2),work(3)을 동시에 실행하고 모든 작업이 완료되면 리스트로 반환
"""

import asyncio

async def work(n):
    await asyncio.sleep(2)
    return n

async def main():
    results = await asyncio.gather(
        work(1),
        work(2),
        work(3)
    )
    print(results)

asyncio.run(main())

즉, Python에서는 아래와 같은 흐름을 가져간다.

async def → coroutine 생성
asyncio.run → event loop 시작
create_task / gather → coroutine을 실행 대상으로 등록
event loop → scheduling

cooperative scheduling

python의 asyncio는 cooperative scheduling 방식으로 동작한다.

작업이 강제로 중단되는 것이 아니라 coroutine이 await 지점에서 스스로 제어권을 event loop에 반환한다

실행의 흐름은 아래와 같다

coroutine 실행
    ↓
await 만남
    ↓
event loop에게 제어권 반환
    ↓
다른 coroutine 실행
    ↓
await 작업 완료
    ↓
다시 실행(resume)

이 방식 덕분에 하나의 thread에서도 여러 작업을 번갈아서 실행하면서 I/O작업을 효율적으로 처리할 수 있다.

이런 동작의 내부적인 흐름은 아래에서 조금 더 자세히 정리하였다.

2. Python 비동기의 내부 동작 (런타임 레벨)

앞에서는 Python에서 비동기 코드를 작성하는 문법적인 방법을 다뤘다. 이번에는 실제고 asyncio가 런타임에서 어떻게 동작하는지 간단히 알아보자.

이벤트 루프(Event Loop)란?

event loop는 비동기 작업을 관리하고 실행 순서를 조정하는 스케줄러이다.

(참고로 아래에 있는 설명은 단순화한 버전이다)

event loop는 개념적으로 while loop 형태의 스케줄러라고 볼 수 있다. while loop를 돌면서 task를 실행한다.

while tasks:
    for task in tasks:
        execute(task)

Task queue(Ready Queue)

task queue는 실행될 준비가 된 task들이 들어있다. 이 task들은 실행될 준비가 되면 이 queue에 추가된다.

https://python.plainenglish.io/build-your-own-event-loop-from-scratch-in-python-da77ef1e3c39

Sleeping queue(scheduled heap)

https://python.plainenglish.io/build-your-own-event-loop-from-scratch-in-python-da77ef1e3c39

timer가 있는 작업이 들어가는 queue도 있다. event loop가 돌 때마다 deadline이 완료된 작업이 있는지 확인한다.

만약 타이머가 다 된 작업이 있다면 ready queue로 옮긴다.

while ready or sleeping:
    if not ready:
       deadline, task = sleeping.pop()
       delta = deadline - time.time()
       if delta < 0 # check if deadline is over
	       ready.append(task)
    
    # execute task
    while ready:
        task = ready.popleft()
        task()

Selector (I/O Multiplexing)

실제 비동기 프로그햄에서는 네트워크 요청, 파일 읽기 등의 I/O작업이 훨씬 많이 발생한다.

이런 I/O작업을 처리하기 위해 asyncio는 I/O multiplexing을 사용한다.

일반적인 blocking I/O 코드를 생각해 보자

data = socket.recv(1024)

이 코드는 데이터가 도착할 때까지 프로그램 실행을 멈춘다. 즉, blocking I/O이다.

이를 해결하기 위해 asyncio는 non-blocking socker과 selctor를 사용한다.

selector의 역할은 특정 socket에 읽기(read) 또는 쓰기(write) 이벤트가 발생하면 이를 감지하는 것이다. 내부적으로는 epoll, kqueue, select 등의 OS 기능을 사용한다.

Pythob에는 이를 selctors 모듈이 제공한다.

import selectors

selector = selectors.DefaultSelector()
selector.register(sock, selectors.EVENT_READ)

event loop는 내부적으로 selctor를 사용하여 I/O 이벤트를 감지한다. 즉, I/O 이벤트가 발생하면 해당 coroutine이 다시 실행될 준비 상태가 된다 (ready queye로 등록)

https://python.plainenglish.io/build-your-own-event-loop-from-scratch-in-python-da77ef1e3c39

asyncio event loop 내부 흐름

https://python.plainenglish.io/build-your-own-event-loop-from-scratch-in-python-da77ef1e3c39

간단하게 정리하자면 event loop는 timer, I/O 이벤트, 실행 가능한 task를 반복적으로 확인하면서 coroutine 실행을 스케줄링한다

while True:

    # timer 확인
    move_scheduled_tasks_to_ready()

    # I/O 이벤트 확인
    events = selector.select()

    # ready queue 실행
    while ready:
        task = ready.popleft()
        task.run()

vent loop는 이 구조들을 계속 확인하면서 coroutine 실행을 조정한다.

3. 마무리

Python의 비동기 모델은 event loop, task scheduling, selector 기반 I/O 이벤트 감지가 동작하면서 구현된다.

coroutine
↓
Task
↓
event loop
↓
ready queue / scheduled queue
↓
selector (I/O 이벤트 감지)

event loop는 이러한 구조를 반복적으로 확인하면서 실행 가능한 coroutine을 스케줄링하고, I/O 이벤트가 발생하면 해당 coroutine을 다시 실행한다.

이러한 방식 덕분에 Python에서는 NodeJs와 같이 하나의 thread에서도 여러 I/O 작업을 효율적으로 처리할 수 있는 비동기 프로그래밍 모델을 구현할 수 있다.

[typescript] Awaited type에 대해 알아보자

9Jaeng — Sat, 17 Jan 2026 22:03:52 +0900

최근에 사용하게 된 Awaited type에 대해 알아보고자 한다.

공식문서 링크 : https://www.typescriptlang.org/docs/handbook/utility-types.html#awaitedtype

Documentation - Utility Types

Types which are globally included in TypeScript

www.typescriptlang.org

Awaited type이란?

Awaited type은 await 했을 때 실제로 얻는 값의 타입을 의미한다. 이 타입은 typescript 4.5 버전에 새로 추가된 타입이다.

그럼 4.5 버전 이전에는 await 했을 때 실제 얻는 값의 타입을 확인할 수 없었을까? 한다면 그것은 아니다. 아래의 예시와 같이 4.5 이후나 이전에도 중첩된 Promise까지 실제 resolve 되는 결괏값 추론은 정상적으로 되었다

type E = Promise<number>;
type F = Promise<Promise<number>>;
type G = Promise<Promise<Promise<number>>>;
type H = Promise<PromiseLike<Promise<number>>>;

declare const e: E;
declare const f: F;
declare const g: G;
declare const h: H;

async function testFunc(){
	const r1 = await e; // type 추론 number
	const r2 = await f; // type 추론 number
	const r3 = await g; // type 추론 number
	const r4 = await h; // type 추론 number
}

그럼 이 타입이 추가된 이유는 무엇일까?

이 타입이 추가되었던 4.5 버전의 릴리즈 노트를 확인해 보면 이 타입이 도입된 배경을 알 수 있는데, Promise를 재귀적으로 완전히 해제(unwrapping)했을 때 실제로 남는 타입을 제대로 추론할 수 있도록 도입된 타입이다.

릴리즈 노트의 예시를 4.4 버전과 4.5 버전에서 각각 확인을 해보면 4.4 버전은 아래와 같은 type errror를 확인할 수 있고 4.5 버전은 result의 타입 추론을 확인할 수 있다.

릴리즈 노트 예시

declare function MaybePromise<T>(
  value: T
): T | Promise<T> | PromiseLike<T>;

async function test(): Promise<[number, number]> {
  const result = await Promise.all([
    MaybePromise(1),
    MaybePromise(2),
  ]);

  return result;
}

4.4 버전

Type '[number | Promise<1>, number | Promise<2>]' is not assignable to type '[number, number]'.
  Type 'number | Promise<1>' is not assignable to type 'number'.
    Type 'Promise<1>' is not assignable to type 'number'.(2322)
const result: [number | Promise<1>, number | Promise<2>]

4.5 버전

const result: [number, number]

위와 같은 에러가 발생한 이유는 typescript 4.5 이전에는 Promise.all 타입 정의 자체가 튜플 내부 요소의 Promise 해제를 재귀적으로 표현하지 못했기 때문이다. MaybePromise <T>는 런타임에서는 결국 T로 resolve 되지만, 당시의 TypeScript 타입 시스템은 Promise.all이 반환하는 튜플 구조의 객 요소까지 Promise를 해제하지 못했다. 그 결과 [number, number]가 아닌 [number | Promise<number>, number | Promise<number>] 로 추론되어 타입 에러가 발생하였다.

typeScript 4.5에서는 Awaited<T> 타입이 도입되면서 “Promise를 완전히 해제했을 때의 최종 타입”을 재귀적으로 추론할 수 있게 되었고, 이를 기반으로 Promise.all, Promise.race 등의 타입 정의가 같이 개선되었다. 관련 PR

즉, 이 타입은 이전 typescript에서 추론하지 못했던 복잡한 Promise 구조를 재귀적으로 unwrapping 하여 최종적으로 얻는 값을 추론하기 위해 도입하였다.

언제 어떻게 사용하는가?

내가 사용하는 방식은 함수의 return type을 사용해야 할 때 이다.

예를 들면 아래와 같이 함수가 있다고 했을 때

async function fetchUser() {
  return { id: 1, name: "jaeng" };
}

// 다른 곳에서 이 함수의 결과 타입이 필요
type User = ReturnType<typeof fetchUser>;
// ❌ 추론 타입 Promise<{ id: number; name: string }>

이렇게 하게 되면 추론 타입은 Promise가 된다. 내가 원하던 추론 타입은 { id: number; name: string }이다. 이럴 때 Awaited를 사용하면 원하는 타입 추론이 가능하다

type User = Awaited<ReturnType<typeof fetchUser>>;
// { id: number; name: string }

특히 TypeORM을 사용할 때, 레포지토리의 쿼리 결과 타입을 서비스 레이어에서 재사용하되 엔티티를 그대로 API DTO로 노출하지 않기 위해 레포지토리 반환 타입을 서비스 내부 타입으로 정의할 때에도 Awaited<ReturnType<…>>를 유용하게 사용할 수 있다.

이와 같이 함수의 반환타입을 정의할 때에도 사용할 수 있고 DTO 등을 만들 때에도 사용할 수도 있겠다.

여기서 ReturnType이란, 함수 선언에 명시된 반환 타입을 가져온다. 링크된 공식문서의 예제를 확인해 보자..!

[NestJS] Monorepo로 구축하기 2 : 모노레포 구축 with NestJs 공식문서

9Jaeng — Mon, 1 Sep 2025 01:03:58 +0900

이전 포스팅에서는 [[NestJS] Monorepo로 구축하기 1 : pnpm workspace] pnpm에 대하 알아보았다.

이번 포스팅에서는 공식문서를 참고하여 간단한 모노레포를 구성해 보고 정리해 보았다

참고한 공식문서 : https://docs.nestjs.com/cli/monorepo

Documentation | NestJS - A progressive Node.js framework

Nest is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, is built with TypeScript and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (Functional Rea

docs.nestjs.com

NestJs에서 모노레포를 만드는 것은 어렵지 않다. Monorepo로 만들기 전에 먼저 standard nest js 프로젝트를 만들어주어야 한다

nest project 생성

nest new monorepo-project

# pnpm을 사용할 것이기 때문에 pnpm선택

해당 프로젝트로 이동해서 프로젝트를 확인해보자

├── eslint.config.mjs
├── nest-cli.json
├── package.json
├── pnpm-lock.yaml
├── src
│   ├── app.controller.spec.ts
│   ├── app.controller.ts
│   ├── app.module.ts
│   ├── app.service.ts
│   └── main.ts
├── test
│   ├── app.e2e-spec.ts
│   └── jest-e2e.json
├── tsconfig.build.json
└── tsconfig.json

기본적인 Standard Mode의 nest js 프로젝트 구조이다. 앱이 하나만 존재한다.

monorepo로 구성할 때와 tsconfig, nest-cli가 조금 다른데, 그것은 아래에서 설명하겠다.

Workspace

NestJs의 monorepo는 workspace라는 개념이 있다. workspace는 여러 앱을 관리하는 하나의 최상위 컨테이너 개념이다.

이 workspace의 구조는 아래와 같다

- application : 실행 가능한 완전한 nestjs앱. main.ts를 갖는다

- library : 단독으로 실행 불가능한 공유 라이브러리들이 이곳에서 관리된다. main.ts는 없고 index.ts를 갖는다

- 그리고 공통 설정 파일인 package.json, tsconfig.json, nest-cli.json 등을 갖는다

이제 여기에 우리가 모노레포 구조로 만들 application을 추가해 보자

nest generate app admin-app

nest generate app cyber-edue

그리고 라이브러리도 추가해 보자.

auth라는 공통 라이브러리를 추가해 보았다.

 nest g library auth

library를 생성하면 prefix를 설정하라는 메시지가 뜬다. 기본은 app인데, 나는 @lib로 하였다.

이 prefix(alias)는 나중에 다른 application에서 lib을 import 할 때 @lib/auth로 import할 수 있게 해 준다

nest cli를 사용하여 구축하면 자동으로 프로젝트 구조를 아래와 같이 만들어준다

├── apps
│   ├── admin-app
│   │   ├── src
│   │   │   ├── admin-app.controller.spec.ts
│   │   │   ├── admin-app.controller.ts
│   │   │   ├── admin-app.module.ts
│   │   │   ├── admin-app.service.ts
│   │   │   └── main.ts
│   │   ├── test
│   │   │   ├── app.e2e-spec.ts
│   │   │   └── jest-e2e.json
│   │   └── tsconfig.app.json
│   ├── cyber-edue
│   │   ├── src
│   │   │   ├── cyber-edue.controller.spec.ts
│   │   │   ├── cyber-edue.controller.ts
│   │   │   ├── cyber-edue.module.ts
│   │   │   ├── cyber-edue.service.ts
│   │   │   └── main.ts
│   │   ├── test
│   │   │   ├── app.e2e-spec.ts
│   │   │   └── jest-e2e.json
│   │   └── tsconfig.app.json
│   └── monorepo-project
│       ├── src
│       │   ├── app.controller.spec.ts
│       │   ├── app.controller.ts
│       │   ├── app.module.ts
│       │   ├── app.service.ts
│       │   └── main.ts
│       ├── test
│       │   ├── app.e2e-spec.ts
│       │   └── jest-e2e.json
│       └── tsconfig.app.json
├── eslint.config.mjs
├── libs
│   └── auth
│       ├── src
│       │   ├── auth.module.ts
│       │   ├── auth.service.spec.ts
│       │   ├── auth.service.ts
│       │   └── index.ts
│       └── tsconfig.lib.json
├── nest-cli.json
├── package.json
├── pnpm-lock.yaml
├── tsconfig.build.json
└── tsconfig.json

여러 프로젝트가 하나의 레포 안에서 구성된 것을 확인할 수 있다.

위에서 Standard Mode의 설정 파일의 설정이 조금 다르다고 하였다. 무엇이 다른지 확인해 보자

프로젝트를 보면 여러 설정파일이 있다. 컴파일 옵션, 빌드 옵션 등을 설정해 주는 tsconfig.json과 nestJs 프로젝트의 프로젝트 구성, 빌드, 배포에 필요한 metadata를 보관하는 nest-cli.json 이 있다

[tsconfig.json]

- Standard Mode

{
  "compilerOptions": {
    "module": "commonjs",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "target": "ES2023",
    "sourceMap": true,
    "outDir": "./dist",
    "baseUrl": "./",
    "incremental": true,
    "skipLibCheck": true,
    "strictNullChecks": true,
    "forceConsistentCasingInFileNames": true,
    "noImplicitAny": false,
    "strictBindCallApply": false,
    "noFallthroughCasesInSwitch": false
  }
}

- Monorepo Mode

{
  "compilerOptions": {
    "module": "commonjs",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "target": "ES2023",
    "sourceMap": true,
    "outDir": "./dist",
    "baseUrl": "./",  // 루트를 기준으로 설정
    "incremental": true,
    "skipLibCheck": true,
    "strictNullChecks": true,
    "forceConsistentCasingInFileNames": true,
    "noImplicitAny": false,
    "strictBindCallApply": false,
    "noFallthroughCasesInSwitch": false,
    "paths": {      // ---> 이게 추가됨
      "@lib/auth": [  // 정확한 경로 매핑
        "libs/auth/src"
      ],
      "@lib/auth/*": [ // 하위 파일들도 매핑
        "libs/auth/src/*"
      ]
    }
  }
}

monorepo의 paths 옵션이 추가된 것을 볼 수 있다. (https://www.typescriptlang.org/tsconfig/#paths)

path는 lib를 생선 하면서 prefix를 설정해 주었을 때 tsconfig에 자동으로 설정되는 옵션이다. paths 옵션을 사용하여 @lib/auth로 libs/auth/src를 import 하도록 alias를 추가해 준다. baseUrl이 있다면 baseUrl을 기준으로, 없다면 해당 taconfig가 있는 경로를 기준으로 조회 경로를 매핑한다.

예를 들면 아래와 같이 경로를 깔끔하게 보이게 할 수 있고 공유 프로젝트임을 확실히 할 수 있다

// 길고 상대경로 대신
import { AuthService } from '../../../libs/auth/src/auth.service';

// 깔끔한 alias 사용
import { AuthService } from '@lib/auth';

[nest-cli.json]

- Standard Mode

{
  "$schema": "https://json.schemastore.org/nest-cli",
  "collection": "@nestjs/schematics",
  "sourceRoot": "src",
  "compilerOptions": {
    "deleteOutDir": true
  }
  // projects section 없음 ← 단일 앱이므로 불필요
}

- Monorepo Mode

{
  "$schema": "https://json.schemastore.org/nest-cli",
  "collection": "@nestjs/schematics",
  "sourceRoot": "apps/monorepo-project/src",
  "compilerOptions": {
    "deleteOutDir": true,
    "webpack": true,
    "tsConfigPath": "apps/monorepo-project/tsconfig.app.json"
  },
  "monorepo": true,
  "root": "apps/monorepo-project",
  "projects": { // ← 여기서 각 프로젝트 메타데이터 정의
    "admin-app": {
      "type": "application",
      "root": "apps/admin-app",
      "entryFile": "main",
      "sourceRoot": "apps/admin-app/src",
      "compilerOptions": {
        "tsConfigPath": "apps/admin-app/tsconfig.app.json"
      }
    },
    "auth": {
      "type": "library",
      "root": "libs/auth",
      "entryFile": "index",
      "sourceRoot": "libs/auth/src",
      "compilerOptions": {
        "tsConfigPath": "libs/auth/tsconfig.lib.json"
      }
    },
    "cyber-edue": {
      "type": "application",
      "root": "apps/cyber-edue",
      "entryFile": "main",
      "sourceRoot": "apps/cyber-edue/src",
      "compilerOptions": {
        "tsConfigPath": "apps/cyber-edue/tsconfig.app.json"
      }
    },
    "monorepo-project": {
      "type": "application",
      "root": "apps/monorepo-project",
      "entryFile": "main",
      "sourceRoot": "apps/monorepo-project/src",
      "compilerOptions": {
        "tsConfigPath": "apps/monorepo-project/tsconfig.app.json"
      }
    }
  }
}

이제 nest-cli.json을 비교해 보자 뭔가 많이 바뀐 것이 보인다.

nest-cli.json의 구성은 global section, 각 project의 metadata를 정의하는 projects section 두 가지로 구성된다.

global section에서 차이를 보면 sourceRoot가 다르고 compile option 외에 여러 옵션이 추가되었다. 하나씩 간단하게 살펴보자

sourceRoot는 standard mode에서는 root source code를 가리키고, monorepo 구조에서는 default project를 가리킨다.

nest build, nest start 등이 project name 없이 호출될 때 실행 할 default project를 명시하는 것이다. 필요 없다면 제거해도 된다. 대신 package.json에 nest build 프로젝트 네임을 명실해 주어야 한다

# 기본 설정이 있을 때
nest start  # → sourceRoot의 프로젝트 실행

# 기본 설정 제거 후
nest start  # → 에러! 프로젝트명 필요

compilerOptions에서는 webpack, tsConfigPath 옵션이 추가되었다. webpack은 compiler를 webpack으로 사용한다는 의미이다. false이면 tsc를 기본으로 사용한다. 이 두 컴파일러의 차이는 아래에 간단하게 정리하였다.

tsConfigPath 옵션은 sourceRoot와 비슷하게 monorepo only, nest build나 nest start 등이 project name 없이 노출될 때 가리키는 taconfig.json의 경로를 가리킨다. 이것 또한 필요 없다면 제거해도 된다. 대신 package.json에 nest build 프로젝트 네임을 명실해 주어야 한다

root도 monorepo인 경우 사용되는 옵션이며 default project의 root project를 가리킨다.

webpack vs tsc
- tsc는 순수 typescript compiler로 ts를 js로 컴파일한다
- 파일 구조가 그대로 유지된다
- 모듈 해석이 단순함
- tsc는 각 파일을 독립적으로 컴파일하므로 패키지 간 의존성 추적이 어렵다
- webpack은 번들링과 complie을 동시에 수행한다
- 복잡한 모듈 해석(alias, path mapping 등)
- HMR(Hot Module Replacement) 지원
- @libs/common 등 복잡한 import문을 처리하는데 필요하다
- 전체 dependency graph를 분석해서 필요한 모든 모듈을 포함한다

monorepo인 경우 project section을 갖는다. (참고로 각 옵션이 의미하는 바는 이 NestJs 공식 문서를 참고하자) 각 프로젝트마다 위에서 해주었던 옵션들을 설정해 줄 수 있다.

추가적으로 package.json도 확인해 보면 아래 jest 설정 부분이 다른 것을 볼 수 있다

// Standard Mode
"jest": {
  "rootDir": "src",                    // ← src만 테스트 대상
  "coverageDirectory": "../coverage"   // ← 상대 경로
}

// Monorepo Mode

"jest": {
  "rootDir": ".",                      // ← 프로젝트 전체 루트
  "coverageDirectory": "./coverage",   // ← 절대 경로
  "roots": [                           // ← 테스트 탐색 범위
    "<rootDir>/apps/",
    "<rootDir>/libs/"
  ],
  "moduleNameMapper": {                // ← alias 매핑
    "^@lib/auth(|/.*)$": "<rootDir>/libs/auth/src/$1"
  }
}

만약 수동으로 alias를 변경해야 한다면 package.json의 jest 설정도 변경해 주어야 한다

// tsconfig.json
"paths": {
  "@auth": ["libs/auth/src"],
  "@auth/*": ["libs/auth/src/*"]
}

// package.json의 moduleNameMapper
"moduleNameMapper": {
  "^@auth(|/.*)$": "<rootDir>/libs/auth/src/$1"
}

library를 application에 적용

위에서 만든 공통 라이브러리를 각 application에서 사용하는 방법은 이 공식문서에 잘 설명되어있다. 여기서는 간략하게만 정리해보겠다.

nestjs의 다른 모듈을 사용하는 것과 다를 것 없이 간단하다.

library를 사용하고자 하는 application의 module.ts에서 import해주면 된다. 만약 그 application에서 전역적으로 사용하고자 한다면 root module인 app.module.ts 에서 Import를 해주면 된다.

import { Module } from '@nestjs/common';
import { AdminAppController } from './admin-app.controller';
import { AdminAppService } from './admin-app.service';
import { AuthModule } from '@lib/auth';

@Module({
  imports: [AuthModule],
  controllers: [AdminAppController],
  providers: [AdminAppService],
})
export class AdminAppModule {}

이를 잘 보면 @lib/auth로 import가 되었다. nestjs는 tsconfig 를 통해 path mapping을 한다.

예전에 각 application의 tsconfig에 path alias를 설정해주었는데 path mapping에 대해 잘 알아보지 않고 했다가 Import가 계속 깨지는 이슈가 있었다. 조심해서? 사용하자

 "paths": {
      "@lib/auth": [
        "libs/auth/src"
      ],
      "@lib/auth/*": [
        "libs/auth/src/*"
      ]
    }

library 적용은 간단하고 직관적이고 쉽다(path mapping을 꼬이지 않게 잘 해준다면)

이렇게 Import를 하고 admin-app을 빌드 하면 nestJs는모듈 해석을 자동으로 처리하고 import를 한 AuthModule코드까지 빌드 산출문레 포함한다.

만약 모노레포의 기본 컴파일러서 webpack이면 단일 번들로(하나의 js로) 묶고, tsc라면 파일 단위로 출력된다.

libs/auth자체를 별도 패키지처럼 별도로 빌드를 해주지는 않지만 앱 번들에 포함되기 때문에 배포가 가능하다

불필요 프로젝트 제거

현재 프로젝트 구조를 보면, 프로젝트 이름인 monorepo-project가 앱으로 구축되어 있다. 아마 모노레포 구조로 만들면서 생성된 것 같다.

프로젝트 이름을 갖는 app을 필요 없어서 제거하였다. 그럼, 위에서 설정되어 있던 global 설정을 변경해 주어야 한다 제거해도 되고, default로 실행할 app으로 대체할 수 있다

마치며

처음에는 이렇게 직접 공식문서를 보고 모노레포로 구축을 하였다. 그런데 운영을 하다보니 빌드 순서라던가, 소나큐브, 테스트 등을 추가하면서 빌드가 느려지는 현상들에 불편함을 느끼게 되었고 "터보레포" 라는 모노레포 관리 도구를 추가하게 되었다.

다음 포스팅은 모노레포에 대해 간단하게 소개하고 적용한 경험에 대해 정리해보겠다.

[CONFERENCE] 2025-TOSS-MAKERS 정리

9Jaeng — Sun, 3 Aug 2025 23:16:55 +0900

25년 토스 메이커스 컨퍼런스를 다녀왔다. 우리 팀에서 운 좋게 두 명이 추첨이 되어 다녀오게 되었다.

총 3일간 진행을 하였고 day1은 product day, day2는 design day day3는 engineering day이며 나는 day3에 참석하였다.

다른 회사에서 하는 컨퍼런스는 2023 우아콘을 다음으로 두 번째 참석해 본다. 이번 컨퍼런스를 통해 토스의 개발 파트는 어떤 문제를 갖고 있는지, 이 문제를 해결하기 위해 어떻게 하는지 살짝 볼 수 있었다.

내가 들은 세션은 아래와 같다

1. 20년 레거시를 넘어 미래를 준비하는 시스템 만들기

2. 현장 결제 서비스의 분산 트랜잭션 관리학 개론

3. 수천개의 API/배치 서버를 하나의 설정 체계로 관리하기

4. 가맹점은 변함없이 결제창 시스템 전면 재작성하기

5. LLM내제화 전략

6. 확장성과 회복 탄력성을 갖춘 결제 시스템 만들기

7. 레거시 정산 개편기 : 신규 시스템 투입 여정부터 대규모 배치 운영 노하우까지

세션 별 간략 정리

이번 토스 컨퍼런스는 우아콘에 비해 더욱 정신이 없었던 것 같다. 우아콘은 점심시간을 별도로 줬었는데 토스는 별도 점심시간을 위한 시간도 없었고 컨퍼런스를 들으랴 정리하랴 조금 정신이 없었다. 그래도 조금이라도 적었던 것을 정리해 보았다

1. 20년 레거시를 넘어 미래를 준비하는 시스템 만들기

이 세션은 20년이나 된 서비스를 인수받고 복잡한 구조를 개선했던 경험, 어떤 문제가 있었고 어떻게 해결했는지에 대한 내용을 다룬다.

문제점

토스 페이먼츠가 2020.08월에 20년이나 된 서비스를 인수받았을 때 아래와 같은 문제들이 있었다

수백 대의 노후화 서버
소스코드 관리가 안되어있는 상태로, 어떤 코드가 최신 코드인지 불분명
인프라 자동화 도구 미존재로 수백 대의 서버 관리를 수작업으로 진행
네트워크 라우팅 구성 개선 필요
- 각 서버마다 라우팅 구성을 갖고 있어서 서버마다 구성을 해주어야 함
- 서버마다 구성이 다른 경우가 발생함

이런 경우 뛰어난 사람이 입사해도 어려움

새로 합류하는 팀원이 비즈니스 임팩트를 낼 수 있도록 구조 개선이 필요했음

해결

인프라 자동화를 위한 AWS 사용 및 devops 팀을 구성하여 인프라 관리를 조직화
문제를 단계적인 해결
- github 도입을 통한 소스코드 관리
  - 하지만 어떤 코드가 최신인지 알 수 없는 상황에서 깃헙을 바로 사용하는 것이 어려웠고 한다. 이를 해결하기 위해 현재 배포되어 있는 코드가 최신코드라고 인식을 하고 disassemble 된 코드를 찾아서 배포를 하는 방식으로 해결

빌드 표준화 및 MSA 아키텍처로 전환 쿠버네티스 도입
- 결제서비스는 결제서버와 어드민 두 개면 되는 것 아닌가? 싶을 수 있지만, 150개의 service가 있었고 개발 단계별 배포 환경 없었기 때문에 MSA의 전환이 필요했음 이를 통한 고가용성 인프라를 구성
자동화된 코드 업데이트 체계 확보
- 코드 변경을 감지하여 자동으로 pr을 만들어주도록 자동화
서비스안정성 성능 고도화
- 안정적인 변경을 위한 카나리 배포 방식을 사용하였다.
- 1% 단위로 트래픽 보내도록 하였고 특정 조건에 따라 점차적으로 %를 늘려가는 방식으로 진행

라스트마일 성능을 높이기 위한 HTTP3, TLS3
멀티 플랙싱, 멀티 캐싱을 사용한 성능 최적화
보안강화
1. AI를 활용한 보안 이벤트 분석
2. 민감한 API E2E 암호화 및 HTTP3, TLS1.3
3. 컨테이너 런타임 보안

- 약 1분 걸리던 쿼리 결과 -> 1초 이내에 응답

- 최근 3개월 데이터 조회 -> 최근 5년 이내의 데이터 조회 가능

이런 대규모 애플리케이션 구조개선을 통한 결과는 위와 같은 결과를 만들어내었다.

아직 경력혐이 많은 것은 아니지만, 지금까지 경험을 해본 바로는 이런 대규모 애플리케이션 개선과 운영을 같이 진행한다는 것은 쉽지 않다는 것을 안다. 아무래도 규모가 있는 곳이라서 가능했던 것일지도 모르겠다

2. 현장 결제 서비스의 분산 트랜잭션 관리학 개론

이 세션은 토스 현장결제 서비스에서 어떻게 분산 트랜잭션을 관리하는지 소개한다.

분산 환경에서 일관성과 정합성을 관리하는 방법에 대해 다룬다. 2 Phase commit과 같은 방식이 아닌 새로운 방식을 소개하였다.

해당 세션은 문제를 정의하고 이를 해결한 방안에 집중한 발표로 진행되었다.

문제 해결을 위해 필요한 세 가지로 정의한다

1. 복잡한 상황을 나타낼 수 있는 표현모델 : 트리구조

첫 번째, 복잡한 상황을 트리구조의 표현모델로 표현한다(오프라인 간편 결제 서비스)

트랜잭션의 결과를 성공과 실패 두 가지로만 분류할 수 있을까?

read timeout , network유실 등 정의되지 않은 에러도 존재하기 때문에성공, 실패, 알 수 없음으로 분류해야 한다.

전통적인 Success/Fail로는 복잡성을 표현 할 수 없다.

일관성을 누가 어떻게 보장할까? : 각 노드가 보장 정책을 갖는다

transaction이 늘어나면 분기는 더 많아진다.

예를 들면, 트랜젝션이 한 개라면 성공/실패/알 수 없음 3가지 조합이 되겠고 transaction이 두 개 라면 3x3 = 9개가 된다.

트랜젝션 간 불일치도 문제가 된다. 위의 그림에서 본다면(내가 잘 이해했는지는 모르겠지만), 결제 승인이 났는데 토스 할인은 success이고 토스 포인트 사용은 fail이다. 토스 머니는 사용했는지 unknown이다.

토스 머니 UNKNOWN은 어떻게 처리해야 할까?
포인트 사용 FAIL은 어떻게 처리해야 할까?
누가 이런 결정을 내려야 할까?

각 노드는 보정 정챙을 자체적으로 갖도록 해야 한다

각 노드는 재시도와 보정 정책을 자체적으로 갖고 있어야 한다.

일관성을 언제까지 보장해양할까? :ASAP 하지만 최종적 일관성 추구

api 트랜젝션 안에서 일관성을 보장할 수 있을까?

분산환경에서는 어렵다. 최종 일관성을 추구해야 한다

실시간 결제 상황에서 모든 트랜젝션이 완벽하게 동기화될 때까지 기다릴 수 없다.

최종 일관성을 각 서비스가 테이블로 관리

(이해한 것이 맞는지 확실하지 않지만) 결제_승인_테이블, 토스_할인_테이블 등 각각의 서비스가 자신만의 트랜젝션 로그 테이블을 보유하는 것으로 이해했다.

이렇게 각자가 일관성을 관리하며 각자의 보정 정책을 갖는다.

모든 서비스는 추상화된 노드이다

- 어딘가 하위 트랙젠션이 있고 추상화된 제3의 노드가 트랜젝션처럼 호출된다

결제 서비스를 깊게(?) 해본 적은 없었기 때문에 이번 세션이 상당히 흥미로웠다. 결제라는 도메인에서 트랜젝션의 일관성은 더욱 중요한 만큼 얼마나 많은 고민이 있었는지 느낄 수 있었다.

3.수천 개의 API/배치 서버를 하나의 설정 체계로 관리하기

단순 복사 붙여 넣기가 아닌 한 번의 클릭으로 개발자의 인프라 접근성을 높인 과정에 대한 발표 세션

핵심 문제: 설정 관리의 복잡성

초기 문제 상황

복붙의 문제: 설정 파일 복사-붙여 넣기로 인한 관리 어려움
인프라 장애까지 갈 뻔함: 설정 오류가 전체 시스템 장애로 확산될 위험

해결책 1: 오버레이 아키텍처

오버레이 아키텍처의 핵심 개념

조합 가능한 계층형 레이어 설정
위에 있을수록 우선순위 낮게: 상위 레이어가 하위 레이어를 오버라이드
요구사항에 따라 계속 바뀌고 구축한다: 동적 설정 변경 지원

한계점과 추가 해결책

오버레이 아키텍처의 한계:

만능은 아니다
중복 제거 힘듦
특정 값만 환경에 따라 변경하기 어려움

해결책: 템플릿 패턴 사용

일률적 해결을 위해 템플릿 패턴 도입
모든 요구사항을 만족할 수 있는 유연한 구조

해결책 2: 배치 서버 관리

배치 시스템의 중요성

한 달에 수조 원의 배치를 한다 - 금융 시스템의 핵심 업무
단순이 최고다, 위험이 클수록 단순해야 한다

Jenkins 기반 솔루션

Jenkins 선택 이유:

완벽하지는 않지만 충분하다고 생각
검증된 오픈소스 도구

JobDSL 플러그인 어댑터 개발:

이미 제공되는 Jenkins의 오픈소스 플러그인
플러그인을 한번 더 감싸서 개발자가 사용하기 쉽게 만들었다
빌더 패턴으로 구현
테스트를 적용하여 개발자의 실수를 줄이도록 함

운영 효율화

리소스 관리:

메모리 문제 해결: 실행 요청에 따라 자동으로 늘어나고 줄어드는 컴퓨팅 리소스

JAR 파일 경로 표준화 수행
적은 비용으로 가능해졌다

협업 개선:

개발자와 데브옵스 간의 단일 업무 인터페이스 구축

핵심 철학: 진화하는 시스템

가장 강력한 기능은 진화

요구사항 증가로 동적으로 증가함
완벽한 설루션보다는 지속적으로 개선 가능한 구조

아래부터는 정리한 내용을 AI에세 요약을 부탁하여 작성하였다.

4. 가맹점은 변함없이 결제창 시스템 전면 재작성하기

이 세션은 토스 페이먼츠의 결제창 시스템을 전면 재편하였던 경험을 다룬다.

문제점:

20년 된 레거시 시스템으로, 코드 중복과 2500줄에 달하는 조건문(if) 분기 처리
결제창 핵심 로직과 외부 인터페이스의 강한 결합, 전역변수로 인한 추적 어려움
SDP 내에서 DB 쿼리와 화면 조작이 혼재, 신규 팀원 온보딩 어려움
PG와 토스 페이먼츠 간 암호화 통신 필요

해결 방안:

추상화 및 결합도 감소: 모든 외부 인터페이스를 단일 인터페이스로 통합, 프론트와 백엔드 간 플로우 정의
로그 기반 파라미터 식별: 한 달치 로그를 분석해 파라미터 식별
Simple Request 도입: Preflight 요청 제거로 요청 단순화
카나리 배포: 점진적 트래픽 전환으로 안정성 확보
비즈니스 이해: 레거시 개편에서 비즈니스 연속성을 유지하기 위해 도메인 이해를 강조

성과: 가맹점 경험을 유지하면서 시스템 안정성과 유지보수성을 개선

5. LLM내재화 전략

토스 페이먼츠의 LLM(대규모 언어 모델) 내재화 전략을 다룬다

문제점:

상용 LLM(GPT, Claude 등)은 금융 도메인 특화 커스터마이징이 어려움
실시간성이 덜 중요하며, 안정성과 도메인 특화가 우선

해결 방안:

도메인 특화 LLM: 한국어와 영어만 지원하고, 금융 도메인에 특화된 소규모 LLM 개발
데이터 파이프라인: 데이터 수집(상용 LLM 활용), 정제, 오픈소스 기반 학습, 평가로 구성
- 평가: Reward Model과 LLM as a Judge로 자동화
인프라: KubeFlow로 파이프라인 관리, 5-10명 규모의 엔지니어 팀 필요
고객 맞춤: 토스증권 고객의 요구사항을 반영한 모델 설계

6. 확장성과 회복 탄력성을 갖춘 결제 시스템 만들기

결제 원장 테이블의 문제를 해결하고 확장성과 회복 탄력성을 강화한 사례를 다룬다

문제점:

비일관성 구조: 카드 결제/취소는 별도 테이블, 계좌이체는 단일 테이블로 운영난이도 증가
강한 의존성: 도메인별 컬럼 의미 상이, 팀 간 협업 문제
확장성 제약: 1:1 구조로 더치페이 같은 유연한 결제 불가능
MySQL 선택 이유: 기존 Oracle 기반 테이블의 복잡성, MyBatis 유지보수 어려움

해결 방안:

일관성 있는 구조: 공통 테이블과 개별 테이블로 분리, 결제/취소 시 insert로 처리
의존성 제거: Kafka 도입으로 도메인 간 직접적 의존성 제거
확장성 강화: 결제와 승인 테이블 분리로 더치페이 가능
비동기 처리: 기존 원장에 선저장 후 신규 원장에 비동기 저장, 쓰레드풀 튜닝 및 graceful shutdown
데이터 정합성: 검증 배치로 적합성 보장, 카나리 배포로 점진적 트래픽 전환
운영 이슈 대응:
- 특정 select 쿼리의 DB 부하(인덱스 미사용으로 풀 스캔) → 롤백 및 인덱스 최적화
- 구-신규 원장 불일치 및 응답 지연 → 로깅 fallback으로 서버 저장
- 이벤트 발행 누락 방지

성과: 확장성과 회복 탄력성을 갖춘 결제 시스템 구축, 신규 팀원 온보딩 시간 단축

7. 레거시 정산 개편기 : 신규 시스템 투입 여정부터 대규모 배치 운영 노하우까지

레거시 정산 시스템 개편과 대규모 배치 운영 방안을 다룬다

문제점:

쿼리 종속성: 복잡한 수수료 계산 쿼리로 유지보수 비용 증가
데이터 모델링 한계: 거래별 세밀한 데이터 관리 부족
고해상도 데이터 문제: 데이터량 증가로 조회 성능 저하
배치 성능: 단일 스레드 기반 Spring Batch로 처리량 한계

해결 방안:

쿼리 분해: 복잡한 쿼리를 비즈니스 로직으로 분해, 분할정복 방식으로 점진적 전환
데이터 모델링 개선:
- 거래별 결과 저장, 최소 단위 데이터 관리
- 계산 결과 스냅샷 저장으로 데이터 추적성 강화
고해상도 데이터 처리: 날짜 기반 레인지 파티셔닝, 복합 인덱스, 조회 전용 테이블 설계
배치 최적화:
- Spring Batch 멀티 스레드 스텝, 모듈러 연산으로 데이터 분할 처리
- 동적 프로비저닝 및 JobDSL로 배치잡 선언 코드화
검증 및 안정성: 구-신규 정산 데이터 비교 검증, 카나리 배포로 안정적 전환
모니터링 강화: OOM, 쓰레드 블록, 성능 지연 탐지, 쓰레드 덤프로 병목 및 데드락 분석

성과: 유지보수성 향상, 데이터 조회 성능 개선, 안정적인 배치 운영

후기

이번 세션을 들으면서 공통적으로 느꼈던 점이 몇 가지 있었다

완벽보다는 실용성과 지속적인 개선을 중요시하는 것 같았다. 전통적인 2PC 대신 자체적인 분산 트랜젝션 도입, jenkins를 "완벽하지는 않지만 충분하다"는 판단 하에 선택하는 등 기존의 방식에 안주하지 않고 새로운 접근방법을 시도하는 부분이 인상적이었다.

그리고 안정적인 서비스 운영에 대한 신중함을 느꼈다. 거의 모든 세션에서 카나리 배포를 언급라면서 갑작스러운 서비스 변경이 아닌 조건에 따른 비율을 늘리면서 조심스럽고 안정적인 서비스 전환을 하는 것을 보면서, 안정적인 금융 서비스 운영을 위한 토스의 신중함이 보였다.

그렇다고 토스 서비스가 느린 편도 아니다. 안정적인 운영과 실용적인 접근으로 빠른 실행속도를 위해 진심으로 일한다고 느껴졌다.

[NestJS] Monorepo로 구축하기 1 : pnpm workspace

9Jaeng — Sun, 25 May 2025 20:19:51 +0900

기존의 프로젝트는 모든 기능이 하나의 단일 코드베이스에서 관리되는 모놀리식 아키텍처(Monolithic Architecture)를 사용하고 있는 거대한 레거시였다.

CSAP 인증을 받기 위해 테이블구조도 큰 변경이 필요했고 서비스가 커지면서 개발 유지보수를 힘들게 만드는 현재의 구조를 변경하기 위해 모노레포 아키텍처로 코드베이스를 변경하기로 논의가 되었다.

이번 블로그는 모노레포를 구성하면서 조사했던 것들에 대해 정리를 해보고자 한다.

첫 번째로, mono repo 구축을 위한 package workspace에 대해 간단히 정리를 해보았다

Monorepo를 구축하는 방법 : pnpm workspace

monorepo를 구축하는 방법으로는 yarn worskapce와 같은 package workspace 나 lerna , Turborepo 등과 같은 도구를 사용하는 방법이 있다.

나는 그중 pnpm workspace를 선택하였는데, 이유는 다음과 같다

1. pnpm workspace는 기본적으로 모노레포를 지원한다.

2. yarn , npm은 phantom dependency문제가 있다

3. 현재 사용 중이라 러닝커브가 높지 않다

phantom dependency란?

여기서 phantom dependnency란, A워크스페이스에서 설치하지 않는 의존성을 사용할 수 있게 된다거나 원래 사용 중이던 의존성을 갑자기 찾지 못한다는 경우를 말한다.

의존성 호이스팅 : yarn classic과 npm의 경우 package설치의 중복을 줄이기 위해 의존성이 호이스팅 된다

아래의 그림을 보면, package-1 은 A, C를 의존성으로 갖고 A, C는 각각 하위 의존성으로 B(1.0), B(2.0)을 갖는다. yarn은 이런 의존성들을 호이스팅 하여 root node_modules에서 관리한다. (평탄화라고 부르는 것 같다)

이때 package-1 은 B(1.0)을 설치하지 않았지만 호이스팅 되어 B(1.0)을 사용할 수 있다. 만약 B(1.0)을 의존하던 것이 없어진다면 node_modules에 B(1.0)이 등록되지 않기 때문에 not found module 이슈가 발생할 것이다.

pnpm의 공식문서 pnpm vs npm과 이 블로그를 참고해 보자

그렇다면, pnpm의 구조는 어떤가?

pnpm은 symlink를 통해 package를 참조하는 방식을 사용한다.

Symlinked `node_modules` structure

Symlinked `node_modules` structure | pnpm

This article only describes how pnpm's node_modules are structured when

pnpm.io

위의 공식문서에 따르면, pnpm 은 symlink를 사용하여 중첩된 종속성 트리를 만든다.

node_modules 안에 있는 모든 패키지의 모든 파일은 content-addressable stora라는 전역 저장소에 대한 hard link를 갖는다.

hard link란, 파일시스템의 기능 중 하나로, 하나의 파일 데이터를 여러 위치에서 참조할 수 있도록 하는 방식. 즉, 동일한 파일 내용을 여러 경로에서 접근할 수 있게 하되, 실제로는 디스크 상에 하나의 데이터만 존재한다.

https://pnpm.io/symlinked-node-modules-structure

위와 같이 하드 링크가 구축되면, 중첩된 종속성 그래프 구조를 구축하기 위해 simlink를 생성한다.

https://pnpm.io/symlinked-node-modules-structure

위의 경우 foo는 bar를 의존하는데, node_modules/. pnpm/foo@1.0.0/node_modules의 bar는. pnpm에 있는 bar를 simlink로 참조한다. 이런 방식을 사용함으로써 순환참조, self 의존의 경우도 문제없이 가능하다.

npm이나 yarn classic과 같이 호이스팅을 하지 않아 phantom dependency는 발생하지 않는다.

pnpm의 saveing disk 전략

pnpm은 위와 같은 content-addressable storage 방식을 사용함으로써 disk 공간 절약에도 좋다

https://pnpm.io/motivation

만약 npm이라면, 하나의 의종성을 100개의 패키지에서 의존성으로 갖는다면, 100개가 복사될 것이지만 pnpm은 store에 한 번만 저장하고 다른 패키지들이 참조를 하도록 하여 디스크를 절약할 수 있다. 만약 의존성의 버전이 올라가면 올라간 버전이 새로 저장되는 방식을 취함으로써 버전별 관리가 가능하다는 장점이 있다.

이런 이유로 pnpm workspace를 사용하게 되었다.

[NestJS] Module의 실행 과정과 종류

9Jaeng — Sun, 16 Mar 2025 23:22:44 +0900

NestJS에서 모듈은 애플리케이션에서 비슷한 기능을 논리적으로 묶은 단위이다. 유사한 기능을 하는 컴포넌트들을 한데 모아 관리하는 컨테이너 역할을 한다.
만약 Auth 서비스(로그인, 회원가입 등), 사용자 관련 서비스(사용자 정보 조회, 사용자 정보 수정 등), 주문 관련 서비스(주문 생성, 주문조회 등)가 있다고 한다면 이들 각가이 하나의 모듈이 된다. 이런 특성으로 코드를 깔끔하게 정리할 수 있고 다른 모듈과 독립적으로 동작하도록 한다.

NestJS 모듈은 @Module() 데코레이터가 달린 단일 클래스이며 이 데코레이터를 통해 애플리케이션 구조를 구성하는데 필요한 메타데이터를 제공받는다. 제공받는 메타데이터는 아래와 같이 네 가지가 존재한다.

imports	다른 모듈에서 export하는 기능을 사용하기 위해 다른 모듈을 가져온다. 의존성 주입의 기본이 되는 부분
controllers	이 모듈에 속한 컨트롤러를 정의. HTTP 요청을 처리하는 부분
providers	모듈에서 사용 할 서비스를 등록하는 부분 import한 다른 모듈에서 export한 provider를 여기에 등록하여 사용한다.
exports	다른 모듈에 제공하고자 하는 provider의 집합이다. export에 등록된 provider만이 다른 모듈에서 사용할 수 있다.

@Module({
    imports: [CommonModule], // CommonModule에서 export하고 잇는 provider를 사용하기 위해 가져오는 module집합
    controllers: [UserController], // UserModule에서 정의된 모든 Controller 집합
    providers: [UserService, CommonService], // UserService와 CommonService를 이 모듈의 비즈니스로직에서 사용하기 위해 provider로 등록한다
    exports: [UserService], // UserService를 다른 모듈에서 사용할 수 있도록 제공
})
export class UserModule {}

NestJS의 모듈 시스템 실행 과정

NestJS는 AppModule이라는 최소 하나의 모듈로 이루어져 있다. 그리고 대부분 Application은 다수의 모듈을 사용한다. 아래의 그림과 같이 AppModule 루트모듈로 Application의 시작점이며 AppModule에서 하위 모듈을 import 하여 그래프 구조를 갖는다.

@Module({
  imports: [AuthModule, UsersModule, OrderModule], // AppModule에서 하위 모듈을 모두 import
})
export class AppModule {}

이렇게 등록된 모듈 시스템은 NestJs가 실행될 때 아래와 같은 순서로 작동한다.

1. 애플리케이션 부트스트래핑과 의존성 그래프 구축

애플리케이션이 시작되면 main.ts의 NestFactory.create(AppModule) 을 호출하여 루트 모듈을 등록한다.

// main.ts
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000);
}
bootstrap();

NestJS 애플리케이션이 부트스트래핑 되면 AppModule에 등록된 하위 Module들은 의존성 그래프를 구축하게 된다. 이 과정에서 아래와 같은 동작이 진행된다.

1. root module의 imports 배열에 선언된 모든 모듈을 재귀적으로 분석한다

2. 각 모듈에 정의된 providers, controllers를 식별한다.

3. 모듈 간 관계와 의존성을 매핑한다

NestJS 코드 내부를 살펴보면,

DependenciesScanner의 scanForModules 에서 reflectMetadata를 통해 @Module 데코레이터의 imports 메타데이트 키인

MODULE_METADATA.IMPORTS를 사용하여 imports의 메타데이터를 가져오는 것을 볼 수 있다.

 const modules = !this.isDynamicModule(
      moduleDefinition as Type<any> | DynamicModule,
    )
      ? this.reflectMetadata(
          MODULE_METADATA.IMPORTS,
          moduleDefinition as Type<any>,
        )
      : [
          ...this.reflectMetadata(
            MODULE_METADATA.IMPORTS,
            (moduleDefinition as DynamicModule).module,
          ),
          ...((moduleDefinition as DynamicModule).imports || []),
        ];

그리고 아래로 더 내려가면 재귀적으로 innerModule에 대해 scanForModules를 호출하면서 재귀적으로 imports문에 선언된 모든 모듈을 분석한다

    let registeredModuleRefs: Module[] = [];
    for (const [index, innerModule] of modules.entries()) {
      // In case of a circular dependency (ES module system), JavaScript will resolve the type to `undefined`.
      if (innerModule === undefined) {
        throw new UndefinedModuleException(moduleDefinition, index, scope);
      }
      if (!innerModule) {
        throw new InvalidModuleException(moduleDefinition, index, scope);
      }
      if (ctxRegistry.includes(innerModule)) {
        continue;
      }
      const moduleRefs = await this.scanForModules({
        moduleDefinition: innerModule,
        scope: ([] as Array<Type>).concat(scope, moduleDefinition as Type),
        ctxRegistry,
        overrides,
        lazy,
      });
      registeredModuleRefs = registeredModuleRefs.concat(moduleRefs);
    }

DependenciesScanner 클래스에서는 각 모듈의 providers, controllers, imports, exports를 식별하고 컨테이너에 등록하는 로직을 통해 각 의존성을 식별한다.

  public async scanModulesForDependencies(
    modules: Map<string, Module> = this.container.getModules(),
  ) {
    for (const [token, { metatype }] of modules) {
      await this.reflectImports(metatype, token, metatype.name);
      this.reflectProviders(metatype, token);
      this.reflectControllers(metatype, token);
      this.reflectExports(metatype, token);
    }
  }

2. 공급자(Provider) 인스턴스화

의존성 그래프가 구축되면, NestJS는 아래와 같은 순서로 Provider를 인스턴스화한다.

1. 글로벌 공급자 먼저 인스턴스를 한다.

2. 모듈별 공급자를 인스턴스화 한다

3. 각 공급자의 의존성을 주입한다

글로벌 공급자는 ApplicationConfig에 등록된 글로벌 가드, 파이프, 인터셉터, 필터 등을 말한다.

코드는 DependenciesScaner 의 applyApplicationProviders 부분과 instance-loader.ts 에서 확인해 볼 수 있다.

3. LifeCycle Hook 실행

https://docs.nestjs.com/fundamentals/lifecycle-events

NestJs는 Provider 인스턴스화 후 아래와 같은 순서로 LifeCycle Hook를 호출한다.

1. onModuleInit() - 해당 모듈의 모든 의존성이 해결된 후 호출

2. onApplicationBootstrap - 모든 모듈이 초기화된 후 호출(하지만 연결을 수신하기 전에 호출된다)

4. 컨트롤러 등록

모든 Provider가 인스턴스화되고 LifeCycle Hook이 실행된 후 NestJS는 각 모듈에 정의된 컨트롤러를 등록한다.

1. 컨트롤러 및 route handler 분석

2. 미들웨어, 가드 등 적용

3. HTTP요청 처리를 위한 라우팅 테이블 설정

code/nest-application.ts의 init을 보면 아래와 같이 NestJS의 LifeCycle Hook 실행 후 Router를 확인하는 함수가 실행되는 것을 볼 수 있다

public async init(): Promise<this> {
    if (this.isInitialized) {
      return this;
    }

    this.applyOptions();
    await this.httpAdapter?.init?.();

    const useBodyParser =
      this.appOptions && this.appOptions.bodyParser !== false;
    useBodyParser && this.registerParserMiddleware();

    await this.registerModules();
    await this.registerRouter();
    await this.callInitHook();
    await this.registerRouterHooks();
    await this.callBootstrapHook();

    this.isInitialized = true;
    this.logger.log(MESSAGES.APPLICATION_READY);
    return this;
  }

이렇게 모든 모듈, 공급자, 컨트롤러가 초기화되면 애플리케이션은 HTTP 요청을 처리할 준비가 된 상태가 된다.

NestJS 모듈의 종류

https://docs.nestjs.com/modules

NestJs의 모듈 종류는 여러 가지가 있다. 위에서 실행과정을 보면서도 nestjs의 모듈 종류에 따라 다르게 처리하는 부분들을 봤던 것 같다.

1. Feature Module

처음 NestJs를 사용하면 기본적으로 사용하는 모듈이다. 비슷한 기능, 관련된 기능 단위로 관리하며 관련된 컨트롤러, 서비스, 레포지토리 등을 묶는다. 기능별로 분리를 하고 독립적으로 동작하거나 다른 모듈에 의존할 수 있다.

import { Module } from '@nestjs/common';
import { AuthController } from './auth.controller';
import { AuthService } from './auth.service';

@Module({
  controllers: [AuthController],
  providers: [AuthService],
})
export class AuthModule {}

2. Shared Module

NestJs에서 모듈은 기본적으로 싱글톤이다. 이러한 특징으로 동일한 instance의 provider를 모듈 간 공유할 수 있다. 모든 모듈이 공유모듈이라고 할 수 있다.

3. Dynamic Module

동적모듈은 런타임에 설정을 동적으로 적용할 수 있는 모듈이다. 애플리케이션 실행 시 생성되는 정적 모듈과 다르게 모듈의 구성 요소를 실행 시점에 정할 수 있어 유연성이 좋다. 비슷한 기능을 여러 모듈에서 사용할 때, 설정만 다르게 해서 동일한 모듈을 재활용할 수 있다는 점이 큰 장점이라고 생각한다.

forRoot()나 forFeature() 같은 메서드를 통해 모듈을 생성하며, 외부 라이브러리나 설정값을 주입할 때 사용된다.

주로 환경 변수 관리(ConfigModule), 데이터베이스 ORM 설정(TypeOrmModule) 등에서 자주 활용된다.

아래의 코드는 동적 모듈로 로그 모듈을 생성하고 사용하는 모듈에서 로그 레벨을 동적으로 설정할 수 있음을 보여준다.

import { Module, DynamicModule } from '@nestjs/common';
import { LoggerService } from './logger.service';

// 정의
@Module({})
export class LoggerModule {
  static forRoot(options: { level: string }): DynamicModule {
    return {
      module: LoggerModule,
      providers: [
        { provide: 'LOG_LEVEL', useValue: options.level },
        LoggerService,
      ],
      exports: [LoggerService],
    };
  }
}

// 사용
@Module({
  imports: [LoggerModule.forRoot({ level: 'debug' })],
})
export class AppModule {}

4. Global Module

글로벌 모듈은 @Global() 데코레이터를 사용하여 전역 범위에서 사용 가능한 모듈이다. 한 번 정의하면 다른 모듈에서 import 없이도 provider를 주입받을 수 있다.

주의할 점은 전역으로 사용되기 때문에 의존성 추적이 어려울 수 있으므로 신중하게 사용해야 한다. 보통 전역 설정, 공통 유틸리티, 캐싱 서비스 등 애플리케이션 전반에 걸쳐 접근해야 하는 경우 사용하기 좋다

import { Module, Global } from '@nestjs/common';
import { CacheService } from './cache.service';

@Global()
@Module({
  providers: [CacheService],
  exports: [CacheService],
})
export class CacheModule {}

마치며

이번 포스팅은 NestJS의 모듈에 대해 알아보았다.

다음은 프로바이더의 내부 동작과 종류 그리고 언제 어떤 방식을 사용하면 좋을지에 대해 정리해 보겠다.

[REFACTORING - 2] CH02 리랙터링의 원칙 정리

9Jaeng — Sun, 2 Mar 2025 22:41:10 +0900

들어가며

1장에서는 리팩터링이 무엇인지 감을 잡기 위한 것이었다면, 2장은 리팩터링의 정의와 이유, 시기, 그리고 리팩터링 시 고려해야 할 다양한 측면들을 다룬다.

2장 요약

2.1 리팩터링의 정의

코드를 정리하거나 구조를 바꾸는 작업을 재구성(restructuring)이라고 하며, 리팩터링은 이러한 재구성의 한 형태다. 리팩터링의 핵심 목적은 코드를 더 이해하기 쉽고 수정하기 쉽게 만드는 것이다. 구체적으로 리팩터링은 "기본 동작은 그대로 유지한 채, 여러 기법들을 사용해서 소프트웨어를 재구성하는 것"을 의미한다.

리팩터링은 작은 단계들을 통해 코드를 점진적으로 수정하고, 이러한 단계들이 연결되어 궁극적으로 큰 변화를 만들어낸다. 가장 중요한 점은 코드의 구조는 변경하지만, 프로그램의 전반적인 기능은 그대로 유지해야 한다는 것이다. 리팩터링으로 인해 기능 변경이 발생해서는 안 된다.

2.3 리팩터링을 하는 이유

많은 개발자들이 코드에 기능을 추가하다 보면 리팩터링을 하고 싶은 욕구를 느낄 것 이라 생각한다. 책에서는 소프트웨어 개발 과정에서 기능 추가와 리팩터링을 목적에 맞게 명확하게 구분해야 한다고 강조한다. 리팩터링을 진행할 때는 테스트 코드조차 추가하지 않는다.

리팩터링의 필요성은 대부분의 개발자가 인식하고 있다고 생각한다. 지속적인 리팩터링은 소프트웨어 설계를 개선하고 코드를 이해하기 쉽게 만든다. 코드가 읽기 쉬워지면 버그도 더 빠르게 발견할 수 있고 유지보수도 용이해진다. 코드를 쉽게 파악할 수 있게 되면 작업 속도 또한 자연스럽게 향상된다.

2.4 리팩터링은 언제 해야할까?

이 책에서는 리팩터링을 세 가지 유형으로 분류한다:

준비를 위한 리팩터링: 기능 추가 직전에 작업을 더 쉽게 만들기 위해 수행하는 리팩터링
이해를 위한 리팩터링: 코드를 더 이해하기 쉽게 만들기 위한 리팩터링
쓰레기 줍기 리팩터링: 비효율적인 로직을 발견했을 때 수행하는 리팩터링

이러한 리팩터링은 모두 기회가 될 때마다, 즉 코드를 작성할 때마다 자연스럽게 진행하는 것이 좋다. 리팩터링을 한 이유와 배경을 알 수 있도록 작업 과정에서 지속적으로 수행하는 것이 중요하다. 또한 수시로 리팩터링을 함으로써 더욱 효율으로 작업할 수 있다. 예를 들면, 새 기능을 추가할 때는 코드를 수정하여 기능 추가가 쉽도록 만드는 것이 가장 효율적인 방법이다.

리팩터링에 소홀하여 별도로 시간을 내어 계획된 리팩터링을 진행할 수도 있지만, 책에서는 이 방법을 크게 추천하지 않는다. 코드에 대한 리팩터링의 필요성은 코드를 작성하는 시점에 가장 명확하기 때문이다.

팀 전체가 참여해야 하는 대규모 리팩터링이 필요한 경우도 있지만, 한 번에 모든 것을 수정하기보다는 해당 코드 관련 작업을 할 때마다 점진적으로 개선해 나가는 방법을 추천한다.

2.5 리팩터링 시 고려할 문제

리팩터링을 하면서 발생할 수 있는 대표적인 문제들은 다음과 같다:

새 기능 개발 속도 저하

리팩터링은 얼핏 보면 새 기능 개발 속도를 저하시킨다는 인상을 줄 수 있다. 그러나 책에서는 "리팩터링의 궁극적인 목적은 개발 속도를 높여서 더 적은 노력으로 더 많은 가치를 창출하는 것"이라고 설명한다. 기능을 추가하기 쉽게 코드를 만든 후 기능을 추가하는 것이 장기적으로는 더 빠른 방법이기 때문이다.

코드 소유권과 브랜치

코드 소유권이 명확하게 나뉘어 있으면 리팩터링에 방해가 될 수 있다. 내가 소유하지 않은 코드를 리팩터링할 때 다른 부분에 영향을 주지 않도록 하는 복잡성이 발생한다. 이를 해결하기 위해 코드 소유권을 팀 단위로 두고, 팀 구성원 모두가 코드를 수정할 수 있는 느슨한 방식을 채택할 수 있다.

지속적 통합(Continuous Integration) 또는 트렁크 기반 개발(Trunk-Based Development)을 도입하여 기능별 브랜치와 마스터 브랜치가 통합되는 기간을 최소화하는 것도 좋은 방법이다. 이러한 방식에서는 구성원들이 하루에 최소 한 번은 마스터와 통합하도록 하여 브랜치 간 차이가 크게 벌어지지 않도록 한다. 이를 통해 병합의 복잡도를 낮추고, 코드베이스 전반에 걸친 리팩터링으로 인한 충돌을 최소화할 수 있다. 여기서 통합이란, 마스터를 개인 브랜치로 pull 하고 작업 결과를 마스터에 올리는 push 하는 작업을 의미한다.

( 팀마다 다르겠지만 master가 아닌 코드 통합 및 테스트의 기본 브랜치(예를 들면 develop)일 것이라 생각한다 )

테스팅

리팩터링의 핵심은 리팩터링 전후의 기능 동작이 변하지 않아야 한다는 것이다. 이를 보장하려면 자동화된 테스트 코드가 필수적이다. 테스트 코드는 리팩터링 과정에서 기능 변경 여부를 확인할 수 있는 중요한 도구가 된다. 또한 지속적 통합 과정에서 활용하여 코드 통합 시 발생할 수 있는 충돌을 효과적으로 식별할 수 있다.

요즘엔 개발을 진행하면서 중요한 비즈니스 로직에는 테스트 코드를 추가하고 있다. 이를 통해 코드를 수정할 때 다른 코드와의 충돌 여부나 중요한 비즈니스 로직이 의도치 않게 변경되지 않았는지 확인할 수 있어 매우 유용하다.

레거시 코드

대규모 레거시 시스템을 테스트 코드 없이 리팩터링하는 것은 매우 어렵다. 이런 경우에는 테스트 보강이 가장 효과적인 접근법이다. 서로 관련된 부분끼리 나누어 하나씩 체계적으로 개선해 나가는 것이 중요하다.

2.6 아키텍처와 YAGNI

리팩터링이 아키텍처에 미치는 가장 큰 효과는 요구사항 변화에 따라 자연스럽게 대응할 수 있도록 코드를 설계해 준다는 점이다.

실제로 소프트웨어를 사용해 보고 나서야 무엇이 적합한지 알게 되는 경우가 대부분이다. 범용성을 고려한 유연성 메커니즘을 미리 구현할 수도 있지만, 이는 실제 요구사항 변화에 따라 달라지는 경우가 많다. 리팩터링은 미리 추측하지 않고 현재까지 파악한 요구사항만을 해결하도록 코드를 구축하도록 한다. 개발을 진행하면서 사용자의 요구사항을 더 깊이 이해하게 되면 그에 맞게 아키텍처도 리팩터링하여 변경한다.

YAGNI(You Aren't Going To Need It)는 "당장 필요한 기능만으로 최대한 간결하게 만들라"는 원칙을 의미한다. 이는 나중에 문제를 더 깊이 이해하게 되었을 때 처리하는 진화형 아키텍처의 핵심 개념이기도 하다.

2.7 리팩터링과 소프트웨어 개발 프로세스

테스트 코드와 지속적 통합, 리팩터링을 함께 적용하면 YAGNI 설계 방식으로 효과적인 개발을 진행할 수 있다.
불확실한 추측에 기반한 유연성 메커니즘보다는 단순한 시스템이 변경하기가 훨씬 쉽다.
이 세 가지 실천 방법(테스트, 지속적 통합, 리팩터링)을 조화롭게 활용하면 요구사항 변화에 신속하게 대응할 수 있다.
지속적 배포는 소프트웨어를 언제든 릴리스할 수 있는 상태로 유지해 준다. 이를 통해 비즈니스 요구에 맞춰 릴리스 일정을 유연하게 계획할 수 있다.

2.8 리팩터링과 성능

리팩터링의 접근 방식은 코드를 튜닝하기 쉽게 만들고, 그 후에 원하는 속도를 달성할 수 있도록 최적화하는 것이다.
리팩터링은 궁극적으로 성능이 좋은 소프트웨어를 만드는 데 기여한다.

마치며

이번 장에서는 리팩터링 전반에 적용되는 다양한 원칙들을 살펴보았다. 리팩터링의 정의와 목적, 적용 시기, 그리고 리팩터링 시 고려해야 할 요소들, 소프트웨어 아키텍처와의 관계, 성능과의 관계 등을 종합적으로 다루었다.

특히 인상 깊었던 부분은 "당장 필요한 기능만으로 최대한 간결하게"라는 의미의 YAGNI 원칙과 이를 통한 진화형 아키텍처 접근법이었다. 최근 진행 중인 레거시 프로젝트 마이그레이션에서 새로운 아키텍처 구성에 대해 고민하던 중이었는데, 책에서 언급한 것처럼 한 번에 모든 요구사항을 예측하는 것은 불가능하며, 모든 상황을 고려한 유연성 메커니즘을 구현하려다 보면 리팩터링 범위가 커질 수 있다는 점을 실감했다.

현재 작업 중인 레거시 코드는 새로운 기능이 필요할 때마다 기존 구조를 고려하지 않고 계속 코드를 추가하다 보니 복잡해진 코드가 많이 있다. 테스트 코드도 없는 상황에서 점진적으로 테스트를 추가하며 리팩터링과 마이그레이션을 진행하고 있는데, 이 과정에서 테스트 코드와 리팩터링의 중요성을 더욱 실감하고 있다. 물론 일정을 맞추기 위해 속도가 중요할 때도 있어 항상 트레이드오프를 고려해야 한다.

이번 장을 통해 특별히 기억하고 싶은 세 가지 핵심 원칙은 다음과 같다:

테스트 코드를 작성하자
수시로 리팩터링을 하자
당장 필요한 기능만으로 최대한 간결하게 개발하자

[리뷰 - 단위 테스트의 기술] - 단위 테스트 제대로 알기!

9Jaeng — Tue, 4 Feb 2025 22:58:07 +0900

개인적으로 요즘 테스트, 특히 단위 테스트에 대해 관심이 생기고 있었다.

단위 테스트를 어떻게 잘, 효율적으로 작성할 수 있을까? 유의미한 단위 테스트는 어떻게 작성하는 것이 좋을까? 하는 고민을 했었고

[TEST]테스트 원칙에 대하여 - 소프트웨어 테스트의 7원칙과 FIRST원칙 이라던가 [TEST]테스트 코드를 어떻게 시작하면 좋을까

와 같은 글도 작성하면서 조금씩 공부를 하고 있다.

이런 와중에 "[길벗출판사] 26차 개발자 리뷰어"를 모집한다는 광고를 보았는데, 그중에 "단위 테스트의 기술"이라는 책이 눈에 들어왔다. 저번에 신청했을 때는 선정이 안되었었기 때문에 큰 기대 없이 신청서 작성을 하였다. 그런데 운 좋게도 이번엔 당첨이 되었다.

책은 이틀 뒤에 받았고, 긴 연휴 동안 천천히 읽었고, 쉬는 목적으로 갔던 해외여행 일정에서도 틈틈이 읽었다.

사실 이런 기술서적은 코드를 직접 쳐보거나 책에서 알려주는 참고 자료들도 찾아보면서 읽는 편이라 책을 조금 느리게 읽는 편이다. 이번엔 기간이 정해져 있어서 원래 읽던 대로 읽지는 못해서 한 번 더 천천히 읽어볼 예정이다.

서론을 여기까지 하고 책에 대한 리뷰를 해보겠다.

목차는 아래와 같다

[목차]

1. 이 책에 대하여

2. 느낀점

3. 마치여

이 책에 대하여

이 책은 로이 오셔로브와 블라디미르 코리코프가 쓴 단위 테스트에 관한 책이다. TDD가 아닌 "단위 테스트" 자체에 초점을 맞추고 있으며, 테스트 작성법부터 시작해 신뢰성 있고 유지보수가 쉬운 테스트 작성 방법, 단위 테스트 도입 노하우, 레거시 코드에 단위테스트를 도입하는 방법 등 실용적인 가이드를 제공한다.

초판은 C#으로 예제가 작성되었는데, 이번 3판에서는 JavaScript와 TypeScript로 바뀌었다. JS의 동적 타입과 TS의 정적 타입 예시를 모두 보여주는데, 대부분의 테스트 관련 서적이 Java 기반인 것에 비해 내가 주로 쓰는 언어로 되어있어서 반가웠다. 물론 이런 기술 서적의 개념들은 특정 언어에 국한되지 않아서 어떤 언어든 적용할 수 있다..!

책은 총 4부로 구성되어 있고, 각 부분은 다음과 같은 내용을 다룬다:

1부: 단위 테스트의 기본기

1장에서는 테스트 단위의 정의, 시작점과 종료점 구분, 단위/통합 테스트의 차이, TDD와의 관계 등을 다룬다. 2장에서는 Jest를 사용한 테스트 작성법, AAA 패턴, 테스트 이름 짓기와 USE 전략, 테스트 구조화 방법 등을 소개한다.

2부: 실전 테스트 작성과 리팩터링

3장은 의존성 종류에 따라 목과 스텁을 어떻게 다르게 사용하는지 다룬다. 특히 스텁을 활용해 내부로 들어오는 의존성을 분리하는 방법과 리팩터링 기술을 집중적으로 다룬다. 순수 함수 스타일과 객체지향형 스타일로 각각의 접근법을 보여주어 개발자의 이해를 돕는다.

4장에서는 반대로 목을 사용해 외부로 나가는 의존성을 분리하는 방법을 소개한다. 목과 스텁의 차이점을 명확히 설명하고, 다시 순수함수 스타일과 객체지향 스타일로 다양한 예시를 통해 개념을 설명한다.

3, 4장에서 수동으로 목과 스텁을 만드는 방식은 중복 코드와 복잡성 문제를 야기할 수 있다. 이를 해결하기 위해 5장에서는 격리 프레임워크를 사용하는 방법을 소개한다.

6장은 비동기 코드에 대한 테스트 기법을 다루며, 실무에서 자주 마주치는 비동기 로직의 테스트 방법을 제시한다.

3부: 신뢰할 수 있는 테스트, 테스트의 유지보수성에 대한 모범 사레들

1, 2부에서 단위 테스트의 기본기와 핵심 기술을 배웠다면, 3부는 테스트의 품질을 높이는 방법론을 제시한다.

7장은 신뢰할 수 있는 테스트에 대해 깊이 파고든다. 잘못된 테스트, 신뢰성 없는 테스트의 패턴과 문제점을 살펴본다. 7장은 나 자신이 지금까지 작성했던 테스트들을 돌아보게 만드는 내용이었다.

8장에서는 테스트의 유지보수성을 높이기 위한 다양한 기술과 접근법을 소개한다.

개인적으로 7, 8장이 가장 중요하다고 생각한다. 이전 회사 경험을 되돌아보면, 유지보수의 어려움 때문에 방치된 수많은 실패한 테스트들이 떠오른다. 지금 와서 생각해보면, 그때 작성했던 테스트들이 정말 신뢰할 수 있는 것들이었는지, 혹시 그저 형식적으로 의무감에서 작성한 것은 아니었는지 의문이 든다.

4부: 실무에 단위 테스트를 도입하는 여러 방법

4부는 실무에서 실제로 마주할 수 있는 문제들을 다룬다. 현실적인 이야기들이 담겨 있어 충분히 공감하며 상상할 수 있었다.

9장에서는 테스트 코드의 가독성을 다룬다. 이름 짓기는 항상 중요하고 어려운 작업이지만, 테스트에서는 그 중요성이 더욱 크게 느껴진다. 무엇을, 어떻게, 왜 테스트하는지 명확히 알 수 있도록 작성한다면 테스트 코드 자체가 훌륭한 문서화 도구가 될 수 있다.

10장은 효과적인 테스트 전략 수립 방법을 다룬다.

11장에서는 조직 내 단위 테스트 도입 과정에서 발생할 수 있는 현실적인 문제들과 초기 도입 시 겪는 어려움들을 구체적으로 다룬다.

12장은 테스트 코드가 전혀 없는 레거시 코드에 테스트를 도입하는 방법을 소개한다. 단위테스트가 없는 기존 코드에 테스트를 적용해야 한다면 11, 12장이 큰 도움이 될 것이다. 세부 상황에 대한 더 자세한 예시가 있었으면 좋겠지만, 그래도 접근 방식에 대한 가이드로는 충분하다고 생각한다.

느낀 점

이 책을 읽으면서 지금까지의 내 테스트 방식의 실수들을 깨달았다. 특히 목과 스텁을 명확히 구분하지 않고 무분별하게 사용했던 점, 하나의 테스트에 여러 검증을 넣었던 점, 의존성 해결을 위해 불필요하게 복잡한 목 객체를 만들었던 경험들이 떠올랐다.

책을 통해 그동안 잘못된 방법으로 테스트를 해왔음을 인정하게 되었다. 앞으로 이 책을 다시 정리하며 읽으면서 모범 사례들을 꼼꼼히 정리해볼 생각이다.

특히 8장의 유지보수성 부분에서 가장 인상 깊은 문장이 있었다. "테스트가 장기적으로 가치가 있으려면 정말로 비즈니스에서 중요하게 생각하는 부분에서만 납득 가능한 이유로 실패해야 한다"는 문장이다.

테스트의 실패는 프로덕션 코드의 실제 버그를 발견하는 "실제 실패"여야 한다. 그 외의 이유로 발생하는 테스트 실패는 모두 "거짓 실패"다. 테스트 유지보수성의 중요성을 뼈저리게 느끼고 있는데, 과거 유지보수 힘든 테스트코드 때문에 결국 테스트코드를 포기했던 개발 문화를 떠올리게 한다.

테스트 코드를 잘 작성하는 방법에 대한 갈망이 있었는데, 이 책이 그 가이드가 될 것 같다. 책에서 언급한 다양한 테스트 관련 도서들도 시간 날 때 읽어보고 싶다. 특히 마이클 C. 페더스의 "레거시 코드 활용 전략"이 읽고 싶지만, 아직 읽을 책들이 산더미라 언제 읽을지는 미지수다.

마치며

평소에 관심 있던 주제에 대한 책이라 흥미진진해하며 읽었다.

한 번 읽기엔 아쉬워서 두고두고 생각날 때마다 가이드처럼 읽어도 좋을 것 같다.

[코드트리 한 달 사용기] 체계적이고 기본에 충실한 코테준비

9Jaeng — Mon, 3 Feb 2025 01:09:20 +0900

개발자 이직을 준비하다 보면 다른 직군에 비해 준비해야 할 것들이 유독 많다는 것을 실감하게 된다. 기계공학과를 졸업하고 관련 직종으로 취업을 준비했던 경험과 비교해보면 그 차이가 확연히 느껴진다.

일반적인 채용 프로세스는 서류 - 1차 면접 - 2차 면접 - (추가 면접) - 협상 - 합격의 순서를 따르지만, 현재 개발자 채용 시장에서는 대부분의 기업이 코딩테스트나 과제전형을 필수로 요구한다. 심지어 둘 다 요구하는 경우도 적지 않다. 여기에 기술면접 준비와 사이드 프로젝트까지 병행하려면 시간이 매우 부족하다.

이런 상황에서 코딩테스트 준비는 종종 서류 합격 이후에 급하게 이루어지곤 했다. 프로그래머스와 백준으로 꾸준히 감을 유지하려 했지만, 실제로는 쉽지 않았다. 매번 급하게 준비하고 나면 '미리 준비할걸' 하는 후회를 종종 하곤 했다.

'어떻게 하면 코딩테스트를 체계적으로 준비할 수 있을까?' 고민하던 중 코드트리 한 달 사용권을 체험할 수 있는 기회를 얻게 되었다. 코드트리는 이전부터 관심 있게 지켜보던 플랫폼이었지만, 유료 서비스라 고민을 많이 하였는데 좋은 기회였다.

한 달간의 코드트리 사용 경험을 통해 개인적으로 부족하다고 느꼈던 부분들을 상당히 보완할 수 있었다. 이 글에서는 실제 사용 경험을 바탕으로 느낀 점들을 공유하고자 한다.

체계적으로 기본기를 다질 수 있다

비전공자로서 코딩테스트를 준비하면서 가장 아쉬웠던 점은 탄탄한 기본기의 부족이었다. 공대를 졸업했지만 컴퓨터공학 전공이 아니다 보니, 자료구조나 알고리즘과 같은 핵심 개념들을 체계적으로 학습할 기회가 없었다. "이것이 코딩테스트다 with 파이썬"과 같은 책으로 독학하고 블로그를 참고하며 깃허브에 정리도 해보았지만, 한정된 문제 수와 실전 적용 가이드의 부족함이 늘 아쉬웠다. 이러한 요구사항은 코드트리를 통해 해소될 수 있었다.

코드트리는 총 6개의 Trail로 구성된 체계적인 커리큘럼을 제공한다

- Novice Low (Trail 1): 다양한 프로그래밍 언어의 기초 문법 학습
- Novice Mid (Trail 2): 기초적인 구현 능력 배양
- Novice High (Trail 3): 문제 해결에 필요한 핵심 알고리즘과 자료구조 학습
- Intermediate Low (Trail 4): BFS, DFS, DP 등 기본 알고리즘 학습
- Intermediate Mid (Trail 5): Two Pointer, 이분 탐색 등 최적화 기법과 고급 자료구조 학습
- Intermediate High (Trail 6): 트리, 위상 정렬 등 심화 알고리즘 학습

계속 이런 기본기에 충실하고 체계적인 커리큘럼을 계속 찾고 있었다..!!

나는 기본기 강화에 초점을 맞추어 Novice High부터 학습을 시작했다. 시간복잡도부터 시작해 기본 자료구조, 그래프 알고리즘까지 체계적으로 구성된 커리큘럼을 따라가며 단계적으로 복습 및 학습을 할 수 있었다.

Trail이 올라갈수록 점점 더 고급 자료구조, 알고리즘에 대해 학습한다.

코드트리의 가장 큰 장점은 반복 학습을 통한 개념 강화하고 생각한다. 단순히 알고리즘에 대한 이론적 설명에 그치지 않고, 중간중간 실전 문제들을 통해 배운 개념을 계속 상기하고 적용해볼 수 있다. 이러한 반복 학습을 통해 자연스럽게 알고리즘 활용 능력이 체화되는 것을 경험할 수 있었다.

특히 주목할 만한 점은 상세한 '해설' 제공이다. 프로그래머스나 백준에서는 다른 사람의 풀이나 토론을 통해 간접적으로만 학습할 수 있었던 반면, 코드트리는 공식 해설을 통해 의도된 풀이 방법과 접근 방식을 직접 확인할 수 있다. 이는 학습 효율을 높여주는 차별화된 장점이라고 생각한다.

꾸준히 풀 수 있도록 하는 경험치 전략과 자동으로 심어지는 잔디

코딩테스트는 지속적인 연습이 성패를 좌우한다. 시험 직전의 벼락치기로는 한계가 명확했고, 실전에서 제 실력을 발휘하기 위해서는 꾸준한 문제 풀이를 통해 감각을 유지하는 것이 중요하다.

코드트리는 이러한 꾸준함을 유도하기 위해 두 가지 흥미로운 전략을 채택하고 있다. 첫째는 경험치 획득 시스템이고, 둘째는 깃허브 잔디 자동 심기 기능이다. 깃허브와 연동해 놓으면 문제를 풀 때마다 자동으로 잔디가 심어지는데, 점점 무성해지는 잔디를 보며 의미 있는 시간을 보내고 있다는 성취감을 느낄 수 있다.

특히 경험치 시스템은 일일 목표 설정을 통해 학습 동기를 부여한다. 하루 90XP라는 구체적인 목표가 있다 보니, 자연스럽게 일정 수준 이상의 문제를 풀게 되는 동기부여가 된다. 물론 이러한 요소들이 완벽한 해결책은 아니지만, 학습 의욕을 높이고 지속적인 연습을 이끌어내는 데 효과적인 장치로 작용함을 느꼈다.

마치며

알고리즘과 자료구조 학습은 단순히 코딩테스트 통과에만 있지 않고 프로그래머로서의 전반적인 문제 해결 능력을 키울 수 있는 도구라고 생각한다. 꾸준한 문제 풀이는 프로그래밍 감각을 유지하는 데 도움이 되며, 여러 자료구조와 알고리즘 지식은 현업에서 마주치는 복잡한 비즈니스 로직을 효율적으로 설계하고 구현하는 데 도움이 될 수 있다

한 달간의 코드트리 사용 경험을 통해, 비전공자로서 느꼈던 기본기에 대한 갈증을 상당 부분 해소할 수 있었다.

앞으로도 남은 Trail들을 완주하며 더 깊이 있는 학습을 이어나가고 싶다.