2020.12.09

클라우드를 위한 선언형 프로그래밍 이해하기

Matt Asay | InfoWorld
지난 10여년 동안 범용 데이터베이스(오라클, SQL 서버 등)에서 전용 데이터베이스(현재 360개이며 계속 증가하는 중)로의 대대적인 전환이 일어났다. 이제 프로그래밍 언어도 같은 방향을 향하는 것으로 보인다. 
 
ⓒ Getty Images Bank

개발자는 API 중심의 고도로 탄력적인 인프라(자원의 존속 기간이 몇 년이 아닌 며칠 정도)로 이동하면서 코드형 인프라(Infrastructure as Code, IaC)를 구축하고 있다. 그러나 IaC를 어떻게 구축할 것인지는 완결되지 않은 문제다. 여러가지 이유로 처음에는 C, 자바스크립트와 같은 명령형 언어를 사용해서 프로그램에 원하는 최종 상태를 어떻게 달성할지를 알리는 것이 주된 방법이었다. 

그러나 해시코프(HashiCorp)의 HCL, 오소(Oso)의 폴라(Polar) 등 새로운 선언형 언어 모델이 등장했다. 이들 언어에서 개발자는 프로그램에 원하는 최종 상태가 무엇인지를 말할 뿐, 그 상태에 어떻게 이르게 될지에 대해서는 그다지 고민하지 않는다. 두 가지 접근 방법 중에서 더 가볍고 안전한 코드를 산출하는 선언형 프로그래밍이 더 나을 수 있다. 이유를 살펴보자. 
 

왜 선언형 프로그래밍인가 

필자가 오소의 CTO인 샘 스콧에게 또 다른 프로그래밍 언어가 정말 필요한지를 묻자 스콧은 “필요하다”고 답했다. 더 구체적으로는 “명령형 언어의 경우 언어와 목적 간 불일치가 자주 발생한다. 명령형 언어는 구성, 정책 등을 정의하는 것이 아니라 앱과 스크립트를 처음부터 새롭게 쌓아 올리는 사람들에게 맞게 설계됐다”고 답했다. 

스콧은 오소의 폴라와 같은 새로운 선언형 언어의 등장은 사실 언어의 난립에 대한 해결책이 될 수 있다면서 “핵심은 특정 문제를 해결하기 위한 또 다른 언어를 만드는 것이 아니라, 어떤 형태의 임베디드 로직을 짤 때마다 매번 언어를 고안해야 할 필요성을 없앨 수 있는 무언가를 만드는 것”이라고 말했다. 

예를 들어 앱싱크(AppSync) 승인을 위해 작성되는 JSON 코드를 생각해 보자. 

{
   “version” : “2017-02-28”,
   “operation” : “PutItem”,
   “key” : {
      “postId” : $util.dynamodb.toDynamoDBJson($context.arguments.id)
   },
   “attributeValues” : {
      “Author” : $util.dynamodb.toDynamoDBJson($context.identity.username)
      #foreach( $entry in $context.arguments.entrySet() )
         #if( $entry.key !="id" )
            ,”${entry.key}” : $util.dynamodb.toDynamoDBJson($entry.value)
         #end
      #end
   },
   “condition” : {
      “expression” : “attribute_not_exists(postId)”
   }
}


데이터와 로직 사이의 균형을 위해 개발자는 아파치 벨로시티 템플릿 언어(Apache Velocity Template Language)로 코멘트 스타일의 인라인 권한을 썼다. 이는 정적 구성과 템플릿의 조합으로 승인(“authZ”) 로직을 표현하기 위해 개발자들이 거치는 복잡한 과정 중 한 가지 예에 불과하다. 

VM웨어의 재러드 로소프는 “그러나 명령형 프로그래밍을 반드시 사용해야 하는지 여부는 중요한 문제가 아니며 그보다는 ‘지금은 프로그래밍 언어를 사용해 승인 규칙을 표현하지 않지만, 그렇게 하는 편이 맞을지도 모른다’는 것”이라고 말했다. 결국 우리는 프로그래밍 언어가 아닌 데이터를 사용해서 authZ 규칙을 표현한다. 로소프는 authZ 규칙이 아주 간단할 때는 문제가 없다고 말했다. 기본적으로 요청이 들어올 때 요청의 승인 여부를 결정하는 데 참조할 조회 테이블이 있는 것이라고 생각하면 된다. 

아주 쉽다. 
 

IaC와 어울리지 않는 명령형 언어 

그러나 앱싱크 예는 데이터 지향적 명령형 접근 방법이 빠르게 복잡해질 수 있음을 보여준다. 로소프는 “처음에는 비교적 간단한 JSON 문서라도 이후 분기와 조건문과 변수가 추가되면서 복잡하게 바뀐다”고 설명했다다. 이 접근 방법을 취하는 개발자는 정적 데이터의 구문 내에서 언어와 유사한 의미 체계를 재창조하기 위해 노력하고, 이는 “구문은 난잡하고 라이브러리도 없고 디버거도 없는, 형편없는 프로그래밍 언어”로 이어진다. 

스콧은 “간결하지도 않다. 전통적인 언어로 승인 로직을 표현하기는 어렵다. 폴라와 같은 특수 목적의 선언형 언어가 이 측면에서 표현력이 더 높고 더 간결하다”고 강조했다.  

스콧이 추가로 설명한 바와 같이 개발자가 자바 또는 파이썬으로 프로세스를 표현하려 시도하는 경우 수천 라인의 코드가 필요하고, 그것 자체도 문제지만 이로 인해 실제 비즈니스 로직을 이해하기 힘들게 되는 더 큰 문제가 발생하는 경우가 많다. 반면 선언형 언어는 같은 작업을 몇십 라인의 코드로 수행할 수 있다. 

로소프는 따라서 구성 구문을 명령형 언어 위로 가져오는 방법 대신 authZ 및 관련 기능을 처리하는 작은 프로그램을 사용해야 한다고 말했다. 데이터를 사용해 시스템을 구성하는 측면에서 현재 많은 프로그래밍 문제가 있지만, 로소프에 따르면 프로그램을 사용하는 편이 더 나을 수도 있다. 몇 가지 예를 들면 다음과 같다. 
 
  • 승인 
  • 배포 템플릿(예: 테라폼(Terraform), 앤서블(Ansible) 등). “이러한 각 템플릿은 데이터 언어의 틀 안에서 언어와 유사한 체계를 만들기 위해 시도하지만 그 결과는 끔찍하다.” 풀루미(Pulumi)는 이 문제에 대한 흥미로운 접근 방법을 제안한다. 
  • 워크플로우. 템포럴(Temporal)은 이전에는 도식적 워크플로우 언어로 했던 것을 범용 프로그래밍 언어 형식으로 가져오는 흥미로운 예다. 
 

간편함과 안전을 겸비한 필요한 만큼의 자유 

로소프는 핵심은 프로그래머에게 승인 규칙을 표현하기에 충분한 언어를 제공하는 동시에 버그 하나가 애플리케이션 전체를 망가뜨릴 수 있을 만큼의 자유는 주지 않는 것이라고 말했다. 사용할 언어를 어떻게 결정해야 할까? 로소프는 다음과 같은 세 가지 의사 결정 기준을 제안했다. 
 
  • 언어가 내가 작성해야 하는 전체 프로그램 범위를 표현할 수 있는가? (승인의 경우, 그 언어로 모든 authZ 규칙을 표현할 수 있는가?) 
  • 언어가 간결한가? (YAML로 할 때보다 코드가 더 적고 읽고 이해하기가 쉬운가?) 
  • 언어가 안전한가? (의도적인 행위를 포함해서 프로그래머로 인한 결함의 유입을 차단하는가?) 

선언형 언어가 코드형 인프라 프로그래밍을 위한 쉽고 명확한 답이 되기 위해서는 아직 갈 길이 멀다. 개발자가 명령형 언어를 선택하는 이유 중 하나는 명령형 언어를 중심으로 구축된 방대한 생태계와 문서, 툴 등이다. 따라서 IaC로 승인 구성을 표현하기에 적합하지 않다 해도 명령형 언어로 시작하는 편이 더 쉽다. 

또한 선언형 언어 자체의 초보자 접근성을 높이기 위한 작업도 필요하다. 이것이 예를 들어 폴라가 명령형 구문을 차용하는 이유 중 하나다. 그러나 선언형 접근 방법이 가진 장점을 감안하면 선언형이 IaC의 표준이 되는 것은 시간 문제일 수도 있다. editor@itworld.co.kr


2020.12.09

클라우드를 위한 선언형 프로그래밍 이해하기

Matt Asay | InfoWorld
지난 10여년 동안 범용 데이터베이스(오라클, SQL 서버 등)에서 전용 데이터베이스(현재 360개이며 계속 증가하는 중)로의 대대적인 전환이 일어났다. 이제 프로그래밍 언어도 같은 방향을 향하는 것으로 보인다. 
 
ⓒ Getty Images Bank

개발자는 API 중심의 고도로 탄력적인 인프라(자원의 존속 기간이 몇 년이 아닌 며칠 정도)로 이동하면서 코드형 인프라(Infrastructure as Code, IaC)를 구축하고 있다. 그러나 IaC를 어떻게 구축할 것인지는 완결되지 않은 문제다. 여러가지 이유로 처음에는 C, 자바스크립트와 같은 명령형 언어를 사용해서 프로그램에 원하는 최종 상태를 어떻게 달성할지를 알리는 것이 주된 방법이었다. 

그러나 해시코프(HashiCorp)의 HCL, 오소(Oso)의 폴라(Polar) 등 새로운 선언형 언어 모델이 등장했다. 이들 언어에서 개발자는 프로그램에 원하는 최종 상태가 무엇인지를 말할 뿐, 그 상태에 어떻게 이르게 될지에 대해서는 그다지 고민하지 않는다. 두 가지 접근 방법 중에서 더 가볍고 안전한 코드를 산출하는 선언형 프로그래밍이 더 나을 수 있다. 이유를 살펴보자. 
 

왜 선언형 프로그래밍인가 

필자가 오소의 CTO인 샘 스콧에게 또 다른 프로그래밍 언어가 정말 필요한지를 묻자 스콧은 “필요하다”고 답했다. 더 구체적으로는 “명령형 언어의 경우 언어와 목적 간 불일치가 자주 발생한다. 명령형 언어는 구성, 정책 등을 정의하는 것이 아니라 앱과 스크립트를 처음부터 새롭게 쌓아 올리는 사람들에게 맞게 설계됐다”고 답했다. 

스콧은 오소의 폴라와 같은 새로운 선언형 언어의 등장은 사실 언어의 난립에 대한 해결책이 될 수 있다면서 “핵심은 특정 문제를 해결하기 위한 또 다른 언어를 만드는 것이 아니라, 어떤 형태의 임베디드 로직을 짤 때마다 매번 언어를 고안해야 할 필요성을 없앨 수 있는 무언가를 만드는 것”이라고 말했다. 

예를 들어 앱싱크(AppSync) 승인을 위해 작성되는 JSON 코드를 생각해 보자. 

{
   “version” : “2017-02-28”,
   “operation” : “PutItem”,
   “key” : {
      “postId” : $util.dynamodb.toDynamoDBJson($context.arguments.id)
   },
   “attributeValues” : {
      “Author” : $util.dynamodb.toDynamoDBJson($context.identity.username)
      #foreach( $entry in $context.arguments.entrySet() )
         #if( $entry.key !="id" )
            ,”${entry.key}” : $util.dynamodb.toDynamoDBJson($entry.value)
         #end
      #end
   },
   “condition” : {
      “expression” : “attribute_not_exists(postId)”
   }
}


데이터와 로직 사이의 균형을 위해 개발자는 아파치 벨로시티 템플릿 언어(Apache Velocity Template Language)로 코멘트 스타일의 인라인 권한을 썼다. 이는 정적 구성과 템플릿의 조합으로 승인(“authZ”) 로직을 표현하기 위해 개발자들이 거치는 복잡한 과정 중 한 가지 예에 불과하다. 

VM웨어의 재러드 로소프는 “그러나 명령형 프로그래밍을 반드시 사용해야 하는지 여부는 중요한 문제가 아니며 그보다는 ‘지금은 프로그래밍 언어를 사용해 승인 규칙을 표현하지 않지만, 그렇게 하는 편이 맞을지도 모른다’는 것”이라고 말했다. 결국 우리는 프로그래밍 언어가 아닌 데이터를 사용해서 authZ 규칙을 표현한다. 로소프는 authZ 규칙이 아주 간단할 때는 문제가 없다고 말했다. 기본적으로 요청이 들어올 때 요청의 승인 여부를 결정하는 데 참조할 조회 테이블이 있는 것이라고 생각하면 된다. 

아주 쉽다. 
 

IaC와 어울리지 않는 명령형 언어 

그러나 앱싱크 예는 데이터 지향적 명령형 접근 방법이 빠르게 복잡해질 수 있음을 보여준다. 로소프는 “처음에는 비교적 간단한 JSON 문서라도 이후 분기와 조건문과 변수가 추가되면서 복잡하게 바뀐다”고 설명했다다. 이 접근 방법을 취하는 개발자는 정적 데이터의 구문 내에서 언어와 유사한 의미 체계를 재창조하기 위해 노력하고, 이는 “구문은 난잡하고 라이브러리도 없고 디버거도 없는, 형편없는 프로그래밍 언어”로 이어진다. 

스콧은 “간결하지도 않다. 전통적인 언어로 승인 로직을 표현하기는 어렵다. 폴라와 같은 특수 목적의 선언형 언어가 이 측면에서 표현력이 더 높고 더 간결하다”고 강조했다.  

스콧이 추가로 설명한 바와 같이 개발자가 자바 또는 파이썬으로 프로세스를 표현하려 시도하는 경우 수천 라인의 코드가 필요하고, 그것 자체도 문제지만 이로 인해 실제 비즈니스 로직을 이해하기 힘들게 되는 더 큰 문제가 발생하는 경우가 많다. 반면 선언형 언어는 같은 작업을 몇십 라인의 코드로 수행할 수 있다. 

로소프는 따라서 구성 구문을 명령형 언어 위로 가져오는 방법 대신 authZ 및 관련 기능을 처리하는 작은 프로그램을 사용해야 한다고 말했다. 데이터를 사용해 시스템을 구성하는 측면에서 현재 많은 프로그래밍 문제가 있지만, 로소프에 따르면 프로그램을 사용하는 편이 더 나을 수도 있다. 몇 가지 예를 들면 다음과 같다. 
 
  • 승인 
  • 배포 템플릿(예: 테라폼(Terraform), 앤서블(Ansible) 등). “이러한 각 템플릿은 데이터 언어의 틀 안에서 언어와 유사한 체계를 만들기 위해 시도하지만 그 결과는 끔찍하다.” 풀루미(Pulumi)는 이 문제에 대한 흥미로운 접근 방법을 제안한다. 
  • 워크플로우. 템포럴(Temporal)은 이전에는 도식적 워크플로우 언어로 했던 것을 범용 프로그래밍 언어 형식으로 가져오는 흥미로운 예다. 
 

간편함과 안전을 겸비한 필요한 만큼의 자유 

로소프는 핵심은 프로그래머에게 승인 규칙을 표현하기에 충분한 언어를 제공하는 동시에 버그 하나가 애플리케이션 전체를 망가뜨릴 수 있을 만큼의 자유는 주지 않는 것이라고 말했다. 사용할 언어를 어떻게 결정해야 할까? 로소프는 다음과 같은 세 가지 의사 결정 기준을 제안했다. 
 
  • 언어가 내가 작성해야 하는 전체 프로그램 범위를 표현할 수 있는가? (승인의 경우, 그 언어로 모든 authZ 규칙을 표현할 수 있는가?) 
  • 언어가 간결한가? (YAML로 할 때보다 코드가 더 적고 읽고 이해하기가 쉬운가?) 
  • 언어가 안전한가? (의도적인 행위를 포함해서 프로그래머로 인한 결함의 유입을 차단하는가?) 

선언형 언어가 코드형 인프라 프로그래밍을 위한 쉽고 명확한 답이 되기 위해서는 아직 갈 길이 멀다. 개발자가 명령형 언어를 선택하는 이유 중 하나는 명령형 언어를 중심으로 구축된 방대한 생태계와 문서, 툴 등이다. 따라서 IaC로 승인 구성을 표현하기에 적합하지 않다 해도 명령형 언어로 시작하는 편이 더 쉽다. 

또한 선언형 언어 자체의 초보자 접근성을 높이기 위한 작업도 필요하다. 이것이 예를 들어 폴라가 명령형 구문을 차용하는 이유 중 하나다. 그러나 선언형 접근 방법이 가진 장점을 감안하면 선언형이 IaC의 표준이 되는 것은 시간 문제일 수도 있다. editor@itworld.co.kr


X