몇년 전 모 입시학원에서 시스템 의뢰가 들어왔었는데...


보통 학원같은 곳은 어디서 빼내오는지 모르겠는데 학원 영업에 활용할 정보를 얻어다가 디비에 넣고 전화 돌려서 애들 땡겨오는 일을 하는 파트가 있음.


이 학원장의 경우는 자기들 영업 명단이 외부로 새어나가는 것 같다면서 가능하면 각 직원들에게 데이터의 모든 정보를 다 보여주지 않았으면 좋겠다고 함. 즉, 학원에서 일하는 직원들에게 제한적으로 정보에 접근할 수 있도록 해야 한다는 것.


예를 들어서 전화 돌리는 직원한테는 전번이랑 애새끼들 몇살인지 이런거, 그리고 회계쪽직원은 돈이 입금됐는지만 확인하면 되니까 이메일이나 전번같은 정보는 보여줄 필요가 없겠지.


모든 영업 타겟 정보(거기서는 영업 대상을 타겟이라고 하더군)가 하나의 테이블에 다 들어가 있고, 심지어 수강 이력, 계좌번호, 결제일 영업 성공한 직원 이름 등등이 모든 하나의 테이블에 다 들어가 있는거였음.


테이블 정규화를 오롯이 무시하고 지금 기억에는 필드가 120개였나, 아무튼 그럴건데, 이거 지들도 관리하려니까 쉽지 않거든..


그러니까 고객 정보 필드만 따로 모아서 가장 왼쪽에 밀어넣고, 전화 넣어서 안되면 o x표시하는 필드가 있고(이거는 지들이 그때그때 지운다고 함) 영업 성공하면 그 옆에 직원 이름 넣는 필드가 있고, 그러면 입금했을때 계좌번호, 입금일, 입금액같은걸 그 옆으로 줄줄이 필드마다 맞춰서 넣음.


하.. ㅅㅂ 그때 그나마 전산직원이라고 하기도 애매한 애가 하나 디비쪽 담당하는 일을 했는데 이 친구한테 왜 테이블 하나에 모든 정보를 다 때려넣었냐고, 이유가 있냐고 물어보니까 관리하기 편해서 그렇다고 하는데, 아마 정규화같은게 뭔지 모르고 그냥 엑셀 쓰듯이 했던거 같음.


그래서 일단 정규화로 테이블을 쪼개야 일이 된다고 하니까 주도권을 놓치고 싶지 않았는지(왜냐하면 입력, 수정을 얘 혼자 했으니까) 끝까지 결사 반대하며 one table 구조는 그대로 가져갔으면 좋겠다고 함. 학원장도 얘가 주로 전산 데이터 담당했는데 혹시라도 나중에 문제 생기지 않을까 우려해서 결국 자기 직원 설득에 넘어가서 one table구조를 전제로 직원별로 필드 접근에 제한을 거는 식으로 대폭 프로젝트 규모가 축소됨(이거는 내가 테이블 안쪼개면 할 수 있는게 줄어든다고 네고해서 줄여버린거임. 사실 이런 더러운 프로젝트는 피하는게 좋음.)



이리 하여 지금껏 전설로만 듣던 one table 아키텍처가 도입되는데...


학원장은 정보 접근을 최소한으로 하고 싶어했기 때문에 각 필드마다 권한레벨을 적은 간단한 텍스트파일을 만들고, 또 각각의 역할(role)을 정의해서 각 역할이 어떤 레벨의 필드에 접근할 수 있는지를 정의했음. 그리고 각 부서별로, 그리고 부서의 직원별로 접근 가능한 role과 바인딩하는 식...



그런데 이런 애들이랑 얘기를 해보면 지들도 뭐가 필요한지를 잘 모르는 경우가 태반임.


처음에는 자기들 주뎅이로 영업담당 직원(전화 돌리는 애들)들은 a, b, c, d, e, f 필드만 접근이 가능하고, 또 회계쪽 직원은 C, E, SS, CC 필드만 접근이 가능하고... 이렇게 떠들어서 확실합니까? 라고 해서 컨펌해놓고 나중에 보니까 회계직원이 한 명인데 이 친구가 쉬어버리면 입금 확인해줄 사람이 없는거임.


하... ㅅㅂ 그럼 이거 뭐 아무 의미도 없는거네?


지들도 이런 상황을 전혀 생각하지 못했는지, 아 그러네요? 그럼 어떻게 하죠? 이 지랄함.. 그걸 나한테 물어보면 안되지 ㅋㅋㅋ


결국 role vs 필드권한 구조가 더 유연해지는 쪽으로 설계가 바뀌고 시간은 속절없이 흘러감.


프로토타입 보여주면서 이렇게 이렇게 작동하게 된다, 저렇게 저렇게 하면 된다, 얘기하고 필드 권한 수정은 학원장만 할 수 있으니까, 권한 부여할때는 이 메뉴를 누르시구요, 이렇게 이렇게 하면 저쪽에서 볼 수 있어요.. 라고 얘기해주고 일이 끝나가는가 싶었는데, 자꾸 아쉬움이 남는지 '이거 좀 해주면 안돼요?', '이런게 해줬으면 좋겠는데요?' 짱나게 이런 소리 늘어놓음.


그거 다 하려면 애초에 테이블을 쪼개놓고 시작했어야 했는데 이제와서 그거 하려면 지금까지 한거 다 뜯어고쳐야 하고, 계약서 다시 써야 합니다 얘기했더니 표정 개썩음.



애초에는 영업대상 타겟들에 대한 지속적인 상태 관리(수강여부, 애가 몇 있는지 등등)를 하면서 이에 대한 직원들의 정보 접근을 최소한으로 줄이는게 목적이었는데 절반은 하지 못했던 듯.


사실 어찌어찌 해달라는대로 다 해줄 수도 있었지만 정규화 안된 테이블 가지고 필드 업데이트 하는게 도무지 답이 안나오는 상황이었음.


결국 예전처럼 전산 담당 하는 애가 직접 디비 건드려서 할 수 밖에 없었고, 학원장도 뭔가 좀 마음에 안드는 찝찝한 표정을 지음.



항상 느끼는거지만 모든 국민은 자기들 수준에 맞는 정부를 갖는다는 말처럼 그 회사 사람들의 수준이 시스템의 수준인듯.


도메인 담당자들의 질이 떨어지면 절대 그 이상 좋은 시스템이 안나온다.