글

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

[ 생각 ] 성공을 이루고 싶다면 리스크를 높여야 한다

-
이미지
아마 한국 내에서 누군가에게 꿈이 무엇인가요라고 묻는다면  대게 '성공하고 싶다'는 이야기를 자주 들을 것 이다. 물론 이에 대한 속내는  대게 돈을 많이 벌고 싶다에 가깝긴 하지만 말이다. 하지만 그런 것 치고는  성공이 무엇인지에 대한 이야기는 전혀 하지 않으며 그것이 얼마나 위험하고 그에 따른 이득은 어떠한지 즉, 리스크는 어떠한지에 대한 이야기는 전혀 하지 않는다. 먼저 성공이 무엇인지에 대한 것은  사람마다 매우 상이하기 때문에 깊은 대화를 나누어볼 필요가 있는데 예컨데 위에서 이야기한 단순히 돈을 많이 벌고 싶다는 말 또한  자신의 현재 사회적 위치에 따라 매우 달라질 수 있을 것 이다. 어린아이라면 몇 만원짜리 장난감을 사기 위해 부모의 허드렛일을 하는데에 마다하지 않을 것이기 때문이며 사회 초년생이라면  그동안 억눌려있던 소유의 욕망을 풀어내기 위해 중년 즈음 되면  주식, 부동산과 같은 자산을 얻어내기 위해 어떤 일이든 마다하지 않을 것이다. 스스로가 싫어하는 것을 하더라도 말이다. 따라서 자신의 현재의 위치에 따라 성공이란 매우 상이할 수 있다. 중년에게 있어서 하루 몇 시간이라면 벌어낼 수 있는 푼 돈이  어린아이에게 있어서는 성공일 수도 있기 때문이다. 어느 정도 나이가 있는 인간에게  두발로 걷기란 숨을 쉬는 것과도 같지만 막 태어난 갓난아기에게는 매우 큰 도전과도 같이 말이다. 나에게도 어린 시절에 과자를 사먹기 위해  설거지를 하며 500원을 용돈으로 받았을 때의 기쁨은 잊기가 힘들다. 하지만 지금 나에게 500원이라는 돈은  그 만큼의 기쁨, 만족감과 같은 가치를 얻어낼 수가 없다. 물론 어떠한 사람들은  그게 무슨 성공이냐고 할지는 모르겠으나   그들의 이야기는 별로 논할 가치는 없을 것 이다. 왜냐하면 그들은 스스로의  비열한 면을 만족시키기 위해 그러한 말을 할 뿐,  대화를 하고 싶거나 상대를 걱정하거나  조언을 하려고하는 것은 더더욱 아니기 때문이다. 겉으로만 그러한 척을 할 뿐이다. 그러한 사람들과 의미 있
자세한 내용 보기

[ Essay - Developer ] 애자일 개발 방법론과 뉴턴의 제 1 법칙

-
이미지
애자일 개발 방법론으로 프로젝트를 진행해보면 어느 순간 이러한 느낌을 받게 된다. (만약 받지 못 한다면 꽤나 위험한 상황일지도 모른다)  내가 참가하고 있는 프로젝트는 애자일스럽게 진행되고 있는가? 라는 의문이다. 여기서 더 나아간다면  나의 팀은 정말로 애자일스럽게 일을 하고 있는가? 라는 의문이 들 것이고 더 나아가서 나는 정말로  애자일스럽게 일을 하고 있는가에 대해서 의문이 들 수 있을 것 이다. 애자일 방법론을 목적에 맞게 그리고 방향에 맞게 올바르게 사용하지 않거나 진행하지 않는다면  애자일 방법론으로 프로젝트를 진행하는 의미가 없어진다. 왜냐하면 프로젝트의 목표에 따라서  애자일을 방법론이 올바른 곳으로  향할 수 있느냐 없느냐가 좌우되기 때문이다. 따라서 목표가 명확하지 않다면 결과 또한 그렇게 좋지 않을지도 모른다. 즉, 전체적인 형태만  그럴듯 하게 애자일 형식으로 꾸미지만 내부적인 운용은 결국 워터폴과 다를 바 없다면 워터폴로 돌아가는게 프로젝트를 위해서 더욱 좋다는 것이다. 예컨데,  단순히 애자일로 개발했다는 실적만을 원한다면 아마 최악의 상황으로 발전할 것 이다. 오늘은 왜 애자일 개발론으로 좋은 퍼포먼스를 내기 힘든지 그리고 해결 방안에 대해 이야기를 해보자. 애자일 개발 방법론과 뉴턴의 제 1법칙 우선 애자일 개발 방법론에 대한 유용성에 대해  더 이상 논의할 필요는 없을 것 이다. 많은 기업이 앞다투어  이 방법론을 도입하려고 시도하는 것은  이 방법론의 효용성이 이미 입증되었기 때문이기에  유용성에 대한 논의는 더 이상 의미가 없다. 이러한 지루한 논의 보다는 어떤 상황에서 어떤 프로젝트에서  더 유용한지에 대해 논의를 하는 것이  더 생산적이고 흥미롭기 때문에 더 이상 언급할 필요는 없을 것 이다. 어쨋든 적어도 애자일 개발 방법론을 도입하는 과정속에서는  애자일 개발 방법론이 뉴턴의 제 1법칙과 같이 움직인다고 볼 수 있다. 본격적인 이야기에 앞서서 뉴턴의 제 1법칙 이 법칙은 교과서에서 언급되는 내용이기에  많은 사람들이
자세한 내용 보기

[ Essay - Technology, Essay - Society ] ChatGPT의 등장은 사회의 큰 변화를 줄 수 있는가

-
이미지
어느덧 한 해가 끝나가는 듯 하다. 이 글을 쓰고 있는 시점에  모두가 크리스마스를 맞이 하기 위해 꽤나 분주해보인다. 개인적으로 올해는 꽤나 의미있는 해가 되었다.  일적인 측면에도 사적인 측면에도  그리고 개인적인 성장 측면에도 꽤나 비약적인 성장을 이루었다. 그 덕분에 여력이 생겨 블로그에 작성했던 글들도  작년에 비해 꽤나 다듬어졌고,  다양한 관점의 글도 작성했다. 물론 나는 아직 부족하지만 말이다. 이제 이번 주제에 대해 본격적으로 이야기를 나누어보자. 서론 Chat GPT의 등장은 사회의 큰 변화를 줄 수 있을까? 약 7년전 구글 알파고와 이세돌의  세기적인 바둑 서커스를 보고  어떤 사람은 영화에서 보던  인공지능이 인류를 위협하게 될 것이라며 미디어에서 상상의 날개를 펼치는 사람들이  꽤나 있었던 것으로 기억한다. 과거 나의 글을 보면 알듯이  나는 예전에 머신 러닝에 흥미가 있어  이에 대한 기초 지식을 탐구한 적이 있다. 물론 나는 그 때나 지금이나  나의 의견은 여전히 동일하다. 다만, 지금 까지의 약 인공지능의 놀랄정도의 성능과 비교적 최근 openAi 내부의 정치적인 싸움까지의  스토리를 생각해보자면  흔히 이야기하는 강 인공지능은 아니지만 약 인공지능으로서 기능은  인간을 이미 뛰어 넘었으며  특이점에 다가가고 있거나 혹은  이미 특이점이 왔다고 보는 편이 좋을 것 이다. 수 많은 솔루션들이 이미  산업 전반적으로 들어오기 시작했으며  초읽기 상태에 접어든 것으로 보인다. 그리고 ChatGPT는 7년전 부터 주목받고 있는  약 인공지능의 결정체이다. 왜냐하면,  단순한 바둑을 두는 기계에서  ChatGPT는 하나의 솔루션으로서  서비스되어 대중화 되었으며 일부 업계에서는 이미 효과가 입증되었고, 그렇지 않은 업계는 비용 절감을 위해  도입을 시도하고 있기 때문이다. 나 또한 이미  이러한 서비스를 사용하고 유용성 또한 확실히 느끼고 있기 때문에  사회 전반적인 변화는 확실히 있을 것으로 보인다. 물론 최근 뉴스에서 Open API 팀
자세한 내용 보기

[ Essay - Redefinition, Essay - Intuition ] 휴식에 대해

-
이미지
서론 삶을 살아가면서  공통적으로 깨달아가는게 몇 가지 있는데   그 중 하나가 아마 휴식의 인식에 변화가 있을 것 이다. 왜냐하면 어린 시절의 나의 휴식에 대한 생각은  단지 내가 좋아하는 것을 하는 시간에 불과했고 이는 굉장히 기분에 따라 즉흥적이였기 때문이다. 하지만, 지금은 다르다. 단순히 내가 좋아하는 것을 한다고 하더라도 잘 휴식을 취했다고 볼 수 없다. 누구든 이러한 경험이 있지 않은가? 물론 이에 대한 명확한 근거를 제시할 수는 없지만 분명 주말에 내가 좋아하는 것들을 했음에도  하루 종일 잠을 자거나 아무것도 하지 않았음에도 불구하고 즉, 휴식을 취했음에도 불구하고  왜 월요일에는 그토록 피곤했던 경험 말이다. 아마 어떠한 사람에게는 매주 월요일이  그러할 지도 모르겠다. 왜 그럴까?  이번에는 이 휴식에 대한 이야기를 나누어보자. 휴식에 정의 물론 서론에서 이야기한  '스스로 좋아하는 것'을 하는 것 또한  휴식에 한 가지 요소라고 볼 수 있다. 하지만, 이 것 하나 만으로는  잘 휴식을 취했다고 보기는 매우 힘들기 때문이다.  그렇지 않은가? 왜냐하면 아무리 그런식으로 휴식을 취했다고 한들 다음날 피곤해서 제대로 된 일을 할 수 없는  경우는 누구나 경험하기 때문이다. 그렇기 때문에 이야기에 들어가기 앞서 휴식에 대한 재정의가 필요하다. 그렇다면 이쯤에서 옥스포드 사전에 정의를 살펴보자. 일반적으로 영어로 휴식은 Rest [1]  이며  이에 대한 정의는 아래와 같다. a period of relaxing, sleeping or doing nothing after a period of activity 일정 기간 활동 후 잠을 자거나 아무것도 하지 않는 해소하는(relaxing) 기간 나는 이 정의 중 집중하고 싶은 단어가 있는데  바로 Relaxing이다. 나는 이 단어가 휴식이라는  한 단어를 잘 나타내는 키라고 생각 한다.  곧 바로 Relaxing [2]  에 대한 정의를 살펴보자. helping you to rest a
자세한 내용 보기

[ 프로젝트 BEP ] 제 2장 : 개발 방법론 - 애자일(Agile) : 서론, 개요, 애자일의 세부 프로세스, 애자일의 허와 실

-
이미지
서론 나는 지금으로 부터 약 3년전  프로젝트 BEP라는 태그로 내부 교육을 위한  초안으로 글을 작성한 적이 있다. 그리고 개발 방법론에 대해 이야기 할때 워터폴과 애자일에 대한 이야기 해야만 했는데 비교적 애자일에 대한 경험이 부족했기 때문에  논의를 이어나가기 힘들었고 애자일에 대한 부분은 넘어간 적이 있다. 물론 그럴싸하게 작성할 수는 있으나 이 프로젝트는 내 경험을 녹여내는 것이 목표였기 때문에 중단한다는 선택을 내릴 수 밖에 없었다. 하지만 어느 정도 시간이 지났고 나 또한 애자일에 대한 경험을 쌓았기 때문에  이 제 2장 개발 방법론 애자일에 대한  논의를 이어감과 동시에 초안에 대한 마침표를 찍으려 한다.  개요: 프로세스 그럼 이제 애자일에 대략적인 프로세스를 살펴보자. 애자일의 프로세스를 살펴보자면  정의(define)를 내리고 만들고(build, programming, develop) 배포(Release)를 반복하는 것을 말한다. 앞서 살펴봤던 워터폴 모델을 살펴보자. 그냥 보기만 해도 애자일 방법론이 워터폴 방법론보다 프로세스가 많다는 것을 알 수 있다. 개요: 애자일 방법론의 목표   애자일 방법론의 목표를 살펴보자면  크게 4가지로 볼 수 있다. terative, incremental, and evolutionary(반복, 점진, 진화) Efficient and face-to-face communication(효율적이고 face to face 커뮤니케이션) Very short feedback loop and adaptation cycle(짧은 주기의 피드백 및 짧은 사이클) Quality focus(품질의 집중) 어렵게 말은 써있지만  많은 반복을 통해  점진적으로 프로젝트를 완성시킴으로써 반복 만큼의 커뮤니케이션과 피드백을 통해  의견을 일치시켜 좋은 품질의 소프트웨어를 만드는 것이다. 워터폴의 가장 큰 문제점은  초입 부분에 요건 및 정의(Requirements and Design)가  사실상 완벽하다고 가정하고 진행하기 때문에
자세한 내용 보기