글

라벨이 프로젝트 BEP인 게시물 표시

[ Architecture, Technology ,Web ] SSO(Single Sign On) 그리고 SAML에 대해

-
이미지
이번 프로젝트 내부에서 어쩌다보니  유저 인증 관련 업무를 담당하게 되었고, 해야하는 업무는 내부에 사용했던 적이 없던  새로운 개발 플랫폼에서  SSO의 프로토콜 중  SAML을 이용해 앱의 인증을 구현해야만 했다. SSO를 생각해본적 조차 없는 상황에 이를 새로운 개발 플랫폼에 도입해야 했기 때문에 많은 시행착오를 겪었으나 구현에 성공하였으며 덕분에 SSO에 대한 전반적인 지식을 쌓을 수 있었다. 이번에는 그러한 과정에서 나온 지식들과 경험을  공유하고자 한다. SSO에 대한 정의 먼저 사전적 정의 부터 살펴보자. 다만, 기술적인 용어다보니 자주 사용하는 옥스포드 사전에 정의를 찾을 수 없기 때문에  검색으로 찾을 수 있는 정의를 몇 가지 살펴보고 교차 검증을 해보자. 첫 번째 정의를 살펴보자. Single sign-on (SSO) is an identification method that enables users to log in to multiple applications and websites with one set of credentials.  SSO는 웹사이트에서 한 번의 인증(one set of credentials)으로 복수의 어플리케이션에 로그인 할 수 있는 인증(identification) 방법(method) 이다. 두 번째는 위키피디아의 정의이다. Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems. SSO는 독립적이지만 연관되어있는 몇몇 소프트웨어에 대해 하나의 ID로 로그인을 할 수 있도록 하는 인증 구조(scheme) 세부 설명에 조금 차이가 있어 보이지만 전체적인 틀은 매우 비슷해 보인다.  몇 가지 포인트가 되는 단어를 추출해 이를 연결해보자면 아래와 같은 의미를 산출 할 수 있다. 독립적이지만 연관되어 있
자세한 내용 보기

[ 프로젝트 BEP ] 제 4장 : 프로그래밍 언어 - 들어가면서

-
이미지
기획 했던 프로젝트 BEP도 이제 4장을 끝내면  단 하나의 5장만을 마지막으로 남겨두게 된다. 이제 일반적인 개발자들의 영역인 언어의 이야기를 할 차례가 왔다. 개발자로서 프로그래밍 언어는 가장 큰 부분을 차지한다. 물론 좀 더 위로 갈 수록  이 언어의 점유율이 점차 줄어들기는 하지만 말이다. 어쨋든 이번 4장에서 이야기할 언어에 대한 이야기는 Java, C 계열, Python 등의  언어의 사용법에 대한 이야기는 하지 않을 것이다.  왜냐하면 학문적으로 언어에서 이야기할 때에는 프로그래밍 언어의 역사에 대해 이야기를 하기 때문이며, 이런 역사의 각 패러다임을 분류하기 때문이기도 하며 또한 언어의 사용법에 대해서는 여기서 언급하지 않아도 구글링하면 얼마든지 찾을 수 있기 때문이다. 따라서 이번 4장에서의 목표는 언어의 역사를 살펴보면서 각 패러다임에 대한 지식과 나의 직감을 전달하는 것을 목표로 한다. 아마 주된 내용은  구조적 프로그래밍과 객체지향 프로그래밍에 대해  그리고 이를 섞은 혼합형 프로그래밍에 대해  이야기를 하게 될 것이라고 생각 한다. 본격적인 이야기를 하기 앞서서 왜 프로그래밍 언어를 배우는 것이 어려운지에 대해  이야기를 하고 넘어가자. 2020.09.30 제 4장 프로그래밍 언어 시작
자세한 내용 보기

[ 프로젝트 BEP ] 제 3장 : 시스템 설계 ③ - 결론

-
이미지
우리는 앞서 간단한 계산기를 설계 해보고 실제 Java로 구현해 보았다. 당연히 실제 엔터프라이즈 급 애플리케이션의 설계도를 하나의 큰 사진으로 담아 펼치면 이보다 클 것이다. 하지만, 실제 프로젝트에 참여할 경우  큰 애플리케이션 안의 작은 클래스, 메소드, 함수등을 개발하게 되는데 클래스 다이어그램을 사용할 경우에 계산기 설계와 크게 다르지 않다. 요는 고작 계산기 설계를 했다고 풀 죽을 필요는 없다는 말이다. 영화나 드라마 같은 영상 매체에서는  천재 프로그래머가 있고,  이런 천재 프로그래머가 하나의 큰 애플리케이션을  혼자 만드는 것을 심심치 않게 볼 수 있는데, 이는 현실에서는 보통 불가능한 이야기 이다. 물론 가능하기는 하다. 하지만, 그렇게 하기 위해서는 시간이 많이 필요하다. 즉, 가능하다고는 할 수 있지만 시간적인 부분에서  효율이 매우 떨어지기 때문에 한 공간에 모여서 다수의 사람들과 함께 일하는 것이다. 한 공간에 모여서 일하는 사람들이  우둔하고, 머리가 좋지 않기 때문이 아니다. 오히려 정반대이다. 영화는 영화고, 현실은 현실이다. 영화와 현실을 착각하지 말기를 바란다. 결론 시스템 설계의 첫번째 글에서도 언급했듯이 소프트웨어 개발자에게는 시스템 설계가 필요하다. 하지만 절대적인 것은 아니다. 프로젝트는 역할 분담이 정해져 있으며 프로그래밍은 그 중 한 프로세스일 뿐이다. 좀 더 정확히는 당신이 IT업계에서 안에서  가치를 증명하고 싶고,  가치를 증명함에 따라 더 많은 사회의 몫을 얻고 싶다면 (한 가지는 확실히 하자. 더 많은 사회의 몫을 얻기 위해 가치를 증명하는 것이 아니다.) 즉, 오늘보다 나은 내일을 꿈꾼다면  시스템 설계는 배워야함이 옳으며 배움과 동시에  계속 해서 작성해보며  자신만의 설계 방식을 찾는 것이 좋을 것 이다. 물론 자신은 지금 상태에 만족하며 더 나아가고 싶지 않다면 배우지 않아도 된다. 전혀 창피한 것이 아니고, 잘못된 것도 아니다. 굳이 IT업계가 아니라도  그런 사람은 이 세상에 많으며, 삶을 살아가
자세한 내용 보기

[ 프로젝트 BEP ] 제 3장 : 시스템 설계 ② - UML의 Class Diagram(클래스 다이어그램)에 대해

-
이미지
이제 정말로 본격적인 이야기를 시작해보자. 바로 UML에서 제시해주는 다이어그램 중 하나인  클래스 다이어그램에 관한 이야기 이다. 이전 글에서 이에 대해 언급했으니  바로 클래스 다이어그램이 정확히  어떤 형식으로 이루어져있는지에 대해 이야기를 나눠보자. 간단한 Class Diagram의 예 간단한 예로서 어느 것이 가장 좋을까? 포스팅 중 Django에 대한 포스팅이  나의 블로그에는 꽤나 있는데, 여기서 사용되었던 Class Diagram을 예로서 살펴보자. 이 다이어그램은 실제 Mozlia 쪽의 튜토리얼에서 제시해줬던  도서관 앱의 Class Diagram이다. 이에 대한 자세한 설명은 아래와 같다. 먼저 빨간색 박스 는 Class의 이름을 표기하는 곳이며 하늘색 박스 는 변수명과 변수 타입 을 표기한다. 또한 주황색 박스 는 클래스 내부의 메소드 들의 표기, 그리고 녹색 박스 는 클래스 간의 관계를 표시하는데 ER다이어그램에서 사용하는 것과 유사하다. 따라서 실제 해당 클래스가 다른 클래스들과  DB에서 어떻게 관계가 이루어지는지를 알 수 있다. 변수 가장 왼쪽에 있는 + 는 public 을 의미하며, - 를 사용할 경우 private 를 의미 한다. 다른 설계 도구를 사용할때에도 마찬가지이지만, 언어와 상관없이 이 설계도만 있으면 해당 앱을 작성할 수 있다. Class Diagram으로 설계 하기 그렇다면 이제 실제로 위의 애플리케이션 설계 보다 더 간단한 것을 설계해보자. 나는 다른 언어를 배울 때마다  꼭 작성해보는 프로그램이 있는데 바로 계산기 프로그램이다. 왜냐하면 계산기 프로그램만 작성해도 기본적인 함수 작성, 함수 리턴, 변수 선언, 변수 리턴, if문 등의 가장 기본적인 문법을 실제 확인해볼 수 있기 때문이다. 따라서 이 계산기 프로그램을 위한 설계를  Class Diagram을 활용해 작성해보기로 하겠다. 물론 글에서는 바로 아래에 표시하겠지만 가능하다면 자신 나름대로  위에서 보여주었던 Class Diagram을 보고  직접 작성해
자세한 내용 보기

[ 프로젝트 BEP ] 제 3장 : 시스템 설계 ① - UML(Unified Modeling Language)에 대해

-
이미지
  이전 글에서 시스템 설계에 대한  이야기를 충분히 했다고 생각하기에  이제 본격적으로 시스템 설계에 대해  그리고 유용한 도구에 대해 이야기해보자.  UML(Unified Modeling Language)의 정의에 대해 늘 그렇듯이 먼저 정의에 대해 알아보고  좀 더 자세한 이야기를 해보자. 우리들의 위키피디아에 따르면  UML 은 시스템 설계를 시각화하는 표준 방법을 제공하기 위한 소프트웨어 엔지니어링 분야에서 사용되는  범용적(a General-purpose) 이고, 개발적(Developmental) 인  모델링 언어(Modeling Language) 이다. 위와 같이 정의내리고 있다. 따라서 시스템 설계를 위한  수 많은 모델링 언어 중 하나라고 생각하면  다소 이해하기 쉬울 것이라 생각한다. 현재 최신 버전은  공식 페이지에 따르면 2.5.1 버전이 최신으로 보인다. UML에 대한 사양서는 공식 페이지인 https://www.omg.org/spec/UML/ 위의 링크에서 참고하길 바란다. 내가 이야기하고자 하는 것은  UML의 일부분 이기 때문에  이렇게 살짝만 언급하고 넘어가기로 하겠다. UML Diagram에 대해 UML에서는 설계 도구인 다이어그램(Diagram)을 표준으로서 제안한다. UML의 다이어그램을  구조적인 정보를 나타내는 구조적 UML 다이어그램(Structural UML diagrams) 과  상호 작용 측면을 나타내는 동작 UML 다이어그램(Behavioral UML diagrams) 두 가지 종류로 나눌 수 있는데 내가 이야기하고 싶은 부분은  구조적 UML 다이어그램 중 클래스 다이어그램(Class Diagram) 을 이야기 하려고 한다. 클래스 다이어그램(Class Diagram)에 대해 물론 어떤 사람은 수 많은 다이어그램 중  어째서 클래스 다이어그램만을 이야기 하는가에 대해 궁금할지도 모르겠다. 그 이유는 현재 대부분의 언어에는  객체지향형 패러다임이 녹아 들어가 있기 때문이다. 따라서 단순히 프로그래밍 측면에서만 본
자세한 내용 보기

[ 프로젝트 BEP, Essay - Developer ] 제 3장 : 시스템 설계 - 왜 개발자는 시스템 설계를 배워야 하는가?

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

[ 프로젝트 BEP ] 개발 프로세스의 애자일 부분에 대해서

-
이미지
개발 프로세스의 워터폴 부분을 마치고  업로드 한 후 4개월이 지났다. 하지만 그 이후로 블로그에  더 이상 글이 업로드 되고 있지 않은데 그 이유는 작성하고 퇴고를 계속해서 하지만 초안으로서 업로드하기에는  만족할 만한 글이 나오지 않았기 때문이다. 그 이유는 여러가지가 있지만 먼저 애자일에 대한 개념은 둘째 치더라도 실제 프로젝트를 진행할 때  메인 프로세스로서  에자일을 사용하는 프로젝트는 매우 드물었기 때문이다.  따라서 글에 나의 직감을 담아내기는 힘들었다. 물론 개념에 온갖 달콤한 말을 붙여가면서  초안을 작성할 수는 있었겠지만 다른 사람들로 하여금 별로 도움이 되는 글은 아닐 것이며, 프로젝트 BEP의 목표와도 어긋 난다. 따라서 많은 고민을 해본 결과  프로젝트 BEP의 진행을 위해  이 애자일을 제외하고, 기획한 대로 초안을 업로드 한 이후에 다시 한번 생각해보려고 한다. 그렇기에 지금 상태에서 개발 프로세스 부분을 마치고 다음으로 넘어가  시스템 설계에 대한 이야기를 하려고 한다. 하지만, 애자일에 대해 어떻게 설명하면 좋을지에 대해 판단이 서지 않기 때문에 고민이 되기에 초안을 완성한다고 해도 애자일에 대해  만족할 만한 글을 작성할 수 있을지에 대해서는 의심이 간다.                                                                                                                 2020.09.19 역 근처 스타벅스에서
자세한 내용 보기

[ 프로젝트 BEP ] 제 2장 : 개발 방법론 - 워터폴(WaterFall) ② <워터폴의 각 프로세스에 대해>

-
이미지
・워터폴의 각 프로세스에 대해 그렇다면 이제 순서에 따른 프로세스들의 세부적인 내용에 대해 알아보자. 위에서 살펴본 기본형과 사이클을 다시 한번 가져와 보면, 아래와 같다. 워터폴(WaterFall) 기본형 모델 ①요구 분석(Analysis) → ②설계(Design)  → ③개발(Implementation) →  ④테스트(Test & Integration)  → ⑤유지・보수(Maintenance) 요구 분석(Analysis)부터 시작해 세부적으로 살펴보자. 사실 프로젝트에서 이런 프로세스가 있지만, 일반 사람들이 인식하고 있는 것은 개발, 단 한 프로세스이다. 이 단계에서 실제로 개발자들이 프로그래밍을 통해 구현하게 된다. 그리고 대부분의 주니어들은 아마 자신이 이런 개발 단계만 하리라, 그리고 실제 실무를 하면 거기에 투입되리라 생각하겠지만, 그렇지 않다. 그런 생각을 가지고 업계에 들어온 주니어들에게는 희망적이지도, 달가워하지 않을 이야기일지도 모르겠지만, 특히 주니어라면 더더욱 개발을 맡기지 않는다. 주니어에게 개발 프로세스의 일을 맞기게 되는 상황이라면, 매우 좋지 않은 상황이며, 정상적인 개발 프로세스가 수행되고 있다고 보기 힘들다. 그렇다 하더라도, 개발만이 개발자의 일은 아니며, 다른 프로세스보다 개발 프로세스가 더욱 중요한 것은 아니다. 이 프로세스에서 중요하지 않은 프로세스는 없다. 간혹 개발자들 중에 특히 테스트를 역할을 맡는 팀을 우습게 보고 이들을 무시하는 경향이 있는데, 어느 프로세스의 역할을 하건 간에 프로젝트 안에서 수직적인 위 아래는 없으며, 그런 하에 프로젝트의 인원들은 모두 동료다. 그렇지 않다면, 우리들의 프로젝트는 원활히 돌아가지 못할 것이다. 따라서 만약 그런 선배들이 보인다면 그런 사람들을 보고 배우지 않았으면 하는 작은 바램이있다. 어쨋든 이 중 하나의 프로세스라도 정상적으로 수행되지 않는다면, 프로젝트는 제대로 완수했다고 볼 수 없다. 그렇기 때문에 개발 일을 하고 싶어서 왔다 하더라도, 아무리 개발 능력이 뛰
자세한 내용 보기

[ 프로젝트 BEP ] 제 2장 : 개발 방법론 - 워터폴(WaterFall) ③ <결론>

-
이미지
지금까지 해서 워터폴(WaterFall)과 각 프로세스에 대한 이야기를 했다. 결론적으로 말하면 워터폴은 업계 표준이라 말 할 수 있을 정도로 자주 사용되어지고 있는 프로세스다. 아마 특별한 경우가 없다면  대부분의 프로젝트는 워터폴로 진행되지 않을까 하는 것이 나의 의견이다. 때문에 워터폴이라는 방법론에 대해 직감을 가지고 있어야 하는 것은 당연하다는 말이다. 워터폴이라는 개발 프로세스의 한해서 주니어로서 할 수 있는 프로세스는 대개 테스트나 유지 보수일 것이다. 물론 자질도 실력도 훌륭한 주니어라면 개발 프로세스를 할 수 있을 것이다. 하지만, 위에서도 언급했다시피 실무 레벨의 프로젝트는 대개 수 많은 사람과 협업을 하며, 그에 따른 암묵적인 관습이나 규칙들이 있다. 이런 암묵적인 관습이나 규칙들은 잘 언급해주지 않기 때문에 그리고 언급해주더라도 주니어들은 익숙하지 않아 대개 잊어버리기 십상이기 때문에 개발 프로세스의 일을 맡기지 않는다. 세상에 절대라는 것이 없듯이 가끔 익숙한 것 처럼 보이는 주니어들이 있다고 할 수도 있지만, 그런 사람들은 사실 주니어라고 보긴 힘들다. 왜냐하면, 이런 유사한 환경에서 일해본 경험이 있기 때문에 기술적으로는 주니어 일지라도, 주니어라고 취급하지 않는다. IT업계에서는 이직과 전직이 흔하기 때문에 누군가 전직한다고 해도 그를 주니어라고 부르지 않는 것과 같은 논리이다. 하지만 이를 논외로 치고  정말로 처음 입사하는 사람 중에 드물게 그런 주니어들이 보이기도 한다. 매우 안타깝게도  늘 그렇듯이 인생을 살아가는데 있어서 가끔 우리의 상상을 뛰어넘는 사람들이 존재해왔었기 때문이다. 그게 IT업계라고 하더라도 예외는 아니다. 하지만,  문제는 자신이 그런 사람이라고  착각하는 사람들이 있어서 문제다. 자신이 정말로 능력을 가지고 있다면 유지 보수에서 실력이 드러나기 때문에 리더 개발자의 판단으로 필요하다면 개발 프로세스를 담당할 수 있을 것이다. 따라서 주니어로서 자신이 개발 프로세스를 하지 못한다 하더라도 이는 이러한 이유
자세한 내용 보기

[ 프로젝트 BEP ] 논의① 부록 : 소득분배론 노트

-
이미지
자세한 내용 보기

[ 프로젝트 BEP ] 제 2장 : 개발 방법론 - 워터폴(WaterFall) ① <워터폴이란 무엇인가>

-
이미지
이번 이야기는 개발 방법론 중 사실상 국제 표준 개발 방법론 이라고 할 수 있는 '워터폴(WaterFall)'에 대해 이야기를 할 것이다. 대부분의 프로젝트는 이 '워터폴(WaterFall)'에 기반을 두고 진행하는 프로젝트가 많을 것 이다. 왜냐하면, 과거부터 이런 프로세스로 성공한 프로젝트 수가 많다는 것을 보면, 워터폴 기반의 개발 프로세스가 안정적이라는 것을 알 수있고, 대다수가 그렇게 느끼고 있기 때문이다. 따라서 누군가가 표준이라고 정하지 않더라도 우리는 암묵적으로 '워터폴(WaterFall)'을 표준으로서 사용하고 있다. 물론 그렇다고 단점은 없는 것은 아니다. 워터폴의 단점 때문에 애자일이라는 개념의 개발 프로세스가 등장했으니 말이다. 어쨋든 애자일은 다음에 하기로 하고, 이번에는 워터폴에 대해 이야기를 해보자. ・워터폴(WaterFall)이란 무엇인가? 한국말로는 폭포수라고도 한다. 아마, 위에서 아래로 떨어지는 폭포수와 같이 이 방법론이 절차대로 아래로 떨어지기 때문이라고 생각한다. 어쨋든 어원은 크게 중요하지 않으니 그렇게 이해하고 있으면 된다. 우리에게 중요한 것은 어원이 아니라 워터폴 모델에서 얻을 수 있는 직감(intuition)이다. 워터폴 모델은 사실 단 한 가지만이 존재하는 것은 아니다. 파생 워터폴 모델들이 엄청 많으며, 이는 대부분 기본형에서 변형한 것이기 때문에 우리가 알아야 하는 것은 가장 기본적인 워터폴 모델이다. 그리고 이런 기본형 워터풀 모델에서 직감을 가져올 수 있다면, 다른 파생 워터폴 모델을 보더라도 큰 문제점은 없을 것이다. 워터폴(WaterFall) 기본형 모델 위의 그림은 사실상 가장 기본이라고도 할 수 있는 워터폴 모델이다. 순서는 아래와 같다. ①요구 분석(Analysis) → ②설계(Design)  → ③개발(Implementation) →  ④
자세한 내용 보기

[ 프로젝트 BEP, Essay - Developer ] 제 2장 : 개발 방법론 - 왜 개발자는 개발 방법론을 배워야 하는가?

-
이미지
이번에는 개발 방법론에 이야기 하려고 한다. 이에 해당하는 학문으로서의 이름은 Software Engineering, 한국어로는 소프트웨어 공학이라는 학문일 것 이다. 그 안에 이번에 이야기 하고자하는 개발 방법론이 포함되어 있다. 여기서 이야기하는 것들은 프로젝트 관점에서 이야기를 한다. 프로젝트의 프로세스는 어떻게 할 것인가? 프로젝트의 비용에 대해서는 어떻게 정할 것인가? 또는 구성원은 어느정도로 하는 것이 좋은가 등등에 대한 학문이다. 아마 건축의 공학적 개념을 소프트웨어에도 적용한것이 아닌가 싶다. 물론 건축의 설계는 실질적인데에 비해 소프트웨어의 설계는 굉장히 추상적이기 때문에 동일 시 할 수는 없을 것이다. 이 Software Engineering이라는 학문안에는 여러가지 개념이 있겠지만, 개발자로서 중요한 곳은 개발 방법론이 아마 가장 중요하다고 생각한다. 그렇다면, 왜 소프트웨어 개발자는 이런 개발 방법론을 알아야할까? 이에 대해서는 '컴퓨터 개론'에 비해서는 비교적 명쾌하다고 할 수 있다. 왜냐하면, 실제 프로젝트는 이런 개발 방법론을 기반으로 개발 프로세스를 가지기 때문이다. 1장에서 이야기 했던 것은 어쩌면 개발 방법론 보다 실무에서 떨어져 있을 수도 있다. 하지만 개발 방법론은 다르다. 소프트웨어 개발자들은 프로젝트의 한 구성원으로서 일을 한다. 그리고 프로젝트의 책임자들은 이런 개발 방법론을 기반으로 실제 개발 프로세스(일정)를 작성한다. 따라서 우리는 이런 개발 방법론을 학문적으로는 자세히는 알 필요는 없지만, 어떤 것이 있고, 어떤 장점과 단점을 가지고 있는지 알 필요가 있며, 이에 대한 직관을 가질 필요가 있다. 이를 통해 실제 프로젝트를 진행하며, 어떨때는 이 개발 프로세스가, 어떨때는 다른 프로세스가 더 어울리는지 개발자로서 직감적으로 느끼고 있어야 한다. 왜냐하면 우리가 그 프로젝트에 직접 참여하게
자세한 내용 보기