흔히들 데이터 양이 많으면 비즈니스 로직이 복잡해진다고 생각할 수 있다. 하지만, 데이터의 양과 비즈니스 로직의 복잡도는 그리 관계가 없다. 오히려 데이터 내의 개념들의 양과 더 깊은 관계가 있다. 가장 단순하게 게시판 글을 생각해봐도 그 내용이 한없이 길어도 단순히 내용만을 보여준다면 비즈니스 로직은 그리 복잡할 것은 없다. 하지만, 그 게시판의 글의 내용에 대한 의미들을 분석해서 나름대로 체계적으로 보여준다면 이는 이를 어떻게 보여주어야 하는 개념들만큼 복잡도가 증가하며 그 개념들 간의 관계까지 고려한다면 기하급수적인 비즈니스 로직이 생겨날 수 밖에 없다.

TodaysArt 2008 - 16n _ ƒ5³
TodaysArt 2008 - 16n _ ƒ5³ by Haags Uitburo 저작자 표시비영리동일조건 변경허락


게시글을 서론, 본론, 결론의 형태로 묶음 단위를 생각해서 화면에 보여준다면, 텍스트 내에서 이를 구분할 수 있는 구분자가 삽입되어서 저장되어야 하며, 조회 역시 이를 체크해서 서론, 본론, 결론의 형태로 화면 출력을 해주어야 한다. 다시 여기에 이들 간의 관계를 엮는다면 서론은 반드시 본론 앞에 오고, 본론은 반드시 결론 앞에 온다는 규칙을 추가해볼 수 있다. 또한, 이들은 각각 서로 다른 화면에서 서론만 보여주거나, 본론의 일부, 혹은 결론의 일부를 보여줄 수도 있을 것이다. 물론, 좀더 복잡해진다면 서론과 본론, 혹은 결론끼리의 조합도 생각해볼 수 있다. 이제 비즈니스 규칙은 좀 더 세분화되고 복잡해지기 시작한다. 처음에는 단순하게 게시글이라는 하나의 큰 데이터 덩어리로 생각했는데, 해당 내용에 대한 분석의 의미를 더함으로써 비즈니스 로직은 더 복잡하게 된다.

지금의 웹과 기술은 기존의 단순한 정보 덩어리를 하나의 관점에서 처리하는 시대에서 그 정보 덩어리를 좀더 의미있는 정보의 조각으로 세분화시켜서 차별화나 더 자세한 정보를 표현하고자 한다. 이는 데이터에서부터 비즈니스 로직까지, 혹은 아키텍처 영역까지도 영향을 미친다. 단순히 하나의 텍스트 덩어리에 구분값을 삽입하던 정보는 여기 저기 찣겨져서 흘러다녀야 하며, 때로는 전혀 다른 정보와 조합을 해야 한다.

아주 적은 양의 데이터라 하더라도 데이터가 사용되는 목적과 지점, 그리고, 그 데이터의 구조, 관계에 대한 의미들이 비즈니스 로직의 복잡도를 증가시키게 된다. 빅 데이터 시대에 이러한 비즈니스 복잡도의 영역도 같이 고려해볼 수 있다. 단순히 데이터가 큰 것만을 관리하는 형태가 아니라, 데이터와 데이터의 관계, 세분화 등의 내용은 앞으로 더 크게 확장되고 고려해야 할 영역이 된다.

이와 같은 형태의 시스템을 위해서는 무엇보다도 정확한 의미의 규칙을 정의하는 것이 무엇보다 중요하다. 서론, 본론, 결론의 세부분으로 나누는 규칙은 서론과 결론으로도 의미가 있는지, 혹은 본론과 결론 만으로도 구성된 정보가 사용될 수 있는지, 혹은 본론의 일부 영역을 어느 영역까지를 의미하는지를 명확하게 정할 필요가 있다. 규칙의 명확화는 바로 시스템에 그대로 적용되며, 이는 시스템의 특성이나 사용자의 영역별로도 상당히 세분화가 될 수 있다. 과거의 '게시글을 화면에 보여준다'라는 규칙은 서론, 본론, 결론을 어떠한 조합으로 어떠한 순서로, 그리고 화면의 크기나 사용자의 특성별로 어떻게 보여줄지에 대한 더 자세한 규칙을 필요로 한다. 규칙의 세분화로 인해서 이를 처리하는 비즈니스 로직은 점차 복잡해질 수 밖에 없다.

또한, 데이터 사이의 조합의 영역에는 새로운 형태의 정보나 규칙이 발생된다. 서론과 결론이라는 두가지 영역이 조합되어서 순서, 표현방법 등 다양한 개념들이 더 나타나며, 이를 처리하기 위한 별도의 영역도 생겨난다. 단순히 데이터의 결합이 정보 양의 증가만을 의미하는 것이 아니라 더 복잡하고 거대한 비즈니스 로직을 만들어내며 이러한 경우의 수들이 증가함에 따라 검증하는 노력 역시 급증할 수 밖에 없다. 더 확장성을 고려한다면, 서론, 본론, 결론의 영역이 서로 조합이 가능하도록 전반적인 아키텍처 구조를 개선시킬 수도 있다. 심지어는 게시글 이외에도 타시스템이나 다른 유형의 광고성 글들도 조합될 수 있는 형태도 고려해야 한다.

데이터가 증가하는 것 못지 않게 비즈니스 로직의 증가 역시 무시할 수 없으며, 단순히 양의 증가가 비즈니스 로직의 복잡도를 말해주지 않는다. 데이터가 가지는 의미와 내재적인 구문의 파악이 먼전 선행되어야 이러한 비즈니스 로직의 복잡도를 관리할 수 있는 형태로 구성이 가능하다. 
저작자 표시 비영리 동일 조건 변경 허락
신고
군대를 다녀온 사람은 익히 잘 알 것이다. 기준의 중요성을. 아니, 군대식으로 통제되던 시절의 중고등학교 시절을 나온 사람들도 충분히 알 수 있을 것이다. 일련의 단체를 일렬로 정렬한다는 자체가 얼마나 어려운 것인지를. 우르르 몰려나온 사람들을 정렬하는 것은 기준을 세우는 것이다. 기준이라는 소리에 모두가 경청하고 오와 열을 맞추고 앞뒤의 간격을 적당하게 유지시키는 노력들을 개인에게 부여한다. 만일 기준의 상체나 하체가 다른 각도로 서있으면 전체의 줄이나 열이 삐딱하게 되는 것을 아침 조례 시간에 경험해본 사람들은 알 것이다.

We brake for nobody!
We brake for nobody! by leg0fenris 저작자 표시비영리변경 금지


SW 개발시에도 기준은 상당히 중요하다. 그것도 제일 처음에 어떠한 형태로 해당 산출물이 만들어졌는지에 따라서 이후의 만들어진 산출물들은 거기에 영향을 상당히 받는다. 어찌 보면 커뮤니케이션이 닫혀진 조직의 속성도 있으며, 무엇인가 고민하면서 왜 그래야 하는지를 반문하면서 새로운 형태로 만들어가려는 노력을 제약받는 환경에서 어쩔 수 없다라는 생각도 들지만, 이러한 현상은 집단 사고에 속하기도 한다.

요즘엔 특정 조직이 템플릿이나 가이드 등을 만들어서 그대로 수행하라는 압박을 주기도 하며, 누군가가 형상관리에 최초에 올려놓은 것을 보고 그대로 좇아서 수행하는 경우도 있다. 그 누구가 되었든 간에 처음 형상관리에 올려놓은 산출물은 바로 기준이 된다. 이 산출물이 예제라고 하더라도 바로 기준이 되어버린다. 소스코드의 주석, 형상관리 항목(소스파일, 디렉토리, 설정파일, 바이너리 파일 등) 이 모든 것들의 최초 산출물은 바로 기준이 된다.

많은 사람들이 동일한 활동을 하는 그룹에서는 최소한 남들만큼만 하기를 원한다. 무엇인가 튀어나오면 감사에 걸리며, 왜 그렇게 되었는지에 대한 심문을 받아야 한다. 하지만, 처음의 기준이 잘못되었다면, 혹은 아무런 의미없이 올려진 산출물이라면 그 이후의 산출물들을 바로 잡기란 여간 난처한게 아니다. 주석이 없는 소스 코드를 보고 이후의 개발자들은 주석이나 형상 변경 정보를 올리지 않는다. 거의 백명에 가까운 개발자가 동시다발적으로 수행하는 프로젝트에서는 이러한 현상을 바로 잡기가 힘들다. 마치 수십년동안 좌측통행에 익숙한 사람들이 어느날 갑자기 우측통행을 하라고 해도 그게 잘 안지켜지는 것처럼.

SW 개발에 참여하는 사람들은 개별 기술에 대해서 깊숙하고 광범위하게 익숙해져야 하고, 언제든지 개발 방식에 대해서 이야기할 수 있어야 한다. 기존의 기준을 세우는 방식은 개발자의 머리를 점점 굳어지게 만든다. 개인이 편한 방식을 아예 처음부터 방지하게 만드는 것이 아니라, 효과적이고 건전한 방식으로 유도해야 한다. 왜 그래야 하는지를 피부로 직접 체험하게 만들어야 한다. 또한, 비관적인(pessimistic) 관리/통제 방식이 아닌 낙관적인(optimistic) 관리/통제 방식으로 개발자의 부담을 덜어주어야 한다. 즉, 무조건 이것은 하고 저것은 하지 말아야 된다는 방식보다 잘못 어긋나는 방식에 대해서 모니터링하고 왜 그러지 말아야 될지에 대해서 기분이 나쁘지 않게 유도해야 한다.

언제까지 기준만을 탓하고 기준을 세우는 작업을 해야하는 것일까. 그러한 통제의 노력은 수많은 비용이 든다. 운동장에 아무렇게나 서있다고 해서 교장 선생님의 훈화를 안듣는 것은 아닐게다. 오와 열을 똑바로 맞추어서 부동자세로 서있다고 하더라도 교장 선생님의 훈화를 전체가 이해하고 듣는다고 생각하는 자세는 이제 시대를 잘못 파악하는 것은 아닐런지. 개발자에게 더 많은 자유와 책임을 부여하고 생산성이 나는 도구를 통해 자기 스스로 기준을 세울 수 있도록 가이드하는 것이 더 중요하다. 물론, 그러한 기준은 특정 방향성에 부합되도록 만들도록 하지만, 접근 방식이 다르다는 것으로 틀리다는 환경을 만들어서는 더더욱 안된다. 오와 열이 정렬된 학생들은 마음속에 서로 다른 생각으로 가득 차 있어서 교장 선생님의 말씀이 결코 귀로 들어가지 않는다.
저작자 표시 비영리 동일 조건 변경 허락
신고
시스템에서 데이터는 다양한 경로를 통해서 내외부로 흘러들어가며, 이는 해당 데이터를 처리하는 코드의 견고성과 건전성을 해치는 원인되기도 합니다. 특히, AS-IS 시스템을 TO-BE 시스템으로 전환하는데 있어서 데이터 마이그레이션과 같은 작업은 적게는 수백개에서 많게는 수천개에 달하는 테이블의 매핑으로 인해서 수많은 오류 데이터를 낳게 됩니다. 이는 AS-IS와 TO-BE의 매핑이 그리 간단하고 쉬운일이 아니기 때문에 발생할 수 있는 오류들 중에 가장 큰 비중을 차지하고 합니다.


His Hand
His Hand by h.koppdelaney 저작자 표시변경 금지


일반적으로 어느 특정 경로를 통해서 입력과 출력의 대상이 되는 데이터를 처리하는 코드는 정해진 비즈니스 규칙에 의해서만 동작하도록 만들어져 있기 때문에 이와 같이 다른 경로를 통해서 입력/출력되는 데이터에 대한 오류에 대해서는 대부분이 에러나 오작동을 하게 만드는 원인이 되기도 합니다. 즉, 데이터의 경로를 통제하고 해당 데이터 값을 무결화시키는 작업이 이러한 에러나 오작동을 최소화시키는 일이지만, 요새와 같이 다양한 접점을 통해서 들어오는 데이터 흐름 경로들은 코드의 견고성과 건전성에 심각한 위험이 되는게 사실입니다.

이를 위해서는 코드가 나름대로 자기 자신을 지키기 위한 수단으로 방어적인 코드를 가지고 있을 필요가 있으며, 그 방어적인 수단은 다양한 형태로 코드에서 표현될 수 있습니다.

1. 정합성 강화
데이터는 조회와 입력은 연산을 처리하기 전에 데이터의 올바름을 검증하기 위한 정합성 로직을 필요로 합니다. 통상 입출력 경로가 어느 특정 코드에서만 처리될 수 있도록 정해진 경우에는 이러한 정합성에 대한 강도가 그리 크지 않아도 크게 문제가 되지는 않습니다. 예를 들어, 웹 화면에서 넘어오는 데이터들은 어느 정도 UI에서 데이터의 정합성 수준을 맞추어주기 때문에 서버에서는 이에 대한 정합성이 크게 필요하지 않을 수도 있습니다. 또한, 이러한 경로를 통해서 들어와서 테이블 상에 저장되는 데이터들 역시 이를 다시 조회했을 때에 그 값들에 대한 의미에 대해 크게 의심할 부분이 없을 것입니다.
하지만, 테이블 상에 놓여있는 데이터가 이와 같은 특정 코드를 통해서 만들어진 것이 아니라, 다른 접점의 코드나 데이터 마이그레이션과 같은 처리로 테이블에 놓여있다고 가정한다면, 해당 데이터를 조회하는 시점부터 그 값들의 정확성을 검증해야 할 것입니다.
예를 들어, 남녀의 구분을 '1'과 '2'로 표현하는 데이터가 있다고 한다면, 정해진 경로를 통해서 들어오는 데이터에 대해서는 해당 값이 있는지만을 점검하기만 하면 될 수도 있을 겁니다. 하지만, 다른 경로를 통해서 들어온 이 값에 대해서는 실제 '1'혹은 '2' 값이 있는지, 그리고, 남자일때('1') 필요한 값들이 모두 충족하는지와 같은 별도의 정합성을 강화시키는 코드를 필요로 할 것입니다. 이는 비즈니스 로직의 재사용하고도 관련이 있는데, 동일 데이터를 처리하는 비즈니스 로직이 분산되면 될수록 이러한 데이터에 대한 정합성 강화와 같은 방어적인 프로그래밍은 추후 발생될 수 있는 오류를 사전에 방지해줄 수 있습니다.

2. 오퍼레이션의 시그너처의 세분화
오퍼레이션은 그 기능에 따라서 범용성의 정도를 표현해볼 수 있습니다. 동일 패턴으로 인한 코드 중복을 피하기 위해서 다소 범용적인 형태로 프로그래밍을 하는 경우도 있습니다. 즉, 입출력 파라미터들이 Collection 유형이거나, Object와 같은 유형으로 시그너처를 만드는 경우에, 그 내부에서는 다양한 경로의 비즈니스 로직들을 단순화시켜(혹은 추상화시켜) 처리하는 경우들이 있습니다. 이러한 경우에는 오류가 있는 데이터에 대한 일반적인 처리를 불가능하게 하거나 기존 코드를 더 복잡하게 만들 우려가 있기 때문에 오류가 발생할 수 있는 경우에 따라서 오퍼레이션을 더 세분화시켜 명확한 오류 지점이나 값을 빨리 찾을 수 있게 해야 합니다. 하지만, 너무 세분화시키거나 분리된 오퍼레이션들은 결국 유지보수를 어렵게 만들거나 동일 비즈니스 로직의 분산의 결과를 초래하기 때문에 유의할 필요는 있습니다. 다만 너무 보편화/일반화시킨 오퍼레이션은 이러한 오류 데이터의 대응을 더 힘들게 만들 수도 있습니다.

3. 구간별/유형별 테스트 방법 강화
데이터 흐름의 경로의 다양화는 테스트 유형의 다양화로 나타날 수 있습니다. 즉, 데이터 흐름을 통제할 수 있는 수준으로 최소화시키는 것이 테스트 유형을 최소화시키는 방법일 것입니다. 코드를 최대한 건전하고 견고성있게 유지하기 위해서는 결국 테스트로 검증을 할 수 밖에 없으며, 이는 비즈니스 로직을 개발하는 개발자에게 상당한 부담이 될 수 밖에는 없을 것입니다. 다양한 유형의 테스트를 통해서 발생할 수 있는 오류를 사전에 점검해보고, 이를 다시 코드에 반영하는 노력은 단순한 경우에는 그리 부담이 되지 않을 수도 있겠지만, 다양한 데이터 흐름의 경로를 가지는 시스템에서는 어느 한 사람의 노력보다 더 많은 사람들의 노력을 필요로 하며, 이는 전체적인 관점에서 검증의 방법을 만들어야 합니다.
예를 들어, 데이터 마이그레이션을 통해서 입력된 데이터들은 온라인에서 실행되는 코드를 통해서 다시 조회해서 비즈니스 로직을 처리하도록 테스트를 만들어야 하며, 그에 대한 결과를 다시 데이터 마이그레이션 코드에 적용해야 합니다. 일반적으로 이 두개의 로직을 처리하는 팀이 구분되어 있고, 서로 다른 영역에서 작업을 하기 때문에 이러한 부분은 특정 한팀이나 개인이 처리하기에는 어렵습니다.

방어적 프로그래밍은 결국 해당 비즈니스 로직을 담는 코드를 최대한 단일화시킨다고 해서 해결될 수 있는 문제는 아닙니다. 그러한 경우, 해당 코드는 상당히 복잡한 구조와 (원래를 요구사항에서 정의되어 있지는 않지만, 내부적인 요구에 의해서 새로 발생되는) 비즈니스 로직을 만들게 됩니다. 또한, 불필요한 코드를 만들어낼 수 있기 때문에 방어의 수준과 비즈니스 로직의 중복 분산의 수준을 적절하게 조정해야 합니다.
저작자 표시 비영리 동일 조건 변경 허락
신고

+ Recent posts