엉망인 레거시 스키마를 코드 경계 뒤에서 개선하는 법

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

의미를 알 수 없는 테이블과 컬럼이 가득한 레거시 DB라면 스키마 이름부터 바꾸는 것이 가장 위험한 출발일 수 있다. 데이터베이스 위에 리포지토리나 어댑터 경계를 만들고, 애플리케이션에는 의미 있는 타입만 노출해 나쁜 어휘가 더 퍼지지 않게 한다. 코드에서 통제력을 회복한 뒤 DB를 개선한다.

이는 현재 동작하는 시스템을 위한 점진 전략이다. 쿼리 결과를 범용 맵으로 넘기는 구조라면 코드에서 얻을 지렛대가 부족해 더 큰 범위의 개선이 필요할 수도 있다.

원시 스키마 아래에 선을 긋는다

코드값으로만 된 테이블을 조회하는 SQL이 애플리케이션 메서드마다 들어 있다고 하자. 모든 호출자가 비즈니스 의미와 DB의 수수께끼를 함께 알아야 한다. 첫 경계는 이 쿼리들을 리포지토리 성격의 구성 요소로 모으는 데서 시작한다.

선 위에서는 데이터의 의미를 이름으로 드러낸 타입을 반환하고, 유스케이스에 필요한 필드만 담는다. 선 아래의 어댑터는 여전히 보기 싫은 쿼리를 실행할 수 있다. 스키마를 곧바로 고치지는 못해도 우연히 생긴 이름을 다른 계층이 더 배우지 않게 한다.

정적 타입은 이때 힘을 준다. 의미 있는 결과가 어디서 쓰이는지, 실제로 어떤 필드를 사용하는지 컴파일러를 통해 확인할 수 있다. 범용 맵은 정보를 거의 남기지 않아 점진 접근이 너무 약해질 수 있다.

오염을 가두면서 의미를 배운다

경계는 이름만 예쁘게 바꾸는 장식이 아니다. 쿼리 접근을 한곳에 모으면 코드 테이블이 실제로 상품을 뜻하고, 열 개 컬럼 중 두 개만 쓰며, 여러 조인이 하나의 비즈니스 행위를 위해 존재한다는 사실이 보이기 시작한다. 그 지식으로 더 나은 이름과 작은 인터페이스를 만들 수 있다.

테이블 이름만 보고 의미를 발명해서는 안 된다. 사용처를 모두 찾아 현재 코드를 읽고, 코드값 테이블과 필드가 무엇을 뜻하는지 알아내야 한다. 이 사례의 정확한 테이블 관계는 알려져 있지 않다.

애플리케이션 코드가 원시 스키마 대신 의미 있는 인터페이스에 의존하면 이후 변경을 그 경계 뒤에 둘 수 있고 스키마 어휘가 호출부로 다시 퍼지는 것도 막을 수 있다.

누출을 막은 뒤 데이터베이스를 바꾼다

원시 테이블명과 컬럼명이 애플리케이션 코드로 더 퍼지지 않게 한 뒤에는 경계 안에서 데이터베이스 개선을 시작할 수 있다. 구체적인 테이블과 관계는 알 수 없으므로 여기서 분명한 것은 순서뿐이다. 코드에서 스키마 어휘를 가두고 의미 있는 타입을 노출한 뒤 데이터베이스에 접근한다.

코드에서 시작하면 레거시 데이터베이스를 가둔 상태로 정적 타입과 컴파일러의 도움을 받을 수 있다.