[ 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 - Intuition, 생각 ] 리스크 관점에서 바라보는 것에 대해

이미지
정말 오랫만에 생각 카테고리로 글을 작성하는 것 같다. 그 동안은 글을 작성한다면  에세이를 중점으로 작성했으니 말이다. 에세이를 작성하는 것은 분명 즐겁지만,  어느 정도 형식이 있고 그 만큼 무겁기 때문에  작성하는데 시간이 꽤 나 걸린다. 무엇보다 이전과 다르게  이러한 글을 작성하는 것보다 일에 대한 중요도와 우선도가 높아졌기 때문인 것이 크다.  이에 더해 최근에는 작성하고 있는 에세이들은  개인적으로 만족스럽지 못해 마침표를 찍지 못하고 있다. 어쨋든 이번에는 가볍게 이야기를 나누어보자. 만약 세상을 바라보는 창이 존재한다고 한다면 나에게 그 창 중 하나가 바로 리스크 이다. 내가 하는 행동들의 대부분은 리스크가 매우 크다. 왜냐하면 나는 좋은 의미에서도 나쁜 의미에서도  보통과는 거리가 멀기 때문이다. 그렇기 때문에 내가 하는  대부분의 행동들은 리스크가 클 수 밖에 없다. 그것을 제외하더라도  외국에 살아가는 것 또한  사실은 무척이나 리스크가 큰 행위이기도 하다. 실제로 그 리스크가 현실로 다가온 경우는 많다. 세상을 리스크 관점에서 바라봤을 때,  가장 큰 이점은 최악의 경우를 상정하기 때문에 그에 대한 대비가 된다는 것 이다. 그렇지 않더라도 상황에 대해 생각한다는 것 만으로도 굉장한 이점이다. 그렇지 않은가? 사람이 가장 크게 무너질 때는 예측하지 못할 때 아니겠는가? 예측하지 못한 상황들은  언제나 사람을 당황하게 만들고 초조하게 만들어  올바른 판단을 내리지 못하게 하기 때문이다. 물론 모든 상황에 대해 예측할 수는 없겠지만 말이다. 하지만, 리스크 관점에서 최악의 상황을 상정하고  대비하거나 생각 해본다면 상황을 해결하기 위한 실마리가 된다. 리스크 관점에서: 법에 대해 예컨데 법에 대해 이를 생각해보자.  복잡한 법까지 갈 것 없이  일상 생활에서의 예로도 충분히 설명이 가능하다. 예컨데, 차도를 건너서 카페에 가기 위해서 서 있다고 가정해보자. 카페의 투명한 창으로 안쪽을 살짝 보니  빨리 간다면 자리에 앉아서 편안하게 시간을 즐

[ 생각 ] 존중과 존경은 구걸하는 것이 아니다

이미지
나의 어린 시절에 어른들은  나에게 존중과 존경을 원했다. 그런 존중과 존경의 의미로 존댓말과 자신들에 요구에 절대적인 긍정하기를 원했다. 하지만, 나는 이런 어른들의 요구에 정확히 언어로 설명할 수는 없었지만 어떤 위화감이 들었다. 그리고 그런 위화감을 내 나름대로 표현했지만 그런 사람들 중 많은 수가  대개 내가 어른이 된다면 이해할 수 있다며  다시는 언급하기를 꺼려했고 불편해 했다. 다시금 언급한다면 가정 교육부터 시작해 심하면 그렇게 불만이면  한국을 떠나라는 이야기를 듣고는 했다. 나의 입을 사실상 봉쇄한 것이다. 물론 나의 이런 경험에 어떠한 사람은 이런 이야기는 하는 사람들은  소수일 뿐이라며 손사래를 치겠지만 약 28년 동안 현실과 가상을 넘나들며 많은 시도를 했지만 결국 같은 말만 반복해서 들었을 뿐이다. 여기서 그 어른이란  한국에 흔히 있는 나이로 나눈 어른이다. 하지만 그들의 예상과는 반대로 나는 지금 이 시점에도 여전히 그들의 말에 동의할 수 없다. 나의 그들에 대한 위화감이 맞았던 것이다. 여기서 더 나아가  그들이 어떠한 의도와 목적에서  그런 말을 했는지 인식할 수 있었다. 결론적으로 그들은 사실  존중과 존경을 원하기는 커녕 단순히 복종을 원한 것이다. 자신의 위치와 자신의 알량한 자존심  그리고 체면이 있기 때문에  본질을 흐려 바꿔 말한 것 뿐이다. 그들은 자신의 알량한 자존심과  자신이 '어른'이라는 위치  즉, 체면을 위해 구태여 거짓말을 한 것이고 바꿔 말해서 나에게 존중과 존경을 구걸한 것 이다. 그리고 다시는 이에 대해 입 밖에도 꺼내지 못하게 어른이 된다면 이라는 조건을 달아 자신이 불리할 수 있는 자신의 신뢰성이 잃을 수 있는  논의 자체를 틀어막은 것 이다. 나는 애석하게도 이러한 말에 속고 말았던 것이다. 물론 그러한 비겁하고 비열한 어른들은 그걸 진짜로 믿었냐며 어깨를 으쓱하겠지만 말이다. 사실 그들의 이러한 행태는 놀랍지도 않다. 사기를 당한 사람이 잘못이며,  피해를 당한 사람이 잘못이라는

[ Redefinition, 생각 ] 새로운 카테고리를 만들면서

이미지
이번에 Redefinition라는 카테고리를 생성 했다. 이유는 사실 지금 까지 작성했던 글들은  이번에 새로 만든 재정의에 가깝기 때문이다. 왜 재정의를 해야만 할까? 결론적으로 말하면, 이 세상이 점점 빠르게 발달하고 실제로 변하고 있기 때문이다. 세상이 빠르게 발달하고 변하고 있다는 것은  패러다임의 변환이 끊임없이 이루어지고 있다는 것이고 이에 따라 기존에 사용되었던 단어에 대한 정의 또한  크고 작던 간에 변하고 있다는 것 이다. 나는 오프라인/디지털로 변하는 그 사이 쯤에 있던 세대 였고 이 사이에서 이루어지는 변화는 과정을 모두 겪었기 때문에 이러한 변화에 대해 다소 민감하다. 하지만, 이런 재정의는 사실상 이루어지지 않는다. 왜냐하면 일이라는 일상 생활에 매몰되어 있기도 하지만 자본주의 패러다임에서는 눈 앞에 보이는 경제력이 굉장히 중요하기 때문이다. 그렇기 때문에 사회 구성원들은  이런 경제력을 얻기 위한 요소들을 얻어내기 위해  많은 시간을 쏟아부어야 한다. 그렇기에 이런 철학적인 담론들이  중요도에 비해 상대적으로 가치가 떨어지는 것은 어찌보면 당연하다. 이러한 철학적인 담론들이  사회 내부에서 중요한 가치가 있던 시절이 있듯이 현재는 자본주의라는 개념하의 경제력은  현 시대에 굉장히 중요한 가치이다. 이런 나의 말에 어떤 사람들은  노골적으로 싫은 눈치를 줄지는 모르겠지만 말이다. 하지만 그러한 사람들을 포함한 이 흐름은 사회 내부의 구성원들 그 누구도 벗어날 수 없다. 거대한 파도, 패러다임 그 자체이기 때문이다. 사회 구성원들은 좋든 싫든  이러한 거대한 파도 아래 서핑을 즐겨야 한다. 그렇지 못하면 거대한 파도에 휩쓸리기 때문이다. 그렇기 때문에 어찌보면  이러한 사회 내부의 구성원들에게  진정한 자유 의지란 존재할 수 없을지도 모른다. 왜냐하면 좋던 싫던 이 게임에 참가해야만 하기 때문이며 대부분의 사회 구성원들에게 선택권은 존재하지 않기 때문이다. 스스로 가지고 있는 무기가 총이 아닌  고작 나뭇가지를 들고 있다고 하더라도 사회에

[ React, JavaScript ] 함수형 컴포넌트 정의에 대해: function 정의, const 정의(Arrow Function)

이미지
서론 React에서 컴포넌트를 새로 작성한다고 가정해보자. 이 때 가장 먼저해야 하는 것은  어떤 형식으로든 메인 함수를 정의하는 것 부터 시작할 것 이며 이와 동시에 하단에 이를 export 할 때,  디폴트로 설정한다는 코드를 작성하게 될 것이다. 아래와 같이 말이다. function NewComponet (){   return < div > null </ div > ; } export default NewComponet ; 나는 React를 배울 때,  위와 같은 방식으로 배웠기 때문에 항상 위와 같은 방식을 선호 했다. 하지만, 개발자라면 모두 느끼고 있듯이 코딩 스타일이라는 것이 일부 다를 수 있다는 것을 가장 잘 알 것이다. 가장 대표적으로 중괄호를 어떻게 쓰느냐를 예를 들 수 있다. function NewComponet () {   return < div > null </ div > ; } export default NewComponet ; 중괄호 스타일 1 function NewComponet (){   return < div > null </ div > ; } export default NewComponet ; 중괄호 스타일 2 재미있게도 나는 실무를 하면서 이런 선언 방식이  사람에 따라 두 가지 방식으로 정의하는 것을 발견했다. 정의 방법은 아래와 같다. 첫 번째, function 정의  두 번째, const 정의 무엇이 다를까 매우 흥미롭다. 이번에는 이 두 가지 정의 방법에 대해 알아보고 이에 대한 차이점에 대해  그리고 이런 정의 방법에 따라 퍼포먼스 문제를  야기 할 수 있는지에 대해 이야기를 나누어 보자. 함수형 컴포넌트 정의에 대해 : 정의 예 먼저 이 두 가지 방법을 한눈에 보기 위해  두 가지 정의 코드를 먼저 살펴보자. function NewComponet (){   return < div > null </ div >

[ React ] React에 대해 : 리렌더링과 memo 메소드

이미지
서론 React는 기본적으로 언제 리렌더링 될까? React에 대해 조금 지식이 있다면 잘 알다시피 아래와 같이 크게 2가지로 나눌 수 있다. 첫 번째, 컴포넌트의 상태(state), 프로퍼티(props) 변경되었을 때 두 번째, 상위 부모 컴포넌트가 변경되었을 때    첫 번째의 경우는 React의 가상 DOM(VDOM)에서 이전 VDOM과 비교해서 변경 된 곳만 실제 DOM에 업데이트 해주기 때문에 이 경우 신경 쓰지 않아도 된다. 하지만, 이 중 두 번째의 경우가 가장 문제일 수 있는데  부모 컴포넌트가 어떤 값이던 간에 바뀐다면 그 하위의 자식 컴포넌트 모두가 리렌더링 대상이 되기 때문이다 즉, 어떤 한 하위 자식 컴포넌트의 값이 변했을 때, 그와 관련 없는 또 다른 자식 컴포넌트 까지 렌더링 대상이 된다는 것 이다. 그렇기 때문에  여기서 우리는 최적화에 대한 문제에 직면하게 된다. 먼저 두 번째에 경우에 대해 이야기하기 전에  React의 이해를 돕기 위해 첫 번째의 경우 부터 이야기를 나누어보자.   첫 번째: 상태와 프로퍼티가 변경되었을 때 본론에 들어가기 앞서 먼저 VDOM에 대해 이야기를 해보자. 사실 React의 매력은 이 VDOM에 있다고 볼 수 있다. 왜냐하면 일반적인 DOM에서 내부 구성 변경되면 UI를 새로 다시 그리기 때문에  기본적으로 애플리케이션의 성능이 그렇게 썩 좋다고 보기는 힘들다.  하지만 이와 다르게 React의 VDOM은  업데이트 된 부분만 수정하기 때문에 일반 DOM을 활용한 시스템보다는  퍼포먼스 측면에서 유리하다고 할 수 있다. 이렇게 실제 DOM과 가상 VDOM을 동기하는 과정을  reconciliation(조정)이라고 하는 것 같지만 실제로는 diffing이라는 단어를 자주 사용하는 것 같다. VDOM [1]  에 대한 내용과 Reconciliation [2]  에 대해서는  공식 도큐먼트에서 확인하기를 바란다. VDOM에 대한 이야기도 조금 했으니  이제 본론으로 넘어가 보자. 여기서 상태(State)와