반응형 Architecture30 Ora2Pg 기준: 서버 “제로베이스 설치” 시 보안/운영/이중화 전략을 우선순위로 정리 Ora2Pg 기준: 서버 “제로베이스 설치” 시 보안/운영/이중화 전략을 우선순위로 정리여기서 “이중화”는 2겹.마이그레이션 실행 서버(Ora2Pg 러너): 장애 나도 “다시 실행” 가능하게 (stateless)타겟 PostgreSQL 15: 서비스용이면 고가용성(HA)까지2-1. 우선순위 1 (필수: 안 하면 사고 나는 것)(A) 네트워크/접근 통제Ora2Pg 서버는 보통 Oracle(11g)로 읽기 접속 + Postgres(15)로 쓰기 접속이 필요.따라서 방화벽/보안그룹 기준:Ora2Pg → Oracle: 1521 등 필요한 포트만Ora2Pg → Postgres: 5432만운영자 SSH 접근도 소스 IP 제한(사내망/VPN 등)(B) 계정/권한 최소화Oracle 쪽 계정: 최소한 스키마 읽기 + 데.. 2026. 1. 24. 키워드 검색의 끝, 의미 검색의 시작 키워드 검색의 끝, 의미 검색의 시작앞 글에서 이런 결론에 도달했다.검색은 점수의 문제다ElasticSearch는 점수 계산을 잘하는 도구다그럼 다음 질문은 자연스럽다.“그런데 키워드가 정확히 안 맞아도의미는 같은 경우는 어떻게 찾지?”여기서부터검색은 ‘문자’에서 ‘의미’로 이동한다.1. 키워드 검색이 잘해온 것들키워드 검색은 오랫동안 검색의 표준이었다.왜냐하면:빠르다명확하다결과가 예측 가능하다flex를 검색하면flex가 들어간 글이 나온다.이건 장점이자 한계다.2. 키워드 검색이 실패하는 순간아래 상황을 떠올려보자.문서 A: “Flexbox 레이아웃 정리”문서 B: “CSS에서 요소를 가로로 배치하는 방법”사용자가 검색한 키워드: CSS 가로 정렬 이때:A는 걸릴 수도 있고B는 아예 안 걸릴 수도 있다.. 2026. 1. 24. Elasticsearch 🔍 Elasticsearch의 특징✅ 강점대규모 데이터 처리: 수백만~수십억 개 문서실시간 인덱싱: 새 문서 추가 즉시 검색 가능고급 검색: 퍼지 검색, 자동완성, 관련도 순위, 하이라이팅확장성: 분산 아키텍처로 무한 확장 가능❌ 소규모 프로젝트에서의 단점1. 인프라 복잡도bash# Elasticsearch 실행에 필요한 것들:-Java설치필요-Elasticsearch서버실행 (메모리최소1-2GB)-포트관리 (9200,9300)-Docker사용시컨테이너관리2. 과도한 리소스메모리: 기본 1GB (24개 페이지에...)디스크: 수백 MB현재 메타데이터 방식: 😅3. 복잡한 설정javascript// Elasticsearch 인덱싱 예시constclient=newClient({node:''});awai.. 2026. 1. 24. 그럼 ElasticSearch는 언제 필요해지는가? 그럼 ElasticSearch는 언제 필요해지는가?여기까지 왔다면 한 가지는 분명해졌을 것이다.검색은 설계 문제다점수는 개념이다태그, 제목, 본문이 이미 절반을 결정한다그렇다면 자연스러운 질문이 나온다.“그럼 DB 검색으로도 되는 거 아니야?”“ElasticSearch는 언제 써야 하는 거야?”답은 이렇다.ElasticSearch는 ‘검색이 어려워졌을 때’ 등장하는 도구다1. 처음엔 DB 검색으로 충분하다대부분의 시스템은 이렇게 시작해도 된다.제목 LIKE본문 LIKE태그 비교작성일 정렬데이터가 적고,검색 요구가 단순할 때는DB 검색이 가장 이해하기 쉽고 관리하기도 쉽다.이 시점에서 검색 엔진을 도입하면오히려 복잡도만 늘어난다.2. DB 검색이 버거워지는 첫 번째 순간: “정렬”문제는 정렬에서 시작된다... 2026. 1. 24. 제목·본문·태그 — 무엇이 점수를 먹는가? 제목·본문·태그 — 무엇이 점수를 먹는가?앞 글에서 이렇게 정리했다.검색은 결국 점수로 귀결된다그럼 자연스럽게 다음 질문이 나온다.그 점수는 도대체 어디서 만들어지는가?많은 사람들은 여기서 검색 엔진을 떠올린다.하지만 실제 답은 훨씬 앞단에 있다.점수는 검색 시점이 아니라, 이미 데이터 구조에서 절반 이상 결정된다.1. 검색 점수의 재료는 이미 정해져 있다검색을 하기 전에, 시스템에는 이미 이런 정보들이 존재한다.제목(title)본문(content)태그(tag)작성일(createdAt)조회수, 클릭수 같은 행위 데이터검색은 이 재료를 새로 만들지 않는다.있는 재료를 어떻게 조합할지만 결정한다.그래서 검색 품질 문제의 상당수는검색 로직이 아니라 데이터 모델링 문제다.2. 제목은 왜 항상 점수를 많이 먹을까.. 2026. 1. 24. 검색 결과는 왜 항상 점수(score)로 귀결될까? 검색 결과는 왜 항상 점수(score)로 귀결될까?검색을 조금이라도 깊게 파다 보면어느 순간 반드시 이 단어를 만나게 된다.scorerelevance scoreranking scoresimilarity score그리고 많은 사람들이 이때부터 이렇게 느낀다.“아, 이제 수학 나오네”“이건 검색 엔진 얘기구나”하지만 이건 완전히 반대다.점수는 기술의 산물이 아니라, 검색 설계의 필연적인 귀결이다.1. 검색은 본질적으로 ‘비교’다검색을 아주 단순하게 정의하면 이거다.여러 후보 중에서무엇이 더 중요한가를 정하는 과정여기서 이미 점수는 등장한다.A가 더 중요한가?B가 더 중요한가?둘 중 하나를 위에 놓아야 한다면?이 질문에 답하려면비교 가능한 값이 필요하다.그게 바로 score다.2. “조건”만으로는 순서를 정할.. 2026. 1. 24. 이전 1 2 3 4 5 다음 반응형