2026/09/10 개발일지

서버 네트워크 점검부터 IEEE Access 논문 정리, 제안서 검토까지

오늘은 크게 학교 서버 네트워크 문제 해결, IEEE Access 논문 정리, 연구 제안서 검토 작업을 진행했다. 특히 서버 네트워크 문제는 단순한 서버 설정 문제가 아니라 물리적인 네트워크 연결과 상위 스위치까지 확인해야 하는 상황이라 하나씩 원인을 좁혀가는 방식으로 점검했다.

---

1. 학교 서버 외부 통신 문제 점검

오늘 가장 많은 시간을 사용한 작업은 학교 서버의 네트워크 연결 문제를 확인하는 것이었다.

현재 서버에서는 패킷 송신은 발생하지만 정상적인 수신이 이루어지지 않는 상태였다. 처음에는 서버 자체 방화벽이나 운영체제의 네트워크 설정 문제를 의심했지만, 학교 측에서 확인한 결과 방화벽에는 특별한 문제가 없는 것으로 확인되었다.

따라서 문제의 범위를 서버 내부 설정에서 물리적인 네트워크 구성과 스위치 연결 상태로 확대하였다.

확인한 내용

서버실의 스위치와 랜선 연결 상태를 직접 확인했다.

확인 과정에서 스위치의 7번, 6번, 4번 포트가 사용 중이었으며 ipTIME 장비에는 5번 포트가 연결된 상태를 확인했다. 또한 기존 연결을 추적하는 과정에서 1번과 5번 포트가 함께 연결되어 있었던 구성도 발견했다.

이를 통해 현재 서버실의 네트워크 구성이 예상했던 것과 다를 가능성을 확인했다.

특히 다음과 같은 가능성을 중심으로 점검했다.

• 서버 자체 네트워크 설정 문제
• 랜선 연결 위치 문제
• 서버실 내부 스위치와 상위 스위치 간 연결 문제
• 상위 스위치 포트 비활성화 가능성
• VLAN 또는 포트 설정 문제

랜선 자체의 문제 여부도 확인했지만 랜선에는 특별한 이상이 없는 것으로 판단했다.

---

2. 상위 스위치 연결 여부 확인

가장 중요한 부분은 서버실 스위치와 학교의 상위 네트워크 스위치가 실제로 연결되어 있는가였다.

상위 네트워크에서 내려오는 것으로 예상되는 랜선을 스위치에 연결했지만 1번 포트의 Link LED가 켜지지 않는 현상이 발생했다.

일반적으로 정상적인 Ethernet 연결이라면 양쪽 장비가 활성화되어 있고 케이블과 포트가 정상일 경우 Link가 형성되어야 한다.

그런데 케이블에 문제가 없는데도 Link LED가 들어오지 않았기 때문에 단순 IP 설정 문제보다는 다음 가능성이 더 높다고 판단했다.

상위 스위치의 해당 포트가 비활성화되어 있거나 실제 상위 스위치 연결선이 아닐 가능성이다.

즉 현재 문제는 서버 → 내부 스위치 구간보다

서버실 스위치 → 학교 상위 스위치

구간에서 발생하고 있을 가능성이 높아졌다.

다음 점검에서는 서버실 스위치의 관리 페이지에 접속하여 포트 상태, VLAN 구성, Link 상태 등을 확인하고 상위 스위치 측에서도 해당 포트가 활성화되어 있는지 확인할 필요가 있다.

---

3. IEEE Access 논문 형식 정리

네트워크 작업과 함께 기존에 작성하던 LLM Compression Safety 관련 논문을 IEEE Access 투고 형식에 맞게 정리하는 작업도 진행했다.

기존 원고에는 MDPI 형식의 흔적이 남아 있었기 때문에 단순히 글꼴이나 여백만 변경하는 것이 아니라 전체적인 논문 구조를 IEEE Access 스타일에 맞게 다시 정리할 필요가 있었다.

주요 작업 방향은 다음과 같다.

• IEEE Access 논문 구조 적용
• 기존 MDPI 형식 제거
• 제목 및 저자/소속 영역 정리
• Abstract 및 Index Terms 구성 정리
• Section/Subsection 구조 수정
• 표와 그림 Caption 형식 통일
• 본문 내 표·그림 인용 방식 수정
• 참고문헌을 IEEE 숫자 인용 방식으로 통일
• 전체 문장을 IEEE 논문에 적합한 학술적 표현으로 수정

단순한 형식 변환뿐만 아니라 논문의 심사 가능성을 높이기 위한 내용 검토도 함께 진행했다.

특히 현재 원고에서는 Related Work 보강, Local Judge 정의와 검증, 통계적 검증 방법, HarmBench 실험 설정, 모델 압축 과정의 재현성 설명 등이 중요한 보완 요소로 확인되었다.

따라서 앞으로는 형식적인 IEEE Access 변환과 함께 실험 방법 및 통계적 검증 부분도 보강해야 한다.

---

4. 연구 제안서 평가 및 보강 방향 검토

기존에 작성한 연구 제안서가 실제 평가에서 어느 정도 경쟁력을 가질 수 있는지도 검토했다.

단순히 내용이 기술적으로 가능한지를 판단하는 것보다 평가위원의 입장에서 다음 요소를 중심으로 확인했다.

필요성 → 문제 정의 → 연구 방법 → 실험 → 정량적 성과

이 흐름이 자연스럽게 연결되는지가 중요한 평가 요소라고 판단했다.

특히 실제 지역의 사이버보안 문제와 연구 필요성을 연결하기 위해 전남지역 지자체 대상 해킹 시도 사례와 같은 자료를 활용하여 연구 필요성을 구체화하는 방향도 검토했다.

연구 내용 자체가 좋아도 제안서에서는 "왜 지금 이 연구가 필요한가"가 명확하게 제시되어야 하기 때문에 실제 통계와 사례를 활용하여 문제의 심각성을 보여주는 것이 중요하다.

향후에는 연구 목표별 정량 지표와 실험 시나리오를 더욱 구체화하여 제안서의 실현 가능성을 높이는 방향으로 보강할 예정이다.

---

5. 오늘 작업하면서 느낀 점

오늘 서버 문제를 확인하면서 다시 한번 느낀 것은 네트워크 장애를 무조건 소프트웨어 설정 문제라고 생각하면 안 된다는 점이다.

처음에는 서버의 IP, Gateway, 방화벽 등을 중심으로 확인했지만 실제로 점검 범위를 넓히면서 물리적인 포트 연결과 상위 스위치 연결 여부가 중요한 문제로 나타났다.

네트워크 문제를 해결할 때는 앞으로 다음 순서로 확인하는 것이 효율적일 것 같다.

Physical → Link → Network → Transport → Application

즉,

랜선/포트 → Link 상태 → IP/Gateway/VLAN → 방화벽/포트 → 웹 서버

순서로 확인하면 문제의 범위를 훨씬 빠르게 좁힐 수 있다.

논문과 제안서 작업에서도 비슷한 점을 느꼈다. 단순히 문장을 잘 작성하는 것보다 논문의 실험 근거와 제안서의 문제 정의가 얼마나 논리적으로 연결되어 있는지가 훨씬 중요하다.

---

오늘의 작업 요약

서버/네트워크

학교 서버의 송·수신 문제를 점검하고 방화벽 이외의 원인을 조사했다. 서버실 스위치와 랜선 연결 상태를 확인했으며, 상위 스위치와의 연결 문제 또는 상위 포트 비활성화 가능성을 확인했다. 다음 단계는 스위치 관리 페이지와 VLAN/포트 상태를 확인하는 것이다.

논문

LLM Compression Safety 논문을 IEEE Access 투고 형식으로 변경하는 작업을 진행했다. MDPI 형식을 제거하고 IEEE 구조로 재구성하는 동시에 Related Work, Local Judge 검증, 통계적 분석, 실험 재현성 등의 추가 보완점을 확인했다.

연구 제안서

제안서의 성공 가능성과 평가 요소를 검토하고 실제 사이버보안 사례를 연구 필요성과 연결하는 방향을 검토했다. 향후 연구 목표와 정량적 성과지표를 더욱 구체화할 예정이다.

---

오늘의 한 줄

오늘은 코드를 새로 만드는 날이라기보다, 서버·논문·제안서에서 각각 발생한 문제의 원인을 찾아 다음 단계로 넘어갈 수 있도록 기반을 정리한 하루였다.