[ 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 - Developer ] 애자일 개발 방법론과 뉴턴의 제 1 법칙


애자일 개발 방법론으로 프로젝트를 진행해보면
어느 순간 이러한 느낌을 받게 된다.
(만약 받지 못 한다면 꽤나 위험한 상황일지도 모른다) 

내가 참가하고 있는 프로젝트는 애자일스럽게 진행되고 있는가?
라는 의문이다.

여기서 더 나아간다면 
나의 팀은 정말로 애자일스럽게 일을 하고 있는가?
라는 의문이 들 것이고

더 나아가서 나는 정말로 
애자일스럽게 일을 하고 있는가에 대해서 의문이 들 수 있을 것 이다.

애자일 방법론을 목적에 맞게 그리고 방향에 맞게
올바르게 사용하지 않거나 진행하지 않는다면 
애자일 방법론으로 프로젝트를 진행하는 의미가 없어진다.

왜냐하면 프로젝트의 목표에 따라서 
애자일을 방법론이 올바른 곳으로 
향할 수 있느냐 없느냐가 좌우되기 때문이다.

따라서 목표가 명확하지 않다면
결과 또한 그렇게 좋지 않을지도 모른다.

즉, 전체적인 형태만 
그럴듯 하게 애자일 형식으로 꾸미지만
내부적인 운용은 결국 워터폴과 다를 바 없다면
워터폴로 돌아가는게 프로젝트를 위해서 더욱 좋다는 것이다.

예컨데, 
단순히 애자일로 개발했다는 실적만을 원한다면
아마 최악의 상황으로 발전할 것 이다.

오늘은 왜 애자일 개발론으로 좋은 퍼포먼스를 내기 힘든지
그리고 해결 방안에 대해 이야기를 해보자.

애자일 개발 방법론과 뉴턴의 제 1법칙


우선 애자일 개발 방법론에 대한 유용성에 대해 
더 이상 논의할 필요는 없을 것 이다.

많은 기업이 앞다투어 
이 방법론을 도입하려고 시도하는 것은 
이 방법론의 효용성이 이미 입증되었기 때문이기에 
유용성에 대한 논의는 더 이상 의미가 없다.

이러한 지루한 논의 보다는
어떤 상황에서 어떤 프로젝트에서 
더 유용한지에 대해 논의를 하는 것이 
더 생산적이고 흥미롭기 때문에 더 이상 언급할 필요는 없을 것 이다.

어쨋든 적어도 애자일 개발 방법론을 도입하는 과정속에서는 
애자일 개발 방법론이 뉴턴의 제 1법칙과 같이 움직인다고 볼 수 있다.

본격적인 이야기에 앞서서 뉴턴의 제 1법칙
이 법칙은 교과서에서 언급되는 내용이기에 
많은 사람들이 알고 있겠지만
엘론 머스크가 자주 언급하는 법칙이기에 
아마 많은 사람들에 머리 속에 남아 있을 것이다.

나는 애자일 개발 방법론을 진행하면서 
가장 빠르게 이 말이 머리 속에서 떠올랐다.

뉴턴의 제 1법칙은 흔히 이야기하는 말로는 
관성의 법칙이며 이에 대한 내용은 아래와 같다.

Every object perseveres in its state of rest, 
or of uniform motion in a right line, 
except insofar as it is compelled to change that state by forces impressed thereon.
물체에 가해지는 힘에 의해 상태가 변경되지 않는 한 
모든 물체는 정지 상태 또는 직선상의 등속 운동 상태를 유지 한다.

이를 애자일 방법론을 도입하는 과정에서 나타나는 현상에 대입해보자.

먼저 도입하려고 한다는 것은 
팀 내/외부가 이미 워터폴에 익숙해져 있다는 것이고 
제 1법칙에서 말하는 상태는 '워터폴'이라는 
전체적인 프로젝트 진행 프로세스가 된다.

문제는 바로 여기서 나타나는데
팀 내/외부 가릴 것 없이 
프로젝트에 관여하고 있는 사람 모두가 
애자일에 대한 강력한 의지가 없다면
워터폴로 다시 돌아가버린다는 것 이다.

이는 최악의 결과로서 
제 1법칙에서 이야기하는 정지 상태가 된다.

어느 정도 의지가 있다고 하더라도 
이는 등속 운동을 할 뿐이며
이 정도로는 진정한 애자일에 도달할 수 없다.

그리고 이 과정에서
형태 혹은 프로세스로서는 애자일이지만 
세부적으로 보면 워터폴과 다를 바 없는 상태가 되는데

그리고 이 결과를 보고 
팀과 그리고 이 팀을 평가하는 외부 인원들은 
애자일에 대한 안 좋은 인식을 받게 되며
결국 선택할 수 있는 폭을 줄이게 되는 결과를 낳게 된다.

당연한 말이겠지만
가능하다면 카드의 수는 많을 수록 좋다.

워터폴이 좋은 프로젝트가 있는 반면
애자일이 좋은 프로젝트가 있기 때문이다.

눈앞에 좋은 카드가 분명 존재하는데 
이를 손에 넣으려 하지 않는다면

이는 전략적으로 실패하는 것이기 때문에
결코 좋다고는 보기 힘들 것이다.

원인 분석


그렇다면 원인은 무엇일까?

먼저 가장 큰 원인부터 이야기해보자.

가장 근본적인 원인은  
이 프로젝트에서 애자일을 도입하려하는지 의도가 불확실하거나
너무나도 욕심이 많기 때문이다.

의도가 불확실하기 때문에 
프로젝트 팀 또한 이에 공감하기 힘들고 
도입에 대한 의논을 해봤자 그렇다할 이유를 찾아내기 힘들다.

그렇기 때문에 이 방법론을 도입하는 동시에
결과물을 원하게 되는데 

방법론을 바꾼다는 것은 일하는 방식 뿐만아니라
인식까지 변해야 하기 때문에 
짧은 기간에 퍼포먼스를 내기란 불가능에 가깝다.

이 리스크를 충분히 인지하지 못한다면 
팀은 결국 가장 안전한 선택으로 
가장 익숙하고 가장 안전한 워터폴의 방식으로 프로젝트를 진행하는 것이 좋다.

물론 개발자로서 문제해결능력을 통해 
불가능해 보이는 것도 가능하게 하는 것이 개발자로서 임무이긴 하지만 
불가능 한 것은 불가능 한 것이다.

왜냐하면, 
리스크를 낮추면서 높은 이득이나 성과를 
얻어 낼 수 있는 방법 따위는 없기 때문이다.

이는 마치 인간의 힘으로 중력이라는 힘에 
벗어나는 방법을 찾아라는 것과 같다. 

높은 성과와 이득을 바란다면 리스크를 높여야하고
리스크를 높이고 싶지 않다면 
당연하게 낮은 성과와 이득을 얻는 것에 만족해야 한다.

모든지 노력으로 가능하다고 믿는 사람들에게는 
불행한 소식이 아닐 수 없다.

그들은 노력만으로 이 또한 해낼 수 있다고 강하게 믿고 있을테니 말이다.
(물론 그들은 남에게만 이야기할 뿐 스스로 행동하지는 않는다)

어쨋든 이외에도 나이가 많건, 직급이 높건 간에 
이러한 웃어른을 더 존중해야한다는 동양적인 사고관에 의해
의미 있는 커뮤니케이션이 불가능하며 

이는 애자일스러운 팀으로 가기 위한 길을 틀어 막기 때문에
성장을 저해할 뿐만 아니라 
워터폴로 돌아가게하는 가장 큰 역할을 한다.

이러한면 때문에 동양권 문화에서는 
애자일 방법론을 포기하는게 
더 나은 방법이지 않을까 하고 생각하기도 한다.

적어도 기업 문화가 어찌되었던
애자일에서는 모두가 프로페셔널해야 되고
위계질서는 딱히 필요가 없다.

모두가 프로페셔널하다면
분명 자기의 레벨은 파악하고 있을 것이고  
퍼포먼스가 좋건 나쁘건 
자신이 할 수 있는 일을 최선을 다해 하면 될 뿐이다.

하지만 흔히 이야기하는 어른들의 사정에 의해 
애자일을 포기한다는 선택지가 없는 경우가 많기 때문에
안타까울 따름이다.

그 다음 원인으로 넘어가 보자.

어쩌면 인간의 한계를 
극복해야만 하는 문제일지도 모르겠다.

바로 익숙한 것에 벗어나지 않으려는 
인간의 특성에 대한 문제이다.

사실 이 원인은 
비롯 애자일 개발 방법론에만 해당하는 문제는 아니다.

섣부른 판단일지는 모르겠지만
인간은 대게 익숙한 것을 선호하며 
이에 잘 벗어나려 하지 않기 때문이다.

선호하는 음식 뿐만 아니라, 음악 
그리고 행동 패턴까지 
어느 정도 형성된 기호는 쉽게 변하지 않으며

시간이 지나 완벽히 굳어지게 되다면
이를 거대한 망치로 큰 충격을 주지 않는 이상 
변화를 기대하기란 매우 힘들게 된다.

애자일 방법론이 워터폴로 돌아가는 이유도
이와 동일 하다.

아이러니하게도 
팀 내부에 워터폴에 익숙한 사람(베테랑)이 많으면 많을 수록 
팀은 자연스럽게 워터폴로 돌아가려고 하며,
시간이 지나면 프로젝트 또한 침식되어
어느 시점에서 형식만 그럴듯하게 애자일로 남고 
실제 내부 프로세스는 워터폴로 형태로 돌아가게 된다.

문제는 이 워터폴에 익숙하다는 것은 
그 만큼 업계에서 일한 기간이 길기 때문에
워터폴에서의 잣대로 판단하려고 하는 경우가 많으며,

수직적인 조직 형태를 선호하거나 
그러한 형태에 장시간 노출되어 있는 사람이 베테랑일 경우
베테랑에 의해 팀이 휘둘리기 때문에 
좋은 애자일 팀으로 나아가기가 매우 힘들다.
(웃어른을 공경해야 한다는 동양적 사고관은 이를 더 욱 가속화 시킨다)

이러한 부분 때문에 
어쩌면 대부분의 팀원 구성을 
IT 업계에서 그렇게 긴 기간 일을 하지는 않았지만
퍼포먼스가 어느 정도 나오는 3~5년차로 구성하는 것이 좋을 수도 있다.

물론 프로젝트의 큰 방향성을 3~5년차에게 바라기에는 
다소 무리가 있기 때문에 베테랑은 어느 정도 필요할지도 모르겠다.

단, 성향이 매우 수직적인 조직을 선호한다면 
위에서 언급했듯이 팀이 휘둘릴수도 있기 때문에
워터폴로 돌아가거나 
서로에 대한 신뢰가 무너짐으로 인해 조직력이 매우 약화될 것 이다. 

애자일에서 가장 중요한 것은 
구성원들의 실력이 아닌 구성원들 간에 
신뢰임을 다시 한번 강조하고 싶다.

완벽하지 않더라도 서로에 대한 신뢰가 없다면
대게 진정한 의미에 커뮤니케이션이 성립하기 힘들다.

마지막으로 모티베이션에 관한 문제이다.

사회에 일하고 있는 사람들을 크게 두 가지로 분류할 수 있는데

첫 번째로 일을 일로서 하는 사람과 
명확한 목표를 갖고 일을 하는 사람이다.

한 마디로 전자의 경우 한 마디로 일(Work)을 잡(Job)으로 다루고 있는 사람이며 
후자의 경우 일(Work)을 커리어(Career)로서 다루고 있는 사람이라 할 수 있다.

물론 여기에 좋고 나쁨은 없다.

이는 인생에서 무엇에 중점을 두느냐에 따라 다르기 때문이다.
이른바 라이프 스타일에 차이라 적어도 나는 생각하고 있기 때문이다.

다만, 문제는 여기서 일을 하는데에 있어서 
모티베이션의 차이가 나게 된다는 점 이다.

예컨데, 
전자의 사람과 후자의 사람과 같이 일하고 있다고 가정해보자.

전자의 사람은 충분한 모티베이션을 가지고 일을 하고 있기 때문에
이번 스프린트 플랜을 세우는 회의에서 
적극적으로 이야기를 나누려하고 필요 이상의 것을 하려 하지만

후자의 사람의 경우 비교적 모티베이션이 적기 때문에 
지금의 현상을 유지하려고 하고 필요 이상의 것을 하려 하지 않을 것 이다.

그리고 시간이 지나면 전자의 사람도 
점점 후자의 사람 처럼 변하게 될 것 인데

대부분의 경우 후자의 사람에 맞추는게 여러모로 편하기 때문이고
그렇게 하나 둘 맞추다보면 팀 전체가 이에 오염되어  
충분한 모티베이션을 가지고 있다고 하더라도 모티베이션은 점점 사라지기 때문이다.

이 모티베이션의 차이는 결과적으로 팀의 성장을 저해함은 물론이고
때로는 한 사람에게 과도한 업무량을 전가해 탈진 상태에 이르게 한다.

만약 충분한 모티베이션을 가진 사람들 끼리 팀을 이룬다면 어떻게 될까?

아마 이 경우가 가장 애자일스러운 팀이 될 것이다.
충분히 모티베이션이 있다면 
서로의 장점을 통해 시너지 효과가 일어나기 때문이다.

또한 이를 통해 자연스럽게 팀은 성장할 수 밖에 없을 것 이다.

하지만, 문제는 한 두 번이야 이 모티베이션을 강제로 주입할 수는 있겠지만
이 것이 지속 불가능 하다는 점이다.

주입을 받는 사람이야 상관 없겠지만
매번 주입을 해야하는 사람은 매우 곤혹스럽기 때문이다.

그렇기 때문에 팀 구성원으로 충분한 모티베이션이 있는 사람으로 
채울 수 없다면 애자일 방법론은 포기하는게 좋지 않을까 생각 한다.

이 외에 문제도 존재하나
이에 대해서는 애자일 방법론에 대해 글에서 
이야기한 내용과 동일하기에 굳이 언급하지는 않겠다.

해결


그렇다면 해결 방안은 존재 할까?

애자일 방법론을 포기한다는 선택지가 없다면
적어도 지금 까지 파악한 바로는 한 가지 뿐이다.

팀 스스로가 끊임 없이 의심하는 수 밖에 없다.

좋은 커리어를 쌓아온 사람들에게
스스로를 의심하라는 것은 매우 어려운 일이기는 하겠지만
이 방법 밖에는 없다.

현재 진행하고 있는 혹은 일하고 있는 방식이 
정말로 애자일스러운 방법이 맞는지 말이다.

물론 이 부분을 상기시키는 것은 
스크럼 마스터의 역할이지만,

이를 팀원 스스로가 인식하고 그리고 
가장 중요한 이러한 움직임이 
정말 애자일 방법론인지에 대한 
의심이 없다면 이 문제를 근본적으로 해결 할 수 없다.

또한 이를 활용할 레트로스펙티브(Retrospective)라는 
스크럼 이벤트 또한 분명히 존재하니 개개인의 반성회가 아닌 
올바르게 팀의 성장를 위한 레트로스펙티브로 활용한다면 
이러한 문제에 대한 하나의 솔루션으로서 활용할 수 있을 것이다.

결론


현재, 전 세계적으로 IT업계에서 유행과도 같이 
워터폴 방법론에서 애자일 방법론으로 바꾸려는 시도가 보이는듯 하다.

이러한 이유로는 아마
그 중 전 세계의 IT업계를 선도 하고 있는 미국은 
이미 꽤나 고무적인 성과를 내고 있기 때문이라 생각한다.

하지만, 
수직적인 형태의 문화가 깊숙히 침투되어 있는
동양권의 특성상 어쩌면 
애자일 방법론은 동양권 혹은 동양인의 심리적 특성상 맞지 않기 때문에 
전반적인 IT업계에서 사용하기란 매우 쉽지 않을지도 모르겠다.

몇 세대에 걸친다면 의도대로 사용할 수 있음에
믿어 의심치 않지만 
지금 당장 성과를 내야만하는 상황이라면 쉽지 않으리라 생각 한다.

결국 이에 대한 해결 방법은 
끊임없이 의심하는 수 밖에는 없어 보인다.

물론 이를 상기시기큰 것은 스크럼 마스터의 몫이겠지만 
팀원 전체가 이 문제에 대해서 인식하고 대응하지 않는다면
애자일 방법론이 제대로 움직이는듯한 느낌은 받기 힘들 것이다.



이 블로그의 인기 게시물

[ Web ] 웹 애플리케이션 아키텍처 (Web Application Architecture)

[ Web ] 서버 사이드(Sever Side) ? 클라이언트 사이드(Client Side)? 1 [서론, 클라이언트 사이드(Client Side)]

[ Web ] 웹 애플리케이션 서버 아키텍처의 정의 및 유형 ( Define and Types of Web Application Server Architecture )