업무 시스템 다시 만들기 (3) 뼈대는 같고 도메인만 달랐습니다

제품이 늘어나며 공통부를 어떻게 갈랐는지 다룹니다. 시리즈의 다른 글 보기

안녕하세요. 오픈소프트랩 개발팀입니다.

1편에서 애자일 방법론을 버린 이야기를, 2편에서 다른 시스템에 붙어야 했던 이야기를 했습니다.

이번 편은 제품이 여러 개가 되면서 생긴 문제입니다.

다른 제품인 줄 알았습니다

사업관리 도구를 만들고, 개발 운영 도구를 만들고, 프로젝트 관리 도구를 만들었습니다. 고객이 다르고 화면이 다르고 쓰는 용어도 달랐습니다.

• 한쪽은 사업이라 부르고 다른 쪽은 프로젝트라 부릅니다
• 한쪽은 요구사항을 다루고 다른 쪽은 변경 요청을 다룹니다
• 한쪽은 산출물을 관리하고 다른 쪽은 소스 버전을 관리합니다

그래서 각각 만들었습니다. 도메인이 다르니 당연하다고 봤습니다.

세 번째쯤에서 같은 걸 또 만들고 있었습니다

세 번째 제품을 만들면서 이상하다는 걸 느꼈습니다.

용어를 걷어내고 보니 하는 일이 같았습니다.

무언가를 등록한다
담당자를 정한다
상태를 옮긴다
결재를 받는다
이력을 남긴다
현황을 본다

용어만 다르고 구조는 같았습니다. 요구사항이든 변경 요청이든 보안 점검이든, 등록되고 담당자가 붙고 상태가 바뀌고 이력이 쌓입니다.

특히 결재가 그랬습니다. 제품마다 결재를 따로 만들고 있었는데, 결재선을 정하고 순서대로 돌리고 반려되면 되돌리는 동작은 완전히 같았습니다. 다른 건 무엇을 결재하는가뿐이었습니다.

가르는 기준을 찾는 데 오래 걸렸습니다

"공통부를 빼자"는 쉽습니다. 어디까지가 공통인지 정하는 게 어렵습니다.

처음에는 화면을 기준으로 갈랐습니다. 비슷하게 생긴 화면은 공통으로 만들었습니다. 이건 금방 실패했습니다. 비슷해 보여도 제품마다 붙는 항목이 달라서, 공통 화면에 조건 분기가 계속 붙었습니다. 나중에는 분기가 너무 많아 원래 코드보다 읽기 어려워졌습니다.

그다음에는 데이터를 기준으로 갈랐습니다. 같은 테이블을 쓰면 공통이라고 봤습니다. 이것도 문제가 있었습니다. 저장하는 모양이 같아도 검증 규칙이 제품마다 다릅니다. 어떤 제품은 결재 없이 완료할 수 있고 어떤 제품은 안 됩니다.

지금 쓰는 기준은 이겁니다.

동작이 같으면 공통, 규칙이 다르면 도메인

결재선을 돌리는 동작은 공통입니다. 몇 단계를 거쳐야 하는지, 누가 반려할 수 있는지는 도메인입니다. 상태를 옮기는 동작은 공통입니다. 어느 상태에서 어느 상태로 갈 수 있는지는 도메인입니다.

이렇게 가르니 공통부에 조건 분기가 줄었습니다. 분기가 생긴다는 건 대개 도메인을 공통부에 밀어 넣었다는 신호였습니다.

그래서 다음 제품이 빨라졌습니다

가르고 나니 새 제품을 만들 때 도메인만 쓰면 됐습니다. 등록·담당자·상태·결재·이력·현황은 이미 있고, 그 위에 그 업무만의 규칙을 얹는 식입니다.

제품이 늘어난 속도도 여기서 나왔습니다. 7종을 만들었다고 하면 많아 보이는데, 일곱 번 처음부터 만든 게 아닙니다.

그리고 제품끼리 붙일 수 있게 됐습니다. 사업관리에서 만든 작업이 개발 운영 쪽으로 넘어가고, 거기서 나온 산출물이 다시 사업관리의 현황에 잡히는 식입니다. 뼈대가 같으니 넘기는 비용이 낮았습니다.

보안 업무에서 처음 어긋났습니다

한동안 이 기준이 잘 맞았습니다. 새 도메인이 와도 등록·담당자·상태·결재·이력으로 대부분 표현됐습니다.

보안 운영을 맡으면서 처음으로 안 맞는 게 나왔습니다.

기존 뼈대에서 일은 담당자가 끝냅니다. 담당자가 처리하고 상태를 옮기면 완료입니다. 결재가 붙어도 마찬가지로 조직 안에서 끝납니다.

그런데 보안 이벤트는 당사자에게 물어봐야 끝나는 건이 있었습니다. 탐지된 행위가 위반인지 아닌지는 그 행위를 한 사람만 알기 때문입니다. 담당자가 아무리 들여다봐도 판단이 안 서는 지점이 있습니다.

기존 뼈대에는 조직 밖의 누군가에게 묻고 답을 기다리는 단계가 없었습니다.

• 물어본 뒤 답이 안 오면 어떻게 할 것인가
• 기다리는 동안 이 건은 무슨 상태인가
• 끝내 답이 없으면 완료로 볼 것인가 아닌가

등록·담당자·상태·결재·이력 어디에도 이 질문의 답이 없었습니다. 그래서 칸을 하나 더 만들어야 했습니다.

뼈대를 늘려야 하나

지금 판단이 필요한 지점입니다.

이 단계를 공통부에 넣으면 다른 제품에서도 쓸 수 있습니다. 실제로 쓸 데가 보입니다. 외부 협력사에 확인을 요청하거나, 다른 부서에 사실 확인을 요청하는 일은 보안 업무 말고도 있습니다.

그런데 지금은 보안 쪽 도메인에 두고 있습니다. 한 제품에서만 쓰는 걸 공통부에 올렸다가 조건 분기가 늘어나는 상황을 앞에서 겪었기 때문입니다. 같은 실수를 반복하지 않으려면 두 번째 사례가 나올 때까지 기다리는 편이 낫다고 봤습니다.

다만 기다리는 쪽에도 비용이 있습니다. 두 번째 사례가 나오면 그때는 이미 양쪽에 비슷한 코드가 있을 테고, 합치는 작업을 따로 해야 합니다.

그래서 지금은 두 번째 사례가 나올 때까지 기다리되, 기다리는 동안 양쪽이 같은 모양을 유지하게 두고 있습니다. 나중에 합칠 때 드는 비용을 미리 낮춰두는 쪽입니다.

이 단계를 어떻게 만들었는지는 다음 시리즈에서 따로 쓰겠습니다. 물어보고 답을 기다리는 절차를 업무 시스템 안에 넣는 일이 생각보다 복잡했습니다.

보안 운영 포탈 이야기는 보안 포탈 설계 시리즈에서 이어집니다.

오픈소프트랩 개발팀이 작성합니다. 보안 운영 포탈과 생성형 AI 사용 통제를 만들고 있습니다.