.jpg)
.jpg)
엔지니어링 능력을 갖춘 회사들은 심심찮게 딜레마에 빠진다. 외주를 주거나 구매를 할까, 아니면 내부에서 전부 개발할까. 결정하기 매우 힘든 문제인데, 잘못 결정하면 큰 손해까지 발생할 수 있어 더 조심스럽다. 그래서 ‘딜레마’다.
[보안뉴스 문정후 기자] 서양 철학의 아버지라고 불리는 소크라테스는 질문하는 행위를 특히나 강조했던 인물이었다. 끊임없이 묻고, 질문들을 계속해서 정제해 가면서 진리에 가까워질 수 있다고 그는 믿었다. 서로가 협력적인 태도로 대화하고, 탐사하고, 건설적으로 반박함으로써 비판적 사고 능력을 키우고 우리도 모르게 무의식의 기저에 깔려 있는 선입견도 해체할 수 있다는 오늘 날의 ‘소크라테스 질문법’ 이론은 이런 소크라테스의 믿음에서 출발한다.
IT 분야 지도자들 역시 끊임없이 질문하고 또 질문하는 위치에 있다. 하지만 모든 질문에 답이 명쾌하게 나오는 것은 아니다. 어쩌면 IT 분야 지도자들을 가장 많이 괴롭히는 질문은 햄릿의 그것과 크게 다르지 않을 것이다. 바로 ‘직접 개발하느냐 외부에서 구매하느냐’이다. 소프트웨어 개발 능력을 조금이라도 갖추고 있는 조직이라면 크기나 역사나 분야에 상관없이 ‘직접 개발할까, 외부에서 사올까’를 고민해 본 경험이 있을 것이다.
엔지니어링 분야의 스타트업들에 있어 이 ‘만드느냐, 사느냐’ 질문은 특히나 치명적이다. 엔지니어들이라고 한다면 대부분 직접 만드는 능력에 대해 자부심을 가지고 있는 게 보통이며, 그런 사람들이 회사 내 득실대기 때문이다. 이런 회사라면 소프트웨어든 솔루션이든 애플리케이션이든 회사가 구매하겠다고 하면 “만들면 되는 걸 왜 돈 주고 사는가?”라는 반박을 여기 저기서 들을 것이다. 만들 줄 안다고 해서 다 만들어 써야 하는 건 아니라는 걸 모두가 알고 있지만 말이다.
이 난제에 대한 정답은 누구나 알고 있는 것으로 ‘상황에 따라 다르다’이다. 정말 많은 요소들을 고려해야 하며, 많은 변수들이 이 결정에 작용한다. 그렇기 때문에 ‘올바른 사람들에게 올바른 질문’을 할 줄 알아야 하며, 이를 통해 솔직하고 사심 없는 대화를 이어갈 수 있어야 한다. 누군가는 그 무엇보다 돈을 아끼는 것에 중요한 가치를 두고 있고, 누군가는 선입견이 있을 수 있으며, 누군가는 아무런 생각도 없을 수 있다. 맞는 사람이 맞는 대답을 해주고, 그것들이 쌓여 통계가 되고, 조직 차원에서의 결정으로 발전할 때까지 대화를 확장시켜가는 게 중요하다.
꼭 물어야 하는 다섯 가지 질문들
‘소크라테스 질문법’의 핵심은 사안에 딱 맞는 올바른 질문들을 지속적으로 하는 것이다. 그 질문들을 통해 공동체 전체가 보다 날카롭고 비판적으로 사유할 수 있게 되며, 그러므로 보다 논리적이면서 합당한 시야를 갖추게 된다는 게 소크라테스의 생각이었다. 이렇게까지만 말하면 ‘그래서 어떤 질문을 던지라는 거야?’라는 의문이 생길 텐데, 그럴 줄 알고 다음 다섯 가지 질문을 준비했다.
1) 고민의 대상이 되는 ‘기능’이 우리 조직에 있어 핵심적이라고 할 수 있는가?
구매냐 직접 개발이냐, 라는 문제는 의외로 ‘기업의 경쟁력’이라는 것에 깊은 뿌리를 내리고 있는 문제다. 특정 시스템과 아키텍처에 대한 완전한 제어 권한을 가져가는 게 장기적으로 회사의 경쟁력에 도움이 되는 건지, 아니면 큰 상관이 없는 건지를 이해하는 게 중요하다. 필자가 예전에 다녔던 한 회사에서 SOAR 플랫폼을 도입해야 한다는 결정이 내려진 적이 있었다. 역시 회사 내에서는 사느냐 직접 개발하느냐에 대한 토론이 격렬하게 벌어졌었다.
시장에는 뛰어난 SOAR 플랫폼이 여러 개 있었다. 여기 저기 견적만 잘 받고 이야기만 잘 하면 가격도 그리 나쁘지 않게 얻어낼 수 있었다. 하지만 우리는 결국 직접 개발하기로 결정했다. 결정 후 개발 팀은 프로토타입을 만들고 우리에게 필요했던 기능을 구현하는 데 수개월을 썼다. 다시 말해 그 수개월 동안 우리 회사는 SOAR 기능을 전혀 사용할 수 없었다는 것이다. 그러면서 ‘처음부터 사서 도입했으면 시간을 훨씬 생산적으로 사용할 수 있었겠다’는 것을 모두가 깨달았다. 개발이 완료된 후 그 힘든 기간을 거쳤음에도 회사에 그리 큰 이익을 가져다주지 못하기도 했다. 회사의 사업적 방향에 있어서 SOAR가 그리 큰 영향을 미치지 않는다는 것을 우리는 몇 개월을 허비한 후에야 깨달았다.
2. 개발에 들어가는 장기적 비용을 우리는 빠짐없이 이해하고 있는가?
조직들이 구매 대신 개발을 선택하는 이유 중 상당수는 ‘비용 절감’이다. 엔지니어들이 직접 개발을 한다고 했을 때에라도 돈이 들어가는 걸 알고는 있지만 대개는 이쪽이 더 싸다고 생각한다. 엔지니어들의 최초 개발 계획에 나오는 예상 기한과 마감일은 이상적인 경우가 대부분이고, 따라서 맞추기 힘든 경우가 훨씬 많은데(개발 프로젝트가 제때 딱 끝나는 경우가 얼마나 있나 생각해 보라) 비용 절감에만 초점을 맞추다 보면 이걸 생각하지 못하게 된다.
게다가 뭔가를 직접 개발해 사용한다고 했을 때 장기적으로 들어가는 진짜 비용은 ‘유지’와 ‘보수’에서 나온다. 한 CIO는 “소프트웨어 비용의 70%는 구축 이후부터 발생한다”고 말했는데, 이 말이 정확하다. 취약점들을 패치하고, 디펜던시들에서 발생하는 문제들도 찾아서 해결하고, 그러면서 생긴 각종 변화들로 인한 호환성 문제까지 다룬다는 건 생각보다 골치 아픈 일이며, 엔지니어들이 사업적으로 필요한 프로젝트보다 이런 내부 문제에 더 많은 시간을 할애하게 될 지도 모른다. 외주를 주는 게 더 간단할 때가 많다. 그러므로 개발에 들어가는 비용을 계산할 때 유지와 보수 비용을 잊지 않았는지 다시 한 번 검토하는 게 중요하다.
3. 우리 팀의 ‘인간적 요인들’을 인지하고 있는가?
구매와 개발을 고민한다고 했을 때 ‘인간적 요소들’도 당연히 고려해야 한다. 이 당연한 이야기를 하는 이유는 엔지니어들과 비용 이야기를 하다 보면 ‘인간적 요소들’을 간과하기 쉽기 때문이다. 여기서 말하는 ‘인간적 요소들’에는 여러 가지가 있는데, 그 중 가장 결정적인 걸 하나 꼽자면 ‘퇴사 의향’이다. 개발에 참여한 엔지니어가 개발 완료 시점까지 회사에 있을 것인지, 개발과 구축 이후 얼마나 오래 남아 있을 것인지는 비용과 효율을 계산하는 데 있어서 매우 중요한 문제다.
게다가 오늘날 소프트웨어를 다룰 줄 아는 사람은 직업 시장에서 매우 귀하다. 어떤 회사가 우리 귀한 엔지니어에게 몰래 접근해 높은 몸값을 부르며 꼬드길지 모른다. 심지어 그 엔지니어가 그 조건을 수락하지 않으리라는 보장이 없다. 이미 여러 시장과 지역에서는 유능한 엔지니어 빼가기 경쟁이 물밑에서 치열하게 벌어지고 있는 것도 사실이다. 인수인계에 대한 규정을 마련한다거나, 담당자가 바뀌어도 유지와 보수 및 관리가 그리 어렵지 않을 수 있도록 한다는 식으로 미리 계획을 짜두는 것이 필요하다.
4. 지금 필요로 하는 기능이 정말로 기성품으로 충당되지 않는 걸까?
직접 개발을 하는 수많은 이유 중 하나는 시장에 물건이 없다고 생각하기 때문이다. 우리의 필요를 꼭 채워줄 수 있는 물건이나 서비스가 없어서 직접 만든다는 건데, 시장에 정말 그러한 물건이 없다면 당연히 그래야 한다. 하지만 현실은 어떨까? 필요한 게 시장에 없다고 하는 기업들 중 대다수가 사실 ‘정말로 필요한 게 뭔지 모른다’와 ‘시장에 필요한 게 없다’를 혼동한다. 자기들에게 필요한 것을 명확히 규정하지 못하고 모호한 채로 시장을 헤매다 보니 당연히 눈에 차는 걸 발견할 수 없게 되는 것이다.
시장에는 정말 많은 서비스와 애플리케이션과 플랫폼과 솔루션들이 나와 있다. 아무리 세상의 모든 기업들이 고유한 가치를 추구하고 있다고 하더라도 사업 행위에 필요한 기술과 도구들마저 전부 고유한 것들로 채울 수는 없다. 출시된 기성품들로도 거의 모든 필요를 충족시킬 수 있는 게 현대 기술 시장의 현실이다. 꼭 맞는 게 없더라도 적절한 커스터마이징을 통해 해결할 수도 있다. 우리의 문제는 오히려 선택지가 너무 많다는 것이지, 꼭 맞는 물건이 없다는 아닌 게 보통이다. 자신의 필요를 먼저 콕 짚어 설명할 수 있는 단계부터 확고히 거치고 나서 시장을 탐색하기 시작하자.
5. 벤더사는 얼마나 안정적으로 시장에 남아 있을까?
구매를 망설이게 하는 가장 큰 이유 중 하나는 ‘이 회사가 5년 후에도 사업을 하고 있을까? 10년 후에도 있을까?’하는 불안감이다. 지금 큰 돈을 주고 솔루션을 구입했는데, 회사가 몇 년 있다가 시장에서 사라지면 해당 솔루션의 업데이트나 유지, 보수, 관리가 큰 문제가 되기 때문이다. 벤더사의 안정성은 구매 시 반드시 살펴봐야 하는 문제다. 벤더사의 안정성과 상관 없이 꼭 사야만 하나면, 벤더사가 망해 없어졌을 때의 유지와 보수 계획이라도 가지고 있어야 한다.
예를 들어 회사의 데이터를 저장하거나 분석하는 데 필요한 솔루션을 구매한다고 하자. 그런데 그 솔루션을 개발한 회사가 하루아침에 증발한다면 어떻게 될까? 벤더사에 혹여 저장되어 있을지 모르는 데이터들을 찾아 삭제하거나 회수할 수 있어야 한다. 구매하려는 제품(솔루션 등)과 우리 회사의 데이터 사이에 API라든가 명확한 접속 방법이 존재해야 한다. 그래서 벤더사를 거치지 않고도 만일의 때에 데이터를 안전하게 처리하는 게 가능해야 한다. 지나치게 벤더사에 의존해야만 하는 솔루션은 그게 아무리 좋더라도 기피하는 게 좋다.
글 : 길라드 슈리키(Gilad Shriki), 공동 창립자, Descope
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] 서양 철학의 아버지라고 불리는 소크라테스는 질문하는 행위를 특히나 강조했던 인물이었다. 끊임없이 묻고, 질문들을 계속해서 정제해 가면서 진리에 가까워질 수 있다고 그는 믿었다. 서로가 협력적인 태도로 대화하고, 탐사하고, 건설적으로 반박함으로써 비판적 사고 능력을 키우고 우리도 모르게 무의식의 기저에 깔려 있는 선입견도 해체할 수 있다는 오늘 날의 ‘소크라테스 질문법’ 이론은 이런 소크라테스의 믿음에서 출발한다.
[이미지 = gettyimagesbank]
IT 분야 지도자들 역시 끊임없이 질문하고 또 질문하는 위치에 있다. 하지만 모든 질문에 답이 명쾌하게 나오는 것은 아니다. 어쩌면 IT 분야 지도자들을 가장 많이 괴롭히는 질문은 햄릿의 그것과 크게 다르지 않을 것이다. 바로 ‘직접 개발하느냐 외부에서 구매하느냐’이다. 소프트웨어 개발 능력을 조금이라도 갖추고 있는 조직이라면 크기나 역사나 분야에 상관없이 ‘직접 개발할까, 외부에서 사올까’를 고민해 본 경험이 있을 것이다.
엔지니어링 분야의 스타트업들에 있어 이 ‘만드느냐, 사느냐’ 질문은 특히나 치명적이다. 엔지니어들이라고 한다면 대부분 직접 만드는 능력에 대해 자부심을 가지고 있는 게 보통이며, 그런 사람들이 회사 내 득실대기 때문이다. 이런 회사라면 소프트웨어든 솔루션이든 애플리케이션이든 회사가 구매하겠다고 하면 “만들면 되는 걸 왜 돈 주고 사는가?”라는 반박을 여기 저기서 들을 것이다. 만들 줄 안다고 해서 다 만들어 써야 하는 건 아니라는 걸 모두가 알고 있지만 말이다.
이 난제에 대한 정답은 누구나 알고 있는 것으로 ‘상황에 따라 다르다’이다. 정말 많은 요소들을 고려해야 하며, 많은 변수들이 이 결정에 작용한다. 그렇기 때문에 ‘올바른 사람들에게 올바른 질문’을 할 줄 알아야 하며, 이를 통해 솔직하고 사심 없는 대화를 이어갈 수 있어야 한다. 누군가는 그 무엇보다 돈을 아끼는 것에 중요한 가치를 두고 있고, 누군가는 선입견이 있을 수 있으며, 누군가는 아무런 생각도 없을 수 있다. 맞는 사람이 맞는 대답을 해주고, 그것들이 쌓여 통계가 되고, 조직 차원에서의 결정으로 발전할 때까지 대화를 확장시켜가는 게 중요하다.
꼭 물어야 하는 다섯 가지 질문들
‘소크라테스 질문법’의 핵심은 사안에 딱 맞는 올바른 질문들을 지속적으로 하는 것이다. 그 질문들을 통해 공동체 전체가 보다 날카롭고 비판적으로 사유할 수 있게 되며, 그러므로 보다 논리적이면서 합당한 시야를 갖추게 된다는 게 소크라테스의 생각이었다. 이렇게까지만 말하면 ‘그래서 어떤 질문을 던지라는 거야?’라는 의문이 생길 텐데, 그럴 줄 알고 다음 다섯 가지 질문을 준비했다.
1) 고민의 대상이 되는 ‘기능’이 우리 조직에 있어 핵심적이라고 할 수 있는가?
구매냐 직접 개발이냐, 라는 문제는 의외로 ‘기업의 경쟁력’이라는 것에 깊은 뿌리를 내리고 있는 문제다. 특정 시스템과 아키텍처에 대한 완전한 제어 권한을 가져가는 게 장기적으로 회사의 경쟁력에 도움이 되는 건지, 아니면 큰 상관이 없는 건지를 이해하는 게 중요하다. 필자가 예전에 다녔던 한 회사에서 SOAR 플랫폼을 도입해야 한다는 결정이 내려진 적이 있었다. 역시 회사 내에서는 사느냐 직접 개발하느냐에 대한 토론이 격렬하게 벌어졌었다.
시장에는 뛰어난 SOAR 플랫폼이 여러 개 있었다. 여기 저기 견적만 잘 받고 이야기만 잘 하면 가격도 그리 나쁘지 않게 얻어낼 수 있었다. 하지만 우리는 결국 직접 개발하기로 결정했다. 결정 후 개발 팀은 프로토타입을 만들고 우리에게 필요했던 기능을 구현하는 데 수개월을 썼다. 다시 말해 그 수개월 동안 우리 회사는 SOAR 기능을 전혀 사용할 수 없었다는 것이다. 그러면서 ‘처음부터 사서 도입했으면 시간을 훨씬 생산적으로 사용할 수 있었겠다’는 것을 모두가 깨달았다. 개발이 완료된 후 그 힘든 기간을 거쳤음에도 회사에 그리 큰 이익을 가져다주지 못하기도 했다. 회사의 사업적 방향에 있어서 SOAR가 그리 큰 영향을 미치지 않는다는 것을 우리는 몇 개월을 허비한 후에야 깨달았다.
2. 개발에 들어가는 장기적 비용을 우리는 빠짐없이 이해하고 있는가?
조직들이 구매 대신 개발을 선택하는 이유 중 상당수는 ‘비용 절감’이다. 엔지니어들이 직접 개발을 한다고 했을 때에라도 돈이 들어가는 걸 알고는 있지만 대개는 이쪽이 더 싸다고 생각한다. 엔지니어들의 최초 개발 계획에 나오는 예상 기한과 마감일은 이상적인 경우가 대부분이고, 따라서 맞추기 힘든 경우가 훨씬 많은데(개발 프로젝트가 제때 딱 끝나는 경우가 얼마나 있나 생각해 보라) 비용 절감에만 초점을 맞추다 보면 이걸 생각하지 못하게 된다.
게다가 뭔가를 직접 개발해 사용한다고 했을 때 장기적으로 들어가는 진짜 비용은 ‘유지’와 ‘보수’에서 나온다. 한 CIO는 “소프트웨어 비용의 70%는 구축 이후부터 발생한다”고 말했는데, 이 말이 정확하다. 취약점들을 패치하고, 디펜던시들에서 발생하는 문제들도 찾아서 해결하고, 그러면서 생긴 각종 변화들로 인한 호환성 문제까지 다룬다는 건 생각보다 골치 아픈 일이며, 엔지니어들이 사업적으로 필요한 프로젝트보다 이런 내부 문제에 더 많은 시간을 할애하게 될 지도 모른다. 외주를 주는 게 더 간단할 때가 많다. 그러므로 개발에 들어가는 비용을 계산할 때 유지와 보수 비용을 잊지 않았는지 다시 한 번 검토하는 게 중요하다.
3. 우리 팀의 ‘인간적 요인들’을 인지하고 있는가?
구매와 개발을 고민한다고 했을 때 ‘인간적 요소들’도 당연히 고려해야 한다. 이 당연한 이야기를 하는 이유는 엔지니어들과 비용 이야기를 하다 보면 ‘인간적 요소들’을 간과하기 쉽기 때문이다. 여기서 말하는 ‘인간적 요소들’에는 여러 가지가 있는데, 그 중 가장 결정적인 걸 하나 꼽자면 ‘퇴사 의향’이다. 개발에 참여한 엔지니어가 개발 완료 시점까지 회사에 있을 것인지, 개발과 구축 이후 얼마나 오래 남아 있을 것인지는 비용과 효율을 계산하는 데 있어서 매우 중요한 문제다.
게다가 오늘날 소프트웨어를 다룰 줄 아는 사람은 직업 시장에서 매우 귀하다. 어떤 회사가 우리 귀한 엔지니어에게 몰래 접근해 높은 몸값을 부르며 꼬드길지 모른다. 심지어 그 엔지니어가 그 조건을 수락하지 않으리라는 보장이 없다. 이미 여러 시장과 지역에서는 유능한 엔지니어 빼가기 경쟁이 물밑에서 치열하게 벌어지고 있는 것도 사실이다. 인수인계에 대한 규정을 마련한다거나, 담당자가 바뀌어도 유지와 보수 및 관리가 그리 어렵지 않을 수 있도록 한다는 식으로 미리 계획을 짜두는 것이 필요하다.
4. 지금 필요로 하는 기능이 정말로 기성품으로 충당되지 않는 걸까?
직접 개발을 하는 수많은 이유 중 하나는 시장에 물건이 없다고 생각하기 때문이다. 우리의 필요를 꼭 채워줄 수 있는 물건이나 서비스가 없어서 직접 만든다는 건데, 시장에 정말 그러한 물건이 없다면 당연히 그래야 한다. 하지만 현실은 어떨까? 필요한 게 시장에 없다고 하는 기업들 중 대다수가 사실 ‘정말로 필요한 게 뭔지 모른다’와 ‘시장에 필요한 게 없다’를 혼동한다. 자기들에게 필요한 것을 명확히 규정하지 못하고 모호한 채로 시장을 헤매다 보니 당연히 눈에 차는 걸 발견할 수 없게 되는 것이다.
시장에는 정말 많은 서비스와 애플리케이션과 플랫폼과 솔루션들이 나와 있다. 아무리 세상의 모든 기업들이 고유한 가치를 추구하고 있다고 하더라도 사업 행위에 필요한 기술과 도구들마저 전부 고유한 것들로 채울 수는 없다. 출시된 기성품들로도 거의 모든 필요를 충족시킬 수 있는 게 현대 기술 시장의 현실이다. 꼭 맞는 게 없더라도 적절한 커스터마이징을 통해 해결할 수도 있다. 우리의 문제는 오히려 선택지가 너무 많다는 것이지, 꼭 맞는 물건이 없다는 아닌 게 보통이다. 자신의 필요를 먼저 콕 짚어 설명할 수 있는 단계부터 확고히 거치고 나서 시장을 탐색하기 시작하자.
5. 벤더사는 얼마나 안정적으로 시장에 남아 있을까?
구매를 망설이게 하는 가장 큰 이유 중 하나는 ‘이 회사가 5년 후에도 사업을 하고 있을까? 10년 후에도 있을까?’하는 불안감이다. 지금 큰 돈을 주고 솔루션을 구입했는데, 회사가 몇 년 있다가 시장에서 사라지면 해당 솔루션의 업데이트나 유지, 보수, 관리가 큰 문제가 되기 때문이다. 벤더사의 안정성은 구매 시 반드시 살펴봐야 하는 문제다. 벤더사의 안정성과 상관 없이 꼭 사야만 하나면, 벤더사가 망해 없어졌을 때의 유지와 보수 계획이라도 가지고 있어야 한다.
예를 들어 회사의 데이터를 저장하거나 분석하는 데 필요한 솔루션을 구매한다고 하자. 그런데 그 솔루션을 개발한 회사가 하루아침에 증발한다면 어떻게 될까? 벤더사에 혹여 저장되어 있을지 모르는 데이터들을 찾아 삭제하거나 회수할 수 있어야 한다. 구매하려는 제품(솔루션 등)과 우리 회사의 데이터 사이에 API라든가 명확한 접속 방법이 존재해야 한다. 그래서 벤더사를 거치지 않고도 만일의 때에 데이터를 안전하게 처리하는 게 가능해야 한다. 지나치게 벤더사에 의존해야만 하는 솔루션은 그게 아무리 좋더라도 기피하는 게 좋다.
글 : 길라드 슈리키(Gilad Shriki), 공동 창립자, Descope
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-01] 
