PH NETWORK

AWS Bedrock Knowledge Base에 CSV 메타데이터 쉽게 등록하기

pilho — Mon, 3 Nov 2025 22:41:44 +0900

AWS Bedrock Knowledge Base(KB)에 장비 목록이 등록된 대용량 CSV 파일을 연결하려는데, 모든 행(row)을 개별 파일로 쪼개지 않고 메타데이터를 등록할 수 있는 방법을 소개합니다.

AWS User Guide: "Include metadata in a data source to improve knowledge base query"

목표

수천 개의 행(row)을 갖고 있는 CSV 파일 1개를 업로드하고, '본문 검색(Semantic Search)'과 '메타데이터 필터링(Filtering)'을 모두 사용해 검색 결과의 정확도를 높이는 것이 목표입니다.

JSON 설정 파일 분석

CSV 파일 업로드 시 필요한 JSON 설정의 핵심은 documentStructureConfiguration 객체입니다.

{
  "documentStructureConfiguration": {
    "type": "RECORD_BASED_STRUCTURE_METADATA",
    "recordBasedStructureMetadata": {
      "contentFields": [ ... ],
      "metadataFieldsSpecification": { ... }
    }
  }
}

각 항목을 자세히 살펴보겠습니다.

1. RECORD_BASED_STRUCTURE_METADATA

이것은 Bedrock에게 "이 파일은 행(Record) 기반으로 구성되어 있고, 메타데이터 규칙은 JSON 구조(Structure)"라고 알려주는 선언입니다.

2. contentFields

역할: 사용자가 자연어(질문)로 검색할 때, Bedrock이 의미를 분석하고 검색할 대상이 됩니다.
처리: 이 열의 텍스트는 '벡터 임베딩'이라는 과정을 거쳐 검색 가능한 상태가 됩니다.
제약사항: Bedrock KB는 현재 contentFields로 단 하나의 열(column)만 지원합니다.
예시: 메모 필드와 같이 자연어가 포함된 열을 지정하는 것이 좋습니다.

      "contentFields": [
        {
          "fieldName": "Comments"
        }
      ],

3. metadataFieldsSpecification

역할: 검색 결과를 좁힐 때 사용할 '태그(Tag)' 역할을 합니다.
처리: 이 열의 값들은 필터 조건(예: Role = 'Wireless' 또는 Site = 'BRANCH')으로만 사용되며, '메모' 필드는 해당되지 않습니다.
fieldsToInclude: 여기에 배열( [] ) 형식으로 필터로 사용하고 싶은 '모든 열 이름'을 나열하면 됩니다.

      "metadataFieldsSpecification": {
        "fieldsToInclude": [
          { "fieldName": "Name" },
          { "fieldName": "Status" },
          { "fieldName": "Site" },
          { "fieldName": "Role" },
          { "fieldName": "Manufacturer" }
          /* ...필터로 사용할 다른 모든 열... */
        ],
        "fieldsToExclude": []
      }

⚠️ metadataAttributes 는 언제 쓸까?

AWS 사용자 가이드(https://docs.aws.amazon.com/bedrock/latest/userguide/kb-metadata.html)의 JSON 예시를 보면 metadataAttributes: { "key": "value" } 같은 형식을 볼 수 있습니다. 이것은 단일 CSV 파일일에서 각 열의 필드를 설명할 때는 필요로 하지 않습니다.

fieldsToInclude 형식: CSV 파일 1개를 업로드할 때, 특정열(column)을 필터로 쓰라고 알려줄 때 사용하는 방법
metadataAttributes 형식: CSV 내의 모든 행(row)을 개별 파일로 쪼개서 업로드할 때. 즉, 수백 또는 수천 개의 콘텐츠/메타데이터 파일 쌍을 보유할때 사용하는 방법

✅ 최종 예시

Comments 열을 '자연어' 검색을 할 수 있게 선언하고, 나머지 25개의 열을 '필터'로 사용하는 최종 JSON 설정 예시입니다.

{
  "documentStructureConfiguration": {
    "type": "RECORD_BASED_STRUCTURE_METADATA",
    "recordBasedStructureMetadata": {
      
      "contentFields": [
        {
          "fieldName": "Comments"
        }
      ],

      "metadataFieldsSpecification": {
        "fieldsToInclude": [
          { "fieldName": "Name" },
          { "fieldName": "Status" },
          { "fieldName": "Tenant" },
          { "fieldName": "Site" },
          { "fieldName": "Location" },
          { "fieldName": "Rack" },
          { "fieldName": "Role" },
          { "fieldName": "Manufacturer" }
        ],
        
        "fieldsToExclude": []
      }
    }
  }
}

RADIUS 인증 실패 및 해결 사례

pilho — Mon, 3 Feb 2025 22:25:04 +0900

우아한기술블로그(https://techblog.woowahan.com/21324/)에 동일하게 작성된 글입니다.

RADIUS 네트워크 인증 환경에서는 보안 강화를 위해 공인인증서를 사용하며, 공인인증서는 매해 갱신 작업이 필요합니다. 하지만 인증서 갱신 과정에서 예상치 못한 클라이언트 인증 실패가 발생하였습니다.

이 글에서는 공인인증서(Globalsign) 갱신 이후 발생한 RADIUS 인증 실패 사례를 분석하고, 원인과 해결 과정을 공유합니다.

공인인증서 갱신 후 RADIUS 인증 실패 문제를 경험했거나, RADIUS 인증 프로세스, 인증서 체계에 관심 있는 독자에게 도움이 되길 바랍니다.

ℹ️ 참고: 이 글을 이해하려면 기업 내 네트워크 인증 운영과 RADIUS 및 EAP-TLS 인증 체계에 관한 기본 지식이 필요합니다.

배경

우아한형제들은 EAP-TLS(인증서) 인증을 사용 중이며, 모든 OS(Windows / MacOS 등)를 사용하는 환경입니다.

첫 발견은 매년 정기적으로 진행하는 도메인 공인인증서(Globalsign) 갱신 작업 후 이슈를 발견했습니다. 전사에서 사용 중인 클라이언트 네트워크 단말 인증이 실패하였고 이는 인증서 발급 대행사, RADIUS 인증서버 개발사, 협력사 모두 경험하지 못한 이슈였습니다.

원인

네트워크 단말 인증 실패에는 2가지 원인이 있었습니다.

1. 루트/중간 인증서가 변경되었습니다.

RADIUS/EAP 네트워크 인증서버에서 기존에 사용했던 루트 인증서가 Globalsign R6 루트인증서로 변경되었습니다. 변경된 루트인증서는 클라이언트 단말에서 신뢰할 수 없는 인증서였고 이로 인해 네트워크 인증 실패가 발생하였습니다.

변경된 사유는 아래와 같습니다.

Mozilla와 같은 주요 브라우저 개발사에서 루트 인증서 신뢰 기준 강화 발표
: 2025.04부터 더 이상 Globalsign R1 루트인증서(SHA-1 해시알고리즘 기반)를 신뢰하지 않음
GlobalSign은 업계 표준을 준수하기 위해 2024.03.13 이후 발급되는 인증서 R1 루트 배포중단
인증서 발급 대행사에서는 아래 내용을 중요하게 공지
: GlobalSign R1 Root 및 R1 Cross Root 배포 중단 안내(유서트;https://www.ucert.co.kr/board/view/all/8711/)

(글로벌 사인의 주요 루트인증서 비교)

루트 인증서	발급 시기	해시 알고리즘	유효 기간	브라우저 호환성	특징
R1	1999년	SHA-1	2028년 1월 28일까지	대부분의 구형 및 최신 브라우저와 호환	GlobalSign의 최초 루트 인증서로, SHA-1의 보안 취약점으로 인해 현재는 사용이 제한적입니다.
R3	2009년	SHA-256	2029년 3월 18일까지	대부분의 최신 브라우저와 호환	SHA-256 알고리즘을 사용하여 보안성이 강화되었으며, 현재 GlobalSign의 주요 비즈니스에 널리 사용되고 있습니다.
R6	2014년	SHA-384	2034년 12월 10일까지	최신 브라우저와 호환, 일부 구형 브라우저에서는 호환성 문제 발생 가능	SHA-384 알고리즘과 더 긴 키 길이를 사용하여 보안성이 더욱 강화되었으며, 최신 인증서 발급에 사용되고 있습니다.

2. RADIUS 인증 과정은 폐쇄망입니다.

RADIUS 인증 이전의 클라이언트 단말은 오프라인 상태와 동일합니다.(*LTE/5G 단말에서는 다를 수 있습니다) 따라서 단말은 로컬영역에 저장된 인증서를 기반으로 서버 인증서를 신뢰(Trust Chain)하게 됩니다. 온라인 상태에서는 중간 인증서가 없는 경우 CA Issuer URI를 사용해 인증서를 자동으로 가져오기도 합니다. 하지만 RADIUS 인증은 네트워크 연결을 위한 인증이기에 폐쇄망의 상태와 동일합니다.

아래 RADIUS 인증 플로우의 빨간색 영역(5a.)이 문제의 영역입니다. 클라이언트 단말(Supplicant)이 서버 인증서의 정합성 확인에 실패하였고 단말 인증이 실패됩니다. 제일 마지막 과정(12)까지 정상 통신이 되면 클라이언트 단말은 비로소 온라인 상태가 됩니다.

EAP-TLS: Breaking Into Secure TLS Deployments (https://www.thexero.co.uk/wifi/Breaking-EAP-TLS)

해결 과정

해결 방법도 크게 2가지가 있었습니다.

1. 클라이언트 단말에 '크로스 루트 인증서' 설치

2. 서버 인증서에 '크로스 루트 인증서' 추가

아래 운영 환경을 보면 두 번째 안이 훨씬 합리적인 해결 방법임을 알 수 있습니다.

2만 대 이상의 인증 단말
이 세상 모든 OS (Windows / MacOS / iOS / Android / Linux)
모바일 계열의 OS는 수동 설치가 어려움
채 1개월도 남지 않은 서버인증서 만료기한

두 번째 안의 경우 인증서 발급 대행사의 지원이 꼭 필요한 해결 방법이었습니다. 유서트 담당영업자 및 기술지원팀과 충분한 의사소통을 하였고, 기술 지원을 받아 해결할 수 있었습니다. 재차 교차 검증해 확인한 내용은 다음과 같습니다.

모질라 재단을 비롯한 글로벌 웹브라우저에서 2025년 4월 R1 루트 및 기존 체인을 비신뢰로 변경할 수 있음
R6/R1 Cross Chain(교차 체인)을 추가한 인증서는 글로벌 사인에서 공식적으로 발급하지 않는다. 따라서 우아한형제들에서 충분히 확인 후 사용 해야 한다.

저희가 최종 확인한 내용은 아래와 같습니다.

RADIUS 인증은 단말 프로비저닝시 관련 인증서를 별도 설치해 기존 루트 및 체인 인증서가 변경, 삭제되어도 문제 없음
R1 Root 인증서 만료(2028-01-28) 기간인 3년 후에는 R6 Root 인증서로 무중단 마이그레이션이 가능(단계적 단말교체 전략)

(인증서의 구조)

기존 인증서 체인형태	서버인증서 > R1Chain > R1 Root
새 인증서 체인형태	서버인증서 > R6Chain > R6 Root
크로스 루트 인증서 체인형태	서버인증서 > R6Chain > R6R1 Cross Chain > R1 Root

향후 방안

Globalsign에서는 폐쇄망 전용의 Multi-Year(다년) 인증서를 판매하는 것으로 확인해 사용 가능 여부를 확인하고 있습니다.
- We will continue to offer multi-year validity for Intranet SSL (privately trusted SSL/TLS) https://support.globalsign.com/ssl/general-ssl/397-day-maximum-tls-certificate-validity
새로 발급받는 서버 인증서 에 크로스루트(R6R1 Cross Chain)가 누락되어 있지 않은지 확인하는 과정이 당분간(R1 루트 만료일 전까지) 필요합니다.

이번 사례는 서버 인증서 갱신 작업 중 RADIUS 인증에 예기치 못한 이슈가 발생한 사례입니다.

네트워크 인증 서버에서는 레퍼런스를 찾아 볼 수 없었던 내용이기에 해결 사례를 공유합니다. 감사합니다.

자빅스: 그라파나에서 값비교 알럿 설정하기

pilho — Tue, 22 Oct 2024 00:13:40 +0900

그라파나 자빅스 소스에서 동시에 여러 메트릭을 N분 전 값과 동일한지 비교하고,

동일하지 않으면 알럿 발생을 설정하는 방법을 공유합니다.

스텝 1

먼저 값을 비교할 데이터를 불러옵니다.

A는 현재, B는 1분 전 값 입니다.

B에서는 1분전 값을 불러오기 위해 timeshift 함수를 사용합니다.

스텝 2

Reduce를 추가해 A와 B값을 정제합니다.

정제가 필요한 이유는 아래 GPT 설명을 추가해두겠습니다.

설정한 C와 D는 각각 Reduce 함수를 사용하여 쿼리 A와 쿼리 B의 결과를 단일 숫자 값으로 변환하는 역할을 합니다.
Reduce 함수는 여러 데이터 포인트 중에서 하나의 값을 선택하거나 계산하는 데 사용됩니다.

1. C (Reduce - Input A):
• 쿼리 A에서 데이터를 가져와 Reduce 함수를 통해 마지막 데이터 포인트를 사용하여 하나의 값으로 축약합니다.
• 여기서 설정된 함수는 Last, 즉 마지막 데이터 포인트를 선택합니다. • 이때, 쿼리 A는 'Total Number of APs' 항목의 현재 값을 반환하고, Reduce 함수는 이 값 중 가장 최근(마지막) 값을 선택하여 이를 이후 수식에서 사용할 수 있도록 합니다.

2. D (Reduce - Input B):
• 쿼리 B도 동일하게 'Total Number of APs' 항목의 데이터를 가져옵니다. 하지만 B 쿼리에는 timeShift(60s)가 적용되어 60초 전의 데이터를 가져오게 됩니다.
• 이후, Reduce 함수가 B 쿼리의 마지막 값(60초 전)을 사용하여 하나의 값으로 축약합니다. 즉, 쿼리 B는 60초 전의 데이터를 기준으로 가장 최근 값을 반환하게 됩니다.

C와 D를 사용하는 이유
• 쿼리 A와 B는 각각 현재 시점의 데이터와 60초 전 데이터를 반환합니다.
• C는 쿼리 A의 데이터를 마지막 값으로 축약하여 현재 값을 나타내고, D는 쿼리 B의 데이터를 마지막 값으로 축약하여 60초 전 값을 나타냅니다.
• 이후 E (Math)에서 이 두 값을 비교하여 그 차이를 구하게 됩니다. 즉, E = C - D는 현재 값과 60초 전 값의 차이를 나타냅니다.

왜 Reduce를 사용하나?
Grafana에서 쿼리가 반환하는 값은 일반적으로 시계열 데이터(여러 개의 데이터 포인트)입니다.
이 데이터들을 수식에서 바로 사용할 수 없기 때문에, Reduce 함수를 사용하여 여러 데이터 포인트 중 하나의 값(예: 마지막 값)을 선택하여 사용할 수 있게 하는 것입니다. 이렇게 하면 수식에서 두 시점의 값(현재와 과거)을 비교하는 것이 가능합니다.

결론
• C: 쿼리 A의 마지막 값을 가져와 하나의 값으로 축약.
• D: 쿼리 B(60초 전)의 마지막 값을 가져와 하나의 값으로 축약.

스텝 3

마지막으로 정제된 C와 D를 비교해 동일하지 않으면 알럿이 발생하도록 설정합니다.

E에서 C와 D의 차이를 계산하고, F (Threshold)에서 그 차이가 0 이상이면 알림을 발생시키는 방식입니다.

이 설정을 통해 시간 간의 값을 비교하는 알림 규칙을 설정할 수 있습니다.

B마트 주문 유실을 없애보자: 네트워크 편

pilho — Tue, 15 Oct 2024 17:12:59 +0900

우아한기술블로그(https://techblog.woowahan.com/17911/)에 동일하게 작성된 글입니다.

안녕하세요 오랜만에 인프라 네트워크와 관련된 경험을 공유하고자 글을 쓰게 되었습니다.

우아한형제들은 퀵커머스 사업에 집중하면서 배민비마트 서비스는 비약적으로 사업 규모가 커졌습니다. 이는 곧 네트워크 가용성이 비즈니스 성과에 직접적으로 영향을 미칠 수 있다고 볼 수 있습니다. 이 글은 비마트 비즈니스 연속성을 높이기 위해 네트워크 인프라에 어떤 노력을 기울였고, 최근 1년의 운영 성과는 어땠는지 공유드리려 합니다.

글 순서는 서비스 특징/분석, 운영 인프라 분석, 설계, 테스트, 배포, 성과 순서로 설명하겠습니다.

서비스 특징

먼저 비마트 서비스 특징에 대해 말씀드리겠습니다.
비마트는 퀵커머스 사업의 일종으로 주문 후 1시간 내에 구매한 물품이 고객에게 전달되어야 한다는 서비스 미션을 갖고 있습니다.

[비마트 광고 캡쳐, https://www.youtube.com/watch?v=mNWQDZIMrZA]

빠른 배달을 위해 거점 센터로 불리는 PPC [1] Picking and Packing Center가 서울 또는 대도시의 행정구/자치구마다 1-3개씩 나누어 있습니다. 이는 인프라 관리자 입장에서는 운영하기 좋은 환경이 아닌데요. 일반적으로 큰 규모(0,000평 이상)의 거점 센터가 있는 경우에는 인프라 설비(비용)를 많이 투자해 안정적인 네트워크 서비스를 운영할 수 있습니다. 하지만 여러 개의 형태로 센터가 분산되어 작게 운영되는 경우는 분산 투자를 해야 합니다. 그렇다고 각 센터의 중요도가 떨어진다 볼 수도 없습니다.
정리해 보면 비마트 인프라는 한정된 자원(비용)에서 센터의 인프라 가용성은 높게 유지해야 하는 미션이 있습니다.

[비마트 타임라인]

네트워크 가용성을 높게 유지하는 것은 모든 인프라 관리자에게 필수 목표지만, 왜 비마트에서 특히 더 강조되는지 궁금하실 수 있을 것 같습니다. 비마트는 고객 앞까지 물품이 배달되기 위해 주문을 포함해 위와 같이 총 7단계의 과정을 거치고 있습니다. 접수부터 배달 완료까지 60분 안에 처리되어야 하며, 이 중 센터 처리단계(접수부터 픽업 대기까지)에서는 10분 이상의 네트워크 단절이라도 발생한다면 서비스 목표(60분 이내 배달 완료)를 달성하지 못할 수도 있습니다.

운영 인프라 분석

서비스 특징과 분석에 대해 확인해 보았으니 다음으로 네트워크 고가용성을 유지하기 위해서는 어떤 부분을 개선하면 좋을지 보겠습니다.
비마트 PPC의 네트워크 인프라는 크게 네트워크 장비와 통신 사업자 회선으로 나눌 수 있습니다. 모두 이중화되어 있지는 않아 제일 쉽게 가용성을 높이는 방법은 장비, 회선을 이중화하는 것입니다. 다만 한정된 자원(비용) 안에서 둘 다 투자할 수는 없었습니다. 그래서 회선, 장비 두 가지 중 연중 장애 빈도와 파급력을 확인하고 무엇에 좀 더 집중해야 할지 우선순위를 매겨보기로 했습니다.

[연간 장애빈도와 장애시간 비교]

위 자료와 같이 연중 장애 발생 빈도가 높고, 파급력이 큰 것은 통신 사업자 회선이었습니다.
그 이유를 살펴보자면 제한된 자원(비용) 안에서 인터넷 회선에 투자가 어려웠습니다. 또한 회선 비용에 따라 SLA(Service-Level Agreement, 서비스 수준 계약)도 비례하다 보니 서비스 품질과 유지 보수(장애 신고) 대응 또한 좋지 않았습니다. 드물게 발생하는 지역/전국 단위의 회선 사업자 장애도 매우 큰 위험 요소였습니다. 따라서 우리는 동일 회선 사업자로 이중화하지 않고, 다른 회선 사업자를 추가해 이원화하는 방안이 필요했습니다.

[Google 기사검색]

이원화 사례로 2021년 KT아현지사 화재 사건을 떠 올릴 수 있었는데요. 이 문제로 며칠 동안 서울 서부지역의 인터넷 장애가 발생했지만 LTE 라우터를 사용한 스타벅스는 정상 영업을 할 수 있었습니다. 또한 입주 건물마다 특정 통신 사업자에 종속되어 다른 통신사는 사용하지 못하는 경우도 있기에 LTE 라우터가 비마트 환경에 적합하다고 판단하였습니다.

‘LTE 라우터’는 일반적으로 개인이 사용하는 ‘에그(와이파이 도시락과 같은 서비스)’와는 다른 법인사업자 제공 상품인데요. 에그 서비스가 LTE라우터 서비스보다 사용이 쉽고 이용요금이 저렴해, 다음과 같은 궁금증이 생길 수도 있을 것 같습니다. “에그가 LTE 라우터보다 비용이나 사용자경험상 더 유리한데 그냥 에그를 사용하면 안 되나?”
여기서 겉으로는 잘 보이지 않는 숨은 비용을 생각해 보아야 합니다. 바로 운영 비용입니다. 첫 번째가 사용자 교육 비용으로 만약 에그를 백업으로 사용한다면 내부망 연결과정부터 배터리 충전까지 모든 행동조치 요령을 운영자(사용자)들이 숙지할 수 있도록 도와주어야 합니다. 일관되게 학습되지 않았다면 최종적으로 그 피해는 서비스 미션을 달성하지 못하는 문제로 돌아올 것입니다. 두 번째는 네트워크 관리 비용입니다. 추가되는 통신회선만큼 관리자 운영비용(시간)도 증가하게 됩니다.

[간략 구성도]

그럼 지금까지 도출된 요구사항을 나열해 보겠습니다.

백업 회선 운영비용(금액)이 메인 회선에 비해 적어야 합니다.
메인 회선 장애 시에는 자동으로 절체되어 장애시간을 줄여야 합니다.
센터 회선은 서로 다른 사업자로 이원화해야 합니다.
회선 문제가 생겨도 사용자는 체감하지 못하도록 네트워크 환경을 제공해 주어야 합니다.
백업 회선 운영 리소스를 최소화해야 합니다.

[LTE라우터 서비스 비교]

LTE 라우터 상품 중에 어떤 요금제가 좋은 지도 고민이 필요한 영역입니다. 먼저 센터에서 필수로 필요한 업무가 무엇인지 파악해야 합니다. 무선 라우터는 유선 인터넷에 비해 빠를 수 없습니다. B사에서는 5G 상품도 있었으나 유선 인터넷의 품질, 속도 및 안정성 면에서 무선 라우터 서비스는 아직 비교할 수 없는 수준이라고 생각합니다.
다행히 비마트 백업망(LTE라우터)에서는 주문 처리만 잘 되면 되므로, 많은 트래픽과 대역폭이 요구되지 않았습니다. 다만 LTE 라우터에서는 일반적으로 핸드폰과 같이 트래픽 사용량에 따른 과금체계이다 보니, 백업 회선에서 발생하는 모니터링 트래픽이 문제였습니다. ICMP(Ping 체크)와 같은 모니터링 트래픽은 유선 인터넷 환경에서는 확인이 필요 없는 수준이지만, LTE 라우터에서는 굉장히 많은 양의 트래픽으로 집계되는 것을 알 수 있었습니다. 이 문제는 통신 사업자의 위탁서비스 사용 시 자체 모니터링이 필요하지 않아 해결할 수 있었습니다.

[PPC 유선인터넷/LTE라우터 회선비용]

최종적으로 A사가 우리에게 적합하다 판단했고, 요금 또한 결합요금제를 제공하여 유선 회선 비용 대비 8% 추가 비용만으로 백업 회선을 구축할 수 있었습니다.

인프라 설계

이제 모든 사전조사는 마쳤습니다. 간략한 네트워크 구성을 보며 설계안에 대해 말씀드리겠습니다.

[터널 및 라우팅 구성]

IDC와 연결된 IPSEC 터널 4개는 Routing AD(Administrative Distance) 설정으로 신속한 라우팅 전환과 더불어 평상시 WAN2에 발생하는 트래픽을 최소화하도록 설계하였습니다. WAN1에는 Link-monitor(대기 시간, 지터 및 패킷 손실 기반 링크 품질 측정 모니터링 방법)를 설정하여 특정 목적지에 몇 차례 도달하지 못하는 경우 라우팅이 비활성화 되어 차순위(2번째 IPSEC 터널) 경로가 활성화되도록 설계하였습니다. 이 설계 과정에서 IPSEC DPD(Dead Peer Detection) 값과 Link-monitor Fail-back 기준에 대해 많은 논의와 테스트를 관계 부서와 하였고 우리 환경에서 수용 가능한 범위의 최적 값을 찾아 적용할 수 있었습니다.

테스트 및 배포

테스트는 크게 2단계로 나누어 진행하였습니다.
첫 번째로 제일 주문이 많은 센터를 선정했고, 주문 처리 트래픽을 LTE 라우터로 분기 처리하여 며칠 동안 특이사항이 없는지 확인하였습니다. 생각지 못한 보조서비스(DNS, DHCP, NTP, RADIUS, 외부참조 소스 등)들이 발견되었고 이를 조치하는 좋은 기회가 되었습니다. 두 번째 테스트는 실제처럼 유선 인터넷을 완전히 분리하여 운영해 보았습니다. 다행히 큰 특이사항 없이 마무리되었습니다.

[LTE라우터 사용시의 트래픽 사용량 및 피크 대역폭 확인]

배포는 사업자 위탁서비스로 보다 편리하게 진행되었습니다. 위탁 업체에서 전국 곳곳에 있는 센터에 직접 방문하여 LTE 신호 세기 확인과 장비 설치까지 진행해, 관리자는 일정과 개통 확인 정도의 업무만 진행하였습니다. 이렇게 모든 비마트에 백업망 구축이 완료되었습니다.

성과 공유

마지막 결론입니다.

[LTE라우터 도입전후 회선장애 발생건수, 2022.03-2023.02 / 2023.03-2024.02]

LTE 라우터를 이용해 비마트 서비스를 운영한지 만 1년이 되었습니다. 네트워크 회선 문제로 인한 주문 유실은 지금까지 없었으며 다음과 같은 장애 극복 사례도 있었습니다.

2023년 12월 29일 금요일 15시 지방의 한 비마트 센터에서 메인 회선 장애 발생
당일 장애 처리가 되지 못함
다음 해인 2024년 1월 2일 장애 처리 완료
3일 연휴 기간 동안 접수된 모든 주문은 1건의 유실도 없이 정상 처리

여기까지 우아한형제들에서 최소의 비용으로 최대의 운영 가용성을 확보한 경험에 대해 공유해 보았습니다.
비슷한 사례로 고민하시는 분들께 도움이 되는 사례가 되었으면 좋겠습니다. 감사합니다.

[1] PPC(Picking&Packing Center): 도심 곳곳에 위치하고 있는 PPC(피패킹센터)에서는 물류기지에서 상품을 입고 받아 보관하다가 주문이 들어오면 즉시 정확하게 피킹 및 패킹(포장)하여 라이더가 배달을 할 수 있도록 준비합니다.

우아한형제들 네트워크 인증시스템 교체기

pilho — Tue, 15 Oct 2024 17:10:32 +0900

우아한기술블로그(https://techblog.woowahan.com/9694/)에 동일하게 작성된 글입니다.

네트워크 인증시스템 교체는 일년 동안(2021.05 - 2022.05) 진행한 프로젝트입니다.
담고 싶은 내용이 많지만 우아한형제들에서는 네트워크 인증시스템 변경을 통해 ‘무엇을 하고 싶었는지’ 그리고 ‘단계별로 어느 것을 고려하였는지’ 간략히 그 내용을 공유해보려 합니다.

배경과 목적

우아한형제들에서 기존에 사용한 네트워크 인증 방식은 맥 주소 인증방식입니다. 많은 회사에서 일반적으로 사용하는 방식입니다. 하지만 보안 취약점과 개인정보보호 중요성이 심화됨에 따라 대다수의 단말 제조사에서는 하드웨어 맥-주소(mac-address)를 임의로 변경하는(randomized mac-address) 기능이 기본적으로 활성화되기 시작했습니다. 이로 인해 단말을 관리해야 하는 관리자와 사내망을 사용하는 사용자 모두 힘들어졌습니다. OS에서 기본으로 활성화된 맥 주소 변경 기능을 모두 바꿔주어야 했기 때문입니다.
뿐만 아니라 사업 확장에 따른 지점, 지사의 수도 월 3, 4개로 급격히 증가했지만 기존 시스템 구성으로는 한계도 존재하였습니다. 미흡한 자동화 기능으로 일일이 관리자가 처리해야 하는 월평균 90건의 티켓(요청 업무)도 시스템 교체를 하게 된 배경입니다.
교체하는 시스템의 목표를 NoOps(no operations)로 정하였습니다. 그 이유는 정교하게 이루어진 정책으로 많은 부분이 자동으로 돌아가는 환경을 만들고자 하였습니다. 언뜻 보면 관리자에 초점이 맞춰진 듯한 목표일 수 있지만 사용자가 편리하면 문의가 없을 것이고, 문의가 없으면 관리자도 필요 없기에 NoOps가 궁극적인 목표라 생각했습니다.

프로세스 설계

1단계: 큰 틀 짜기

처음으로 한 일은 사용자 편의기능 제공여부와 기존 인프라와의 호환성과 확장성을 확인하는 것이었습니다. 그리고 보안 요구사항도 나열해 보았습니다. 여기서 도출된 기능 요구사항을 바탕으로 사용할 프로토콜과 기본적인 인증 프로세스의 기틀을 잡았습니다. 마지막으로 우리가 설정한 궁극적인 목적과 방향이 맞는지 요구사항과 비교해 보았습니다.

2단계: 솔루션 선정

1단계에서 작성한 요구사항을 바탕으로 솔루션 제안 소개를 받았습니다. 그중 C사(社)의 I솔루션과 A사(社)의 C솔루션이 대부분의 요구 조건을 만족하였습니다. 본격적으로 PoC(Proof of Concept) 대상을 확정하기 위해 상세평가를 진행하였고 최종적으로 A사(社)의 C솔루션을 대상으로 테스트하였습니다.

3단계: 인증 프로세스

이 단계에서는 사내 사용 단말의 종류와 단말에서 지원하는 프로토콜을 확인하였습니다. 누가, 어디서, 어떻게 사용하는지도 세부적으로 조사하였습니다. 이후 상세 프로세스 설계를 하였습니다. 상세 프로세스 설계시 최소 인증 조건과 개인정보 보안을 만족하는지 보안팀과 밀접하게 논의하고 최종 인증 프로세스를 확정하였습니다.

4단계: 네트워크 대역 재설계

전사에 공통된 인증 정책을 배포하기 위해 표준화된 대역 재설계가 꼭 필요했습니다.
네트워크 담당자는 최소의 IP 대역 운영이 관리요소를 줄일 수 있어 좋습니다. 하지만 보안 담당자 입장에서는 전통적으로 IP 대역 단위의 정책 제어를 사용하기에 서로의 입장이 상반됩니다. 다행히 프로젝트 처음부터 보안 요구사항으로 사용자(user) 단위의 역할 기반 접근 제어(role-based access control, RBAC) 기능 구현이 가능했기에 최소한의 IP 대역으로 재설계가 가능했습니다. 이로써 우아한형제들에서는 적은 IP 대역으로 사용자 직무에 맞는 보안 정책을 부여하고 있습니다.

RBAC 설명, https://m.blog.naver.com/ijoos/221685299627

신규 시스템 사용준비

테스트 그리고 테스트

설계를 마치고 이제 우리가 원하는 대로 작동하는지 테스트했습니다.
호환성 확인과 사용자 대응을 위해 단말종류, OS 버전, 웹브라우저 등 모든 단계에서 테스트가 필요했습니다. 만약 원하는 결과가 나오지 않은 경우 문제가 무엇인지, 다른 대안은 없을지, 그 대안이 처음 세운 궁극적인 교체 목표와 같은지 계속 확인하였습니다. 제일 생각나는 일화는 하나의 단말이라도 다른 OS버전과 브라우저를 테스트하다 보니 기록하면서 하지 않으면 금세 기억하지 못해 했던 것을 몇 번이고 다시 테스트 한 생각이 납니다. 정말 그 과정이 지루하고 힘들어 종종 쉬운 방법을 택하려 했지만 사내 곳곳에 붙어있는 문구 하나가 쉽게 포기하지 말라는 듯이 보였습니다.

사내 문구, https://brunch.co.kr/@lovebrander/35

배포 준비와 협업

사용자 배포를 위한 준비는 혼자 할 수 있는 영역이 아니었습니다.
사내 브랜드 디자인팀에서는 웹페이지와 안내물(사이니지) 디자인 도움을 받았습니다. 전사교육팀에서는 기계에 익숙지 않은 사용자의 눈높이로 매뉴얼 제작 도움을 받았습니다. 마지막으로 피플팀의 도움으로 수 천명의 구성원에게 효율적으로 공지가 전파될 수 있었습니다.

사용자에게 배포하기

베타 테스트

정식 배포 전 마지막 베타 테스트를 실 대상 분들에게 하였습니다. 사용 피드백과 놓친 부분을 확인 하였습니다. 사용자 인증 과정에서 HTTPS, HTTP 웹페이지 전환 간에 발생하는 웹 경고와 Apple 프로파일, Windows EXE 설치 중 발생하는 설치 경고가 불편하다는 피드백을 수용하여 공인 인증서를 발급받아 조치하였습니다. 이제 모든 준비는 끝났습니다.

비서비스 대상

마이그레이션 사내에서 사용하는 단말을 나누어보자면 PDA와 같은 서비스 유형의 단말과 구성원이 사용하는 비서비스 단말로 나눌 수 있습니다. 비교적 사업에 영향이 적은 구성원 단말부터 마이그레이션을 시작 하였습니다. 간혹 발생하는 문의는 충분히 예상된 범위 내에서 해결되었고 큰 문제없이 배포가 완료되었습니다.

서비스 대상

마이그레이션 구성원 대상으로 약 3개월 정도 안정화 기간을 가졌습니다. 그 후 서비스 단말을 마이그레이션 하였습니다. 이로써 6개월간의 마이그레이션이 끝났고 전사에 새로운 인증시스템이 도입되었습니다.

도입 결과

네트워크 인증시스템 교체 후 6개월이 지난 시점에서 교체 목표였던 ‘NoOps’ 지표는 달성했을까요?
결과는 성공적 이었습니다.

사용자 셀프서비스 기능 오픈으로 변경 전 월 평균 티켓(요청 업무) 90건은 현재 월 평균 1건 이하로 유지되고 있습니다. 물론 코로나19 펜데믹으로 시행한 전면 재택근무와 변경 전 대비 5배 이상의 인증단말 증가로 동일 환경에서 정확한 비교를 하기는 어렵습니다.

운영 중인 네트워크 인증 시스템을 사용자 불편 없이 변경하는 일은 정말 쉽지 않은 일 입니다.
이 교체기가 조금이나마 관련된 일을 하시는 분들에게 도움이 되었으면 합니다. 차후에 후속 편을 작성하게 된다면 도입 후 생긴 기술적 고민과 이용 사례도 적어 보도록 하겠습니다.
감사합니다. 끗.