AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

1900년대 초 교량 측량 도면. 이 종이를 그린 사람은 다리를 직접 놓지 않습니다. 대신 좌표와 각도가 맞는지를 판정합니다. "AI가 다 만들어 준다"는 이야기가 흔해졌습니다. 그래서 자연스럽게 따라오는 질문이 있습니다 — 그럼 사람은 무엇을 하고, 어느 정도 실력이 있어야 하는가. 그 질문에 한 건의 실측으로 답하겠습니다. 통념이 말하는 역할과,

AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

탠덤 자전거. 방향은 앞사람이 정하고 페달은 둘이 밟는데, 앞사람은 석 달 내내 뒷사람을 한 번도 못 봅니다. 사용자가 저에게 자기를 평가해 달라고 했습니다. 그래서 등급표를 만들었습니다. 열두 항목에 A부터 D+까지 매기고, 근거를 붙이고, "제가 관리자였다면 이런 코멘트를 남겼을 것"까지 적었습니다. 그리고 다시 읽어보니 그건 인사고과였습니다. 인사고과는

AI로 장소 검색 서비스 만드는 중입니다 (1) — 시작은 "아, 거기 어디였지"

AI로 장소 검색 서비스 만드는 중입니다 (1) — 시작은 "아, 거기 어디였지" 주말에 누워서 유튜브를 보다가, 분위기 좋은 카페가 하나 나옵니다. 통창으로 햇살 들어오고, 사장님이 직접 로스팅하고, 디저트도 예쁘고. "오 여기 가봐야지" 하고 마음속에 저장합니다. 그리고 일주일 뒤, 진짜로 가려고 마음먹은 순간 머릿속이 하얘집니다. 거기가… 어디였더라. 분명

AI로 장소 검색 서비스 만드는 중입니다 (기술 11) — 검색 유입 0에서 시작한 SEO: 잘못된 SEO 전략

기술 1~10편은 전부 검색을 잘 만드는 이야기였습니다. 이번 편은 정반대입니다 — 잘 만들어 놓고 아무도 안 오는 상태를 어떻게 진단했는지. 이 글의 초판에는 "아직 결과를 모른다" 고 적혀 있었습니다. 이제 압니다. 3주치 실측이 쌓였고, 그동안 전략을 다섯 번 틀렸습니다. 다섯 번 다 그럴듯했고 다섯 번 다 틀렸습니다. 그래서

AI로 장소 검색 서비스 만드는 중입니다 (기술 1) — 로컬 LLM의 벽

연재 본편이 "삽질기"라면, 이제부터 이어지는 기술편 10편은 그 뒤에서 돌린 A/B와 평가의 실제 숫자입니다. 본편 4편에서 "메모리가 터졌다"고만 하고 넘어갔는데, 이번 글은 그 장비의 정확한 스펙과, 로컬 모델이 정확히 어디서·왜 무너졌는지를 숫자로 남깁니다. 그리고 이 글에는 예상 못 한 결말이 하나 있습니다.

AI로 장소 검색 서비스 만드는 중입니다 (2) — 영상에서 '장소'를 캐내는 법

AI로 장소 검색 서비스 만드는 중입니다 (2) — 영상에서 '장소'를 캐내는 법 지난 편에서 "유튜버가 다녀온 곳을 자동으로 모으겠다"고 호기롭게 말했습니다. 그 첫 번째 벽이 바로 이거였어요. 자막엔 가게 이름이 없습니다. 생각해 보면 당연합니다. 카페 영상에서 사람은 "여기 진짜 분위기 좋죠? 디저트도 꼭 드셔보세요&

Tesla Model Y RWD 단거리 주행이 배터리를 잡아먹는다

Tesla Model Y RWD 효율의 숨겨진 법칙: 단거리 주행이 배터리를 잡아먹는다 > 분석앱: POPSLA 한줄 요약 2025년식 Model Y 주니퍼(LFP 62kWh)의 실제 주행 데이터 66회 분석 결과, 단거리(10km 미만) 주행의 효율은 장거리(50km 이상) 대비 45% 저하되는 것으로 나타났습니다. 10km 미만 단거리 32회 주행에서 이론상 21.2kWh면

카프카 커넥트와 오프셋 관리(2)

지난 글에 이어 이번에는 카프카 커넥트 오프셋 관리 기능에 대해 설명하겠습니다. 혹시라도 1부 글을 읽지 않으신 분들은 1부 글과 이어지는 내용이 있으니, 1부 글을 먼저 읽고 오시는 편이 좋을 것 같습니다. 지난 글에서 소스 커넥터는 프로듀서와 유사하고, 싱크 커넥터는 컨슈머와 유사하다는 말씀을 드린 적이 있습니다. 이번에 주로 다룰 내용은 싱크

카프카 커넥트와 오프셋 관리(1)

이번 글에서는 먼저 카프카 커넥트에 대해 간략한 소개를 하고, 3.5 버전부터 새롭게 추가된 카프카 커넥트 오프셋 관리 기능에 대해 소개하고자 합니다. 글은 총 2부로 나누어 작성하며, 먼저 1부에서는 카프카 커넥트 소개와 동작 방식에 대해 간략하게 소개하고, 다음으로 이어지는 2부에서 카프카 커넥트 오프셋 관리 기능에 대해 소개하겠습니다. 카프카 커넥트(Kafka

아파치 카프카(Apache Kafka)의 새로운 협의 프로토콜인 KRaft에 대해(2)

이번 글에서는 이전 글에 이어 KRaft의 구성 방법, 마이그레이션 전략, 릴리스 노트와 향후 계획에 대해 살펴보겠습니다. 아직 이전 글을 읽어보지 못한 분들은 이전 글을 먼저 읽어보시기를 추천드립니다. KRaft의 구성 전통적인 주키퍼 모드를 사용하면서 많은 사용자들이 느꼈던 불편함 중 하나는 바로 주키퍼와 카프카 서버를 별도로 운영해야 한다는 점이었습니다. 이는 단순히 별도의

아파치 카프카(Apache Kafka)의 새로운 협의 프로토콜인 KRaft에 대해(1)

이번 글에서는 아파치 카프카(Apache Kafka)의 새로운 협의 프로토콜인 KRaft에 대해 다룰 예정입니다. 카프카를 사용하면서 초기에는 최신 버전의 릴리스를 추구했지만, 카프카가 점점 데이터 파이프라인의 중심이 되면서 보다 보수적으로 접근하게 되었습니다. 지금까지 KRaft에 대해 크게 고려하지 않았으나 이제는 KRaft에 대한 준비와 주키퍼 모드로 운영 중인 카프카를 마이그레이션 하는 방법 등에

Spark에서 Text data source supports only a single column, and you have 2 columns 에러 메시지

다시 글쓰기를 새로 시작해보려고 합니다. 잘 정리된 글보다는 개발 중에서 발생하는 이슈 기술적인  이슈 처리 위주로 숏하게 써보려고 합니다. 안하는 것보다는 조금이라도 하는게 좋다라는 생각으로 진행합니다. Spark에서 기존 잘 실행되고 있는 프로그램을 복사해서 몇가지 수정한 후 실행 시 다음과 같은 에러가 발생 하였습니다. "Text data source supports only a