2021.03.25

글로벌 칼럼 | 소모적인 인증 개발 '암흑시대' 끝이 보인다

Matt Asay | InfoWorld
메시지 또는 영상 통화 기능은 트윌리로(Twilio)로 실행할 수 있다. 신용카드 결제 처리는 스트라이프(Stripe)로 해결된다. 머신 러닝 모델 실행 또는 컴퓨터 리소스 확장이 필요하거나 팟캐스트를 비롯한 수백 가지 다른 서비스의 기록이 필요하다면 클라우드 제공업체를 통한 API만 있으면 된다. 반면, 해당 애플리케이션에서 사용자에게 권한을 부여하거나 거부하는 일은 만만치 않다.
 
ⓒ Getty Images Bank

허가 기능은 (인증 기능과 더불어) 앱 개발자에게 가장 기본적으로 필요한 것에 속하지만 이를 실행하는 일은 여전히 엄청난 골칫거리다. 랜달 데게스가 “필자가 웹사이트와 모바일 앱, API 서비스의 인증 및 허가 기능을 구축하려고 할 때마다 막막하지 않은 적이 거의 없었다”라고 지적한 것이 2017년인데, 2021년에도 사정은 마찬가지다.

오소(Oso)는 상황이 개선될 것으로 자신한다. 최근 세쿼이아(Sequoia) 시리즈 A 펀딩을 받은 이 업체는 개발자가 빠르게 허가 기능을 사용할 수 있도록 라이브러리와 사전 구축 통합 기능을 제공하는 한편, 개발자가 필요에 따라 얼마든지 수정할 수 있는 폴라(Polar) 정책 언어를 내장해 제공한다.

오소 CEO 그래함 네레이는 한 인터뷰에서, 허가 기능이 “소프트웨어에서 개별화 또는 추상화가 필요한 다음 계층”이라고 말했다. 필자 역시 동의하며 이와 같은 개발자의 근본적인 고충을 해결하는 기업이 큰 성공을 거둘 가능성이 높다고 생각한다.
 

허가 기능 구현의 어려움

데게스가 2017년에 지적한 내용은 구체적으로 다음과 같다.
 
“사용자 등록과 로그인을 지원하는 간단한 웹사이트를 구축하려고 해도 여전히 하급 허가 개념을 알고 이해해야 한다. 또한, 애플리케이션에서 가장 중요한 데이터인 사용자 개인정보를 보호하기 위해 이러한 개념을 안전하고 안정적으로 구현해야 한다. 내가 무슨 프로그래밍 언어를 사용하든 마찬가지다. 결과적으로 미션 크리티컬하고 고도로 민감한 정보를 다루며 잘못하면 큰 사업 손실을 초래할 수 있는 중복 로직을 엄청나게 많이 구현해야 한다.”

기술의 엄청난 발전 속도를 고려하면 데게스의 글이 나온 지 3년이 넘는 시간 동안 이 문제가 해결됐다고 생각할 수 있다. 틀린 것은 아니지만 완전히 맞는 것도 아니다. 오소의  네레이에 따르면, 개발자 도구의 많은 진전에도 불구하고 개발자는 여전히 각자 저마다의 허가 기능을 만들고 있다. 널리 적용할 수 있을 만큼 일반적이지만 쓸모 있을 만큼 유연한 솔루션은 아직 없었다는 것이다.

이유가 무엇일까. 데게스가 별도의 게시물에서 밝힌 이유에 따르면, 오쓰(OAuth), OIDC(OpenID Connect)같은 허가 툴에는 (개발자가) 이러한 표준의 작동 방식을 이해해야 하고 (기왕이면) 이러한 표준을 본인의 애플리케이션에 적용하는 방법도 이해해야 하는 부담이 있다.

그는 "하지만 현직 개발자 중 99.99%가 오쓰, OIDC는 물론 다른 어떤 보안 사양에 대해서도 잘 모르거나 알고 싶어 하지 않는다. 현직 개발자가 원하는 것은 단지 가장 간단하고 쉽게 그들의 애플리케이션에서 사용자 허가 및 인증 기능을 지원할 방법을 찾는 것이다”라고 말했다.

앤드루 올리버는 오쓰의 브라우저 중심적 문제를 지적한다. 그는 “요청을 하는 사람이 HTTP 리다이렉트(redirect)를 처리할 수 있다고 가정하는데 이처럼 웹 브라우저에 치중하는 것은 모바일 앱에는 물론 사물인터넷 상의 모든 ‘사물’에 방해가 된다”라고 말했다. 정리하면 과거의 허가 툴은 여전히 한계가 너무 많고 지나치게 어렵다.
 

배터리 포함 방식이 중요

네레이가 지적한 것처럼 많은 기술 발전에도 불구하고 허가 기능은 상대적으로 ‘암흑시대’에 머물러 있다. 이 상황을 어떻게 해결해야 할까. 오소는 개발자의 편의를 극적으로 개선해 주고자 허가에 대한 ‘배터리 포함’ 방식은 물론 ‘코드로서의 정책’ 언어를 제공한다. 이 언어를 통해 개발자는 기본적인 사용자화가 아닌 필요에 따른 사용자화가 가능해진다.

그 언어가 바로 폴라다. 일종의 선언형 언어인데 개발자가 원하는 허가 세계의 모습을 기술할 수 있지만, 이를 실현하려면 무엇을 해야 하는지는 신경 쓰지 않아도 된다. 네레이는 "러스트(Rust)에 내장된 폴라는 허가 로직 표현, 즉 해당 애플리케이션에서 누가 무엇을 할 수 있는지를 표현하기 위한 토대 역할을 한다"라고 말했다.

이어 “그 로직을 실행하고 멀티 테넌시와 같은 공통적인 패턴과 계층 및 관계, 그리고 디버거와 REPL을 모델링하기 위한 API 및 가이드를 폴라 위에 구축했다. 그 결과, 오소를 사용하는 개발자는 허가 기능 구축에 쓰는 시간이 줄어든다. 이것이 이 툴의 핵심 가치다"라고 말했다.

그러나 앞으로 해야 할 일이 여전히 많다. 향후 몇 달(그리고 몇 년)에 걸쳐 오소는 라이브러리 및 API의 범위와 유용성을 개선해야 한다. 그래야만 개발자가 허가 기능을 구현하기 위해 해야 하는 번거롭고 힘든 작업을 줄일 수 있다.

여기서 끝이 아니다. 네레이는 오소가 좀 더 크게 생각하고 있다고 밝혔다. 실제로 오소는 현재 오픈 소스 라이브러리로써만 이용할 수 있지만 이를 관리 제품으로 확장할 계획이다. 인터넷의 허가 기능을 가능하게 해 주는 클라우드 서비스를 상상해 보자. 이러한 비전을 실현하려면 사용성, 지연, 데이터 이주를 둘러싼 복잡한 분산 시스템 문제와 씨름해야 한다.

쉽지 않은 작업이지만 성공한다면 오소는 물론 개발자에게 더 큰 보상을 할 수 있다. 2021년 3월 초 옥타(Okta)는 오스0(Auth0)을 65억 달러에 인수하기로 합의했다. 이 거래에 앞서 비슷한 거래가 여러 건 체결된 바 있다. 개발자 생산성 향상을 위해 허가 기능 문제를 해결하려는 기업의 노력이 이어지고 있음을 알 수 있다.

이번 인수 금액만 봐도 허가된 접근을 하나씩 차근차근 제공해 개발자의 삶을 편하게 해 주는 것이 얼마나 큰 가치가 있는지 잘 보여준다. editor@itworld.co.kr
 


2021.03.25

글로벌 칼럼 | 소모적인 인증 개발 '암흑시대' 끝이 보인다

Matt Asay | InfoWorld
메시지 또는 영상 통화 기능은 트윌리로(Twilio)로 실행할 수 있다. 신용카드 결제 처리는 스트라이프(Stripe)로 해결된다. 머신 러닝 모델 실행 또는 컴퓨터 리소스 확장이 필요하거나 팟캐스트를 비롯한 수백 가지 다른 서비스의 기록이 필요하다면 클라우드 제공업체를 통한 API만 있으면 된다. 반면, 해당 애플리케이션에서 사용자에게 권한을 부여하거나 거부하는 일은 만만치 않다.
 
ⓒ Getty Images Bank

허가 기능은 (인증 기능과 더불어) 앱 개발자에게 가장 기본적으로 필요한 것에 속하지만 이를 실행하는 일은 여전히 엄청난 골칫거리다. 랜달 데게스가 “필자가 웹사이트와 모바일 앱, API 서비스의 인증 및 허가 기능을 구축하려고 할 때마다 막막하지 않은 적이 거의 없었다”라고 지적한 것이 2017년인데, 2021년에도 사정은 마찬가지다.

오소(Oso)는 상황이 개선될 것으로 자신한다. 최근 세쿼이아(Sequoia) 시리즈 A 펀딩을 받은 이 업체는 개발자가 빠르게 허가 기능을 사용할 수 있도록 라이브러리와 사전 구축 통합 기능을 제공하는 한편, 개발자가 필요에 따라 얼마든지 수정할 수 있는 폴라(Polar) 정책 언어를 내장해 제공한다.

오소 CEO 그래함 네레이는 한 인터뷰에서, 허가 기능이 “소프트웨어에서 개별화 또는 추상화가 필요한 다음 계층”이라고 말했다. 필자 역시 동의하며 이와 같은 개발자의 근본적인 고충을 해결하는 기업이 큰 성공을 거둘 가능성이 높다고 생각한다.
 

허가 기능 구현의 어려움

데게스가 2017년에 지적한 내용은 구체적으로 다음과 같다.
 
“사용자 등록과 로그인을 지원하는 간단한 웹사이트를 구축하려고 해도 여전히 하급 허가 개념을 알고 이해해야 한다. 또한, 애플리케이션에서 가장 중요한 데이터인 사용자 개인정보를 보호하기 위해 이러한 개념을 안전하고 안정적으로 구현해야 한다. 내가 무슨 프로그래밍 언어를 사용하든 마찬가지다. 결과적으로 미션 크리티컬하고 고도로 민감한 정보를 다루며 잘못하면 큰 사업 손실을 초래할 수 있는 중복 로직을 엄청나게 많이 구현해야 한다.”

기술의 엄청난 발전 속도를 고려하면 데게스의 글이 나온 지 3년이 넘는 시간 동안 이 문제가 해결됐다고 생각할 수 있다. 틀린 것은 아니지만 완전히 맞는 것도 아니다. 오소의  네레이에 따르면, 개발자 도구의 많은 진전에도 불구하고 개발자는 여전히 각자 저마다의 허가 기능을 만들고 있다. 널리 적용할 수 있을 만큼 일반적이지만 쓸모 있을 만큼 유연한 솔루션은 아직 없었다는 것이다.

이유가 무엇일까. 데게스가 별도의 게시물에서 밝힌 이유에 따르면, 오쓰(OAuth), OIDC(OpenID Connect)같은 허가 툴에는 (개발자가) 이러한 표준의 작동 방식을 이해해야 하고 (기왕이면) 이러한 표준을 본인의 애플리케이션에 적용하는 방법도 이해해야 하는 부담이 있다.

그는 "하지만 현직 개발자 중 99.99%가 오쓰, OIDC는 물론 다른 어떤 보안 사양에 대해서도 잘 모르거나 알고 싶어 하지 않는다. 현직 개발자가 원하는 것은 단지 가장 간단하고 쉽게 그들의 애플리케이션에서 사용자 허가 및 인증 기능을 지원할 방법을 찾는 것이다”라고 말했다.

앤드루 올리버는 오쓰의 브라우저 중심적 문제를 지적한다. 그는 “요청을 하는 사람이 HTTP 리다이렉트(redirect)를 처리할 수 있다고 가정하는데 이처럼 웹 브라우저에 치중하는 것은 모바일 앱에는 물론 사물인터넷 상의 모든 ‘사물’에 방해가 된다”라고 말했다. 정리하면 과거의 허가 툴은 여전히 한계가 너무 많고 지나치게 어렵다.
 

배터리 포함 방식이 중요

네레이가 지적한 것처럼 많은 기술 발전에도 불구하고 허가 기능은 상대적으로 ‘암흑시대’에 머물러 있다. 이 상황을 어떻게 해결해야 할까. 오소는 개발자의 편의를 극적으로 개선해 주고자 허가에 대한 ‘배터리 포함’ 방식은 물론 ‘코드로서의 정책’ 언어를 제공한다. 이 언어를 통해 개발자는 기본적인 사용자화가 아닌 필요에 따른 사용자화가 가능해진다.

그 언어가 바로 폴라다. 일종의 선언형 언어인데 개발자가 원하는 허가 세계의 모습을 기술할 수 있지만, 이를 실현하려면 무엇을 해야 하는지는 신경 쓰지 않아도 된다. 네레이는 "러스트(Rust)에 내장된 폴라는 허가 로직 표현, 즉 해당 애플리케이션에서 누가 무엇을 할 수 있는지를 표현하기 위한 토대 역할을 한다"라고 말했다.

이어 “그 로직을 실행하고 멀티 테넌시와 같은 공통적인 패턴과 계층 및 관계, 그리고 디버거와 REPL을 모델링하기 위한 API 및 가이드를 폴라 위에 구축했다. 그 결과, 오소를 사용하는 개발자는 허가 기능 구축에 쓰는 시간이 줄어든다. 이것이 이 툴의 핵심 가치다"라고 말했다.

그러나 앞으로 해야 할 일이 여전히 많다. 향후 몇 달(그리고 몇 년)에 걸쳐 오소는 라이브러리 및 API의 범위와 유용성을 개선해야 한다. 그래야만 개발자가 허가 기능을 구현하기 위해 해야 하는 번거롭고 힘든 작업을 줄일 수 있다.

여기서 끝이 아니다. 네레이는 오소가 좀 더 크게 생각하고 있다고 밝혔다. 실제로 오소는 현재 오픈 소스 라이브러리로써만 이용할 수 있지만 이를 관리 제품으로 확장할 계획이다. 인터넷의 허가 기능을 가능하게 해 주는 클라우드 서비스를 상상해 보자. 이러한 비전을 실현하려면 사용성, 지연, 데이터 이주를 둘러싼 복잡한 분산 시스템 문제와 씨름해야 한다.

쉽지 않은 작업이지만 성공한다면 오소는 물론 개발자에게 더 큰 보상을 할 수 있다. 2021년 3월 초 옥타(Okta)는 오스0(Auth0)을 65억 달러에 인수하기로 합의했다. 이 거래에 앞서 비슷한 거래가 여러 건 체결된 바 있다. 개발자 생산성 향상을 위해 허가 기능 문제를 해결하려는 기업의 노력이 이어지고 있음을 알 수 있다.

이번 인수 금액만 봐도 허가된 접근을 하나씩 차근차근 제공해 개발자의 삶을 편하게 해 주는 것이 얼마나 큰 가치가 있는지 잘 보여준다. editor@itworld.co.kr
 


X