시니어 프로그래머로 넘어가는 길 (3)

2019/01/20 - [Programming/기타] - 시니어 프로그래머로 넘어가는 길 (2)

이번 글은 적을까 말까 고민하다가 결국 적기로 마음먹은, 일종의 후기나 외전 같은 성격의 글입니다. 실제 있었던 일을 저의 편향된 시선으로 적은 내용이므로 잘 가려서 보시길 바랍니다.

제가 겪은 회사의 사례를 통해 왜 고급개발자가 필요하며, 고급개발자가 어떠한 환경에서 일해야 하는지와 고급개발자로 어떠한 일을 해야 하는지, 그 필요성에 대해서 약간은 알려지게 되길 기대합니다.

제가 겪은 회사의 사례입니다.

회사는 여러 가지 서비스를 제공하고 있는 상태였고, 개발자도 수십 명을 보유한 곳이었습니다. 하지만, 내부적으로는 기술력이 높지 않다고 구성원들이 생각하고 있었고, 서비스의 질 보다는 내부 코드나 아키텍쳐에 큰 불만이 많은 상태였습니다.

제가 이 회사 입사할 때에는 이런 내부적인 상황을 알 수 없었습니다. 단지, 채용공고에 JSP, PHP 등의 개발을 할 수 있는 서버 프로그래머를 채용한다고만 되어 있었으니까요. 실제 면접 시에도 관리직이 아닌 개발자로써 오랫동안 일하고 싶다고 했고, 면접관들 역시 이 회사는 그렇게 할 수 있고 개발 경력을 잘 살려서 회사에 공헌해달라고 했습니다.

채용 후 얼마 지나지 바로 몇 가지 문제가 눈에 띄였습니다.

1. 개발 언어가 PHP 와 특정 프래임워크 하나로 통일된 상황이었습니다. 프래임워크를 쓰는 이유를 잘 몰랐던 것 같은 코드들이 저에게 주어졌었습니다. 다행인 건, 이 코드가 이 회사에서 가장 엉망인 코드로 정평이 나 있었던 코드였다는 것이었습니다. 최소한 다른 곳은 이보다는 낫겠다 싶은 것이 그나마 위안이었습니다. 하지만, 그 때 당시에 보안 패치가 곧 끝나가는 PHP 버전과 이를 업그레이드 하기 힘든 상황 등이 맞물려 이러지도 저러지도 못한 상황이었고, 회사의 정책이 이러한 문제를 해결하기 힘들게 만들고 있었습니다. 게다가 프래임워크에서 제공하는 기능 조차 커스터마이징을 하거나 의도적으로 무시하고 사용하고 있어서 문제 발생 시 원인 파악이 힘들고 DBA 조직에서 Wait Timeout 을 너무 짧게 설정해서 Query 수행 후 중간에 약간 긴 처리 시간을 가진 코드를 실행하면 Connection 이 종료되어 오류가 발생하는 아주 기본적인 문제까지 존재했습니다. 게다가 상당수의 기능을 상당수의 Controller 가 상속받는 상위 Class 를 만들어 구현하다 보니, 해당 기능이 필요없음에도 페이지 호출 때마다 그 Class 을 읽어서 페이지 열림이 매우 무거운 형태도 문제였습니다. 물론 PHP IDE 가 Java 나 C# 같은 언어에 비해 지원이 너무 빈약하고, 프래임워크 지원도 제대로 없어서 개발자의 노하우에 따라 결과물 나오는 시간이나 품질이 차이가 많이 난다는 문제도 있었습니다.

2. RDBMS 의 관리가 너무 보수적이었습니다. MySQL 을 주로 썼는데 버전은 최신 release 버전의 몇 단계 아래 버전에 고정되어 있었고, 몇 안되는 시스템은 SQL Server 을 이용중이었으나 이 또한 출시한 지 십 년이 다되어 가는 버전과 함께 많은 레코드를 한 테이블에 넣고 저장하기 위해 MySQL 대신 사용할 뿐, DBA 가 아닌 개발자 입장에선 왜 SQL Server 을 써야 하는지 알기 힘든 상황이었습니다. 아이러니 하게도 개발코드도 엉망이라 Transaction 조차도 쓰고 있는지 의심스러운 부분이 많은 상태였습니다. Sharding 은 당연히 존재하지 않았고, MySQL 은 Master 와 Slave 로 나뉘어져 있고 코드에서 성격에 따라 읽기/쓰기 혹은 읽기 전용 상태에 따른 DB 연결을 나눠서 쓰는 고전적인 형태를 사용중이었습니다. 그러다보니 Scale Out 에 대한 대비가 전혀 이루어지지 않고 있었습니다. 그리고 SQL Server 에 연결된 서비스는 이러한 부하분산 조차 존재하지 않았습니다.

3. RDBMS 의 부하 분산을 위해 Cache 을 도입했습니다. 하지만 여기서도 큰 문제가 몇 가지 있었습니다. 가장 빠른 속도를 자랑하는 Memcached 을 도입한 것인데, 이를 관리할 주체가 없었습니다. RDBMS 에서 부하를 견디지 못해 도입한 것인데 개발자가 그냥 적용한 뒤 운영가이드를 만들거나 다른 팀에 메뉴얼을 만들어서 양도한 것이 아니라, 건드리지 않아도 잘 돌아가고 있으니 그냥 두고 쓰는 형태였던 것입니다. 또한, PHP 에서 Memcached 을 접속할 때에 여러 서버에 분산해서 저장할 수 있는데, 이 알고리즘을 PHP Module 이 결정하기 때문에 서버 장애 시 데이터의 오염 등 문제를 야기할 수 있는 상황이었습니다. 이보다는 좀 덜한 문제이지만, Memcached 는 기본적으로 범위(range) 검색이 없기 때문에 Key 기반으로 가져올 데이터(Value)를 정확히 지정해줘야 하는데, 특정 날짜의 정보를 가져올 때에는 Key 에 날짜 정보를 포함시켜 이를 이용할 수 있지만, 시나 분까지 범위 검색을 해야한다면 너무 요청량이 많아지기 때문에 이렇게 구현할 수 없다는 문제가 존재합니다.

다만, PHP 을 쓰면서 가지는 장점도 보였습니다.

1. Capistrano 기반의 배포 환경을 구축하여 서비스 중지 없이 새로운 소스로 배포할 수 있는 환경을 구축하였습니다.

이러한 문제를 해결하기 위해 해결책을 모색했습니다. 물론 저의 경험을 통해 해결책을 몇 가지 제시하는 것이기 때문에, 저의 경험의 폭이 적으면 적을수록 해결책의 수도 적겠죠.

제가 제시한 해결책은 위 번호와 관계없이 다음과 같습니다.

1. PHP 와 같은 동적, Script 기반의 언어는 개발자의 숙련도가 미치는 영향이 크고 Singleton 등을 이용할 수 없는데, 이는 개발자의 실수나 DB Pool 혹은 Class Loading 등을 하지 못하거나 불완전하게 하기 때문에 불필요한 리소스 소모가 많습니다. 특히 PHP 에서 DB Pool 등은 불안정하고 완벽하지 않으니 Java 나 C# 와 같은 언어로 교체할 필요가 있습니다.

2. MVC 을 잘 설계하고 상속으로 전처리를 하는 방식을 지양해야 합니다.

3. RDBMS 을 통일하고 버전업을 할 필요가 있습니다. 아울러 NoSQL 을 적절히 도입해야 합니다.

4. Memcached 운영에 문제가 많으니 NoSQL 도입 시 Memcached 을 대체할 방법도 같이 논의되어야 합니다. 특히 운영 상 다루기 까다로운 제품은 지양해야 합니다.

5. Java 나 C# 등으로 언어를 변경할 경우 소스 덮어쓰기로 실시간 배포의 효과를 누리기 힘들기 때문에 Active-Stanby 형태의 서버 구성을 통해 실시간 배포를 유지할 수 있는 방안은 모색해야 합니다.

이러한 제안을 하였고, 일부는 실제 적용도 되었습니다.

하지만, 문제는 개발자들이 이러한 변화를 두려워하는 것에서 발생할 것 같다는 처음의 걱정과는 달리 기존 개발자들은 너무나 이를 환영하는 반면에 개발자들 혹은 개발 외의 조직의 관리자들이 기존 원칙을 고수하거나 변화를 위해서 너무나 많은 절차와 근거를 요구하기 시작했습니다. 그래서, 이 때 안좋은 방법도 몇 가지 동원됐는데 그 중 하나가 "제가 해봤는데요" 입니다. 실제 제가 써본 라이브러리나 제품을 제안에 넣고, 이것이 문제가 없는지에 대한 자료 요청에 "권위" 를 이용하는 안좋은 방법도 취할 수 밖에 없었습니다. 어느 정도까지는 이것도 먹혔으나, 실제 NoSQL 하나를 회사의 표준으로 삼고 이를 DBA 조직이 관리하는 형태를 취하자고 했을 때, 많은 자료가 제공되고 테스트와 개발자 사용 의견 등이 제시됐으나 내부 베타테스트에만 반 년이 소모되고, DBA 조직이 이를 운영할 수 있는 학습 시간을 가지는데 다시 일 년이 소모되었습니다. 인력 부족 등의 문제가 있었겠지만, 사실 그건 당사자들만 알 문제겠죠. 하지만, 이를 사용해 본 적이 있는 사람과 비교적 잘 구성되어 있는 시스템과 문서들이 있음에도 1 년 이상의 시간이 소모되었다는건, 기존의 업무를 더 개선하기 위해서는 주니어 개발자가 진행하는 건 꿈만 같은 일이고, 시니어 개발자로도 아주 힘든 여정이라는 것을 보여주는 사례라고 볼 수 있겠습니다.

물론 이 외에도 언어 변경과 같은 일을 진행하면서도 문제가 많았습니다. 특히, 언어를 선정할 때 여러 개발자들이 모여서 토론을 해서 Java 로 결정했는데, 나중에 다른 조직에서 "새로운 기술을 써보기 위한 너희의 욕심 아니냐" 라는 말도 들었습니다. 저는 그 선봉에 서서 "새로운 것만 하려고 하는", 말 그대로 회사를 생각하지 않는 사람으로 인식되었구요. 네...제가 2000년 부터 쓰던 Java 을, 제임스 고슬링이 1995 년에 오픈한 Java 을 어떤 조직에선 "최신 기술" 로 받아들이고 있더군요. 하나의 조직에 너무 오랫동안 머물러 있으면 이런 일이 발생할 수도 있구나...싶은 사례였고, 이를 타파하기 위해서는 다양한 경험이 필요하다고 느꼈었습니다. 물론 PHP 을 극한까지 갈고 닦아서 이러한 문제를 다 해결할 수 있는 분도 존재하겠지만, 아쉽게도 제 눈에는 그게 훨씬 어려워 보였습니다.