특별한 리소스 관리법

그럼에도 불구하고 너무나 인간적인

코딩할 때 우리는 모두 리소스를 관리한다. 메모리, 트랜잭션, 스레드, 파일, 타이머 등 사용에 어떤 제한이 있는 모든 종류의 것을. 대개의 경우, 리소스 사용은 예측할 수 있는 패턴을 따른다. 그렇지만, 많은 개발자들은 리소스 할당과 해제를 다루는 일관된 계획을 갖고 있지 않다.

- 앤드류 헌트, 데이비드 토머스 《실용주의 프로그래머》 中

"메모리가 풀 났습니다."

이 말을 들으면 신경이 곤두선다. 메모리가 풀(full) 났다는 것은 '가득 찼다'는 말이고 더 이상 분배할 자원이 없다는 말이다. 그럼 보통 사용자들은 시스템에 접속할 수 없거나 기능 사용이 제한된다. 이 같은 상황은 일반적으로 개발자 실수로 발생하는 경우가 많아 메모리가 풀 나면 PM은 뿔난다.

사원이던 시절, 선배와 협업해서 비교적 큰 기능을 개발한 적이 있다. 함께 코딩한 선배와 아이디어를 주고받으며 코드를 리뷰하고, 함께 디버깅하면서 많은 것을 배운 유익한 시간이었다. 중요한 기능이다 보니 테스트도 많이 하고 나름 신경을 많이 썼는데, 문제는 해당 기능을 반영한 다음 날인 월요일에 터졌다. 한창 사용자가 몰리는 시간에 시스템 접속이 안 된다는 연락을 받았다. 서버 담당자는 서버에 기록된 로그를 분석한 결과 우리가 개발한 부분에서 메모리가 풀이 나서 'Out of memory'가 발생한다고 했다. 

그때부터 상황은 긴박하게 돌아갔다. 나와 선배는 즉시 문제의 원인을 찾아야 했다. 분명 완벽하다고 자부한 코드에 문제가 발생했던 터라 몹시 당혹스러웠다. 주위의 이목이 집중되고 사람들의 관심이 느껴지자 코드에 더욱 집중이 되지 않았다. 그렇게 문제의 원인을 찾지도 못한 채 야속하게 시간은 흘러갔다. 사용자들의 문의는 쇄도하고, 문제해결이 지체되자 더는 안 되겠다고 느낀 PM이 호출한, 다른 개발자의 도움을 받고서야 문제의 원인을 찾을 수 있었다. 원인은 대량의 데이터를 파일로 쓰면서 자원을 효율적으로 관리하지 못해 발생한 데 있었다. 사용자가 몰리면서 리소스 사용률은 급속도로 치솟았을 것이다. 임계치를 넘어서면 결국 시스템은 버티지 못한다. 왜 그 부분을 고려하지 못한 걸까? 지금 생각하면 사전에 충분히 방지할 수 있었으리라는 아쉬움이 남는다.

리소스(resource)는 컴퓨터 시스템의 모든 자원을 총칭하는 말로서, 넓은 의미로는 컴퓨터 시스템에 종사하는 인력을 포함한다. 고로 개발자 역시 리소스의 일부다. 리소스를 관리해야 하는 이유는 자원이 한정돼 있기 때문이다. 프로그래밍할 때는 사용할 수 있는 메모리가 제한돼 있기에 사용 후에는 반드시 자원을 반환해야 한다. 그래야 프로그램이 원활하게 동작하고 중간에 멈추는 극단적인 현상이 발생하지 않는다.

이 경험을 통해 시스템 리소스의 일부인 개발자의 리소스 관리는 잘 되고 있는지 생각해 보게 되었다. 소프트웨어 개발은 분명 제한된 시간과 인력이 투입되는 활동이다. 그래서 일정이 부족하고 요구사항이 추가되면 인력과 기간을 더 늘려야 하는 것이 마땅한데도 부족한 게 마치 당연한 것처럼 지켜지지 않는다. 부족한 일정은 야근과 주말 근무로 채워지고, 개발자들의 리소스는 할당만 되고 제대로 해제되지 않는다. 프로젝트에 투입되면 한두 명은 꼭 병원에 입원하고, 대다수의 개발자들은 과로와 스트레스에 시달린다. 리소스가 풀이 나기 전에 충분한 휴식을 취해야 하는데도 현실은 투자한 자원을 넘어서는 효과를 원한다.

일과 삶의 적절한 조화는 때때로 어불성설처럼 들린다.

당장 개발해야 할 것들이 산적해 있는데, 여름휴가를 꿈꾸고 가족과 함께 여유로운 시간을 보낸다는 것은 현실적으로 불가능한 소리로 들린다. 참으로 슬픈 현실이다. 어느 순간은 일을 잠시 내려놓고, 방전된 배터리를 채워야 함에도 항상 일이 우선시 된다. 하지만 그럼에도 우리가 간과하지 말아야 할 사실은 기계처럼 일만 한다면 결국엔 지쳐버리고 말 것이란 점이다. 

나는 개발자가 현장에서 흔히 겪는 리소스 관리의 문제점을 개발자의 관점에서 접근해보고 싶었다. 개발자로 생활하면서 고려하지 않으면 언젠가는 문제가 되어 돌아오는 요소들을 살펴봄으로써 프로젝트의 중요한 인적 자원인 개발자가 자신의 자원을 효과적으로 관리하고 행복하게 코딩에 전념할 수 있는 환경을 조성하는 게 내 주된 관심사다. 실제 우리에겐 수많은 시행착오 끝에 터득한 소프트웨어에 대한 많은 리소스 관리 기법들이 존재하지만 인적 자원에 대해서는 등한시해 온 것이 사실이다. 

주위를 둘러보면 일하는 시간에 비례해 생산성이 높아진다는 사고가 만연하고 개발자를 닦달하면 일정을 줄일 수 있다는 생각을 가진 관리자나 고객사 담당자들이 아직도 많다. 또한 우리의 노동력을 단지 한 달 동안 프로젝트에 투입된 인력 수를 기준으로 사업비를 계산하는 M/M(Man Month)으로 수치화시킴으로써 인력의 수준에 상관없이 경제논리에 맞춰 사람을 양적 수단으로만 대하는 관례는 좀처럼 고쳐지지 않고 있다. 이런 현상은 이미 40년 전부터 프레더릭 브룩스(Frederick Brooks)가 그의 저서 《맨먼스 미신》을 통해 지적해 오던 터라 오랜 시간이 지나도 개선되지 않는 소프트웨어의 실태를 여실히 보여준다. 실제 브룩스는 한 여성이 임신해 출산하기까지 9개월이라고 할 때 9명의 여성이 임신을 한다면 한 달만에 출산할 수 있느냐고 반문했다. 몇 명이 임신을 하든 임신 기간은 9개월이고 아무리 많은 사람이 임신을 하더라도 기간을 나눌 수는 없다는 것이다. 즉, 단지 산술적 논리로만 소프트웨어 개발이 설명되지 않음을 주장했다.

이 오랜 악습들은 별다른 대안없이 현재까지 계승되어 개발자들을 괴롭히고 있다. 그럼 우리에게 현실을 개선할 방법은 없는 걸까? 이대로 불합리한 관행을 원망하며 언제까지나 현재의 문제를 안고 가야 하는 걸까? 특히나 리소스 관리는 우리의 삶의 질과도 밀접하게 연관된 문제라는 점에서 민감하게 다뤄질 필요가 있다. 

사실 이 부분에 있어서 내가 생각하는 가장 이상적인 해결책은 프로그래밍 시 리소스를 할당하는 루틴이나 객체가 해제까지 책임지듯, 리소스를 필요로 하는 주체가 되는 회사나 고객 또는 관리자가 해제까지도 함께 고려해주는 것이다(《실용주의 프로그래머》에서는 리소스 사용의 균형을 위해 “시작한 것을 끝내라”는 팁을 제시하는데 이때 고려된 사항이 자원 할당을 시작한 루틴이 해제까지도 책임지는 것이다.). 지적 노동자인 개발자에게 생산성은 단지 투입한 시간의 양에 비례하지 않는다는 점을 인식하고 가중된 리소스 부담이 오히려 프로젝트의 위험요소로 작용할 수 있음을 인정하는 게 맞다. 하지만 오랜 시간이 지나도 해결되지 않는 이 바닥의 생태를 볼 때 현실을 탓하며 마냥 기다리기보다 직접 나서 해법을 모색하는 것이 더 빠를 것 같다. 실제 누군가 만들어주기만을 바라다보면 지켜지지 않는 약속처럼 분노와 허무감만 더해질 것이다. 

그럼 우리가 취할 수 있는 적극적인 활동은 무엇이 있을까? 그것은 할당된 자원이 자동으로 해제될 수 있도록 최소한의 안전장치를 걸어두는 것이다. 실제 소프트웨어 개발에서도 프로세스가 사용하는 시스템 자원을 제한(limit)함으로써 시스템과 서버 환경을 보호한다. 특정 시간 이상의 접근은 timeout을 정해 차단하고, 지정한 최대 파일 사이즈나 메모리 양을 넘거나 최대 스레드 개수를 초과하지 못하도록 임계치를 설정함으로써 극단적인 상황에 대비한다. 

결국 무분별한 사용에 제한을 두는 것, 이것이 리소스 관리의 기본이다.

주어진 리소스를 넘지 않도록 일정 수준의 한계를 정해 스스로 자원이 해제할 수 있도록 유도하는 것이 우리가 적극적으로 자원을 보호하고 최소한의 삶의 질을 확보하는 방안이다. 이런 이유로 일찍이 익스트림 프로그래밍 진영에서는 에너지가 떨어진 상태에서는 집중력이 나오지 않는다는 이유를 들어 프로그래머에게 주당 40시간 이상의 노동을 지양해왔다. 나는 이 말에 전적으로 동의한다. 끊임없이 머리를 회전해야 하는 지식 노동자에게 머리를 쉬게 하는 시간은 필수로 요구된다. 오랜 시간 앉아있어도 머리가 돌아가지 않으면 차라리 나가서 바람을 쐬고 오는 편이 낫다는 것이다. 컴퓨터 앞에 마냥 앉아 있는다고 해서 코드가 작성되는 것은 아니다. 이땐 오히려 버그만 양산되어 품질에 악영향을 미친다. 그런 의미에서 보자면 개발자들에게 근무 중 티타임과 휴식시간은 소모되는 시간이 아닌 재충전이 되는 시간이라고 보는 관점이 맞다. 

아무리 바빠도 주기적으로 휴식을 취하고, 근무 시간 외 야근은 가급적 지양하며, 우리끼리라도 정시퇴근하는 사람들을 무책임한 사람으로 보는 시선을 거둬야 한다. 일을 우선해서 사람을 평가하는 것, 그리고 그렇게 확보된 시간은 사랑하는 사람들과 자신을 위해 사용하는 것. 이 모든 것들이 여전히 인식 부족으로 인해 여건은 어렵지만 우리가 먼저 비효율적이고 불합리한 관행을 타파하기 위해 노력해야 한다. 우리부터 눈치 보지 않고 이것을 당연한 권리로 여길 수 있어야 한다. 우리들의 용기 있는 행동은 때론 사회적 통념에 부딪혀 좌절되겠지만 최소한 다른 사람들의 선택을 좀 더 쉽게 도울 것이다. 

'시간이 없다'는 말을 입에 달고 산다면 삶의 통제권을 '일'에 넘겨준 것은 아닐까?

결국 나부터 나서서 용기를 내야 한다. 삶의 가치는 자신이 만드는 것이다. 시스템의 리소스 관리만큼 중요한 우리의 소중한 자원인 시간을 적절히 분배해 삶에 투입할 수 있어야 한다. 실제로 자신에게 의미 있는 일은 누군가에 의해 주어진 일이 아니라 스스로 발견한 일이다. 

내가 지금 바쁜 이유가 단순히 치열한 경쟁 속에서 뒤처지지 않기 위해 일에만 매달리고 있어서는 아닌지 생각해봐야 한다. 자원을 언제나 정확하게 해제할 수는 없겠지만 일에 끌려다니며 매번 일 속에 나는 없고 일만 존재한다면 그건 일 중독에 빠진 대표적인 모습일 것이다. 

영국의 경영사상가 찰스 핸디(Charles Handy)는 포트폴리오 인생을 살 것을 강조한다. 그가 말한 포트폴리오 인생이란 자신의 삶을 어떻게 재편하고 이끌어가느냐에 따라 만족하는 삶을 살 수도 그렇지 않을 수도 있으며, 어느 순간이든 자신이 주도해서 일의 적절한 균형을 고려해야 한다는 것이다. 실제로 그는 런던 근교에 있는 집에서 집필 작업을 할 때 집필하는 시간과 자료를 읽고 연구하는 일, 그리고 집안일 하는 시간을 적절히 섞는 계획을 세운다. 또한 휴식과 기분전환 시간도 꼼꼼히 챙긴다. 이렇게 적당한 이완을 포함한 계획된 활동은 일의 즐거움은 물론 균형 잡힌 삶이 가능하도록 돕는다. 결국 포트폴리오는 전문적인 일을 하는 사람들의 전유물이 아니라 행복한 일상을 꿈꾸는 사람들에게 반드시 필요한 요건이다. 사람마다 지향하는 바는 다르겠지만 결국에는 자신의 일에 에너지가 재충전되는 시간을 포함한 포트폴리오를 설계해야 한다는 점에서는 변함이 없다.

지금 생각하면 사원 시절에 만들어냈던 리소스 문제는 여유를 가지고 넓게 보지 못해서 발생했을 것이다. ‘한 발짝 뒤로 물러서서 봤으면 어땠을까’라는 아쉬움이 남는다. 사실 모든 일이 그렇다. 당장 눈앞에 닥치면 부담이 되고 큰 짐으로 다가오지만 한 발짝 물러서면 그동안 보이지 않던 부분들이 보이기 시작한다. 눈앞에 놓인 '일'을 지원하기 위한 우리의 '삶'이 그렇다. 일과 삶의 균형, 어떻게 보면 형용모순처럼 느껴지지만 이 둘을 어떻게 적절히 관리하느냐에 따라 삶의 질이 달라진다. 결국 삶과 일은 별개가 아니다. 실제 일을 단순히 생계의 문제로만 바라보면 밥그릇을 뺏기지 않으려는 지독한 존재로만 다가온다. 그럼 그때부터 삶이 치열해진다. 결국 일을 삶의 영역으로 끌고 올 수 있어야 한다. 일은 삶의 목적이 아니라 삶의 일부분임을 인식하는 것이 중요하다. 일에 저당 잡힌 인생은 초라하고, 자신의 삶을 우선적으로 살면서 일을 대하는 사람의 인생은 풍요롭다. 그런 의미에서 개발자에게 빡센 근무는 더이상 자랑거리가 아니다. 

오늘 하루도 시스템의 리소스를 모니터링하고, 메모리의 할당과 해제를 고민하는 개발자들의 삶에도 적절한 리소스가 재분배되어 삶을 위해 반환되는 환경이 갖춰지길 바란다.