네트워크 엔지니어를 준비하는 취업 준비생의 프로젝트를 점검하다 보면 Python을 이용해 여러 장비의 정보를 한 번에 가져오거나 동일한 설정을 배포한 경험을 포트폴리오에 넣는 경우가 많습니다. 처음 보면 수동 작업을 코드로 바꿨다는 점에서 충분히 자동화 프로젝트처럼 보입니다. 그런데 자동화하기 전에는 얼마나 반복적인 작업이었는지, 일부 장비에서 명령이 실패하면 어떻게 처리했는지, 잘못된 설정이 여러 장비에 동시에 적용되는 문제는 어떻게 막았는지를 질문하면 설명이 짧아지는 경우가 있습니다. 반대로 Python 코드는 길고 GitHub 저장소도 잘 정리되어 있는데 실제 네트워크가 무엇 때문에 개선되었는지 보이지 않는 프로젝트도 있습니다. 장비에 SSH로 접속하고 명령을 실행하는 함수는 있지만, 라우팅과 인터페이스 상태를 왜 수집했는지, 결과를 어떤 정상 기준과 비교했는지, 설정을 변경한 뒤 서비스 통신이 정상인지 다시 확인했는지가 빠져 있는 식입니다. 이 경우에는 Python 프로젝트는 될 수 있어도 네트워크 운영 문제를 자동화한 포트폴리오라고 설명하기에는 근거가 부족할 수 있습니다. 현재 네트워크 자동화 환경도 단순 CLI 스크립트에서 더 넓은 방향으로 확장되어 있습니다. Cisco의 2026년 IOS XE 프로그래머빌리티 가이드에는 Python API뿐 아니라 NETCONF, RESTCONF, Model-Driven Telemetry, gNMI 등이 함께 포함되어 있으며, 네트워크 장비를 프로그램과 데이터 모델을 이용해 관리하는 구조가 일반적인 운영 영역으로 자리 잡고 있음을 보여줍니다.
Ansible의 현재 네트워크 자동화 문서에서도 반복 작업 자동화뿐 아니라 여러 제조사의 네트워크 장비를 inventory와 playbook, module로 관리하고 SSH·NETCONF·HTTP API 같은 서로 다른 연결 방식을 사용할 수 있도록 설명합니다. 즉 네트워크 자동화는 코드를 작성하는 것만이 아니라 대상 장비와 설정 데이터를 구조화하고, 변경과 검증을 반복 가능한 방식으로 운영하는 문제에 가깝습니다.
취업 포트폴리오에서도 같은 기준이 필요합니다. Python에서는 반복 작업과 데이터를 어떻게 구조화했는지, API에서는 장비나 컨트롤러와 어떤 방식으로 정보를 주고받았는지, 설정관리에서는 변경 전후 상태와 버전, 실패와 복구를 어떻게 관리했는지를 하나의 흐름으로 보여주는 편이 좋습니다. 네트워크 자동화 포트폴리오의 핵심은 코드를 얼마나 많이 작성했는지가 아니라 사람이 반복하던 네트워크 운영을 어떤 기준으로 자동화하고, 변경 결과까지 어떻게 검증했는지를 보여주는 것입니다.
이번 글에서는 네트워크 자동화 경험을 포트폴리오로 만드는 방법을 Python, API, 설정관리 세 가지 기준으로 나누어 정리하겠습니다.
Python은 네트워크 명령을 대신 입력하는 것보다 반복 업무와 데이터를 구조화하는 도구입니다
- 자동화 프로젝트는 먼저 어떤 반복 업무를 줄이려 했는지가 보여야 합니다
Python으로 네트워크 장비에 접속했다는 사실만으로 프로젝트의 목적이 명확해지는 것은 아닙니다. 사람이 기존에 어떤 작업을 반복했고 그 과정에서 어떤 오류나 시간 낭비가 발생할 수 있었는지를 먼저 보여주면 자동화 이유가 훨씬 선명해집니다.
프로젝트에서는 다음 내용을 연결해서 볼 수 있습니다.
- 여러 장비에서 반복적으로 확인하던 항목을 구분합니다.
- 사람이 수동으로 수행하던 작업 순서를 기록합니다.
- 장비마다 달라지는 값과 공통 작업을 나눕니다.
- 수집 결과를 어떤 형식으로 저장할지 정합니다.
- 일부 장비에서 실패했을 때 전체 작업이 중단되지 않게 구분합니다.
- 자동화 전과 후에 확인해야 하는 결과를 동일하게 유지합니다.
예를 들어 30대의 스위치에서 인터페이스 상태와 OS 버전, 장비 이름을 확인해야 한다면 각 장비에 접속해 명령을 반복하는 대신 Python으로 결과를 수집할 수 있습니다. 하지만 포트폴리오에서는 30대 장비 정보를 자동 수집했다는 문장만 남기는 것보다 수동 확인 과정 → 반복되는 문제 → 자동화 대상 → 결과 저장 → 이상 장비 분류의 흐름을 보여주는 편이 좋습니다. 이렇게 구성하면 Python은 네트워크를 대신하는 기술이 아니라 기존 네트워크 운영 업무를 더 일관되게 수행하기 위한 도구로 보입니다.
- Python 문법 학습과 네트워크 자동화 경험은 문제를 해결하는 방식에서 차이가 있습니다
Python 공부를 많이 했다고 해서 네트워크 자동화 프로젝트가 자동으로 만들어지는 것은 아닙니다. 네트워크 상황을 데이터와 조건으로 바꿀 수 있어야 코드가 실제 운영 문제와 연결됩니다.
- Python 문법 중심: 반복문과 조건문, 함수와 예외처리를 사용할 수 있습니다.
- 네트워크 데이터 중심: 장비 이름과 IP, 플랫폼, 인터페이스 정보를 리스트나 딕셔너리 형태로 관리합니다.
- 운영 조건 중심: 특정 인터페이스가 Down 상태인지와 예상하지 않은 설정이 존재하는지를 조건으로 분류합니다.
- 오류 처리 중심: 접속 실패와 인증 실패, 명령 실행 실패를 서로 다르게 기록합니다.
- 결과 활용 중심: 수집된 결과를 CSV나 JSON 등으로 저장하고 정상·비정상 장비를 구분합니다.
이 차이를 이해하면 Python 코드 자체를 포트폴리오의 중심에 두지 않게 됩니다. 중요한 것은 함수 개수나 코드 길이보다 네트워크 상태를 어떤 데이터로 만들고 어떤 조건으로 판단했는지입니다.
- 실패하는 장비를 처리한 경험이 있으면 자동화 프로젝트의 현실성이 높아집니다
실습 환경에서는 모든 장비가 정상적으로 연결되고 같은 명령을 지원하도록 구성하기 쉽습니다. 하지만 실제 네트워크에서는 장비 응답이 늦거나 인증에 실패하고, 제조사와 운영체제에 따라 같은 작업도 다른 방식으로 수행될 수 있습니다.
프로젝트에서는 다음 상황을 포함할 수 있습니다.
- 접속하지 못한 장비를 별도로 기록합니다.
- 인증 실패와 타임아웃을 구분합니다.
- 명령 결과가 비어 있는 경우를 처리합니다.
- 장비별 운영체제 차이를 데이터에서 구분합니다.
- 실패한 장비만 다시 실행할 수 있도록 대상을 분리합니다.
- 정상 완료와 오류 결과를 하나의 실행 기록으로 남깁니다.
Ansible 네트워크 자동화 역시 장비 종류에 따라 network platform을 구분하고 CLI over SSH, NETCONF, HTTP API 등 여러 연결 방식을 사용할 수 있도록 구성되어 있습니다. 네트워크 장비가 모두 동일한 방식으로 동작한다고 가정하기 어렵다는 점을 보여주는 구조입니다. 따라서 프로젝트에서도 성공한 결과만 보여주는 것보다 일부 장비가 실패했을 때 자동화가 어떻게 반응하는지까지 기록하면 운영 경험이 훨씬 구체적으로 보입니다.
- Python 자동화는 네트워크 기본 지식을 대신하지 않고 검증 범위를 넓혀줍니다
자동화 코드를 작성하면 여러 장비에 설정을 빠르게 적용할 수 있습니다. 하지만 잘못된 판단을 코드로 만들면 잘못된 설정도 빠르게 확산될 수 있기 때문에 자동화할수록 네트워크 원리를 이용한 검증이 중요합니다.
- 수집 단계: 인터페이스와 라우팅, 장비 상태를 Python으로 가져옵니다.
- 판단 단계: 정상 네트워크 구조와 비교해 이상 상태를 구분합니다.
- 변경 단계: 필요한 장비와 설정만 대상으로 선택합니다.
- 재확인 단계: 변경 이후 같은 데이터를 다시 수집합니다.
- 서비스 검증 단계: 경로와 연결 상태가 실제로 원하는 결과인지 확인합니다.
예를 들어 특정 인터페이스 설정을 자동으로 변경했다면 스크립트가 오류 없이 종료되었다는 사실만으로 완료라고 보기 어렵습니다. 해당 인터페이스가 정상 상태인지와 라우팅 경로가 유지되는지, 연결된 서비스가 통신할 수 있는지까지 확인해야 합니다. 따라서 Python 경험을 포트폴리오로 만들 때는 자동 실행 성공보다 네트워크 상태까지 확인한 구조가 더 중요합니다.
API는 네트워크 장비와 컨트롤러의 상태를 프로그램이 이해할 수 있는 데이터로 다루는 영역입니다
- API 경험은 단순 호출보다 요청과 응답 데이터를 네트워크 상태와 연결할 수 있어야 합니다
네트워크 자동화를 공부하면서 REST API를 호출해 장비 목록이나 인터페이스 정보를 가져오는 실습을 할 수 있습니다. 하지만 응답 데이터를 출력하는 수준에서 끝나면 API 사용 경험은 남아도 네트워크 업무와 연결되기는 어렵습니다.
API 프로젝트에서는 다음 내용을 확인할 수 있습니다.
- 어떤 endpoint에서 필요한 정보를 받을 수 있는지 확인합니다.
- 인증 방식과 필요한 권한을 구분합니다.
- HTTP 요청 결과와 상태 코드를 기록합니다.
- JSON이나 XML에서 필요한 값을 추출합니다.
- 실제 장비 상태와 API 결과가 일치하는지 비교합니다.
- 오류 응답이 발생했을 때 원인을 별도로 처리합니다.
RESTCONF는 YANG 모델을 기반으로 네트워크 리소스를 프로그램이 읽을 수 있는 형태로 다루며 GET, POST, PUT, PATCH 같은 HTTP 방식으로 장비와 상호작용할 수 있도록 설계되어 있습니다. NETCONF 역시 모델 기반으로 네트워크 장비와 프로그램이 통신하는 방식입니다. 포트폴리오에서는 REST API 사용이라는 한 줄보다 어떤 네트워크 상태를 조회했고 그 데이터를 어떤 운영 판단에 사용했는지를 설명하는 편이 좋습니다.
- CLI 자동화와 API 기반 자동화는 데이터를 주고받는 방식에서 차이가 있습니다
SSH로 접속해 CLI 명령을 실행하는 것도 충분히 사용할 수 있는 자동화 방식입니다. API 방식은 장비 또는 컨트롤러가 정해진 데이터 구조로 정보를 제공한다는 점에서 추가적인 장점을 가질 수 있습니다.
- CLI 기반 자동화: 사람이 사용하는 명령을 프로그램이 실행하고 출력 문자열을 해석합니다.
- API 기반 자동화: 시스템이 정의한 인터페이스를 통해 구조화된 데이터를 요청하고 응답받습니다.
- 모델 기반 자동화: YANG과 같은 데이터 모델을 기준으로 설정과 상태 정보를 다룰 수 있습니다.
- 컨트롤러 기반 자동화: 여러 장비 정보를 하나의 관리 시스템에서 조회하고 정책을 적용할 수 있습니다.
- 혼합형 자동화: 장비와 기능에 따라 CLI, NETCONF, RESTCONF, HTTP API 등을 적절히 사용할 수 있습니다.
Ansible도 현재 네트워크 연결 방식으로 CLI over SSH뿐 아니라 NETCONF와 HTTP API를 지원하며, 네트워크 플랫폼과 작업 목적에 따라 연결 방식을 선택하도록 안내합니다. 따라서 API를 공부할 때 CLI를 오래된 방식으로 단순하게 비교할 필요는 없습니다. 포트폴리오에서는 대상 환경과 목적에 따라 어떤 방식이 적절했는지를 판단한 과정이 더 중요합니다.
- API 프로젝트에는 조회뿐 아니라 인증과 권한, 오류 처리를 함께 포함하는 것이 좋습니다
API 호출 예제는 정상적인 인증정보와 정확한 URL이 준비되어 있는 경우가 많습니다. 실제 운영에서는 만료된 인증정보와 권한 부족, 잘못된 입력, 타임아웃 등 여러 실패 조건이 발생할 수 있습니다.
프로젝트에서는 다음 경험을 포함할 수 있습니다.
- 인증정보를 코드에 직접 노출하지 않습니다.
- 조회와 변경에 필요한 권한을 구분합니다.
- 정상 응답과 오류 응답을 별도로 처리합니다.
- 일정 시간 안에 응답하지 않을 경우를 기록합니다.
- 잘못된 장비나 리소스 ID를 구분합니다.
- 변경 API 사용 시 적용 대상을 다시 확인합니다.
네트워크 자동화에서도 API를 사용할 수 있다는 사실보다 어떤 권한으로 어떤 요청을 수행했는지와 실패할 경우 무엇을 남겼는지가 운영 관점에서 더 중요합니다. 이런 내용이 프로젝트에 포함되면 개발 언어를 사용했다는 경험과 네트워크 운영 자동화를 수행했다는 경험의 차이가 더 명확해집니다.
- API 결과를 실제 네트워크 검증으로 연결해야 포트폴리오의 깊이가 생깁니다
API에서 HTTP 200 응답을 받았다고 해서 네트워크 전체가 정상이라는 의미는 아닙니다. 설정 요청이 정상적으로 처리되었더라도 실제 데이터 플레인에서 원하는 경로와 통신이 만들어졌는지는 별도로 확인해야 할 수 있습니다.
- API 요청 성공: 서버나 컨트롤러가 요청을 정상적으로 받아 처리했습니다.
- 설정 반영 확인: 대상 장비에 의도한 설정이 적용되었는지 다시 조회합니다.
- 상태 확인: 인터페이스와 라우팅, 인접 관계 등이 정상인지 확인합니다.
- 통신 확인: 실제 서비스 트래픽이 원하는 경로로 이동하는지 검증합니다.
- 이상 발견: 기대 결과와 다르면 변경 내용과 이전 상태를 비교합니다.
예를 들어 API를 통해 VLAN을 생성한 뒤 성공 응답을 받았더라도 필요한 포트가 해당 VLAN에 포함되지 않았다면 서비스는 정상적으로 동작하지 않을 수 있습니다. 따라서 API 경험을 포트폴리오에 넣을 때도 요청 → 응답 → 설정 확인 → 네트워크 상태 확인 → 서비스 검증의 흐름을 함께 보여주는 편이 좋습니다.
설정관리는 빠른 변경보다 동일한 상태를 반복하고 추적하며 안전하게 되돌리는 영역입니다
- 좋은 설정관리 프로젝트는 현재 상태와 원하는 상태의 차이를 관리할 수 있어야 합니다
네트워크 자동화 프로젝트에서 여러 장비에 설정을 배포하는 기능은 눈에 잘 띕니다. 하지만 실제 운영에서는 설정을 한 번 넣는 것보다 어느 장비가 어떤 상태여야 하는지를 지속적으로 관리하는 문제가 더 중요할 수 있습니다.
설정관리 프로젝트에서는 다음 내용을 연결할 수 있습니다.
- 장비별 공통 설정과 개별 변수를 분리합니다.
- 적용 전에 현재 설정을 수집합니다.
- 원하는 설정 상태를 템플릿이나 데이터로 정의합니다.
- 변경될 내용과 유지될 내용을 구분합니다.
- 적용 후 다시 상태를 수집해 결과를 비교합니다.
- 문제가 발생했을 때 이전 상태로 복구할 자료를 남깁니다.
Ansible은 네트워크 자동화에서 inventory와 playbook, module을 이용해 여러 장비를 관리하고, 일부 네트워크 모듈은 설정 백업과 복원 기능도 제공합니다. 이는 설정관리를 단순 명령 실행보다 반복 가능한 운영 상태의 관리로 볼 수 있게 합니다. 포트폴리오에서도 설정 자동 배포보다 현재 상태 → 원하는 상태 → 차이 확인 → 변경 → 재검증 구조를 보여주는 편이 더 좋습니다.
- 단순 스크립트와 설정관리는 재사용성과 변경 이력을 다루는 방식에서 차이가 있습니다
Python 스크립트 하나로 설정을 자동으로 넣을 수 있어도 장비와 정책이 늘어나면 관리가 복잡해질 수 있습니다. 설정 값과 실행 로직을 나누고 버전 관리까지 연결하면 프로젝트가 운영 구조에 가까워집니다.
- 단일 스크립트 방식: 코드 안에 장비 주소와 설정값, 실행 순서가 함께 포함됩니다.
- 데이터 분리 방식: 장비 목록과 IP, VLAN 등 변경 가능한 값을 별도 데이터로 관리합니다.
- 템플릿 방식: 공통 설정 형식을 만들고 장비별 변수만 적용합니다.
- 버전 관리 방식: Git 등을 이용해 설정과 자동화 코드의 변경 이력을 남깁니다.
- 검토 방식: 실제 적용 전에 어떤 설정이 바뀌는지 확인할 수 있도록 합니다.
Ansible의 네트워크 자동화 구조도 inventory를 이용해 대상을 관리하고 playbook과 module을 통해 반복 가능한 작업을 정의합니다. 일반 Ansible의 핵심 원칙에는 원하는 상태를 선언하고 이미 해당 상태라면 불필요한 변경을 반복하지 않는 예측 가능성과 idempotence가 포함됩니다. 이런 개념을 이해하면 설정관리 프로젝트가 단순 대량 배포에서 벗어나 같은 기준을 여러 장비에 반복적으로 유지하는 경험으로 발전합니다.
- 설정 변경에는 사전 검증과 사후 검증, 복구 기준이 함께 있어야 합니다
자동화는 작업 속도를 높이지만 잘못된 변경의 영향 범위도 빠르게 넓힐 수 있습니다. 따라서 포트폴리오에서는 얼마나 많은 장비를 변경했는지보다 잘못된 설정을 어떻게 예방하고 발견했는지를 보여주는 편이 좋습니다.
프로젝트에서는 다음 과정을 포함할 수 있습니다.
- 변경 대상 장비와 설정값을 실행 전에 확인합니다.
- 현재 설정을 백업하거나 필요한 상태를 기록합니다.
- 입력 데이터의 형식과 값 범위를 검증합니다.
- 일부 장비에서 먼저 적용해 결과를 확인합니다.
- 변경 이후 인터페이스와 라우팅 상태를 다시 수집합니다.
- 문제가 발생할 경우 이전 설정으로 복구할 기준을 준비합니다.
예를 들어 모든 스위치에 새로운 VLAN을 추가하는 프로젝트라면 30대에 동시에 배포했다는 결과보다 잘못된 VLAN 번호와 대상 장비를 어떻게 사전에 확인했는지가 중요합니다. 또한 설정이 적용된 뒤 실제 트렁크와 액세스 포트, 통신 상태가 원하는 결과인지 확인해야 합니다. 이 구조가 있어야 자동화가 속도를 높이는 도구에서 변경 위험을 통제하는 운영 방식으로 발전합니다.
- 포트폴리오에서는 코드보다 문제와 변경, 검증의 흐름이 한눈에 보여야 합니다
GitHub 저장소에 코드만 올려두면 면접관이 프로젝트의 네트워크 목적을 파악하기 어렵습니다. README와 프로젝트 문서에는 코드 설명보다 자동화 전후 운영 방식과 검증 결과가 먼저 보이는 편이 좋습니다.
- 문제 정의: 어떤 반복 작업이나 운영 문제가 있었는지 설명합니다.
- 기존 방식: 사람이 어떤 순서로 장비를 확인하고 설정했는지 정리합니다.
- 자동화 구조: Python과 API, 설정관리 도구가 각각 어떤 역할을 담당했는지 보여줍니다.
- 안전장치: 권한과 입력 검증, 백업, 대상 제한을 어떻게 구성했는지 설명합니다.
- 결과 검증: 변경 전후 네트워크 상태와 오류 발생 장비를 비교합니다.
- 한계와 개선: 장비 종류 확대와 테스트 자동화, 모니터링 연계 등 다음 개선 방향을 정리합니다.
이런 구조라면 코드의 양이 많지 않더라도 자동화 프로젝트의 판단 과정이 보입니다. 반대로 수백 줄의 Python 코드가 있어도 어떤 운영 문제가 해결되었는지 설명하지 못하면 포트폴리오의 직무 연관성은 낮아질 수 있습니다. 결국 설정관리 경험을 보여줄 때 중요한 것은 자동화 스크립트를 만들었다는 결과가 아니라 네트워크 변경을 재현 가능하고 검증 가능한 방식으로 관리했다는 과정입니다.
- conclusion
네트워크 자동화 경험을 포트폴리오로 만들 때 가장 흔한 실수는 Python 코드를 많이 작성하거나 여러 장비에 설정을 한 번에 배포하면 충분하다고 생각하는 것입니다. 자동화는 분명 네트워크 엔지니어의 반복 업무를 줄일 수 있지만, 빠른 실행 자체가 프로젝트의 목적은 아닙니다. 어떤 문제를 자동화했고, 어떤 데이터를 이용해 대상을 판단했으며, 잘못된 변경을 어떻게 통제했는지가 함께 보여야 합니다. Python에서는 반복문과 SSH 라이브러리를 사용했다는 사실보다 네트워크 상태를 데이터로 만들고 정상과 이상을 구분한 경험이 중요합니다. 접속 실패와 타임아웃, 장비 차이를 처리하고 실행 결과를 기록하면 단순 스크립트보다 실제 운영 상황에 가까운 프로젝트가 됩니다. API에서는 REST 요청을 한 번 성공시킨 결과보다 장비와 컨트롤러에서 어떤 상태를 조회하고 어떤 조건으로 변경했는지를 보여줄 필요가 있습니다. NETCONF와 RESTCONF, HTTP API처럼 여러 방식이 존재하는 이유를 이해하고 대상 환경에 맞는 방식을 선택했다면 자동화 구조를 더 구체적으로 설명할 수 있습니다. 현재 네트워크 자동화 도구 역시 CLI over SSH뿐 아니라 NETCONF와 HTTP API 등 다양한 프로토콜을 지원하고 있습니다. 설정관리에서는 빠르게 배포하는 것보다 현재 상태를 기록하고 원하는 상태와 비교하며 변경 이후 동일한 기준으로 다시 확인하는 과정이 중요합니다. Git과 템플릿, inventory와 playbook 같은 도구를 활용할 수도 있지만 핵심은 특정 제품을 사용했다는 사실이 아니라 변경을 반복 가능하게 만들고 이력을 추적하며 문제가 있을 때 원인을 찾고 되돌릴 수 있는가입니다.
최종적으로 확인할 항목은 다음과 같습니다.
- 자동화 이전에 사람이 반복하던 업무를 설명할 수 있는지 확인합니다.
- Python에서 장비와 상태 데이터를 구조적으로 관리했는지 살펴봅니다.
- API 요청과 응답을 실제 네트워크 상태와 연결했는지 확인합니다.
- 정상 실행뿐 아니라 인증 실패와 타임아웃 등을 처리했는지 점검합니다.
- 설정 변경 전후의 상태를 같은 기준으로 비교했는지 살펴봅니다.
- Git이나 백업을 이용해 변경 이력과 복구 기준을 남겼는지 확인합니다.
네트워크 자동화 포트폴리오 준비 흐름은 다음과 같이 연결할 수 있습니다.
- TCP/IP·라우팅·스위칭 기초 → Linux 기초 → Python 문법 → 장비 목록 데이터화 → SSH 기반 상태 수집 → 오류 처리 → HTTP와 JSON 이해 → REST API 활용 → NETCONF·RESTCONF 개념 이해 → 현재 설정 백업 → 설정값과 실행 로직 분리 → 템플릿·Inventory 구성 → Git 변경 이력 → 자동 설정 적용 → 상태 재수집 → 네트워크 통신 검증 → 실패·복구 기록 → README와 결과 문서화 → 포트폴리오와 면접 연결
결국 좋은 네트워크 자동화 포트폴리오는 자동화 도구를 많이 사용한 프로젝트가 아닙니다. Python에서는 반복 업무와 네트워크 데이터를 구조화하고, API에서는 장비와 컨트롤러를 프로그램이 사용할 수 있는 인터페이스로 연결하며, 설정관리에서는 변경 전후 상태와 버전, 실패와 복구를 일관되게 관리할 수 있어야 합니다. 이 세 영역이 하나의 프로젝트 안에서 이어져 있다면 단순히 Python을 사용할 수 있다는 설명을 넘어, 실제 네트워크 운영 문제를 분석하고 안전한 자동화 구조로 개선한 경험을 포트폴리오와 면접에서 더 구체적으로 보여줄 수 있습니다.