Homebrew는 macOS를 위한 오픈 소스 패키지 관리자로, 개발자들 사이에서 필수 도구로 자리 잡았습니다.CLI 인터페이스를 통해 다양한 소프트웨어를 쉽게 설치, 업데이트, 관리할 수 있게 해주며, 의존성 문제도 자동으로 해결됩니다.이러한 편의성 덕분에 Homebrew는 macOS 사용자들, 특히 개발자들에게 없어서는 안 될 도구가 되었습니다.이번 글에서는 이전에 소개한 ALN(Amazing Lucky Numbers) 라이브러리를 macOS용 Homebrew 패키지로 만들고, TAP을 통해 bottle로 배포하는 과정을 상세히 다루겠습니다.Formula 작성, bottle 빌드, TAP 저장소 설정, 그리고 최종적으로 사용자들이 쉽게 설치할 수 있도록 패키지를 배포하는 방법까지 단계별로 설명하겠습니다.Homebrew는 맥주 양조에서 영감을 받아 이름이 지어졌으며, 많은 용어들이 맥주 제조 과정과 관련이 있습니다.실제로 명령으로 패키지를 설치할 때 터미널에 맥주 아이콘이 표시됩니다.각 용어에 대해 Homebrew에서의 의미와 맥주 양조에서의 의미를 함께 설명하면 다음과 같습니다.• None• None 가정에서 직접 만드는 수제 맥주• None Brew: 패키지를 설치하거나 관리하는 주요 명령어• None 맥주를 만드는 과정 자체• None• None 맥주 제조를 위한 재료와 방법을 기술한 레시피• None Cellar: Homebrew가 패키지를 설치하는 디렉토리 (기본 위치: Intel mac - /usr/local/Cellar, Apple Silicon Mac - /opt/homebrew/Cellar)• None 맥주를 저장하고 숙성시키는 공간• None• None 맥주를 저장하고 서빙하는 데 사용되는 통• None Tap: 공식 저장소 외에 사용자가 추가하여 사용할 수 있는 Formula 저장소• None 맥주를 따르는 데 사용되는 밸브나 꼭지• None Cask: GUI 애플리케이션을 관리하기 위한 Homebrew의 확장 기능• None 대량의 맥주를 저장하고 운반하는 데 사용되는 큰 통• None Bottle: 미리 컴파일된 패키지 버전으로, 설치 시간을 크게 단축시킴• None 맥주를 담아 판매하거나 보관하는 유리병Homebrew 기반의 패키지를 만들어서 배포하는 과정을 맥주 용어로 다시 설명하면 아래와 같습니다.• None• None 맥주 제조를 위한 재료와 방법을 기술한 레시피(Formula) 작성• None• None 맥주를 제조한 후 유리병(Bottle)에 담아 준비• None Github 저장소를 이용해 Tap 추가 및 패키지 설치• None 맥주 양조장을 통해 맥주를 받아옴(Tap). 병으로 바로 받거나(Bottle) 레시피(Formula)로 직접 제조Apple Silicon Mac 기준으로 Homebrew는 디렉토리를 사용하는데, 세부 디렉토리는 아래와 같습니다.• None (Git 저장소): 이 디렉토리는 Homebrew의 루트 디렉토리이며, 동시에 Git 저장소입니다. 이를 통해 Homebrew 자체의 업데

Frontend 개발자가 아닌데 굳이 해당 분야를 공부해야 할 필요가 있을까요?개인적으로는 불과 몇년전까지 Frontend 분야에 대하여 막연히 Web Site 를 만드는 직군으로서, Backend 나 AI 관련 직무와는 업무적으로 서로 크게 관여할 일이 많지 않을 것이라고 생각했었습니다.또한 제대로 공부해보지는 않았었지만, 굉장히 지루해 보였던 HTML 과 CSS 를 다루며 다른 개발 직군과는 다소 거리가 있는 직군이라는 편견을 가지고 있었습니다.이로 인해, ML/DL 모델링 직군으로 입사했던 상황에서 Frontend 분야는 커리어 관점에서나, 회사에서의 업무 관점에서 크게 접할 계기가 없을 것이라는 판단을 했었습니다.SKT 입사 이후, 담당하고 있는 대부분의 프로젝트가 Frontend 분야와 직간접적으로 연결되어 있다는 것을 깨닫는 데는 긴 시간이 걸리지 않았습니다.단순하게는 속해 있는 프로젝트의 성공이 Web/App 완성도에 따라 좌지우지될 수 있을 정도로 서비스 관점에서 큰 영향력을 가지고 있었고,직접 개발한 ML/DL 기반 모델의 추천 정보가 최종적으로 고객에게 더 효과적으로 전달될 수 있도록 모델 API 및 화면 Spec 을Frontend 개발자분들과 협의하는 과정을 수차례 경험하며 해당 분야에 자연스럽게 관심을 가지기 시작했습니다.또한, 고객에게 직접적으로 노출되는 서비스 화면이 아니더라도,사내 구성원들이 사용하는 크고 작은 Admin Web 은 서비스를 안정적으로 운영해야하는 백오피스 관점에서 빼놓고 생각할 수 없는 요소였습니다.Frontend 분야에 처음 관심이 생긴 이후, 초기에는 Python 기반의 간단한 Library 를 학습하며 업무에 조금씩 적용하기 시작했습니다.전통적인 Web 개발 방식과는 다소 거리가 있었지만, 익숙한 개발 언어를 사용하며 단기간에 원하는 기능을 화면에 적용하는 경험을 하며 한동안 재밌게 이것저것 만들어 봤던 것 같습니다.구체적으로는, Streamlit 이라는 Library 를 사용했고 Frontend 기초 지식 학습을 병행하며,Hydralit 을 통해 GNB (Global Navigation Bar) 기반의 Multi-page 구조를 구현하며 그럴듯해 보이는 Admin Web 을 구축해보기도 했습니다.해당 Admin Web 은 추후 기능이 고도화되며 A. 큐피드 서비스에 활용되는 주요 모델들의 버젼 및 배포 관리에 핵심적으로 활용되었습니다.Streamlit 이나 Gradio 와 같은 Python 기반 Web Library 는 쉽고 빠르게 필요한 화면을 개발할 수 있다는 큰 장점을 가지고 있지만,반대로 Web-application 개발 측면에서 여러가지 치명적인 단점을 가지고 있습니다.UI 컴포넌트가 제한되어 있고 커스터마이징하기 어려울 뿐 아니라, 복잡한 Web-application 을 구현하거나 Js 기반 고도화된 기능을 구현하기에는 적합하지 않았습니다.이로 인해, Svelte 라는 Js 기반 Web Framework 에 대한 학습을 본격적으로 시작하였습니다.많은 화면 개발 경험을 해본 상

에이닷을 사용하는 사용자에 필요한 정보를 제공하는 가장 좋은 방법에는 어떤 것 들이 있을까요?여러 가지 방법들이 있겠지만 그 중 하나는 사용자의 요청이 없어도 먼저 말을 걸어 알려 주는 방법을 생각해 볼 수 있습니다.하지만 사용자의 직접 적인 요청이 없어도 잘 제공할 수 있을까요?이를 위해 어떻게 하면 먼저 말을 잘 걸 수 있을지 고민하고 개발한 내용을 소개해 드리도록 하겠습니다.새롭게 개편된 에이닷을 사용해 보면 에이닷이 먼저 말을 걸어 옵니다.정해진 말만 하는 것은 아닐까 하는 생각이 들 수도 있지만 조금만 에이닷을 사용해 보면 다양한 내용으로 말을 걸어 오는 것을 볼 수 있습니다.우선 우리는 에이닷이 말을 먼저 거는 기능을 '선톡'으로 부르며 다음과 같은 종류로 나누었습니다.• None - 개인 정보(통화, 수면, 일정, 위치 등등)을 활용해서 정보를 알려 주며 말 걸기• None - 개인적인 관심사, 좋아하는 음악 등에 대해서 말 걸기개발의 방향은 필요한 정보를 Context로 구성하고 개인화 Agent에서 이를 활용하여 선톡을 Offering 하는 구조를 기본으로 하고 있습니다.Offering 을 효율적으로 하면서 고도화도 유연하게 하기 위해 다음과 같이 Context 영역과 Agent 영역을 구분했습니다.주요 기능들은 아래와 같은 모듈들이 담당하고 있습니다.선톡의 시작은 사용자의 Context에서 시작 됩니다. Context에 대해서 다음과 같이 3가지 영역으로 문제를 정의하고 개발을 하였는데 수집부터 활용까지 하나씩 알아 보도록 하겠습니다.• None Context 가공 - LLM Prompting에 활용하기 좋은 형태로 가공필요한 Context를 정의하고 수집하는 단계로 아래 표는 대표적인 Context의 예시 입니다.그 밖에도 전화, 라디오 정보 등 다양한 Context가 있고 하루 하루 계속 추가가 되고 있습니다.다만 수집된 Context 정보는 아래 예시와 같이 약어로 표기된 필드명과 알기 어려운 단순한 숫자 값으로 되어 있는데이는 개인화 Agent (LLM 활용)에 바로 사용하기 어려운 경우가 많습니다.필요한 항목만 선택하여 LLM이 이해하기 쉬운 형태로 아래와 같이 변경을 합니다.Context는 UPS에 저장되어 있는데 선톡에서 원하는 Context를 쉽게 조회 할 수 있도록 API를 제공하고 있습니다.해당 API에서는 원하는 Context 항목을 선정하고 세부 조건을 설정합니다.아래와 같이 개인화 Agent의 LLM Prompt에 적합한 형태로 사용하게 되고,개인화 Agent는 아래와 같이 선톡을 생성합니다.Context의 종류는 매우 많고 앞으로는 더욱 더 많아 질 것이기 때문에 해당 Context를 기반으로 제공할 수 있는 수 많은 선톡 중에서 어떤 선톡을 선택해서 제공할 지가 Agent의 핵심 요소입니다.우리는 최적의 선톡을 선택하기 위해 평가 시스템 (Evaluation System)을 다음과 같이 만들었습니다.가장 처음에 하는 일은 선톡의 종류에 따른 우선 순위를 정하는 것입니다. 기본적으로 아래와 같은

여러분은 업무에서 GitHub Copilot(이하 '코파일럿'으로 명명) 등 AI-assisted Software를 얼마나 많이 사용하고 계신지요? :)SK플래닛에서도 이미 작년부터 코파일럿을 업무에 도입한 개발자들이 있었지만, 직무와 연차, 활용 용도에 따라 상이하게 사용하고 있었고 각자의 만족도도 달랐습니다. 따라서 당사는 2024년 4월부터 8월까지, 다양한 개발 업무에서 개발 생산성 향상 실험 및 사례 발굴 등의 활동을 진행하였습니다. 본 글은 이 활동을 회고/정리하는 '코파일럿 활용기' 성격으로 작성하였사오니 함께 참고 부탁드립니다.참고로 SK플래닛에서 사용한 코파일럿 버전은 'Copilot for Business' 이며, 당사의 사업 및 개발 분야는 아래를 참조하시기 바랍니다.이번 '코파일럿 활용'의 목표는 (1) 코파일럿의 다양한 활용 사례를 정리하여 구성원에게 공유하는 것과 (2) 코파일럿이 개발업무 생산성에 미치는 영향을 정량적으로 측정/비교 실험을 포함하였습니다(좀 어려웠...). 또한 (3) 많이 사용되는 백엔드, 프론트엔드 개발 외에도 데이터, 인프라, 블록체인 개발자에 대한 피드백을 함께 받아 실용성을 높이고자 하였습니다.이를 위해 먼저, 3월에 외부 전문가를 초빙하여 생성형 AI 기반 Coding에 대해 최근 기술 트렌드를 공유하고 눈높이를 맞추었습니다(주제: 실리콘밸리 개발자가 바라보는 AI 생산성 툴 및 개발 방식의 변화, 연사: 한기용 Upzen 대표). 본 세미나에 대한 요약은 다음 글을 참고하시기 바랍니다 => https://techtopic.skplanet.com/genai-productivity/4월에는 Kick-off meeting을 통해 취지를 설명하고 2개의 내부 사용자 그룹을 구성하여 업무 도입 및 활용 사례를 정기적으로 공유하였습니다. 그룹 1은 SDE(백엔드, 프론트엔드, Android/iOS 앱 개발), Web3 개발 중심으로 구성하였고, 그룹 2는 Data Engineer, 인프라 개발자 중심으로 총 30명의 사내 개발자가 참여하였습니다.코파일럿은 아시는 것처럼 생성형 AI 기반 코드 작성 도구로, 코드 자동완성 및 추천, 언어간 전환 기능, 코드 수정 기능(리팩토링, 오류 수정), 코드 설명 등의 다양한 개발 업무에 도움을 줄 수 있습니다. 이를 전통적인 자동 완성 기능과 비교할 경우 다음과 같은 차이가 있습니다.(1) 자동 완성은 사전(dictionary)을 참조하는 Syntax 기반의 자동 완성으로, 문법의 오류를 방지하고 타이핑을 줄여주는 정도의 수준입니다. 글쓰기에 비유하면 '맞춤법 검사기 + 단어 자동완성' 수준으로 볼 수 있습니다.(2) 반면 코파일럿은 개발자의 의도에 따른 소스 코드 생성, 자연어 프롬프트 기반의 로직 생성 및 개발자 의도 예측에 따른 로직 생성이 가능합니다. 글쓰기에 비유하면 '스토리를 스스로 생성하는 수준' 으로 볼 수 있습니다.그럼 좀더 자세히 활용 사례를 보도록 할까요? :)코파일럿에서 가장 직관적이고 많이 활용하는 기능 중 하나는 '자연어 to C

안녕하세요. 카카오 기술전략 소속의 로빈입니다.현재 저는 카카오의 AI 교육 자문 활동 맡아 AI 교육 커리큘럼 설계 및 감수를 진행하고 있으며, AI Native Company로의 여정을 위해 AI를 활용하는 사내 시스템을 구축하고 있습니다. 또한 사내의 ChatGPT 커뮤니티를 운영하며, 생성형 AI와 관련한 다양한 트렌드와 소식을 사내 크루들에게 전달하고 있기도 합니다.많은 분들이 AI 서비스를 구현할 때 가장 고민되는 것 중에 하나가 바로 '...

1. 고객과의 거리를 좁혀보자 - 생일 축하 문자SK텔레콤과 고객과의 거리가 점점 멀어지는 것 같습니다.그저 제 개인적인 생각이라면 다행인데, 언론에서 통신사를 다루는 이야기나그것에 대한 여론을 보면 저만의 느낌만은 아닌 것 같아 안타깝습니다.그래서, 고객과의 거리를 좁히고자 고객이 기뻐하는 Event에 함께 축하 하는 문자 메세지를 제작해서 보내기로 했어요.가장 먼저 생각난 Event는 '생일'이었고, 고객의 생일에 진심으로 기뻐하고 함께 축하하는 감성적인 문자 메시지를 기획했습니다.아래와 같은 고려 사항들을 생각하면서 하나씩 재료들을 모으고, 만들어 갔습니다.1. Mass 형태의 동일한 메세지는 지양하고, LLM을 통해 최대한 다양한 감성적인 메세지를 생성한다2. 기존 문자 메시지의 포맷에서 벗어나, 편지지/이미지를 생성해서 조합한다(이미지 생성)일단 가장 먼저 한 작업은 고객이 생일에 어떤 행동 패턴을 보이는지 확인하기 위해 데이터를 분석하는 작업이었어요.이 작업부터 한 이유는 생일 행동을 유형화해놓아야, 각 유형에 소구할 수 있는 메시지 프롬프트를 만들 수 있기 때문입니다.생일 행동 패턴을 유형화하기 위해 분석해 본 도메인 중 하나는 T멤버십입니다.생일에 특히 많이 사용(할인/적립) 하는 멤버십 브랜드를 통해 고객의 생일 관련 행동을 유추해볼 수 있기 때문입니다.생일 고객과 생일이 아닌 고객의 이전월/생일월의 멤버십 사용을 비교해보니 아래와 같은 점이 눈에 띄더군요.대체로 생일 고객은 생일이 아닌 때보다 생일이 있는 시기에 멤버십 사용이 늘어났고,이 늘어난 정도는 여성 고객에서 더욱 두드러졌습니다.생일에 특히 많이 사용되었던 멤버십 브랜드는 서울스카이, 야놀자, 아웃백 등 외부활동/외식에 포함된 브랜드였고,더 적게 사용된 브랜드는 편의점/카페 등 평소에도 사용량이 많은 브랜드였습니다.이와 같은 분석을 통해 생일에 드러난 행동 패턴을 유형화하여 아래와 같이 나누었습니다.일단 연령대로 고객군을 크게 나눈 다음, 각각의 유형에 고객군이 할당 되도록 셋팅했습니다.연령대부터 나누는 것이 바람직한지는 아직까지도 고민이기는 한데(저보다 힙하고 트렌디한 60대 분들도 많이 계시니..),기본적으로는 나눠놓는 것이 메세지 생성에 도움이 되는 것 같아 구분지었습니다.3. 감동과 정성을 담아... - 메세지 생성가장 메인 작업이자 핵심인 메세지 생성에서 제가 원하는 것은 아래와 같았습니다.[감성적]인 축하 메시지를 [SKT가 제공하는 가치]와 부합되게 LLM이 생성하는 것.생일 축하 메시지인 만큼 형식적이거나 딱딱함 보다는 감성적이었으면 좋겠고,가능하면, SKT가 고객에게 제공하는 가치들(통화, 문자, AI, 연결 등등)이 축하 메시지에함축적으로 담겨 있으면 좋겠다고 생각했어요.회사 내용이 너무 많이 들어가면 광고 문자처럼 보일 수도 있지만,SKT가 제공하는 가치는 분명 고객 삶에서 함께 하기에 완전 동떨어진 내용처럼보이지는 않을 것 같았습니다.그런데, 이렇게 적어놓은 순간 머리에 몇몇 문구가 떠오르더군요.3. 사랑을 연결하는 가장 진화한 방법넵, 모두 SKT CF속에서 나오는 대사/카피들입니다.생각해보니 제가 하고 있는 고민들은 모두 SKT 광고에 포함된 내용들이었습니다.그래서 우선, 그동안 SKT CF의 모든 카피들을 모으는 작업부터 하였습니다.처음 선택한 방법은 whisper API를 활용하여 유튜브에 있는 SKT 광고 카피들을 모으는 것이었습니다.whisper는 오디오 파일에서 텍스트를 생성하는 모델인데, 꽤 성능이 좋았습니다.아래와 같은 코드를 통해서 만들었는데, 문제는 SKT 광고들이 유튜브에 별로 없더군요.그래서 다른 방법을 찾아보니 TVCF(https://tvcf.co.kr/) 사이트에 기업별로 광고들이 정리되어 있더군요.🙃😭그래서 방법을 바꾸어 이 사이트에서 아래와 같이 SKT 광고 카피들을 모았습니다.이제 모은 재료들을 바탕으로 메시지 생성을 위한 기본 프레임워크를 만들 차례입니다프롬프트에는 고객유형별로 MMS 생성 가이드라인을 준수하면서 작성하되,감성적인 문구는 SKT 광고 카피에서 참고하여 작업하라는 내용을 담았습니다.LLM 모델은 처음 n개의 메시지는 'azure/openai/gpt-4o-2024-05-13'와 'anthropic/claude-3-5-sonnet-20240620'모두 사용해서 비교해봤고, claude의 작명 실력이 월등히 좋아 claude 모델만 사용하고 있습니다.프롬프트 엔지니어링은 여러 기법들이 있지만, 가장 가시적으로 효과가 좋았던 방법은 해야할 일을step별로 쪼개는 것과((Least-To-Most), 예시를 보여주는 few-shot이었습니다.• None N-Shot Prompting: 다양한 예시를 제공하여 LLM의 답변 정확도를 높이는 기법• None Chain-Of-Thought Prompting: 단계별 추론 과정을 통해 문제 해결 능력을 향상시키는 기법• None Least-To-Most Prompting: 복잡한 문제를 단순한 하위 문제로 분해해 해결하는 기법• None Self Consistency Prompting: 다양한 추론 경로를 생성하여 가장 일관된 답변을 선택하는 기법• None Generated Knowledge Prompting: LLM이 자체적으로 배경 지식을 생성해 더 깊이 있는 답변을 제공하는 기법output 형식을 지정해줄 수 있는 langchain의 response schema도 잘 활용했습니다.사실 감성적인 문구만을 모아 vector DB로 만드는 RAG을 이용할까도 했지만,RAG은 최신정보/정확한 정보를 가져오는 것에 더 맞는 방법론인 것 같아서 감성적인 문구를 만드는 데에는 프롬프트를 다듬는 데에만 집중했습니다.이렇게 생성된 메시지들은 팀에서 직접 확인하여 선별하고,선별된 메시지는 검토하는 팀(고객언어연구팀)의 검수도 한번 더 받습니다.이외에도, 개인화의 수준은 SKT에서 준수하고 있는 고객 데이터 AI 활용의 가이드 라인을 따랐습니다.가이드 라인은 고객의 비식별화된 개인정보 또한 프롬프트에 명시적으로 활용할 수 없고,프롬프트에 가능한 정보는 높은 수준의 가명처리를 해야 된다는 등 혹시나 오용될