비즈니스 로직

서비스를 만들다 보면 기술과 상관없는 결정이 잔뜩 생깁니다. 무료로 쓰는 팀은 문서를 몇 개까지 만들 수 있는지, 결제가 실패하면 며칠까지 봐주는지, 초대받은 사람이 문서를 지울 수 있는지 같은 것들입니다. 프로그래밍 지식으로는 답이 나오지 않는 질문이고, 회사가 정하고 나면 코드 어딘가에 들어가야 합니다.

문제는 그 어딘가가 정해져 있지 않을 때 생깁니다. 웹 화면을 만들던 사람이 "문서 세 개를 넘으면 버튼을 막자" 고 화면 쪽 코드에 조건을 넣습니다. 몇 달 뒤 모바일 앱을 만드는 사람은 그런 규칙이 있는지 모른 채 만들고, 앱에서는 문서가 다섯 개까지 만들어집니다. 고객센터에 "앱에서는 되던데요" 라는 문의가 들어오고, 그때서야 규칙이 한 군데가 아니라 화면마다 따로 있었다는 사실이 드러납니다.

비즈니스 로직이라는 말은 이 규칙들을 한 자리에 모아 두자는 합의에서 나왔습니다. 화면을 그리는 코드도 데이터를 저장하는 코드도 아닌, 규칙을 판단하는 코드를 따로 두고 모든 경로가 그곳을 거치게 하는 것입니다. 그러면 규칙이 바뀌었을 때 고칠 곳이 한 군데가 됩니다.

요청 하나가 들어와 처리되는 길은 네 층으로 나뉩니다.

1. 화면 — 사용자가 보고 누르는 쪽입니다. 프론트엔드라고 부릅니다. 버튼을 누르면 서버로 요청이 날아갑니다.
2. 전달 — 요청을 받아 누가 보낸 것인지 확인하고 기록을 남기는 층입니다. 미들웨어가 이 일을 맡습니다. 여기서는 로그인 여부나 호출 횟수처럼 어느 기능에나 공통인 것만 봅니다.
3. 규칙 — 비즈니스 로직이 있는 자리입니다. 이 요청을 허용할지, 허용한다면 무엇을 바꿀지 판단합니다.
4. 저장 — 판단 결과를 데이터베이스에 반영합니다. 데이터베이스는 데이터를 저장하고 꺼내 쓰게 해 주는 시스템이고, 시키는 대로 넣고 뺄 뿐 판단하지 않습니다.

3번에서 벌어지는 일은 조건 확인의 연속입니다. 문서를 새로 만드는 요청이 들어왔다면, 이 팀의 플랜을 확인하고 무료일 때 지금 문서가 몇 개인지 세고 세 개 이상이면 거절합니다. 결제가 실패한 팀이라면 실패한 날로부터 며칠이 지났는지도 봅니다. 7일 안이면 읽기만 허용하고 8일째부터는 잠급니다.

규칙을 여기 두는 이유는 이 층만 모든 경로의 공통 통로이기 때문입니다. 웹에서 만들든 앱에서 만들든 외부 개발사가 API로 부르든 요청은 결국 여기로 들어옵니다. API 는 프로그램끼리 주고받기로 약속한 창구입니다. 화면 쪽에 규칙을 두면 화면 수만큼 사본이 생깁니다. 화면에서 하는 검사를 없애라는 뜻은 아닙니다. 그것은 사용자에게 미리 알려 주는 편의이고, 최종 판단은 아니라는 뜻입니다.

이 말이 오가는 자리는 셋입니다.

1. 기획과 개발 사이 — PRD에 적힌 정책이 그대로 이 층의 코드가 됩니다. PRD 는 무엇을 왜 만들지와 완료 기준을 적은 제품 요구사항 문서입니다. 기획서에 "7일 유예" 라고만 적혀 있고 7일이 지난 시점이 결제 실패 시각 기준인지 그날 자정 기준인지가 비어 있으면, 그 빈칸은 코드에서 누군가가 임의로 메웁니다.
2. 사람 손 없이 도는 작업 — 규칙이 필요한 곳은 사용자가 버튼을 누를 때만이 아닙니다. 매달 1일에 청구서를 만드는 크론 잡도 어느 팀에 얼마를 청구할지 같은 판단을 해야 하고, 백그라운드 작업으로 돌리는 대량 처리도 마찬가지입니다. 그래서 규칙은 화면에서 부르는 코드 안이 아니라 양쪽이 같이 부를 수 있는 자리에 둡니다.
3. 구조를 다시 짤 때 — 규칙이 흩어져 있으면 고칠 때마다 빠뜨리는 곳이 생깁니다. 도메인 주도 설계는 이 문제를 정면으로 다루는 설계 방법으로, 업무에서 쓰는 말과 경계를 코드 구조에 그대로 옮기자고 합니다. 기획자가 "워크스페이스" 라고 부르는 것이 코드에도 같은 이름으로 있으면, 규칙이 바뀌었을 때 어디를 열어야 하는지가 대화만으로 정해집니다.

"이건 화면 문제가 아니라 비즈니스 로직이 앱이랑 웹이 달라서 그래요."

같은 규칙의 사본이 두 벌 있고 둘이 어긋났다는 뜻입니다.

"그 판단은 프론트에서 하지 말고 로직으로 올려 주세요."

최종 판단을 서버의 규칙 층으로 옮기자는 요청입니다.

"기획서에 7일이라고만 돼 있는데, 시작 시점이 언제예요?"

규칙을 코드로 옮기려면 기획서에 없는 경계가 정해져야 한다는 말입니다.

페이지덱에서 이 대화가 길게 이어졌던 적이 있습니다. 결제 실패 유예를 7일로 정하면서 지현이 정책을 적었는데, 태오가 구현에 들어가기 전에 세 가지를 되물었습니다. 7일의 시작이 카드사 응답을 받은 시각인지 그날 자정인지, 유예 기간에 이미 있던 문서를 내려받는 것도 읽기에 들어가는지, 유예 중에 결제가 성공하면 며칠 치를 청구하는지였습니다. 셋 다 코드로 옮기려면 답이 있어야 하는 질문인데 기획서에는 없었습니다.

지현이 그 자리에서 정하지 않고 수아에게 물어본 것이 결과를 갈랐습니다. 기업 고객은 카드 정보를 경리 담당자가 관리해 실패를 알아채는 데만 며칠이 걸린다는 답이 돌아왔고, 유예는 7일이 아니라 14일이 됐습니다.

비즈니스 로직을 복잡한 알고리즘 같은 것으로 여기는 경우가 많습니다. 로직이라는 말이 어렵게 들려서 생기는 오해입니다. 실제로 이 층의 코드는 대부분 조건문 몇 줄입니다. 플랜이 무료인지 보고, 개수를 세고, 넘으면 거절합니다. 어려운 것은 코드가 아니라 그 조건이 무엇이어야 하는지를 정하는 쪽입니다. 그래서 이 층의 코드를 읽으면 회사가 지금까지 내린 결정이 그대로 보이고, 반대로 기획 문서에 없는 결정이 코드에만 남아 있는 경우도 이 층에서 발견됩니다.

두 번째는 화면에서 하는 검사도 비즈니스 로직이니 서버 쪽은 대충 해도 된다고 보는 것입니다. 화면에서 이미 막았으니 두 번 확인하는 것은 낭비처럼 느껴집니다. 하지만 화면은 사용자가 통제하는 영역이라 우회할 방법이 많습니다. 개발자 도구로 버튼을 되살리거나, 브라우저 없이 서버에 직접 요청을 보내면 화면의 검사는 아무 의미가 없습니다. 서버 쪽 검사를 빼 두면 무료 플랜으로 문서를 백 개 만드는 일이 실제로 일어나고, 그때는 데이터가 이미 들어온 뒤라 되돌리는 쪽이 비쌉니다.