%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4

서비스 만들기 삽질기와 기술 삽질기를 병행해서 올리고 있습니다. 이번 글은 기술 삽질기 입니다. "내 GPU"의 정체 — MacBook Pro M3 Max 이번 서비스를 만들면서 local llm을 경험해보고자, 맥미니 64GB 모델을 구매하려고 개인적으로 예산을 확보하는 중이었는데 단종되어 버리는 어처구니 없는 상황을 접하고, 맥스튜디오 64GB 모델은 가격이 이 세상 가격이 아닌 천상계 가격으로 올라가는 상황에서 어쩔수 없이 선택한 장비가 맥북 프로 M3 Max 입니다. 로컬 LLM을 돌린 장비는 이겁니다....

AI로 장소 검색 서비스 만드는 중입니다 (2) — 영상에서 '장소'를 캐내는 법 지난 편에서 "유튜버가 다녀온 곳을 자동으로 모으겠다"고 호기롭게 말했습니다. 그 첫 번째 벽이 바로 이거였어요. 자막엔 가게 이름이 없습니다. 생각해 보면 당연합니다. 카페 영상에서 사람은 "여기 진짜 분위기 좋죠? 디저트도 꼭 드셔보세요"라고 말하지, "지금 보시는 곳은 서울 성동구 성수동에 위치한 ○○카페입니다"라고 또박또박 말해주지 않습니다. 가게 이름은 화면 자막에 잠깐 떴다 사라지거나, 더보기란에 적혀 있거나, 아예 없습니다. 사람은 영상을 보면서 자연스럽게 "아 저 집이구나" 하지만, 컴퓨터에게 자막은 그냥 "여기 좋아요 디저트 맛있어요"라는 글자 덩어리일 뿐입니다. 그래서 이 편은...

AI로 장소 검색 서비스 만드는 중입니다 (1) — 시작은 "아, 거기 어디였지" 주말에 누워서 유튜브를 보다가, 분위기 좋은 카페가 하나 나옵니다. 통창으로 햇살 들어오고, 사장님이 직접 로스팅하고, 디저트도 예쁘고. "오 여기 가봐야지" 하고 마음속에 저장합니다. 그리고 일주일 뒤, 진짜로 가려고 마음먹은 순간 머릿속이 하얘집니다. 거기가… 어디였더라. 분명 봤는데. 채널 이름도 가물가물하고, 영상 제목엔 "서울 카페 투어 5곳"이라고만 적혀 있고, 20분짜리 영상 어디쯤에 30초 나왔던 그 가게를 다시 찾으려면 영상을 처음부터 돌려봐야 합니다. 더보기란을 뒤지고, 댓글을 뒤지고, 운이 좋으면 누군가 "3분 42초 카페 이름이 뭐예요?" 라고 물어봐 줬고, 대부분은 그냥 포기합니다. 저는 이걸 한두 번 겪은 게 아니라서, 어느 날 문득 이런 생각이 들었습니다....

Tesla Model Y RWD 효율의 숨겨진 법칙: 단거리 주행이 배터리를 잡아먹는다 > 분석앱: POPSLA 한줄 요약 2025년식 Model Y 주니퍼(LFP 62kWh)의 실제 주행 데이터 66회 분석 결과, 단거리(10km 미만) 주행의 효율은 장거리(50km 이상) 대비 45% 저하 되는 것으로 나타났습니다. 10km 미만 단거리 32회 주행에서 이론상 21.2kWh면 충분한 구간에 30kWh를 소모—약 **8.8kWh(29.5%)가 워밍업과 보조장치 작동에 '낭비'**된 셈입니다. 평균 속도 60km/h 이상에서는 7.0km/kWh 라는 놀라운 효율을 기록한 반면, 10km/h 미만 저속 구간은...

지난 글에 이어 이번에는 카프카 커넥트 오프셋 관리 기능에 대해 설명하겠습니다. 혹시라도 1부 글 을 읽지 않으신 분들은 1부 글과 이어지는 내용이 있으니, 1부 글을 먼저 읽고 오시는 편이 좋을 것 같습니다. 지난 글에서 소스 커넥터는 프로듀서와 유사하고, 싱크 커넥터는 컨슈머와 유사하다는 말씀을 드린 적이 있습니다. 이번에 주로 다룰 내용은 싱크 커넥터와 오프셋 관련된 부분이므로 참고하시기 바랍니다. 싱크 커넥터와 오프셋 싱크 커넥터는 컨슈머와 유사한 기능을 하며, 카프카의 토픽에서 데이터를 읽은 뒤 싱크 시스템으로 전송하는 역할을 합니다. 컨슈머의 경우 카프카의 토픽에서 메시지를 읽어가게 되면, 컨슈머의 점검, 컨슈머의 확장, 컨슈머의 재시작 등을 유연하게 대응하기 위해 컨슈머가 메시지를 어디까지 읽었는지 위치를 표시하게 됩니다. 이러한 위치를 카프카에서는 오프셋이라고 하고, 컨슈머 그룹마다 오프셋 위치를 별도의 공간에 저장하게 됩니다. 컨슈머 그룹의 오프셋은 초기 카프카 버전에서는 주키퍼의 지노드에 저장하였습니다. 이는 성능상의 이슈로 현재 버전의 카프카에서는 카프카의 내부 토픽인 __consumer_offset 토픽에 저장하고 있습니다. 컨슈머...

이번 글에서는 먼저 카프카 커넥트에 대해 간략한 소개를 하고, 3.5 버전부터 새롭게 추가된 카프카 커넥트 오프셋 관리 기능에 대해 소개하고자 합니다. 글은 총 2부로 나누어 작성하며, 먼저 1부에서는 카프카 커넥트 소개와 동작 방식에 대해 간략하게 소개하고, 다음으로 이어지는 2부에서 카프카 커넥트 오프셋 관리 기능에 대해 소개하겠습니다. 카프카 커넥트(Kafka Connect)란? 카프카 커넥트는 아파치 카프카(Apache Kafka)와 다른 시스템 간에 데이터를 보내고 받을 수 있는 도구입니다. 소스 시스템에서 카프카로 데이터를 스트리밍 하거나 카프카에서 싱크 시스템으로 데이터를 스트리밍 하는 것에 중점을 두며, 고품질, 안정성, 고성능 등을 제공하여, 사용자 및 관리자가 유연하게 사용할 수 있습니다. 뿐만 아니라, REST API를 제공하여 별도의 코드 작성 없이 사용자가 원하는 커넥터를 생성, 삭제 등을 할 수 있는 장점도 가지고 있습니다....

이번 글에서는 이전 글에 이어 KRaft의 구성 방법, 마이그레이션 전략, 릴리스 노트와 향후 계획에 대해 살펴보겠습니다. 아직 이전 글 을 읽어보지 못한 분들은 이전 글을 먼저 읽어보시기를 추천드립니다. KRaft의 구성 전통적인 주키퍼 모드를 사용하면서 많은 사용자들이 느꼈던 불편함 중 하나는 바로 주키퍼와 카프카 서버를 별도로 운영해야 한다는 점이었습니다. 이는 단순히 별도의 애플리케이션 운영 관리를 넘어서, 추가로 별도의 물리적 서버 자원의 할당까지 포함하고 있습니다. 제가 받은 많은 질문 중 하나도, 주키퍼 물리 서버의 할당과 관련된 주제로, 주키퍼와 카프카를 동일한 서버에서 실행해도 되는지에 관한 것이었습니다. 사실 주키퍼는 카프카를 관리하는 역할을 하므로, 이상적으로는 카프카와 분리된 별도의 서버에서 운영하는 것을 권장합니다. 하지만 이는 강제성을 요구하는 것도 아니고, 서버의 리소스 제약이 있는 경우 주키퍼와 카프카를 동일한 서버에서 실행할 수도 있습니다. KRaft의 등장 이후 카프카 사용자들이 환영한 변화중 하나는 주키퍼의 의존성 제거입니다. 이는 애플리케이션의 관리 단순화뿐만 아니라, 물리적 서버의 리소스 절감도 가능하다고 생각했던 것 ...

이번 글에서는 아파치 카프카(Apache Kafka)의 새로운 협의 프로토콜인 KRaft에 대해 다룰 예정입니다. 카프카를 사용하면서 초기에는 최신 버전의 릴리스를 추구했지만, 카프카가 점점 데이터 파이프라인의 중심이 되면서 보다 보수적으로 접근하게 되었습니다. 지금까지 KRaft에 대해 크게 고려하지 않았으나 이제는 KRaft에 대한 준비와 주키퍼 모드로 운영 중인 카프카를 마이그레이션 하는 방법 등에 대해서도 심도 있는 검토가 필요한 생각이 들었습니다. 이번에 새롭게 KRaft에 대한 자료 조사도 하고, 마이그레이션 테스트도 진행하면서 경험한 내용들을 간략히 공유하고자 합니다. 전체 글의 내용은 KRaft의 등장 배경과 중요성, 마이그레이션 전략, 릴리스 노트와 향후 계획 등을 설명하며, 총 2편으로 나누어 작성하겠습니다. 먼저 KRaft의 등장 배경과 중요성에 대해 살펴보겠습니다....

다시 글쓰기를 새로 시작해보려고 합니다. 잘 정리된 글보다는 개발 중에서 발생하는 이슈 기술적인  이슈 처리 위주로 숏하게 써보려고 합니다. 안하는 것보다는 조금이라도 하는게 좋다라는 생각으로 진행합니다. Spark에서 기존 잘 실행되고 있는 프로그램을 복사해서 몇가지 수정한 후 실행 시 다음과 같은 에러가 발생 하였습니다. 소스 코드 원인 위 에러 메시지는 Spark job 결과를 Text 파일로 저장할 경우 발생할 수 있는 에러 메시지인데 내용은 다음과 같습니다....

로그스태시를 이용한 데이터 연동 시 문자열 데이터는 형태소 단위로 인덱싱하는 text 타입과 집계 정렬 목적으로 인덱싱을 하지 않는 keyword 타입, 2개의 필드에 저장된다. 이때 keyword 타입 필드는 ignore_above 값 (기본값은 256) 보다 길이가 긴 데이터를 저장하지 않는다고 한다. 실제 text와 keyword 필드를 비교해보니 저장 결과가 다른 상황 발생. ­ ignore_above 수정. 재인덱싱 후 다시 비교해봤다. 필드 유실 없음. ­ agent 길이를 재보니 ignore_above 수정 전 유실된 데이터 개수와 256보다 길이가 긴 데이터 개수가 같다....