랄라라

지난 포스트 공공 IT제안서 접근전략은 예상외로 너무 많은 분들이 공감해주셨다. 난 어차피 그 분야에 종사하는 경험많은 선수(?)들에게 일종의 팁을 제공한거였다. 따라서 이런저런 앞뒤 사정은 제외하고 컨텐츠의 의미정의에 집중했는데 여러 질문을 받다보니 역시 해설이 조금 필요할 듯 싶어 다시 글을 쓰게 되었다. 그리고 해당 코칭의 당사자였던 A부장님을 다시 만나 코칭의 마지막 시간을 진행하면서 나온 반응도 있어 그 또한 기술하고자 한다.

A부장님의 결과물

A부장은 지난주 위 그림과 같이 설명했을때 무릎을 탁쳤다. 그제서야 감이 잡힌다고 하면서 말이다. 그러나 일주일 후에 만났을때 그는 다시 혼란에 빠져있었다. 결과물을 보니 여전히 ➊➋➌의 구분과 문법이 모호했다. 원인은 간단했다. 그는 RFP에서 고객이(정확히 말하자면 고객사 IT부서의 담당자가) 명시한 문구를 버리지 못하고 적당한 위치를 찾다 다시 혼란에 빠진 것이었다. 그걸 보면서 아마 나의 지난 포스팅을 읽었던 많은 분들도 그렇지 않을까 생각되었다. 그날 나는 A부장에게 다른 방식으로 그 문제를 바라보게 했고 그 방법이 더 쉽다는걸 알았다. 그리고 그 방법을 여기 다시 쓴다. 그리고 몇 가지 질문에 대해서 답을하겠다

다른관점에서 보자

나는 똑같은 얘기지만 표현을 좀 달리해서 설명했다. 아래와 같은 그림이었는데 현재 업무의 흐름에 의거해 주요 주체들을 표시해 놓았다. 각 주체들은 이 일에 대해 자신들만의 입장이 있다. 불만이나 요구사항 같은것들 말이다. 각 주체가 주절거리는 말풍선내의 내용을 정리한 것이 위의 다이어그램이다. 좀 더 정리가 쉽지 않은가? 아래 그림은 시사하는바가 크다. 오늘은 이 그림에 대해 좀 더 얘기하고자 한다

담당부서에 목매지 마라

담당부서(IT부서)만 설득했다고 제안에 승리하는 것은 아니다. 어떤 SI사들은 고객사의 RFP를 대신 써주기도 하고 그들의 프로젝트 기안서 작성을 돕기도 한다. 그러면서 담당부서에만 목을 매는데 조금 더 제안환경을 넓게 확장해서 봐야한다. 담당부서를 설득시킬 논리보다 담당부서가 내부고객(의사결정권자)을 설득할 논리까지 제공해야 이긴다. 거의 담당부서 입장이 되어 고민해야 한다. 그들과 친분이 있든없든 말이다.

시간이 지나면서 제안환경은 담당부서를 의사결정에서 제외시키는 쪽으로 변화해가고있다. 현업인원들 과 외부인사들이 대거 심사위원에 이름을 올리기도 한다. 그러니 포커스를 그쪽으로 이동시켜야 한다. 대대적인 전략수정이 필요하다. 일단 그들은 제안PT 자리에서 제안사의 프리젠터를 처음보게 될 가능성이 높다. 일단 심사위원은 프리젠터를 기본적으로 ‘장사꾼’으로 생각하고 약간 네거티브한 자세로 시작한다고 가정해야 한다.

그래서 처음이 중요하다

상황이 그렇기 때문에 제안사가 전체 비즈니스 상황을 제대로 정리하여 설명하는 것이 중요하다. 현업에서 왔거나 외부에서 온 심사위원이라면 제안사가 비즈니스도 제대로 모르면서 단지 시스템을 납품하려고 달려드는 것을 아주 못마땅하게 여기는 경향이 짙다. 그러므로 시작하자마자 그들의 마인드를 본론의 내용을 수용할 수 있게 ‘세팅’하는 것이 진짜 중요하다. 여기서 실패하면 사실 IT시스템 구축에 대한 내용은 듣지도 않고 자기들이 질문할 수 있는 가격, 유지보수, 비주얼 따위의 대결로 넘어가 버리는 것이다.

IT에 대한 얘기를 최대한 나중에 꺼내고 그들의 비즈니스적 목적에 집중해야 한다. 우리는 결국 그 비즈니스적 목적을 충족시키기 위한 수단으로 IT시스템을 제안하는 것이니 말이다.

RFP의 내용을 과감하게 버려라

고객이 RFP상에서 명시한 배경 및 목적에 대한 문구를 버릴 용기가 있느냐가 최대 관건이다. 사실 내가 구경한 대부분의 RFP는 말도 안되는 멋진 단어들의 조합일 뿐이다. 따라서 일단 RFP의 내용이 별로라면 고민하지 말고 제로베이스에서 시작해서 우리만의 논리를 갖춘다음 비로소 그들의 불편한 심기를 어떻게 달랠지를 (나중에) 걱정하라. A부장 역시 RFP문구를 버리라는 나의 조언에도 불구하고 고객의 심기를 건드리게 될까봐 선뜻 그러겠노라고 하지 못했다.

RFP 문구들의 특성은 수수께끼 같아서 배경, 목적, 필요성, 목표, 요건이라고 정리된 내용들을 사실 어디에 집어넣어도 묘하게 말이 된다. (지금 바로 RFP를 꺼내서 시험해보라) 그러니 ‘당신들이 준 RFP만 보고 쉽게 정리해봤다’고 뻔뻔스럽게 얘기하라. (그것마저 눈치채지 못할 것이다)

A부장의 경우 제안서엔 고객이 명시한 그대로를(왜냐하면 어차피 잘 안읽을 것이기 때문에), PT버전엔 우리의 논리를 들고가기로 했다.

꼭 이렇게까지 해야하나 ?

이 접근에 대해 회의적일 수도 있다. 꼭 그렇게해야 하나 ? 그렇게하면 승률이 높아질까 ? 난 두 가지 측면에서 긍정적이라 본다. 1) 뒤의 모든 내용에 정당성을 부여하여 튼튼한 논리적 방어벽이 된다. 2) 이 자체가 제안을 차별화 시킨다. 난 현재 은행원들의 업무공간이 비좁고, 메모는 거의 안하고 보기만하는 특성때문에 새로운 탁상달력은 공간에 최적화 되어야 하고 보는 달력으로서의 디자인을 가져야 한다는 두 가지 요건을 초반에 주장하고 그에 대한 공감을 얻어냈다. 후반부에 얘기할 디테일, 가령 탁상달력의 높이, 숫자의 크기, 메모공간의 축소, 폰트의 종류 등 세세한 스펙 하나하나는 그 두가지 요건의 통제하에 놓이게 되면서 청중의 챌린지를 방어하기 좋아진다. 숫자의 크기가 너무 큰거 아니냐는 질문은 ‘보는 캘린더로서 1미터 이상의 거리에서 평균시력만 가지고도 보여야 한다’는 초반 요건으로 버텨낼 수 있다.

제안의 차별화 측면도 크다. 거의 대부분이 시간에 쫓기는 상황에서 논리적 완성도와 단순함은 기대하기 힘들게 되었는데 우리는 의도적으로 이를 알기쉬운 논리대결로 몰아가야 한다. 전체적인 제안의 특성이나 구도를 다른 제안팀에서 파악할 수 있었냐고 (무언의) 압박해들어가야 한다. 디자인이나 스피치가 승리의 결정요건이 되는 것은 여러 제안사 전체가 특징없는 내용으로 일관했을때다.

원문 : 공공제안서 접근전략 2

상황

나에게 코칭을 받는 A부장님(이하 A라 하겠다)은 공공기관에서 나온 RFP를 바탕으로 IT프로젝트에 대한 제안서를 작성하려고 한다. 내가 요구하는 것은 수백장에 달하는 제안서의 단순명료한 전략방향이었고 그를 통해 타 SI회사들과의 내용적 차별성을 확보하겠다는 심산이었다. 내용적 차별성이란 IT지식이 높지 않은 심사위원들을 설득하기 위한, 쉽게 이해되는 논리전개였다. 이에 실패한다면 제안의 심사는 내용적인 것을 떠나 발표력, 예쁜 디자인, 태도, 제안금액 등 피상적인 대결로 넘어가 버린다. 어차피 심사위원의 상당수는 복잡한 IT기술을 30분 이내에 이해하기 어렵기 때문.

지난 코칭 7주간 우리는 이 문제에 대해서 여기저기를 들쑤시다가 개미지옥에 들어섰는데 첫 부분인 전략세팅도 제대로 못하고 그 많은 시간을 보내버렸다. (뭐 그런일은 너무 흔하다) 결국 이리저리 찔러보는 중에 그간의 혼돈이 말끔히 정리되어 버렸다. 바로 위의 그림으로 말이다. 위 그림은 제안서 초반부의 전략세팅 부분을 도식화 한 것이다. 이제부터 그림을 보기 시작하라

문제

위 그림에서 ➊,➋,➌ 정도가 RFP와 제안서의 초반부에 등장한다. 문제는 ➊,➋,➌에 실제로 무슨 내용을 넣어야 하는지 의미파악을 못하고 있다는 것. 그리고 그 셋이 논리적으로 연결되지 않는 다는 것이다. 그래서 보통 이 세 부분은 그저 멋지고 뜬구름잡는 말로 얼버무려지게 된다. 이를테면 배경은 ‘전 국민의 건강증진과 삶의 질 개선’과 같은 애매한 말로 말이다. 먼저 이 세 가지의 의미를 분석해보자.

➊ 배경 : 외부 주체의 요구사항

여기서 배경은 요구사항(Needs)이다. 이 니즈의 주체는 사업을 추진하게된 해당 공공기관의 담당부서 바깥쪽에 있는 사람들이다.

예를 들어보자. 재난안전청이란 기관의 상황대응부란 부서가 주관하는 ‘실시간 재난대응 시스템’이란 사업인데, 소나컴퍼니란 곳에서 제안서를 낸다 가정하자.

여기서 배경은 국민들의 요구사항인 ‘사전 재난예보로 물적, 인적 손실 최소화 준비시간 확보’가 된다. (물론 몇 가지가 더 있겠지만) 배경은 상황대응부 입장에서 바라보는 타부서와 최종고객인 국민들의 요구를 적은 것이다. 제안에 참여한 업자인 소나 컴퍼니 입장의 배경이 아닌것이다. 한가지 더 중요한 것은 국민들의 요구이기에 딱 그들 입장에서 나올 수 있는 부분만 정리해야 하며 상황대응부의 업무영역을 침범해서는 안된다. ‘실시간 재난 대응 시스템 마련’은 상황대응부의 입장이지 국민들의 요구라기엔 영역을 넘어온 셈이다. 이때문에 종종 목적에 기술되어야 할 내용이 배경에 있기도 한다.

➋ 목적 : 실행부서 입장의 비즈니스적인 목적

목표는 결과물을 얘기하고 목적은 의도를 나타내니 상이한 개념이다. 목적은 배경이 제대로 기술되어 있으면 상당히 수월하다. 배경에서 요구한 문장을 그대로 수용하면서 그 실행력을 구체화 시켜 추가하는 것이다. ‘사전 재난예보를 위한 감지, 분석, 지침전달 체계를 구축하는 것’ 배경은 상당히 모호한 요구다. 그러나 그 요구를 받은 상황대응부는 그걸 구체화시켜 작동가능한 형태로 만드는 실행부서이므로 그 구체적인 실행에 대해 기술해야 하는 것이다.

여기서 중요한 것은 역시 한발 앞서가지 않는 것이다. 여기에 IT개념이 이미 녹아들어선 안된다. 비즈니스 입장으로 정리하라. IT가 아닌 사람이 수작업으로 한다 생각하고 문구를 만들어야 한다.

➊+➋ = 비즈니스의 이해

공공제안서엔 초기에 항상 비즈니스의 이해에 대한 부분이 있는데 ➊+➋가 바로 그것이다. RFP에 나온 것을 근거로 이를 원뜻의 훼손없이 재정리하고나서 ‘맞느냐’고 물어보는 것이다. 이때 제안사에서 추가로 조사한 정보가 추가될 수도 있다. 이 바로뒤엔 ➌,➍가 나오는데 여기부턴 제안사의 영역이다.
➊+➋와 ➌+➍는 유연하게 연결되어야 한다. 구체적으로 얘기하자면 ➋와 ➌의 맥락 연결이 매끄러워야 하는데 그 때문에 우리는 ➊+➋를 ➌의 인터페이스에 맞게 재정리하는 것이며 그들의 요구를 우리의 프레임내로 끌어들이는 결정적인 지점이다.

임상센터와 관련된 제안발표가 있었는데 가장 첫 슬라이드가 바로 위의 그림이었다. 회의에 참석한 대부분의 관계자가 반대했다. 발표장에 있는 모든 사람들이 잘 아는 내용이므로 생략해도 된다는 것이었다. 물론 나도 그걸 잘 알고 있었다. 하지만 난 이렇게 설명했다.

“모두가 잘 아는 내용으로 시작해 우리만 아는 영역으로 쥐도새도 모르게 끌어들이는 것이 수월한 전개방식입니다”

➌ 목표 : IT기술로 구현된 결과물의 목적에 부합하는 특성

완성된 IT시스템(결과물)이 가지는 목적적합성이다. ‘IoT와 위성통신 기반 실시간 재난감지 시스템’ 정도면 괜찮겠다.

➊,➋,➌ : 비슷하고도 다르다

➊,➋,➌은 어느 제안서에나 등장한다. 그런데 의미가 비슷하다보니 서로 바꿔 쓰기도 하는데 그때부터 전체 전략과 맥락은 어긋나기 시작하고 당연히 의미를 잃기 시작한다. 사실 이들 셋은 거의 같은 내용이다. 다만 주체만 다르다. ➊은 최종고객의 입장, ➋는 (갑의)실행부서, ➌은 제안사의 입장이다. 이 셋에 차별성과 대의명분을 부과하는 것이 ➍다.

➍ 요건 : 제약조건, 대의명분, 고려사항

요건은 원래 발주사(갑)에서 일목요연하게 정해져 나와야 한다. 하지만 요건 자체가 정의되지 않았거나 유명무실한 RFP가 많다. 이건 규격을 얘기하는 것이 아니라 제약조건이나 고려사항을 얘기하는 것이다. 예를들어 미국 국방성이 무기회사들에게 차세대 보병 소총에 대한 제안을 의뢰할때 다음과 같은 요건을 내걸 수 있다.

• 근접전에 적합할 것
• 휴대성이 좋을 것
• 연속발사력이 우수할 것

다른건 몰라도 위의 세 가지 요건은 절대적이다. 요건을 어기면 탈락하기 때문이다. 그런데 우리는 저 요건을 우리의 요건으로 구체화 해야 한다.

• 80cm이하일 것
• 3Kg이하, 60cm이하로 접힐 것
• 32발 이상의 탄창을 사용할 것

이렇게 만들어진 요건이 사실상 논리의 중추가 된다. ➌도 요건의 지배를 받게되며 뒤로 이어지는 수백페이지의 세부내용 ➐도 결국 ➌의 논리에 지배를 받으며 명분을 부여받게 된다. 그리고 저 세 가지의 우리의 요건은 그 하부에 당위성(Why)에 대한 설득자료가 준비되어 있어야 한다. 우리가 전체 제안서의 전략이라 부를만 한 부분은 바로 요건이다.

요건은 ➌에 포함될 수도 있지만 굳이 분리한 것은 요건하나로 여러가지 ➌(대안들)을 만들어 낼 수있기 때문이다. 대안은 공격받을 수 있어도 요건이 건재하면 다음 기회가 있는 반면 요건이 공격당하면 전체가 어려움에 빠질 수 있다.

요건은 ➋로부터 가져온다. 상황대응부의 예에서라면 요건은 ‘실시간성’, ‘재난독립성’이 될 수 있는데 이 둘을 고려하면 솔루션은 ‘위성’밖에 없다. 일반 인터넷을 이용한 정보수집은 그 역시 재난때문에 두절될 수 있기에 그에서 그나마 가장 안전한 것이 ‘위성’이니 말이다.

➎ 얼라인먼트 : IT의 목표는 비즈니스의 얼라인먼트다(=아주 좋은 명분이다)

비 IT계열의 청중들에게 우리 제안을 어필하는 가장 대중적인 방법은 우리의 IT솔루션이 그 회사 비즈니스 전략을 제대로 파악하고 그에 따라 세심하게 설계되었다고 믿게 만드는 것이다. 비 IT 청중은 IT솔루션의 우수성에 점수를 주기보다는 우리 사업을 정확히 꿰뚫고 있는 사람에게 더 호감이 가는 법이다. IT솔루션에 대한 변별력이 낮기 때문이다.

그러니 기본적으로 비즈니스와 IT의 얼라인먼트에 대해 얘기하려면 ➋는 철저히 비즈니스 용어로만, ➌은 비즈니스 용어를 포함한 IT용어로 말하는 것이 낫다.

➏ 배경에서 생략된 현상과 문제

➊ 배경은 주체인 국민들이 겪는 현상과 문제점 파악을 거친 개선방향이 된다. 보통은 생략되어 있지만 제안 PT에서는 가끔 이 부분부터 시작할 때가 많다. ‘우면동 산사태 발생으로 95가구 함몰’-현상, ‘위험성 통보가 늦어 피해를 키움’정도로 정리 할 수 있다.

원문 : 코칭로그 : IT기업의 공공부문 제안전략

- ISP는 Information Strategic planning의 약자로 말 그대로 정보전략계획이다. 즉 최적의 정보(Information)화를 추진 하고 나가기 위한 중장기 전략(Strategic)을 계획(Planning)하는 것으로 중장기 It Masterplan 이라 말할 수 있습니다.

출처 - http://www.dbvision.co.kr/service/servISP.jsp

웹 어플리케이션을 개발할 때 보안은 개발자를 힘들게 만드는 것 중 하나입니다.
허가된 사용자만 접근할 수 있도록 하고, 현재 접속하려는 사용자가 누구인지역시 확인해야 하죠.
또 사용자의 비밀번호는 암호화 하여 저장하기도 해야 합니다.

웹 보안은 3가지로 요약할 수 있습니다.

인증 : 현재 사용자가 누구인지 확인하는 과정입니다. 아이디/비밀번호로 인증을 처리합니다.
인가 : 현재 사용자가 특정 url에 사용한 권한이 있는지 검사합니다.
ui처리 : 권한이 없는 사용자가 해다 url에 접근했을 경우 에러화면등을 보여줍니다.

이 세 가지는 웹 어플리케이션마다 고민하게 하는 요소중 하나입니다. 하지만 구현이 쉽지 않죠.

인증은 쉬우나 그 이후의 과정은 쉽지 않습니다.

하지만 스프링 시큐리티(Spring Security)가 제공하는 틀을 사용하고, 각 웹 어플리케이션에 맞게 커스터마이징 한다면 보다 빠르게 구현을 할 수 있습니다.
또한 스프링 시큐리티는 암호화 기능도 제공하고 있기 때문에 사용자의 비밀번호 등을 암호화 하여 보관할 수도 있습니다.
우선 기본적인 세팅이 필요합니다.

세팅은 다음 블로그를 참조하여 진행하였습니다.
http://zgundam.tistory.com/44

기본적인 세팅이 끝나면 각 웹 어플리케이션에 맞게 커스터마이징이 필요합니다.
현재 진행중인 프로젝트의 예제를 보며 실제 프로젝트에 스프링 시큐리티가 어떻게 적용 되는지에 확인해 보도록 하겠습니다.
진행중인 프로젝트의 필요한 기능은 다음과 같았습니다.

1. 슈퍼 관리자는 모든 권한을 다 갖고 있으며, 모든 기능, 모든 메뉴에 접근 가능하다.
2. 그 외 관리자는 슈퍼 관리자가 권한을 설정할 수 있으며, 해당 권한이 있는 경우에만 그 메뉴에 접근 가능하다.

해당 기능을 위해 우선 Spring Security의 설정 수정이 필요했습니다.

context-security.xml

각 권한별로 접속할 수 있는 url을 설정해주고 모든 url에 슈퍼관리자는 접근이 가능하도록 수정해줬습니다.
다음으로는 사용자가 로그인 했을 때 어떠한 사용자가가 로그인을 하였고, 해당 사용자의 권한은 어떤것들이 있는가를 판단하도록 설정을 해주었습니다.
또한 로그인 시 사용되는 페이지를 지정 해주고, 인증 성공 시 이동 페이지와 인승 실패 시 이동 페이지를 설정해주었습니다.

또 필요한 파일들에 대해 경로를 설정해주었습니다.

순서대로
1. 현재 로그인 하려는 유저의 인증절차
2. 로그인 성공시 이동
3. 로그인 실패시 이동
4. 비밀번호 암호화
입니다.

스프링 시큐리티에서는 UserDetails라는 인터페이스가 제공 되는데 정의된 메소드와 역할을 도표로 정리하면 다음과 같습니다.

이 인터페이스를 상속받아 로그인 관련 기능을 구현하도록 도와주는 것이 바로 UserDetailsService입니다.
기본적으로 스프링 시큐리티에서 제공하는 UserDetailsService상속받아 UserDetailsServiceImpl.java 만들어 다음과 같이 기능을 구현하였습니다.

UserDetailsServiceImpl.java

기본적으로 UserDetailsService의 loadUserByUsername이라는 메서드를 상속 받습니다.
이후 loginForm 에서 입력된 adminId를 통해 해당 유저에 관련된 권한을 가져옵니다.
슈퍼 관리자의 경우에는 ROLE_ADMIN이라는 권한을 authorities.add를 통해 저장시켜 주고,
그외의 관리자의 경우에는 슈퍼관리자가 설정해준 권한을 반복문을 통해 저장시켜줍니다.

이후 스프링 시큐리티에서 제공하는 User객체를 통해 인증을 시도하게 되고, 성공시 AuthenticationSuccessHandler를 호출하게 됩니다.
해당 인터페이스를 상속받는 클래스를 만들어서 로그인 이후의 해야할 액션을 설정시켜줍니다.

AdminAuthenticationSuccessHandler.java

필요한 액션들을 한 후 제일 하단 메소드를 통해 지정한 url로 이동을 하게 됩니다.
이미 스프링 시큐리티 설정에서 defulaltUrl에 대해 지정을 해주었기 때문에 해당 url로 이동을 시킵니다.

만약 인증이 실패(로그인 실패) 했을 경우에 AuthenticationFailureHandler를 호출하게 됩니다.
해당 인터페이스를 상속받는 클래스를 만들어서 로그인 이후의 해야할 액션을 설정시켜줍니다.

AdminAuthenticationFailureHandler.java

로그인 실패 시 어떠한 원인인지에 대해서도 스프링 시큐리티는 지원을 해주고 있습니다.
해당 원인에 대해 정의를 한 후 로그인 실패 페이지로 이동 시킵니다.

로그인 실패 페이지에서는 원인을 확인하고 해당 값에 맞는 alert창을 띄워줬습니다.

슈퍼관리자가 아닌 그외의 관리자가 로그인을 한 후 권한이 없는 페이지에 접근시에는 accessDenied 에러가 발생하게 됩니다.
말 그대로 권한이 없다는 것입니다. 만약 ui처리를 해주지 않는다면 기본 에러페이지로 표시되게 때문에 권한 확인 후 권한이 없을 시 ui처리가 필요하게 됩니다.
해당 설정 역시 스프링 시큐리티에서 지원하고 있습니다.

context-security.xml

권한이 없을 시 해당 url로 이동을 시켰습니다.

스프링 시큐리티는 보안이라는 이슈를 꽤 편리하게 잡아줄 수 있습니다.
이번 포스트에서는 매우 간단하게 설명을 했고, 많이 빠진 부분이 많기 때문에 스프링 시큐리티를 이해하고 실제로 프로젝트에 적용하기란 쉽지 않습니다.
하지만 스프링 시큐리티가 없었다면 해당 기능 구현을 훨씬 더 어려웠을 것이고, 기본적으로 제공해주는 설정이 매우 다양하고 강력하기 때문에 적절하게 사용한다면 보안에 강력한 웹 어플리케이션을 개발할 수 있을 것 입니다.

출처 - http://changjaeso.com/?p=17435