글

[ 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) 세부 설명에 조금 차이가 있어 보이지만 전체적인 틀은 매우 비슷해 보인다.  몇 가지 포인트가 되는 단어를 추출해 이를 연결해보자면 아래와 같은 의미를 산출 할 수 있다. 독립적이지만 연관되어 있
자세한 내용 보기

[ Essay - Technolgy, IT, Architecture ] JAVA와 C 계열의 빌드 과정과 크로스 플랫폼에 대해

-
이미지
대학생 시절만 하더라도 나는 IT업계는 프로그래밍 언어가 중요한 부분을 차지한다고 생각하고 있었다. 그리고 지금 생각만해도 매우 웃음이 나오지만 나 혼자만 잘하면 다 될 것이라고 생각했었다. 하지만 실제로 개발자로서 일하면서 점점 느끼는 사실은 프로그래밍은 일부에 불과하다는 것과 나 혼자서 하기에는 엔터프라이즈 급의 프로그램을  요구를 정의하고, 설계를 하고, 프로그래밍을 하고, 테스트하는  과정을 시간적으로 그리고 인간의 체력의 한계가 있기 때문에  절대 불가능하다는 사실을 깨달았다. 그리고 해를 거듭하면 거듭할 수록 다른 사람들과 프로젝트를 진행하면서  이런 느낌은 더더욱 강해지기 시작 했다. 물론 그 시절에는 대학생이였고, 개발 경험이라고는 전무 했기 때문이여서 그럴 수 있다고는 생각하지만 말이다. 어쨋든 그런 웃음이 나는 일들을 떠올리면서도  IT업계에서 일을 하면서 여러가지 느끼는 것이 있고 생각하는 것들이 있는데, 그 중 일부가 실제 개발자가 작성한 코드가 어떤 과정을 거쳐서 컴퓨터에서 어떻게 실행되는가에 대한 것과 크로스 플랫폼에 대한 것이다. 물론 단순히 프로그래밍을 한다고 생각한다면, 이에 대해 깊게 생각할 필요는 없다. 하지만, 나의 목표는 진정한 엔지니어가 되는 것이 목표이고, 더 나아가 내가 가지고 있는 커뮤니케이션 능력, 경험, 그리고 기술들로  사회의 문제를 해결해주는  그런 해결사의 역할을 하고 싶기 때문이다. 그리고 그러기 위해서는  IT업계에서는 소프트웨어 아키텍트라고 불리우는 급이 되어야한다. 그렇다고 한다면, 내가 해야할 것은 다양한 시스템을 경험해보고 다양한 아키텍처를 보며, 이를 분석하여 내 나름대로 이에 대한 직감을 가지는 것과 동시에  이를 '부분적 진리'까지 승화시켜 다른 사람들에게 설명할 수 있어야 할 것이다. 이 글을 포함한 내 블로그들의 모든 글들은  그러한 과정 중에 하나이다. 그렇기에 이번에는 이런 고민들 중 하나인 프로그래밍 언어의 표준이라고 말할 수 도 있는 C 계열과 JAVA의 실행 과정에
자세한 내용 보기

[ Ruby On Rails, Ruby, Coursera ] Ruby On Rails를 중단하면서

-
이미지
막 Ruby On Rails에 대해 공부를 시작했을 시점은 Django의 토이 프로젝트가 마무리되고 있었고 코로나 때문에 일을 잠시 쉬었던 기간이 였다. 그렇기에 Ruby On Rails도 건드려보고 싶어서 늘 그렇듯이 욕심을 내고 기획을 했었는데 복직을 하고 나서 일이 바뻐지기 시작하면서 에세이를 쓰는데에도 벅차기 시작했다. 게다가 다음 이직은 아마 Python의 Django 쪽으로 거의 마음을 먹었기 때문에 여러가지 하는 것 보다는 Django쪽에 집중하는 것이  아무래도 좋을 것 같다는 판단도 들었다. 따라서 개인적으로 매우 아쉽다고 생각하지만 일단 Ruby On Rails는 중단하기로 하고 에세이와 Python에 좀 더 집중하기로 결정 했다. 이후 시간이 널널하다면 포스트를 재개하고 토이 프로젝트 때 다루었던  기능들을 Ruby On Rails로 구현해보려고 한다.
자세한 내용 보기

[ Essay - Intuition ] 책은 읽어야만 하는가?

-
이미지
책은 읽어야 만하는가? 최근 들어서 이런 생각이 들기 시작했다. 왜냐하면 이런 주제로 생각해본적이 없기 때문이고  실제로 나도 그러한 이야기를 해본적은 없기 때문이다. 물론 대다수의 사람들은 이런 논제에 대해  당연히 읽어야 한다는 사람들이 많을 것 이다. 나도 읽어야 한다는 논지에 대해서는 딱히 반대하지 않는다. 하지만 생각해보면  그 누구도 왜 읽어야만 하는지에 대해  철학적인 논의를 하지 않았다. 그래서 나는 궁금해졌다. 왜 읽어야만 하는가하고 말이다. 그렇기에 이번에는 책을  왜 읽어야하는지에 대해 이야기를 해보자. 왜 책을 읽어야 하는가? 지나가는 사람에게 책을 왜 읽어야 한다고 생각한다고 물어보면 마치 어떤 누군가가 그렇게 말하라고 세뇌를 했거나  다같이 그렇게 하기로 한듯이 마치 영혼이 들어가 있지 않은 대답들만 들을 수 있을 것이다. 한국으로 예를 들면,  한국 수능 시험에서 좋은 점수를 받기 위해서 혹은 대학 입학 시험에서 좋은 평가를 받기 위해서  책을 읽어야 한다는 사람도 심심치 않게 보일 것이다. 실제로 내가 고등학생 시절에는 어른들로부터 이런 이야기를 수 없이 들어 왔다. 나는 이런 현실에 대해 조금 의문이 들었고 지금에 와서는 의심으로까지 확장되었다. 왜냐하면 사람마다 어떤 행동에 대한 이유는 대부분 다를 것인데, 대부분 책은 읽어야한다고 사실에 대해서 동의하는 상황에서  어째서 책을 읽어야하는 이유에 대해서는  대부분 영혼 없는 대답이 들려오는 것 일까? 물론 이런 이유에 대해서는 위에서도 살짝 언급했듯이 아무도 철학적인 논의를 하지 않기 때문이라고 나는 생각하고 있다. 그렇기 때문에 영혼 없는 대답을 할 수 밖에 없으며, 스스로 동기부여를 할 수 없으니 책을 멀리 할 수밖에 없는 것이다. 이는 책 뿐만이 아니다. 그것이 책이던 외국어던 수 많은 어른들은 해야만 한다는 것을 수도 없이 침이 튈 정도록 떠들고 있지만 정작 가장 중요한 철학적 논의는 전혀 하지 않으며, 심지어 논의를 온몸을 비틀며 거부함은 물론이고 나이부터 시작해 온갖
자세한 내용 보기

[ Essay - Entropy ] 엔트로피 세계관과 양적 완화(Quantitative Easing, QE) : 엔트로피 세계관과 양적 완화

-
이미지
이전 글로  양적 완화에 대해 어느 정도 이해했다면, (그러길 바라고 있다.) 드디어 다음 이야기로 넘어 갈 수 있다. 바로 엔트로피 세계관에서 양적 완화가  어떤 엔트로피를 쌓는가에 대한 이야기이다. 여기서 고려해봐야할 점은 일반적인 엔트로피 뿐만아니라 플러스 엔트로피의 요소가 존재해  플러스 엔트로피가 쌓이는 것도 고려해봐야할 것 이다. 양적 완화와 플러스 엔트로피 양적 완화로 얻고자 했던 것은  외부 요인을 배제하고 자국의 경제 활성화를 얻고자 했을 것이다. 조금 어렵게 말하자면 시장에 '유동성'을 공급해 자국의 경제를 활성화시키려는 목적이 있었다. 결과적으로 시장에 '유동성 공급'은 성공했던 것으로 보인다. 이것은 플러스 엔트로피로 볼 수 있을 것 이다. 하지만, 이로서 얻을 수 있는 엔트로피는 더욱 증가하게 되었다. 가장 대두되는 엔트로피는 '부의 양극화'이다. 양적 완화는 기본적으로 자국의 화폐를 찍어내서 국채나 사채를 사들임으로써 시장에 '유동성'을 넣어주는 것을 목표로 한다. 그렇기 때문에 직접 사람들에게 화폐를 뿌리는 것이 아닌 중앙 은행이 돈을 찍어내고,  이 찍어낸 돈으로 국채나 자국 회사채를 사서 국채의 경우는 폐기시키고  중앙 은행은 이 돈을 은행 준비금으로 보유 한다. 따라서 이론상으로는 실물 경제에 큰 영향이 없을 것이다. 중앙 은행과 정부가 손을 잡고,  정당한 방법으로 '사기'를 치는 것에 불과하기 때문이다. 물론 어떤 사람은 그렇게 복잡하게 돌려서 하지 말고 직접 모든 사람들에게 돈을 뿌리면 좋은거 아닌가?라고 말하는 사람들도 있을 것이다. 하지만, 이럴 경우 나타날 수 있는 리스크가 너무 크다. 1차 세계대전에서 패한 독일이  전쟁배상금으로 화폐를 마구 찍어내면서 나타난 현상을 보면 화폐 자체를 뿌리는 것은 리스크가 너무나도 크다. 나라 경제 자체가 붕괴할 수 있기 때문이다. 그렇기 때문에 돌고 돌아서 시장에만 유동성을 제공하는 것이다. 이러한 양적 완화로
자세한 내용 보기

[ Ruby On Rails, Ruby, Coursera ] Ruby On Rails : Ruby ② - Ruby의 흐름 제어, Function과 Method, 파일 읽기/쓰기, 환경 변수

-
이미지
  다음은 Ruby의 제어 흐름(Flow of Control)에 대한 이야기이다. Ruby의 흐름 제어 흐름 제어 쪽에서 알아볼 것은 말 그대로  Ruby에서 흐름을 제어하는 명령어에 대한 것을 말한다. 일반적인 if/elseif/else, while/for의 모습도 보이지만 다른 형태의 흐름 제어 명령어도 보인다.  기본적으로 if, elseif, else의 경우는  다른 언어와 큰 차이는 없어보이며 Python과 마찬가지로 블록을 사용하지 않고  end를 사용해 끝을 알리는 것 같다. 조금 특이한 것이 있다면 아닐 경우를  unless라는 명령어로 구분하는 부분이다. 다음으로 while과 until인데 사실 while이라는 명령어가 ~동안이라는 의미를 가지고 있기 때문에 익숙하지 않다면 자주 헷갈리는 부분이다. Ruby의 경우는 until이라는 명령어가 있어서 until을 사용한다면, 가독성이 상승할 것 같다. modifier form(수정자 폼)이라는 것도 있는데, 이 기능은 영어 형식에 대해  가독성을 높일 수 있게 만든 것이기 때문에 다른 언어권이면 잘 사용하지 않을 것 같다. 강의에서는 자연스러운 영어 처럼 읽을 수 있기 때문에  표현 방식이 풍부해질 수 있다고는 이야기한다. 놀랍게도 Ruby에서는 모든 것이 true 를 반환한다고 한다. 단, fasle 와 nil 라는 객체를 빼고 말이다. Ruby에서는 '==='의 명령어를 지원하는데, '==='는 해당 문자열을 포함하는지와 같은  정규식을 활용할 때나 '=='와 똑같은 역할을 할 수도 있다. 심지어 정수 클래스(Integer)와 정수 값(21)을 비교할 경우에도 '==='을 사용할 수 있다.   다음으로 Case 표현에 관한 내용이다. 2가지 방법이 존재하는데,  if문을 활용할 때와 유사한 방식과 case ~ when로 값을 비교해 제어하는 방식이다. 전자의 경우 상단의 코드를 나타내는데, '>='와 '==&#
자세한 내용 보기

[ Essay - Society ] 왜 사회에서 인종 차별은 없어지지 않을까?

-
이미지
누구나 이성으로는 인종 차별이 행해지면  안된다는 것을 이해하고 있다. 종으로서 보면 인종과 관계없이 인간이기 때문이다. 이러한 사실에 고개를 기웃거리는 사람은  사실상 없을 것 이다. 현재 이 세상에 살고 있는 인간들은  2000년의 역사를 지니고 있고, 현대인들 또한  모두 인류로서는 모두 같다. 하지만, 인종 차별은  시간이 지나도 사라지지 않아 보인다. 왜냐하면 미국만 보더라도 이제 백인과 흑인간에 갈등은 너무나도 익숙하기 때문이다. 왜 인종 차별은 사라지지 않을까? 나는 이에 대해 이방인으로서 살아가면서  어떤 직감을 얻었다. 이번에는 이에 대해 이야기를 해보려한다. 현재와 과거의 인종 차별 현재의 인종 차별과 과거의 인종 차별은  조금 다른 성향을 보인다. 과거에는 우월한 인종이 열등한 인종을 가르친다는 한국에서 매우 혐오하는 '식민 사관' 에 의해  이런 우월과 열등의 관계 속에 행해져왔다. 물론 그 속내는 값싼 노동력을 얻고 잉여 생산물을 소비시키기 위한 행위였지만 말이다. 현재의 역사는 이렇게 평가하고 있다. 하지만 현재의 인종 차별은 조금 다른 성향을 띈다. 대개 사람들에게 우월한 인종이  열등한 인종을 가르친다는 인식은 보이지 않는듯 하며,  이방인인 나도 그렇게 느끼고 있지는 않다. 다만 일부의 사람들은  이런 생각을 가지고 있을지는 모르겠다. 자신의 나라가 가지고 있는 경제력에 기반해 자신의 나라에 한참 미치지 못하는 경제력을  가지는 나라의 사람들을 깔보고 멸시하는 사람들 말이다. 누군가 이런 말을 대놓고 한다면 사회 구성원들에 의해 강력한 철퇴를 맞게 될 것이다. 그렇기에 세상의 수 많은 이러한 비열한 인간들은  특정한 행동을 취한다거나, 돌려말하기를 즐겨한다. 물론 그들이 비열한 인간임에는 의심의 여지가 없다. 그들은 자신이 특별한 인간임을 느끼고 싶은 그러한 욕망을 채우기 위해 그러한 행위를 하고 있기 때문이다. 이렇게 과거의 인종 차별이 조금 변질해서 잘 발달된 나라의 사람이 발달되지 않은 사람에게 느끼는 우월감을
자세한 내용 보기

[ Ruby On Rails, Ruby, Coursera ] Ruby On Rails : Ruby - ① Ruby의 기본

-
이미지
  해당 강좌를 이제 본격적으로 시작해보자. 물론 앞서 Ruby의 기초를 넘기고, 바로 Ruby On Rails로 넘어갈 수 는 있을 것이다. 하지만, 대부분의 일에는 순서가 있는 법이고 설사 알고 있다고 하더라도  모든 것을 외울수는 없기에 다시 한번 보는 것도 나쁘지 않은 선택이다. 나는 오히려 이쪽을 좀 더 선호하는 편이다. 따라서 Ruby On Rails를 시작하기 앞서 Ruby의 기초를 알고 넘어가자. 이번 글의 내용은 Ruby on Rails: An Introduction>2주 차>Ruby Basics 에 해당 된다. Ruby의 기본 Ruby는 기본적으로 객체로 구성되어 있으며, 심지어 정수 조차도 완전한 객체로 구성되어 있다. Ruby를 만든 마츠모토 유키히로는 Ruby를 프로그래머들을 행복하게 하도록 설계 했다 고 하는데 이는 Java와 Ruby의 코드 구성을 보면  그의 이야기에 쉽게 납득할 수 있을 것 이다. 자바의 경우 콘솔에 Hello World를 띄우기 위해서는 먼저 클래스를 선언하고, 그 아래에 Main 메소드에  반복문인 For문을 활용해 코드를 작성해야 한다. 하지만 Ruby의 경우 단 한 줄이면  콘솔에 Hello World를 출력할 수 있다. 위의 예를 통해  Ruby는 표현력이 뛰어나며, 가독성이 매우 좋다는 것 을 알 수 있다. Ruby는 Python과 유사하게  코드의 중첩 수준(nested level)에 대해 들여쓰기로 구분된다. 다만 이는 권장 사항일 뿐이며 Python과 같이 강제하지는 않는다. 또한 주석(comments)는 #을 통해 작성할 수 있지만, 강의에서는 Ruby는 언어 자체의 표현력이 강력하기 때문에  즉, 가독성이 뛰어나기 때문에 주석을 적당히 사용하라고 권하고 있다. 콘솔에 출력하기 위한 명령어로 puts 과 p 를 활용할 수 있는데, puts은 Ruby의 표준 String 콘솔 출력 메소드로 Java의 System.out.println() 과 유사하다고 한다. 또한 이 강의에서 주로 사용하
자세한 내용 보기