안면 인식과 초개인화 키오스크 정도는 해커톤이면 충분하지 않나?

요약: 이 글에서는 AWS Gen AI를 활용한 안면 인식 기반 초개인화 키오스크를 개발해 3위를 수상한 경험을 공유합니다. Face Five팀은 ‘무엇을 개발할지’에 집중해 고객 얼굴로 식별, 메뉴 추천, 매출 분석이 가능한 솔루션을 설계했습니다. 또한, AWS Bedrock과 OpenSearch를 활용해 안면 인식과 개인화 추천 기능을 구현했습니다.

💡 리뷰어 한줄평

sunny.ryu Face Five팀의 안면 인식과 초개인화 키오스크 아이디어는 해커톤을 넘어 실제 실무에도 적용하고 싶을 만큼 값진 아이디어라 인상 깊었습니다.

시작하며

안녕하세요! 올해 진행한 제2회 카카오페이 해커톤에서 무려 3등을 수상한 Face Five팀입니다! 저희 팀이 수상한 안면 인식기반의 초개인화 키오스크 솔루션에 대해서 A부터 Z까지의 경험을 공유하고자 합니다.

비 개발자들의 해커톤 도전?

보통은 해커톤 하면 아무래도 개발 능력이 기반이 되어야 하기 때문에 개발자만 참여하는 경우가 많은데요. 저희는 카카오페이에서 기술지원직무를 수행하는 기술지원팀 팀원 5명이 모여서, Face Five라는 팀명으로 참가했습니다. 전체 팀 중에 유일하게 비 개발자들만으로 구성한 팀이었습니다.

Face Five라는 팀명은 안면 인식 솔루션이라는 점과 5명이 함께 한다는 의미를 담아서 정했습니다. 팀원(제임스, 올리비아, 샤른, 엘리제이, 피에르) 모두 개발자가 아니었지만, AWS Gen AI와 함께라면 충분히 도전해 볼 만하다고 생각했습니다. 더불어 해커톤에 참여하면서 반복되는 업무 속에서 새로운 활력소가 될 거라고 기대하며, 만장일치로 해커톤에 참가하기로 결정했습니다.

사실 참여를 결정했을 때만 해도 카카오페이의 쟁쟁한 개발자들이 많이 참여하기 때문에 입상까지는 전혀 기대하지 않았습니다. 초기 목표는 동작하는 프로덕트를 만들어서 시연이라도 한번 해보자 하는 마인드로 도전했습니다. 하지만 열정적으로 임한 덕분에 초기 목표를 뛰어넘어 3등이라는 놀라운 결과를 만들었습니다.

그럼 저희 Face Five팀이 어떻게 AI를 활용해서 좋은 결과를 낼 수 있었는지, 아이디어 구성과 기획 그리고 개발 및 최종 발표까지의 여정을 함께 살펴보시죠.

Phase 1: 아이데이션 - 아이템으로 승부 보자

이번 해커톤은 모든 팀이 AWS Gen AI를 반드시 활용해야 했습니다. 이러한 조건은 저희한테는 큰 이점으로 다가왔습니다. 이유는 개발자분들도 AWS Gen AI의 사용 경험은 많지 않을 것이고, AI를 활용한다면 저희도 준 개발자 수준의 퍼포먼스를 낼 수 있다고 판단 했기 때문입니다. 그렇다면 AI를 활용하는 기술요소보다는 솔루션의 번뜩이는 아이템과 그것을 임팩트 있게 풀어내는 기획, 마지막으로 심사위원을 매료시키는 PT가 핵심일 것이라고 가정했고, 운이 좋은 것일 수도 있지만 결과적으로는 저희 전략이 맞아떨어졌습니다.

결론적으로 저희는 어떻게 개발을 하느냐 보다는 무엇을 개발하느냐에 많은 힘을 쏟았습니다.(사실 어려운 부분은 AWS 담당자분들에게 도움을 받았기에 큰 어려움은 없었습니다.) 이미지 생성이나 문서 분석 등 일반적으로 AI를 활용하는 아이템으로는 승산이 없을 것으로 판단했습니다. 때문에, 카카오페이 서비스와 연관 있으면서도 시장에서 핫하게 뜨는 아이템으로 의견으로 모으고, 아이데이션을 진행했습니다.

*키오스크(Kiosk): 고객이 직접 결제하는 POS(Point of Sale)를 칭함.

이런 아이데이션 과정에서 탄생한 것이 제목과 같이 AWS Gen AI 기반 안면 인식기반 초개인화 키오스크 솔루션입니다! 짝짝짝짝!

*키오스크 솔루션 클라이언트 메인 진입화면

Phase 2: 솔루션 기획 - 아이템을 실현(입상) 가능하게

아이템을 구상한 뒤부터였던 것 같습니다. 저희가 입상에 대한 검은 욕망이 피어난 것이..
저희 팀은 상세 기획을 시작할 때부터 주요 기능들이 일관된 스토리가 있어야 하며, 심사위원(카카오페이 임원진 + AWS 담당자)를 위한 어필까지 필요하다고 생각했습니다. AWS 심사위원들에게는 비개발자 팀이 단기간에 AWS Gen AI로 솔루션을 만들었다는 스토리를 강조했습니다. 카카오페이 임원진에게는 오프라인 결제 서비스 혁신과 확장으로 카카오페이 서비스 가치를 높이는 방향으로 어필했습니다.

저희는 오프라인 결제 서비스의 혁신과 확장 이라는 목표를 솔루션에 담고자

결제 경험 혁신
초개인화된 추천 서비스 제공
오프라인 매장 영업 전략 수립

이 세 가지 주요 배경을 기반으로 저희 솔루션이 카카오페이가 이미 보유한 강력한 오프라인 결제 플랫폼을 기반으로 서비스의 확장성과 경쟁력을 한 단계 끌어올릴 수 있는 기폭제가 될 것이라고 기대했습니다. (약간 맞춰가는 느낌이지만 저희의 고도의 전략이었고, 실제 심사위원에게 제출하는 기획 문서 내용 그대로입니다.)

이러한 목표하에 다음 단계에서는 아래와 같이 전략을 수립했습니다.

주요 기능

결제 경험의 혁신 > 고객을 얼굴 하나로 식별하자
초개인화된 추천 서비스 제공 > 얼굴로 고객을 식별하고, 메뉴까지 추천하자
오프라인 매장 영업 전략 수립 > 점주에게 마케팅 및 판매 전략을 수립해 주자

구상 단계에서의 데이터 처리 과정 또한 상세하게 설계했습니다.

키오스크에서 고객 정보를 수집하고, AWS에 전송한다.(얼굴 이미지, 나이대, 성별, 선호 음식 분류)
수신받은 고객 정보를 AWS에 저장한다(RDS에 고객 정보, S3와 OpenSearch에 얼굴 이미지)
고객이 방문 시 얼굴로 인식하여 고객을 식별한다.(등록정보와 비교)
고객을 식별하면 고객 정보 + 구매 이력 + 날씨/지역을 기반으로 메뉴를 추천한다.
고객은 추천받은 메뉴를 선택하여 결제한다.(결제 내역 + 메뉴 + 고객 데이터 전송)
AWS에서 결제 내역을 저장하고 분석한다.(점주를 위한 마케팅 전략, 고객의 구매 이력을 통한 식습관 체크)

이렇게 Flow를 기획하고 보니 실제로 구현해야 할 부분이

고객 접점이 있는 키오스크
데이터를 송수신할 API GW
데이터를 저장할 RDS와 이미지를 저장할 벡터DB
점주와 고객 개인별로 제공되는 웹

화면 등이 필요했습니다.

사실상 POS 시스템을 거의 풀스택으로 구현해야 하는 상황이었습니다. 하지만 사전에 스터디를 해본 결과 키오스크(클라이언트) 빼고는 모두 AWS AI 플랫폼을 활용해서 구현할 수 있었습니다. AWS와 도움주실 TAM(AWS 기술지원)분들을 전적으로 신뢰하고 본격적으로 데이터를 설계했습니다.(키오스는 팀원 중 과거에 POS 클라이언트를 개발한 경험을 살려 샘플 프로그램으로 구성이 가능했음.)

Phase 3: 데이터와 아키텍처 설계 - 돌아가게 설계하자

기능 목록이 나왔기 때문에 주로 송수신할 데이터 기반으로 설계를 진행하기 시작했습니다. 저희 솔루션의 핵심은 고객 얼굴이미지에 대한 처리(안면 인식) 와 이를 바탕으로 한 개인별 메뉴 추천(초개인화) 이었습니다.

3.1 Data Interface Design

3.1.1 고객 정보 등록(키오스크 > AWS)

비하인드 스토리지만 저희는 고오급 카메라가 아닌 다*소에서 5,000원짜리 카메라를 구매했습니다. 비용도 비용이지만 처리 속도도 고려했습니다. 화소가 너무 높으면 이미지 파일 용량이 커서, 전송 속도 자체가 너무 오래 걸릴 것 같았습니다. 아래는 키오스크에서 고객 사진을 찍고 정보를 전송하는 데이터입니다.

curl --location --request POST 'https://{AWS API Gateway}/facefive/customerRegist' \
--header 'Content-Type: application/json' \
--data-raw '{
    "Id": "123456789012345678901234",
    "Name": "춤추는라이언",
    "Gender": "남",
    "AgeRange": "20대",
    "FavoriteFood": "한식",
    "faceImage": "iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg=="
}'

핵심은 faceImage이며 다*소 5,000원 카메라로 찍은 2MB 정도의 이미지를 base64로 인코딩하여 AWS로 전송했습니다. 지금에서야 하는 얘기지만 화소가 낮은 카메라임에도 불구하고 이미지를 전송하는 통신 시간이 체감상 수초대로 걸려, AWS에서 데이터를 처리하는 시간만큼 소요됐습니다. 배보다 배꼽이 큰 상황이었습니다.

3.1.2 메뉴 추천 요청(키오스크 > AWS)

이후 고객이 방문 시 키오스크에서는 얼굴을 사진으로 찍고 바로 아래와 같이 전송합니다.

curl --location --request POST 'https://{AWS API Gateway}/facefive/recommend \
--header 'Content-Type: application/json' \
--data-raw '{
    "datetime": "20250328094800",
    "salesMenu": ["햄버거", "콜라", "사이다" … 등등 매장에서 파는 전체 메뉴 리스트, 키는 메뉴명]
    "faceImage": "iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg=="
}'

아래 백엔드 부분에서 설명하겠지만 전송한 faceImage와 기존에 등록된 고객의 얼굴 이미지를 비교하여 아래 메뉴 추천 응답을 내려주게 됩니다.

3.1.3 메뉴 추천 응답(AWS > 키오스크)

아래는 요청에 따른 메뉴 추천에 대한 응답입니다.

HTTP/1.1 200 OK
Content-type: application/json;charset=UTF-8
{
  "customerId": "123456789012345678901234",
  "recommendMenu": ["짜장면", "짬뽕"],
  "recommendNotice": "춤추는 라이언님 평소에 패스트푸드를 즐겨드시지만 오늘은 날씨도 4도로 으슬으슬한데 한식 어떠실까요? 된장찌개는 건강에도 좋고.. 어쩌고 저쩌고 ",
}

customerId로 고객을 식별하여 고객 등록 당시 얼굴이미지를 출력하며, 매장에서 판매하는 메뉴 중에 고객이 선호하는 음식을 recommendMenu로 내려줍니다. 그리고 recommendNotice에 왜 추천했는지 상세 설명까지 포함하여 송신하여 키오스크에서는 해당정보를 표시합니다.

고객 식별도 안면 인식의 핵심이지만, 키오스크에서는 수신받은 정보를 기반으로 바로 메뉴를 등록하여 고객이 얼굴만 찍어도 자동으로 주문합니다. 이점도 메뉴 추천과 더불어 자동 주문 관점에서 좋은 평가를 받았습니다. 아래는 추천한 메뉴를 자동으로 등록하여 바로 결제할 수 있도록 한 키오스크 주문 화면입니다.

제한된 시간 때문에 화면 구성의 완성도가 다소 떨어지는 점은 아쉬웠습니다.

3.1.4 매출데이터 전송(키오스크 > AWS)

마지막으로 결제하면 아래와 같이 고객 정보와 함께 메뉴 정보를 함께 전송합니다.

curl -X POST \
  https://{AWS API Gateway}/facefive/salesRegist \
  -H "Content-Type: application/json" \
  -d '{
    "salesDatetime": "20250328094800",
    "salesAmount": 50000,
    "salesType": "결제",
    "salesMethod": "머니",  // 머니, 카드
    "salesCorpName": "카카오페이",  // 신한카드, 삼성카드 등
    "customerId": "123456789012345678901234",
    "menuInfo": ["햄버거", "콜라", "사이다"]
}'

해당 데이터를 바탕으로 Bedrock을 활용해서 매출 분석과 마케팅 전략을 수립하도록 구현했습니다. 원래 집계 테이블등에 데이터를 집계하여 상품별, 일자별, 고객별 분석하는 것이 보통입니다. 그러나, 저희는 원장에 데이터를 한 번에 넣고 AI가 자동으로 분석하게끔 진행하였습니다.

분석과 제안에 대한 퀄리티는 높았지만 수식계산에 오차를 보였는데, 이런 저 차원적인 실수를 하는 부분은 생성형 AI의 단점이 아닌가 싶습니다.

3.2 아키텍처 설계

데이터 설계를 어느 정도 완료한 이후, 해당 데이터를 처리할 AWS 벡엔드 아키텍처를 구성하였습니다.

먼저 키오스크를 통해 고객의 얼굴 이미지는 그대로 S3에, 이미지에서 추출한 특징벡터정보는 OpenSearch 에 저장하였고, 고객 정보(나이대, 성별, 선호 메뉴)는 MySQL에 저장하도록 구성했습니다. 중간 API-GW 역할은 Lambda를 통해서 Serverless 형태로 구현하여 별도의 API-GW는 구축하지 않았습니다.

저희 솔루션 핵심은 안면 인식을 얼마나 인식률 높게 하느냐였습니다. AWS에서 제공하는 Amazon Rekognition 솔루션을 사용하는 게 인식률면에서 좋은 선택지였으나 AWS Bedrock 사용이 필수기도 했고, 적용하기 간편한 AWS Bedrock Titan 파운데이션 모델 을 사용하기로 결정했습니다.

마지막으로 점주가 매출 분석, 마케팅 분석 등으로 사용할 웹페이지의 경우 Streamlit 앱서비스를 이용해서 적용하기로 했습니다.

이렇게 설계한 최종아키텍처입니다.

과연 저희가 구현할 수 있을까 했지만 해커톤 시작 전에 최대한 스터디하여 준비하였고, AI의 힘을 빌어서 대응하기로 하고 각자의 영역에서 준비에 매진했습니다.

Phase 4: 개발 - 그것을 현실로 만들다

열심히 스터디도 했지만 AWS Gen AI의 강력함으로 핵심 기능을 크게 어려움이 구현해 낼 수 있었습니다.(이점에서 AWS Gen AI에 박수를 한번 쳐주고 싶었고, 실제 최종 PT에서도 전략적으로 박수치는 퍼포먼스를 했습니다.)

지금부터 핵심인 백엔드 데이터 처리에 대해서만 살펴보겠습니다.

안면 이미지 저장

고객 정보는 MySQL에 촬영한 이미지 그대로 Lambda를 통해서 S3에 저장합니다. 저장된 이미지는 비교용으로 바로 사용할 수 없습니다. 때문에 저장 후 특징 벡터를 추출하여 별도의 벡터 DB(OpenSearch)에 저장해야 했습니다.

그래서 아래와 같이 Bedrock를 통해서 이미지에서 특징 벡터를 추출하여 OpenSearch에 저장했습니다.

  # Bedrock Runtime 클라이언트를 생성하고, 이미지 임베딩 모델 호출
    bedrock = boto3.client('bedrock-runtime')
    response = bedrock.invoke_model(
        modelId="amazon.titan-embed-image-v1",  # Amazon Titan Image Embedding v1 모델 지정
        contentType="application/json",
        accept="application/json",
        body=json.dumps({
            "inputImage": image_base64  # Base64로 인코딩된 이미지 데이터를 요청 본문에 포함
        })
    )

    # 모델 응답에서 이미지 임베딩 벡터 추출
    embedding = json.loads(response['body'].read())['embedding']

    (중략)

    # OpenSearch에 저장할 문서(document) 정의
    document = {
        'vector': embedding,     # Bedrock에서 생성된 임베딩 벡터
        's3_key': f"{key}",      # S3 객체 키
        's3_bucket': f"{bucket}" # S3 버킷 이름
    }

    # OpenSearch 인덱스에 문서 저장
    opensearch.index(index=opensearch_index, body=document)

저희가 설계한 대로 amazon.titan-embed-image-v1 모델을 통해서 특징 벡터를 추출하였고, 해당 정보를 OpenSearch에 저장했습니다. OpenSearch에 저장 후 인덱싱하는 시간이 30초 정도 걸리는 이슈가 있었습니다. 시연 시 등록 후 바로 조회하면 고객이 없기 때문에 유사한 사람으로 나오는 문제점이 있었지만, 인덱싱하는 30초를 잘 설명하며 위기를 모면했습니다.

안면이미지 비교

고객이 방문하여 주문 시 실시간으로 찍은 얼굴 이미지를 기존에 등록된 고객 이미지와 비교하는 부분입니다.

def search_opensearch(client: OpenSearch, query_vector: list):
    """
    OpenSearch에서 k-NN 검색을 수행하여 가장 유사한 문서를 찾습니다.

    :param client: OpenSearch 클라이언트 객체
    :param query_vector: 검색에 사용할 쿼리 벡터 (list 형태)
    :return: 유사도가 높은 순으로 정렬된 검색 결과 목록 (score, s3_key, s3_bucket 포함)
    """

    # OpenSearch에 보낼 검색 쿼리 정의
    query = {
        "size": 10,  # 검색 결과로 반환할 문서 수
        "query": {
            "knn": {  # k-NN(k-Nearest Neighbor) 검색을 사용
                "vector": {
                    "vector": query_vector,  # 검색을 수행할 벡터
                    "k": OPENSEARCH_K_NEAREST  # 찾을 가장 가까운 이웃의 수 (k값)
                }
            }
        }
    }

    # 정의된 쿼리로 OpenSearch 검색 API 호출
    response = client.search(index=OPENSEARCH_INDEX, body=query)

    # 검색 결과에서 필요한 정보(score, s3_key, s3_bucket)만 추출하여 새로운 리스트로 생성
    results = [
        {
            'score': hit['_score'],  # 유사도 점수
            's3_key': hit['_source']['s3_key'],  # S3 객체 키
            's3_bucket': hit['_source']['s3_bucket']  # S3 버킷 이름
        }
        for hit in response['hits']['hits']
    ]

    # 추출된 결과 리스트 반환
    return results

실시간으로 찍은 이미지도 특징 벡터를 추출하여, 기존에 저장된 벡터 정보와 유사도를 비교하도록 구현하였습니다. 유사도 알고리즘 중 k-NN 알고리즘을 선택해서 최대 10개까지 유사도가 높은 벡터를 찾고, 해당 정보를 응답으로 처리해서 고객을 식별합니다. 응답값 중 s3_key가 고객 번호이고 클라이언트(키오스크)에 해당 key 값을 송신하여 고객을 식별하도록 했습니다.

여기서 “안면 인식이 정확히 될까?” 하는 궁금증이 생길 수도 있는데요. 사전에 등록한 크루와 당일 시연에 참여한 크루가 총 50명 안팎인데, 단 한건의 인식 실패가 없어서 저희도 놀랐습니다.(날카로운 CTO께서 고객이 많아지면 인식률과 속도가 문제가 되겠네요 > 물론입니다.. 해커톤이고 시간이 없었어요.. 감안해서 잘 봐주시죠..로 넘겼습니다.)

메뉴 추천

고객 별로 Claude 모델을 사용하여 고객 정보와 점포 메뉴를 기반으로 메뉴를 추천하는 함수입니다.

def recommend_menu_with_claude(client, customer_info: dict, sales_menu: str, weather_info: dict, order_info: dict):
    """
    Claude 모델을 사용하여 고객 정보, 메뉴, 날씨, 과거 주문 정보를 기반으로 메뉴를 추천합니다.

    Args:
        client: AWS Bedrock 클라이언트 인스턴스.
        customer_info (dict): 고객 정보 (예: 성별, 나이, 좋아하는 음식).
        sales_menu (str): 현재 판매 중인 메뉴 목록을 나타내는 문자열.
        weather_info (dict): 현재 날씨 정보 (예: 위치, 온도, 습도, 날씨 상태).
        order_info (dict): 고객의 과거 주문 내역.

    Returns:
        tuple: recommend_notice1, recommend_notice2, recommend_notice3, recommend_notice4, recommend_menu
               추천 메시지 4개와 쉼표로 구분된 추천 메뉴 2개를 반환합니다.
    """
    # Claude 모델에게 전달할 메시지(프롬프트)를 구성합니다.
    messages = [
        {
            'role': 'user',
            'content': [
                {
                    'type': 'text',
                    'text': f"""당신은 식당의 메뉴 추천 전문가입니다. 다음 고객의 정보와 현재 가게 메뉴와 날씨정보를 기반으로 가장 적절한 메뉴를 추천해 주세요.

    **고객 정보:**
    성별: {customer_info.get('gender', '알 수 없음')}
    나이: {customer_info.get('age', '알 수 없음')}
    좋아하는 음식: {customer_info.get('favorite_food', '알 수 없음')}
    과거 먹었던 음식들(시간, 주문했던 메뉴) : {order_info}

    **현재 가게 메뉴:**
    {sales_menu}

    **현재 위치/날씨 정보:**
    위치 : {weather_info.get('name', '경기도 성남시 분당구 판교동')}
    온도 : {weather_info.get('temperature', '알 수 없음')}
    습도 : {weather_info.get('humidity', '알 수 없음')}
    날씨상태 : {weather_info.get('weather', '알 수 없음')}

    위 정보를 바탕으로 구분해서 API로 응답 줘야 해.

    recommend_notice1: {customer_info.get('name', '알 수 없음')}님 안녕하세요. O번째 방문해 주셨네요({order_info} 여기서 몇 번 먹었는지 추출 가능). 오늘도 방문해 주셔서 감사합니다. (1줄)
    recommend_notice2: 과거 주문음식 정보 알려줘야해. 과거 주문한 내역(시간도 포함)과 좋아하는 음식을 알려주는 멘트(1줄)
    recommend_notice3: 현재 시간 <판교>의 날씨 정보 알려주는 멘트. 마지막은 OOO 날씨예요.(1줄)
    recommend_notice4: 날씨정보 + 과거 주문음식 정보를 토대로 음식 추천해줘야 해. 음식 추천은 {sales_menu} 메뉴 안에서만 가능해.(너무 길지 않게, 최대 50자 안으로만)

    recommend_menu: 추천 메뉴를 2가지만 골라줘. 구분자는 ','로 해줘. 예시는 카레, 돈까스

매장에서 파는 전체 메뉴(sales_menu)중에서 고객이 입력한 선호 정보(customer_info)와 해당 고객이 기존에 매장에서 먹었던 메뉴(order_info)를 파라미터로 넘겨서 메뉴를 추천합니다. 기존 구매 정보를 기반으로 한다는 점에서 고객의 건강 리포트까지 구현할 수 있었습니다. 거기에 더 풍부한 추천을 위해 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 을 활용하여 날씨와 위치 정보 같은 데이터도 추가했습니다.

중요한 부분은 내부로직보다는 프롬프트의 최적화가 아닌가 싶습니다. 사실 메뉴 추천이 복잡도가 높은 프롬프트는 아니고, 추천도 메뉴에 한정적입니다. 좀 더 복잡한 프롬프트를 입력한다면 개발보다는 미세하게 파라미터를 조정하는 작업에 아마 리소스를 많이 소모할 것 같습니다.

저희는 시간 관계상 파라미터 조정 등의 디테일은 챙기지 못했습니다. 중식을 좋아한다고 했으니 짜장면이 나왔지요 하면서요..

매출 분석과 고객 식습관 확인까지

점주 입장에서 매출 리포트와 마케팅 분석을 할 수 있는 관리자 웹 화면도 구성하였습니다. 고객 입장에서도 고객의 식습관을 확인(건강 리포트)할 수 있는 화면도 구성했는데요, 이 부분에서 예상치 못하게 큰 점수를 얻었습니다.

API 로직은 Lambda와 Bedrock, Bedrock Agent를 사용했고, Streamlit으로 웹 서비스를 구현했습니다. Python 기반이라서 어려움은 없었습니다.

제한된 시간 내에 기획과 설계 개발 디자인을 모두 마무리해야 했기 때문에 완성도는 다소 떨어졌습니다. 그러나, 저희가 목표로 했던 안면 인식과 초개인화를 실제로 구현해냈습니다. 팀원들의 역량도 있겠지만, 실제 작업하면서 AWS Gen AI의 강력함을 더욱더 체감했습니다.

제품만 만든다고 해결되는 건 아니겠죠? 자 인제 제품을 어떻게 프레젠테이션했는지 살펴보겠습니다.

Phase 5: 최종 PT - 기술지원팀의 값진 결과

시연으로 승부를 걸자

심사는 1차와 2차로 나누어서 진행했으며, 1차 부스 행사에서는 심사위원분들이 실제 시연을 살펴보며 평가했습니다. 1차 심사에서 최종 6팀을 선정하였고, 저희 팀도 최종 6팀에 선정이 되어서 결선 PT를 준비했습니다. 발표 후 30분 만에 결선 PT를 준비해서 진행해야 했지만, 열정 가득한 저희 팀은 이미 결선 PT를 준비해두고 있었습니다.

하지만 해커톤 기간 내에 PT도 준비하고 완성도를 높이는 일은 솔루션도 완성도에 비해서 우선순위가 낮았습니다. 때문에 PT에 집중하기보다 ”백문이 불여일견(百聞不如一見)“이라는 말처럼, 개발한 솔루션으로 시연하기로 했습니다. 임팩트 있는 장표 몇 장으로 빠르게 소개하고, 진행자 중 한 분을 바로 앞으로 모셨습니다. 극적인 요소를 더 넣기 위해 실시간으로 안면을 등록하고 바로 인식이 가능하다는 것을 증명하며 승부수를 띄었습니다.(웃음) 사실 승부라기엔 부스에서 시연하면서 이미 수십 명의 사용자 중 한 번의 실패도 없었기에 자신 있었습니다.

*아래 줄 왼쪽이 저희 팀이고, 진행자 중 한 분을 모셔서 실제 시연하는 장면입니다.

자신은 있었지만 다행스럽게도 안면 인식을 훌륭하게 Bedrock이 해주었고, 이 점에서 박수를 받으며 점수에 높이 반영되어 입상까지 가지 않았나 싶습니다. 심사 항목은 아이디어 참신성(40점), AI 활용도(30점), 서비스 완성도 및 발표력(30점) 기준인데, 후에 얘기를 들어보면 아이디어 참신성과 발표력 부분에서 높은 평가를 받았다고 들었습니다.

에어팟프로 아니 3등 입상!

결선 PT 이후 바로 해커톤 결과가 발표됐습니다. 저희 “페이스파이브” 팀은 치열했던 29개 참가팀의 경쟁 속에서 최종 3위라는 값진 성과를 얻었습니다! 비 개발자 팀으로서 AWS Gen AI를 활용하여 이뤄낸 성과이기에 더욱 감격스럽고 자랑스러운 순간이 아니었나 싶습니다.

(왼쪽부터 샤른, 엘리제이, 올리비아, 피에르, 제임스)

마치며

에어팟프로보다 값진 해커톤 경험

프로젝트 개발 과정에서 가장 큰 어려움 은 아무래도 팀원 모두가 개발자가 아니었다는 점이었습니다. 생소한 AWS Gen AI 서비스를 이해하고, 그것들을 조합하여 애플리케이션으로 구현하는 과정 하나하나가 큰 도전이었습니다. 하지만 서로 협력하고 배우면서 문제를 해결해 나가는 과정에서 많은 것을 배우고 느낄 수 있었습니다.

그리고 기술지원팀 소속 5명의 크루가 AWS Gen AI라는 강력한 도구를 활용하여 땀 흘리며 만들어낸 결과는 팀원 모두에게 큰 성취감을 안겨주었습니다. 사전 구상부터 개발, 그리고 최종 발표까지 비록 짧은 기간이었지만, 아이디어를 구체화하고 실제 동작하는 서비스로 만들어내는 과정과 좋은 결과는 매우 값진 경험이었습니다.

이번 해커톤을 경험하며 AI의 무한한 가능성을 체감했습니다. 앞으로 AI를 기술지원 업무에 적극적으로 활용할 다양한 아이디어도 얻었습니다. 저희 Face Five 팀의 AWS 해커톤 도전기는 여기서 일단락하지만, 이 경험이 미래 카카오페이 서비스 혁신의 작은 밑거름이 되기를 기대합니다.

긴 글 읽어주셔서 감사합니다!