一旦保存 : Brain External Storage

앞서 검색엔진 내부에서 형태소 분석기가 문장을 어떻게 칼질하는지 알맹이를 파헤쳤다. 엔진 속사정을 알고 나니 이제 내 시선은 시스템 아키텍처로 향했다. "근데 애초에 오라클이나 MySQL에 있는 그 수천만 건의 데이터를 어떻게 검색엔진으로 안전하게 옮겨오는 거지?" 실무에서 시니어 선임님들이 가장 신경 쓰고장애가 나면 백엔드가 발칵 뒤집히는 구간이 바로 여기다. 오늘 다룰 내용은 검색엔진으로 데이터를 밀어 넣는 거대한 다리인색인(Indexing)과 인덱서(Indexer) 시스템에 대한 이야기다.검색엔진에서 '색인(Indexing)'의 진짜 의미 우리가 흔히 RDB에서 말하는 "인덱스(Index) 탄다"의 인덱스는 조회 속도를 높이기 위한 색인 기능을 의미한다.하지만 검색엔진 생태계에서 '색인(Indexi..

지난번 OpenSearch와 Elasticsearch의 역사적(?) 관계를 정리하면서검색엔진이 빠른 이유가 '역색인(Inverted Index) 장부' 덕분이라는 것까지는 완벽히 마스터했다. 공부할수록 꼬꼬무..."검색엔진은 도대체 어떤 기준으로 문장을 쪼개서 장부에 등록하는 걸까?" 우리가 "아이유가 부르는 좋은 날"이라는 문장을 던졌을 때이 녀석이 '아이유', '부르는', '좋은', '날'로 이쁘게 칼질을 해주는 비결. 그것이 바로 오늘 파헤칠 검색엔진의 심장 형태소 분석기(Analyzer)다. 이건 ES냐 오픈서치냐의 문제가 아니라 모든 텍스트 검색엔진의 '근본'에 가깝다.Analyzer(분석기)란 무엇인가? 쉽게 말해 분석기는 인간이 쓰는 자연어 문장을 검색엔진이 장부에 등록하고 검색할 수 있도..

지난번 OpenSearch의 근본을 파헤치고 나니 자연스럽게 이 거대한 검색엔진 생태계의 '뿌리'이자 '지배자'인 Elasticsearch로 시선이 향했다. 실무에서 검색엔진을 논할 때 Elasticsearch를 빼놓고 이야기하는 것은 불가능에 가깝다. 선임님들이 "엘라스틱 서치 쿼리 좀 확인해 봐"라고 하실 때마다 대충 검색엔진이구나~ 하고 넘겼다면, 이제는 이 녀석이 왜 검색엔진의 대표 기술이 되었는지, 그리고 내가 이전에 정리했던 OpenSearch와는 도대체 어떤 관계인지 공부해 보았다.Elasticsearch란? (검색엔진의 절대강자) 공식 문서나 기술 블로그를 보면 Elasticsearch를 다음과 같이 정의한다. "Elasticsearch는 Apache Lucene(루씬) 기반의 분산형 ..

감자가 된 지 어엿한 3년 차, 드디어 검색엔진이라는 거대한 벽(이자 신세계)을 마주했다. 그동안 선임님이 멋지게 구축해 두신 시스템 덕분에 오픈소스 검색엔진을 다루는 것 자체는 큰 어려움이 없었다. 하지만 서비스가 커지고, 계속해서 튜닝 작업을 거치며 다양한 방식으로 검색엔진을 접하다 보니 문득 이런 생각이 들었다. "이 녀석은 도대체 내부가 어떻게 돌아가길래 이렇게 빠른 걸까?" 역시 근본을 알아야 제대로 쓸 수 있는 법. 나와 같은 감자들을 위해, 그리고 미래의 나를 위해 OpenSearch의 핵심 개념을 정리해 보았다.검색엔진이란? (데이터를 '저장'하는 곳이 아니다) 많은 이들이 검색엔진을 단순한 '데이터 저장소'로 오해하곤 한다. 하지만 검색엔진의 본질은 데이터를 단순히 쌓아두는 시스템이 아..

요즘 들어 코드를 직접 “작성하는 시간”보다, 엔터를 치는 시간이 더 많아졌다.AI가 물어보면 YES 라는 대답만 할 뿐이다. 그동안은 AI에게 문제를 알려주고 소스를 제공하여 힌트를 얻는 정도였다.결국 문제 해결은 개발자가 했고, AI는 구글링을 하지 않아도 되는 보조 도구에 가까웠다. 어디까지나 “내가 중심”이라는 느낌이 있었다. 그런데 에이전트라는 개념이 등장하고, 회사에서도 Claude Code 같은 도구를 적극적으로 도입하면서 흐름이 완전히 달라졌다.이제는 내가 코드를 짜는 게 아니라, AI가 만들어낸 결과를 받아보는 형태에 가까워졌다. 물론 검증은 필요했기 때문에 AI가 결과물을 100% 만들어도 개발자로서 일말의 자부심은 남아있었다.하지만 솔직히 말하면, 요즘 결과물은 “검증이 의미가 있나?..

Dev Journal이라는 카테고리를 따로 만들었다. 개발 시장은 생각보다 훨씬 빠르게 변하고 있다. 불과 몇 년 전만 해도 안정적이라고 여겨지던 직군에서도 이제는 권고사직이나 구조조정이 자연스럽게 언급되는 분위기가 되었고, 더 이상 남의 이야기가 아니라는 걸 체감하게 된다. 이 변화의 속도는 개인이 준비하는 속도보다 훨씬 빠르다. 나 역시 빠르게 커리어를 시작한 편은 아니다. 이제 겨우 3년 차에 들어서는 시점이고, 아직도 배워야 할 것들이 훨씬 많다고 느낀다. 그래서 그동안은 비교적 전통적인 방식으로 준비하려고 했다. Kafka, 알고리즘, 코딩 테스트처럼 ‘언젠가는 반드시 필요하다’고 여겨지는 것들을 차근차근 쌓아가면 된다고 생각했다. 그런데 AI를 실제 업무에 활용하기 시작하면서, 이 전제가 ..

내 계정이 해킹당하는 건 "운이 나쁜 사람"에게만 일어나는 일이 아니다.오늘 이 글을 읽고 나면, MFA가 왜 선택이 아닌 기본인지 이해하게 될 것이다. 왜 비밀번호만으로는 안 될까? 기존 로그인 방식은 대부분 아이디 + 비밀번호 하나에만 의존하고 있다. 그런데 이 방식은 생각보다 훨씬 취약하다. 비밀번호의 주요 취약점 ✓ 비밀번호 재사용 > 대부분의 사람들은 여러 사이트에서 동일한 비밀번호를 사용한다. 한 곳에서 유출되면 나머지도 모두 위험해진다. ✓ 피싱 공격 > 가짜 로그인 페이지를 통해 비밀번호를 탈취하는 방식으로, 매년 수백만 건의 피해가 발생한다. ✓ DB 유출 사고 > 서비스 서버가 해킹당하면 암호화된 비밀번호조차 무력화될 수 있다. ✓ 무차별 대입 공격..

[Auth] SSO(Single Sign-On, 싱글 사인온)란?SSO (Single Sign-On)은 유저가 하나의 자격 증명을 사용하여,한 번만 로그인하면 동일한 세션 중에 여러 서비스에 액세스 할 수 있는 인증 체계이다. SSO를 가장 쉽게 정의하면 "하나의 ID/PW로 모든 서chun-k.tistory.comSSO 구조를 조금 익히고 스켈레톤 코드를 짜기 전, 어떤 언어를 사용할지에 대해 잠깐 고민을 했다. 보안이 중요한 영역이다 보니 처음에는 자연스럽게 Java를 떠올렸다. Spring Security 기반 레퍼런스도 많고, 실제 기업 환경에서도 가장 많이 사용되는 조합이기 때문이다. 그런데 최근 Kotlin을 조금씩 사용해보고 있던 터라, “굳이 Java만 고집할 필요가 있을까?”라는 생각도 ..

SSO (Single Sign-On)은 유저가 하나의 자격 증명을 사용하여,한 번만 로그인하면 동일한 세션 중에 여러 서비스에 액세스 할 수 있는 인증 체계이다. SSO를 가장 쉽게 정의하면 "하나의 ID/PW로 모든 서비스를 여는 마스터 키 시스템"이라고 할 수 있을 것 같다. 예를 들면,구글 로그인 1번 → Gmail / YouTube / Drive 자동 로그인회사 포털 1번 → 그룹웨어 / ERP / 내부시스템 자동 접속 -> 매번 로그인을 하지 않아도 되는 이것이 SSO이다.SSO를 사용하는 이유SSO를 사용하지 않았던 기존 방식에서는 서비스마다 로그인을 해야 했고,서비스가 늘어날수록 아래와 같은 문제들이 함께 따라온다. ✓ 비밀번호를 서비스 갯수만큼 관리✓ 반복적인 인증으로 효율 저하✓ 계정 ..

2025년 1월 6일, Python으로 만든 대민 시스템을 배포했었다.그 당시 나는 리눅스를 보면 눈이 뒤로 넘어가고, 말도 제대로 못 하던 시절이었고배포라고 해봐야 쉘 스크립트만 실행하는 수준이었다. 배포 환경 세팅은 모두 팀장님이 해주셨고 나는 그저 주어진 스크립트를 실행하는 역할만 했다.그 이후 내가 담당했던 배포는 대부분 JAR / WAR 기반이었기 때문에 Python 서비스의 WSGI 설정을 직접 볼 일은 거의 없었다. 그러다 최근, uWSGI 프로세스가 죽지 않고 이중으로 기동되는 현상을 발견했고이 문제의 원인을 파악하고 조치하는 과정에서 “많이 늦었지만” WSGI를 다시 제대로 공부하게 되었다.WSGI(Web Server Gateway Interface)란 무엇인가? 한 줄로 정의하면 다음과..