글

[ 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 - Human ] 노력은 사람을 배신하기도 한다.

-
이미지
내가 어릴 때 가장 자주 들었던 이야기가 있다. 바로 '노력은 배신하지 않는다' 라는 격언이다. 이러한 격언을 들으며 자라왔던 나는 정말 '노력은 배신하지 않는다'라는  왜냐하면 정말 수 많은 어른들이  그러한 이야기를 나에게 했기 때문이며, 미디어에서 조차 이런 말을 했기 때문이다. 그렇기 때문에 어렸을 적의 나는  그 격언이 '진리'인 줄 알았으며, 이에 따라 나의 노력을 어른들이 부정한다고 해도 나의 마음속에서는 조금 이상함을 느꼈지만, 그들의 비판인듯한 비난을 받아드릴 수 밖에 없었고, 나의 노력이 부족하다고 생각했었다. 왜냐하면 내가 조금 이상하다며 이야기를 할 때마다 들을 수 있는 대답들은  '아직 너가 어려서 사회를 모른다'라는 식의 이야기 였기 때문이다. 사실이다.  나는 그 당시 어렸고,  사회에 진입할 나이는 아니였기 때문에  그러한 의문점을 마음 한 구석진 곳에 밀어 넣으며 애써 무시했다. 하지만, 나이가 점점 들어감에 따라 조그만 했던  의문이 점점 커지기 시작 했다. 왜냐하면 내가 충분히 노력을 했음에도  대체로 내가 원했던 결과가 나오지 않았으며, 심지어 수준 미달인 경우도 있었다. 이에 대해 나는 의문을 제시했다. '노력은 배신하지 않는다'라는 말이 옳고, 그것이 진리라면 나는 노력을 하지 않은 것이 되기 때문이다. 나는 알고 있다. 나 자신이 충분히 시도했고 노력했다는 사실을 말이다. 하지만 사회는, 어른들은  '노력은 배신하지 않는다'라는 격언에 따라 '너의 노력이 부족하다'라는 이야기를 나에게 서슴 없이 했다. 나의 노력이 정말로 부족했을까? '노력은 배신하지 않는다'라는 격언이 이상한게 아닐까? 라는 생각이 그때부터 들기 시작 했다. 그리고 그때부터  노력이라는 가치에 대해 끊임 없이 생각해 왔었고 최근에 들어서 나는 이런 노력이라는 가치에 대해 결론을 맺을 수 있었다. 따라서 오늘은 이에 대한 이야기를 하려고 한
자세한 내용 보기

[ 프로젝트 BEP ] 제 4장 : 프로그래밍 언어 ① - 왜 프로그래밍 언어는 어려울 수 밖에 없는가?

-
이미지
왜 개발 업무는 입문이 어려울까라는 생각이 문득 들었다. 나의 대학 시절만 떠올려도 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 Language)를 사용하는 것 이였다. 어셈블리어는 가장 기계에 최적화되어 있기 때문에  대안으로서는 훌륭하다고 할 수 있지만
자세한 내용 보기

[ 프로젝트 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
자세한 내용 보기