대용량 트래픽을 소화하는 에이닷 전화, 통화요약, 문자 서비스를지난 2년 동안 개발/배포하며 무수히 많은 API 들의 생성과 변경이 있어왔습니다."인터페이스" 는 하나의 약속임에 따라이를 관리하는데 적지 않은 리소스가 들어가는 것을 공감하실 거라 생각합니다.• None 협업 및 관련 부서와의 소통, 히스토리 등등저 역시 아직도 번번이 이러한 이슈를 겪고 있습니다만적어도 담당하고 있는 서비스들 내에서라도 이러한 이슈를 해결하고자를 모토로, API 명세 & SDK 용 프로젝트를 개발했고지난 2년 동안 개발/운영해온 후기를 적고자합니다.이 중에 하나는 공감되실까요서버 개발자 A 와 클라이언트 개발자 B 의 사례로 문제점들을 설명드리려고 합니다.일단 코드 나가고 명세는 좀 이따 작업할게요개발자 A 가 출근한 어느 날, 급하게 연락이 와 새로운 요구사항을 전달받았습니다.일단 코드는 수정하고 명세는 나중에 변경하면 되지라고 생각하며, 명세 변경을 미루었습니다.그리고 그새 버그가 발생해 대응을 하는 동안, 명세 최신화를 까먹습니다.이제 연동하려는 다른 개발자 B 는 명세에 나와있는 대로 구현을 해도 실패가 납니다.이전에도 이런 경험이 있어, 더이상 명세를 신뢰할 수 없게 되었습니다.명세대로 동작하지 않아 매번 확인을 위해 메신저를 보내보지만, 개발자 A 는 바빠서 답장 확인이 느립니다연동이 성공할 때까지 커뮤니케이션 리소스가 더 들어가겠네요.개발자 B는 드디어 연동을 위한 올바른 API 명세를 확인했습니다.이제 코드로 구현을 해볼텐데요이럴수가! JSON 객체 필드가 10개가 넘는데, Nested JSON 도 있습니다!한 땀 한 땀 데이터 모델 클래스로 변환하다가 오타가 났는데,실제로 연동을 시도하기 전까지 어떤 부분을 실수했는지 확인도 어렵습니다.클라이언트 종류가 다양해, Android, iOS (Swift), Flutter, Javascript 코드로 각각 이를 반복합니다.시간이 흘러 개발자 B는 기존 API 를 업데이트하고자, 담당자인 개발자 A에게 연락을 했습니다.새로운 API 버젼이 많이 나와있는데, 현재 몇 버젼까지 배포가 되어있는지 묻습니다.그런데 개발자 A가 휴가를 가있어 대무를 맡은 다른 담당자는현재 배포되어있는 서버는 어떤 버젼의 명세를 구현하고 있는지 모른다고 합니다.이 후 개발자 B 는 개발자 A 가 휴가에서 복귀했다는 소식을 듣고 다시 연락을 했습니다.기존 버젼과 신규 버젼의 변경점이 많은데, 어떤게 변경되었는지 질문을 합니다.개발자 A는 시간이 많이 지나 잘 기억이 안나니, 직접 보고 비교해서 보라고 합니다.새로 추가된 필드들이 너무 많아 실수할 것만 같습니다.문제 1과 2의 원인은 명확합니다."명세를 수정하는 작업"과 "코드를 작성하는 작업"이 분리되어 있기 때문입니다.이 작업을 하나로 합쳐로 만든다면 해결할 수 있습니다.이를 가능하게 해주는 오픈소스가 바로 OpenAPI Generator 입니다.사실 개발자 분이시라면 이러한 Concept 을OpenAPI Generator 보다 protobuf 를 사용하는 gRPC 를 통해 미리 알고 계실 수도 있으실텐데요.인터페이스 명세를 원하는 프로그래밍 언어의 코드 파일로 생성해주는 오픈소스입니다.아직 지원하지 않는 기능이 좀 있지만, 이를 감안하더라도 생산성이 극대화되기 떄문에사용할 이점이 훨씬 더 크다고 판단했습니다.참고로, 팀 내 메인 Tech Stack 이 Kotlin, Gradle 프로젝트인 관계로이 오픈소스를 Gradle Plugin 으로 포팅한 플러그인 방식으로 프로젝트에 적용하였습니다.(문제 3은 후술) 문제 4는 이미 익숙한 문제라고 생각합니다.Version Control System, Git 을 통해 해결할 수 있는 문제입니다.버져닝이 되는 Wiki 도 방법이겠지만, OpenAPI 명세 파일은 일반적인 자연어가 아닌, Yaml /JSON 포맷이고API 관리 주체인 개발자가 관리하는 측면에서, 개발자에게 친숙한 Git 이 더 좋은 해결책이라고 생각합니다.API 명세의 변경과 히스토리를 커밋과 PR/MR, 코멘트 등을 통해 관리하도록 Git 프로젝트로 만들었습니다.명세 파일은 근본적으로 Yaml 혹은 JSON 포맷입니다.이를 잘 렌더링된 UI 로 보아야 비로소 가독성이라는 진가가 발휘된다고 생각합니다. (예쁜 UI는 마음이 편해지죠)UI 로 제공하는 방법들은 여러 가지 있는데요, 직접 Web UI 서버(Swagger UI, Redoc 등)를 구축해도 되지만,Gitlab 에서 자체 제공하는 OpenAPI 렌더링 기능을 이용할 수도 있습니다.저는 CI 를 통해 이러한 prefix 가 자동으로 들어가게끔 강제하였습니다.이렇게 브라우저, Gitlab UI 를 통해 볼 수 있게 됨에 따라API 명세를 공유하는 방법 역시 Git Repository 의 코드 파일 URL 을 공유하기만 하면 됩니다.따라서 자동으로 Git 에 접근할 수 있는 권한을 가진 사람만 볼 수 있도록, 인증 및 인가도 처리되구요.추가로 위에서 설명드린 OpenAPI Generator 로 생성된 코드 파일을 사용하는 방법도Gitlab 을 통해 손쉽게 이용할 수 있습니다.바로 Gitlab Package Registry 에 코드 파일을 빌드해서 배포하면, SDK/Library 처럼 pull 받아서 이용하는 방식입니다.Maven 과 같이 Public Registry 가 아닌 Private Registry 를 이용하려면, SaaS 를 사용하거나 직접 On-premise 로 구축해야할텐데요Github 뿐만 아니라 Gitlab Server 에서도 이를 지원하고 있어, 별도 구축 비용 없이 전사 시스템을 이용할 수 있었습니다.SDK/Library 를 publish 하는 작업도 maven-publish Gradle plugin 를 통해, 손쉽게 코드로 설정할 수 있었는데요.Publish 간에는 버젼값을 설정할 수 있으므로, 명세의 버젼을 그대로 이용하여 SDK 버젼으로 배포하였습니다.이를 통해 SDK 를 pull 받아 사용하는 Application 프로젝트에서는,의존성 관리 (ex. build.gradle.kts) 파일에서 특정 버젼을 명확하게 명시하게 되고

TV를 켜는 순간, 우리는 수많은 질문과 마주하게 됩니다.“지금 화면에 나오는 저 배우 어디서 많이 봤는데… 누구더라?”,“이런 줄거리의 영화 제목이 뭐더라?“콘텐츠를 소비하는 과정 자체가 이미 수많은 궁금증으로 가득 차게 됩니다.그런데 만약 나의 취향과 감정,지금 보고 있는 장면의 분위기와 등장인물, 줄거리까지 파악하고그 모든 맥락을 반영하여 추천까지 해주는 나만의 AI 미디어 친구가 있다면 어떨까요?B tv는 작년 10월, 국내 최초로 대화형 미디어 에이전트 서비스를 선보이며‘보는 TV’를 넘어 ‘소통하는 TV’로의 전환을 시작했습니다.그리고 지금, B tv는 나를 기억하고 이해하는 AI 미디어 친구로의 진화를 시도하고 있으며,그 중심에는 대화형 AI 플랫폼 에이닷이 자리하고 있습니다.이러한 진화를 위한 첫 걸음으로, 2025년 상반기에는 IPTV 3사 최초로 AI 플랫폼 에이닷과의 회원 연동을 통해사용자 개인화를 위한 첫 기반을 마련했습니다.이 글에서는 이 연동된 프로필 정보를 바탕으로,에이닷과 함께하는 B tv가 어떻게 나를 알아보고, 기억함으로써 ‘콘텐츠 플랫폼’을 넘어 ‘AI 미디어 파트너’로 진화 할 예정인지,그리고 에이닷-B tv가 실제 일상 속에서 어떻게 작동할 것이고, 어떤 가능성을 열어갈지 그 방향성과 비전을 소개하고자 합니다.첫번째 방향성, 나를 이해하는 대화 – 나를 알아보는 것부터B tv는 오랫동안 가족이 함께 사용하는 서비스로 자리 잡아 왔습니다.여러 사람이 하나의 프로필을 공유하며 이용하는 모습이 익숙한 풍경이었죠.하지만 최근 1년간의 사용 데이터를 살펴본 결과, 전체 사용자 중 약 30%가 개인 프로필을 직접 생성해 사용하는 것으로 나타났습니다.TV 안에서도 나만을 위한 경험을 바라는 니즈가 점점 뚜렷해지고 있는 겁니다.이러한 흐름에 발맞춰, B tv는 기존의 개인 프로필에에이닷의 회원 정보를 연동하며 더 깊이 있는 개인화의 기반을 갖추기 시작했습니다.단순히 TV 안의 데이터를 넘어서,에이닷과의 연동을 통해 사용자의 일상과 일정, 감정을 이해하고 반영하는더 정교하고 입체적인 개인화 대화를 실현할 수 있는 기반을 갖춘 것입니다.나만의 이름으로 시작되는 대화, 내 이름을 부르는 TV현재 B tv 에이닷에서는 아래 이미지 예시와 같이 하나의 TV에 최대 4개의 에이닷 프로필을 연동할 수 있으며,사용자를 구분해 이름을 불러주고, 나만을 위한 대화를 시작합니다.이는 단순한 계정 구분을 넘어, TV가 나를 개인으로 인식하고 대화를 시작한다는 점에서 사용자 경험에 큰 전환을 예고합니다.목소리로 나를 알아보는 TVB tv는 2023년, 휴대폰의 Wi-Fi 및 Bluetooth 신호를 활용한모바일 기반 사용자 자동 인식 기능(Auto Detection) 을 도입하며사용자별 맞춤 환경 제공의 기반을 다져왔습니다.그리고 이제 그 다음을 준비 중입니다.TV가 직접 목소리를 듣고 ‘누가 말했는지’를 구분하는 기술,이를 통해, 같은 질문이라도누가 말했느냐에 따라 TV의 설정과 응답이 달라지게 됩니다.사용자의 목소리를 인식하여 각자에게 맞는 콘텐츠, 기능, 말투까지 자동으로 구성되는 거죠.이처럼 B tv는 목소리만으로 누구인지를 알아보고,각자의 취향과 시청 히스토리를 반영한 ‘맞춤 환경’을 능동적으로 구성해주는 방향으로 진화하고 있습니다.앞으로는 리모컨을 일일이 조작하거나, 기억을 되짚으며 정확히 말하려 애쓸 필요가 없습니다.TV가 내가 누구인지, 무엇을 좋아하는지 이미 알고 기억하고 있기 때문에,그저 생각나는 대로 말만 하면 나를 위한 반응이 자연스럽게 이어지는 새로운 대화 경험의 시대가 열리는 것입니다.이처럼 앞으로 B tv가 사용자를 인식하게 되면,단순한 구분을 넘어 어떤 개인화 경험들이 가능해질까요?‘나’를 알아보는 B tv가 어떻게 나만을 위한 미디어 메이트로 진화해 나갈지, 함께 살펴보겠습니다.두 번째 방향성, 지극히 개인적인 – 나만의 TV, 나와의 TV, 에이닷B tv 에이닷이 사용자 개인을 구분할 수 있게 되면서,이제는 단순히 나를 인식하는 것을 넘어‘나에게 맞는 대화’와 ‘나만을 위한 콘텐츠’로 연결되는 개인화 경험이 본격적으로 시작됩니다.우리는 먼저 “사용자들은 어떤 개인화 경험을 원할까?”라는 질문에서 출발했습니다.그리고 실제 사용자 발화 로그를 하나하나 살펴보며“내가 좋아하는 채널만 틀어줘”, “선호하는 채널만 보고 싶어”와 같은 요청이생각보다 자주 등장하고 있다는 점을 발견했습니다.이러한 사용자 니즈를 반영하여, Btv는 정교하게 학습된 사용자의 선호와 성향을 기반으로 맞춤형 콘텐츠 콜렉션 추천을 제공할 예정입니다.이제는 말 한마디면 나만을 위한 큐레이션이 눈앞에 펼쳐지는 시대가 오는 겁니다.예를 들어 TV에서 보고 싶지 않은 채널이 나올 때,굳이 리모컨을 조작하지 않아도 “내가 좋아하는 채널 틀어줘”라고 말하면,Voice ID 기반으로 프로필이 자동으로 전환되고나의 선호 채널만 골라 보여주는 방식으로 더욱 편리한 시청 환경이 제공되는 겁니다.그때그때 궁금한 걸, 맥락까지 읽고 응답하는 – 콘텐츠 맥락 기반 실시간 응답 기능또한 에이닷은 단순한 질의응답을 넘어,콘텐츠를 보는 순간 떠오르는 다양한 궁금증에 실시간으로 반응하고,그때그때의 맥락과 사용자 정보를 고려해 더 정교하고 자연스러운 추천을 이어가는 기능을 준비중입니다.“이거 너무 잔인하지 않아?”, “이 배우 어디서 봤지?”와 같은 질문에사용자의 과거 시청 이력과 성향, 발화 문맥을 고려해더욱 자연스럽고 정교하게 응답하는 기능을 제공하게 될 것입니다.이처럼 Btv 에이닷은 단순한 VOD 추천을 넘어,콘텐츠 시청 중 떠오르는 궁금증에 실시간으로 응답하고,개인의 성향과 상황을 바탕으로 콘텐츠 경험을 확장하는 방향으로 진화해 나가고 있습니다.언젠가 우리는 이렇게 자연스럽게 이야기할 수 있을 겁니다.• None “에이닷, 이 장면 너무 진부하지 않아? 어제 그 반전 맛집 영화가 훨씬 짜릿했잖아.”• None 에이닷: "어제 보신 〈기묘한 전개〉는 확실히 긴장감 넘쳤죠. 비슷한 스타일의 추천작을 준비해둘게요!"세 번째 방향성, 말하기 전에 알아서 – 나를 알고 먼저 말을 거는 TV항상 대답만 하는

29분 이상 걸리던 CS 처리를 2.9분으로 줄이다안녕하세요 29CM 세일프라이싱팀의 백엔드 개발자 김도영(Dorie)입니다.저희 팀은 고객에게 정확하고 매력적인 가격 경험을 제공하기 위해상품 등록부터 노출, 할인, 쿠폰, 결제 혜택에 이르는 전 과정의 가격 전략과 시스템 운영을 담당하고 있습니다.그 과정에서 내부 운영팀의 요청으로 상품 설정 변경이나 이관 처리 등 개발자가 직접 수동으로 대응해야 하는 CS 업무 가 반복적으로 발생하곤 합니다.오늘은 이러한 CS 업무를 LangChain 기반 AI로 자동화한 사례를 공유드리려 합니다.CS 업무로 인한 개발 생산성 병목세일프라이싱팀은 매 스프린트마다 평균 16.45건, 일 기준으로는 평균 약 3건이 넘는 CS 업무를 처리하고 있었습니다. 하나하나 보면 그리 어렵지 않은 단순 요청이지만 문제는 그 수와 반복성이었습니다.CS 요청 예시CS 한 건을 처리하는 데 평균 30분이 걸렸습니다. 이를 환산하면 하루 약 100분, 스프린트(2주) 기준으로는 8시간 이상을 반복적인 CS 작업에 사용한 셈입니다. 심한 경우에는 스프린트당 17시간이 넘기도 했습니다.생산성이 떨어진 개발자개발 리소스가 이런 운영성 업무에 지속적으로 묶이다 보니 기획된 기능 개발이나 시스템 개선에 대한 비중이 점점 줄어들 수밖에 없었습니다.그래서 저희는 반복적인 CS 업무를 대신 생각하고 대신 실행해 줄 수 있는 LangChain 기반의 AI Bot을 만들기로 했습니다.우리 팀의 손을 덜어줄 뿐 아니라 더 빠르고 더 정확하게 대응하는 자동화 흐름을 만드는 게 목표였습니다.왜 LangChain이어야 했을까?처음에는 단순한 RPA(Robotic Process Automation)만으로 해결해 볼 수 있지 않을까 생각했습니다. 하지만 곧 한계에 부딪혔습니다. 정형화된 규칙 기반의 RPA만으로는 비정형 요청의 문맥을 이해하고 적절히 대응하기 어려웠습니다.우리가 필요했던 것은 정해진 규칙의 반복 실행 이 아니라, 문맥을 이해하고 상황에 맞게 판단할 수 있는 지능형 자동화 였습니다.이런 요구에 가장 적합했던 도구가 LangChain이었습니다.LangChain은 GPT나 LLaMA 같은 대형 언어 모델(LLM, Large Language Model)을 애플리케이션에 쉽게 통합하고 구조적으로 개발할 수 있도록 돕는 프레임워크입니다.무엇보다도 LLM을 사용하게 되면서 별도의 모델 학습 없이 사내 위키, 내부 API, 권한 시스템 등과 유연하게 연결할 수 있어 복잡한 시나리오를 빠르게 구현할 수 있었습니다.특히 검색 증강 생성(RAG, Retrieval-Augmented Generation) 기법을 통해 실시간으로 내부 문서를 검색하고, 그 검색 결과를 답변에 반영함으로써 보안·비용·정확도 측면 모두에서 효율적인 구조를 만들 수 있었습니다.LLM을 활용한 LangChain은 Spring 기반 시스템과의 호환성도 뛰어났습니다. 도입 당시 Spring AI보다 훨씬 많은 기업이 이미 사용 중이었고 공식 문서도 체계적이며 실제 사례도 풍부해서 업무에 빠르게 적용 가능하다는 점에서 도입을 결정하게 되었습니다.어떻게 CS 업무 프로세스가 바뀌었을까?LangChain 기반 지능형 자동화가 기존의 업무 프로세스를 어떻게 개선했는지, 도입 이전(As-is)과 이후(To-be)를 비교하여 살펴보겠습니다.기존 프로세스기존에는 다음과 같은 수작업 과정을 거쳐야 했습니다.CS 요청자가 Jira에 티켓을 등록하고 Slack 채널에 공유담당 개발자가 티켓 내용을 확인문맥 파악을 위해 과거 티켓 또는 요청자에게 직접 문의처리 가능한 API나 수동 방법을 탐색해 직접 실행결과를 요청자에게 전달하고 요청자가 확인 후 종료이 일련의 흐름에는 평균 30분 이상이 소요되었으며 요청이 몰리는 경우엔 더 지연되고, 담당 개발자의 피로도도 심각해졌습니다. 이는 곧 핵심 기능 개발 일정에 영향을 주는 병목으로 작용했습니다.자동화 후 프로세스변화는 매우 직관적입니다.사용자가 Slack을 통해 자연어로 CS 요청을 전달하면 29CM-AI-BOT이 적절한 문서를 참조하여 실행 가능 여부를 판단하고 승인하면 사용자 확인을 거쳐 API를 실행합니다.전체 프로세스는 3분 이내로 끝나고 담당 개발자는 더 이상 CS에 소모되지 않고 고도화된 업무에 집중할 수 있습니다.어떻게 작동하는가  1. 사용자 요청 수신AI Bot에 100번 상품을 8547번 브랜드로 이관해 줘 라는 요청이 들어오면,Slack 멘션 이벤트를 수신한 AI Bot 서버는 우선 해당 요청의 내용을 분석합니다.2. 시나리오 판별 및 선택이후 분석 결과가 상품 정보 변경 유형에 해당함을 판단하고, 이에 따라 상품 정보 변경 시나리오 를 선택합니다.3. 내부 문서 검색선택된 시나리오에 따라 LangChain 기반 RAG 검색을 수행해 Confluence에 등록된 내부 API 문서 중 상품 브랜드 이관 API 문서를 탐색합니다.4. LLM을 통한 파라미터 추론LLM은 요청 내용에서 API 실행에 필요한 파라미터를 추론합니다.5. 실행 전 승인 절차이후 실질적인 API 호출 전에 사용자 승인 단계를 거칩니다. AI Bot은 다음과 같은 정보를 요청자에게 사전 제공하며 확인을 요청합니다.추출된 API 설명추론된 파라미터예상 실행 결과6. API 실행 및 결과 응답요청자가 승인 버튼을 클릭하면, AI Bot은 해당 API를 실제로 실행하고 그 결과를 요청자에게 다시 응답합니다.7. 자동화의 신뢰성과 안정성 확보이러한 구조는 사람이 직접 SQL이나 API를 찾고 실행하던 과정을 LLM과 RAG로 대체하면서도 승인 기반 가드레일을 통해 자동화의 신뢰성과 안전성을 확보합니다.품질·보안 가드레일자동화의 궁극적인 목적은 업무 효율을 높이는 것이지만, 우리가 그보다 더 중요하게 본 가치는 정확성과 신뢰성 이었습니다.사람이 아닌 봇이 실수한다면?잘못 변경한 AI Bot예를 들어 누군가가 A로 변경해줘 라고 요청했는데, AI가 잘못 이해하고 B로 변경해버린다면 이건 단순한 실수가 아니라 데이터 손상 또는 정책 위반이 될 수 있습니다. 해결책 1: 사용자 승인 기반의 안전 장치승인/반려 과정이에

CTO가 직접 만든 온디맨드 서비스의 탄생기2025년 초, 마이리얼트립은 새로운 도전에 나섰습니다. 이름하여 “온디맨드 현지도우미”. 여행자가 낯선 도시에서 실시간으로 가이드를 호출하고, 근처에 있는 현지인이 도우미로 연결되어 여행을 도와주는, 말 그대로 ‘여행판 우버’ 같은 서비스입니다. 우리나라는 물론 세계적으로도 최초로 시도하는 혁신적인 서비스라고 할 수 있죠.그런데 문제는 개발 리소스였습니다. 당장 여기에 전담할 수 있는 개발자가 없었죠. 예전 같았으면 인력을 채용하거나, 우선순위를 조정해 프로젝트를 미뤘을 겁니다.하지만 이번엔 다르게 접근했습니다.“내가 직접 개발해보자.”제가 마이리얼트립에 합류한 이후 실무 개발은 거의 4년 만이었습니다. 그동안은 조직과 구조, 기술 방향을 잡는 역할에 집중해 왔죠. 그런데도 직접 개발에 나선 이유는 단순히 리소스를 채우기 위함만은 아니었습니다.AI 시대, 개발자의 역할이 어떻게 변하고 있는지 몸소 체험해보고 싶었기 때문입니다.프로토타입부터 시작된 AI 도구와의 협업디자이너가 그려준 UX 플로우를 기준으로 웹 기반 프로토타이핑을 시작했습니다. 백엔드는 그래도 익숙했지만, 클라이언트 개발은 정말 막막했습니다. 제가 알던 웹 개발은 프리마커(Freemarker) 수준이었고, React나 Next.js는 사실상 처음이었습니다.이때부터 AI 개발툴인 Cursor의 도움을 받기 시작했습니다. 프로젝트 세팅부터 로그인 페이지, 지도 API 연동까지 — 커서는 마치 옆에서 함께 일해주는 페어 개발자 같았습니다. 디자이너가 작성한 피그마에서 html 소스를 받은 다음 “Next.js로 로그인 페이지를 만들고 아래 html 코드 형태로 스타일링해줘”라고 말하면, 금세 코드와 설명이 눈앞에 펼쳐졌습니다.가장 인상 깊었던 건 지도 기능이었습니다. 구글 맵을 모바일 웹에 최적화된 형태로 띄우고 마커를 찍는 일은 저에겐 꽤 까다롭게 느껴졌던 작업인데, AI에게 설명하자 마치 마법처럼 구현됐습니다. 이 과정을 통해 “아, 웹 개발도 내가 해볼 수 있겠구나”라는 자신감을 얻었죠.물론 AI가 완벽한 건 아니었습니다. 종종 의도와 다른 코드를 제시하거나, 문맥을 놓치고 엉뚱한 방향으로 나아가기도 했습니다. 하지만 그 과정에서 저는 중요한 교훈을 얻었습니다.AI를 제대로 활용하려면, 명확한 질문을 던지고, 기술에 대한 기본 이해가 있어야 한다는 것.이렇게 완성한 프로토타입은 내부 경영진에게 긍정적인 반응을 얻었고, 우리는 이 프로젝트에 본격적으로 투자하기로 결정했습니다.프로토타이핑 당시의 프로젝트 구조. backend/frontend 모듈로만 이뤄졌지만 저에게 frontend 모듈은 새로움의 연속이었습니다.작은 팀, 빠른 실행, 그리고 다시 AI팀은 정말 작았습니다. 저(BE), 디자이너, iOS 개발자, Android 개발자. 단 네 명.PM도 없었고, 사업개발 인력도 없었습니다. 오히려 그 덕분에 모든 구성원이 제품의 본질에 집중하며 빠르게 실행할 수 있었습니다.하지만 본격적인 개발이 시작되자, 프로토타입 단계에서 겪지 않

얼마 전에 충격적인 사실을 알았습니다. 지난 기고에 참고했던 문서가 번역본을 제공하더라고요.알고보니 제가 애써서 번역할 필요가 없었습니다. 코드를 이해하는데 꼭 필요한 기반 지식을 설명하는데 큰 의의가 있기는 했지만요.이번에는 라이팅(Lighting)와 머티리얼(Material)에 대해 다루려고 합니다.컴퓨터 그래픽스에서 어떤 물체를 사실적으로 표현하기 위해서는 라이트와 머터리얼, 이 두 가지가 꼭 필요합니다.지난 편에서 회전하는 초록색 박스가 사실적으로 표현되지 않았는데요. 두 가지를 추가해서 우리에게 익숙한 화면으로 연출해 보겠습니다.라이팅에 대해 어디까지 다루어야 할지 고민이 되었습니다.보다 사실적으로 물체를 표현하기 위해서 아주 기본적인 물리적인 요소에서부터 점차 연산량과 고려 사항을 늘려나가 결국 쉐이터와 GPU를 탄생시키는데 일조했기 때문입니다.여기에서는 WebGL을 활용하여 기본적인 어플리케이션을 만드는데 필요한 수준까지만 설명하고, 이론적으로 알아두면 좋은 것 같은 부분은 문서 마지막에 레퍼런스로 소개하도록 하겠습니다.기본적으로 라이팅의 종류를 설명할 때는 광원(Light source)으로 분류합니다. 광원은 빛을 방출하는 지점 또는 영역을 의미합니다.다양한 종류의 광원이 있으며, 각각 고유의 특성을 가지고 있습니다.• None 방향광(Directional Light): 빛이 일정한 방향으로 평행하게 쏟아지는 광원으로, 태양광과 비슷합니다. 아주 먼 곳에서 다량의 광선이 쏟아져 온다고 가정하는 것으로, 빛의 방향은 모두 평행합니다. 방향광이 중요한 이유는 우리 실생활에서 느끼는 자연광과 매우 유사한 결과를 만들어주며, 마찬가지로 직관적으로 이해할 수 있는 그림자를 생성하기 때문입니다.• None 점광원(Point Light): 특정 지점에서 모든 방향으로 빛을 방출하는 광원입니다. 전구와 같은 방식으로 빛이 퍼집니다. 빛의 세기는 광원으로부터 거리와 비례합니다. 다음의 예제를 통해 쉽게 이해할 수 있습니다.• None 스포트라이트(Spotlight): 특정 방향으로만 빛이 집중되도록 방출되는 광원입니다. 손전등처럼 빛의 범위가 제한됩니다. 광원으로부터 콘(cone) 모양으로 방출됩니다.• None 환경광(Ambient Light): 장면 전체에 고르게 퍼진 빛으로, 특정한 광원에서 오는 것이 아닌 전체적인 분위기를 조성하는 데 사용됩니다. 모든 물체의 표면에 동일하게 작용합니다.하나의 장면(scene)에 하나의 조명(light)만 사용하는 것은 아닙니다.연출하고자 하는 장면에 따라 여러개의 다양한 조명을 쓰기도 하는데요.지난 시간에 사용했던 예제에 다음의 코드를 추가해 주겠습니다.DirectionalLight의 파라미터는 빛의 색상과 강도입니다. 이후에 3차원 좌표로 위치를 설정해줬고요.무엇이 바뀌었나요? 아무것도 바뀌지 않았습니다. 이제 머티리얼을 배울 차례입니다.머티리얼(Material; 재질)은 어떠한 물체의 외관을 묘사하는 다양한 속성들을 말합니다.금속은 빛을 잘 반사하기 때문에 반짝거리는 특성이 있습니다. 반면 마른 흙이나 고무 등은 금속보다 빛을 덜 반사합니다.옷감 중에서도 면과 벨벳은 명확하게 구분되는 시각적 차이를 가지고 있습니다.컴퓨터 그래픽스는 물체의 색상, 질감, 형태, 빛의 반사 등의 다양한 특성을 조합하여 시각적으로 표현하고자 하며, 이러한 특성들의 조합을 머티리얼이라고 지칭하는 것입니다.Three.js 라이브러리에서 자주 사용하는 대표적인 몇 가지 Material을 다루어 보겠습니다.아래로 갈수록 더 많은 계산 비용이 필요하며, 더 사실적으로 표현할 수 있습니다.반사율을 계산하기 위해 Lamberial 모델을 사용합니다.이 모델은 광택(specular highlights)에 대한 고려가 되어 있지 않기 때문에 나무나 돌과 같은 표면은 잘 표현할 수 있지만, 금속이나 반짝이는 재질을 표현하기는 어렵습니다.하지만 빠르게 동작하고 고유의 색을 표현하는데에는 부족함이 없기 때문에 활용할 부분이 많아요.비물리 기반의 Blinn-Phong 모델을 사용합니다. Lambertian 모델과는 달리 반사되는 광택을 더 잘 표현할 수 있습니다.Unity, Unreal 등에서 자주 사용하고 3D Max, Maya등의 그래픽스 스탠다드 도구에서도 프로 레벨에서 많이 사용하는 모델입니다.물리 기반 렌더링(PBR; Physically based rendering) 기법의 일부를 사용합니다. 물리 기반 렌더링이란 빛을 물리적, 수치적으로 모델링하여 정확하게 계산해보자는 접근 방법입니다.다른 기법들보다 더 사실적이고 정확한 표현이 가능하지만 계산량이 아주 많다는 단점이 있습니다.예전에는 영화 쪽에서나 사용할 수 있던 기법인데 최근 GPU의 등장으로 실시간 계산 성능이 좋아지면서 게임이나 Web 쪽으로 적용되고 있는 추세입니다.Standard material의 확장판으로, 더 다양한 속성의 물리 기반 렌더링을 지원합니다. 더 많은 계산 비용을 사용하지만, 활용하기에 따라서 더 사실적인 결과를 연출할 수 있습니다.머티리얼 몇 개를 사용해보고 차이점을 눈으로 확인해보도록 하지요. 우리의 cube를 MeshLambertMaterial로 바꾸어 보겠습니다.실행해보니 뭔가 이상합니다. 이제 큐브가 3차원인 느낌이 나는 것 같긴 한데 자꾸 중간에 사라집니다.이유는 이렇습니다. 우리는 윗쪽에 directional light를 설정했고, 그 조명의 빛을 받는 면만 화면에 그려지고 있는 것입니다.실생활에서는 조명과 떨어져 있더라도 환경에 의해 반사되는 빛들로 다른 부분도 표현이 되지만, 그래픽스의 세상에서는 반사되는 빛을 표현하려면 이것 역시 계산해 줘야 합니다.그렇다면 간단하게 극복할 수 있는 방법은 무엇일까요? 위에서 언급한 ambient light를 이럴 때 사용합니다.이 공간에는 “기본적으로 반사되는 빛이 있어”라고 설정해버리는 것이죠. Directional light 다음에 아래의 코드를 추가합니다.AmbientLight의 파라미터는 색상 값과 빛의 강도입니다.이렇게 설정하는게 찜찜할 수도 있습니다. 뭔가 정확한 느낌은 아니잖아요?그러나 계산량을 줄이면서 그럴싸해 보이

1편에 이어서 2편은 IAM 나머지 설정(임시 자격 증명)과 S3 버킷 설정을 진행해 보겠습니다.1편은 아래를 참고해 주세요.장기 자격 증명과는 반대되는 개념.먼저 장기 자격 증명은 보통 app 등에서 aws 리소스 접근시 aws 유저의 acesskey, secretkey를 입력해서 접근하게 되는데 이 acesskey, secretkey 가 유출(github등) 되면 제한없이 aws 리소스 접근이 되기 때문에 보안에 취약하다.임시 자격 증명은 단기로 사용할 수 있는 자격 증명이다.몇분에서 몇시간 까지 지속시간이 정해져 있어서 '임시' 라는 말이 들어간다. 자격 증명이 만료된 이후에는 어떤 종류의 액세스도 허용되지 않는다.장기 자격 증명 보다는 다소 번거로운 작업들이 있지만 대신 보안에 뛰어나다.IAM User(깡통)가 특정 Role의 모자를 써서 마치 권한이 있는 User처럼 되는걸 AssumeRole 이라고 한다.클라이언트(app등)에서 프로그래밍 방식으로 접근할때도 위 Flow대로 개발하여 접근해야 한다.AWS에 접근이 가능하지만, 아무런 권한이 없는 깡통 유저IAM User가 역할로부터 임시 토큰을 얻기 위한 시스템.특정 AWS 리소스 권한을 가지고 있는 역할(S3 라던지 Lambda 등등)아무권한 없는 aws 유저를 먼저 생성한다.(아무것도 설정 안하고 계속 다음 다음... )사용자 생성후에 액세스키를 만든다(클라이언트에서 접속하기 위한)"액세스 키 만들기" 클릭하여 생성 → accesskey / secretkey를 잘 보관하여 사용하는 클라이언트에게 전달만든 유저 클릭 → 권한 추가 → 인라인 정책 생성신뢰할 수 있는 엔티티 유형 → AWS 계정 → 이 계정 선택ARN 확인(ARN 정보를 클라이언트에게 전달해야 한다)임시권한 획득을 위해 클라이언트에게 제공할 데이터버킷 이름은 {환경}-ifland-s3-mediaconvert 로 생성• None 임의의 ACL(액세스 제어 목록)을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단• None 새 퍼블릭 버킷 또는 액세스 지점 정책을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단• None 임의의 퍼블릭 버킷 또는 액세스 지점 정책을 통해 부여된 버킷 및 객체에 대한 퍼블릭 및 교차 계정 액세스 차단 "새 ACL(액세스 제어 목록)을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단" 까지 체크시, mediaConvert에서 S3 접근시 Access denied 오류가 발생. 버킷 정책에 Cloud Front 생성시 같이 생성한 OAC 정책을 복붙해줌.위 설정을 하지 않으면 mediaConvert에서 S3 접근시 ACL 오류 발생.CORS(Cross-Origin 리소스 공유) 섹션에서 편집을 선택.CORS 구성 텍스트 상자에서 아래 CORS 구성을 복사하여 붙여 넣는다.바쁘다는 핑계로 2편이 좀 늦어졌네요.다음 연재는 더 빠르게 할수 있도록 노력하겠습니다!!!