RDB 모델링 설계시 추상화의 중요성과 거시적 관점이 왜 중요해 졌을까?(프로젝트 모델링 회고)

추상화?

추상화는 구체적인 무언가에 대해 본질적으로 그것을 묶는 그룹에 이름이라고 나는 생각하며 설계를 바라본다. 좀 더 흔히 하는 비유를 들자면 사자, 치타, 표범 같은 동물을 추상화시키면 고양잇과 동물이 되고 그 고양잇과 동물을 추상화시키면 포유류가 될 수 있다. 이처럼 세상 모든 것들을 RDB로 포함할 때는 사자, 치다, 표범처럼 구체화시켜 표현해 낼 수 있지만 워터폴 한 설계중심의 예전 서비스 들과는 달리 최근의 사용자들이 요구하는 것은 다양하며 시시때때로 변화한다. 그렇기 때문에 사용자들에게 이쁨 받기 위해 애플리케이션은 항상 유연하게 변모해야 하며 그렇게 하기 위해서는 추상화라는 개념 없이는 "유연한 요구사항에 항상 대응할 수 있는 설계"를 절대 할 수 없다고 생각한다.

예를 들어 나의 이번 마이그레이션을 진행할 프로젝트에 초기 요구사항은 다음과 같았다

• 경영진 : 자~ 25g씨 우리는 사자만 하면 돼요 사자만 빨리 만들어서 투자자들에게 우리의 개발 속도를 보여줍시다.
• 개발팀 : 아... 그러면 나중에 치타나 표범을 해야 할 일은 없나요? 이거 너무 중요한 사항인데 결정해 주세요.
• 경영진 : 없어요 일단 사자만 만들어서 1달후에 투자자 미팅이 있으니 그때까지 보여줘야 해요 어차피 MVP니까 그냥 리팩토링 할 시간 줄 테니 지금은 그냥 빨리만드는데 집중해 주세요.
• 개발팀 : ....넵..

대부분의 스타트업에서 흔히 있는 일이라고들 한다. 경연진의 시간적 압박, 개발에 대한 낮은 이해도, 주도적으로 설득시키지 못한 개발팀 아주 많은 실수들이 모여 괴물이 탄생했다.
괴물이라 표현한것은 나 자신에 대한 반성이자 앞으론 이런식의 요구사항을 유연하게 받는 방법, 미래를 고려한 설계를 향한 나의 경험이 되리라 좋게 생각을 하고 있다.
그렇다 위 이야기의 주인공은 다름아닌 나다. 핑계라면 많은 핑계들이 있었다. 와이어 프레임 페이지 수가 30장이 넘어가는 프로젝트를 1달 보름 만에 개발 인력이 나 포함 2명에서 작성 해야했고, 설계할 시간은 너무 없다 판단 했다. 그래서 구체화된 모델링 기반으로 정규화를 전부 3NF까지 한 후 빠르게 비즈니스 로직 개발로 넘어갔다 지금 생각해 보면 다른 많은 선택지가 있었음에도 나의 경험 부족으로 경연진을 설득 시키지 못했고 관성대로 "시키는 대로" 일이 진행 돼 버렸다..

거시적 관점

위와 같은 사건에서 내가 할 수 있는 선택지는 무엇이 있을지 생각해 보자

1. 노코드 툴로 빠르게 프로토타입을 만들어 시장검증 부터 한다.
2. 경영진의 요구사항 대로 하지 않고 기능을 더 줄여서 핵심기능만 골라 낸 후 도메인별로 최대한 유연하게 설계할 수 있게 요청드린다.
3. 시장검증을 위해 직접 개발할 도메인에 현업을 배우러 다니거나 현업자에 인터뷰를 따러 다닌다.
4. 좀 더 거시적인 관점으로 바라보고 추상화시켜 개발한다.
   물론 위 말고도 더 좋은 결과를 위한 수많은 방법 들이 있었겠지만 글을 쓰는 시점에 생각나는건 저정도이다.

본질적으로 내가 DB설계를 개판 쳤나? 그렇다고 보기엔 결과적으로 보면 나는 교과서대로 성능을 고려하여 3NF까지 정규화를 했고, 요구사항에 맞는 애플리케이션도 기간내에 만들어 냈으며, 그 결과로 인해 투자까지 성공적으로 이어졌다.
투자가 이어진 시점 이제 나에게 마지막 기회가 주어졌었다 라는것을 모른것이 이번 프로젝트의 또 하나의 실수이다.
이 마지막 기회가 무엇이라 하면... 다~!!!! 버리고! 새로 만들었어야 했다
이제는 위 1,2,3,4 를 할 시간이 주어 졌을 지도 모른다. 하지만 투자까지 됐다는 말에 안심하며 그대로 프로젝트를 진행시키는 것에 집중했더니 새로운 요구사항이 들어올 때마다 골머리가 썩어나갔었다.

 

거시적 관점, 다르게 말하면 미래예측이 될 수 있을 것 같은데. 미래 예측은 그렇게 대단한게 아니다. 오늘 팀장님이 짬뽕을 먹으러 가자 할것같은데 같은 사사로운 것들도 전부 미래 예측의 한 부분이다. 내가 요구사항으로 "사자"를 받았을때 아 이 "사자"가 들어왔다는건 언젠가 "표범"이나 "치타"를 만들어야 할 일도 있겠구나 하고 ERD를 설계할때 테이블 이름이 "사자"가 아닌 "고양잇과 동물" 정도로만 추상화 했어도, "사자가 고기를 먹는다"는 행위를 "고양이과 동물이 음식을 서비스한다."? 정도로만 추상화를 해 놨어도 이번에 개고생하며 마이그레이션작업을 할 일은 없었을지도 모른다.

 

요구사항은 항상 변화한다. 경험적으로 요구사항은 요구를 하는 사람도 뭘 얻고 싶은지 잘 모른다 그렇기 때문에 항상 의심하고 설계를 할 땐 요구사항 그 이상의 것을 보려 늘 노력해야 한다. 요구자는 뭘 요구하는지 모르고 요구하는 경우가 정말 많고 결국 가장 중요한 것은 본질적으로 나는 무엇을 설계해야 하는가였던 것 같고 그 본질을 집요하게 알아내고 파내는 것이 유연한 시스템 설계의 정말 중요한 덕목이었다 나는 그러지 못했고 그 죗값을 지금 톡톡히 치르고 있으며 이 죗값을 달게 받음으로 인해 한 단계 성장할 것이라 믿는다.

 

마지막으로 이번 회고 글에서 하고 싶은 말은 누구나 실수를 하고 현업 백엔드 개발 3년 차에 DB설계란 무거운 직무는 말 그대로 나에게 너무 무겁고 버거운 직무였다라고도 생각한다. 스타트업 특성상 개발자가 보안이며 설계며 다~ 해야 하는 환경에서 일을 하다 보니 그 무개를 모르고 덤벼든 것 같다.
하지만 그런 덕분에 많은 것을 몸으로 느끼고 배우며 성장할 수 있는 좋은 기회를 얻은 샘이니 이를 자책하기보단, 계속해서 회고하고 보완하며 더 나은 개발자가 될 수 있게 성장하는 게 현명하다 판단한다.

이제 푸념 그만 하고 마이그레이션 하러 가야지...