기술 황무지에서 살아남기: 제가 어떻게 해야 하나요?
들어가기 전에 : 테크 기업이 아닌 전통적인 서비스 기업에서 주니어 개발자로 지낸 6개월, 그 시간 동안 겪은 시행착오와 작지만 소중했던 시도들을 글로 정리해봤습니다. 선배 개발자 분들의 많은 조언과 피드백 부탁드립니다.
컴퓨터공학을 전공했고, 나는 자연스럽게 개발자가 됐다.
첫 회사에 들어갈 때는 기대도 컸다. 테크 기업은 아니었지만, 사용자에게 가치를 전달하는 '서비스'의 본질을 배우는 게 더 중요하다고 생각했다. 최신 기술을 반드시 다루지 않아도 괜찮다고 여겼고, 실무 경험과 문제 해결 능력이 더 중요하다고 믿었다.
하지만 현실은 생각보다 훨씬 복잡했다. 이 정도로 시스템이 낙후돼 있을 줄은 몰랐고, 무엇부터 손대야 할지조차 막막했다. 기술적인 기반이 부족하다 보니, 개선을 시작하는 것 자체가 쉽지 않았다.
겉보기에는 컨테이너 기반의 기술을 쓰고 있었지만, 그건 껍데기에 불과했다. 서비스는 Docker 위에서 돌아갔지만, 그에 걸맞은 운영 체계는 없었다. 모니터링 시스템은 없었고, 장애나 리소스 이슈에 대한 대응은 늘 늦었다. 로그 관리나 배포 이후의 관측 체계도 부재했다.
개발자가 시스템 전반을 이해하거나 주도적으로 개입하기 어려운 구조였다.
ORM 도입, 모니터링 구성, 인프라 운영 같은 기술 결정은 외부 업체가 주도했고 개발자는 주어진 구조 안에서 구현만 맡는 경우가 많았다.
코드 리뷰도 없었고, 기술을 실험하거나 제안할 기회도 드물었다.
아.. 말 그대로, 이곳은 기술 황무지였다.
그 속에서 도망치고 싶었던 순간도 많았다. 이직을 진지하게 고민한 적도 있었다. 처음엔 '왜 이 정도도 안 돼 있지?'라는 의문이 들었고, 기대보다 현실이 훨씬 부족해 보였다. 더 답답했던 건, 그 환경에서조차 내가 성장할 수 있는 구조가 없다는 점이었다.
그러다 어느 순간, 생각이 바뀌었다.
"내가 황무지를 숲으로 바꿀 수 있는 건 아닐까?"
로드맵은 없었지만, 기반이 전혀 없는 건 아니었다. 그러면 방향을 만들면 된다고 생각했다. 그래서 할 수 있는 일을 스스로 정의하고, 하나씩 실행해 보기로 했다. 내가 가진 지식 안에서, 지금 할 수 있는 일을 찾는 것. 그게 내가 황무지에서 살아남는 방식이었다.
크고 대단한 프로젝트는 아니었지만, 분명한 문제의식을 갖고 두 가지 작업을 주도했다. 그 경험이 나를 단단하게 만들었다.
지금부터 그 이야기를 해보려 한다.
모니터링 시스템을 구축하며 생존을 시작하다
입사 후 얼마 지나지 않아 깨달았다. 우리 회사에는 애플리케이션 상태를 실시간으로 확인할 수 있는 방법이 없다는 것이었다.
AWS EC2에서 운영 중인 SQL Server, Docker로 배포된 컨테이너, 온 프레미스 서버까지 다양한 환경이 혼재했지만,이를 통합적으로 관리할 체계는 없었다.
트래픽이 폭주하거나 시스템이 자주 멈추는 건 아니었지만, 불필요한 리소스 낭비와 장애 대응의 어려움은 분명 존재했다.
그래서 이렇게 생각했다. "인프라를 더 효율적으로 운영하면, 비용도 줄이고, 안정성도 높일 수 있지 않을까?" 이 작은 문제의식이 모니터링 시스템 구축으로 이어졌다.
선택한 도구
cAdvisor: 컨테이너 리소스 수집
Prometheus: 메트릭 수집 및 저장
Windows Exporter: EC2 서버의 성능 데이터 수집
Grafana: 대시보드 시각화
Docker Compose로 도구들을 구성했고, Windows Exporter를 EC2 인스턴스에 설치해 Prometheus와 연결했다. Grafana로 온프레미스와 클라우드 데이터를 통합 시각화할 수 있도록 했다.
설정 파일을 다루고, 도구 간 흐름을 연결하는 과정을 통해 단순한 설치를 넘어 시스템을 바라보는 시야를 얻을 수 있었다.
SP에서 ORM으로, 낡은 구조를 넘어서다.
두 번째 프로젝트는 더 오래된 구조와의 싸움이었다. 우리 시스템은 대부분 Stored Procedure(SP) 기반이었다. 로직은 데이터베이스에 묻혀 있었고, 쿼리들은 서로 얽혀 있었다. 문서는 있었지만 구조를 파악하기 어려웠고, 테스트와 협업도 쉽지 않았다.
SP는 과거엔 합리적인 선택이었지만, 지금은 여러 문제를 드러내고 있었다.
로직 분산으로 협업과 테스트가 어렵다.
버전 관리가 되지 않는다
벤더 종속성으로 확장성과 이식성이 떨어진다.
이 문제를 해결하기 위해 ORM 기반 구조로 점진적 전환을 시작했다. 단순한 조회부터 복잡한 트랜잭션까지 하나씩 옮기며 비교하고 테스트했다.
N+1 문제, 성능 이슈, 조직 내부의 우려 등 장애물도 있었지만, “지금은 괜찮아도, 언젠가 큰 문제가 될 수 있다”는 생각으로 실험을 이어갔다. 이 전환은 단순한 기술 교체가 아니었다. 시스템을 ‘관리 가능한 구조’로 바꾸는 작업이었다.
아직 모든 로직이 전환된 건 아니지만, 많은 것이 바뀌었다. 코드는 명확해졌고, 테스트가 가능해졌으며, 다른 개발자도 구조를 빠르게 이해할 수 있었다. 작은 변화들이 팀의 리듬을 바꾸고 있었다.
황무지에 첫 묘목을 심으며
기술 황무지에서 살아남는다는 건 최신 기술을 다루는 것이 아니다. 지금 있는 환경에서, 내가 가진 지식으로 할 수 있는 일을 실행하는 것이다. 누군가는 이런 환경을 비효율적이라 말할지 모른다. 하지만 나는 이곳에서 문제를 정의하고, 해답을 직접 설계하는 힘을 배웠다. 모니터링 시스템을 만들며 인프라를 이해했고, ORM 전환을 통해 시스템 구조를 다룰 수 있게 됐다.
그리고 무엇보다, 그 일을 시도할 수 있었던 건, 혼자였지만 혼자만은 아니었기 때문이다.
내 가능성을 믿고, 자율성을 맡겨준 팀장님이 계셨기에 내가 하고 싶었던 일을 실제로 해볼 수 있었다.
나는 황무지에 첫 묘목을 심었다. 아직은 주니어 개발자라 작은 묘목 하나밖에 심지 못했지만, 언젠가 이곳이 숲이 되기를 바란다.
기술 황무지에서도 살아남을 수 있다. 그 출발점은 언제나, “내가 가진 지식 안에서 할 수 있는 일을 찾는 것”이다.
관련 포스팅 읽기
왔노라, 보았노라, 모니터링 했노라 : 제로부터 시작하는 모니터링 시스템 구축 - https://okky.kr/articles/1529867
달리는 자동차의 타이어를 교체하기 : Stored Procedure 기반 데이터 접근 방식에서 ORM 기반으로 전환 (1) - https://okky.kr/articles/1529724
