Friday, Aug 30, 2019
이래저래 십수년간 코딩을 하면서 천천히 만들어진 나의 개발철학에 대해서 이야기해보려고 한다.
이 항목은 개발관이라기보다는 직업관에 가까운 내용이다.
한때 나는 나에게 주어진 일만 잘하면 아무런 문제가 없다 라고 생각을 했다. 나에게 주어진 일을 빨리 끝내면 미래의 할 일을 미리 하고 그것마저 다 했다면 업무를 확장하여 더 많은 일을 해내고 이를 통해 능력을 인정받는 것이 엔지니어로서 가장 큰 성취라고 생각을 했었다.
하지만 이 생각이 틀렸다는 것을 깨닫는데에는 긴 시간이 걸리지 않았다.
일단, 어떠한 집단 에서 내가 소속되어 하는 일이 어떤 성격을 가지는지를 생각해보아야 한다.
인간이 집단을 이루어서 행하는 일들은 대부분 혼자서 해결하기 어렵거나 큰 일이다. 그리고 그중에 나에게 주어진 일이 그자체로 가치를 가지는 경우는 많지 않다. 대게는 다른이가 이룬 성취들과 합쳐져서 큰 목표나 목적을 달성할때 비로소 가치를 얻게 된다.
즉, 내가 많은 가치를 만드는데 기여하는 사람이 되려면 나에게 주어진 일을 잘 해내야 함은 물론이고, 나의 성취가 전체의 가치의 일부가 되기 위해 필연적으로 의존하고 의존될 다른이의 성취를 가속하는것도 매우 중요하다.
이 생각을 좀 더 큰 스케일에서 적용 해 보면. 집단이 수행하는 목표나 목적을 달성하기위해 필요한 모든 일은 구성원 모두의 것이며 나에게 주어진 일은 나의 책임의 범위 내에 있을뿐이다 라고 정리 할 수 있다.
“난 내가 할 일을 다 했어!"
축하한다. 당신은 당신의 책임을 훌륭하게 완수했다.
이제 더 큰 목표를 이루기 위해 주변을 돌아볼 시간이다.
컴퓨터 프로그래밍 은 컴퓨터 프로그램을 만드는 행위이고 __컴퓨터 프로그램__은 컴퓨터가 작업을 수행하기위한 명령어들의 집합체 라고 정의된다.
하지만 난 프로그래밍을 왜 하는지에 대해 계속 질문을 던져왔고 나름대로 정리가 생겼다.
내가 생각하는 프로그래밍의 목표는 __정보를 다루는 것__이다. 불과 망치로 쇠를가공하듯 코딩을 해서 정보를 다루는것이다.
정보가 크건, 작건 어딘가 저장이되건, 휘발되건 이런건 큰 의미가 없다. 정보를 생성, 전달, 가공, 보존 하는 모든 행위가 이에 포함된다. 수많은 개념들이 흥망성쇠 했지만 변하지 않는것은 프로그램의 “입력과 출력”, “자극과 반응"의 대상이 되는것은 항상 데이터 자체였다.
쓰기편하고 아름답게 만들어진 UI, 소설처럼 쉽게 읽히는 예술적인코드, 번개보다 빠르게 동작하는 성능을 가진 프로그램 이라도 잘못된 정보를 만들어낸다면 아무도 사용하지 않을것이다.
그럼 프로그래밍을 하면서 우리가 최악의 상황에서도 사수해야하는 단 한가지, 그리고 마지막 가치는 정보를 잘 다루는 것이 된다.
만들지 않아도 될 삼중 for 문을 작성하거나, 반납하지 않은 메모리들이 널부러져있는것도 세상끝 마지막 최후에는 괜찮을 수 있다. 데이터만 “잘” 처리되고 있다면.
“내가” 하는 __“프로그래밍”__의 목적이 __“무엇”__이냐를 “데이터” 라고 정의 했다면 프로그래밍을 “어떻게” 할것이냐 라는 질문이 따라오게 된다.
프로그램을 작성하는것은 문서와 논리를 자아내는 창작활동인 동시에 생명을 가진 결과물을 만드는 생산활동이다.
게다가 서로 다른 인격체들이 여럿 모여서 함께 해내야 하는 과제다.
프로그래밍은 한순간에 끝나지 않기 때문에 작업에 참여하는 사람들의 의식을 한방향으로 유도하지 않으면 갈피를 잃고 코드의 엔트로피가 높아져서 결국은 유지보수가 더2019-08-30T14:12:03.388Z이상 불가능한 지경에 (너무 빨리) 이르게 될것이다.
그렇다면 프로그램의 “수명” 을 길게 만들기 위해서는 어떤것들이 필요할까?
옛날 일기를 꺼내 읽어보면 느낄수 있듯, “미래의 나” 와 “과거의 나” 는 “현재의 나” 가 아닌 타인이나 마찬가지다. 이 때문에 나는 개인 프로젝트를 할 때에도 내 코드를 읽고 이해하며 고치는 사람이 완벽한 타인으로 간주하기로 했다.
지속가능한 개발이라는것이 “내 다음에 일할 사람이 계속해서 작업할 수 있는 환경을 만들어주는것” 이라고 정의하면 “과거의 나” 라는 타인이 내게남긴 코드에서 “현재의 나” 가 기대하거나 요구하는것들을 “미래의 나” 에게 만들어 건내주는것이 제일 쉬운 접근방법이라고 생각했다.
당장 몇개 생각해보자면 이런것들이 있을 수 있겠다.
이왕 만드는 내 자식같은 프로그램들이 이왕이면 다른사람의 도움을 받아 많이 발전하고 장수하면 좋지 않은가?
신기술은 기존기술의 한계를 극복하기위해 개발되거나 새로운 패러다임을 제시하기 때문에 배울점이 반드시 있다고 본다.
때문에 항상 우리가 새로 접하는 신기술들은 밝게 빛나보이며 자기들이 제일 잘났다고 소리를 지른다.
하지만 무조건 현혹되어 비판하지 않고 맹목적으로 신기술을 수용하게 되면 필요도 없는 기술을 공부하는데 시간을 낭비하거나 시야가 좁아질 위험이 있다.
특히나 요즘은 오픈소스 프로젝트들도 어딘가에는 결국 비지니스를 하는 조직이 있는경우가 많기 때문에 장점이 부풀려지고 단점은 쉬쉬하려고 한다.
그렇다고 쏜살같이 흘러가버리는 기술트랜드를 그냥 놓아서 흘려 보낼수는 없으니 “적당히” 파악을 해두는 노력은 항상 해야한다.
우선, 신기술을 파악해두는 목적이 무엇인지 분명히 해야한다.
모든 요구조건을 만족시킬 수 있는 완벽한 범용기술은 존재하기 어렵다. 같은 영역에서 사용되는 소프트웨어라고 할지라도 장점과 단점을 각기 가지고, 그로인한 개성과 특징이 기술선정의 이유 혹은 목적이 된다.
그래서 나는 “미래에 내가 이런기술이 필요할때 선택지에 넣기위해서” 알아둔다고 생각한다.
이런 생각을 가지고 나면 신기술을 공부할때 관심있게 보아야 하는 포인트들이 명확해진다.
전문가가 될 필요도 없고, 어디가서 아는척을 할 필요도 없다. 단지 머릿속에 색인해두고 가끔씩 업데이트 해두면 나중에 기술선정을 해야할때 서베이를 시작하는 마중물로 사용하기만 해도 충분히 가치가 있을것이다.
파이의 테두리나 수박의 흰부분처럼 맛없는 부분 같은게 프로그래밍에도 있다. 문서작성, 테스트코드작성, 혹은 자동화하기 애매한 반복작업등이 내게는 그런 부분이다.
이런 일들은 남이 대신해주지 않을뿐더러 해주는게 효율적이지도 않다. 완성된 소프트웨어를 만드는데는 반드시 필요한 부분이기 때문에 피할 수도 없다.
나는 이런 일들을 최대한 줄이거나 효율적으로 처리하기 위해 가능한 자동화를 하지만, 이렇게까지 해도 결국 우직하게 해 내야만 하는 일은 남는다.
받아들이는데는 여러가지 방법이 있겠지만 난 이것을 완성을 하는 작업이나 일종의 수양으로 받아들이곤 한다.
용그림의 눈에 점을 찍는다는 마음으로 인내를 가지고 할 수 밖에 없다.
그리고 비로소 전체가 완성되었을때 느낄 수 있는 희열은 코딩이나 디버깅을 하면서 얻을 수 있는 그것과는 또 다른 느낌인지라 나름대로의 재미가 있다.
프로그래머 100명이 있다면 개발철학도 100개가 있을것이고, 나의 기준과 완벽히 대치되는 지점에 서있는 누군가도 있을것이다.
그렇기에 이런 생각들은 맞고 틀리고를 가리고자 하는 기준이라기 보다는 프로그래머의 개으로 보고 서로 존중하는것이 좋다고 생각한다.