> ## Content Index > Fetch the complete content index at: https://blog.heimdex.co/llms.txt > Use this file to discover other available public pages before exploring further. # [heimdex people] kt connect에서 24시간 안에 이중화를 만들어야 한다면, 무엇을 포기하시겠습니까｜DevOps - URL: https://blog.heimdex.co/ko/heimdex-infrastructure-engineering-note-live-demo-24h-ko/ - Published: 2026-08-07T01:59:53.000Z - Updated: 2026-08-10T04:10:48.000Z - Description: KT 'AX 테크 커넥트 2026' 라이브 데모를 준비하며 24시간 내에 HA(고가용성)를 구축한 기록. 정석 대신 Active-Active 스크립트 기반 이중화, 수동 페일오버, 데이터 정합성 가드레일을 선택한 엔지니어링 의사결정과 회고를 공유합니다. - Author: Heimdex - Tags: #ko, Insights ## **하임덱스 인프라 엔지니어링 노트 — 라이브 데모 준비 기록** ## 안녕하세요, 하임덱스입니다. 👋 지난 7월, KT가 서울 서초 KT우면연구개발센터에서 「AX 테크 커넥트 2026」을 열었습니다. KT의 AX미래기술원이 주관해 자체 AI 모델 '믿:음 K'와 멀티모달 AI, 하이퍼 AI 네트워크 등 R&D 성과를 공개한 자리입니다. 하임덱스는 이 행사에 출품해, KT의 저지연 네트워크를 보여주는 장치로 실시간 영상 검색과 인물 매칭, 한·영·일 3개국어 번역 영상 해설을 시연했습니다. ### **하임덱스가 시연한 것** - **자연어 장면 검색** — "파란 트럭이 지나가는 장면"처럼 말로 설명하면 영상 속 해당 구간을 찾아냅니다 - **인물 매칭** — 얼굴 인식으로 특정 인물이 등장하는 구간만 모아 보여줍니다 - **한·영·일 3개국어 영상 해설 생성** — 장면을 분석해 해설 문장을 만들고, 세 개 언어로 이어서 생성합니다 - **처리 시간 비교** — 같은 모델과 같은 영상을 상용망과 KT 저지연 네트워크에서 각각 돌려, 처리 시간을 화면에 나란히 띄웠습니다 미리 만들어 둔 영상을 재생한 게 아닙니다. 관람객이 보는 앞에서 실제로 돌아갔고, 처리 시간이 화면에 실시간으로 표시됐습니다. 이 시연에 쓰인 하임덱스 시스템을 설계하고 운영한 사람은 올해 합류한 신입 개발자였습니다. 개발팀 박지석 님이 직접 정리한 준비 기록을 인터뷰 형식으로 옮겼습니다. > 이 글에서 다루는 것은 **라이브 데모용으로 별도 구성해 운영한 하임덱스 자체 서버 환경**입니다. 고객사에 제공되는 운영 환경과도, 행사장 인프라와도 다른 별개의 구성입니다. --- ### **Q1\. 지석님, 자기소개와 이번에 맡으신 일을 간략히 설명해 주세요.** 안녕하세요, 하임덱스 개발팀 박지석입니다. 인프라와 풀스택을 담당하며 서버, 데이터베이스, 검색, 배포 등 서비스가 안정적으로 작동하도록 기반을 구축하는 일을 주로 맡고 있습니다. 입사 전 ROTC 장교로 복무하며 다진 집요함, 그리고 철저한 리허설을 통해 플랜 B를 마련해 두는 습관은 지금 제가 일하는 방식에도 깊게 남아 있습니다. 이번에는 시연에 쓰이는 하임덱스 시스템 설계와 현장 운영을 맡았습니다. 검색 요청을 처리하는 서버, 영상 분석 작업이 쌓이는 백로그, 검색 인덱스까지요. 대규모 라이브 데모는 처음이었고 "시연 중 서버 한 대가 죽어도 티 안 나게 즉시 복구해야 한다"는 조건이 붙어 있어서 솔직히 긴장됐습니다. 그래서 다소 과하다 싶을 만큼 여러 상황을 가정하며 리허설을 거듭했어요. ### **Q2\. 행사 2일 전에 구성을 바꾸셨다고요. 무슨 일이 있었나요?** 리허설을 반복해서 돌리다가 문제를 찾았습니다. 시연 시나리오를 실제 순서대로 계속 태워봤어요. 영상이 들어오고, 분석 작업이 백로그에 쌓이고, 인덱스가 갱신되고, 검색어가 들어오면 응답이 나가는 흐름입니다. 그러다 저희 서버 한 대가 죽는 경우에 대한 대안이 없다는 게 드러났어요. 평상시 서비스라면 몇 분 안에 복구하면 되는 일입니다. 그런데 시연은 다릅니다. 관람객이 화면을 보고 있는 그 몇 분이 없어요. 화면에 결과를 띄우는 게 저희 시스템이니까, 여기가 멈추면 시연 자체가 멈춥니다. 바로 팀에 공유했고, 내부 논의를 거쳐 이중화를 넣기로 결정했습니다. 외부에서 요구받은 게 아니라 저희가 정한 기준이었어요. 남은 시간을 계산해 보니 24시간이었습니다. ### **Q3\. 24시간 안에 정석대로 하는 건 불가능했을 텐데, 무엇을 포기하셨나요?** 관리형 서비스와 인프라 자동화 도구를 포기했습니다. 정석대로 하면 클라우드 관리형 서비스로 이중화를 구성하고 인프라를 코드로 관리합니다. 그게 맞는 방향이에요. 그런데 권한 설정하고 동작을 검증하는 데만 며칠이 걸립니다. 24시간 안에 시작해서 신뢰할 수 있는 상태까지 가는 건 불가능한 일정이었습니다. 그래서 기준을 다시 세웠어요. 이번 목표는 '이론상 완벽한 구축'이 아니라 '시연장에서 하임덱스의 검색·분석 성능을 무장애로 보여주는 것' 하나였습니다. 그 기준으로 보면 답이 달라집니다. 스크립트 기반의 Active-Active 구조로 방향을 틀었어요. A(Primary) 노드가 데이터 권위자를 맡고, B(Standby) 노드가 승격 준비를 마친 상태로 A의 데이터를 따라가는 방식입니다. 검증 가능한 범위로 좁히고, 대신 리허설을 반복해서 돌렸습니다. 여기서 중요했던 건 **포기한 게 무엇인지 정확히 적어둔 것**이에요. 나중에 무엇부터 정식으로 올려야 하는지가 그 문서에서 나왔습니다. ### **Q4\. 자동 Failover를 일부러 넣지 않으셨다고요. 엔지니어 입장에서 의외의 선택인데요.** 의도적으로 뺐습니다. 이번에 가장 오래 고민한 부분이에요. 자동 장애 조치는 평상시 운영에서는 당연히 필요합니다. 그런데 시연장이라는 특수 환경에서는 계산이 달라집니다. 자동화가 오판했을 때의 피해가, 사람이 몇 초 늦게 대응했을 때의 피해보다 훨씬 큽니다. > **스플릿 브레인 / 플래핑이란?** > 순간적인 네트워크 지연 때문에 시스템이 "메인 서버가 죽었나?" 하고 착각해서, 멀쩡한 서버를 꺼버리거나 껐다 켰다를 반복하는 오작동입니다. 라이브 데모는 저희 서버실이 아니라 외부 현장에서 돌아갑니다. 어떤 환경이든 순간적인 지연은 생길 수 있고, 그때 자동화가 멀쩡한 메인 서버를 내려버리면 관람객 앞에서 손쓸 방법이 없어요. 그래서 헬스체크가 여러 번 연속 실패하고, 엔지니어가 직접 실행을 확인해야만 승격이 일어나도록 이중 안전장치를 뒀습니다. 사전 리허설에서 측정해 보니 메인 서버가 죽어도 10초 내외 지연 후 B 서버가 트래픽을 전부 넘겨받고, 87초 만에 완전히 승격됐습니다. 시연 시나리오에서 감당 가능한 숫자였어요. 화려한 자동화보다 **결과를 예측할 수 있는 쪽**을 골랐습니다. ### **Q5\. 검색 데이터 동기화 쪽에도 공을 들이셨다고요.** 하임덱스는 영상을 장면 단위로 쪼개서 검색 인덱스로 만드는 게 핵심입니다. 그 인덱스가 어긋나면 검색 결과가 틀리게 나와요. 시연에서 그게 최악의 시나리오입니다. 서버가 죽는 건 눈에 보이니까 대응할 수 있지만, 틀린 결과는 그 자리에서 알아채기도 어렵습니다. 데이터베이스는 처음부터 실시간 스트리밍 복제로 운영 중이어서 지연이 거의 없었어요. 신경 써야 했던 건 검색 인덱스 쪽이었습니다. **주기적 무중단 리시드(Reseed)와 Alias 원자적 교체(Atomic Swap)** 를 구현했습니다. 백그라운드에서 Standby 노드에 최신 데이터를 다 준비해두고, 준비가 끝나면 무중단으로 '연결 스위치(Alias)'만 새 데이터로 바꾸는 방식이에요. 사용자 입장에서는 끊김이 없습니다. 여기에 두 가지를 더 넣었어요. **3중 지문 비교(Fingerprint Check)** — 전체 문서 개수만 비교하면 놓치는 케이스가 있습니다. 1건이 추가되고 1건이 삭제되면 개수가 같아서 정상으로 보여요. 그래서 문서 수, 비디오 ID별 개수, 최신 등록 시각까지 세 가지를 비교했습니다. **안전 가드레일** — 메인 서버(A)에 일시적인 조회 이상이 생기면, Standby(B)가 잘못된 데이터를 받아오는 게 아니라 기존 정상 상태를 유지하도록 했습니다. 동기화보다 정합성이 우선이라고 판단했어요. 이 구조 덕분에 데이터 차이를 빠르게 감지해 자동으로 맞췄고, 시연 중 검색이 멈추거나 틀린 결과를 낸 적은 한 번도 없었습니다. ### **Q6\. 현장에서는 어떻게 지켜보셨나요?** 노트북 한 대를 현장 통제실로 만들었어요. 자동 감시 프로그램이 짧은 주기로 서버 상태를 확인하고, 검색 데이터가 어긋났는지 점검해서 자동으로 최신화했습니다. 화면을 여러 판으로 나눠서 서버 상태, 리소스 사용량, 백로그가 얼마나 쌓였는지, Slack 알림을 한눈에 봤어요. 현장에서는 예상하지 못한 상황이 계속 생깁니다. 그때마다 대응 스크립트를 즉석으로 보완하면서 통제했어요. 리허설을 많이 돌려둔 덕에 어떤 신호가 위험한 신호인지는 이미 알고 있었습니다. ### **Q7\. KT 저지연 네트워크에서 돌려 본 소감은 어땠나요?** 개인적으로 이번에 가장 인상적이었던 부분입니다. 영상을 장면 단위로 쪼개고 문장을 만드는 작업은 연산과 데이터 이동이 계속 오갑니다. 그래서 네트워크 조건에 민감한데, 평소 저희 환경에서 돌릴 때와 체감이 확실히 달랐어요. 같은 모델, 같은 영상인데 기다리는 시간이 눈에 보이게 짧아집니다. 시연에서 상용망과 나란히 놓고 처리 시간을 띄운 것도 그래서였어요. 저희가 설명하지 않아도 화면 두 개만 보면 차이가 바로 보이니까요. 그 차이를 만든 게 저희 코드가 아니라 KT가 구축해 놓은 네트워크라는 게, 엔지니어 입장에서는 좀 부러운 경험이었습니다. 이런 인프라 위에서 우리 워크로드를 돌려볼 기회가 흔치는 않으니까요. ### **Q8\. 시연이 끝난 뒤 회고에서 무엇을 정리하셨나요?** **시연 환경의 요구사항과 상시 운영 환경의 요구사항을 문서로 분리했습니다.** 이번 회고의 결론은 그거였어요. 이번 구성은 24시간 안에 검증 가능한 상태를 만드는 게 목적이었습니다. 상시 운영은 목적이 다르니 기준도 달라야 합니다. 그래서 운영 환경 기준을 세 가지로 잡고 순서를 정했어요. - **인프라 코드화** — 설정을 전부 코드로 작성해 같은 환경을 버튼 하나로 재현 - **관리형 백엔드** — 이번에 만든 alias 교체·정합성 검증 로직은 유지하고, 복제 자체는 관리형 기능으로 대체 - **자동 장애 조치** — 사람의 개입 없이 시스템이 스스로 감지하고 교체 순서가 이렇게 잡힌 이유가 있습니다. 코드화가 먼저 되어야 나머지 두 개를 안전하게 검증할 수 있어요. 자동 페일오버를 먼저 붙이면, 이번에 걱정했던 오판 문제를 재현하기 어려운 환경에서 디버깅해야 합니다. ### **Q9\. 그다음 단계는 어떤 모습인가요?** Enterprise AI 솔루션에 걸맞은 시스템을 준비하고 있습니다. - **컨테이너 오케스트레이션** — 트래픽에 따라 자동으로 확장·축소되는 무중단 배포 환경 - **AI 파이프라인 신뢰성 강화** — 작업 요청이 몰려도 병목이 생기지 않도록, 대기열 깊이에 따라 AI 워커가 자동으로 늘어나는 구조 - **트레이싱** — 영상이 업로드되고 AI 분석을 거쳐 검색에 노출되기까지 전 과정을 요청 단위로 추적 마지막 항목이 개인적으로 가장 필요하다고 느낀 부분이에요. 이번에 문제가 생겼을 때 어느 단계에서 지연이 발생했는지 찾는 데 시간이 걸렸습니다. 추적이 되면 그 시간이 사라집니다. ### **Q10\. 마지막으로 총평 부탁드립니다.** 한 문장으로 정리하면 **"이번 데모는 사람이 지켜서 버틴 이중화로 성공했지만, 다음에는 시스템이 스스로 버티게 만들고 싶다"** 입니다. 24시간이라는 짧은 시간 안에서 정석적인 구조 대신, 직접 작성한 스크립트와 반복 리허설, 그리고 집요한 감시로 빈자리를 채웠습니다. 행사가 끝날 때까지 분할 모니터링 화면을 계속 주시하며 가시성을 확보해 나갔어요. 그래서 다음 프로젝트의 1순위 목표는, 이번에 검증한 로직을 바탕으로 감시와 장애 전환을 사람 손이 아닌 시스템에 맡기는 것입니다. 짧은 기간이었지만 오버엔지니어링 없이 필요한 만큼 빠르게 구현해 낸 점은 스스로 칭찬해주고 싶습니다. 동시에 관련 개념을 더 깊게 공부해야겠다는 과제도 얻었고요. 갈 길은 멀지만, 개발자로서 더 성장하고 싶다는 동기를 얻은 값진 경험이었습니다. --- ## 💡 하임덱스와 함께하실 분을 찾습니다. 하임덱스는 영상을 검색하는 AI를 만듭니다. 수천 시간 분량의 아카이브에서 "파란 트럭이 지나가는 장면", "이 인물이 나오는 구간"을 자연어로 찾아냅니다. 얼굴 인식으로 인물을 구분하고, 장면 단위로 무슨 일이 일어나는지 이해합니다. 그 이해를 바탕으로 자막이나 화면해설 초안도 만듭니다. 고객사 내부 환경에 직접 설치하는 온프레미스 구축도 지원합니다. 설립 7개월만에 빠른 성장을 하고 있습니다. - **엔비디아 인셉션**과 중기부·엔비디아 **엔업(N-Up) 2026**에 선정됐습니다 - **삼성화재로부터 프리시드 투자**를 유치했습니다. 보험 손해사정과 사기 탐지 과정의 영상 분석 수요가 접점이었습니다 - **LG헬로비전, 라이브나우** 등과 엔터프라이즈 PoC를 진행하고 있습니다 - 중앙대 PAI Lab과 2026 **산학협력 R&D**를 수행 중입니다 2025년 12월 광주에서 법인을 세우고 8개월 만에 온 지점입니다. ## 인프라를 맡으면 어떤 일을 하게 되나 영상 AI는 모델만으로 굴러가지 않습니다. 대용량 파일이 들어오고, GPU 작업이 큐에 쌓이고, 인덱스가 갱신되고, 그게 사용자 검색 응답으로 나가기까지 손댈 곳이 많습니다. 여기에 온프레미스 구축까지 들어가면 고객사 환경마다 조건이 달라집니다. 그래서 다루는 범위가 넓습니다. 이번 글의 지석님처럼, 합류한 지 얼마 안 돼도 시스템 하나를 통째로 맡고 판단까지 하게 됩니다. 그게 이 단계 회사의 단점이자 장점입니다. 지금은 기본기를 쌓는 단계입니다. 코드화, 관리형 전환, 자동화가 순서대로 앞에 놓여 있습니다. 이미 다 갖춰진 곳에서 운영을 배우는 것과, 무엇을 먼저 세울지 정하면서 만드는 것은 다른 경험입니다. 후자에 관심 있는 분이라면 이야기 나눠보고 싶습니다. 인프라 외에도 여러 직군에서 채용을 진행하고 있습니다. - **채용 문의**: \[[채용 공고 링크](https://heimdex-dev.notion.site/?pvs=74&ref=blog.heimdex.co)\] / [heimdex@heimdex.co](mailto:heimdex@heimdex.co) - **기술 도입 문의**: [https://www.heimdex.co/contact](https://www.heimdex.co/contact?ref=blog.heimdex.co)