개발자 기초지식 (운영체제, 네트워크, 장애대응)

저도 처음엔 화면 잘 만들고 SQL 잘 짜면 개발자로서 충분하다고 생각했습니다. MES, PLM 프로젝트 초반에는 JSP 화면 수정과 데이터 조회 정도가 일의 전부였으니까요. 그런데 운영 서버에서 장애가 터진 날, 제가 알고 있던 개발 지식의 범위가 얼마나 좁았는지 깨달았습니다. 코드만 보는 개발자와 시스템을 보는 개발자는 완전히 다른 사람이었습니다.

코드 밖에서 터진 장애, 운영체제가 보였다

당시 운영 서버에서 시스템 속도가 급격하게 떨어지는 장애가 발생했습니다. 팀 전체가 처음엔 당연히 DB 문제라고 봤습니다. SQL 튜닝도 하고 인덱스도 다시 점검했는데, 속도는 전혀 나아지지 않았습니다.

결국 원인은 WAS(Web Application Server)의 메모리 문제였습니다. 여기서 WAS란 웹 애플리케이션이 실행되는 서버 환경으로, 사용자 요청을 받아 비즈니스 로직을 처리하는 미들웨어를 말합니다. 이 WAS 프로세스가 JVM(Java Virtual Machine) 위에서 동작하고 있었고, 메모리 사용량이 비정상적으로 치솟으면서 GC(Garbage Collection)가 끊임없이 반복되고 있었던 것입니다.

GC란 JVM이 더 이상 사용하지 않는 메모리 객체를 자동으로 정리하는 과정을 말합니다. 평상시엔 조용히 돌아가는 작업이지만, GC가 과도하게 발생하면 애플리케이션이 그 시간 동안 멈춰버리는 'Stop-the-World' 현상이 나타납니다. 제가 겪은 장애가 정확히 이 상태였습니다.

솔직히 이건 예상 밖이었습니다. SQL을 아무리 잘 짜도, 서버 프로세스 자체가 메모리를 감당 못 하면 시스템은 그냥 멈춥니다. 그날 이후로 저는 리눅스 명령어, JVM 힙(Heap) 구조, 프로세스 상태 모니터링 방법을 따로 공부하기 시작했습니다. 힙이란 JVM이 객체를 저장하는 메모리 공간으로, 이 영역이 가득 차면 OutOfMemoryError가 발생하며 서버가 다운됩니다.

개발자가 알아야 할 운영체제 기본 지식을 정리하면 다음과 같습니다.

• 프로세스와 스레드의 차이, 그리고 멀티스레드 환경에서의 동작 방식
• JVM 메모리 구조(힙, 스택, 메서드 영역)와 GC 발생 조건
• top, ps, free, jstat 같은 리눅스 모니터링 명령어 기본 활용법
• 서버 로그 경로와 에러 로그 패턴을 읽는 방법

이 정도를 모르면, 장애 상황에서 DB 팀에 책임을 떠넘기다 시간만 허비하게 됩니다. 제가 직접 겪어봤기 때문에 이건 자신 있게 말할 수 있습니다.

네트워크를 모르면, 원인 자체를 볼 수 없다

운영체제 공부를 어느 정도 마칠 즈음, 이번엔 다른 종류의 벽에 부딪혔습니다. 삼성전자 반도체 데이터 시스템 프로젝트를 진행할 때였는데, 설비 데이터가 특정 시간대에만 간헐적으로 수집되지 않는 문제가 발생했습니다.

처음엔 당연히 프로그램 버그라고 생각했습니다. 코드를 며칠 동안 뜯어봐도 문제를 찾을 수 없었습니다. 그때 제 경험상 이건 좀 다른 영역이라는 느낌이 왔고, 네트워크 구간을 살펴보기 시작했습니다.

원인은 특정 네트워크 구간에서 발생한 패킷 지연이었습니다. 패킷(Packet)이란 네트워크에서 데이터를 전송할 때 일정 크기로 잘라서 보내는 단위를 말합니다. 이 패킷이 목적지에 제때 도달하지 못하면서 API 호출에서 타임아웃(Timeout)이 발생했고, 결과적으로 데이터가 유실되고 있었던 것입니다.

타임아웃이란 특정 시간 안에 응답이 오지 않을 경우 요청을 강제로 끊어버리는 설정값입니다. 대부분의 시스템에서 이 값은 기본값으로 설정되어 있는데, 네트워크 환경에 따라 이 값을 적절히 조정하지 않으면 제가 겪은 것처럼 데이터 유실로 이어질 수 있습니다.

이 경험 이후로 HTTP 통신 구조, TCP/IP 프로토콜, 포트 개념을 제대로 공부했습니다. TCP/IP란 인터넷을 포함한 대부분의 네트워크에서 데이터 전송 규칙을 정의하는 표준 프로토콜 스택으로, 개발자가 API를 설계하거나 연동할 때 반드시 이해해야 하는 기반 지식입니다.

실제로 소프트웨어 개발에서 네트워크 지식이 필요한 장면은 생각보다 훨씬 많습니다. 한국인터넷진흥원(KISA)에 따르면 서비스 장애 원인 중 상당수가 애플리케이션 레이어 외부, 즉 인프라 또는 네트워크 계층에서 발생한다고 분석하고 있습니다(출처: 한국인터넷진흥원). 코드를 아무리 잘 짜도 네트워크를 모르면 이런 장애 앞에서 손을 놓을 수밖에 없습니다.

또한 과학기술정보통신부 산하 기관들이 발간한 SW 개발자 역량 가이드에서도 운영체제와 네트워크 기초는 직군을 막론하고 모든 개발자가 갖춰야 할 핵심 역량으로 명시되어 있습니다(출처: 과학기술정보통신부). 단순히 코딩 실력만 키우는 것으로는 부족하다는 뜻입니다.

결국 개발자의 실력은 코드 밖에서도 증명됩니다. 장애 상황에서 당황하지 않고 원인을 좁혀가는 능력, 그 능력의 바탕에는 운영체제와 네트워크에 대한 기초 이해가 반드시 있어야 합니다. 처음엔 막막하게 느껴지더라도, 실제 장애를 한 번 경험하고 나면 공부의 방향이 선명하게 잡힙니다. 저처럼 장애가 터진 뒤에 허겁지겁 공부하기보다는, 지금부터 조금씩 쌓아두시길 권합니다. 코드를 잘 짜는 개발자와 시스템을 이해하는 개발자 사이의 차이는 생각보다 훨씬 크게 느껴지는 순간이 반드시 옵니다.

---

참고: https://velog.io/@cherry_eong/%EA%B0%9C%EB%B0%9C%EC%9E%90%EA%B0%80-%EC%95%8C%EC%95%84%EC%95%BC-%ED%95%A0-%EA%B8%B0%EC%B4%88%EC%A7%80%EC%8B%9D