Tech Dive

Databricks Genie Space 사용 사례

0. 들어가며

사업담당자가 유동인구를 자연어로 직접 조회하는 도구, OOH(Out of Home) CELL FLOW 구축기


안녕하세요. KT 전수연, 송찬영, 김성수입니다. 저희는 각각 광고 관련 미디어데이터 분석과, 클라우드 빅데이터 플랫폼 운영, 옥외광고 매체 선정 및 효과 리포트 발행을 담당하고 있습니다.


옥외광고는 한번 집행하면 수 주에서 수 개월을 갑니다. 그만큼 어디에 걸지를 감이 아니라 데이터로, 그것도 빠르게 판단하는 일이 중요해지고 있습니다. 유동인구처럼 살아 움직이는 데이터를 그때그때 들여다보고 대응하는, 애자일하고 데이터에 기반한 분석이 옥외광고에도 필요해진 것입니다. 그런데 정작 그 데이터로 매체를 골라야 하는 사업담당자는 데이터를 직접 다루지 못했습니다. 좌표도 SQL도 낯설고, 매번 분석팀을 거쳐야 했기 때문입니다. 이 간극을 메우려고 만든 것이 Databricks Genie Space 기반의 도구, OOH CELL FLOW입니다.


이 글에서는 사업담당자, 그러니까 개발을 하지 않는 실무자가 유동인구를 자연어로 직접 조회할 수 있도록 이 도구를 어떻게 만들었는지를 먼저 다룹니다. 그리고 그렇게 손에 쥔 데이터가 옥외광고 현장에서 어떤 새로운 가치를 만들어 내는지를 실제 사례로 이어서 이야기 드리고자 합니다.


1. 왜 만들었나

옥외광고는 매체를 어디에 거느냐가 성과를 가릅니다. 같은 예산이라도 사람이 많이, 그 중에서도 정확한 광고타깃층이 많이 오가는 자리에 걸어야 효과가 납니다. 그 판단의 근거가 유동인구입니다.


KT는 통신망을 기반으로 50m 셀 단위의 유동인구 데이터를 가지고 있습니다. 시간대와 성별, 연령까지 나뉜 정밀한 신호입니다. 문제는 데이터가 아니라 접근성이었습니다. 정작 이 데이터로 매체를 골라야 하는 사업담당자가 직접 뽑지 못했습니다.


이유는 세 가지였습니다.

  1. 원천 테이블의 진입장벽 → 원천은 컬럼이 수십 개라, 어디를 봐야 유동인구가 나오는지, 어떤 컬럼을 어떻게 조합해야 하는지 비개발자가 알기 어렵습니다.

  2. 좌표와 SQL의 벽 → “광화문 반경 1km”를 뽑으려면 좌표계를 알아야 하고, 집계 SQL을 짜야 합니다. 사업담당자에게는 둘 다 낯선 언어입니다.

  3. 분석팀을 거치는 리드타임 → 결국 매번 분석팀에 요청해야 했고, 답을 받기까지 며칠이 걸렸습니다. 시장의 좋은 기회들은 대개 그 시간을 기다려주지 않습니다.


정리하면 데이터는 있는데 남의 손에 있었습니다. 이것을 사업담당자 자기 손으로 옮기는 것이 이 프로젝트의 출발점이었습니다.


2. Genie Space?

해답의 출발은 Databricks의 Genie Space였습니다.

Databricks Genie는 사용자가 자연어(Natural Language)로 데이터에 질문하고 답변을 받을 수 있게 해주는 AI 기반 대화형 인터페이스입니다.SQL을 모르는 사용자도 "소공동의 어제 유동인구 알려줘?" 같은 한국어로 질문을 입력하면, Genie가 SQL 쿼리를 자동 생성하여 실행하고 결과를 테이블, 차트, 지도, 텍스트 설명 형태로 결과를 제공합니다.

Genie의 핵심은 '답변 정확도'

Genie의 성공은 다양한 기능보다 답변의 정확도와 신뢰성에 달려 있습니다. 사용자가 원하는 결과를 정확하게 제공하지 못한다면, 아무리 뛰어난 기능을 갖추고 있더라도 실제 업무 활용도는 낮아질 수밖에 없습니다.

Genie의 답변 정확도를 높이는 가장 효과적이고 쉬운 세 가지 방법을 소개합니다.


첫째, 작게 시작하고 점진 확장

  • 처음부터 많은 테이블을 연결하기보다는 5개 미만의 핵심 테이블로 Space를 구성하는 것을 권장합니다.
  • Genie가 참조해야 하는 테이블이 많아질수록 잘못된 테이블이나 컬럼을 선택할 가능성이 높아지고, 이는 답변 정확도 저하로 이어질 수 있습니다. 핵심 데이터부터 시작해 검증을 거친 후 점진적으로 확장하는 방식이 가장 효과적입니다.


둘째, 메타 데이터(동의어) 설정
  • 특히 한국어 비즈니스 용어를 Synonyms로 등록하면 사용자의 자연어 질문과 데이터 모델 간의 매칭 정확도가 크게 향상되어 보다 정확한 답변을 제공할 수 있습니다.
    02.png


  • 예) 2026년 월별 가입 건수를 알려줘
    ✔︎ 동의어가 없을 경우 다른 컬럼을 선택 할 수 있습니다
    ✔︎ base_dd : 기준일자, new_dd : 신규일자


셋째, Instruction 설정
  • Instruction은 Genie가 사용자의 질문 의도를 정확하게 이해하고, 일관된 결과를 생성할 수 있도록 정의하는 작업 지침입니다.
    03.png


  • Genie는 사용자의 업무 맥락과 도메인 지식을 알지 못하므로, 사용자가 알고 있는 정보를 텍스트 형태로 명확하게 제공할수록 더 정확한 분석과 답변을 생성할 수 있습니다.


결국 프로젝트의 핵심은 Genie를 구축하는 것이 아니라, Genie가 올바르게 이해하고 답변할 수 있도록 데이터와 지식을 얼마나 체계적으로 정의했는가에 있습니다.


지금부터 실제 프로젝트에서 이러한 원칙을 어떻게 참고했고, 답변 정확도를 어떻게 개선했는지 소개하겠습니다.


3. 무엇을 만들었나

만든 도구의 이름은 OOH CELL FLOW입니다. Genie에 유동인구 원천을 그대로 붙이지 않고, 가운데에 서빙 레이어를 한 겹 두었습니다.


전체 구조는 다음과 같습니다.

01.jpg


서빙 레이어는 세 가지로 이루어집니다. 구현 상세는 4장에서 다룹니다.

  • 서빙 뷰 8종 → 필요한 컬럼만 노출하고 집계는 미리 해 둔 창구

  • 커스텀 함수 6종 → 위경도를 우리 셀 좌표로 바꾸고, 반경 안 셀을 찾아 주는 계산기

  • 시스템 프롬프트 → 사람의 말을 어떤 데이터로 옮길지 정한 규칙


여기에 한 가지를 더했습니다. 옥외광고 매체는 종류가 많습니다. 바로광고 매체 6,954개(가로변 버스쉘터 인쇄 2,259, 타운보드 2,120, 편의점 탑뷰 1,488, 미디어밋 695 등 30여 종)의 위경도·이름 테이블을 통째로 연동했습니다. 그래서 “강남역 매체 반경 유동인구”, “버스쉘터 매체별 상위 20개” 같은 질문이 가능해졌습니다.

이렇게 채워 두면 사업담당자는 실제로 여덟 갈래로 묻습니다.


#
유형
질문 예시
1
행정구역
“소공동 어제 유동인구”
2
성별·연령
“강남역 2030 여성”
3
7일 추이
“최근 7일 홍대 추이”
4
순위
“종로구에서 유동인구 상위 동”
5
위경도 반경
“광화문 1km 반경”
6
50셀 지도
“그 반경 50셀 지도로”
7
매체 반경
“강남역 출구 매체 반경 누가 다녀”
8
매체 검색
“버스쉘터 매체별 상위 20개”


한 번 문법을 익히면 여덟 유형 어디서나 같은 방식으로 묻습니다. SQL도 좌표도 몰라도 됩니다.



4. 어떻게 구현 했나

자연스럽게 동작하기까지 세 가지를 고민했습니다. 겉은 no-code지만 안에는 직접 만든 것들이 들어 있습니다.


서빙 뷰 — 필요한 것만 담은 창구

원천을 Genie에 바로 붙이지 않은 이유가 있습니다.

  • 원천은 컬럼이 수십 개라 비개발자가 길을 잃습니다.

  • 원천을 그대로 노출하면 보호도 어렵고, 매번 무거운 집계라 응답도 느립니다.

그래서 Unity Catalog 뷰(ooh_genie_*)로 필요한 컬럼만 노출하고, 자주 쓰는 집계는 미리 계산해 두었으며, “최근 7일”은 매일 새로 만들어 구조로 고정했습니다. 원천은 붙이지 않았습니다. 사용자는 정리된 창구만 보고, 원천은 뒤에서 안전하게 둡니다.


동적 위경도 함수 — 위경도를 우리 셀로 바꾸는 계산기

이 프로젝트에서 가장 품이 많이 든 부분입니다.


사업담당자는 “광화문”, “강남역”처럼 이름으로 말합니다. 위경도 좌표는 모릅니다. 그런데 유동인구는 50m 셀 단위라, 위치를 정확한 좌표로 집어야 찾을 수 있습니다. 게다가 묻는 위치는 질문마다 달라서 미리 정해 둘 수가 없습니다.


그래서 위경도를 그때그때 변수로 받아, 그 지점을 기준으로 반경을 계산하고, 반경 안에 드는 50m 셀을 찾아 주는 함수를 직접 만들었습니다. 핵심 계산은 두 단계입니다.

02.png


함수 계산식 — 위경도를 셀 좌표로 변환하고 반경 안 셀을 골라냄

함수가 함수를 부르는 구조입니다. Unity Catalog에 함수 6개를 직접 등록했고, 서로를 호출합니다.

03.png


함수 호출 구조 — 함수가 함수를 부른다

06.jpg

Unity Catalog에 직접 등록한 함수 6개. 서로를 호출합니다.


이 부분에서 특히 시간이 든 지점은 KT 50셀 좌표계에 맞추는 정렬 오프셋(+110800 / +100000)이었습니다. 표준 투영 공식만으로는 우리 셀 좌표와 미세하게 어긋나서, 검증된 좌표(예: 광화문)와 맞을 때까지 오프셋을 직접 맞춰야 했습니다.


참고로 이 좌표 변환과 거리 계산은 당시에는 직접 구현해야 했는데, 마침 2026년 6월에 Databricks가 Spatial SQL을 정식 출시했습니다. ST_Transform, ST_DWithin 같은 표준 공간 함수로 상당 부분을 대체할 수 있게 되었고, 지금은 그쪽으로 옮겨 가는 것을 검토하고 있습니다. 다만 표준 변환만으로는 우리 50m 셀 위치와 살짝 어긋나서, 위치를 맞추는 보정은 여전히 직접 해 줍니다.


시스템 프롬프트 — no-code의 진짜 코드

no-code 도구에서 실제 코드 역할을 하는 것은 시스템 프롬프트, 곧 지침이었습니다. 사람의 말을 어떤 데이터로 옮길지를 글로 적어 두는 부분입니다. 이 지침이 있고 없고의 차이가 곧 답의 정확도 차이라, 여기에 가장 많은 공을 들였습니다. 규칙은 세 묶음으로 설계했습니다.


첫째, 데이터 라우팅입니다. 어떤 질문에 어떤 창구를 쓸지 정하는 규칙입니다. 같은 유동인구라도 질문 유형에 따라 답을 찾는 곳이 다릅니다. 그래서 유형별로 쓸 뷰와 함수를 지정했습니다.

  • 행정구역 질문(소공동, 종로구) → admin_hour_demo 뷰

  • 위경도 반경 질문(광화문 1km) → cell_hour_demo + cel50_dim + 좌표 함수

  • 매체 반경 질문 → media_spot_lookup


여기에 안전장치를 하나 걸었습니다. “원천 테이블은 절대 조회하지 마세요.” 사용자가 무심코 원천을 건드리는 일을 권한이 아니라 프롬프트 단에서 한 번 더 막았습니다.


둘째, 날짜 규칙입니다. 가장 섬세했던 부분입니다. 날짜는 실수가 나기 가장 쉬운 지점이었습니다. 규칙이 없으면 Genie가 엉뚱한 날짜를 잡거나, 최악의 경우 전체 기간을 스캔합니다.

  • 날짜를 말하지 않으면 → 최신 가용일 하루만 (fn_latest_pop_date())

  • “최근 7일”이라고 명시하면 → 딱 7일 (allowed_dates)

  • “6월 12일”, “어제” → 그 날짜를 그대로 조회 (최신일로 덮어쓰지 않도록)

  • 7일을 넘는 기간이나 한 달, 전체 요청 → 실행하지 않고 “최신 포함 최대 7일까지 조회할 수 있습니다”라고 안내

  • 답변에는 항상 기준 날짜를 함께 표시


셋째, 시간대 해석입니다. 사람의 말을 시(hour)로 옮기는 규칙입니다. 사업담당자는 “점심”, “퇴근 시간”처럼 말하지 “hour 17~19”라고 말하지 않습니다. 그래서 일상어를 시간 범위로 옮기는 사전을 만들었습니다.

  • “점심” → 11~13시, “퇴근 시간” → 17~19시, “저녁” → 18~21시

  • “오후 3-5시” → hour 15~17

  • 시간을 말하지 않으면 → 전 시간대 합산, 답에 “전 시간대 합산”이라고 명시


실제 지침은 이런 문장들로 되어 있습니다. (일부 발췌)

  • 원천 테이블은 절대 조회하지 마세요.

  • 행정구역 질문은 ooh_genie_admin_hour_demo_7d_core4_v1 우선 사용하세요.

  • 날짜를 말하지 않으면 fn_latest_pop_date()가 반환하는 최신일 1일만 조회하세요.

  • "점심"은 11-13시, "퇴근 시간"은 17-19시, "저녁"은 18-21시로 해석하되,

  

답변에 해석한 시간대를 명시하세요.

  • 시간이 없으면 전 시간대(0-23시) 합산으로 답하고 "전 시간대 합산"이라 명시하세요.

    07.jpg

    Genie Space에 실제로 등록한 지침(General Instructions) 화면.

    08.jpg

    지침과 함께 등록한 예시 질문들. Genie가 이걸 참고해 비슷한 질문에 답합니다.


같은 “광화문”이라도 행정구역인지 좌표 반경인지, “어제”가 며칠인지, “점심”이 몇 시인지. 사람에게는 당연한 맥락을 Genie에게는 하나하나 글로 적어 줘야 답이 흔들리지 않습니다. 프롬프트를 글이 아니라 라우팅 규칙처럼 다룬 셈입니다.


가장 어렵고 시간이 많이 걸린 작업

좌표계 오프셋 검증이 첫 번째였습니다. 표준 투영 공식과 KT 셀 좌표계 사이의 미세한 차이를, 검증된 지점 좌표와 맞을 때까지 반복해서 보정했습니다.


질문 모호성 라우팅이 두 번째였습니다. “광화문”이 행정구역인지 좌표 반경인지처럼, 한 단어가 여러 갈래로 갈릴 수 있는 지점을 지침으로 하나하나 정리했습니다.


기억에 남는 순간

“광화문 1km 반경”을 이름으로 물어도, “위도 37.5759, 경도 126.9769 반경 1km”를 좌표로 물어도 같은 답이 나오는 것을 확인했을 때입니다. 사용자는 편한 대로 말하고, 안에서는 정밀한 공간 연산이 도는, 처음 그리던 그림이 실제로 맞아떨어진 순간이었습니다.


5. 결과

무엇이 바뀌었는지부터 보겠습니다.

구분
Before
After
유동인구 조회
분석팀에 요청 → 며칠
사업담당자가 자연어로 즉시
필요 지식
좌표·SQL·원천 구조
없음 (한국어 문장)
매체 반경 분석
사실상 어려움
“이 매체 반경 누가 다녀” 한 줄


실제로는 이렇게 답이 나옵니다.

  • “광화문 1km 반경 유동인구” → 1,119,740명. 반경 안 50m 셀 1,258개를 합산한 값으로, 도심 유동으로는 상당한 규모입니다.

  • “위도 37.5759, 경도 126.9769 반경 1km” → 1,119,740명. 좌표로 물어도 같은 결과입니다.

  • “소공동 어제 유동인구” → 230,960명. 성별과 연령으로도 나눠서 답합니다.

    09.jpg


    위경도로 물으면 반경 안 50셀의 위치와 유동인구가 표로 나옵니다. 오른쪽 Data 탭에 연동한 서빙 객체들이 보입니다.

    10.jpg

    같은 결과를 지도로 본 모습입니다. 반경 300m 안 50m 셀별 유동인구 분포이며,색이 진할수록 사람이 많은 셀입니다.


6. 사업부서 사용 효과

앞에서는 이 도구를 어떻게 만들었는지를 다뤘습니다. 이제 이렇게 다루기 손 쉬워진 유동인구 데이터가 실제 옥외광고산업 현장에서 어떤 가치있는 도구가 되는지를 이야기해보겠습니다.


옥외광고의 효과 측정

다양한 길거리와, 교통수단들에서 우리의 눈을 사로잡는 전광판과 포스터들처럼 실외에서 접할 수 있는 광고들을 옥외광고라고 합니다. 옥외광고는 실제로 얼마나 많은 사람들이 지나가면서 보았는지가 중요합니다. 24시간 내내 지나가는 사람 수를 세고 있을 수는 없으니, 광고 효과를 측정하고 수치화 하는데 현실적인 어려움이 크기 때문에, 클릭 수와 접속자수를 셀 수 있는 디지털 광고들에 비해서 최근 수년 간 열위에 있어 왔습니다.


데이터 기반 의사결정의 시대에, 성과를 숫자로 확인할 수 있는지 여부는 광고비를 집행하는 광고주 입장에서 매우 중요한 문제입니다. 그렇기에 ‘옥외광고 효과측정’은 오랜 기간동안 해결되어야만 하는 난제로 남아있었고, 그 해답 중 하나가 바로  “유동인구 데이터” 였습니다. KT가 구축한 통신신호 기반 유동인구 데이터는, 오프라인 환경에서도 광고 노출 기회의 수(OTS, Opportunity To See)를 측정할 수 있게 만들어 옥외광고산업의 발전을 이끈 주인공이었습니다.


OOH CELL FLOW는 간단한 채팅만으로 이 유동인구 분석을 실행하고, 옥외광고의 효과를 판단하는 데 필요한 주요 지표 수치를 제공합니다. 이를 통해서 저희는 광화문의 랜드마크인 KT Square를 비롯해 여러 지역에 위치한 KT 주요 광고매체의 성과를 빠르게 분석하고, 서로 비교할 수 있게 되었습니다.


화면 캡처 2026-07-16 081943.png

3만명에 가까운 사람들이 모인 2026 북중미월드컵 남아공전 거리응원


빠르고 정확한 유동인구 분석이 가장 간절한 순간은 역시 대형 이벤트들이 있을 때입니다. 올해만 해도 3월의 BTS 공연부터, 6월의 월드컵 거리응원까지 수만 명이 모이는 다양한 이벤트들이 광화문 광장에서 진행되었는데요. 얼마나 성공적으로 마무리되었는지 행사의 규모를 가늠하기 위해서, 행사 주체부터 서울시를 비롯한 관공서와 언론사들까지 모두가 얼마나 많은 사람들이 모였는지 파악되기를 목빠지게 기다리며 궁금해합니다. KT 광고사업담당은 OOH CELL FLOW 를 통해서 빠르면 이틀 안에도 해당 대형 이벤트의 방문 인원은 물론 시간대별, 성연령별 특성 통계까지 확인할 수 있습니다. 한시가 급한 이 속도전의 타이밍에, 누구보다도 빠른 정보력을 갖고있는 것이죠.


신규 옥외광고매체 개발

한국의 옥외광고산업 시장은 최근 5년간 연평균 10.7% 성장률(「2025 옥외광고통계」기준)을 기록하며 주목받고 있습니다. 시장이 커지면서 새로운 사업 기회도 함께 열리고 있고, 그만큼 여러 후보지 중에서 실제로 광고효과와 인기가 높을 만한 입지를 가려내는 일이 중요해졌습니다. OOH CELL FLOW 를 통한 유동인구 분석은 이렇게 새로운 광고매체를 설치하기에 적합한 입지를 찾을 때에도 유용하게 쓰입니다. 유동인구가 많고, 또 성장세에 있는 지역이 바로 옥외광고매체를 설치하기에 최고의 입지이기 때문입니다.

11.jpg

구의역 이스트폴 파노라마 설치를 위한 입지 분석 사례


기존에는 주로 일시적인 경험이나 직감에만 의존하여 입지 가치를 판단하였으나, 이제는 유동인구 통계를 활용한 입지 분석을 통해서 실제로 어느 곳에 사람들이 많을지 정확한 수치 데이터를 통해서 수익성을 분석하여 의사결정하고 있습니다. 더 나아가 성별·연령 인구통계를 통해서 해당 매체가 어떤 광고주들에게 수요가 있을지 예측하고, 또 검증하는데도 활용하고 있습니다. 신규 매체 후보지의 유동인구 분석은 사실 사업부서에서 데이터분석부서에게 가장 빈번하게 요청드리던 분석요청 사항이었고, OOH CELL FLOW가 만들어지게 된 가장 중요한 배경이었다고 볼 수 있습니다.



광고타깃팅 지원

광고 캠페인의 목표는 한정된 예산 안에서 원하는 타깃에게 최대한 효과적으로 도달하는 것입니다. 그래서 많은 광고주들은 어떤 매체를 선택하는 것이 가장 효율적일지를 고민하고, 그 결정을 뒷받침할 객관적인 근거를 원합니다. 이 때 OOH CELL FLOW에 “강남, 판교, 광화문 중 3040 남성 유동인구가 가장 많은 지역을 분석해줘”와 같은 질문을 해본다면, 고민 중인 광고 캠페인에 적합한 최적의 매체와 집행근거가 될 객관적인 수치를 얻어내어 광고주에게 제안할 수 있습니다.


더불어 전국 천여 개 편의점 매장에 설치된 ‘편의점 탑뷰(계산대 위 광고판)’나 아파트·오피스 등 생활권 매체인 ‘타운보드(엘리베이터내 테블릿형 광고판)’처럼 매체 수가 많은 경우에는 OOH CELL FLOW의 장점이 더욱 분명해집니다. 성별·연령 등 주요 방문자 특성을 조회하여 매장을 ‘2030 카페러버족 특화 매체’, ‘2030 청년집중구역 매체’ 등 카테고리별로 매체를 분류할 수 있고, 이렇게 분류된 결과는 광고주에게 더 효과적인 매체 패키지를 구성하고 제안하는 데 활용됩니다. 추가로 올해 하반기 리뉴얼하여 오픈 예정인 ‘KT 바로광고’ 플랫폼에서는 이러한 광고 타깃팅에 맞는 매체 추천 기능을 광고주들이 직접 이용 가능하도록 기능적으로 구현될 예정이니 많은 관심 부탁드립니다.

12.jpg

리뉴얼 오픈 예정인 바로광고 사이트의 광고매체 추천기능 예시


7. 마치며

이번 작업은 Genie를 붙인 것이 아니라, 비개발자가 데이터를 직접 쓰게 만드는 하나의 방식을 만든 과정이었습니다.

  • 원천테이블을 그대로 열지 않고 정리된 창구(서빙 뷰)를 한 겹

  • 비개발자의 말(위경도, 이름)을 데이터로 옮기는 커스텀 함수

  • 사람의 말을 어떤 데이터로 보낼지 정한 시스템 프롬프트


이 세 겹은 유동인구가 아닌 다른 데이터에도 그대로 적용할 수 있는 방식입니다. Genie Space라는 플랫폼이 받쳐 주니, 우리는 사용자가 실제로 쓸 수 있게 만드는 데 집중할 수 있었습니다.


만드는 사람에게도, 쓰는 사람에게도

돌아보면 Genie Space를 택한 이유는 양쪽 모두에게 편했기 때문입니다.


챗봇을 만드는 개발자에게는, 자연어를 SQL로 바꾸는 엔진도 대화 화면도 직접 개발할 필요가 없었습니다. 서빙 뷰와 함수, 지침만 얹었고 챗봇 본체는 Genie가 제공합니다. 덕분에 데이터를 잘 쓰게 만드는 설계에만 집중할 수 있었습니다.


챗봇을 쓰는 사업담당자에게는, SQL도 좌표도 배울 필요 없이 평소 말로 물으면 됩니다.


개발 부담은 낮추고 사용 문턱도 낮춘 것, 이것이 Genie Space를 택한 이유였습니다.


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


전수연,송찬영,김성수

전수연 : 광고 관련 미디어데이터 분석

송찬영 : 클라우드 빅데이터 플랫폼 아키텍처 설계 및 운영

김성수 : 옥외광고 매체 선정 및 광고효과 리포트 발행