시스템 개발의 목적은

해당 시스템이 탄생해서 생명을 다할때까지 그 시스템이 추구하는 business rule이 적용된 process가 만들어내고 취급하는 데이터를 고품질로 생산하고 유지하는 것이 목적이다.

고품질이 아니라면 요즘 세상에서는 의미가 없다. Machine learning이 가능하고 AI기술이 발전할 수 있는 이유도 고품질의 데이터가 많아 졌기에 가능하다는 사실을 잊어서는 않된다. 우리가 의도하던 하지 않던 세상은 고품질의 데이터를 그것도 많이 필요로 한다.

시스템 구성의  양대산맥 : 프로세스와 데이터

개발자입장에서 시스템 구축에 있어 필요한 요소는 여러가지가 있겠지만, 본인은 크게 두가지 관점으로 나누어서 바라본다.

그것은 "프로세스"와 "데이터"다.

프로세스는 '수단', '시간적 flow', '과정', '개발', '프로그래밍'이라는 단어로 표현할 수 있고, 인지한 범위내에서 최선의 선택(개발)이 가능하다.

데이터는 '목적', 'snapshot', '결과', '설계', 'DB'라는 단어들과 밀접하며 전체를 보아야만 최선의 판단(설계)을 할 수 있다.

프로세스와 데이터는 떨어질수 없는 System의 구성요소이나 특징은 서로 많이 다르다.

갑자기?

그럼 개발은 누가하고 설계는 누가하는가? 

보통 개발경력이 좀 쌓이면 설계역할을 맏게 되는데 설계자 역할을 맏게 되는 그 이유가 웃긴다.

개발이 힘들어서, 설계를 해보고 싶어서, 관리자들이 시켜서, 나이가 드니 뭔가 하나의 전문 업무영역이 필요할 것 같아서.. 등등이다.

어떤 이유든 설계에 대한 지식이 있다면 상관없지만, 관리자들이 착각하는 것이있다.

프로세스영역을 주로 다루던 개발자가 연차가 쌓이고, 프로젝트 수행경험이 많아지면 설계능력이 생기는 줄 안다는 것이다.

그리고 그들에게 갑자기 설계자 역할을 시킨다. 프로젝트가 잘 되기를 기대하면서..

경험이 쌓이면 잘할 수 있지 않을까?

그런데 프로젝트의 현실은 이상하다.

왜 그렇게 한가지 업무를 오랬동안 수행하고, 해당 업무의 프로젝트 수행경험을 10년 20년을 쌓아왔음에도 불구하고,

또 그런 개발인력으로 팀을 꾸렸음에도 불구하고 프로젝트의 성공여부는 항상 들쭉날쭉하는지 의문이 들지 않는가?

앞서 언급했듯이 '프로세스'영역의 관점과  '데이터'영역의 특성은 다르다.

가장 문제가 되는 것이

해야할 것에 대한 인지한 범위내에서 뭔가를 하나하나 해결하면 결과가 나오는 프로세스적인 사고방식의 경험으로 설계를 한다는 것이다.

솔직히 이것은 전체를 보고 시스템 구성을 고민하는 설계가 아니고, 좋게 해석해서 단순히 요구자와의 interview의 연속된 needs의 접수과정만 있을 뿐이다.

여기서 하나 짚고 넘어가야 할게 있다.

프로젝트를 성공적으로 수행했다 혹은 실패했다는 시스템 구축이 잘 되었느냐 아니냐와는 별개라는 것이다.

아무리 외부시각에서 재시간에 시스템을 open하고 고객이 만족했다하더라도,

프로젝트 수행인력 관점에서는 고생해서 어떻게든 돌아가게 만든 시스템이라면 이것을 성공적인 프로젝트라 할 수 있는가?

앞서 언급한 시스템 구축목적을 달성되었다고 할 수 있는가?

단언컨데 프로젝트는 성공했는지 몰라도 시스템 구축은 실패한 것이다. 

이런 개발인력을 갈아넣는 프로젝트를 복불복으로 반복될 수 있다면 이 글을 읽는 사람들은 받아 들일 수 있는가? 

* 프로젝트의 성공에 관여하는 변수는 여러가지이다. 여기서는 프로젝트 외부적 요건은 배제하고 내부적인 실제수행에 관한 관점을 주제로 한다.

폭포수 방법론과 애자일 방법론 : 무지한 설계자의 self 면죄부 애자일

이런 설계의 본질적 특성를 모르는 설계자들이 주로하는 주장이 빨리빨리 화면을 만들어 사용자에게 보여주고 feedback을 받아 다시 시스템에 반영하는 과정을 반복하는 애자일 방법론이 최선의 관리방법인양 말한다. 그 과정에서 만들고 부수고 만들고 부수고 하는 과정에서 개발자들의 에너지만 소진되는건 당연한 과정이라 생각한다.

애초에 폭포수 방법론의 문제가 고객의 feedback을 받을 동안 너무 많은 설계와 개발의 공수가 소진되고, 그 소진된 기간만큼 고객이 예상한 시스템과 개발팀간의 생각의 차이가 커지는 risk가 크다는 것이다. 이를 보완한 방법이 애자일인데 이 애자일을 잘못 해석하고 있다는 것이다.

개발단계 진입하기 전에는 설계가 완료되어야 한다.

폭포수로 하든 에자일로 하든 설계는 개발단계 진입전에 완료되어야 한다. 설계와 개발이 함께 애자일로 관리될 수는 없다. 이건 폭포수도 마찬가지다.

애자일이라는 이름아래 설계와 개발이 함께진행 되고 있다는게 문제다.

즉, 설계단계를 애자일로 관리하고, 그렇게 완성된 설계로 개발단계를 애자일로 관리해야 하는 것이다.

프로세스는 인식의 범위내에서 최단거리를 만들수 있고, 그렇게 만들어진 최단거리의 조합이 전체의 최단거리가 될수 도 있고 않될 수 도 있다.

그리고 프로세스는 그렇게 연결한 조합이 전체의 최단거리가 되지 않았다 하더라도 문제가 되지도 않고, 만약 문제가 된다면 문제가 되는 부분만 고치면 된다.

그러나 데이터(설계) 영역은 다르다.

데이터 영역은 requirement전체를 도출한 다음에라야 시스템에서 관리할 최소단위 데이터를 도출 할 수 있지,

인식한 범위 혹은 인지한 범위내에서만 최단거리를 만들고, 그런식으로 도출된 최단거리의 조합이 시스템 전체의 최단거리가 되지 않는다.

그리고 프로세스영역과는 다르게 데이터(설계)는 이렇게 조합된 시스템의 구성이 최단거리가 되지 않으면 문제가 된다.

왜냐고? 모든 requirement를 배수로 조합해 낼 수 있는 최소 데이터 단위는 일부의 requirement만으로는 도출 할 수 없기 때문이다.

설계란 최대 공약수 구하기

수학으로 말하자면 설계는 최대 공약수 구하기이다.

숫자 A, B, C, D를 배수로 조합할 수 있는 약수중 가장 큰수를 구하였다 하더라도,

그 약수가 아직 도출되지 않은 미지의 수(needs) E나 F까지 배수로 조합해 낼 수 있다고 보장할 수 없기 때문이다.

모든 수를 배수로 만들수 있는 최대 공약수는 말그대로 모든 숫자(needs)가 도출된 다음에야 구할 수 있다.

설계에서 최대 공약수는 해당 시스템에서 취급할 데이터의 최소 단위, 즉 정규화된 데이터를 말한다.

모델링, DA 어떻게 말하든 좋다. 설계는 통찰력을 필요로하고, 시스템 전체를 보고 프로세스를 진행하고, 관리하는 데이터의 최소 단위를 정확히 구해야 한다.

아마도 이런 경험들이 있을 것이다. 앞선 프로세스에서 취급해온 데이터 단위가 특정 needs구현 단계에서 어떤식으로 데이터를 끄집어내도 아귀가 맞지않는 경험이 있을 것이다.

설사 억지로 맞췄다 하더라도 또 다른 케이스에서 약간식 어긋나서 보정을 하고, 또 어긋나고 또 보정하고..

이건 꼭 데이터의 경우뿐만 아니라,

제어속성간의 부정확한 정의로 발생하는 종속성 위배,

제어속성간의 경합이 발생할 경우 우선순위의 부재로인한 프로세스의 잘못된 전개 등등.

이런 문제는 전제가 되는 앞선 rule부터 다시 검토해야하는 경우가 많고, 최악의 경우 애써 지켜온 rule을 모두 변경해야할 수 도 있다. 

그럼 어떻게 미지의 수를 도출하여 risk를 줄일 수 있을까?

Insight

통찰력이라는 단어가 그저 이 글을 꾸미기 위한 단어가 아니다.

어떤 하나의 needs가 접수되면 needs의 미래를 예측, 추론, 추리, 유추 등등 어떤 방식으로든 needs요구자를 취조하여

가능한한 데이터 운명의 모든 경우의 수를 도출하고, 볼 줄 알고, 질문할 수 있어야 한다.

왜냐하면 needs의 요구자는 항상 우리에게 조각정보(불완전정보)만을 제시하지 완전정보를 전달하지 않는다,

게다가 시간적으로 긴 간격을 두고 조각정보를 전달한다. 그것도 일관된 단어나 용어를 사용하지 않고 혼란스럽게...

그래서 설계자는 이런식으로 데이터의 미래를 도출하지 않으면 결국 개발자만 죽어나는 것이다.

인식의 범위내에서 설계를 하게 되면, 특정 시점에서 문제가 닥쳐서야만 다시 설계를 수정하게 되고

그렇게 수정된 설계로 인해 이제껏 애써 만들어온 프로세스의 규칙을 다시 허물고 소급하여 수정해야만 하는 삽질(?)을 반복하는 것이다.

앞서 언급했듯이 이것을 애자일 방법론이라 말하는 이상한 사람들이 있다.

그래서 통찰력이라는 것이 설계자의 필수자질이고, 없다면 만들어야 하는 자질이다.

이것은 공학이자 기술이다. 경험에서 만들어지는 것이 아니다.

통찰력이라는 표현을 그저 사용한 것이 아니다.

그럼 어떻게 통찰력을 얻을 수 있을까...

공부를 하지 않으면 본인이 무엇을 모르는지 모른다.

앞서 말했지만 사람들이 착각하는게 이런 설계, DA라는 능력이 단순히 경력이 쌓인다고, 경험이 쌓이면 저절로 생기는 능력인줄 아는 것이다.

이사람들이 자주하는 말이 "하나의 업무에 대해 전문가가 되라"고 말하는 특징이 있다.

하지만 하나의 업무를 전문적으로 아는 것보다는 모든 needs의 본질을 이해하고 재조립할 수 있는 능력이 있다면 ^*굳이 하나의 업무에 종속될 이유는 없다.

* 하나의 전문업무영역으로 갈것인지는 자신의 IT인생의 방향성에 따라 다르다.
본인은 특정 업무에 종속되고 싶지않다. 그저 개발이 재미있을 뿐이고, 전산으로 구축할 세상의 본질(needs)을 탐구하는게 좋다.

이 말이 업무의 대한 전문성이나 이해도가 중요치 않다고 말하는것이 아니며, 

설계나 DA를 전문적으로 공부하지 않는 업무 전문가는 해당 업무설계를 잘 하지 못한다고 말하는 것이 아니다.

본인은 설계나 DA를 전문적으로 공부하지 않아도 설계수행을 잘하는 개발자 출신 설계자들을 봐왔다.

특정 업무에 대한 이해와 경험치가 설계의 본질을 이해하는 것과는 별개라는 것을 말을 하는 것이다.

특정 업무의 시스템구축에는 무리없이 관리해왔지만, 새로운 업무영역의 시스템 구축에서는 감도 잡지 못하는 경우가 이런 근본적인 설계의 본질을 이해하지 못했음이 크다.

우리는 어떤 대상이라도 그 본질을 이해하고 꿰뚫어 보기 위해 탐구와 학습을 하지, 국소적인 한분야에 종속되기를 원하는 사람은 없을 것이다.

무엇을 하더라도 일정 수준의 설계가 일관되게 되어야 개발단계의 risk를 줄일수 있기 때문이다.

게다가 특정 업무의 전문가라 하더라도 고객마다 needs는 모두 다양하고, 그 업계마다 다 다르다. 그리고 업무는 항상 변한다.

또 고객들을 만나 얘기해보면 모두가 자신들의 현재 업무중심으로 프로세스를 해석해여 partial된 정보와 혼동된 용어, 잘못된 용어들로 우리를 혼란스럽게한다.

무질서속에서 정제된 정보를 도출해 낼려면 단순히 본인의 지난 경험치 보다는 표준화된 recipe가 더 도움이 된다.

무엇이 옳바른 것인지 기준을 알고 있다면  자신이 어디쯤 있는지는 좀 더 객관적으로 판단할 수 있을 것이다.

그것이 'DA'를 공부해야 하는 이유이다.

그렇기에 여전히 하나의 업무전문가라 하더라도 다양한 요구의 본질을 꿰뚫어 볼 DA의 본질은 필수적 요소임은 변함이 없다.

하나의 관점으로 모든 것을 이해 할 수 있는 일이관지(一以貫之)의 안목을 얻어 무엇을 수행하든 risk를 최소화할수 있다면 가장 아름다울것 아닌가?

수학을 아무리 잘 한다고해서, 영어를 잘 할 수 있는가?

국어를 아무리 좋아해도 과학도 저절로 알게 되는가?

서로 별개이다.

우리가 운전을 아무리 10년 20년 해도 자동차를 만들수는 없는 것과 같다.

개발도 마찬가지다. 그저 개발을 오래한다고 해서 설계능력이 생기는 것이 아니다.

별도의 자기 시간을 내어 공부해야만 그 이치를 알 수 있다.

DA가 무엇을 가져다 주는가? 방향성

모든 일에 완벽한 방법이란 없다. 언젠가는 더 좋은 의견이 제시되고, 더 짜임새있는 논리가 나오기 마련이다. 

그리고 우리를 둘러싼 세상이라는 환경이 항상 바뀐다.

우리는 항상 자신이 무엇을 모르고 있는지를 모르고 있다는 사실을 잊지 말아야 한다.

늘 자신을 의심하고 自問해야 하는 이유다.

그 질문을 잘 하기 위한 방법이 DA를 공부하는것이다.

완벽할 수 없다면 같은거 아니냐 할 수 있으나 우리는 조금이라도 더 理想이라는 목표에 근사치로 다가가려고 노력해야 한다.

본인은 늘 그 방향으로 가는 길위에 있기를 바란다. 그 길위를 걷기만 한다면 理想에 조금 더 가까워질 것이라 믿고있다.

물론 그 길위에서 스트레스도 받고, 실수도 하고, 욕도 먹을 수 있겠지만...

조제 무리뉴가 이런말을 했다. 자신도 실수를 하지만 항상 새로운 실수만 한다고

같은 실수는 하지 말자.

人不知而不慍 不亦君子乎 : 인부지이불온 불역군자호

'다른 사람이 자신을 알아주지 않는다 하더라도 화를 내지 안는다면 그것만으로도 군자라 불리울만 하다'란 말이다.

그것이 의미 있는 삶이다.