9월, 2020의 게시물 표시

[ 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을 보고  직접 작성해

[ Essay - Etc ] 흥미로운 한국 경제

이미지
한국 경제는 매우 흥미롭다. 아니 사실은 한국이라는  나라 자체가 매우 흥미롭다고 해야 옳을지도 모르겠다. 그면에 있어서는 자부심을 가져도 좋다고 생각한다. 왜냐하면 전쟁이 이루어졌던 나라에서 반 세기만에 세계에서 손꼽히는 경제력을 보유한 나라는  사실 없다고 보는 것이 사실이기 때문이다. 이에 관해서는 오만해지지 않는다는 가정하에서는  다소 자부심을 가질 수 있다고 생각 한다. 하지만, 이는 이런 경제력을 보유하기 위해 기반을 쌓은 나의 할아버지, 할머니 세대의 희생이 있었기 때문에 가능했던 것 이다. 자신들이 사과를 받아야 마땅한 권리를 달러를 주고 팔고, 달러를 벌기 위해 외국 탄광이나 간호사로서 일해야만 했던 그 분들 말이다.  과거에도 그리고 지금에도  기축 통화인 펀더멘탈을 가지지 못해 지금의 경제구조를 가질 수 없었을 것 이다. 그리고 이런 가까운 선조들의 희생에 대해 이야기하지 않고,  오늘도 차디찬 도시 구석에서 고독사하고 있을지도 모른 나의 가까운 선조들에 대한 모국의 태도에 매우 유감스럽다. 어쨋든 오늘은 흥미로운 한국 경제에 대해 이야기해보려고 한다. 한국의 경제 지표에 대해 흥미로운 한국 경제를 이야기 앞서 먼저  유용한 지표를 몇 가지 살펴보고  몇 가지 특성들을 추출해볼 필요가 있다. 왼쪽부터 국제 통화 기금(2019), 세계 은행(2019), 유엔(2018)이 발표한  특정 연도에 한 국가 내에서 생산된 모든 최종 상품 및 서비스의 가치를  달러로 환산하여 같은 해 평균 인구로 나눈 1인당 명목 GDP이다. 대략 31000불로, 대충 환산하면  3000만원 정도의 1인당 상품 및 서비스의 가치를 지니고 있는 셈이다. 다음으로  특정 년도의 한 국가 내에 생산된  모든 최종 상품 및 서비스의 구매력 평가 GDP(PPP)이다. 왼쪽부터 동일하게  국제 통화 기금(2020), 세계 은행(2019),  중앙 정보국(Central Intelligence Agency, 2017)순 이다. 대략 40000불로 대충 환산하면 1년에 한국 사람 1

[ 프로젝트 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

[ Essay - Human, Technology ] 올바른 것이란 무엇인가? - 양자 세계관, 뉴럴 네트워크 및 머신 러닝

이미지
올바른 것이란 무엇일까? 이 세상에는 수 많은 사람들이  자신의 올바름에 대해 이야기하는 사람들이 많다. 그들은 과연 어떤 기저에서  자신이 올바르다고 생각하는 것 일까? 나는 이런 것이 항상 궁금하다. 실제로 가끔 이에 대해  상대방에 대해 물어보기도 하는데 경험상 대개 자신이 올바르다고 생각한 그에 대한 기저에는 매우 주관적이며, 다듬어지지 않은 직감이 있었다. 즉, 기저가 매우 신뢰성이 떨어졌기 때문에 그것이 정말로 올바른지에 대해서는 믿기 어려웠다. 예컨데,  현대에 들어서 가장 많이 사용되는 기저로서 통계가 사용되고 있는데, 통계의 결과물만 보고  어떤 사항에 대해 올바름을 주장한다. 하지만, 통계는 결과물 뿐만 아니라 어떤 조건 하에서 결과물을 도출했는지도 매우 중요하다. 표본의 수가 적절한지, 표본 편향은 없는지, 발표한 기관이 신뢰성이 있는 기관 인지 등을 고려해 정말 이 통계가 신뢰 가능한지에 대해 살펴봐야 한다.  하지만 일반적으로 결과물과  기관에 대한 사항만 보여줄 뿐 그 외에 사항에 대해서는 구체적으로 제시해주지 않는다. 만약 표본 자체의 문제가 있다면 애초에 전제부터 틀렸기 때문에  그것이 정말로 올바르다고 이야기 하기는 적절하지 못할 것이다. 그렇기에  자신의 올바름을 주장하거나 어떤 사항에 대해 올바름을 이야기할 때, 자신만만하게 올바름에 대해  이야기하는 사람들의 기저에는 매우 주관적인 다듬어지지 않은 직감에  의존하고 있다고 생각하고 있다. 재미있는 것은 자신의 직감이 아닌 뉴스와 같은 매체나 검증되지 않는 글이나 이야기에  기저를 두고 자신의 올바름을 이야기하는 사람이 세계에 꽤 나 많이 존재한다는 사실이다. 이러한 기저들에 대해  쉽게 말하면, 소문이나 루머와 같은 가쉽에 매우 의존한다. 소문이나 루머에 의해 공동체를 떠나거나 심지어 자살하는 연예인와 같은 사람들도 심심치 않게 보인다. 이 경우  이런 소문과 루머에 기저를 두고  자신의 올바름을 주장한 사람들은 마치 처음부터 그런 사람들이 존재하지 않은 것 처럼 눈을 씻고