안녕하세요. 개발자로 일하고 있는 EL 이라고 합니다. 저는 낯선 개념과 서비스였던 Webhook과 AWS Lambda를 이용해서 개발을 진행했던 경험을 소개하려 합니다. 저와 같은 개발 경력이 얼마 안 된 주니어 개발자가 새로운 서비스와 낯선 개념에 너무 당황하지 말고, 배워가는 과정을 즐길 수 있으면 좋겠다 생각 하며 글을 작성합니다. 이 글을 읽는 여러분은, webook이 뭔지 아십니까? AWS에서 제공하는 Lambda는 무엇일까요? 대부분은 아시겠지만, 모르셔도 괜찮습니다. 저도 몰랐습니다. 하지만 알고 나면, 신기하고 재밌는 Webhook과 AWS Lambda입니다. 저는 특정 서비스(이하 서비스 A)에서 가져온 data을 AX의 DB에 저장하고, 이미 있는데 data는 업데이트를 하며, 업데이트된 정보를 AWS SQS/SNS를 활용해서 특정 서비스에 저장된 정보를 보내주는 개발을 해야 했고, 연동을 하면서, 앞서 말한 Webhook과 AWS Lambda을 이해해야 했습니다.

회사에서 어떤 일을 진행할 때, 목적을 분명하게 합니다. 연동 목적은 특정 서비스를 이용하는 AX 고객에게 실시간으로 맞춤 서비스를 제공하기 위함 입니다. 그런데, 목적을 달성하기 위한 개발을 진행하기 위해서 알아야 할 Webhook과 AWS Lambda 가 무엇인지 전혀 알지 못했었습니다. 하지만, 모름지기 개발자라 함은 모르는 개념과 방법을 알아가고, 해결해 나가는 과정의 연속이 아닐까 생각합니다. 들어가기 앞서 이해를 돕기 위해 전체적인 연동흐름을 살펴보겠습니다.

이 글에서 저는 서비스A와 연동을 위해서, 위 그림과 같이 Webhook - APIG - AWS Lambda - DB 로 이어지는 각 단계를 이해하고, 서비스A에서 필요한 data을 저장하고, 업데이트 업무를 진행했던 경험을 바탕으로, 각각의 개념과 연동을 위한 과정을 이야기하려고 합니다. 1년도 안된 액스의 유일한 꼬꼬마 개발자 EL이기에, 설명하는 과정에서 각각의 개념의 깊이와 방법 등이 다소 부족할 수 있습니다. 이 글에서는 저장된 정보를 보내주는 방법으로 활용한, SQS/SNS와 관련한 개념과 연동방법은 글의 내용이 너무 길어질 것 같아서 설명은 생략하겠습니다. 그럼 각각의 개념에 대해서 알아보시죠.
Webhook이란?

저는 Webhook을 만드는 것이 아닌, 특정 앱/웹에서 만든 Webhook을 활용하는 방법을 중점으로 설명드리려 합니다.

Webhook이란 무엇을 말하는 것일까요? Webhook의 개념은 크게 어렵지 않습니다.

A Webhook in web development is a method of augmenting or altering the behavior of a web page or web application with custom callbacks. These callbacks may be maintained, modified, and managed by third-party users and developers who may not necessarily be affiliated with the originating website or application. The term "Webhook" was coined by Jeff Lindsay in 2007 from the computer programming term hook.[1]

The format is usually JSON. The request is done as a HTTP POST request.

참조 : 위키피디아

하나의 앱/웹이 다른 어플리케이션으로 앱관련 이벤트 정보를 실시간으로 제공하기 위한 방법이라고할 수 있습니다. Reverse API, Web Callback, HTTP PUSH API로 불리기도 합니다. 즉, 특정 앱/웹 에서 특정 이벤트가 발생하면, 설정된 data을 Webhook으로 보내주고, Webhook을 통해 들어온 data을 개발이 필요한 개발자가 사용하는 것 입니다.

Webhook을 검색할 때 Polling 이라는 개념을 쉽게 볼 수 있습니다. Polling은 지속적으로 이벤트 발생 여부를 묻고 이에 대해 응답받는 형태를 말합니다. 여기서 지속적으로 이벤트 발생 여부를 확인해야 하기 때문에 Webhook과 달리 불필요한 리소스가 발생할 수 있는 단점이 있습니다. 지속적으로 수신여부를 확인하는 Polling과 달리, Webhook은 특정 이벤트가 발생했을때만 Http Method에 의해서 효율적으로 활용할 수 있는 장점이 있습니다. Slack, MS Teams, GitLab 등 다양한 협업을 위한 APP에서 incoming Webhook 기능을 제공받아 활용해서 연동을 할 수 있습니다. 주의해야 할 점은 Webhook을 보내주는 웹/앱이 중단된 경우입니다. Webhook으로부터 오는 데이터가 유실될 가능성이 있고, 또한 Webhook 서비스가 너무 많은 Event를 발생시킬 경우, 서비스에 대한 DDOS 공격이 될 수도 있다는 점을 숙지하고 있어야 합니다. Webhook을 활용해서 개발할 수 있는 예시를 보면, 쉽게 이해할 수 있습니다. AXer는 회사 메신저로 Slack을 사용하고, 스케줄 관리는 Google Calendar을 사용합니다. Slack으로 메세지를 전달할 때, Google Calendar에서 일정이 생성되면, Webhook을 이용해 일정 정보를 Slack의 원하는 채널에 메세지를 전송할 수 있습니다. 이러한 형태가 Webhook을 활용한 연동 예시입니다.

저는 당시 Webhook 이라는 개념을 처음 알았고, 그럼 API와는 무슨 차이가 있는 것 인지 궁금했습니다. Webhook과 API의 가장 큰 차이는 누가 API와 Webhook을 받는지를 생각하면 쉽습니다. 예를 들어, 위와 같이 서비스A 에서 AX가 data을 받아야 하는 상황이라면, API는 AX가 요청했을 때 서비스A 에서 요청한 자료를 주는 것이고(response), Webhook의 경우에는 서비스A가 설정해 놓은(또는 제공해주는) 특정 이벤트가 발생했을 때 해당 정보들을 보내는 것 입니다.

1 Webhook 설정

우리가 연동하려고 하는 서비스에서는 자체 Webhook을 제공했습니다. Webhook을 받기위한 설정 방법은 서비스마다 다르지만, 설정해야할 공통적인 부분은 같습니다. 첫번째로 Webhook을 보내줄 주소값, 두번째로 Webhook이 발생하는 이벤트(트리거)입니다. 두번째 경우, 제가 연동하는 서비스에서는 특정 메시지를 입력하면 Webhook이 발생하는 구조이었습니다.

예를 들어, “AX는 최고” 라는 단어를 설정하면, “AX는 최고”라는 단어가 트리거가 되고, Webhook을 발생시켜, 해당 Webhook이 설정한 URL주소로 POST요청을 보내고, JSON 형식의 Webhook에서 필요한 data을 활용해서 개발을 진행하면 되는 것 입니다. 처음에는 Webhook으로 들어오는 data 구조를 파악하고, 필요한 data가 어디에 숨어있는지 찾는데 조금 힘들었습니다만, 한번 구조를 파악하면 Webhook으로 들어오는 data구조는 똑같기 때문에 필요한 data만 뽑아서 사용하면 됩니다. 다음으로 Lambda에 대해 알아 보겠습니다.

2 AWS Lambda란?

서버리스와 AWS Lambda에 대한 설명은 제가 존경하는 개발자 Noah께서 작성한 “​⁠서버에서 서버리스로”에서 개념과 장점, 단점을 잘 설명해 주셨습니다. 여기서는 짧게만 설명드리겠습니다.

AWS Lambda 는 Amazon Web Services 의 일부로 Amazon 에서 제공하는 이벤트 기반 의 서버리스 컴퓨팅 플랫폼 입니다. 이벤트 에 대한 응답으로 코드를 실행 하고 해당 코드에 필요한 컴퓨팅 리소스를 자동으로 관리하는 컴퓨팅 서비스입니다. 2014년 11월에 도입되었습니다. [1]

Node.js , Python , Java , Go , [2] Ruby , [3] 및 C# ( . NET 을 통해 )은 모두 2018년부터 공식적으로 지원됩니다 . 2018년 말에 사용자 지정 런타임 지원 [4] 이 AWS Lambda에 추가되었습니다.

참조 : 위키피디아

서버리스라는 것은 서버가 없다는 뜻은 아닙니다. 개발자가 서버를 신경 쓸 필요 없이, AWS에서 제공하는 컴퓨팅 플랫폼을 사용해서 개발자는 서버 이외 다른 개발에 집중할 수 있게 도와주는 아주 유용한 AWS 서비스입니다.

AWS Lambda는 아주 많은 장점이 있지만, 그중 트리거가 실행될 때만 코드를 실행시키고 싶은 경우에 사용할 수 있는 장점이 있습니다. 즉, Webhook이 발생한 경우에만 AWS Lambda을 실행하는 것이죠. 그럼 Webhook이 발생했을 때, 어떻게 AWS Lambda가 실행되고, 어떻게 작동하는지 확인할 수 있을까요?

3. Webhook & Lambda 연동

전체적인 흐름은 간단합니다. 사실 지나고 나니깐 간단하다고 느낍니다만, 당시에는 정말 까마~득했습니다. 무엇인지 모르는 개념들과 Webhook이 어디서 어디로 가고, 필요한 data을 어떻게 가져와서, 저장하고 업데이트해야하는지… 참 막막했지만, 하나하나 배우고 알아가는 재미가 무척(?) 즐거웠습니다.

1) AWS API Gateway로 Webhook 전달

분명히 Webhook과 Lambda만 알면 된다고 했지만, AWS Lambda를 사용하기위해서 꼭 알아야할 개념과 서비스 입니다. AWS API Gateway은 AWS Lambda로 Webhook data을 전달해주기 위한 중간 다리의 역할을 합니다.

서비스A 에서 Webhook이 발생하면 Lambda로 Webhook의 data를 보내주기 위해서 , AWS API Gateway설정이 필요합니다.

Amazon API Gateway는 규모와 관계없이 REST 및 WebSocket API를 생성, 게시, 유지, 모니터링 및 보호하기 위한 AWS 서비스입니다. API 개발자는 AWS 또는 다른 웹 서비스를 비롯해 AWS 클라우드에 저장된 데이터에 액세스하는 API를 생성할 수 있습니다. API Gateway API 개발자는 자체 클라이언트 애플리케이션에서 사용할 API를 생성할 수 있습니다. 또는 타사 앱 개발자가 API를 사용하도록 제공할 수도 있습니다.

참조: Amazon 공식문서

자세한 설명은 공식문서에 아주 잘 나와있습니다. AWS API Gateway는 Http요청을 받아서 처리하는 역할을 합니다. 즉, Webhook을 받아서 AWS Lambda function으로 보내주는 역할을 하는 것 입니다.

Webhook 요청을 처리하는 API Gateway 설정 창 입니다. (설정은 개발자 Noah께서 해주셨습니다.)

설정한 API API Gateway 주소값을 가져와서, 1) Webhook 설정에서 설정해야할 url주소값을 넣어주면, AWS API Gateway를 통해서 AWS Lambda가 실행되는 흐름입니다.

설정이 완료되고, Webhook의 data는 Lambda 함수에서 어떻게 확인할 수 있을까요?

2) 내 컴퓨터에서 작성한 코드가 어떻게 Lambda 함수로 가는 것인가??

일반적으로 개발을 진행할때 VScode를 이용해서 코드 작업을 하고, 로컬에서 웹 페이지를 실행시켜 테스트를 진행하면서, 확인이 완료되면 Github에 코드를 올리는 방식이 제가 진행해 왔던 일반적인 개발 방식입니다. 하지만, Lambda를 이용하면서 실시간으로 테스트 하고, 확인을 마치면 해당 코드를 로컬환경으로 가져와서 Github에 코드를 올려 PR-merge를 진행합니다. merge가 완료되면, 설정된 Github-Action workflow을 통해서 Serverless framework로 배포되는 구조입니다.

저 처럼 이런 구조를 처음 처음 접하는 분이라면, 무척 당황스러울 것입니다. 일반적으로 AWS Lambda 코드 페이지에서 함수를 작성하고, Test를 할 수 있습니다. 하지만, Git을 활용한 버전관리와 코드 관리가 필요하기 때문에 로컬 환경에서 코드를 작성해서 PR을 올리고, merge가 완료되면, 그림 2와 같은 흐름에 의해서 AWS Lambda 함수에 내가 작성한 코드가 업데이트됩니다. 개인적으로는 당시에 어떻게 이게 가능한 것인지 정말 신세계이었습니다. 설정 자체는 제가 존경하는 AX 개발팀의 Noah와 Kevin께서 해주셨지만, 이 흐름을 이해하지 못하고 개발을 진행하는 것은 불가능하다고 느껴졌습니다. Github를 통해서 PR-Merge가 되면 Lambda에 자동으로 업데이트되는 이유는 .yml 이라는 파일에 소스코드 형식으로 설정된 설정값에 의해서, 로컬에서 작업한 코드를 GitgubAction를 통해서 Lambda 함수의 로직이 내가 로컬에서 작성한 코드로 업데이트되는 구조라는 것을 배울 수 있었습니다.

그럼 Webhook의 data는 Lambda함수에서 어떻게 확인할 수 있을까요? 이 간단한 것을 몰라서, 구글링을 얼마나 많이 했는지 모릅니다. event 파라미터에 data가 들어오는 구조인데, event을 어떻게 확인하는지 방법을 몰랐었습니다.

def Webhook_account_create(event, context):
print('Webhook 구조확인',event)

2) AWS CloudWatch도 모르고 뭘 한다고??

그럼 Lambda 함수에 어떻게 Webhook data가 들어오는지 알아야 data을 활용해서 저장을 하든, 업데이트를 하든 할 것입니다. 내가 작성한 코드를 확인하는 방법 자체를 모르고 어떻게 코드를 작성할 수 있을까요? 지금 생각해 보면, 부끄러운 이야기입니다만, 처음에 저는 CloudWatch을 몰라서, Webhook의 data가 Lambda 함수의 event 파라미터을 통해서 들어온다는 것만 알고, event 파라미터에 어떤 구조로 data가 들어오는 것 인지 확인하는 방법을 몰랐었습니다. 그래서 로컬에서 맞는지, 틀리는지도 모르는 코드를 작성하고, 배포를 해야 내가 작성한 코드가 맞았는지, 오류가 났는지 확인할 수 있는 줄 알았습니다. 지금 생각해도 참 황당한 생각인 것 같습니다.

Amazon CloudWatch는 AWS 리소스와 AWS에서 실행 중인 애플리케이션을 모니터링 하는 서비스 입니다. Lambda 함수가 이상 없이 작동하는지, 로그를 확인하고, data을 확인할 수 있는 모니터링 서비스입니다. 위에서 작성한 'Webhook 구조 확인' print도 CloudWatch을 통해서 확인할 수 있습니다.

def Webhook_account_create(event, context):
print('Webhook 구조확인',event)

이렇게 Lambda 함수에서 작성된 로직이 제대로 돌아가는지, 오류가 나는 것은 아닌 것 인지 CloudWatch을 통해서 확인할 수 있습니다.

3. 마치며..

연동작업의 전체적인 흐름은 “특정 서비스에서 Webhook이 발생하면, AWS API Gateway을 통해서 AWS Lambda 함수로 전달되고, 전달된 Lambda함수의 내부 로직의 이상유무를 CloudWatch를 통해서 확인한다” 입니다. 서비스 A와 연동을 통해서, 필요한 Data을 AX DB에 저장하고, 저장한 Data을 필요로 하는 서비스에 AWS SQS/SNS를 이용해서 보내주는 개발을 완료했습니다. 이 개발을 완료하기 까지 우여곡절이 많았지만, 기획한대로 정상적으로 작동되는 것을 확인하니, 결과를 얻기위한 그동안의 노력이 너무 값지게 느껴졌고, 뿌듯했습니다.

전체적인 흐름을 정리하면 위 두 줄밖에 안되는 내용입니다만, 당시 아무것도 몰랐던 저는, 익숙하지 않은 서비스와 개념으로 고생을 좀 했습니다. 전체적인 흐름을 이해하고, 각각의 개념과 서비스가 어떤 역할을 하고, 사용방법은 무엇인지를 배우고 익히는 게 쉬운 일은 아니었습니다. 물론, 이미 해당 서비스에 익숙하신 분들은 고작(?)이라 생각할 수 있을 것 같습니다. 개발 경력이 얼마 안 된 저와 같은 주니어 개발자라면, 새로운 서비스와 개념을 만났을 때 저처럼 많이 당황스럽고 겁이 날 것 같습니다. 하지만 어떤 것이든 너무 당황하지 마시고, 새로운 개념과 서비스를 배우고 알아가는 재미를 느낄 수 있었으면 좋겠다 생각합니다. 우리에게는 구글과 도움을 줄 수 있는 선임 개발자분들이 있으니깐요. 어제도, 오늘도, 우리 개발팀에게 감사하단 말씀 올립니다.

뭐 대단한 개발을 한 경험은 아니지만, 전혀 모르는 개념과 서비스를 배우고, 이런 개발경험을 통해서, AWS Lambda를 활용할 수 있고, Webhook은 무엇인지도 알았다는 약간의 자신감을 얻을 수 있었습니다. 시니어 개발자도 우리와 같은 주니어 시절이 있었습니다. 모르는 것을 알아가고, 왜 안될까를 고민하면서, 안 되는 것을 되게 하는 것이 개발에 즐거움이 아닐까 합니다. 모든 주니어 개발자가 시니어 개발자가 되는 그날까지 화이팅 입니다. 긴 글 읽어주셔서 감사합니다.