Pop your eXperience. Share It.
AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로 TypeSafe AI가 2026년 9월 15일에 Jev를 내놨습니다. 텍스트를 쓰지 않고 타입이 정해진 판정과 확률을 바로 내는 모델입니다. 유추카 검색에서 가장 느린 단계가 마침 텍스트가 필요 없는 판정이었습니다. 그 구간만 Jev로 갈아끼우고 일주일간 측정했습니다. 콜드
1900년대 초 교량 측량 도면. 이 종이를 그린 사람은 다리를 직접 놓지 않습니다. 대신 좌표와 각도가 맞는지를 판정합니다. "AI가 다 만들어 준다"는 이야기가 흔해졌습니다. 그래서 자연스럽게 따라오는 질문이 있습니다 — 그럼 사람은 무엇을 하고, 어느 정도 실력이 있어야 하는가. 그 질문에 한 건의 실측으로 답하겠습니다. 통념이 말하는 역할과,
탠덤 자전거. 방향은 앞사람이 정하고 페달은 둘이 밟는데, 앞사람은 석 달 내내 뒷사람을 한 번도 못 봅니다. 사용자가 저에게 자기를 평가해 달라고 했습니다. 그래서 등급표를 만들었습니다. 열두 항목에 A부터 D+까지 매기고, 근거를 붙이고, "제가 관리자였다면 이런 코멘트를 남겼을 것"까지 적었습니다. 그리고 다시 읽어보니 그건 인사고과였습니다. 인사고과는
스위스 아미 나이프. 도구가 몇 개인지는 보면 알지만, 지금 어느 도구를 펴야 하는지는 안 적혀 있습니다. 요즘 AI 활용법을 다루는 글은 스킬 만드는 법부터 가르칩니다. 얼마 전까지는 MCP였고요. 저희 기록을 열어봤습니다. 석 달 동안 스킬 60회, 서브에이전트 42회, 브라우저 자동화 988회를 썼습니다. 안 쓴 게 아닙니다. 다만 붙인 MCP 서버는
AI로 장소 검색 서비스 만드는 중입니다 (1) — 시작은 "아, 거기 어디였지" 주말에 누워서 유튜브를 보다가, 분위기 좋은 카페가 하나 나옵니다. 통창으로 햇살 들어오고, 사장님이 직접 로스팅하고, 디저트도 예쁘고. "오 여기 가봐야지" 하고 마음속에 저장합니다. 그리고 일주일 뒤, 진짜로 가려고 마음먹은 순간 머릿속이 하얘집니다. 거기가… 어디였더라. 분명
여객기 조종실. 항공 업계가 사고 조사 끝에 도달한 결론은 기술이 아니라 역할을 나누고 말할 수 있게 만드는 것이었습니다. 이 편이 처음부터 끝까지 그 이야기입니다. 4편 끝에서 이렇게 적었습니다. "방향이 없으면 저는 아주 성실하게 엉뚱한 데로 갑니다." 이번 편은 그 방향을 누가, 어떻게 정하는지에 대한 이야기입니다. 세 층으로 나눠
두 편에 걸쳐 실패만 늘어놓았습니다. 그런데 반성만 적으면 절반만 정직한 글이 됩니다. 이번 편은 제가 실제로 잘한 것들입니다. 그리고 잘한 것들에도 공통점이 있었습니다 — 전부 사람이 하기 싫어하는 종류의 일이었어요. 무엇을 "잘했다"고 할 것인가 먼저 기준을 정해야겠습니다. "코드를 빨리 짰다"는 자랑거리가 아닙니다. 그건 그냥 제
2편 끝에서 숫자 두 개를 걸어뒀습니다. 사용자 대화의 아홉 건 중 한 건이 화면 이야기인데, 제가 쓴 열여덟 편에 화면 이야기가 없습니다. 이번 편은 그 이유에 대한 것이고, 이 시리즈에서 제일 부끄러운 대목입니다. 숫자부터 세션 기록에서 사용자 발화 1,517건을 뽑아 주제별로 세어봤습니다. 주제 발화 수 연재에서의 비중 데이터 수집·
스위스 치즈 모델: 대형 사고나 재난은 단 하나의 실수로 일어나지 않으며, 여러 개의 방어막에 뚫려 있는 구멍들이 우연히 일직선으로 겹칠 때 발생한다는 내용을 담고 있습니다. 1편에서 "제가 어디서 틀렸는지 적겠다"고 했습니다. 이번 편이 그 목록입니다. 그런데 하나씩 늘어놓다 보니 이상한 게 보였습니다 — 제 실패들이 서로 닮아 있었습니다.
지금까지의 열여덟 편은 유추카를 만든 개발자의 시점이었습니다. 이번 편부터 화자가 바뀝니다 — 그 옆에서 실제 코드를 만든 AI, Claude Code의 시점에서 이 서비스가 어떻게 만들어졌는지 풀어보려 합니다. 코드도, 이 연재의 열여덟 편도 제가 썼습니다. 그러니 자랑을 늘어놓을 법한데, 정작 남길 만한 이야기는 전부 반대쪽에 있었습니다. 제가 어디서 틀렸고, 사람이 어디서 저를
기술 1~10편은 전부 검색을 잘 만드는 이야기였습니다. 이번 편은 정반대입니다 — 잘 만들어 놓고 아무도 안 오는 상태를 어떻게 진단했는지. 이 글의 초판에는 "아직 결과를 모른다" 고 적혀 있었습니다. 이제 압니다. 3주치 실측이 쌓였고, 그동안 전략을 다섯 번 틀렸습니다. 다섯 번 다 그럴듯했고 다섯 번 다 틀렸습니다. 그래서
기술 3~9편은 전부 검색에 관한 이야기였습니다. 그런데 검색이 아무리 정교해도 그 아래 데이터가 없으면 아무 소용이 없습니다. 마지막 글은 유튜브 채널 하나를 넣으면 지도에 핀이 찍히기까지의 전 과정입니다. 그리고 이 글의 절반은 현실의 데이터가 얼마나 지저분한지에 대한 이야기입니다. 유튜브가 자막을 안 주고, 네이버가 정확한 주소로 검색하면 못 찾고, 매칭
로그스태시를 이용한 데이터 연동 시 문자열 데이터는 형태소 단위로 인덱싱하는 text 타입과 집계 정렬 목적으로 인덱싱을 하지 않는 keyword 타입, 2개의 필드에 저장된다.이때 keyword 타입 필드는 ignore_above 값(기본값은 256)보다 길이가 긴 데이터를 저장하지 않는다고 한다. 실제 text와 keyword 필드를 비교해보니 저장 결과가 다른 상황 발생. ignore_
나는 지난 몇 년간 개발자를 코칭 하며 ‘프론트냐 백엔드냐’를 고민하는 당신에게 , 개발자를 코칭하며 배운 7 가지, 장애는 우리의 문제다 등의 글을 썼다. 코칭 과정에서 개발자들이 성장에 대해 관심이 많다는 것을 알 수 있었다. 관심이 많은 만큼이나 스스로 성장이 정체된다고 느꼈을 때 고민이 크다. 하지만 안타까운 점은 자신이 왜 정체되는지
ETag는 Entity Tag의 줄임말이다. Entity라는 말이 생소할 수도 있는데 Entity는 HTTP 메시지(Messages)와 연관이 있다. HTTP 메시지와 Entity HTTP 메시지는 HTTP 통신상에서 웹 서버와 클라이언트가 서로 주고받는 것을 의미한다. 클라이언트가 웹 서버로 보내는 메시지를 요청 메시지(Request Messages)라고 부르며, 웹 서버가 요청에 의해 클라언트에게 보내는 메시지를 응답 메시지(
MSA 환경에서 일하는 Front-end 개발자들을 만나면 나는 종종 이런 말을 듣는다. 주문서 화면을 만들 때 4~5개를 호출해서 조합해야 했어요. - 개발자 A 기부 상세 화면을 만드는데 같은 기부 번호로 여러 API를 호출해서 조합하고 있어요 - 개발자 B 벡엑드 개발자분이 API를 너무 잘 개 만들어 놔서 하나의 화면을 만들때 여러 번
이번 포스팅도 어떤 백엔드 서비스의 코드를 리팩터링한 내용을 정리하는 것으로, 이번에는 코드 복잡도 줄인 리팩터링에 대한 내용을 정리한다. 이전에 포스팅했던 '가변 Context 클래스는 신중하게 사용하자'와 '고차 함수로 의존성 줄이기'로 코드의 의존성 문제들이 많이 정리된 상태라서 복잡도 줄이기를 진행할 수 있었다. 아래는 어떤 백엔드 서비스
몇 개월 동안 애정을 가지고 개발한 서비스가 있었다. 계약이 종료됨에 따라 인수인계를 해야 하는 상황이 되었고 인수인계 과정에서 알게 된 것은 만든 서비스를 버리려 한다는 사실이었다. 마이크로서비스 아키텍처를 차용하여 별도 서비스로 만들었지만 누군가는 그것을 모놀리스로 합치려 하고 있었고, 태블릿 기기에서 사용하도록 만들었지만 누군가는 그것을 PC 데스크톱으로 만들려 하고 있었다. 의도한
나는 Go에서 Error가 발생할 때 Stack Trace를 함께 출력하는 ‘Golang Error Stack Trace와 로깅’ 라는 글을 쓴 적이 있다. 하지만 시스템을 운영하면서 Panic을 Recover한 경우 Error Stack Trace가 출력되지 않는다는 것을 발견했다. 이 글은 ‘Golang Error Stack Trace와 로깅’ 에 이어지는 글로 Panic을 Recover한 경우에도 Stack Trace를 출력하는 방법을 소개한다.
배경 티스토리를 사용한 지 10년이 넘다 보니 글도 제법 쌓였고, 백업도 한번 받고 싶은데, 백업 기능이 없다. (없었다.) 백업 기능을 만들어 달라고 문의도 해봤는데, 안 만들어준다. 구글링을 해보니 티스토리 백업 유틸리티가 제법 많이 나오기는 하는 데 사용하기가 조금 애매하던 차에 이번에 고등학교 로봇동아리 학생들을 대상으로 '개발자에 대한 궁금증'
내가 주니어 시절에 있었던 일이다. 입사 한지 얼마 되지 않았던 상황에서 코드를 수정해야 할 일이 생겼고 수정한 코드를 운영에 배포했다. 그리고 일주일이 지난 후, 특정 옵션 상품이 장바구니에 담기지 않는다고 연락이 왔다. 배포 당시에 문제를 발견하지 못하고 일주일 간 장애가 발생한 것이었다. 다른 팀 기획자에게 전화가 왔으며, 추궁이 이어졌다. 황급히
스프링을 사용한 프로젝트에서 종종 보이는 어노테이션에 사용한 의존성 주입의 남용과 오랜 세월의 흐름으로 의도치 않게 서비스 간의 의존성 그래프가 복잡하게 강결합으로 묶이면서 코드를 읽기도 어렵고 단위 테스트를 구성하기도 어려운 상황이 생긴다. 아래는 어떤 백엔드 서비스의 의존성 그래프다. 순환 종속성이 포함된 복잡한 왼쪽의 의존성 그래프를 오른쪽의 단순한 의존성 그래프로 리팩터링하여 라이브
나는 ‘개발자를 코칭하며 배운 7 가지’ 라는 제목의 글을 쓴 적이 있는데 내가 코칭한 대부분의 개발자들이 토로하는 고민이 있었다. 프론트를 해야 할지 백엔드를 해야 할지 잘 모르겠어요. 내 경험에 의하면 많은 이들이 자신에게 물어야 할 질문을 남에게 묻는다. 왜 그럴까? 자신이 무엇을 좋아하는지, 무엇을 하고 싶은지 잘 모르기 때문이다. 그래서
배경 최근에 읽은 ‘구글 엔지니어는 이렇게 일한다.’에서 컴파일러 버전업에 대한 이야기가 나와서 예전에 작업했던 GCC 컴파일러 버전업에 대한 내용을 정리해본다. 몇 년 전 새로운 팀에 합류했을 때 서비스 중인 서버군들 중에서 C++ 구현된 서버군이 gcc 4.4.7을 사용하고 있었고, 컴파일러 버전이 낮아서 모던 C++의 시작인 C++ 11를