No-Code 자동화 툴인 n8n과 Open WebUI를 활용하여 간단한 예제를 만들어보고자 합니다.n8n의 Docs를 확인해보면, API가 있는 다양한 서비스들을 연결하거나 No-Code 또는 Low-Code로 데이터를 조작할 수 있도록 도와주는 자동화된 워크플로우 툴입니다.• None 커스터마이징 가능: 고도로 유연한 워크플로우와 커스텀 노드를 구축할 수 있음• None 편리함: n8n을 npm이나 Docker로 사용할 수 있고(Self-Hosted) 클라우드로도 사용 가능n8n Self-hosted 방식은 Docker 혹은 npm으로 설치할 수 있습니다. 사내 개발환경에서 docker 사용이 불가하기 때문에ㅠㅠ npm으로 설치하였습니다.npm 사용시 node 버전은 18 버전 이상이여야 합니다. 명령어로 글로벌하게 다운받아 사용해주시면 됩니다.Open WebUI와 LLM 워크플로우는 챗봇 중심의 간단한 답변 시스템을 만들 수 있습니다.하지만 n8n을 활용하면 다양한 역할을 하는 노드들을 엮어 AI 에이전트의 서버를 개발할 수 있다는 점입니다.또한, 저처럼 백엔드 개발하시는 분들은 불필요하게 프론트엔드 작업을 할 수고가 적어지는 것 같습니다.이 예제에서 만들어 볼 간단한 workflow를 구성해 볼 것입니다.외부의 request를 트리거로 작성된 workflow를 시작하게 하는 노드입니다. 즉, 특정 이벤트 발생시 workflow를 실행하는 노드입니다.Webhook 설정에서 HTTP Method(DELETE, GET, POST, PATCH, HEAD, PUT)을 선택할 수 있으며, Path, Authentication, Respond 등 선택하여 이벤트를 받아올 수 있습니다.• None• None Immediately: 요청 받자마자 즉시 응답, 워크플로우가 끝나는 것을 기다리지 않고 바로 응답을 돌려줌, 즉, 워크플로우의 실행 결과와 응답 내용이 아무런 관계가 없을 때 “받았습니다”만 빨리 알려주고 싶은 경우에 사용• None When last node finishes: 워크플로우의 마지막 노드까지 실행이 끝나고 나서 응답을 돌려줌, 예를 들어서 외부 서비스인 Slack의 응답값을 이용하고 워크플로우 실행의 결과를 응답으로 보내야할 때 사용함, 워크플로우를 어떻게 구성했느냐에 따라 시간이 초과되어 외부서비스가 timeout 날 가능성이 있음• None Using ‘Respond to Webhook’ Node: Webhook 노드 에서는 요청을 받아만두고 워크플로우 안에서 를 이용하여 내가 원하는 시점에 응답하도록 함, 즉, 조건에 따라 다른 응답 시점과 내용도 자유롭게 커스터마이징해서 사용이 예제에서는• None 으로 설정하고 진행하겠습니다.Webhook과 바로 연결된 AI Agent node를 생성하여 연결해보도록 하겠습니다.• None• None webhook에서 입력한 json.body.chatInput을 참조하게 됨(open WebUI에서 Function 입력 기본값, 변경가능)• None Language Model: OpenAI Chat Model (다른 모델도 사용가능)Webhook 노드를 Using 'Respond to Webhook' node 로 설정했기 때문에, Respond to Webhook 노드 설정이 필요합니다.• None Respond With: 외부 요청에 응답할 데이터를 어디서 가져올지 정함• None All Incoming Items: 들어온 모든 데이터를 JSON 배열로 응답• None Binary File: 워크플로우 중간에 처리된 파일을 응답으로 직접 전송, HTTP Header에 Content-Type도 파일 확장자에 맞게 자동 설정됨• None JSON: JSON 에디터에 직접 json 응답을 작성하여 지정하여 이 값이 그대로 나감• None JWT Token: JWT 토큰 형식으로 응답 전송, Secret로 설정• None No Data: 204 No Content 같은걸 나타낼때 사용, 받기는 했으나 응답할 내용이 없을 때• None Redirect: 브라우저나 클라이언트를 다른 주소로 보냄, Location Header 자동 설정됨Save하여 진행상황을 저장하고, Inactive를 Active로 전환하여 플로우를 실행할 수 있도록 변경하면 됩니다.Execute workflow 버튼을 눌러 지금까지 구성한 Workflow를 확인해보겠습니다.저는 Postman을 이용하여 n8n webhook에 트리거를 주었습니다.200 OK status code와 함께 model이 생성한 output을 응답으로 받은 것을 확인할 수 있습니다.그렇다면, n8n으로 만든 workflow와 Open WebUI를 연결해보도록 하겠습니다.Open WebUI는 로컬 환경에서 LLM 모델을 적용하고 웹 인터페이스로 다양한 상호작용을 할 수 있는 환경을 제공합니다.간단하게 설치과정을 요약하자면, docker, pip 등 방식이 있는데 마찬가지로 사내환경에서 docker가 안되기 때문에… pip로 설치하였습니다.저는 파이썬 개발은 PyCharm을 이용하고 있어서, Python Packages에 open-webui를 검색하여 설치하였습니다.Open WebUI 서비스 구동은 open-webui serve 로 실행시키면 됩니다.Open WebUI를 실행시키고 로그인을 진행한 후,• None 새로운 창에서 Functions - N8N Pipe 검색• None 목록에서 N8N Pipe 클릭, open webui 주소를 localhost:8080 설정하고 Import to WebUI• None N8N Pipe Function 옆에 톱니바퀴를 눌러서 N8N Url(http://localhost:5678/webhook-test/n8n)으로 수정 및 실행• None 메인에서 N8N Pipe로 설정 후, 채팅창에 원하는 말을 입력(chatInput)마지막으로, chatInput을 아무거나 입력해서 보내면 성공적으로 n8n으로부터 응답이 오는 것을 알 수 있습니다.앞으로 적용해보고 싶은 것들?RAG와 MCP server를 추가해서, 더 다양한 데이터를 기반으로 업무와 관련된

여기어때 컬처 라운지 ep. 8‘어떻게 하면 주어진 업무를 더 잘 해나갈 수 있을까?’‘나에게 부족한 부분은 어떻게 채워나갈까?’성장에 대한 열망이 있는 사람이라면 누구나 업무 중 이런 저런 고민을 마주하게 됩니다. 여기어때에서는 이러한 성장의 고민을 해결하고 잠재력을 마음껏 펼칠 수 있도록 다양한 지원 제도를 운영하고 있어요. 오늘은 구성원들의 성장을 지원하는 몇가지 제도에 대해 소개해 드릴께요.🌱 언제 어디서든, 나만의 속도로 <온라인 교육 지원>첫번째로는 시공간 제약 없이 편리하게 수강할 수 있는 온라인 교육 수강제도를 운영하고 있어요.사이버 연수원을 통해 매월 수강신청을 할 수 있고, 다음 한 달간 신청한 강의를 들을 수 있어요. 공통 소프트 스킬부터 기획, 기술, 영업, 마케팅, Data, HR, 경영지원 등 직무별로 폭넓은 커리큘럼이 마련되어 있어 원하는 강의를 자유롭게 선택할 수 있어요. 온라인 과정 특성상 언제 어디서든 편리하게 수강할 수 있고 버튼 한 번으로 신청할 수 있어 간편한 것도 장점이랍니다.💡 깊이 있는 인사이트가 필요할 때 <외부 교육 지원>사이버 연수원에서 제공하는 커리큘럼으로는 채울 수 없는 심화 내용이나, 네트워킹을 통해 생생한 인사이트를 얻을 수 있는 컨퍼런스 등은 외부 교육 지원제도를 통해 신청이 가능합니다.구성원들이 원하는 교육 기관과 강의를 자유롭게 찾고 신청할 수 있으며, 교육 뿐만 아니라 컨퍼런스, 세미나 등 다양한 형식으로 신청할 수 있어요. 사이버 연수원과 달리 원하는 시기에, 온/오프라인 형식에 관계없이 신청할 수 있어 선택의 폭과 자율성이 크다는 장점이 있답니다.이러한 외부 교육 지원은 단순히 업무 스킬을 향상시키는 것을 넘어, 최신 트렌드를 직접 경험하고 외부 전문가들과 교류하며 시야를 넓히는 기회를 제공해요.📚 읽고 싶을 땐 언제든 <도서 구매 지원>교육이나 강의 외에도, ‘책’을 통해 마음의 양식과 지식을 쌓는 것도 빼놓을 수 없는 부분이죠? 여기어때는 이러한 구성원들의 지적 호기심과 배움의 열정을 아낌없이 지원하고 있어요.직무와 관련된 서적이라면 지원 금액 한도 없이 언제든 구매할 수 있도록 지원하고 있어요.🎤 함께 배우고 지식을 나눌 수 있는 <사외 강사 특강 지원>개인의 성장을 넘어 조직 전체의 지식을 함께 나누고 발전시키는 것도 무엇보다 중요해요. 여기어때에서는 최신 트렌드나 특정 분야에 대한 인사이트를 여러 구성원과 나누고 싶다면, 사외 강사 특강을 직접 기획하고 신청할 수 있어요.조직별로 필요한 주제의 외부 전문가를 초청하여 함께 학습하고 토론하는 장을 마련해볼 수 있죠. 최근에는 AI Tool, UX Research, 효과적인 글쓰기 등 다양한 주제로 조직별 특강이 진행되기도 했어요. 조직과 직무에 상관 없이 참여를 희망하는 누구나 신청해서 들을 수 있어, 동료와 함께 성장하는 특별한 경험을 할 수 있어요.마지막으로 여기어때의 성장 지원제도를 통해 눈부신 성장을 경험한 동료들의 이야기도 들어볼까요?💬 QA1팀 리더 요셉 : “팀 회의 시, 주로 팀장인 저만 이야기하는 것

AI 기술의 발전은 우리의 일상에 놀라운 변화를 가져오고 있습니다.특히 셋톱박스에 AI 기능이 탑재되면서 음성 명령을 통해 TV 채널을 변경하거나 볼륨을 조절하는 등 더욱 직관적이고 편리한 사용자 경험을 제공하고 있죠.최근에는 나만의 AI 개인비서인 ‘에이닷’을 통해 자연스러운 대화가 가능해지면서, 콘텐츠 검색, 정보 및 리뷰 요약, 기분에 맞춘 추천 기능 등 다양한 서비스로 그 영역이 확장되고 있습니다.셋톱박스는 음성인식 기반 인터페이스를 도입하며 사용자와의 상호작용을 한 단계 더 발전시켰습니다.리모컨을 사용하거나 멀리서 음성으로 가상 어시스턴트를 호출하는 등 다양한 방식으로 손쉽게 서비스를 이용할 수 있게 되었죠.하지만 이러한 혁신적인 기능들이 원활히 작동하기 위해서는 음성 명령을 정확히 인식하고, 깨끗한 소리를 재생할 수 있는 음향 기술이 필수적입니다.앞서 에이닷 통화 중 녹음에 사용되는 음향 처리 기술과 Auto에서의 음향 측정 및 분석에 대해 살펴본 바 있는데요.오늘은 셋톱박스의 음향 기술 중에서도 음향 서비스의 목적을 실현하기 위한 근간이 되는 음향 시스템 설계에 대해 알아보는 시간을 갖도록 하겠습니다.일반적으로 스피커는 소리를 크게 깨끗하게 하기 위해서 다양한 음역대를 재생할 수 있는 드라이버를 배치하고 출력 파워를 높이기 위해 앰프의 출력과 스피커의 임피던스를 매칭하여 선정합니다.또한 마이크는 충분한 음성 대역을 커버하고 멀리 떨어져 작아진 음성 신호도 입력받아야 하기때문에 주파수 응답이나 감도를 고려하여 선정하게 됩니다.좋은 스피커와 좋은 마이크를 사용하면 좋겠지만 제품의 용도, 디자인, 크기, 연결 방식 , 가격 등의 이유로 제한이 생기고 유닛과 공간의 제약을 받게 됩니다.그러므로 내부 기준을 가지고 단품을 선정하고 공간배치를 하여 충분한 성능을 확보하기 위한 노력이 필요하게 됩니다.아래는 B tv AI 사운드맥스 제품에서의 선정과 배치 사례 입니다.• None• None STB용 마이크 선정에서는 디지털 마이크와 아날로그 마이크 중 선택해야 합니다.• None 디지털 마이크는 비싸지만 SoC 앞에 별도 ADC가 필요 없어 시스템 복잡도를 줄일 수 있으며, MEMS 기반 마이크로폰은 크기가 작고 비용이 저렴하여 다채널 시스템 구성에 적합합니다.• None 최근 STB은 주로 MEMS 디지털 마이크를 채택하는 추세입니다.• None• None AI STB는 보통 4개의 마이크를 내장하여 빔포밍 기술을 구현합니다.• None 이는 집안 어디서든 음성 명령을 정확히 인식할 수 있는 원거리 음성 인식 성능을 제공하기 위함입니다.• None 마이크 개수, 어레이 크기, 형태, 마이크 간 거리가 성능에 직접적인 영향을 미칩니다.• None• None 마이크는 STB 상단부에 배치하되, 스피커와의 간섭을 최소화해야 합니다.• None• None STB 스피커 시스템은 일반적으로 풀레인지 스피커와 우퍼로 구성됩니다.• None SK브로드밴드의 AI 사운드 맥스는 40W 우퍼 스피커 2개와 15W 풀레인지 스피커 2개를 장착했습니다.• None 고역 재생을 위해서는 트위터가 더 적합하지만, STB의 공간 제약으로 인해 미드 우퍼와 트위터의 조합보다는 광대역 풀레인지 스피커를 주로 사용합니다.• None 트위터는 고주파 영역에서 뛰어난 세밀함을 제공하지만, 중대역 커버리지 한계와 시스템 복잡도 증가 문제가 있습니다.• None 공간이 제한된 STB에서 저음 성능을 향상시키기 위해 패시브 라디에이터 기술을 적용합니다.• None 이는 별도의 전력 없이 메인 스피커의 진동에 의한 공기 흐름을 받아 저음을 증폭시키는 기술로, 아스텔앤컨 같은 전문 브랜드의 사운드 튜닝과 결합하면 뛰어난 효과를 얻을 수 있습니다.스피커와 마이크의 선정과 배치가 마무리되면 음질의 투명성과 정확도를 위해 주요한 요인을 체크하게 됩니다. 그것은 오늘도 등장하는 거슬림 입니다.좁은 공간에 스피커와 마이크를 배치하게 되기 때문에 설계시 불가피하게 거슬림의 요인들이 발생하게 됩니다.오늘은 선정과 배치시에 셋탑박스에서의 신호의 왜곡을 유발하는 주요 거슬림 요인들에 대해서 알아보는 시간을 갖도록 하겠습니다.마이크에서 밀폐(Sealing)이란 외부 잡음이 내부로 들어오는 것을 막고 전달되는 음성 신호의 손실을 막음으로써, 음향적 왜곡을 줄이고 마이크의 음질을 안정적으로 유지할 수 있는 것을 말합니다.마이크에서 실링이 원활히 되지 않는다면 아래와 같이 일부 대역의 손실과 함께 SNR의 열화를 가져오게 됩니다.스피커의 진동(Vibration) 은 소리를 생성하기 위해 필수이지만, 잘못된 진동은 음질에 좋치 못한 영향을 줄 수 있습니다.대표적으로 스피커의 구조물이 공명하여 발생하는 진동이 있고 그 외에도 스피커의 다이어프램이나 바닥면과의 반사로 인해 진동을 야기할 수 있습니다. 잘못된 진동은 흔히 스피커 떨림이라고 표현합니다.만약 마이크의 밀폐가 잘 되지 않고 스피커의 떨림이 구조물을 타고 들어온다면 음성은 왜곡이 되고 외부 잡음와 더불어 비선형성 잡음이 크게 증가하여 큰 문제가 야기될 수 있는 부분입니다.이는 음악을 듣거나 콘텐츠를 볼 때 다른 동작을 하기 위한 음성 명령을 하게 되는 바진 상황에서 더욱 문제로 두드러질 수 있게 됩니다.AI 셋탑박스에서의 음향 시스템 설계의 목표는 스피커의 불필요한 진동의 발생 요인들을 제거하여 스피커 음질을 향상과 함께 마이크의 완전한 밀폐를 통해 왜곡을 줄이고 투명한 음성을 전달받을 수 있도록 하는 것입니다.아래는 실제 AI B tv 에서 음향 시스템 설계시 동일한 신호 재생하여 실링 여부에 따른 마이크로 입력된 신호의 차이입니다.아래 그림과 같이 마이크 실링되지 않았을 때는 바닥에 깔려있는 잡음의 에너지가 큰 반면 신호의 에너지는 작게 보입니다.밀폐를 위한 다양한 H/W 기구 처리를 통해 아래 오른쪽 그림과 같이 신호의 에너지는 크게 하고 잡음의 크기는 작게 되었습니다.**스펙트럼 뷰는 시간에 따른 주파수별 에너지 분포를 나타냄 (밝을수록 해당주파수에서 에너지가 크다는 의미, 어두울수록 에너지가 작거나 없음을 의미함).이렇게 음향 시스템의 기본 성능을 확보한 뒤에는, 멀티

우리 팀에도 Jarvis 가 생겼다 – 생성형 AI 로 만든 에러 분석가 이야기팀 내에서 생성형 AI 를 활용한 사례를 공유합니다.• 왜 에러 로그는 항상 늦게 처리되는가?• 에러 로그 분석 자동화, 우리는 이렇게 구성했습니다.• MCP란 무엇인가? 우리는 왜 Jarvis 를 투명인간 취급하였을까• 다음 목표는? 지나간 해결 방법 학습과 미지의 영역• 자동 분석이 만든 변화• 이 글을 마치며왜 에러 로그는 항상 늦게 처리되는가? 안녕하세요. 컬리의 배송 시스템을 맡고 있는 딜리버리프로덕트의 김성준입니다.개발자인 우리는 하루하루 개발을 하다 보면 수많은 에러 로그와 마주치게 됩니다. 이 로그들은 마치 복잡한 숲 속에서 길을 안내하는 작은 이정표 같습니다. 그러나 문제는, 그 이정표가 흐릿하거나 때로는 아예 보이지 않는다는 데 있었습니다. "에러났어요!"라는 메시지를 보는 순간, 우리는 익숙한 길 위로 다시 돌아가게 됩니다. 로그를 찾고, 읽고, 해석하고, 대책을 마련하는 긴 여정을 반복하면서 말이죠. 마치 어딘가로 떠나는 길 위에서 되풀이되는 지루한 습관처럼. 로그를 찾는 데만 5분, 10분, 때로는 그 이상이 걸리곤 합니다. 설령 로그를 발견하더라도, 그 내용을 이해하고 정확히 대처하는 데는 더 많은 시간이 필요합니다. 서비스에 익숙하지 않은 팀원들이나 이제 막 개발에 발을 디딘 주니어 개발자들에게는 이 여정이 더욱 길고 험난합니다. 그렇게 시간이 흐르다 보면 시스템의 안정성이라는 것은 점차 흔들리고 맙니다.그래서 우리는 문득 생각했습니다. "에러 메시지가 뜨는 순간, 바로 그 해결 방법도 함께 떠오르면 얼마나 좋을까?" 그렇게 해서 우리는 에러 분석을 도와줄 작고 현명한 비서를 만들기로 했습니다. 그 비서에게는 특별한 이름을 붙였죠. 아이언맨의 현명한 조수에서 영감을 받아, “Jarvis” 라는 이름을 말입니다. 목표는 간단했습니다. 에러가 발생하면 자동으로 로그를 분석하고, 신속히 해결 방안을 안내하는 것이었죠. 에러 로그 분석 자동화, 우리는 이렇게 구성했습니다. 비서에게 역할과 이름을 정해준 다음, 우리는 분석 자동화를 어떻게 구현할지 고민하기 시작했습니다. 가장 쉬운 방법은 구글이나 Stack Overflow에서 찾아 결과를 전달하는 것이었지만, 그 방법에는 몇 가지 문제가 있었습니다.첫째, 정확성의 문제였습니다. 우리 시스템에 특화된 에러는 일반적인 검색으로 정확히 해석되지 않는 경우가 많았습니다. 둘째, 시간 소모였습니다. 검색 결과를 다시 확인하고 정확성을 검증하는 데 또다시 많은 시간이 걸렸습니다.이러한 문제를 해결할 방법을 고민하던 중, 우리는 Gemini 같은 생성형 AI의 가능성에 주목하게 되었습니다. AI가 에러 로그를 읽고 분석하여 적절한 조치를 제안한다면, 우리의 문제를 더 쉽게 해결할 수 있을 거라 기대했습니다.이러한 기대를 가지고 만든 에러 분석 자동화 시스템, Jarvis 는 다음과 같은 핵심 기능을 수행합니다.• 알림 수신: Slack 으로부터 에러 알림을 받습니다.• 에러 분석: Gemini와 같은 생성형 AI를 통해 첨부된 에러 메세지의 원인을 유추합니다.• 조치 가이드 제공: 분석 결과를 바탕으로 적절한 대응 방법을 제안합니다. Jarvis 는 Slack 으로부터 받은 에러 알림의 내용을 바탕으로 Gemini 에게 분석을 요청하고, 분석 내용을 다시 Slack 으로 전달하는 흐름을 가지고 있습니다. 이를 위해 우리는 Slack의 Event Subscriptions 와 Gemini 연동을 위한 LangChain 등의 기술을 도입했고, 그 구조는 간략히 다음과 같습니다. 처음에는 그저 Jarvis 에게 "이 에러를 분석해 해결 방법을 알려줘"라고만 요청했습니다. 그러나 결과는 기대와는 거리가 멀었습니다. 요약은 부정확했고, 중요한 키워드를 놓치거나, 때로는 "요청을 이해할 수 없습니다"라는 건조한 답변만 돌아왔죠. 그래서 우리는 프롬프트 자체를 다시 생각하기 시작했습니다. Jarvis 에게 너무 모호한 질문을 던지고 있던 것은 아닐까 하는 생각이 들었죠. 누군가에게 부탁할 때처럼 구체적으로 요청하기 위해 우리는 다섯 가지의 규칙을 정했습니다.• 구체적이고 명확하게 작성할 것.• AI가 맥락을 이해할 수 있도록 문맥을 제공할 것. 이러한 규칙을 기반으로 우리는 프롬프트를 재구성했습니다. "역할 정의", "에러 확인", "중요도 평가", "발생 원인", "조치 방안" 등의 명확한 카테고리를 설정해, Jarvis 가 원하는 답을 정확히 할 수 있도록 다듬었습니다. 몇 번의 시행착오 끝에, Jarvis 는 점점 숙련된 '시니어 개발자'처럼 대답하기 시작했습니다. 여전히 완벽하진 않지만, 에러 메시지의 원인과 해결 방안을 자신만의 언어로 설명할 수 있게 되었습니다. MCP란 무엇인가? 우리는 왜 Jarvis 를 투명인간 취급하였을까 Jarvis 를 실무에 적용한 지 시간이 지나면서, 우리는 어느 순간부터 Jarvis 의 제안을 잘 참고하지 않는다는 것을 깨달았습니다. 이토록 열심히 만들었음에도 왜 Jarvis 를 마치 존재하지 않는 사람처럼 취급했을까 하는 생각에 우리는 다시 리서치를 진행했습니다.조사 결과, 이유는 의외로 단순했습니다.• 제공된 정보의 부족으로 기초적인 해결 방안만 제시됨. 어찌보면 지극히 당연한 내용이었지만, 피부에 와닿기엔 너무나 가려져있던 진실이었습니다. 한마디로 Jarvis 는 필요한 정보를 충분히 받지 못하고 있었습니다. 에러 메시지만 가지고서는 실제 코드나 비즈니스 로직을 파악하기 어려웠던 것입니다. 이제 Jarvis 가 무엇을 더 원하는지 알게 되었으니 Jarvis 는 더이상 투명이간이 아닌 팀원으로써 같이 일하는 개발자로 변모하기 시작할 겁니다.• 전체적인 에러 메세지: Datadog 에 적재된 에러 메세지 전체를 전달.• 관련 비지니스 로직: Git 저장소의 관련 소스 코드 일부를 전달. 에러가 발생하면 전체적인 에러 메세지와 관련된 소스 코드를 보고 원인을 분석하는 것처럼 Jarvis 에게 관련 정보를 추가로 전달하기 위해 MCP(Model Context Protocol) 를 도

iOS Safari에서 새 창이 열리지 않은 이유와 해결 방법실무에서 마주친 iOS Safari의 예외 상황과 브라우저 정책를 사용해 새 창 열기 기능을 구현하던 중, 특정 기기/페이지에서만 해당 기능이 동작하지 않는 이슈가 있었습니다.이 이슈의 원인을 파악하고 해결해 나간 과정에 대해서 공유드리려합니다.iOS Safari에서만 코드가 동작하지 않았던 이유제휴 서비스에 연결 및 제휴 페이지로 이동하는 기능을 개발하던 중, 새 창을 여는 코드가 일부 iOS 기기에서만 동작하지 않는 문제가 발생하였습니다.같은 링크 이동 공통 코드를 사용하는 다른 페이지에서는 정상적으로 새 창이 열렸고, 동일한 페이지도 Android나 데스크탑에서는 문제가 없었습니다.심지어 같은 OS인 다른 iOS 기기에서는 또 정상 동작하였습니다.이슈 상황이 한정적이 었기 때문에, 원인 파악이 굉장히 까다로웠습니다.위 케이스 분석을 통해, 문제가 된 페이지의 동작 방식과 문제가 발생한 iOS 기기의 설정이 동시에 작용할 때만 이슈가 발생한다는 점을 유추할 수 있었습니다.문제를 해결하기 위해 다양한 시도와 디버깅을 진행하였고, Safari 브라우저에서 사용자 상호작용과 팝업 생성 시점 사이의 타이밍에 민감하게 반응한다는 점을 확인하게 되었습니다.Safari가 팝업을 차단하는 조건Safari는 팝업(새 창)이 열리는 시점이 사용자의 명시적인 상호작용과 연결되어 있지 않으면 해당 팝업을 차단하는 정책을 가지고 있습니다.이번 이슈에서 문제가 된 페이지는 사용자가 버튼을 클릭한 뒤, API 요청을 보내고 그 응답을 기다린 후에 을 실행하도록 구현되어 있었습니다.이처럼 사용자 인터랙션 직후에 팝업이 동작하지 않으면, Safari는 해당 팝업을 비의도성 광고성 팝업으로 간주하여 자동으로 차단합니다.API 호출 과정에서 문제가 발생하는 것인지 알아보기 위해 사용자 클릭 이벤트 직후 으로 창을 여는 시도하며 어느 시점부터 동작을 차단하는지 확인해보았습니다.Safari는 클릭 이후 1초만 지나도 새 창 열기 동작을 차단하였고, API 호출 및 후처리 로직을 1초 이내로 완료하는 것은 현실적으로 불가능하였습니다.지연 시간을 줄일 수 없으니 클릭 이벤트 트리거를 생성해보기로 하였습니다.히든 버튼을 생성하고 버튼에 팝업 열기 이벤트를 할당해두었습니다. API호출 후 로직이 완료되면 생성해둔 버튼을 클릭하여 이벤트가 발생하도록 시도해보았습니다.하지만 이 방법 또한 사용자의 직접적인 클릭 이벤트가 아니기 때문에 동일하게 차단되었습니다.이 과정을 통해 Safari가 단순히 이벤트 핸들러와의 지연시간을 확인하는 것이 아니라,사용자의 직접적인 클릭 행위와 창 생성의 타이밍이 얼마나 즉각적으로 연결되어 있는지를 판단한다는 점을 알게 되었습니다.빈 창을 먼저 열고, 나중에 URL을 설정하기결국 Safari의 팝업 차단 정책을 우회하지 않고, 만족하는 방식으로 문제를 해결하기로 했습니다.사용자가 버튼을 클릭하는 시점에 으로 빈 새 창을 먼저 열어두고, 이후 API 응답이 도착하면 해당 창의 를 변경하여 랜딩시키는 방식입니다.이렇게 하면 Safari는 "사용자의 상호작용으로 열린 창"이라고 판단하여 이를 차단하지 않으며, 보안 정책을 준수하면서도 기능을 정상적으로 수행할 수 있게 됩니다.사용자 경험 개선을 위한 로딩 페이지 도입이러한 구조로 새 창을 열게 되면, 사용자는 새 창에 주소가 할당될 때까지 빈 페이지를 보게 됩니다.이 상태에서는 아무런 안내가 없기 때문에 사용자 입장에서 혼란스러울 수 있습니다.이를 보완하기 위해 사용자를 빈 페이지가 아닌 공통 로딩 페이지로 랜딩시켜 사용자에게 현재 처리가 진행 중임을 명확히 전달하도록 개선했습니다.처리가 끝나고 나면 주소를 새로 할당해 제휴사 페이지로 이동시켰습니다.위와 같은 개선 사항을 통해,사용자는 팝업 차단 설정을 해제하거나 빈페이지를 보고있지 않고도 서비스 플로우를 따라갈 수 있게 되었고 사용자 경험을 크게 개선 시킬 수 있었습니다.사용자 환경을 이해하고 설계하는 개발자이번 문제를 해결하며 사용자 경험을 제공하는 서비스를 개발하기 위해서는 단순히 개발 역량만으로는 충분하지 않다는 점을 체감하였습니다.사용자의 기기 환경이나 설정 상태에 따라 예외 케이스가 얼마든지 발생할 수 있기 때문에,실무에서는 기술 스펙뿐 아니라 서비스가 제공되는 환경에 대한 이해와 고찰을 충분히 해야할 필요가 있습니다.

마테크 스타트업 AB180의 AWS 비용 관리 노하우를 공유합니다. 청구서 확인부터 시작해 태그 전략, 자동화된 대시보드, 정기적인 FinOps 미팅을 통해 비용 관리 문화를 만들어온 과정과 5가지 핵심 교훈을 확인해보세요.

소프트웨어 개발에서 테스트는 선택이 아닌 필수입니다.개발을 하던 중에, 어딘가의 코드 한 부분을 수정했는데 예상치 못한 곳에서 에러가 발생하는 경우를 모두 한번씩은 경험해 보셨을 겁니다.그럴때 마다, 테스트 코드가 잘 구현된 코드가 얼마나 안전하고 오류를 줄일 수 있는지 깨닫게 됩니다.그렇기에 많은 언어 환경에서 테스트를 잘 할 수 있도록 라이브러리를 많이 제공하는 편인데요.특히 Go 언어는 간결함과 효율성을 철학으로 삼는 만큼, 테스트 또한 내장 도구로 간편하게 작성할 수 있도록 설계되어 있습니다.이번 포스트에서는 Go의 테스트 문화와 철학부터 시작해서 Unit Test 작성 방법 부터 Integration Test 구성 방법까지 폭넓게 다뤄보겠습니다.마지막으로, CI를 활용한 테스트 자동화와 테스트 베스트 프랙티스 및 유지보수 전략도 살펴볼 텐데요.예제 코드를 곁들여 설명하니, Go로 테스트를 처음 작성해보는 분들도 쉽게 따라오실 수 있을 것입니다.• None 테스트의 편리함을 더하는 Testify• None Mocking 기법으로 외부 의존성 다루기• None 여러 조각을 하나로: Integration Test 구성Go 언어는 태생부터 테스트를 중요시해 왔고, 표준 라이브러리에서 바로 테스트 프레임워크를 제공합니다.Go 개발자들은 “테스트도 결국 코드다”라는 철학 아래, 추가 DSL이나 거창한 프레임워크 없이 표준 testing 패키지와 평범한 Go 코드만으로 테스트를 작성하는 미니멀리즘을 지향합니다.실제로 Go의 테스트는 함수 앞에 Test라는 접두사를 붙이고 *testing.T를 인자로 받아서, 그 안에 일반적인 조건문과 함수 호출로 검증하는 식으로 작성되지요.다른 언어처럼 어노테이션이나 복잡한 설정이 필요 없고, 테스트 초기화/정리(setup/teardown)를 위한 별도 문법도 최소한으로 줄여 두었습니다.이런 단순함 덕분에 Go 개발자는 익숙한 Go 문법으로 곧바로 테스트를 작성할 수 있고, 새로운 테스트 전용 언어를 배우지 않아도 됩니다.Go의 기본 테스트는 별도 프레임워크 없이 표준 라이브러리만으로 구현됩니다.Go는 go test 명령과 testing 패키지를 통해 테스트를 자동으로 탐지하고 실행합니다.테스트 코드는 다음 규칙을 따르면 자동 인식됩니다:테스트 파일 이름은 _test.go로 끝나야 합니다 (예: math_test.go)테스트 코드는 일반 코드와 같은 패키지에 두는 것이 관례입니다.테스트 함수는 Test로 시작하고 *testing.T를 인자로 받습니다.예를 들어, 형식입니다. 반환값은 없어야 하며, 등 testing.T의 메서드를 호출해 실패를 보고합니다.동일한 패키지 내의 여러 테스트 함수들은 기본적으로 순차 실행되지만, 패키지 간 테스트는 CPU 코어 수만큼 병렬 실행됩니다.작성한 테스트는 go test 명령 하나로 쉽게 실행할 수 있습니다.기본적으로 성공한 테스트는 조용히 지나가고, 실패한 테스트만 출력됩니다. 자세한 로그를 보고 싶다면 -v 옵션을 사용하시면 됩니다:: 정규식에 매치되는 특정 테스트들만 실행 (go test -run TestAdd 등).아래는 간단한 Add 함수와 그에 대한 유닛테스트 예시입니다:Unit Test에서는 여러 시나리오를 하나의 테스트에 넣기 보다는 하나의 논리만을 검증하는 것이 좋습니다.또한, 테스트 함수의 이름은 무엇을 테스트하는지 명시적으로 드러나게 지어야 디버깅과 협업에 용이할 수 있을 것입니다.외부 자원 접근이나 환경에 의존하는 코드는 유닛테스트에서 최대한 격리하는 것이 좋습니다.Unit Test의 장점은 실행이 매우 빠르고 특정 메서드(함수)의 문제를 정확히 찾아낼 수 있다는 점입니다.다만, 시스템 전체의 관점에서 발생하는 이슈는 찾을 수 없고 다른 모듈과의 상호작용에서 발생하는 문제는 해당 테스트로는 검출하기 어렵다는 한계가 있습니다.따라서, Unit Test로는 메서드 단위의 동작을 탄탄히 검증한 뒤, Integration Test로 보완하는 전략을 사용하는 것이 일반적입니다.3. 테스트의 편리함을 더하는 Testify당연히 Go의 기본 내장 testing 패키지는 테스트를 작성할때 아주 직관적이고 간단하지만, 때로는 여러 번의 반복적인 코드를 작성하는데 있어 불편함이 있습니다.이런 문제를 보완하여 더욱 간편하게 테스트 코드를 작성할 수 있게 해주는 것이 바로 Testify입니다.실제로 개발하다 보면 거의 대부분의 상황에서 이 testify 라이브러리를 사용하는 것 같습니다. (특히, assert 기능..!)Testify는 Go 언어용 테스트 라이브러리로, 기본 내장된 testing 패키지보다 더 편리하고 간결한 테스트 작성을 지원합니다.특히 다음과 같은 기능을 제공합니다:: 보다 직관적이고 명확하게 값을 검증하는 메서드를 제공: 모의 객체를 쉽게 생성하고 관리하는 기능 제공: 관련된 여러 테스트들을 묶어서 관리 가능Testify의 가장 큰 장점 중 하나는 강력한 Assertion 기능입니다.기존 Go 기본 내장 테스트와 비교하여 아래와 같이 더 깔끔한 문법으로 테스트를 작성할 수 있습니다.그 외에도 테스팅에 있어 편리함을 주는 다양한 기능들이 있으니,관심이 있으신 분들은 Testify 공식 문서(https://pkg.go.dev/github.com/stretchr/testify)을 통해 살펴보기면 좋겠습니다.4. Mocking 기법으로 외부 의존성 다루기테스트할 코드가 외부 시스템이나 DB, 네트워크 호출 등에 의존한다면 Mocking 기법이 필요합니다.Mock(모의 객체)은 실제 구현 대신 동작을 흉내 내는 객체로, 해당 의존성을 대체하여 테스트 대상 로직만 검증할 수 있게 도와줍니다.Go는 언어 차원에서 Mock을 지원하지는 않지만, 몇 가지 대표적인 서드 파티 라이브러리가 널리 쓰이고 있습니다: testify/mock과 Mockery가 그 예입니다.testify의 mock 패키지를 이용하면 인터페이스에 대한 모의 객체를 쉽게 만들 수 있으며, 사용 방법의 개요는 다음과 같습니다:• None 인터페이스 정의: 먼저 모킹 대상이 되는 인터페이스를 정의합니다. 예를 들어 메시지를 보내는 인

C++ 개발자는 멀티 스레드 환경에서 mutex나 atomic 같은 동기화 도구를 익숙하게 사용합니다. 하지만 이런 도구를 잘 활용해도 동시성 문제가 발생할 수 있으며 이 경우 디버깅에 많은 시간과 노력이 필요합니다.데이터 레이스(data race)의 개념을 정확히 이해하면 동기화 도구가 어떤 문제를 해결하는지 어떤 상황에서 계속 데이터 레이스가 발생하는지 알 수 있습니다. 이 글에서는 C++의 동시성(concurrency) 문제와 이를 방지하기 위한 스레드 안전성의 주요 개념을 관련 이론 및 사례와 함께 공유합니다. 안정적인 멀티 스레드 코드 작성에 도움이 되기를 바랍니다.관련 발표 영상은 Thread-safety in C++에서 이어보실 수 있습니다.데이터 레이스멀티 스레드 환경에서는 서로 다른 스레드가 동시에 같은 데이터에 접근하는데, 이때 접근 방식이 적절하지 않으면 데이터 레이스가 발생할 수 있습니다. 데이터 레이스는 다음 조건을 모두 충족할 때 발생합니다.두 개 이상의 스레드가 하나의 메모리 위치(memory location)에 동시에 접근하나 이상이 쓰기 연산을 수행하나 이상이 atomic 연산이 아님여기서 '메모리 위치'는 int나 bool 같은 기본 타입(primitive type)의 하나로 이해하면 됩니다.(표준에서는 더 엄밀하게 정의하고 있습니다.) '동시에 접근'은 단순히 시간이 겹친다는 의미가 아니라 C++ 메모리 모델에서 연산 간 선후 관계(happens-before)가 정의되지 않았다는 의미입니다.C++에서는 데이터 레이스가 발생하면 이를 미정의 행동(undefined behavior)으로 간주합니다. 미정의 행동은 어떤 결과가 나올지 예측할 수 없으며, 코드가 정상 작동할 수도 있고 심각한 오류가 발생할 수도 있으므로 절대로 발생하지 않아야 합니다.연산 간 선후 관계순차 실행 관계(sequenced-before)C++에서는 같은 스레드 안에서 실행되는 두 연산 사이에 명확한 순서가 존재하면 이 관계를 순차 실행 관계라고 부릅니다. 이 관계는 연산 간 선후 관계의 전제 조건입니다.다음 코드를 보겠습니다.a = 1; b = a; 여기서 a = 1 연산이 먼저 실행되고, 그 다음 줄(b = a)에서 값을 읽습니다. 이 두 연산은 순차 실행 관계에 있습니다. a = 1이 반드시 먼저 실행되고, 그 다음에 b = a가 실행된다는 것이 언어 차원에서 보장됩니다.비결정적인 순서(indeterminately-sequenced)코드에 적힌 순서대로 실행이 보장되지 않는 경우도 있습니다.f(a = 1, b = a); 이런 표현식에서는 a = 1이 먼저 실행될지 b = a가 먼저 실행될지 정해져 있지 않습니다. 이런 경우에 순서가 비결정적이라고 합니다. 순서는 있지만 어떤 것이 먼저인지는 알 수 없습니다.순서 보장 없음(unsequenced)다음과 같은 경우도 있습니다.(a = 1) + (b = a);이 경우 두 연산 사이에 순서를 보장하지 않습니다. 실제로 동시에 실행될 수도 있고 컴파일러가 임의로 순서를 정할 수도 있습니다. 이는 데이터 레이스로 분류되지는 않지만 미정의 행동입니다.멀티 스레드 안전성과의 관계이런 순서 보장은 멀티 스레드 환경에서 안전성을 확보하기 위한 기초 개념입니다. 같은 스레드 내에서는 순차 실행 관계가 있어야만 그 순서가 연산 간 선후 관계로 이어질 수 있습니다. 코드에 순서가 있다고 해도 그것이 명확한 순차 실행 관계가 아니면, 여러 스레드 실행 시 순서를 정하는 데 문제가 될 수 있습니다.스레드 간 동기화 관계(synchronized-with)같은 스레드 내에서는 코드 상의 순서대로 실행되는 연산 간에 순차 실행 관계가 있습니다. 서로 다른 스레드 간에도 특정한 조건이 만족되면 동기화 관계(synchronizes-with)가 성립하고, 이것이 순차 실행 관계와 합쳐져서 연산 간 선후 관계로 확장될 수 있습니다.동기화 관계는 C++ 표준에서 특정한 라이브러리 호출 쌍에서 명시적으로 정의합니다. atomic이 대표적인 예입니다.한 스레드에서 std::atomic 변수에 대해 store(value, memory_order::release)를 수행다른 스레드에서 같은 변수에 대해 load(memory_order::acquire)를 수행하여 해당 값을 읽음이 두 연산 사이에는 동기화 관계가 형성됩니다.동기화 관계가 생기면, 각 스레드 내의 순차 실행 관계를 이어 붙여서, 결국 하나의 스레드에서 먼저 일어난 일이 다른 스레드에서 나중에 일어난 것처럼 순서를 보장합니다. 이것이 바로 연산 간 선후 관계입니다.동기화 관계는 atomic 연산에만 국한되지 않습니다. 예를 들어 한 스레드가 mutex.unlock()을 호출하고, 다른 스레드가 같은 mutex에 대해 mutex.lock()을 성공적으로 수행하면 이 두 연산 사이에도 동기화 관계가 성립합니다.연산 간 선후 관계는 멀티 스레드 환경에서 안전한 실행 순서를 정의하기 위한 핵심 메커니즘입니다. 이 관계를 통해 어떤 연산의 결과가 다른 스레드에 반영되는 것을 보장할 수 있고 데이터 레이스를 막을 수 있습니다. 멀티 스레드 프로그래밍에서는 동기화 관계를 어떻게 만들고 연결하느냐가 매우 중요합니다.연산 간 선후 관계의 시각적 이해연산 간 선후 관계가 어떤 원리로 형성되는지 시각적으로 정리해보겠습니다.두 개의 스레드가 나란히 표시되어 있고, 각 스레드 내에서의 연산은 위에서 아래로 흐른다고 가정합니다.Thread 1의 연산들은 순차 실행 관계atomic-store-release와 atomic-load-acquire는 동기화 관계Thread 2의 연산들은 순차 실행 관계이 모든 관계가 이어져서 Thread 1 처음의 'A에 3을 쓰기'와 Thread 2 마지막의 'A에서 3을 읽기' 간에 연산 간 선후 관계가 완성됩니다.이것이 C++에서 여러 스레드에서 접근하는 동일 메모리 위치에 대한 연산 간 순서를 정하는 방식입니다. 이런 순서 관계가 명확히 성립하지 않으면, 값이 제대로 전달되지 않거나 동기화가 되지 않아서 데이터 레이스, 즉 미정의 행동이 발생할 수 있습니다.퀴즈: 다음 연산은 데이터 레이스

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. C++에서 안정적인 멀티 스레드 코드를 위한 스레드 안전성 개념 정리 에서도 살펴보실 수 있습니다. 발표 내용C++ 에서 thread safe 한 프로그램을 만들기 위해 알아야 할 기본 개념인 data race 와 basic thread safety, 연산 간 순서 관계에 대해 설명합니다.발표 대상동시성 프로그래밍 업무를 수행하는 C++ 개발자목차Data raceData race연산 간의 선후 관계(Sequenced-before)연산 간의 선후 관계(Synchronizes-with)연산 간의 선후 관계(happens-before)Basic thread safetyBasic thread safetyStandard library 의 thread safetystd::shared_ptr T 의 basic thread safetyBasic thread safety 보장하지 않는 타입의 예Basic thread safety 를 왜 보장해 줘야 하나?External synchronizationExternal sychronizationExternal sychronization w/ std::mutexExternal sychronization w/ std::atomicSynchronizes-with 관계를 제공하는 함수들Internally synchronized typesInternally synchronized typesInternally synchronized type 만들기 시도Synchronization primitivesSynchronization primitive 사용한 internally synchronized typestd::atomic 으로 구현하는 mutex NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

안녕하세요, SK플래닛 DevRel 담당자입니다! SK그룹 테크블로그가 궁금하신 분들을 위해, 작년에 이어 SK ICT 테크블로그 2025년 버전을 업데이트해 보았어요~ (참고: SK ICT 테크블로그 2024년 버전 - https://techtopic.skplanet.com/skict-techblog24/ )1년이 지났을 뿐인데 업데이트할 내용들이 제법 있었어요. SK ICT를 대표하는 SK데보션 블로그, 지금 보고 계시는 SK플래닛 Tech Topic 등은 계속 잘 운영되고 있구요, 올해 변경된 주요 내용은• SK C&C의 사명 변경(SK AX)과 인사이트 메뉴 소개• 원스토어의 개발자 스타일 블로그 오픈 이야기• SK쉴더스의 정보보안/물리보안 블로그 내용을 추가했어요~올해로 4주년을 맞은 데보션은 SK텔레콤이 운영하는 SK그룹의 대표 개발자 커뮤니티 플랫폼으로, SK ICT 패밀리사의 개발 전문가들과 외부 인재간 소통 및 기술 공유를 위한 개발자 활동(DevRel) 채널 역할을 겸하고 있습니다. 블로그뿐만 아니라 AI 개발 생태계를 지원하는 '데보션 오픈랩', 실무형 AI 인재 성장을 지원하는 '데보션 AI 펠로우십' 등 다양한 외부 프로그램을 함께 진행합니다.2025년 6월 1일부터 SK(주) C&C의 회사명이 SK(주) AX로 변경되었습니다! ('AX'는 'AI Transformation' 이라는 의미입니다)SK AX 테크 블로그는 2024년 C&C 때부터 회사 대표 웹사이트에 포함되었으며, 'Insights' 메뉴 내에 기술 인사이트 및 트렌드 메뉴를 별도로 운영하고 있습니다.판교에 있는 SK플래닛에서 운영 중인 기술 블로그입니다. 2023년 1월부터 월 평균 1회 수준으로 블로그를 운영 중이며, OK 캐쉬백, 시럽(Syrup) 등 SK플래닛에서 개발한 프로덕트의 기술과 개발 회고 내용을 소개합니다(초기에는 UX, 솔루션을 포함하였으나 개발 내용 중심으로 변화 중!). 위에서 소개드린 SK데보션 및 T Academy, 외부 개발자 포털(코드너리, TechBlogPosts)와도 연계되어 있구요. 블로그와 함께 개발자 페이스북을 함께 운영 중입니다(SK플래닛 개발자 활동, 팔로워 약 4.6천). 덧. SK플래닛 초기에는 'README'라는 블로그를 2012년 오픈하여 2018년 11번가 분사 전까지 운영했습니다.• SK플래닛 구 블로그(아카이브): https://web.archive.org/web/20190116065552/http://readme.skplanet.com/11번가에서 운영 중인 테크 블로그입니다. 2021년 오픈하였으며 Java, Spring, AWS 개발 및 배포 사례 등 서버 및 클라우드 기술 중심으로 포스팅합니다.음악 서비스 FLO를 개발하는 드림어스컴퍼니에서 운영하는 블로그입니다. 기술뿐만 아니라 회사 컬처 등을 함께 외부에 소개하고 있으며, 기술 카테고리에서 커버하는 내용은 앱 개발, 서버, 추천 기술 등 다양한 카테고리를 포함합니다.TMAP을 개발 및 서비스하는 티맵모빌리티의 블로그입니다. 브런치를 활용하고 있으며, TMAP 개발자들이 직접 쓰는 테크노트 중심의 글들을 포스팅한다는 컨셉으로 외부에 기술을 공유합니다.2024년 12월 모던한 분위기의 원스토어 기술블로그를 새롭게 오픈하였습니다. 많은 관심과 참고 부탁드립니다! (회사 사이트 메뉴에 블로그 메뉴가 포함되어 있습니다)SK쉴더스 회사 사이트에 블로그 메뉴가 포함되어 있습니다. 독특한 것은 정보보안 블로그와 물리보안 블로그가 별도로 운영된다는 점입니다(참고로 SK쉴더스는 예전에 SK인포섹과 ADT캡스라는 두 개의 회사가 하나로 합쳐진 회사여서, 각각의 사업 영역에 맞는 블로그를 운영하는 것 같습니다).지금까지 SK ICT 패밀리사 중심으로 운영되었거나 운영 중인 다양한 기술 블로그들을 소개하였습니다(작년보다 더 많아졌네요!). 혹시 빠진 내용이나 보완할 부분이 있다면 알려주시면 감사하겠습니다. 이들 블로그들이 SK그룹 내 개발자뿐만 아니라 외부의 개발자들과도 공유 및 소통하며 서로가 성장하는 도구로 잘 활용되기를 바랍니다. 읽어 주셔서 감사합니다.