Thinking

애자일 개발 방법론으로 프로젝트를 진행해보면 어느 순간 이러한 느낌을 받게 된다. (만약 받지 못 한다면 꽤나 위험한 상황일지도 모른다)  내가 참가하고 있는 프로젝트는 애자일스럽게 진행되고 있는가? 라는 의문이다. 여기서 더 나아간다면  나의 팀은 정말로 애자일스럽게 일을 하고 있는가? 라는 의문이 들 것이고 더 나아가서 나는 정말로  애자일스럽게 일을 하고 있는가에 대해서 의문이 들 수 있을 것 이다. 애자일 방법론을 목적에 맞게 그리고 방향에 맞게 올바르게 사용하지 않거나 진행하지 않는다면  애자일 방법론으로 프로젝트를 진행하는 의미가 없어진다. 왜냐하면 프로젝트의 목표에 따라서  애자일을 방법론이 올바른 곳으로  향할 수 있느냐 없느냐가 좌우되기 때문이다. 따라서 목표가 명확하지 않다면 결과 또한 그렇게 좋지 않을지도 모른다. 즉, 전체적인 형태만  그럴듯 하게 애자일 형식으로 꾸미지만 내부적인 운용은 결국 워터폴과 다를 바 없다면 워터폴로 돌아가는게 프로젝트를 위해서 더욱 좋다는 것이다. 예컨데,  단순히 애자일로 개발했다는 실적만을 원한다면 아마 최악의 상황으로 발전할 것 이다. 오늘은 왜 애자일 개발론으로 좋은 퍼포먼스를 내기 힘든지 그리고 해결 방안에 대해 이야기를 해보자. 애자일 개발 방법론과 뉴턴의 제 1법칙 우선 애자일 개발 방법론에 대한 유용성에 대해  더 이상 논의할 필요는 없을 것 이다. 많은 기업이 앞다투어  이 방법론을 도입하려고 시도하는 것은  이 방법론의 효용성이 이미 입증되었기 때문이기에  유용성에 대한 논의는 더 이상 의미가 없다. 이러한 지루한 논의 보다는 어떤 상황에서 어떤 프로젝트에서  더 유용한지에 대해 논의를 하는 것이  더 생산적이고 흥미롭기 때문에 더 이상 언급할 필요는 없을 것 이다. 어쨋든 적어도 애자일 개발 방법론을 도입하는 과정속에서는  애자일 개발 방법론이 뉴턴의 제 1법칙...

왜 개발 업무는 입문이 어려울까라는 생각이 문득 들었다. 나의 대학 시절만 떠올려도 3학년 즈음되었을 때  그래도 생각했던 함수 정도는 만들 수 있었다. 다시 말해서  1~2년 때 까지만해도  제대로된 Class나 Function을 만드는데에도 힘겨웠다는 말이다. 대략 3년이 걸린 것이다. 물론 군대까지 포함한다면 5년이 되겠지만 말이다. 물론 이는 사람의 따라 편차는 크겠지만  대부분 꽤나 많은 시간이 걸렸을 것이고, 대 다수의 사람들은  이 1~2년 사이에 그만두는 경우가 많을 것 이다. 그렇다면 왜 개발 업무는 입문이 어려울까? 정확히는 왜 프로그래밍 언어를 배우는게  이렇게 힘들 수 밖에 없을까? 다른 사람들에게는  그냥 넘어가는 것들이겠지만 파해치는것을 좋아하는 나에게는 이런 것들은 매우 흥미로운 주제이다. 프로그래밍 언어란 무엇인가? 그렇다면 항상 하던대로 프로그래밍 언어가 무엇인가에 대해  정의를 하고 넘어가야 한다. 물론 어떤 합의를 통해 도출된 정의는 아니며 내 개인적인 직감에 도출된 정의이다. 그렇다면 프로그래밍 언어는  왜 생기게 되었는가에 대한 이야기 부터 출발해야 한다. 컴퓨터는 정확히는 이 세상의 모든 기계는  0과 1로만 이루어진, 0과 1로만 대화할 수 있다. 0과 1만으로 AND, OR, XOR 등의 산술 기법을 통해 원하는 결과값을 얻어 내는 것이 기계의 본질적인 역할이다. 위와 같이 0과 1로만 이루어진 코드를  이진 코드(binary code)라고 한다. 이 세상에 모든 하드 웨어와  소프트 웨어를 끝까지 파고 들어가면 결국에는 이런 0과 1로만 이루어진 이진 코드로 나타날 것 이다. 하지만 이진 코드는 기계가 보기에는 매우 익숙할지는 모르겠지만 인간이 보기에는 매우 불편하다. 단순히 위의 사진을 해석하기도 매우 불편하고 힘들다. 그 다음에 제시된 것이  명령어로 이루어진 어셈블리어(Assembly Languag...

드디어 프로젝트 BEP의 중반 부분인  시스템 설계의 들어설 차례이다. 사실 제 1장과 제 2장  특히 제 1장은 다소 실제 개발자가 하는 일과는  거리가 떨어져 있다고 할 수 있다. 따라서 모른다 하더라도  직접적으로 일을 하는데에 있어서  크게 문제는 없다. 하지만 이 설계 부터 시작하는 제3장 이후 부터는 일을 하는데에 있어서  충분히 인지하고 있지 않으면 실제 프로젝트에서 자신의 유용성을 증명하기 힘들 것 이다. 그렇다면 왜 개발자에게 시스템 설계가 필요할까? 물론 자신이 프로그래머 수준에 머물고 싶다면  딱히 설계를 배울 필요는 없다. 그냥 설계를 해준 대로  그대로 프로그램을 작성하면 되기 때문이다. 하지만, 그 위를 노리고 있는 사람이라면 설계는 반드시 배워야 할 것이며, 실제 프로젝트에서도 필요할 것 이다.  하지만 어떻게 설계를 배워야 하며, 어떻게 작성 해야 할까? 이번 글에서는 시스템 설계에 대해 배우기 앞서  이에 대한 이야기를 충분히 나누어보자. 설계(Design)의 정의 그렇다면 설계란 무엇일까? 사실 한자권 나라에서 설계라는  매우 명확한 그리고 매우 좁은 의미의 단어로서 사용하지만 영어권에서는 넓은 의미로서 Design으로서  애매하고 매우 넓은 의미로서 사용 한다. 먼저 옥스포드 사전에서 찾아보면  Design에 대한 매우 다양한 의미를 볼 수 있는데, IT 시스템 설계에서 의미하는 것은 그 중 2가지이다. 그림, 계획, 모델의 의미와 패턴의 의미로서 Design이라 부른다. 이에 대한 자세한 내용은 아래의 링크를 참고하길 바란다. https://www.oxfordlearnersdictionaries.com/definition/english/design_1?q=design 다만, 이는 공학적인 의미에서 Design을 말한다. 공학적인 의미에서 이런 Design들의 기저에는  건축에서 사용하는 개념이 깔려있는데...

나는 어떤 문제에 대해  이런 직감들을 가지려고 수 없이 노력 한다. 이런 직감을 도출하는 과정을 좋아하기 때문이기도 하지만 도출된 직감이 사회에 도움이 되었으면 좋겠다 하는 마음도 있기 때문이다. 마치 이런 자신의 직감을 정리해  이념을 제시했던 수 많은 선조들 처럼 말이다. 아마 내 마음속 한켠에는  그들 처럼 되고 싶다는 마음이 있을지는 모르겠다. 내가 그들 처럼 되고 싶은 이유는  내가 선조들에게 받았던 그들의 직감들은  나의 인생 전반적으로 영향을 끼쳤고 내 스스로 앞으로 나아가기 위한 원동력이 되어주었기 때문이다. 그렇기 때문에 나 또한 선조들 처럼 미래의 후손들에게 또는 같이 이 사회를 살아가는 각 개인들에게  좋은 영향을 주어 원동력이 되어 주고 싶기 때문이다. 나의 개인 블로그에 계속해서  글을 개시하는 이유는 이런 이유가 가장 크다. 이전에도 언급했듯이 애초에 나는 블로그를 IT를 포함한 나의 에세이를  공개할 생각은 전혀 없었다. 단순히 백업용 블로그로 사용할 예정이였다. 특히 에세이 쪽의 이야기들은   어떤 사람들에게는 매우 불쾌할 수 있어  그런 사람들에게 공격 당하기 쉽기 때문에  공개할 생각은 더더욱 없었다. 그럼에도 내가 에세이를 비롯한 이 블로그의 모든 글을  공개하는 이유는 여러가지가 있지만 내가 살아가면서 많은 사람들에게 도움을 받았듯이 나도 많은 사람들에게 도움을 받았기에 이것을 되돌려줄 수 있는 방법은  내가 할 수 있는 한해서 사회 안의...