본문 바로가기
가치관 쌓기/개발 돌아보기

개발DB 꼭 필요한가요? 진짜 필요한거예요?

by simplify-len 2023. 2. 24.

Photo by Campaign Creators on Unsplash

배경

 회사를 옮기고 적응하는 과정에서, 개발 DB 대한 고찰을 하게 되었다. 스타트업 회사는 제한적인 리소스에서 최고의 효율을 내야만 했던 회사였으며, 이번에 옮긴 회사는 리소스가 풍부했기 때문에 무엇이든 할 수 있었다. 그 과정에서 '개발 DB는 무엇을 위해 필요로 하는가?'에 대한 생각을 하게 되었다.

들어가기

 개발자가 일하는 대부분의 환경은 다음과 같은 형태로 일을 하게 된다.

프로덕트 DB(Product DB) ----- 개발 DB(DevelopDB) ----- 로컬(LocalDB)

 이런 형태는 하나의 기능을 개발하고 테스트해서 최종적으로 릴리즈 되기 까지 3가지 타입의 DB을 활용하게 된다. 동작되고 있는 프로덕트에 릴리즈하기 직전까지 개발자들끼리 기능 구현시 활용하는 DB는 개발 DB. 기능을 배포하고, QA를 시작한다.

또는 다음과 같은 형태의 DB 을 사용할 수 도 있다. 규모가 큰 다우기술에서 다음과 같은 형태의 DB 가 있었다.

프로덕트 DB(Product DB) ----- 스테이징DB(StagingDB) ----- 개발 DB(DevelopDB) ----- 로컬(LocalDB)

 위와 같이 4가지 타입을 가진 계층으로 스테이징DB는 인프라스트럭쳐 팀에서 릴리즈 직전에 정상적으로 프로젝트가 잘 동작하는지 확인하기 하기 위해 만든 DB이다. 스테이징DB는 인프라스트럭쳐에 팀에서 관리되어지는 DB이다.

마지막으로, 이직하기 직전에 근무하던 스타트업에서는 다음과 같은 단순한 형태로 개발했다.

프로덕트 DB(Product DB) ----- 로컬(LocalDB)

 이 글을 읽는 사람들은 무엇가 이상하다고 느낄 수 있다. 개발 DB가 없다. 그렇다면 개발한 것을 어떻게 테스트할것인가? 라는 물음이 나올 수 밖에 없다. 정말 그런가?

이 쯤에서 이상하다고 느끼는 사람들에게 물어보고 싶은 것이 있다. "개발 DB가 왜 필요한가요?", "무엇을 테스트하고 싶으신가요?"

 

본문

 스타트업에서 근무할 적에도 빈번하게 개발 DB는 있어야 하는가? 없어도 되는가? 에 대해서 개발자들끼리 논의가 있었다. 그 당시 결론 내렸던 결과는 '언제나 서두를 필요가 없다' 결론이었다. 개발 DB 가 있으면 좋지만 없어도 무관하다. 그렇게 생각한 이유에 대해서는 뒤에서 조금 더 이야기해보자.

이번에 옮긴 회사에서도 결이 비슷한 고민을 하게 되었다.

 개발 DB는 있지만, 반대로 로컬 DB는 사용하지 않은 형태이다. 모두가 여러 개의 개발 DB 을 사용하고 있는데, 이것은 개발자 간에 공유해서 사용하는 DB이다.

이렇게 될 경우 다음과 같은 문제점을 겪게 될 수 있다.

1. 개발 DB에 의존한 형태로 개발될 수 있다.
2. Branch 변경 시, Release 시점에 따라 코드가 정상적으로 동작하지 않을 수 있다.
3. DB Schema에 대한 History 관리가 되지 않는다.

 조금 더 구체적인 상황을 이야기해보면 다음과 같다. 새로운 개발자가 입사하여 프로젝트를 빌드한다. 문제없이 빌드 된 것을 확인했고 동작까지 잘 되는 것처럼 보이지만, 특정 Table 컬럼을 찾을 수 없다는 Exception 또는 Enum 의 타입이 없다는 것을 발견하게 될 수 있다.


그렇다면 스타트업에서는 개발 DB 없이 어떻게 개발했을까?

개발 DB 가 없어도 프로젝트가 진행할 수 있었던 주된 이유는 테스트 코드에서 발견할 수 있다. 스타트업에서 근무할 때, CTO 님은 종종 이런 말을 자주하곤 했다.

f(x) = true 이고, g(y) = true 이면 f(g(y)) 는 무엇일까?
true 이다. 

점진적으로, 반복적으로

 점진적으로 테스트의 범위를 넓혀 가는 것이 개발 DB가 없을 수 있었던 주된 이유라고 생각한다. 결합도가 낮고 응집도가 높은 형태의 아키텍처가 만들어질 수 있다면 영역별 테스트 코드의 신뢰성을 높여준다. 도메인 계층, 애플리케이션 계층, 웹 계층. 각 계층에 대한 테스트 코드를 신뢰할 수 있다면 문제가 없음을 밝힐 수 있다.

그럼 다시, 개발 DB 가 있어야 하는 이유는 무엇이었을까? 바로 데이터 의존 테스트가 필요하기 때문이다. 다우기술이라는 대기업에 있을 때도 똑같이 테스트했던 적이 떠올랐다. 기능을 구현한 코드를 만들어 놓고, Build, Run 한 뒤에 드래그앤 드랍으로 기능에 대해 테스트했다. 이렇게 하다 보니, 문제점은 내 머릿속에 있는 성공 사례에 대해서만 누르고 있는 내 모습을 발견하곤 했다.

그러므로, 각 계층에 대한 코드에 대해서 신뢰할 수 있을 만큼의 테스트 코드는 개발 DB 가 굳이 필요하지 않도록 만들어 준 것이다.

정말 필요가 없을까?

 계속 정말 필요하지 않은지 고민해봤을 때 정말로 필요한 순간이 있을 수 있다. 바로 E2E(EndToEnd) 테스트할 때는 필요할 것 같다. MSA 환경에서는 이해관계자와의 의사소통이 중요하다. 동시에 더 중요한 건 눈에 보이는 동작하는 소프트웨어라고 생각한다.

 위에서 언급된 DB형태 중 아래와 같은 형태를 가진 회사가 있었다.

프로덕트 DB(Product DB) ----- 스테이징DB(StagingDB) ----- 개발 DB(DevelopDB) ----- 로컬(LocalDB)

여기서 개발 DB 를 제외한 형태가 가장 이상적이라고 생각한다.

프로덕트 DB(Product DB) ----- 스테이징DB(StagingDB) ----- 로컬(LocalDB)

 여기서 스테이징 DB는 개발자가 관리하는 DB가 아니다. 인프라스트럭쳐를 관리하는 팀이 관리하는 DB이다. 그렇지 않다면, 개발자만 알 수 없고 QA, Infra만 접근 가능한 DB 가 있는 형태로 가져가는 것은 어떠할까? 이런 관점이라면 개발 DB는 필요할 수 있다고 생각한다.


결론

 사실 우리가 개발하는 환경에서는 개발 DB가 있냐? 없느냐? 가 중요한 요소는 아닐 수 있다. 각 환경에서 어떻게든 자신의 퍼포먼스만 낼 수 있다면 문제가 없다고 생각한다. 단순히 조금 더 나은 환경이 있을 뿐이라고 생각한다.

댓글