글

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

[ Essay - Human ] 툰베리가 주목 받고 있는다는 사실은 사회에 무엇을 외치고 있는가( What does it mean that Greta Thunberg attracts attention in society : 1) : 1

-
이미지
이제 에세이를 쓰는 것도  어느정도 정립되었기 때문에 자유롭게 쓰는 '생각'과  조금은 형식을 갖춘 '에세이'로 나누어서 작성하려고 한다. 그리고 카테고리 '생각'의 경우는 수정이 거의 없지만, 카테고리 '에세이'의 경우 최하단에  간단한 이력을 명시해 놓을 예정이며, 에세이의 수정시 계속해서 업데이트 될 예정이다. 따라서 이후의 글의 카테고리 또한  그렇게 나뉘어질 예정이다. 그리고 이에 따른 대망의 첫번째 에세이로 나는 툰베리가 주목 받는 것이  사회에 어떤 것을 시사하는가에 대해 이야기하고 싶다. 왜냐하면, 사람들이 행동하고 선택하는 것에는  그 나름의 이유가 있기 때문이고 그런 이유에는 내가 인지하지 못하는 어떤 이유가 있음에 틀림없다고 생각하기 때문이다. 어떤 사람들은 툰베리와 그의 지지자들을 보고 '멍청하다'느니 '세상물정을 모른다'느니 '저런 멍청한 꼬맹이가 노벨 평화상의 후보라니!' 라며 마치 세상이 곧 멸망할 것 처럼 이야기하면서 치를 떨지는 모르겠다. 하지만, 위에서도 살짝 언급했듯이  나는 모든 행동에 이유가 있다고 생각하는 사람이다. 그것이 정당한 이유이던 정당하지 않던간에 많은 사람들이 툰베리를 지지하는 이유는  아마 어떤 이유가 있으리라 생각한다. 또한 밀의 '자유'라는 이름하에 그들이 가지는 생각은 정당하다. 물론 그들을 비판하는 것 또한  정당한것은 말할것도 없다. 하지만, 이런것들을 다 떠나서 그 이유에 대해서는 지금의 내가 알 방법이 없다. 그들과 대화를 할 수 있을 수가 없으며, 그들의 이야기는 현재진행형이다. 따라서 그들에 대해 평가를 하는 것은 옳지 못하며, 평가는 후손들의 몫이지 나의 몫이 아니다.
자세한 내용 보기

[ 프로젝트 BEP, Essay - Developer ] 제 2장 : 개발 방법론 - 왜 개발자는 개발 방법론을 배워야 하는가?

-
이미지
이번에는 개발 방법론에 이야기 하려고 한다. 이에 해당하는 학문으로서의 이름은 Software Engineering, 한국어로는 소프트웨어 공학이라는 학문일 것 이다. 그 안에 이번에 이야기 하고자하는 개발 방법론이 포함되어 있다. 여기서 이야기하는 것들은 프로젝트 관점에서 이야기를 한다. 프로젝트의 프로세스는 어떻게 할 것인가? 프로젝트의 비용에 대해서는 어떻게 정할 것인가? 또는 구성원은 어느정도로 하는 것이 좋은가 등등에 대한 학문이다. 아마 건축의 공학적 개념을 소프트웨어에도 적용한것이 아닌가 싶다. 물론 건축의 설계는 실질적인데에 비해 소프트웨어의 설계는 굉장히 추상적이기 때문에 동일 시 할 수는 없을 것이다. 이 Software Engineering이라는 학문안에는 여러가지 개념이 있겠지만, 개발자로서 중요한 곳은 개발 방법론이 아마 가장 중요하다고 생각한다. 그렇다면, 왜 소프트웨어 개발자는 이런 개발 방법론을 알아야할까? 이에 대해서는 '컴퓨터 개론'에 비해서는 비교적 명쾌하다고 할 수 있다. 왜냐하면, 실제 프로젝트는 이런 개발 방법론을 기반으로 개발 프로세스를 가지기 때문이다. 1장에서 이야기 했던 것은 어쩌면 개발 방법론 보다 실무에서 떨어져 있을 수도 있다. 하지만 개발 방법론은 다르다. 소프트웨어 개발자들은 프로젝트의 한 구성원으로서 일을 한다. 그리고 프로젝트의 책임자들은 이런 개발 방법론을 기반으로 실제 개발 프로세스(일정)를 작성한다. 따라서 우리는 이런 개발 방법론을 학문적으로는 자세히는 알 필요는 없지만, 어떤 것이 있고, 어떤 장점과 단점을 가지고 있는지 알 필요가 있며, 이에 대한 직관을 가질 필요가 있다. 이를 통해 실제 프로젝트를 진행하며, 어떨때는 이 개발 프로세스가, 어떨때는 다른 프로세스가 더 어울리는지 개발자로서 직감적으로 느끼고 있어야 한다. 왜냐하면 우리가 그 프로젝트에 직접 참여하게
자세한 내용 보기

[ 프로젝트 BEP ] 제 1장 : 컴퓨터 개론 - 결론

-
이미지
이렇게 해서 내가 이야기 하고 싶었던 컴퓨터 아키텍처에 대한 이야기를 여기까지 해서 끝내도록 하겠다. 이에 따라 우리는 이야기 하기 앞서서 폰 노이만에 대한 찬사를 했고, 폰 노이만 구조에 대해 알아보며 이를 현실의 디바이스들과 매칭시켜, 확장 및 최근에 컴퓨터 아키텍처를 살펴보고 마지막으로 소프트웨어 개발자로서 왜 병목 현상을 주목해야하는 이야기 까지 내가 하고 싶은 이야기는 한 것 같다. 이것으로 비전공자 주니어로서 컴퓨터 개론에서 컴퓨터 아키텍처에 대한 기본은 가졌다고 생각된다. 물론 마음만 같았으면, 졸업장 같은 증명서를 주고 싶지만, 나는 그렇게 사회적 지위가 높은 사람이 아니다. 따라서 나의 컴퓨터 아키텍처에 대한 '부분적 진리' 를 씹고 뜻어보며 음미한 다음 좀 더 확장시키길 바란다. 물론 어떤 사람들은 '최근에 들어서 하드웨어가  비약적으로 발전함에 따라  메모리 관리는 필요 없다.' 라고 주장할지는 모르겠다. 난 그 의견에 대해 동의하기도 하고, 동의하지 않기도 하다. 왜냐하면 단순하게  메모리 관리는 필요 없다 고 생각하기에는 조금 거부감이 들기 때문이다. IT의 분야는 생각보다 엄청 넓다. 현재의 하드웨어 기반이 충분해 메모리 관리가 필요 없는 분야가 있는 반면, 현재의 하드웨어 기반이 충분치 못해 메모리 관리가 필요한 분야도 있다. 따라서 우리가 스스로 Software Developer 라고 자칭하고 다니는 이상, 그리고 그 위를 목표로 잡고 있는 나는 이런 메모리 관리의 방법은 잘 모를지 언정, 메모리 관리의 필요성 정도는 개발자로서 반드시 알 필요가 있다고 생각한다. 또한 가까운 과거에도 그랬듯이 IT분야에서 계속 일하고 싶다면, 유연한 사고를 가져야 한다. 왜냐하면, 프로그래밍과 같은 코딩은 대게 어린 사람들이 빠르게 잘하기 때문이다. 물론 나이가 들어서 빠르게 잘하는 사람도 있다. 하지만 그런 사람들
자세한 내용 보기

[ 프로젝트 BEP ] 제 1장 : 컴퓨터 개론 - 폰 노이만 병목 현상(Von Neumann bottleneck)과 메모리 누수(Memory Leak) 현상에 대해

-
이미지
폰 노이만 병목 현상(Von Neumann Bottlenect) 우리는 살다보면  병목 현상(Bottleneck) 이라는 말은 한번쯤 들어봤을 것이다. 폰 노이만 구조에도 이런 병목 현상이 발생한다. 폰 노이만 구조 병목 현상 위에서 언급한 분류를 다시 한번 언급하겠다. 제어 장치, 산술장치  → CPU(중앙처리장치) 메모리  → RAM, Cache 등 그외의 디바이스(저장 장치 등)  → HDD, SSD , USB Drive ,CD Drive 등   폰 노이만 구조에서는  메모리 와  그외의 디바이스 를 메모리 라는 이름으로 하나로 묶었던 것을 기억할 것이다. 하지만 현재 컴퓨터 아키텍처는 이를 분리하였는데, 이는 CPU의 처리속도는 빠른것에 비해, 메모리에서 CPU까지 전달 속도가 느림에 따라 메모리(저장 장치등을 말함)에서 CPU까지 아직 데이터가 도달하지 않았는데, CPU는 이미 그 전에 전달 받은 처리를 끝내 대기하는 상태 즉,  병목 현상 이 나타남에 따라 자주 쓰는 데이터들을  메모리(Ram, Cache 등) 에 올려놓는 것 으로 이 구조를 개선한 것이 현재의 컴퓨터 구조이다. 하지만, 이것은 개선한 것에 불과하며, 여전히  병목 현상 은 나타난다. 이렇게 분리함에 따라 SSD나 HDD와 같은 저장장치를 비휘발성 메모리, RAM과 Cache를 휘발성 메모리라고 학문으로서 분류되어 있지만 사실 크게 중요하지는 않다. 중요한 사실은 CPU처리 속도가 너무 빠른 것에 비해, 다른 장치들에서 CPU까지의 전달 속도가 매우 느리다는 것 만 기억하면 된다. 특히, 소프트웨어로서 이야기 되어지는 것은 SSD나 HDD와 같은 즉,  저장 장치의 전달 속도가 비교적 매우 느리다는 것 을 기억하기 바란다. RAM이 컴퓨터 시스템에서 필요한 이유 RAM 이라고 불리우는 메모리가 필요한 이유가 여기서 드러난다. 새로운 처리가 필요할 때마다  HDD나 SSD와 같은 저장 장치에서  다시
자세한 내용 보기

[ 프로젝트 BEP ] 제 1장 : 컴퓨터 개론 - 컴퓨터 아키텍처에 대해

-
이미지
이번 글에서는 컴퓨터 아키텍처에 대해 이야기 할 것이다. 현재에 와서는 여러가지의 컴퓨터 아키텍처가 언급될 수 있으나, 소프트웨어 개발자로서, 그 중 비전공자 주니어에게 알아야 하는 것은 폰 노이만 구조 만 알면 된다고 생각한다. 왜냐하면, 지금 존재하고 있는 컴퓨터 기기들은 모두 이런 폰 노이만 구조에 크게 벗어나지 않았다고 봐도 무방하기 때문이다. 따라서 일단 폰 노이만 구조에 대해 대략적으로 이해하기만 한다면, 다른 컴퓨터 아키텍처에 대한 것은 필요할때 마다 공부하면 된다. 이는 사실 Programmer라던가 Developer등의 다음 레벨의 개발자들에게도 마찬가지라 나는 생각하고 있다. 따라서 이번 글에서 이야기하고자 하는 것은 폰 노이만 구조 단 하나의 컴퓨터 아키텍처만 설명할 것이다. 그럼 이에 대한 이야기를 시작해보자. 폰 노이만에 대해 소프트웨어던 하드웨어던, 우리가 개발자로서 일을 할수 있는 것은 사실 이런 폰 노이만 구조와 같은 이론을 제시한 사람들이 있기 때문이다. 따라서 우리는 개발자로서 초기 컴퓨터 구조를 제시해준 폰 노이만과 그의 동료들에게 머가리를 천번 박아도 모자를 지도 모르겠다. 어쨋든 폰 노이만은 천재로서 세상에 알려져 있다. 그의 업적을 보면, 그 누구도 이에 동의하지 않는 사람은 없을 것이다. 폰 노이만은 아래와 같이 생겼다. 폰 노이만 하지만 이런 의문이 든다. 폰 노이만이 분명 천재이고, 그가 위대한 업적을 남긴것에 깊이 공감하며, 그 업적에 대해서는 찬사를 보내는 바이지만, 소프트웨어 개발자로서 그를 자세히 알 필요가 있을까? 나는 없다고 생각하기 때문에 딱히 언급하지는 않겠다. 하지만, 컴퓨터를 제외하고도 수학 등의 업적을 남긴 사람이기 때문에 어떻게 생긴 사람인지는 알아야 되며, 폰 노이만은 충분히 그럴 자격이 있는 사람이다. 혹시 알고 싶은 사람을 위해서 아래 위키백과의 링크를 남긴다. ( https://en
자세한 내용 보기

[ 프로젝트 BEP, Essay - Developer ] 제 1장 : 컴퓨터 개론 - 왜 개발자는 컴퓨터 개론을 배워야 하는가?

-
이미지
드디어 본론으로 넘어갈 차례다. 앞서 우리는 몇 가지 개발자에 대한 논의를 해보았고, 이런 나의 논의가 교육을 받는 자로 하여금 그리고 이 글을 보고 있을 당신에게 도움이 되었기를 바란다. 또한 나의 논지에 동의하지 않더라도, 그에 대한 논의를 스스로 꼭 해보길 바란다. 왜냐하면, 이런 고찰을 해봐야 개발자가 하는일이 무엇이고, 어떻게 나아가야할지가 즉, 개발자로서 큰그림이 그려지기 때문에 이는 당신의 커리어에도 많은 도움이 될 것이다. 어쨋든 본론으로 다시 돌아가서 먼저 왜 개발자가 컴퓨터 개론을 배워야 하는지 논의부터 하고 넘어가야 된다. 이에 대해 또 논의야?라며 질색을 하는 사람이 있을지는 모르겠지만, 이런 논의들 그러니깐 철학적인 생각은 커리어 뿐만아니라 인생에서도 꼭 필요한 것들이다. 현대 교육에서는 이런 철학적 생각들 보다 지식을 머리에 쑤셔넣는 것을 우선시 하기 때문에 이것이 인생에 있어서, 더 나아가 커리어에 있어서 가장 중요함에도 불구하고 외면시 받고 있는 것이 현실이다. 이런 현실에 대해 밀은 고대 그리스(로마)이 교육을 비교하며, 인간에 대한 근본적인 철학적 생각들을 하지않는 것에 매우 유감스럽다는 표현을 한다. 나 또한 이에 동의한다. 어떤 학문을 받아들일때 왜 이 학문을 배워야하는가에 대해 진지한 고찰이 없다면, 그 학문의 '부분적 진리'라는 원석은 얻을 수 없고, '단순한 지식'이라는 껍데기 밖에 얻을 수 없을 것이다. 심지어 그런 '단순한 지식'은 대개 '진리'는 아니며, 학자들이 논의와 실험을 통해 '이럴 가능성이 높겠다'라는 의견이다. (그들을 비난하는 것이 아니다. 단지 '진리'가 아님을 이야기 하고 싶을 뿐이다.) 따라서 우리는 이런 학문조차 의심할 필요가 있다. 다시 말해서, 흔히 말하는 비판적 사고(Critical Thinking)를 통
자세한 내용 보기

[ 프로젝트 BEP, Essay - Developer ] 논의③ : 개발자는 무엇인가?(What is Developer?)

-
이미지
아마 마지막 논의가 될 것이라 생각된다. 앞서 우리는 개발자에게 학위가 필요한지, 그리고 수학이 필요한지에 대해 조금 논의해봤다. 그럼 마지막으로 개발자(Developer)라는 것이 무엇인지 그리고 어떻게 분류되어지는지, 마지막으로 각각 하는일은 무엇인지에 대해 논의해보자. 개발자란 무엇인가? 사실 한마디로 딱 정의 내리기가 어렵긴하다. 왜냐하면 이 개발자라는 개념 자체가 명쾌하지 않기 때문이다. 따라서 사람들마다 말하는 개발자가 다를 수가 있다. 또한 다른 사람들과의 논의 없이 개발자에 대해 정의내리는 것이 매우 꺼려진다. 그럼에도, 교육을 위해서 하고 넘어가야 하기 때문에 내 스스로 감히 정의 내려보겠다. 사람들이 흔히 말하는 개발자는 다소 다를 수 있지만, 비교적 명쾌하다고는 할 수 있다. 왜냐하면, 개발자가 ' 프로그래밍을 하는 사람' 이라는 직업이라는 것은 비교적 명쾌하기 때문이다. 하지만 정확히 어떤 일을 하는지에 대해서는 위와 같이 명쾌하지 않기 때문에 사람마다 이야기가 다를 수 있지만, 개발자가  '프로그래밍을 하는 사람' 임에는 틀림없다. 하지만 정확히 개발자가 무엇을 하는지에 대해 논의하려면 좀 더 큰 틀에서 봐야할 필요가 있다. 왜냐하면 개발자로서 직업을 가질 수 있는 이유는 큰 틀의 사회에서 필요로 하기 때문이다. 그래서 큰 틀의 사회가 개발자들에게 어떤 것을 요구하는지 알 필요가 있다. 큰 틀에서 보면 개발자는 '사회에서 해결하지 못한 문제를 IT기술을 통해 해결해주는 사람' 이다. 여기서 몇가지 단어를 추출해 줄여본다면 '사회의 문제를 해결해주는 사람' 이다. 따라서 개발자는 크게 보면, 위와 같이 ' 사회의 문제를 해결해주는 사람 '이다. 이런 개발자들이 두각을 나타내기 전의 근대의 사람들은 기록을 남길 때, 남들과 의사소통을 할 때 모두 '종이'라는 매체를
자세한 내용 보기

[ 프로젝트 BEP, Essay - Developer ] 논의② : 개발자에게 수학은 필요한가?(Developer need math?)

-
이미지
오늘은 그 두 번째 논의로 「개발자에게 수학은 필요한가?」 에 대한 논의다. 이 논의는 사실 개발자가 아니더라도 알고 있는 사실인듯 하다. 왜냐하면, 내가 이전에 어떤 한 커뮤니티에 글을 몇개 쓴적이 있는데, 개발자가 아닌 사람들도 개발자에게 수학이 필요하다는 사실은 알고 있음을 확인했었다. 그리고 IT회사가 아니더라도, 잘 모르는 사람이더라도, 개발자에게 '수학' 이 필요하다는 것은 부정하지 않는 사실인듯 하다. 나 또한 필요하다고 생각하는 입장이다. 따라서 오늘은 필요하다는 입장으로 이야기를 하도록 하겠다. 분명 개발자에게 수학이 필요하다는 것은 대부분의 사람이 그렇게 느끼고 있지만, 여기서 '수학' 이라는 것이 ' 어떤 수학' 인지를 확실히 대답하는 사람은 매우 드물다. 따라서 ' 수학이 필요해 '라고 말하는 사람은 많지만, ' 어떤 수학이 필요해 '라고 정확하게 말해주는 사람은 거의 없다고 봐도 무방하다. 그렇기에 개발자에게 필요한 '수학' 이 도대체 ' 어떤 수학' 인지를 먼저 명확히 정의하고, 분류하여 정확히 개발자에게 필요한 '수학' 이라는 것을 명쾌하지 못할지라도 추출할 필요가 있다. 개발자에게 필요한 수학에 대한 정의 먼저 사람들이 가장 먼저 접하게되는 ' 수학 '에 대해 이야기 해보자. 우선 다른 사람들에게 '수학이 뭔지 알아?'라고 물어보면, 대부분의 사람들은 , 덧셈, 뺄셈, 나눗셈 과 같은 즉, 사칙 연산, 미분, 적분, 로그 등과 같은, 어떤 수를 표현하기 위한 규칙 그리고 수식과 그 답에 도달하기 위한 것들을 ' 수학 '이라 말할 것이다. 왜냐하면, 현대 교육시스템에 의해 배워진 수학은 그런 ' 수학 '밖에 없기 때문이다. 하지만 개발자에게 필요한 ' 수학 &
자세한 내용 보기