AWS Lambda 출력 형식 제어 완벽 가이드

AWS Lambda와 서버리스 환경에서 다양한 출력 형식을 제어하는 방법을 배웁니다. JSON, 마크다운, 테이블 형식의 응답을 생성하고, 출력을 검증하며, 파싱 에러를 처리하는 실무 노하우를 담았습니다.

1. 구조화된 출력의 필요성

어느 날 김개발 씨가 AWS Lambda 함수를 작성하던 중 난감한 상황에 부딪혔습니다. API Gateway로 연결된 Lambda 함수가 단순 문자열만 반환해서 프론트엔드 팀에서 데이터를 제대로 파싱하지 못한다는 연락을 받았습니다.

"우리 팀은 JSON 형식이 필요한데, 어떻게 바꿀 수 있나요?"

구조화된 출력이란 데이터를 일정한 규칙과 형식에 맞춰 반환하는 것을 말합니다. 마치 도서관 사서가 책을 분류 체계에 맞춰 정리하는 것처럼, 데이터도 미리 정해진 포맷으로 정돈해야 합니다.

이렇게 하면 데이터를 받는 쪽에서 일관된 방법으로 처리할 수 있고, 오류를 줄일 수 있습니다.

다음 코드를 살펴봅시다.

# 비구조화된 출력 (나쁜 예)
def lambda_handler_bad(event, context):
    # 단순 문자열 반환 - 파싱 어려움
    return "User: John, Age: 30, Status: Active"

# 구조화된 출력 (좋은 예)
def lambda_handler_good(event, context):
    # 명확한 구조로 반환
    return {
        'statusCode': 200,
        'headers': {'Content-Type': 'application/json'},
        'body': {
            'user': 'John',
            'age': 30,
            'status': 'Active'
        }
    }

김개발 씨는 입사 3개월 차 백엔드 개발자입니다. 첫 번째 AWS Lambda 프로젝트를 맡아 열심히 코드를 작성했습니다.

함수는 잘 작동했고, 데이터도 제대로 반환되는 것처럼 보였습니다. 그런데 프론트엔드 팀 이수진 씨에게서 슬랙 메시지가 날아왔습니다.

"김개발 님, API 응답이 문자열로 오는데 JSON으로 바꿔주실 수 있나요? 지금은 파싱이 너무 어려워요." 김개발 씨는 당황했습니다.

분명히 데이터를 반환했는데 뭐가 문제일까요? 선배 개발자 박시니어 씨가 화면을 보더니 한숨을 쉽었습니다.

"아, 출력 형식을 제대로 안 맞췄네요. 이건 기본 중의 기본인데." 구조화된 출력이란 무엇일까요?

쉽게 비유하자면, 구조화된 출력은 마치 택배 상자에 물건을 담는 것과 같습니다. 물건을 그냥 비닐봉지에 아무렇게나 넣으면 배송 중에 망가지거나 분실될 수 있습니다.

하지만 적절한 크기의 상자에 완충재와 함께 정돈해서 담으면 안전하게 배송할 수 있습니다. 데이터도 마찬가지입니다.

프로그래밍에서 데이터를 주고받을 때 가장 중요한 것은 일관성입니다. 데이터를 보내는 쪽과 받는 쪽이 같은 규칙을 따라야 오류 없이 통신할 수 있습니다.

구조화되지 않은 출력의 문제점은 무엇일까요? 첫째, 파싱이 어렵습니다.

단순 문자열로 "User: John, Age: 30"이라고 반환하면 받는 쪽에서 문자열을 직접 잘라내고 분석해야 합니다. 콤마의 위치가 바뀌거나 순서가 달라지면 파싱 로직이 깨집니다.

둘째, 확장성이 없습니다. 나중에 새로운 필드를 추가하려면 문자열 포맷을 바꿔야 하고, 이미 작성된 파싱 코드도 모두 수정해야 합니다.

프로젝트가 커질수록 이런 변경은 악몽이 됩니다. 셋째, 타입 정보가 사라집니다.

숫자 30이 문자열 "30"이 되면서 타입 정보가 손실됩니다. 받는 쪽에서 다시 숫자로 변환해야 하는 번거로움이 생깁니다.

바로 이런 문제를 해결하기 위해 구조화된 출력이 필요합니다. 구조화된 출력을 사용하면 명확한 데이터 구조를 제공할 수 있습니다.

JSON 같은 표준 포맷을 사용하면 키와 값의 관계가 분명해지고, 중첩된 데이터도 표현할 수 있습니다. 또한 타입 정보도 보존됩니다.

숫자는 숫자로, 불린은 불린으로 전달됩니다. 무엇보다 호환성이라는 큰 이점이 있습니다.

JSON은 거의 모든 프로그래밍 언어에서 지원하는 표준 포맷입니다. Python으로 작성한 Lambda 함수의 출력을 JavaScript 프론트엔드에서 그대로 사용할 수 있습니다.

위의 코드를 비교해 보겠습니다. 나쁜 예시에서는 단순히 문자열을 반환합니다.

이 데이터를 받은 프론트엔드는 정규표현식이나 문자열 분리 로직으로 데이터를 추출해야 합니다. 실수하기 쉽고, 유지보수도 어렵습니다.

좋은 예시에서는 statusCode로 HTTP 상태를 명시하고, headers로 컨텐츠 타입을 지정하며, body에 실제 데이터를 구조화해서 담습니다. 이 형식은 API Gateway의 표준 응답 구조입니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 전자상거래 서비스를 개발한다고 가정해봅시다.

주문 정보를 조회하는 Lambda 함수를 작성할 때, 주문번호, 고객정보, 상품목록, 결제금액 등 복잡한 데이터를 반환해야 합니다. 이럴 때 구조화된 JSON 출력을 사용하면 프론트엔드, 모바일 앱, 외부 파트너사 시스템 모두가 같은 API를 문제없이 사용할 수 있습니다.

AWS에서는 Lambda와 API Gateway를 함께 사용할 때 특정 응답 구조를 권장합니다. statusCode, headers, body를 포함하는 딕셔너리 형태입니다.

이 구조를 따르면 API Gateway가 자동으로 HTTP 응답으로 변환해 줍니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 body를 딕셔너리로 그대로 반환하는 것입니다. API Gateway는 body를 문자열로 기대하기 때문에, 딕셔너리를 JSON 문자열로 직렬화해야 합니다.

이 부분을 놓치면 런타임 에러가 발생합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 코드를 수정했습니다. statusCode와 headers를 추가하고, body를 JSON 문자열로 변환했습니다.

다시 배포하고 테스트하니 이수진 씨에게서 엄지척 이모티콘이 날아왔습니다. 구조화된 출력을 제대로 이해하면 API 개발의 기본을 탄탄히 다질 수 있습니다.

여러분도 오늘 배운 내용을 실제 Lambda 프로젝트에 적용해 보세요.

실전 팁

💡 - API Gateway와 Lambda를 함께 사용할 때는 statusCode, headers, body 구조를 반드시 지키세요

body는 JSON 문자열로 직렬화해야 한다는 점을 잊지 마세요

2. JSON 형식 응답 요청

구조화된 출력의 중요성을 깨달은 김개발 씨는 이제 본격적으로 JSON 형식 응답을 작성하기 시작했습니다. 그런데 막상 코드를 작성하려니 궁금한 게 생겼습니다.

"JSON 직렬화는 어떻게 하지? 한글은 깨지지 않을까?"

JSON 형식 응답은 데이터를 JavaScript Object Notation 표준에 맞춰 반환하는 것입니다. Python의 딕셔너리나 리스트를 json.dumps() 함수로 문자열로 변환하면 됩니다.

Lambda에서는 이 JSON 문자열을 body에 담아 반환하고, Content-Type 헤더를 올바르게 설정해야 클라이언트가 JSON으로 인식합니다.

다음 코드를 살펴봅시다.

import json

def lambda_handler(event, context):
    # 반환할 데이터 준비
    data = {
        'orderId': 'ORD-2025-1234',
        'customer': '김철수',
        'items': [
            {'name': '노트북', 'price': 1500000, 'quantity': 1},
            {'name': '마우스', 'price': 30000, 'quantity': 2}
        ],
        'totalAmount': 1560000
    }

    # JSON 문자열로 변환 (한글 깨짐 방지)
    return {
        'statusCode': 200,
        'headers': {
            'Content-Type': 'application/json; charset=utf-8'
        },
        'body': json.dumps(data, ensure_ascii=False)
    }

김개발 씨는 구조화된 출력의 중요성을 깨달았습니다. 이제 실전입니다.

주문 조회 API를 만들어야 하는데, 주문 정보를 JSON으로 반환해야 합니다. 코드 에디터를 열고 손을 올렸지만, 문득 의문이 들었습니다.

"Python 딕셔너리를 그냥 반환하면 되나? 아니면 뭔가 더 해야 하나?" 옆자리 박시니어 씨가 웃으며 말했습니다.

"딕셔너리를 JSON 문자열로 바꿔야죠. json 모듈을 import 했나요?" JSON 형식 응답을 제대로 만들려면 몇 가지 단계를 거쳐야 합니다.

비유하자면, JSON 변환은 마치 편지를 봉투에 넣는 것과 같습니다. 편지 내용(데이터)을 작성했다면, 이제 봉투(JSON 문자열)에 넣고 우표(헤더)를 붙여야 상대방에게 제대로 전달됩니다.

편지를 그냥 던져주면 분실되거나 내용이 훼손될 수 있습니다. Python에서 JSON으로 변환하는 것을 **직렬화(serialization)**라고 부릅니다.

메모리에 있는 객체를 네트워크로 전송할 수 있는 문자열 형태로 바꾸는 과정입니다. 반대로 JSON 문자열을 다시 객체로 바꾸는 것은 **역직렬화(deserialization)**라고 합니다.

JSON 직렬화 없이 딕셔너리를 그대로 반환하면 어떻게 될까요? Lambda는 반환값을 자동으로 JSON으로 바꿔주지 않습니다.

API Gateway는 body가 문자열이기를 기대합니다. 딕셔너리를 그대로 넣으면 타입 에러가 발생하거나, 최악의 경우 클라이언트가 예상치 못한 데이터를 받게 됩니다.

또 다른 문제는 한글 깨짐입니다. Python의 기본 JSON 인코더는 ASCII 문자만 사용하려고 합니다.

한글 같은 유니코드 문자는 이스케이프 시퀀스(\uXXXX)로 변환됩니다. 클라이언트에서는 읽을 수 있지만, 로그를 볼 때나 디버깅할 때 사람이 읽기 어렵습니다.

바로 이런 문제를 해결하기 위해 json.dumps() 함수를 사용합니다. json.dumps() 함수는 Python 객체를 JSON 문자열로 변환합니다.

ensure_ascii=False 옵션을 주면 한글을 그대로 유지합니다. 이렇게 하면 로그에서도 한글이 깨지지 않고 보입니다.

또한 Content-Type 헤더를 올바르게 설정해야 합니다. 'application/json'으로 지정하면 클라이언트는 이 응답이 JSON임을 알고 자동으로 파싱합니다.

'charset=utf-8'을 추가하면 한글 같은 유니코드 문자를 제대로 처리합니다. 위의 코드를 단계별로 분석해 보겠습니다.

먼저 import json으로 JSON 모듈을 불러옵니다. Python 표준 라이브러리에 포함되어 있으므로 별도 설치가 필요 없습니다.

다음으로 data 딕셔너리를 준비합니다. 주문 ID, 고객명, 상품 목록, 총액을 담았습니다.

items는 리스트 안에 딕셔너리가 있는 중첩 구조입니다. JSON은 이런 중첩 구조를 완벽히 지원합니다.

json.dumps(data, ensure_ascii=False)로 딕셔너리를 JSON 문자열로 변환합니다. ensure_ascii=False 덕분에 '김철수', '노트북' 같은 한글이 그대로 유지됩니다.

마지막으로 statusCode 200, 적절한 headers, 그리고 JSON 문자열이 담긴 body를 반환합니다. 이 형식은 API Gateway가 기대하는 정확한 구조입니다.

실제 현업에서는 어떻게 활용할까요? 대부분의 REST API는 JSON으로 통신합니다.

사용자 정보 조회, 주문 생성, 상품 검색 등 거의 모든 API 응답이 JSON 형식입니다. Lambda를 사용하면 서버리스 환경에서 간단히 JSON API를 만들 수 있습니다.

특히 마이크로서비스 아키텍처에서는 서비스 간 통신도 JSON을 많이 사용합니다. 주문 서비스가 재고 서비스를 호출할 때, Lambda 함수끼리 이벤트를 주고받을 때 모두 JSON이 표준입니다.

프론트엔드 개발자들은 fetch나 axios로 API를 호출하고, 자동으로 JSON을 파싱해서 JavaScript 객체로 사용합니다. Content-Type이 정확히 설정되어 있으면 자동 파싱이 완벽하게 작동합니다.

하지만 주의할 점이 있습니다. datetime 객체는 JSON으로 직렬화할 수 없습니다.

Python의 datetime은 JSON 표준에 없는 타입이기 때문입니다. 날짜를 반환해야 한다면 문자열로 변환하거나, 커스텀 JSON 인코더를 작성해야 합니다.

보통은 ISO 8601 형식 문자열('2025-01-15T10:30:00')로 변환합니다. 또 다른 실수는 순환 참조입니다.

객체 A가 객체 B를 참조하고, B가 다시 A를 참조하면 json.dumps()는 에러를 발생시킵니다. 데이터 구조를 설계할 때 순환 참조가 없도록 주의해야 합니다.

김개발 씨는 코드를 완성하고 테스트했습니다. curl로 API를 호출하니 깔끔한 JSON이 반환되었습니다.

한글도 깨지지 않았습니다. 프론트엔드 팀에서도 만족스럽다는 피드백이 왔습니다.

JSON 형식 응답을 제대로 이해하면 API 개발이 훨씬 수월해집니다. 여러분도 json.dumps()와 적절한 헤더 설정을 꼭 기억하세요.

실전 팁

💡 - datetime 같은 특수 타입은 문자열로 변환한 후 JSON 직렬화하세요

ensure_ascii=False를 사용하면 한글이 읽기 쉬운 형태로 유지됩니다
API Gateway 통합 시 body는 반드시 문자열이어야 합니다

3. 마크다운 형식 활용

JSON으로 데이터를 주고받는 것에 익숙해진 김개발 씨는 새로운 요구사항을 받았습니다. "AI 모델의 응답을 사용자에게 보여줄 때 마크다운 형식으로 반환해주세요." 마크다운이라니, 그게 뭔가요?

마크다운 형식은 텍스트에 간단한 서식을 추가하는 경량 마크업 언어입니다. #으로 제목을, **로 굵은 글씨를, -로 목록을 표현합니다.

Lambda 함수가 AI 모델 응답이나 문서를 반환할 때 마크다운을 사용하면 프론트엔드에서 마크다운 렌더러로 깔끔하게 표시할 수 있습니다.

다음 코드를 살펴봅시다.

import json

def lambda_handler(event, context):
    # AI 모델 응답을 마크다운으로 구성
    markdown_content = """# AWS Lambda 소개

**AWS Lambda**는 서버를 관리하지 않고도 코드를 실행할 수 있는 서비스입니다.

## 주요 특징
- 서버리스 아키텍처 지원
- 자동 스케일링
- 사용한 만큼만 과금

### 코드 예시
def hello():
    return "Hello, Lambda!"

자세한 내용은 [AWS 공식 문서](https://aws.amazon.com/lambda)를 참고하세요.
"""

    return {
        'statusCode': 200,
        'headers': {'Content-Type': 'text/markdown; charset=utf-8'},
        'body': json.dumps({'content': markdown_content}, ensure_ascii=False)
    }

김개발 씨는 이제 JSON 응답을 능숙하게 다룰 수 있게 되었습니다. 그런데 새로운 프로젝트가 시작되었습니다.

회사에서 AI 챗봇 서비스를 런칭하기로 했고, Lambda 함수가 AI 모델의 응답을 프론트엔드에 전달하는 역할을 맡았습니다. PM인 최기획 씨가 요구사항을 설명했습니다.

"AI 응답에 제목, 목록, 코드 블록 같은 서식이 필요해요. 마크다운 형식으로 반환해 주시면 프론트엔드에서 예쁘게 렌더링할게요." 김개발 씨는 고개를 갸우뚱했습니다.

"마크다운이요? README 파일에서 본 것 같은데, 정확히 뭔가요?" **마크다운(Markdown)**이란 무엇일까요?

마크다운은 마치 문서 작성의 속기법과 같습니다. HTML처럼 복잡한 태그를 쓰지 않고도, 간단한 기호로 제목, 강조, 목록, 링크 등을 표현할 수 있습니다.

예를 들어 # 하나면 큰 제목, **로 감싸면 굵은 글씨가 됩니다. 배우기 쉽고, 작성하기 편하며, 읽기도 쉽습니다.

GitHub의 README 파일, 기술 블로그, 문서화 도구에서 마크다운을 광범위하게 사용합니다. 최근에는 AI 챗봇 응답에도 마크다운이 많이 쓰입니다.

ChatGPT나 Claude 같은 AI가 응답할 때 마크다운으로 서식을 표현합니다. 마크다운 없이 평범한 텍스트만 반환하면 어떻게 될까요?

제목과 본문의 구분이 없어 가독성이 떨어집니다. 중요한 단어를 강조할 수도 없고, 코드를 표시할 방법도 없습니다.

모든 텍스트가 똑같은 스타일로 보이면 사용자는 어디가 중요한지 파악하기 어렵습니다. 프론트엔드에서 HTML을 직접 생성할 수도 있지만, 이건 백엔드와 프론트엔드의 책임이 섞이는 것입니다.

백엔드는 데이터와 간단한 서식 정보를 제공하고, 프론트엔드가 실제 렌더링을 담당하는 게 깔끔합니다. 바로 이런 이유로 마크다운 형식이 중간 포맷으로 적합합니다.

마크다운을 사용하면 간결한 문법으로 서식을 표현할 수 있습니다. # 하나로 h1 제목, ## 두 개로 h2 제목을 만듭니다.

텍스트는 굵게, 텍스트는 기울임꼴이 됩니다. - 기호로 목록을 만들고, 숫자로 순서 있는 목록을 만듭니다.

또한 코드 표현이 편리합니다. 백틱 세 개(```)로 코드 블록을 만들고, 언어를 지정하면 문법 하이라이팅도 지원합니다.

인라인 코드는 백틱 하나로 감쌉니다. 무엇보다 크로스 플랫폼 호환성이 뛰어납니다.

웹, 모바일, 데스크톱 모두 마크다운 렌더러 라이브러리가 있습니다. React에서는 react-markdown, Vue에서는 vue-markdown 같은 라이브러리로 쉽게 렌더링합니다.

위의 코드를 살펴보겠습니다. 먼저 markdown_content 변수에 마크다운 문자열을 작성합니다.

파이썬의 트리플 쿼트(""")를 사용하면 여러 줄 문자열을 편하게 작성할 수 있습니다. # 하나는 h1 제목입니다.

"AWS Lambda 소개"가 큰 제목으로 표시됩니다. AWS Lambda처럼 별표 두 개로 감싸면 굵은 글씨가 됩니다.

두 개는 h2 제목입니다. "주요 특징"이 중간 크기 제목이 됩니다.

기호로 시작하는 줄은 목록 항목이 됩니다. ### 세 개는 h3 제목입니다.

백틱 세 개와 python을 써서 코드 블록을 만들고, 다시 백틱 세 개로 닫습니다. 텍스트 형식으로 하이퍼링크를 만듭니다.

Content-Type을 'text/markdown'으로 설정하면 클라이언트가 이 응답이 마크다운임을 알 수 있습니다. 하지만 실제로는 JSON body 안에 content 키로 마크다운 문자열을 담는 경우가 많습니다.

이렇게 하면 추가 메타데이터(작성자, 작성일 등)도 함께 보낼 수 있습니다. 실무에서는 어떻게 활용할까요?

AI 챗봇 서비스에서 Lambda 함수가 OpenAI API를 호출하고, 응답을 마크다운 형식으로 정리해서 반환합니다. 프론트엔드는 react-markdown 같은 라이브러리로 예쁘게 렌더링합니다.

사용자는 제목, 목록, 코드가 잘 구분된 답변을 받게 됩니다. 기술 문서 서비스에서도 마크다운을 많이 씁니다.

Lambda 함수가 S3에 저장된 마크다운 문서를 읽어 반환하면, 프론트엔드가 렌더링합니다. 문서 작성자는 복잡한 HTML 대신 간단한 마크다운으로 작성할 수 있습니다.

코드 리뷰 봇, 이슈 트래커, 위키 시스템 등 협업 도구에서도 마크다운이 표준입니다. GitHub, Notion, Slack 모두 마크다운을 지원합니다.

주의할 점도 있습니다. **마크다운 방언(flavor)**이 여러 가지입니다.

CommonMark가 표준이지만, GitHub Flavored Markdown(GFM), Markdown Extra 등 확장 버전이 있습니다. 테이블, 체크박스, 이모지 등 추가 기능을 지원합니다.

사용할 렌더러가 어떤 방언을 지원하는지 확인해야 합니다. 또 다른 함정은 XSS 취약점입니다.

사용자 입력을 마크다운으로 렌더링할 때, 악의적인 사용자가 <script> 태그를 삽입할 수 있습니다. 안전한 마크다운 렌더러는 HTML 태그를 이스케이프하거나 화이트리스트 방식으로 필터링합니다.

react-markdown은 기본적으로 안전하지만, 옵션을 잘못 설정하면 위험합니다. 김개발 씨는 마크다운 형식으로 응답을 작성했습니다.

프론트엔드 팀에서 react-markdown으로 렌더링했더니 깔끔하게 표시되었습니다. 최기획 PM이 흡족한 표정으로 엄지를 들어 올렸습니다.

마크다운 형식을 활용하면 AI 응답이나 문서를 우아하게 표현할 수 있습니다. 여러분도 Lambda 함수에서 마크다운을 적극 활용해 보세요.

실전 팁

💡 - 프론트엔드와 어떤 마크다운 방언을 사용할지 미리 합의하세요

사용자 입력을 렌더링할 때는 XSS 공격에 주의하세요
코드 블록에 언어를 지정하면 문법 하이라이팅을 지원합니다

4. 테이블 형식 출력

마크다운까지 마스터한 김개발 씨에게 또 다른 요구사항이 들어왔습니다. "사용자별 월간 사용량 리포트를 표 형태로 보여주면 좋겠어요." 표라니, JSON으로는 어떻게 표현하죠?

테이블 형식 출력은 데이터를 행과 열로 구조화해서 보기 쉽게 만드는 것입니다. JSON으로는 리스트와 딕셔너리의 조합으로, 마크다운으로는 파이프(|) 기호로 테이블을 만듭니다.

Lambda 함수가 데이터를 테이블 구조로 반환하면 프론트엔드에서 표나 그리드로 쉽게 표시할 수 있습니다.

다음 코드를 살펴봅시다.

import json

def lambda_handler(event, context):
    # 사용량 데이터 (테이블 형태)
    usage_data = [
        {'user': '김철수', 'plan': 'Pro', 'requests': 15000, 'cost': 45000},
        {'user': '이영희', 'plan': 'Basic', 'requests': 5000, 'cost': 10000},
        {'user': '박민수', 'plan': 'Enterprise', 'requests': 50000, 'cost': 120000}
    ]

    # 마크다운 테이블 형식으로 변환
    markdown_table = """| 사용자 | 요금제 | 요청 수 | 비용 (원) |
|--------|--------|---------|-----------|
| 김철수 | Pro | 15,000 | 45,000 |
| 이영희 | Basic | 5,000 | 10,000 |
| 박민수 | Enterprise | 50,000 | 120,000 |
"""

    return {
        'statusCode': 200,
        'headers': {'Content-Type': 'application/json; charset=utf-8'},
        'body': json.dumps({
            'data': usage_data,  # JSON 형식
            'markdown': markdown_table  # 마크다운 형식
        }, ensure_ascii=False)
    }

김개발 씨는 이제 JSON과 마크다운에 자신감이 붙었습니다. 그런데 영업팀에서 새로운 요청이 들어왔습니다.

월간 리포트 기능을 추가해 달라는 것입니다. 각 사용자의 요금제, 요청 수, 비용을 한눈에 볼 수 있는 표가 필요하다고 합니다.

김개발 씨는 생각했습니다. "표를 어떻게 만들지?

JSON은 계층 구조인데, 표는 2차원 구조잖아?" 선배 박시니어 씨가 말했습니다. "테이블은 결국 행의 집합이에요.

각 행을 딕셔너리로, 전체를 리스트로 만들면 됩니다. 마크다운으로도 표를 만들 수 있고요." 테이블 형식 출력이란 무엇일까요?

테이블은 마치 엑셀 스프레드시트와 같습니다. 가로줄(행)과 세로줄(열)이 교차하면서 데이터를 격자 형태로 배치합니다.

첫 번째 행은 보통 헤더(컬럼명)이고, 나머지는 데이터 행입니다. 이런 구조는 사람이 데이터를 비교하고 분석하기에 최적입니다.

프로그래밍에서 테이블 데이터를 표현하는 방법은 여러 가지입니다. 데이터베이스는 실제로 행과 열로 데이터를 저장합니다.

CSV 파일도 테이블 형식입니다. JSON에서는 객체의 배열로 테이블을 표현합니다.

테이블 형식 없이 데이터를 나열하면 어떻게 될까요? 사용자별 데이터를 단순히 텍스트로 나열하면 비교가 어렵습니다.

"김철수는 Pro 요금제에 15000건 요청, 이영희는 Basic 요금제에 5000건 요청..." 이렇게 나열하면 누가 가장 많이 사용했는지, 어떤 요금제가 인기 있는지 한눈에 보이지 않습니다. 반면 테이블로 표시하면 같은 컬럼끼리 세로로 정렬되어 비교가 쉽습니다.

숫자 컬럼은 오른쪽 정렬해서 자릿수를 맞추면 더 보기 좋습니다. 바로 이런 이유로 테이블 형식이 리포트나 대시보드에서 필수입니다.

테이블 데이터를 JSON으로 표현하는 가장 일반적인 방법은 객체의 배열입니다. 각 객체가 한 행을 나타내고, 객체의 키가 컬럼명이 됩니다.

이 형식은 직관적이고, 프론트엔드에서 반복문으로 쉽게 렌더링할 수 있습니다. 마크다운으로도 테이블을 만들 수 있습니다.

파이프(|) 기호로 열을 구분하고, 대시(-)로 헤더와 데이터를 구분합니다. GitHub Flavored Markdown에서 지원하는 기능입니다.

두 가지 형식을 함께 반환하면 유연성이 높아집니다. 프론트엔드가 HTML 테이블을 직접 렌더링하고 싶으면 JSON 데이터를 쓰고, 마크다운 렌더러를 쓰고 싶으면 마크다운 문자열을 쓰면 됩니다.

위의 코드를 분석해 보겠습니다. usage_data는 리스트 안에 딕셔너리가 담긴 구조입니다.

각 딕셔너리는 한 사용자의 데이터를 나타냅니다. 'user', 'plan', 'requests', 'cost' 키가 컬럼명 역할을 합니다.

이 데이터를 프론트엔드에서 받으면 React나 Vue의 반복문으로 쉽게 테이블을 그릴 수 있습니다. 예를 들어 React에서는 usage_data.map()으로 각 행을 <tr>로 렌더링합니다.

markdown_table은 마크다운 테이블 문법을 사용한 문자열입니다. 첫 번째 줄은 헤더입니다.

두 번째 줄의 대시는 헤더와 데이터를 구분합니다. 세 번째 줄부터는 실제 데이터입니다.

마크다운 렌더러가 이 문자열을 받으면 자동으로 HTML <table> 태그로 변환합니다. 개발자가 직접 테이블 HTML을 작성할 필요가 없습니다.

두 형식을 모두 body에 담아 반환합니다. 프론트엔드는 필요에 따라 data를 쓸지 markdown을 쓸지 선택할 수 있습니다.

실무에서는 어떻게 활용할까요? 관리자 대시보드에서 사용량 리포트, 매출 통계, 사용자 목록 등을 테이블로 표시합니다.

Lambda 함수가 데이터베이스를 조회해서 테이블 형식 JSON으로 반환하면, 프론트엔드는 ag-Grid나 React Table 같은 라이브러리로 고급 테이블을 만듭니다. 데이터 분석 도구에서도 테이블이 핵심입니다.

Jupyter Notebook은 pandas DataFrame을 테이블로 표시합니다. Lambda 함수가 데이터를 가공해서 테이블 형식으로 반환하면 데이터 과학자가 바로 분석할 수 있습니다.

이메일 리포트를 보낼 때도 테이블이 유용합니다. Lambda 함수가 월간 리포트를 마크다운 테이블로 작성하고, SES로 HTML 이메일을 전송합니다.

수신자는 이메일에서 바로 표를 볼 수 있습니다. 주의할 점이 있습니다.

컬럼 순서가 중요합니다. JSON 객체는 사실 순서를 보장하지 않지만, Python 3.7 이상에서는 딕셔너리가 삽입 순서를 유지합니다.

프론트엔드에서 컬럼 순서를 명시적으로 지정하거나, 백엔드에서 컬럼 메타데이터를 함께 전송하는 것이 안전합니다. 대용량 데이터를 한 번에 반환하면 성능 문제가 생깁니다.

수만 개 행을 JSON으로 직렬화하면 시간이 오래 걸리고, 네트워크 전송도 느려집니다. 페이지네이션(pagination)을 구현해서 한 번에 일부만 반환하는 것이 좋습니다.

마크다운 테이블은 복잡한 셀 병합을 지원하지 않습니다. 엑셀처럼 여러 셀을 합치거나 중첩 테이블을 만들 수 없습니다.

복잡한 레이아웃이 필요하면 HTML 테이블을 직접 생성하거나, 프론트엔드에서 커스텀 렌더링해야 합니다. 김개발 씨는 두 가지 형식으로 테이블 데이터를 반환하는 코드를 완성했습니다.

영업팀에서 리포트를 보더니 "딱 이거예요!"라며 기뻐했습니다. 이제 매달 자동으로 사용량 리포트가 생성됩니다.

테이블 형식 출력을 잘 활용하면 데이터를 직관적으로 전달할 수 있습니다. 여러분도 리포트 기능을 만들 때 테이블 형식을 적극 사용해 보세요.

실전 팁

💡 - JSON 테이블은 객체의 배열 형태로 표현하세요

대용량 데이터는 페이지네이션을 구현해서 부분적으로 반환하세요
마크다운 테이블은 간단한 표에만 사용하고, 복잡한 레이아웃은 HTML이나 프론트엔드 렌더링을 고려하세요

5. 출력 검증하기

김개발 씨는 여러 형식으로 데이터를 반환하는 데 익숙해졌습니다. 그런데 어느 날 버그 리포트가 들어왔습니다.

"API 응답이 가끔 이상해요. 데이터가 누락되거나 타입이 틀릴 때가 있어요." 출력을 제대로 검증하지 않았던 것입니다.

출력 검증은 Lambda 함수가 반환하는 데이터가 기대한 구조와 타입을 만족하는지 확인하는 과정입니다. JSON 스키마 검증, 타입 체크, 필수 필드 확인 등을 통해 잘못된 데이터가 클라이언트에 전달되는 것을 방지합니다.

Pydantic 같은 라이브러리를 사용하면 쉽게 검증할 수 있습니다.

다음 코드를 살펴봅시다.

import json
from typing import List, Optional
from pydantic import BaseModel, Field, ValidationError

# 응답 모델 정의
class UserUsage(BaseModel):
    user: str = Field(..., min_length=1, max_length=50)
    plan: str = Field(..., pattern='^(Basic|Pro|Enterprise)$')
    requests: int = Field(..., ge=0)  # 0 이상
    cost: int = Field(..., ge=0)

class UsageReport(BaseModel):
    data: List[UserUsage]
    total_requests: int = Field(..., ge=0)
    total_cost: int = Field(..., ge=0)

def lambda_handler(event, context):
    try:
        # 데이터 준비 (DB 조회 등)
        raw_data = [
            {'user': '김철수', 'plan': 'Pro', 'requests': 15000, 'cost': 45000},
            {'user': '이영희', 'plan': 'Basic', 'requests': 5000, 'cost': 10000}
        ]

        # 검증하면서 객체 생성
        report = UsageReport(
            data=[UserUsage(**item) for item in raw_data],
            total_requests=sum(item['requests'] for item in raw_data),
            total_cost=sum(item['cost'] for item in raw_data)
        )

        # 검증된 데이터를 JSON으로 변환
        return {
            'statusCode': 200,
            'headers': {'Content-Type': 'application/json; charset=utf-8'},
            'body': json.dumps(report.dict(), ensure_ascii=False)
        }
    except ValidationError as e:
        # 검증 실패 시 에러 응답
        return {
            'statusCode': 400,
            'body': json.dumps({'error': 'Invalid data', 'details': e.errors()})
        }

김개발 씨는 이제 다양한 출력 형식을 능숙하게 다룰 수 있게 되었습니다. JSON, 마크다운, 테이블까지 모두 마스터했습니다.

코드가 잘 작동하는 것처럼 보였습니다. 배포도 순조로웠습니다.

그런데 며칠 후, 프론트엔드 팀의 이수진 씨에게서 급한 슬랙 메시지가 왔습니다. "김개발 님, API 응답이 가끔 이상해요.

user 필드가 없을 때도 있고, requests가 문자열로 올 때도 있어요. 프론트엔드가 계속 터져요!" 김개발 씨는 당황했습니다.

분명히 잘 작동했는데, 무엇이 문제일까요? 로그를 확인해 보니 데이터베이스에서 가져온 데이터가 예상과 달랐습니다.

어떤 사용자는 이름이 null이고, 어떤 레코드는 숫자가 문자열로 저장되어 있었습니다. 박시니어 씨가 코드를 보더니 한숨을 쉬었습니다.

"출력 검증을 안 했네요. 데이터를 그대로 반환하면 안 됩니다.

반드시 검증해야 해요." 출력 검증이란 무엇일까요? 출력 검증은 마치 공장의 품질 검사와 같습니다.

제품을 만들고 나서 바로 출하하지 않습니다. 검사 과정을 거쳐 규격에 맞는지, 불량은 없는지 확인합니다.

불량품은 걸러내고, 합격한 제품만 고객에게 보냅니다. 데이터도 마찬가지입니다.

Lambda 함수가 데이터베이스, 외부 API, 파일 등에서 데이터를 가져올 때, 그 데이터가 항상 올바르다고 보장할 수 없습니다. 데이터베이스 스키마가 바뀌었을 수도 있고, 마이그레이션 중에 잘못된 데이터가 들어갔을 수도 있습니다.

외부 API는 문서와 다르게 동작할 수도 있습니다. 출력 검증 없이 데이터를 그대로 반환하면 어떻게 될까요?

첫째, 클라이언트가 오류를 만납니다. 프론트엔드는 user 필드가 항상 있다고 가정하고 코드를 작성했는데, user가 없으면 JavaScript 에러가 발생합니다.

사용자는 빈 화면이나 에러 메시지를 보게 됩니다. 둘째, 디버깅이 어려워집니다.

문제가 백엔드에서 발생했는지 프론트엔드에서 발생했는지 불명확합니다. 프론트엔드 개발자는 백엔드를 의심하고, 백엔드 개발자는 프론트엔드를 의심합니다.

시간이 낭비됩니다. 셋째, 보안 문제가 생길 수 있습니다.

검증하지 않은 데이터에 악의적인 내용이 포함될 수 있습니다. SQL 인젝션, XSS 공격에 활용될 수 있습니다.

바로 이런 문제를 해결하기 위해 출력 검증이 필수입니다. 출력 검증을 하면 조기 에러 감지가 가능합니다.

데이터가 잘못되었을 때 클라이언트에 도달하기 전에 Lambda 함수에서 에러를 발생시킵니다. 로그를 보면 어떤 필드가 문제인지 명확히 알 수 있습니다.

또한 타입 안전성을 보장합니다. requests는 반드시 정수여야 하고, 음수일 수 없습니다.

plan은 'Basic', 'Pro', 'Enterprise' 중 하나여야 합니다. 이런 규칙을 코드로 명시하면 실수를 방지할 수 있습니다.

무엇보다 **계약(contract)**을 명확히 합니다. API 문서에 "user는 필수 문자열, requests는 0 이상의 정수"라고 쓰는 것보다, 코드로 검증하는 것이 확실합니다.

문서는 오래되지만, 코드는 항상 최신입니다. 위의 코드를 살펴보겠습니다.

Pydantic의 BaseModel을 사용해서 데이터 모델을 정의합니다. UserUsage는 한 사용자의 데이터 구조를 나타냅니다.

user는 1~50자 문자열, plan은 정규표현식으로 세 가지 값만 허용, requests와 cost는 0 이상의 정수입니다. UsageReport는 전체 리포트 구조입니다.

data는 UserUsage의 리스트입니다. total_requests와 total_cost도 0 이상의 정수입니다.

lambda_handler에서 raw_data를 가져온 후, UserUsage 객체로 변환합니다. 이 과정에서 Pydantic이 자동으로 검증합니다.

타입이 틀리거나 범위를 벗어나면 ValidationError가 발생합니다. 검증을 통과하면 report 객체가 생성됩니다.

report.dict()로 딕셔너리로 변환하고, json.dumps()로 JSON 문자열로 변환해서 반환합니다. 검증 실패 시 except 블록이 실행됩니다.

statusCode 400과 함께 에러 상세 정보를 반환합니다. 클라이언트는 어떤 필드가 잘못되었는지 알 수 있습니다.

실무에서는 어떻게 활용할까요? 대부분의 프로덕션 API는 출력 검증을 합니다.

FastAPI 같은 프레임워크는 Pydantic을 기본으로 사용합니다. API를 정의할 때 응답 모델을 지정하면 자동으로 검증됩니다.

마이크로서비스 아키텍처에서는 서비스 간 계약이 중요합니다. 각 서비스가 반환하는 데이터 구조를 명확히 정의하고 검증하면, 한 서비스의 변경이 다른 서비스를 망가뜨리지 않습니다.

CI/CD 파이프라인에서도 검증이 유용합니다. 유닛 테스트에서 응답 모델을 검증하면, 코드 변경이 API 계약을 깨뜨리는지 자동으로 확인할 수 있습니다.

주의할 점이 있습니다. 검증은 비용입니다.

Pydantic은 빠르지만, 수만 개 객체를 검증하면 시간이 걸립니다. 성능이 중요한 경우 선택적으로 검증하거나, 스키마가 확실한 내부 데이터는 검증을 건너뛸 수 있습니다.

에러 메시지가 너무 상세하면 보안 문제가 될 수 있습니다. 내부 데이터베이스 구조나 민감한 정보가 에러 메시지에 노출되지 않도록 주의해야 합니다.

개발 환경에서는 상세히, 프로덕션에서는 간략히 반환하는 것이 좋습니다. 김개발 씨는 Pydantic을 사용해서 출력 검증을 추가했습니다.

배포 후 며칠간 지켜보니 더 이상 이상한 응답이 발생하지 않았습니다. 이수진 씨에게서 감사 메시지가 왔습니다.

"이제 API가 믿을 만해요!" 출력 검증을 제대로 하면 API의 신뢰성이 크게 향상됩니다. 여러분도 Pydantic이나 유사한 도구로 검증을 꼭 추가하세요.

실전 팁

💡 - Pydantic의 Field로 타입, 범위, 패턴 등을 상세히 지정하세요

검증 에러는 로그에 남기고, 클라이언트에는 간략히 전달하세요
성능이 중요한 경우 검증 범위를 조정하세요

6. 파싱 에러 처리

출력 검증까지 완벽하게 마친 김개발 씨는 안심하고 있었습니다. 그런데 모니터링 알람이 울렸습니다.

"JSON 파싱 에러가 발생했습니다." 클라이언트가 Lambda 응답을 파싱하다가 에러를 만난 것입니다. 대체 무엇이 문제일까요?

파싱 에러는 클라이언트가 Lambda 응답을 해석할 때 발생하는 오류입니다. JSON 문법 오류, 인코딩 문제, 예상치 못한 데이터 타입 등이 원인입니다.

이를 방지하려면 JSON 직렬화 시 예외 처리를 철저히 하고, 인코딩을 명시하며, 클라이언트가 에러 응답도 파싱할 수 있도록 일관된 구조를 유지해야 합니다.

다음 코드를 살펴봅시다.

import json
import decimal
from datetime import datetime, date

# JSON 직렬화 불가능한 타입을 처리하는 커스텀 인코더
class CustomJSONEncoder(json.JSONEncoder):
    def default(self, obj):
        # Decimal 타입 (DynamoDB에서 자주 사용)
        if isinstance(obj, decimal.Decimal):
            return float(obj)
        # datetime, date 타입
        if isinstance(obj, (datetime, date)):
            return obj.isoformat()
        # 기타 처리 불가능한 타입
        return super().default(obj)

def safe_json_dumps(data):
    """안전한 JSON 직렬화"""
    try:
        return json.dumps(data, cls=CustomJSONEncoder, ensure_ascii=False)
    except (TypeError, ValueError) as e:
        # 직렬화 실패 시 에러 정보 반환
        return json.dumps({
            'error': 'Serialization failed',
            'message': str(e)
        })

def lambda_handler(event, context):
    try:
        # DynamoDB에서 가져온 데이터 (Decimal 포함)
        data = {
            'orderId': 'ORD-2025-1234',
            'amount': decimal.Decimal('1560000.50'),
            'createdAt': datetime.now(),
            'dueDate': date.today()
        }

        return {
            'statusCode': 200,
            'headers': {
                'Content-Type': 'application/json; charset=utf-8'
            },
            'body': safe_json_dumps({'data': data, 'success': True})
        }
    except Exception as e:
        # 예상치 못한 에러 처리
        return {
            'statusCode': 500,
            'headers': {
                'Content-Type': 'application/json; charset=utf-8'
            },
            'body': json.dumps({
                'error': 'Internal server error',
                'success': False
            })
        }

김개발 씨는 출력 검증까지 완벽하게 구현했습니다. 이제 API는 탄탄해 보였습니다.

모든 테스트를 통과했고, 프론트엔드 팀도 만족했습니다. 배포하고 퇴근 준비를 하던 중, 갑자기 슬랙에 알람이 울렸습니다.

"Production 환경에서 에러 발생! JSONDecodeError: Expecting value" 김개발 씨는 황급히 로그를 확인했습니다.

Lambda 함수는 정상 실행되었는데, 클라이언트가 응답을 파싱하다가 에러를 만났습니다. 대체 무엇이 문제일까요?

박시니어 씨가 로그를 보더니 원인을 찾았습니다. "DynamoDB 데이터를 그대로 직렬화하려고 했네요.

Decimal 타입은 JSON으로 바로 변환 안 됩니다." 파싱 에러란 무엇일까요? 파싱 에러는 마치 외국어 번역 실패와 같습니다.

한국어를 영어로 번역할 때, 번역기가 이해하지 못하는 단어나 문법이 나오면 번역이 멈춥니다. JSON도 마찬가지입니다.

Python 객체를 JSON 문자열로 변환할 때, JSON이 이해하지 못하는 타입이 있으면 직렬화가 실패합니다. JSON 표준은 아주 제한적인 타입만 지원합니다.

문자열, 숫자, 불린, null, 배열, 객체뿐입니다. Python의 datetime, Decimal, set, bytes 같은 타입은 JSON 표준에 없습니다.

이런 타입을 json.dumps()로 변환하려고 하면 TypeError가 발생합니다. 파싱 에러를 무시하면 어떻게 될까요?

첫째, 클라이언트가 망가집니다. JavaScript fetch가 response.json()을 호출할 때 JSON 파싱 에러가 발생하면 catch 블록으로 빠집니다.

사용자는 "네트워크 오류" 같은 불친절한 메시지를 보게 됩니다. 둘째, 디버깅이 매우 어렵습니다.

Lambda 함수는 성공(statusCode 200)했는데 클라이언트는 에러를 받았습니다. 로그를 보면 Lambda는 정상이고, 클라이언트는 파싱 실패입니다.

어디가 문제인지 찾기 어렵습니다. 셋째, 간헐적 에러가 발생합니다.

어떤 데이터는 잘 직렬화되고, 어떤 데이터는 실패합니다. 테스트에서는 잘 작동했는데 프로덕션에서만 에러가 나는 최악의 상황입니다.

바로 이런 문제를 해결하기 위해 파싱 에러 처리가 필수입니다. 파싱 에러를 방지하려면 커스텀 JSON 인코더를 사용합니다.

json.JSONEncoder를 상속받아 default() 메서드를 오버라이드합니다. 이 메서드는 기본 인코더가 처리하지 못하는 타입을 받아 JSON 호환 타입으로 변환합니다.

예를 들어 Decimal은 float으로 변환합니다. DynamoDB는 숫자를 Decimal 타입으로 반환하는데, 이것을 그대로 직렬화하면 에러입니다.

float으로 변환하면 해결됩니다. 정밀도가 중요하다면 문자열로 변환할 수도 있습니다.

datetime과 date는 ISO 8601 형식 문자열로 변환합니다. isoformat() 메서드를 호출하면 '2025-01-15T10:30:00' 같은 표준 형식이 됩니다.

이 형식은 JavaScript의 new Date()가 이해할 수 있습니다. 또한 safe_json_dumps() 같은 래퍼 함수를 만들면 예외 처리를 한 곳에 모을 수 있습니다.

직렬화가 실패하면 에러 정보를 담은 JSON을 반환합니다. 최소한 클라이언트가 파싱은 할 수 있게 합니다.

위의 코드를 분석해 보겠습니다. CustomJSONEncoder 클래스는 json.JSONEncoder를 상속받습니다.

default() 메서드에서 특수 타입을 처리합니다. isinstance()로 객체의 타입을 확인합니다.

Decimal이면 float()으로 변환합니다. datetime이나 date면 isoformat()으로 문자열로 변환합니다.

처리할 수 없는 타입이면 super().default(obj)를 호출해서 기본 에러를 발생시킵니다. 이렇게 하면 에러 메시지에 어떤 타입이 문제인지 나옵니다.

safe_json_dumps() 함수는 json.dumps()를 try-except로 감쌉니다. cls=CustomJSONEncoder로 커스텀 인코더를 지정합니다.

직렬화가 실패하면 에러 정보를 담은 JSON을 반환합니다. 최소한 JSON 문법은 올바르므로 클라이언트가 파싱할 수 있습니다.

lambda_handler에서 DynamoDB 데이터를 가져왔다고 가정합니다. amount는 Decimal, createdAt은 datetime, dueDate는 date 타입입니다.

safe_json_dumps()를 사용하면 모두 안전하게 변환됩니다. 최상위 try-except로 예상치 못한 에러도 잡습니다.

어떤 에러가 발생하더라도 statusCode 500과 함께 JSON 형식 에러 응답을 반환합니다. 클라이언트는 항상 JSON을 기대할 수 있습니다.

실무에서는 어떻게 활용할까요? AWS Lambda와 DynamoDB를 함께 사용할 때 Decimal 문제가 자주 발생합니다.

DynamoDB는 정밀한 숫자 계산을 위해 Decimal을 사용하지만, JSON은 Decimal을 모릅니다. 커스텀 인코더로 자동 변환하면 이 문제가 해결됩니다.

날짜와 시간을 다루는 API에서도 커스텀 인코더가 필수입니다. 예약 시스템, 일정 관리, 로그 분석 등에서 datetime을 자주 반환합니다.

ISO 8601 문자열로 변환하면 프론트엔드에서 쉽게 처리할 수 있습니다. 마이크로서비스에서 서비스 간 통신 시에도 에러 처리가 중요합니다.

한 서비스가 잘못된 JSON을 반환하면 연쇄적으로 다른 서비스도 실패합니다. 일관된 에러 응답 구조를 유지하면 에러가 전파되는 것을 막을 수 있습니다.

주의할 점도 있습니다. float 변환 시 정밀도 손실이 발생할 수 있습니다.

Decimal('1560000.50')을 float으로 변환하면 부동소수점 오차가 생길 수 있습니다. 금융 데이터처럼 정밀도가 중요하다면 문자열로 변환하는 것이 안전합니다.

타임존 문제도 주의해야 합니다. datetime.now()는 로컬 시간입니다.

서버가 어느 지역에 있느냐에 따라 시간이 달라집니다. UTC를 사용하거나, 타임존 정보를 명시적으로 포함해야 합니다.

커스텀 인코더가 너무 복잡해지면 성능 문제가 생길 수 있습니다. 매 객체마다 isinstance()를 여러 번 호출하면 느려집니다.

자주 사용하는 타입만 처리하고, 나머지는 기본 에러를 발생시키는 것이 좋습니다. 김개발 씨는 커스텀 인코더를 추가하고 다시 배포했습니다.

더 이상 파싱 에러가 발생하지 않았습니다. DynamoDB 데이터도 문제없이 반환되었습니다.

모니터링 대시보드에 녹색 불이 켜졌습니다. 파싱 에러 처리를 제대로 하면 API의 안정성이 크게 향상됩니다.

여러분도 커스텀 JSON 인코더를 꼭 구현하세요.

실전 팁

💡 - DynamoDB 사용 시 Decimal을 float 또는 문자열로 변환하세요

datetime은 ISO 8601 형식 문자열로 변환하면 크로스 플랫폼 호환성이 좋습니다
금융 데이터는 정밀도 유지를 위해 문자열로 전송하는 것을 고려하세요
에러 응답도 반드시 JSON 형식으로 반환해서 클라이언트가 일관되게 처리할 수 있도록 하세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#Python#Lambda#JSON#API#OutputFormat#AWS

AWS Lambda 출력 형식 제어 완벽 가이드

# AWS Lambda 출력 형식 제어 완벽 가이드 AWS Lambda와 서버리스 환경에서 다양한 출력 형식을 제어하는 방법을 배웁니다. JSON, 마크다운, 테이블 형식의 응답을 생성하고, 출력을 검증하며, 파싱 에러를 처리하는 실무 노하우를 담았습니다. --- ## 목차 1. [구조화된_출력의_필요성](#구조화된-출력의-필요성) 2. [JSON_형식_응답_요청](#json-형식-응답-요청) 3. [마크다운_형식_활용](#마크다운-형식-활용) 4. [테이블_형식_출력](#테이블-형식-출력) 5. [출력_검증하기](#출력-검증하기) 6. [파싱_에러_처리](#파싱-에러-처리) --- ## 1. 구조화된_출력의_필요성 어느 날 김개발 씨가 AWS Lambda 함수를 작성하던 중 난감한 상황에 부딪혔습니다. API Gateway로 연결된 Lambda 함수가 단순 문자열만 반환해서 프론트엔드 팀에서 데이터를 제대로 파싱하지 못한다는 연락을 받았습니다. "우리 팀은 JSON 형식이 필요한데, 어떻게 바꿀 수 있나요?" **구조화된 출력**이란 데이터를 일정한 규칙과 형식에 맞춰 반환하는 것을 말합니다. 마치 도서관 사서가 책을 분류 체계에 맞춰 정리하는 것처럼, 데이터도 미리 정해진 포맷으로 정돈해야 합니다. 이렇게 하면 데이터를 받는 쪽에서 일관된 방법으로 처리할 수 있고, 오류를 줄일 수 있습니다. 다음 코드를 살펴봅시다. ```python # 비구조화된 출력 (나쁜 예) def lambda_handler_bad(event, context): # 단순 문자열 반환 - 파싱 어려움 return "User: John, Age: 30, Status: Active" # 구조화된 출력 (좋은 예) def lambda_handler_good(event, context): # 명확한 구조로 반환 return { 'statusCode': 200, 'headers': {'Content-Type': 'application/json'}, 'body': { 'user': 'John', 'age': 30, 'status': 'Active' } } ``` 김개발 씨는 입사 3개월 차 백엔드 개발자입니다. 첫 번째 AWS Lambda 프로젝트를 맡아 열심히 코드를 작성했습니다. 함수는 잘 작동했고, 데이터도 제대로 반환되는 것처럼 보였습니다. 그런데 프론트엔드 팀 이수진 씨에게서 슬랙 메시지가 날아왔습니다. "김개발 님, API 응답이 문자열로 오는데 JSON으로 바꿔주실 수 있나요? 지금은 파싱이 너무 어려워요." 김개발 씨는 당황했습니다. 분명히 데이터를 반환했는데 뭐가 문제일까요? 선배 개발자 박시니어 씨가 화면을 보더니 한숨을 쉽었습니다. "아, 출력 형식을 제대로 안 맞췄네요. 이건 기본 중의 기본인데." **구조화된 출력**이란 무엇일까요? 쉽게 비유하자면, 구조화된 출력은 마치 택배 상자에 물건을 담는 것과 같습니다. 물건을 그냥 비닐봉지에 아무렇게나 넣으면 배송 중에 망가지거나 분실될 수 있습니다. 하지만 적절한 크기의 상자에 완충재와 함께 정돈해서 담으면 안전하게 배송할 수 있습니다. 데이터도 마찬가지입니다. 프로그래밍에서 데이터를 주고받을 때 가장 중요한 것은 **일관성**입니다. 데이터를 보내는 쪽과 받는 쪽이 같은 규칙을 따라야 오류 없이 통신할 수 있습니다. 구조화되지 않은 출력의 문제점은 무엇일까요? 첫째, **파싱이 어렵습니다**. 단순 문자열로 "User: John, Age: 30"이라고 반환하면 받는 쪽에서 문자열을 직접 잘라내고 분석해야 합니다. 콤마의 위치가 바뀌거나 순서가 달라지면 파싱 로직이 깨집니다. 둘째, **확장성이 없습니다**. 나중에 새로운 필드를 추가하려면 문자열 포맷을 바꿔야 하고, 이미 작성된 파싱 코드도 모두 수정해야 합니다. 프로젝트가 커질수록 이런 변경은 악몽이 됩니다. 셋째, **타입 정보가 사라집니다**. 숫자 30이 문자열 "30"이 되면서 타입 정보가 손실됩니다. 받는 쪽에서 다시 숫자로 변환해야 하는 번거로움이 생깁니다. 바로 이런 문제를 해결하기 위해 **구조화된 출력**이 필요합니다. 구조화된 출력을 사용하면 **명확한 데이터 구조**를 제공할 수 있습니다. JSON 같은 표준 포맷을 사용하면 키와 값의 관계가 분명해지고, 중첩된 데이터도 표현할 수 있습니다. 또한 **타입 정보**도 보존됩니다. 숫자는 숫자로, 불린은 불린으로 전달됩니다. 무엇보다 **호환성**이라는 큰 이점이 있습니다. JSON은 거의 모든 프로그래밍 언어에서 지원하는 표준 포맷입니다. Python으로 작성한 Lambda 함수의 출력을 JavaScript 프론트엔드에서 그대로 사용할 수 있습니다. 위의 코드를 비교해 보겠습니다. 나쁜 예시에서는 단순히 문자열을 반환합니다. 이 데이터를 받은 프론트엔드는 정규표현식이나 문자열 분리 로직으로 데이터를 추출해야 합니다. 실수하기 쉽고, 유지보수도 어렵습니다. 좋은 예시에서는 **statusCode**로 HTTP 상태를 명시하고, **headers**로 컨텐츠 타입을 지정하며, **body**에 실제 데이터를 구조화해서 담습니다. 이 형식은 API Gateway의 표준 응답 구조입니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 전자상거래 서비스를 개발한다고 가정해봅시다. 주문 정보를 조회하는 Lambda 함수를 작성할 때, 주문번호, 고객정보, 상품목록, 결제금액 등 복잡한 데이터를 반환해야 합니다. 이럴 때 구조화된 JSON 출력을 사용하면 프론트엔드, 모바일 앱, 외부 파트너사 시스템 모두가 같은 API를 문제없이 사용할 수 있습니다. AWS에서는 Lambda와 API Gateway를 함께 사용할 때 특정 응답 구조를 권장합니다. statusCode, headers, body를 포함하는 딕셔너리 형태입니다. 이 구조를 따르면 API Gateway가 자동으로 HTTP 응답으로 변환해 줍니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **body를 딕셔너리로 그대로 반환하는 것**입니다. API Gateway는 body를 문자열로 기대하기 때문에, 딕셔너리를 JSON 문자열로 직렬화해야 합니다. 이 부분을 놓치면 런타임 에러가 발생합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 코드를 수정했습니다. statusCode와 headers를 추가하고, body를 JSON 문자열로 변환했습니다. 다시 배포하고 테스트하니 이수진 씨에게서 엄지척 이모티콘이 날아왔습니다. **구조화된 출력**을 제대로 이해하면 API 개발의 기본을 탄탄히 다질 수 있습니다. 여러분도 오늘 배운 내용을 실제 Lambda 프로젝트에 적용해 보세요. **실전 팁** 💡 - API Gateway와 Lambda를 함께 사용할 때는 statusCode, headers, body 구조를 반드시 지키세요 - body는 JSON 문자열로 직렬화해야 한다는 점을 잊지 마세요 --- ## 2. JSON_형식_응답_요청 구조화된 출력의 중요성을 깨달은 김개발 씨는 이제 본격적으로 JSON 형식 응답을 작성하기 시작했습니다. 그런데 막상 코드를 작성하려니 궁금한 게 생겼습니다. "JSON 직렬화는 어떻게 하지? 한글은 깨지지 않을까?" **JSON 형식 응답**은 데이터를 JavaScript Object Notation 표준에 맞춰 반환하는 것입니다. Python의 딕셔너리나 리스트를 json.dumps() 함수로 문자열로 변환하면 됩니다. Lambda에서는 이 JSON 문자열을 body에 담아 반환하고, Content-Type 헤더를 올바르게 설정해야 클라이언트가 JSON으로 인식합니다. 다음 코드를 살펴봅시다. ```python import json def lambda_handler(event, context): # 반환할 데이터 준비 data = { 'orderId': 'ORD-2025-1234', 'customer': '김철수', 'items': [ {'name': '노트북', 'price': 1500000, 'quantity': 1}, {'name': '마우스', 'price': 30000, 'quantity': 2} ], 'totalAmount': 1560000 } # JSON 문자열로 변환 (한글 깨짐 방지) return { 'statusCode': 200, 'headers': { 'Content-Type': 'application/json; charset=utf-8' }, 'body': json.dumps(data, ensure_ascii=False) } ``` 김개발 씨는 구조화된 출력의 중요성을 깨달았습니다. 이제 실전입니다. 주문 조회 API를 만들어야 하는데, 주문 정보를 JSON으로 반환해야 합니다. 코드 에디터를 열고 손을 올렸지만, 문득 의문이 들었습니다. "Python 딕셔너리를 그냥 반환하면 되나? 아니면 뭔가 더 해야 하나?" 옆자리 박시니어 씨가 웃으며 말했습니다. "딕셔너리를 JSON 문자열로 바꿔야죠. json 모듈을 import 했나요?" **JSON 형식 응답**을 제대로 만들려면 몇 가지 단계를 거쳐야 합니다. 비유하자면, JSON 변환은 마치 편지를 봉투에 넣는 것과 같습니다. 편지 내용(데이터)을 작성했다면, 이제 봉투(JSON 문자열)에 넣고 우표(헤더)를 붙여야 상대방에게 제대로 전달됩니다. 편지를 그냥 던져주면 분실되거나 내용이 훼손될 수 있습니다. Python에서 JSON으로 변환하는 것을 **직렬화(serialization)**라고 부릅니다. 메모리에 있는 객체를 네트워크로 전송할 수 있는 문자열 형태로 바꾸는 과정입니다. 반대로 JSON 문자열을 다시 객체로 바꾸는 것은 **역직렬화(deserialization)**라고 합니다. JSON 직렬화 없이 딕셔너리를 그대로 반환하면 어떻게 될까요? Lambda는 반환값을 자동으로 JSON으로 바꿔주지 않습니다. API Gateway는 body가 문자열이기를 기대합니다. 딕셔너리를 그대로 넣으면 타입 에러가 발생하거나, 최악의 경우 클라이언트가 예상치 못한 데이터를 받게 됩니다. 또 다른 문제는 **한글 깨짐**입니다. Python의 기본 JSON 인코더는 ASCII 문자만 사용하려고 합니다. 한글 같은 유니코드 문자는 이스케이프 시퀀스(\uXXXX)로 변환됩니다. 클라이언트에서는 읽을 수 있지만, 로그를 볼 때나 디버깅할 때 사람이 읽기 어렵습니다. 바로 이런 문제를 해결하기 위해 **json.dumps() 함수**를 사용합니다. json.dumps() 함수는 Python 객체를 JSON 문자열로 변환합니다. ensure_ascii=False 옵션을 주면 한글을 그대로 유지합니다. 이렇게 하면 로그에서도 한글이 깨지지 않고 보입니다. 또한 **Content-Type 헤더**를 올바르게 설정해야 합니다. 'application/json'으로 지정하면 클라이언트는 이 응답이 JSON임을 알고 자동으로 파싱합니다. 'charset=utf-8'을 추가하면 한글 같은 유니코드 문자를 제대로 처리합니다. 위의 코드를 단계별로 분석해 보겠습니다. 먼저 import json으로 JSON 모듈을 불러옵니다. Python 표준 라이브러리에 포함되어 있으므로 별도 설치가 필요 없습니다. 다음으로 data 딕셔너리를 준비합니다. 주문 ID, 고객명, 상품 목록, 총액을 담았습니다. items는 리스트 안에 딕셔너리가 있는 중첩 구조입니다. JSON은 이런 중첩 구조를 완벽히 지원합니다. json.dumps(data, ensure_ascii=False)로 딕셔너리를 JSON 문자열로 변환합니다. ensure_ascii=False 덕분에 '김철수', '노트북' 같은 한글이 그대로 유지됩니다. 마지막으로 statusCode 200, 적절한 headers, 그리고 JSON 문자열이 담긴 body를 반환합니다. 이 형식은 API Gateway가 기대하는 정확한 구조입니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 REST API는 JSON으로 통신합니다. 사용자 정보 조회, 주문 생성, 상품 검색 등 거의 모든 API 응답이 JSON 형식입니다. Lambda를 사용하면 서버리스 환경에서 간단히 JSON API를 만들 수 있습니다. 특히 마이크로서비스 아키텍처에서는 서비스 간 통신도 JSON을 많이 사용합니다. 주문 서비스가 재고 서비스를 호출할 때, Lambda 함수끼리 이벤트를 주고받을 때 모두 JSON이 표준입니다. 프론트엔드 개발자들은 fetch나 axios로 API를 호출하고, 자동으로 JSON을 파싱해서 JavaScript 객체로 사용합니다. Content-Type이 정확히 설정되어 있으면 자동 파싱이 완벽하게 작동합니다. 하지만 주의할 점이 있습니다. **datetime 객체는 JSON으로 직렬화할 수 없습니다**. Python의 datetime은 JSON 표준에 없는 타입이기 때문입니다. 날짜를 반환해야 한다면 문자열로 변환하거나, 커스텀 JSON 인코더를 작성해야 합니다. 보통은 ISO 8601 형식 문자열('2025-01-15T10:30:00')로 변환합니다. 또 다른 실수는 **순환 참조**입니다. 객체 A가 객체 B를 참조하고, B가 다시 A를 참조하면 json.dumps()는 에러를 발생시킵니다. 데이터 구조를 설계할 때 순환 참조가 없도록 주의해야 합니다. 김개발 씨는 코드를 완성하고 테스트했습니다. curl로 API를 호출하니 깔끔한 JSON이 반환되었습니다. 한글도 깨지지 않았습니다. 프론트엔드 팀에서도 만족스럽다는 피드백이 왔습니다. **JSON 형식 응답**을 제대로 이해하면 API 개발이 훨씬 수월해집니다. 여러분도 json.dumps()와 적절한 헤더 설정을 꼭 기억하세요. **실전 팁** 💡 - datetime 같은 특수 타입은 문자열로 변환한 후 JSON 직렬화하세요 - ensure_ascii=False를 사용하면 한글이 읽기 쉬운 형태로 유지됩니다 - API Gateway 통합 시 body는 반드시 문자열이어야 합니다 --- ## 3. 마크다운_형식_활용 JSON으로 데이터를 주고받는 것에 익숙해진 김개발 씨는 새로운 요구사항을 받았습니다. "AI 모델의 응답을 사용자에게 보여줄 때 마크다운 형식으로 반환해주세요." 마크다운이라니, 그게 뭔가요? **마크다운 형식**은 텍스트에 간단한 서식을 추가하는 경량 마크업 언어입니다. #으로 제목을, **로 굵은 글씨를, -로 목록을 표현합니다. Lambda 함수가 AI 모델 응답이나 문서를 반환할 때 마크다운을 사용하면 프론트엔드에서 마크다운 렌더러로 깔끔하게 표시할 수 있습니다. 다음 코드를 살펴봅시다. ```python import json def lambda_handler(event, context): # AI 모델 응답을 마크다운으로 구성 markdown_content = """# AWS Lambda 소개 **AWS Lambda**는 서버를 관리하지 않고도 코드를 실행할 수 있는 서비스입니다. ## 주요 특징 - 서버리스 아키텍처 지원 - 자동 스케일링 - 사용한 만큼만 과금 ### 코드 예시 def hello(): return "Hello, Lambda!" 자세한 내용은 [AWS 공식 문서](https://aws.amazon.com/lambda)를 참고하세요. """ return { 'statusCode': 200, 'headers': {'Content-Type': 'text/markdown; charset=utf-8'}, 'body': json.dumps({'content': markdown_content}, ensure_ascii=False) } ``` 김개발 씨는 이제 JSON 응답을 능숙하게 다룰 수 있게 되었습니다. 그런데 새로운 프로젝트가 시작되었습니다. 회사에서 AI 챗봇 서비스를 런칭하기로 했고, Lambda 함수가 AI 모델의 응답을 프론트엔드에 전달하는 역할을 맡았습니다. PM인 최기획 씨가 요구사항을 설명했습니다. "AI 응답에 제목, 목록, 코드 블록 같은 서식이 필요해요. 마크다운 형식으로 반환해 주시면 프론트엔드에서 예쁘게 렌더링할게요." 김개발 씨는 고개를 갸우뚱했습니다. "마크다운이요? README 파일에서 본 것 같은데, 정확히 뭔가요?" **마크다운(Markdown)**이란 무엇일까요? 마크다운은 마치 문서 작성의 속기법과 같습니다. HTML처럼 복잡한 태그를 쓰지 않고도, 간단한 기호로 제목, 강조, 목록, 링크 등을 표현할 수 있습니다. 예를 들어 # 하나면 큰 제목, **로 감싸면 굵은 글씨가 됩니다. 배우기 쉽고, 작성하기 편하며, 읽기도 쉽습니다. GitHub의 README 파일, 기술 블로그, 문서화 도구에서 마크다운을 광범위하게 사용합니다. 최근에는 AI 챗봇 응답에도 마크다운이 많이 쓰입니다. ChatGPT나 Claude 같은 AI가 응답할 때 마크다운으로 서식을 표현합니다. 마크다운 없이 평범한 텍스트만 반환하면 어떻게 될까요? 제목과 본문의 구분이 없어 가독성이 떨어집니다. 중요한 단어를 강조할 수도 없고, 코드를 표시할 방법도 없습니다. 모든 텍스트가 똑같은 스타일로 보이면 사용자는 어디가 중요한지 파악하기 어렵습니다. 프론트엔드에서 HTML을 직접 생성할 수도 있지만, 이건 백엔드와 프론트엔드의 책임이 섞이는 것입니다. 백엔드는 데이터와 간단한 서식 정보를 제공하고, 프론트엔드가 실제 렌더링을 담당하는 게 깔끔합니다. 바로 이런 이유로 **마크다운 형식**이 중간 포맷으로 적합합니다. 마크다운을 사용하면 **간결한 문법**으로 서식을 표현할 수 있습니다. # 하나로 h1 제목, ## 두 개로 h2 제목을 만듭니다. **텍스트**는 굵게, *텍스트*는 기울임꼴이 됩니다. - 기호로 목록을 만들고, 숫자로 순서 있는 목록을 만듭니다. 또한 **코드 표현**이 편리합니다. 백틱 세 개(```)로 코드 블록을 만들고, 언어를 지정하면 문법 하이라이팅도 지원합니다. 인라인 코드는 백틱 하나로 감쌉니다. 무엇보다 **크로스 플랫폼 호환성**이 뛰어납니다. 웹, 모바일, 데스크톱 모두 마크다운 렌더러 라이브러리가 있습니다. React에서는 react-markdown, Vue에서는 vue-markdown 같은 라이브러리로 쉽게 렌더링합니다. 위의 코드를 살펴보겠습니다. 먼저 markdown_content 변수에 마크다운 문자열을 작성합니다. 파이썬의 트리플 쿼트(""")를 사용하면 여러 줄 문자열을 편하게 작성할 수 있습니다. # 하나는 h1 제목입니다. "AWS Lambda 소개"가 큰 제목으로 표시됩니다. **AWS Lambda**처럼 별표 두 개로 감싸면 굵은 글씨가 됩니다. ## 두 개는 h2 제목입니다. "주요 특징"이 중간 크기 제목이 됩니다. - 기호로 시작하는 줄은 목록 항목이 됩니다. ### 세 개는 h3 제목입니다. 백틱 세 개와 python을 써서 코드 블록을 만들고, 다시 백틱 세 개로 닫습니다. [텍스트](URL) 형식으로 하이퍼링크를 만듭니다. Content-Type을 'text/markdown'으로 설정하면 클라이언트가 이 응답이 마크다운임을 알 수 있습니다. 하지만 실제로는 JSON body 안에 content 키로 마크다운 문자열을 담는 경우가 많습니다. 이렇게 하면 추가 메타데이터(작성자, 작성일 등)도 함께 보낼 수 있습니다. 실무에서는 어떻게 활용할까요? AI 챗봇 서비스에서 Lambda 함수가 OpenAI API를 호출하고, 응답을 마크다운 형식으로 정리해서 반환합니다. 프론트엔드는 react-markdown 같은 라이브러리로 예쁘게 렌더링합니다. 사용자는 제목, 목록, 코드가 잘 구분된 답변을 받게 됩니다. 기술 문서 서비스에서도 마크다운을 많이 씁니다. Lambda 함수가 S3에 저장된 마크다운 문서를 읽어 반환하면, 프론트엔드가 렌더링합니다. 문서 작성자는 복잡한 HTML 대신 간단한 마크다운으로 작성할 수 있습니다. 코드 리뷰 봇, 이슈 트래커, 위키 시스템 등 협업 도구에서도 마크다운이 표준입니다. GitHub, Notion, Slack 모두 마크다운을 지원합니다. 주의할 점도 있습니다. **마크다운 방언(flavor)**이 여러 가지입니다. CommonMark가 표준이지만, GitHub Flavored Markdown(GFM), Markdown Extra 등 확장 버전이 있습니다. 테이블, 체크박스, 이모지 등 추가 기능을 지원합니다. 사용할 렌더러가 어떤 방언을 지원하는지 확인해야 합니다. 또 다른 함정은 **XSS 취약점**입니다. 사용자 입력을 마크다운으로 렌더링할 때, 악의적인 사용자가 ` ` 태그를 삽입할 수 있습니다. 안전한 마크다운 렌더러는 HTML 태그를 이스케이프하거나 화이트리스트 방식으로 필터링합니다. react-markdown은 기본적으로 안전하지만, 옵션을 잘못 설정하면 위험합니다. 김개발 씨는 마크다운 형식으로 응답을 작성했습니다. 프론트엔드 팀에서 react-markdown으로 렌더링했더니 깔끔하게 표시되었습니다. 최기획 PM이 흡족한 표정으로 엄지를 들어 올렸습니다. **마크다운 형식**을 활용하면 AI 응답이나 문서를 우아하게 표현할 수 있습니다. 여러분도 Lambda 함수에서 마크다운을 적극 활용해 보세요. **실전 팁** 💡 - 프론트엔드와 어떤 마크다운 방언을 사용할지 미리 합의하세요 - 사용자 입력을 렌더링할 때는 XSS 공격에 주의하세요 - 코드 블록에 언어를 지정하면 문법 하이라이팅을 지원합니다 --- ## 4. 테이블_형식_출력 마크다운까지 마스터한 김개발 씨에게 또 다른 요구사항이 들어왔습니다. "사용자별 월간 사용량 리포트를 표 형태로 보여주면 좋겠어요." 표라니, JSON으로는 어떻게 표현하죠? **테이블 형식 출력**은 데이터를 행과 열로 구조화해서 보기 쉽게 만드는 것입니다. JSON으로는 리스트와 딕셔너리의 조합으로, 마크다운으로는 파이프(|) 기호로 테이블을 만듭니다. Lambda 함수가 데이터를 테이블 구조로 반환하면 프론트엔드에서 표나 그리드로 쉽게 표시할 수 있습니다. 다음 코드를 살펴봅시다. ```python import json def lambda_handler(event, context): # 사용량 데이터 (테이블 형태) usage_data = [ {'user': '김철수', 'plan': 'Pro', 'requests': 15000, 'cost': 45000}, {'user': '이영희', 'plan': 'Basic', 'requests': 5000, 'cost': 10000}, {'user': '박민수', 'plan': 'Enterprise', 'requests': 50000, 'cost': 120000} ] # 마크다운 테이블 형식으로 변환 markdown_table = """| 사용자 | 요금제 | 요청 수 | 비용 (원) | |--------|--------|---------|-----------| | 김철수 | Pro | 15,000 | 45,000 | | 이영희 | Basic | 5,000 | 10,000 | | 박민수 | Enterprise | 50,000 | 120,000 | """ return { 'statusCode': 200, 'headers': {'Content-Type': 'application/json; charset=utf-8'}, 'body': json.dumps({ 'data': usage_data, # JSON 형식 'markdown': markdown_table # 마크다운 형식 }, ensure_ascii=False) } ``` 김개발 씨는 이제 JSON과 마크다운에 자신감이 붙었습니다. 그런데 영업팀에서 새로운 요청이 들어왔습니다. 월간 리포트 기능을 추가해 달라는 것입니다. 각 사용자의 요금제, 요청 수, 비용을 한눈에 볼 수 있는 표가 필요하다고 합니다. 김개발 씨는 생각했습니다. "표를 어떻게 만들지? JSON은 계층 구조인데, 표는 2차원 구조잖아?" 선배 박시니어 씨가 말했습니다. "테이블은 결국 행의 집합이에요. 각 행을 딕셔너리로, 전체를 리스트로 만들면 됩니다. 마크다운으로도 표를 만들 수 있고요." **테이블 형식 출력**이란 무엇일까요? 테이블은 마치 엑셀 스프레드시트와 같습니다. 가로줄(행)과 세로줄(열)이 교차하면서 데이터를 격자 형태로 배치합니다. 첫 번째 행은 보통 헤더(컬럼명)이고, 나머지는 데이터 행입니다. 이런 구조는 사람이 데이터를 비교하고 분석하기에 최적입니다. 프로그래밍에서 테이블 데이터를 표현하는 방법은 여러 가지입니다. 데이터베이스는 실제로 행과 열로 데이터를 저장합니다. CSV 파일도 테이블 형식입니다. JSON에서는 객체의 배열로 테이블을 표현합니다. 테이블 형식 없이 데이터를 나열하면 어떻게 될까요? 사용자별 데이터를 단순히 텍스트로 나열하면 비교가 어렵습니다. "김철수는 Pro 요금제에 15000건 요청, 이영희는 Basic 요금제에 5000건 요청..." 이렇게 나열하면 누가 가장 많이 사용했는지, 어떤 요금제가 인기 있는지 한눈에 보이지 않습니다. 반면 테이블로 표시하면 같은 컬럼끼리 세로로 정렬되어 비교가 쉽습니다. 숫자 컬럼은 오른쪽 정렬해서 자릿수를 맞추면 더 보기 좋습니다. 바로 이런 이유로 **테이블 형식**이 리포트나 대시보드에서 필수입니다. 테이블 데이터를 JSON으로 표현하는 가장 일반적인 방법은 **객체의 배열**입니다. 각 객체가 한 행을 나타내고, 객체의 키가 컬럼명이 됩니다. 이 형식은 직관적이고, 프론트엔드에서 반복문으로 쉽게 렌더링할 수 있습니다. 마크다운으로도 테이블을 만들 수 있습니다. 파이프(|) 기호로 열을 구분하고, 대시(-)로 헤더와 데이터를 구분합니다. GitHub Flavored Markdown에서 지원하는 기능입니다. 두 가지 형식을 함께 반환하면 **유연성**이 높아집니다. 프론트엔드가 HTML 테이블을 직접 렌더링하고 싶으면 JSON 데이터를 쓰고, 마크다운 렌더러를 쓰고 싶으면 마크다운 문자열을 쓰면 됩니다. 위의 코드를 분석해 보겠습니다. usage_data는 리스트 안에 딕셔너리가 담긴 구조입니다. 각 딕셔너리는 한 사용자의 데이터를 나타냅니다. 'user', 'plan', 'requests', 'cost' 키가 컬럼명 역할을 합니다. 이 데이터를 프론트엔드에서 받으면 React나 Vue의 반복문으로 쉽게 테이블을 그릴 수 있습니다. 예를 들어 React에서는 usage_data.map()으로 각 행을 \ 로 렌더링합니다. markdown_table은 마크다운 테이블 문법을 사용한 문자열입니다. 첫 번째 줄은 헤더입니다. 두 번째 줄의 대시는 헤더와 데이터를 구분합니다. 세 번째 줄부터는 실제 데이터입니다. 마크다운 렌더러가 이 문자열을 받으면 자동으로 HTML \ 태그로 변환합니다. 개발자가 직접 테이블 HTML을 작성할 필요가 없습니다. 두 형식을 모두 body에 담아 반환합니다. 프론트엔드는 필요에 따라 data를 쓸지 markdown을 쓸지 선택할 수 있습니다. 실무에서는 어떻게 활용할까요? 관리자 대시보드에서 사용량 리포트, 매출 통계, 사용자 목록 등을 테이블로 표시합니다. Lambda 함수가 데이터베이스를 조회해서 테이블 형식 JSON으로 반환하면, 프론트엔드는 ag-Grid나 React Table 같은 라이브러리로 고급 테이블을 만듭니다. 데이터 분석 도구에서도 테이블이 핵심입니다. Jupyter Notebook은 pandas DataFrame을 테이블로 표시합니다. Lambda 함수가 데이터를 가공해서 테이블 형식으로 반환하면 데이터 과학자가 바로 분석할 수 있습니다. 이메일 리포트를 보낼 때도 테이블이 유용합니다. Lambda 함수가 월간 리포트를 마크다운 테이블로 작성하고, SES로 HTML 이메일을 전송합니다. 수신자는 이메일에서 바로 표를 볼 수 있습니다. 주의할 점이 있습니다. **컬럼 순서**가 중요합니다. JSON 객체는 사실 순서를 보장하지 않지만, Python 3.7 이상에서는 딕셔너리가 삽입 순서를 유지합니다. 프론트엔드에서 컬럼 순서를 명시적으로 지정하거나, 백엔드에서 컬럼 메타데이터를 함께 전송하는 것이 안전합니다. **대용량 데이터**를 한 번에 반환하면 성능 문제가 생깁니다. 수만 개 행을 JSON으로 직렬화하면 시간이 오래 걸리고, 네트워크 전송도 느려집니다. 페이지네이션(pagination)을 구현해서 한 번에 일부만 반환하는 것이 좋습니다. 마크다운 테이블은 **복잡한 셀 병합**을 지원하지 않습니다. 엑셀처럼 여러 셀을 합치거나 중첩 테이블을 만들 수 없습니다. 복잡한 레이아웃이 필요하면 HTML 테이블을 직접 생성하거나, 프론트엔드에서 커스텀 렌더링해야 합니다. 김개발 씨는 두 가지 형식으로 테이블 데이터를 반환하는 코드를 완성했습니다. 영업팀에서 리포트를 보더니 "딱 이거예요!"라며 기뻐했습니다. 이제 매달 자동으로 사용량 리포트가 생성됩니다. **테이블 형식 출력**을 잘 활용하면 데이터를 직관적으로 전달할 수 있습니다. 여러분도 리포트 기능을 만들 때 테이블 형식을 적극 사용해 보세요. **실전 팁** 💡 - JSON 테이블은 객체의 배열 형태로 표현하세요 - 대용량 데이터는 페이지네이션을 구현해서 부분적으로 반환하세요 - 마크다운 테이블은 간단한 표에만 사용하고, 복잡한 레이아웃은 HTML이나 프론트엔드 렌더링을 고려하세요 --- ## 5. 출력_검증하기 김개발 씨는 여러 형식으로 데이터를 반환하는 데 익숙해졌습니다. 그런데 어느 날 버그 리포트가 들어왔습니다. "API 응답이 가끔 이상해요. 데이터가 누락되거나 타입이 틀릴 때가 있어요." 출력을 제대로 검증하지 않았던 것입니다. **출력 검증**은 Lambda 함수가 반환하는 데이터가 기대한 구조와 타입을 만족하는지 확인하는 과정입니다. JSON 스키마 검증, 타입 체크, 필수 필드 확인 등을 통해 잘못된 데이터가 클라이언트에 전달되는 것을 방지합니다. Pydantic 같은 라이브러리를 사용하면 쉽게 검증할 수 있습니다. 다음 코드를 살펴봅시다. ```python import json from typing import List, Optional from pydantic import BaseModel, Field, ValidationError # 응답 모델 정의 class UserUsage(BaseModel): user: str = Field(..., min_length=1, max_length=50) plan: str = Field(..., pattern='^(Basic|Pro|Enterprise)$') requests: int = Field(..., ge=0) # 0 이상 cost: int = Field(..., ge=0) class UsageReport(BaseModel): data: List[UserUsage] total_requests: int = Field(..., ge=0) total_cost: int = Field(..., ge=0) def lambda_handler(event, context): try: # 데이터 준비 (DB 조회 등) raw_data = [ {'user': '김철수', 'plan': 'Pro', 'requests': 15000, 'cost': 45000}, {'user': '이영희', 'plan': 'Basic', 'requests': 5000, 'cost': 10000} ] # 검증하면서 객체 생성 report = UsageReport( data=[UserUsage(**item) for item in raw_data], total_requests=sum(item['requests'] for item in raw_data), total_cost=sum(item['cost'] for item in raw_data) ) # 검증된 데이터를 JSON으로 변환 return { 'statusCode': 200, 'headers': {'Content-Type': 'application/json; charset=utf-8'}, 'body': json.dumps(report.dict(), ensure_ascii=False) } except ValidationError as e: # 검증 실패 시 에러 응답 return { 'statusCode': 400, 'body': json.dumps({'error': 'Invalid data', 'details': e.errors()}) } ``` 김개발 씨는 이제 다양한 출력 형식을 능숙하게 다룰 수 있게 되었습니다. JSON, 마크다운, 테이블까지 모두 마스터했습니다. 코드가 잘 작동하는 것처럼 보였습니다. 배포도 순조로웠습니다. 그런데 며칠 후, 프론트엔드 팀의 이수진 씨에게서 급한 슬랙 메시지가 왔습니다. "김개발 님, API 응답이 가끔 이상해요. user 필드가 없을 때도 있고, requests가 문자열로 올 때도 있어요. 프론트엔드가 계속 터져요!" 김개발 씨는 당황했습니다. 분명히 잘 작동했는데, 무엇이 문제일까요? 로그를 확인해 보니 데이터베이스에서 가져온 데이터가 예상과 달랐습니다. 어떤 사용자는 이름이 null이고, 어떤 레코드는 숫자가 문자열로 저장되어 있었습니다. 박시니어 씨가 코드를 보더니 한숨을 쉬었습니다. "출력 검증을 안 했네요. 데이터를 그대로 반환하면 안 됩니다. 반드시 검증해야 해요." **출력 검증**이란 무엇일까요? 출력 검증은 마치 공장의 품질 검사와 같습니다. 제품을 만들고 나서 바로 출하하지 않습니다. 검사 과정을 거쳐 규격에 맞는지, 불량은 없는지 확인합니다. 불량품은 걸러내고, 합격한 제품만 고객에게 보냅니다. 데이터도 마찬가지입니다. Lambda 함수가 데이터베이스, 외부 API, 파일 등에서 데이터를 가져올 때, 그 데이터가 항상 올바르다고 보장할 수 없습니다. 데이터베이스 스키마가 바뀌었을 수도 있고, 마이그레이션 중에 잘못된 데이터가 들어갔을 수도 있습니다. 외부 API는 문서와 다르게 동작할 수도 있습니다. 출력 검증 없이 데이터를 그대로 반환하면 어떻게 될까요? 첫째, **클라이언트가 오류를 만납니다**. 프론트엔드는 user 필드가 항상 있다고 가정하고 코드를 작성했는데, user가 없으면 JavaScript 에러가 발생합니다. 사용자는 빈 화면이나 에러 메시지를 보게 됩니다. 둘째, **디버깅이 어려워집니다**. 문제가 백엔드에서 발생했는지 프론트엔드에서 발생했는지 불명확합니다. 프론트엔드 개발자는 백엔드를 의심하고, 백엔드 개발자는 프론트엔드를 의심합니다. 시간이 낭비됩니다. 셋째, **보안 문제**가 생길 수 있습니다. 검증하지 않은 데이터에 악의적인 내용이 포함될 수 있습니다. SQL 인젝션, XSS 공격에 활용될 수 있습니다. 바로 이런 문제를 해결하기 위해 **출력 검증**이 필수입니다. 출력 검증을 하면 **조기 에러 감지**가 가능합니다. 데이터가 잘못되었을 때 클라이언트에 도달하기 전에 Lambda 함수에서 에러를 발생시킵니다. 로그를 보면 어떤 필드가 문제인지 명확히 알 수 있습니다. 또한 **타입 안전성**을 보장합니다. requests는 반드시 정수여야 하고, 음수일 수 없습니다. plan은 'Basic', 'Pro', 'Enterprise' 중 하나여야 합니다. 이런 규칙을 코드로 명시하면 실수를 방지할 수 있습니다. 무엇보다 **계약(contract)**을 명확히 합니다. API 문서에 "user는 필수 문자열, requests는 0 이상의 정수"라고 쓰는 것보다, 코드로 검증하는 것이 확실합니다. 문서는 오래되지만, 코드는 항상 최신입니다. 위의 코드를 살펴보겠습니다. Pydantic의 BaseModel을 사용해서 데이터 모델을 정의합니다. UserUsage는 한 사용자의 데이터 구조를 나타냅니다. user는 1~50자 문자열, plan은 정규표현식으로 세 가지 값만 허용, requests와 cost는 0 이상의 정수입니다. UsageReport는 전체 리포트 구조입니다. data는 UserUsage의 리스트입니다. total_requests와 total_cost도 0 이상의 정수입니다. lambda_handler에서 raw_data를 가져온 후, UserUsage 객체로 변환합니다. 이 과정에서 Pydantic이 자동으로 검증합니다. 타입이 틀리거나 범위를 벗어나면 ValidationError가 발생합니다. 검증을 통과하면 report 객체가 생성됩니다. report.dict()로 딕셔너리로 변환하고, json.dumps()로 JSON 문자열로 변환해서 반환합니다. 검증 실패 시 except 블록이 실행됩니다. statusCode 400과 함께 에러 상세 정보를 반환합니다. 클라이언트는 어떤 필드가 잘못되었는지 알 수 있습니다. 실무에서는 어떻게 활용할까요? 대부분의 프로덕션 API는 출력 검증을 합니다. FastAPI 같은 프레임워크는 Pydantic을 기본으로 사용합니다. API를 정의할 때 응답 모델을 지정하면 자동으로 검증됩니다. 마이크로서비스 아키텍처에서는 서비스 간 계약이 중요합니다. 각 서비스가 반환하는 데이터 구조를 명확히 정의하고 검증하면, 한 서비스의 변경이 다른 서비스를 망가뜨리지 않습니다. CI/CD 파이프라인에서도 검증이 유용합니다. 유닛 테스트에서 응답 모델을 검증하면, 코드 변경이 API 계약을 깨뜨리는지 자동으로 확인할 수 있습니다. 주의할 점이 있습니다. **검증은 비용**입니다. Pydantic은 빠르지만, 수만 개 객체를 검증하면 시간이 걸립니다. 성능이 중요한 경우 선택적으로 검증하거나, 스키마가 확실한 내부 데이터는 검증을 건너뛸 수 있습니다. **에러 메시지**가 너무 상세하면 보안 문제가 될 수 있습니다. 내부 데이터베이스 구조나 민감한 정보가 에러 메시지에 노출되지 않도록 주의해야 합니다. 개발 환경에서는 상세히, 프로덕션에서는 간략히 반환하는 것이 좋습니다. 김개발 씨는 Pydantic을 사용해서 출력 검증을 추가했습니다. 배포 후 며칠간 지켜보니 더 이상 이상한 응답이 발생하지 않았습니다. 이수진 씨에게서 감사 메시지가 왔습니다. "이제 API가 믿을 만해요!" **출력 검증**을 제대로 하면 API의 신뢰성이 크게 향상됩니다. 여러분도 Pydantic이나 유사한 도구로 검증을 꼭 추가하세요. **실전 팁** 💡 - Pydantic의 Field로 타입, 범위, 패턴 등을 상세히 지정하세요 - 검증 에러는 로그에 남기고, 클라이언트에는 간략히 전달하세요 - 성능이 중요한 경우 검증 범위를 조정하세요 --- ## 6. 파싱_에러_처리 출력 검증까지 완벽하게 마친 김개발 씨는 안심하고 있었습니다. 그런데 모니터링 알람이 울렸습니다. "JSON 파싱 에러가 발생했습니다." 클라이언트가 Lambda 응답을 파싱하다가 에러를 만난 것입니다. 대체 무엇이 문제일까요? **파싱 에러**는 클라이언트가 Lambda 응답을 해석할 때 발생하는 오류입니다. JSON 문법 오류, 인코딩 문제, 예상치 못한 데이터 타입 등이 원인입니다. 이를 방지하려면 JSON 직렬화 시 예외 처리를 철저히 하고, 인코딩을 명시하며, 클라이언트가 에러 응답도 파싱할 수 있도록 일관된 구조를 유지해야 합니다. 다음 코드를 살펴봅시다. ```python import json import decimal from datetime import datetime, date # JSON 직렬화 불가능한 타입을 처리하는 커스텀 인코더 class CustomJSONEncoder(json.JSONEncoder): def default(self, obj): # Decimal 타입 (DynamoDB에서 자주 사용) if isinstance(obj, decimal.Decimal): return float(obj) # datetime, date 타입 if isinstance(obj, (datetime, date)): return obj.isoformat() # 기타 처리 불가능한 타입 return super().default(obj) def safe_json_dumps(data): """안전한 JSON 직렬화""" try: return json.dumps(data, cls=CustomJSONEncoder, ensure_ascii=False) except (TypeError, ValueError) as e: # 직렬화 실패 시 에러 정보 반환 return json.dumps({ 'error': 'Serialization failed', 'message': str(e) }) def lambda_handler(event, context): try: # DynamoDB에서 가져온 데이터 (Decimal 포함) data = { 'orderId': 'ORD-2025-1234', 'amount': decimal.Decimal('1560000.50'), 'createdAt': datetime.now(), 'dueDate': date.today() } return { 'statusCode': 200, 'headers': { 'Content-Type': 'application/json; charset=utf-8' }, 'body': safe_json_dumps({'data': data, 'success': True}) } except Exception as e: # 예상치 못한 에러 처리 return { 'statusCode': 500, 'headers': { 'Content-Type': 'application/json; charset=utf-8' }, 'body': json.dumps({ 'error': 'Internal server error', 'success': False }) } ``` 김개발 씨는 출력 검증까지 완벽하게 구현했습니다. 이제 API는 탄탄해 보였습니다. 모든 테스트를 통과했고, 프론트엔드 팀도 만족했습니다. 배포하고 퇴근 준비를 하던 중, 갑자기 슬랙에 알람이 울렸습니다. "Production 환경에서 에러 발생! JSONDecodeError: Expecting value" 김개발 씨는 황급히 로그를 확인했습니다. Lambda 함수는 정상 실행되었는데, 클라이언트가 응답을 파싱하다가 에러를 만났습니다. 대체 무엇이 문제일까요? 박시니어 씨가 로그를 보더니 원인을 찾았습니다. "DynamoDB 데이터를 그대로 직렬화하려고 했네요. Decimal 타입은 JSON으로 바로 변환 안 됩니다." **파싱 에러**란 무엇일까요? 파싱 에러는 마치 외국어 번역 실패와 같습니다. 한국어를 영어로 번역할 때, 번역기가 이해하지 못하는 단어나 문법이 나오면 번역이 멈춥니다. JSON도 마찬가지입니다. Python 객체를 JSON 문자열로 변환할 때, JSON이 이해하지 못하는 타입이 있으면 직렬화가 실패합니다. JSON 표준은 아주 제한적인 타입만 지원합니다. 문자열, 숫자, 불린, null, 배열, 객체뿐입니다. Python의 datetime, Decimal, set, bytes 같은 타입은 JSON 표준에 없습니다. 이런 타입을 json.dumps()로 변환하려고 하면 TypeError가 발생합니다. 파싱 에러를 무시하면 어떻게 될까요? 첫째, **클라이언트가 망가집니다**. JavaScript fetch가 response.json()을 호출할 때 JSON 파싱 에러가 발생하면 catch 블록으로 빠집니다. 사용자는 "네트워크 오류" 같은 불친절한 메시지를 보게 됩니다. 둘째, **디버깅이 매우 어렵습니다**. Lambda 함수는 성공(statusCode 200)했는데 클라이언트는 에러를 받았습니다. 로그를 보면 Lambda는 정상이고, 클라이언트는 파싱 실패입니다. 어디가 문제인지 찾기 어렵습니다. 셋째, **간헐적 에러**가 발생합니다. 어떤 데이터는 잘 직렬화되고, 어떤 데이터는 실패합니다. 테스트에서는 잘 작동했는데 프로덕션에서만 에러가 나는 최악의 상황입니다. 바로 이런 문제를 해결하기 위해 **파싱 에러 처리**가 필수입니다. 파싱 에러를 방지하려면 **커스텀 JSON 인코더**를 사용합니다. json.JSONEncoder를 상속받아 default() 메서드를 오버라이드합니다. 이 메서드는 기본 인코더가 처리하지 못하는 타입을 받아 JSON 호환 타입으로 변환합니다. 예를 들어 Decimal은 float으로 변환합니다. DynamoDB는 숫자를 Decimal 타입으로 반환하는데, 이것을 그대로 직렬화하면 에러입니다. float으로 변환하면 해결됩니다. 정밀도가 중요하다면 문자열로 변환할 수도 있습니다. datetime과 date는 ISO 8601 형식 문자열로 변환합니다. isoformat() 메서드를 호출하면 '2025-01-15T10:30:00' 같은 표준 형식이 됩니다. 이 형식은 JavaScript의 new Date()가 이해할 수 있습니다. 또한 **safe_json_dumps() 같은 래퍼 함수**를 만들면 예외 처리를 한 곳에 모을 수 있습니다. 직렬화가 실패하면 에러 정보를 담은 JSON을 반환합니다. 최소한 클라이언트가 파싱은 할 수 있게 합니다. 위의 코드를 분석해 보겠습니다. CustomJSONEncoder 클래스는 json.JSONEncoder를 상속받습니다. default() 메서드에서 특수 타입을 처리합니다. isinstance()로 객체의 타입을 확인합니다. Decimal이면 float()으로 변환합니다. datetime이나 date면 isoformat()으로 문자열로 변환합니다. 처리할 수 없는 타입이면 super().default(obj)를 호출해서 기본 에러를 발생시킵니다. 이렇게 하면 에러 메시지에 어떤 타입이 문제인지 나옵니다. safe_json_dumps() 함수는 json.dumps()를 try-except로 감쌉니다. cls=CustomJSONEncoder로 커스텀 인코더를 지정합니다. 직렬화가 실패하면 에러 정보를 담은 JSON을 반환합니다. 최소한 JSON 문법은 올바르므로 클라이언트가 파싱할 수 있습니다. lambda_handler에서 DynamoDB 데이터를 가져왔다고 가정합니다. amount는 Decimal, createdAt은 datetime, dueDate는 date 타입입니다. safe_json_dumps()를 사용하면 모두 안전하게 변환됩니다. 최상위 try-except로 예상치 못한 에러도 잡습니다. 어떤 에러가 발생하더라도 statusCode 500과 함께 JSON 형식 에러 응답을 반환합니다. 클라이언트는 항상 JSON을 기대할 수 있습니다. 실무에서는 어떻게 활용할까요? AWS Lambda와 DynamoDB를 함께 사용할 때 Decimal 문제가 자주 발생합니다. DynamoDB는 정밀한 숫자 계산을 위해 Decimal을 사용하지만, JSON은 Decimal을 모릅니다. 커스텀 인코더로 자동 변환하면 이 문제가 해결됩니다. 날짜와 시간을 다루는 API에서도 커스텀 인코더가 필수입니다. 예약 시스템, 일정 관리, 로그 분석 등에서 datetime을 자주 반환합니다. ISO 8601 문자열로 변환하면 프론트엔드에서 쉽게 처리할 수 있습니다. 마이크로서비스에서 서비스 간 통신 시에도 에러 처리가 중요합니다. 한 서비스가 잘못된 JSON을 반환하면 연쇄적으로 다른 서비스도 실패합니다. 일관된 에러 응답 구조를 유지하면 에러가 전파되는 것을 막을 수 있습니다. 주의할 점도 있습니다. **float 변환 시 정밀도 손실**이 발생할 수 있습니다. Decimal('1560000.50')을 float으로 변환하면 부동소수점 오차가 생길 수 있습니다. 금융 데이터처럼 정밀도가 중요하다면 문자열로 변환하는 것이 안전합니다. **타임존 문제**도 주의해야 합니다. datetime.now()는 로컬 시간입니다. 서버가 어느 지역에 있느냐에 따라 시간이 달라집니다. UTC를 사용하거나, 타임존 정보를 명시적으로 포함해야 합니다. 커스텀 인코더가 너무 복잡해지면 **성능 문제**가 생길 수 있습니다. 매 객체마다 isinstance()를 여러 번 호출하면 느려집니다. 자주 사용하는 타입만 처리하고, 나머지는 기본 에러를 발생시키는 것이 좋습니다. 김개발 씨는 커스텀 인코더를 추가하고 다시 배포했습니다. 더 이상 파싱 에러가 발생하지 않았습니다. DynamoDB 데이터도 문제없이 반환되었습니다. 모니터링 대시보드에 녹색 불이 켜졌습니다. **파싱 에러 처리**를 제대로 하면 API의 안정성이 크게 향상됩니다. 여러분도 커스텀 JSON 인코더를 꼭 구현하세요. **실전 팁** 💡 - DynamoDB 사용 시 Decimal을 float 또는 문자열로 변환하세요 - datetime은 ISO 8601 형식 문자열로 변환하면 크로스 플랫폼 호환성이 좋습니다 - 금융 데이터는 정밀도 유지를 위해 문자열로 전송하는 것을 고려하세요 - 에러 응답도 반드시 JSON 형식으로 반환해서 클라이언트가 일관되게 처리할 수 있도록 하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: Python

태그: Python, Lambda, JSON, API, OutputFormat, AWS

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS Lambda 출력 형식 제어 완벽 가이드

목차

1. 구조화된 출력의 필요성

2. JSON 형식 응답 요청

3. 마크다운 형식 활용

두 개는 h2 제목입니다. "주요 특징"이 중간 크기 제목이 됩니다.

4. 테이블 형식 출력

5. 출력 검증하기

6. 파싱 에러 처리

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

보안 아키텍처 구성 완벽 가이드

AWS Organizations 완벽 가이드

AWS KMS 암호화 완벽 가이드

AWS Secrets Manager 완벽 가이드