개발자 vs 엔지니어: 생각을 바꿔 메모리 문제를 해결한 방법

출처: Dev.to

개발자와 엔지니어의 가장 큰 차이는 단순히 작성하는 코드에 있지 않다. 시스템을 어떻게 설계하고, 어떻게 최적화하며, 자원을 어떻게 활용하는가에 있다.
이 점을 나는 실제 프로젝트를 통해 깨달았다.

테스트를 진행했을 때, 메모리 사용량이 평소보다 훨씬 높았다. 정상 범위보다 훨씬 많이 사용되고 있었다.
개발자라면 그냥 넘어갔을 것이다. “동작하잖아, 괜찮아.” 라고 말이죠. 하지만 나는 왜 이렇게 메모리를 많이 잡아먹는지 스스로에게 물었다.

사실 나는 메모리를 두 배로 늘리는 작업을 무의식적으로 하고 있었다. 먼저 10,000개의 레코드를 모두 메모리에 로드해 데이터를 저장했고, 그 뒤 파일에 쓰는 동안에도 같은 데이터를 다시 메모리에 보관하고 있었다. 같은 데이터가 메모리 안에 두 개씩 존재하는 셈이다. 이런 방식은 요청이 많아질수록 신뢰할 수 없고, 확장성이 떨어진다. 조용히 자원을 잡아먹을 뿐이다.

그때 나는 스트림을 발견했다.

스트리밍의 아이디어는 단순하지만 강력하다. 모든 데이터를 한 번에 로드하는 대신, 데이터를 작은 청크로 나눈다. 언제든 메모리에는 하나의 청크만 존재한다. 그 청크를 읽고, 변환하고, 파일에 쓰고, 다음 청크로 넘어간다.

변환 단계가 핵심이다. 단순히 데이터를 한 곳에서 다른 곳으로 옮기는 것이 아니라, 각 청크를 검증하고 구조가 올바른지 확인하며, 필요하면 정제까지 한다. 즉, 파일에 기록되기 전에 데이터를 미리 정리할 수 있다. 이렇게 하면 메모리를 효율적으로 사용할 뿐 아니라, 데이터 처리에 대한 제어권도 높아진다.

그리고 한 번에 작은 조각만 작업하기 때문에, 100개의 요청을 처리하든 100,000개의 요청을 처리하든 메모리 사용량은 낮고 일정하게 유지된다.

“내가 자원을 신뢰할 수 있게 사용하고 있는가?”라는 한 가지 질문이 문제를 단순히 해결하는 수준을 넘어, 근본을 이해하게 만들었다. 이것이 엔지니어의 사고방식이다. 단순히 동작하게 만드는 것이 아니라, 내부에서 어떻게 동작하고 확장될 때 어떤 일이 일어나는지를 고민하는 것이다.

이 사고 전환이 모든 것을 바꾸어 놓았다.