프로그래밍의 다면적 특성
설계: 생각을 ‘차려’ 물질로 만드는 힘
프로그래머 대상 강의를 만들다가 문득 이런 생각이 들었습니다.
프로그래밍도 글쓰기와 비슷한 점이 있습니다.
타이핑을 해야 하고, 실제 이야기를 만들어 나가는 것이기도 하니까요. 다만, 그 줄거리를 상상력에만 의존해서 쓸 수는 없습니다. 그래서, 초기 프로그램들은 간단한 도식으로 표현했고, 알고리듬이라는 특수한 형태로 써 나가는 방식도 존재해 왔습니다.
엄격한 규칙성을 지닌 글쓰기
그래서, 프로그래밍을 '엄격한 규칙성을 지닌 글쓰기'로 볼 수도 있습니다. 프로그램은 구동하는 결과를 만나려고 작성하는데, 하드웨어가 지닌 제약이 고려되어야 합니다. 가상 머신(Virtual Machine)이라는 기술을 비롯해서 다양한 기술로 인해서 규칙 자체도 프로그래밍으로 작성하기도 합니다. 네트워크의 발달로 프로그램이 별도의 하드웨어에서 구동하는 분산 기술은 이제 아주 보편화되었습니다. 물리적인 제약은 모두 프로그램 규약(Protocol) 형태로 치환되거나 극복되는 듯 보이기도 합니다.
점차 하드웨어와 소프트웨어의 경계가 모호해지는 듯도 합니다. 그렇지만, 하드웨어에 대해 자유도가 높아진다고 해도 여전히 엄격한 규칙성을 요구한다는 점은 프로그래밍의 주요한 특징입니다.
협업이 요구되는 프로그래밍 환경
한편, 프로그래밍은 창작이긴 하지만, 예술로 보지는 않습니다. 프로그래밍의 결과물이 실용적으로 활용하기 위한 하나의 도구로 쓰이는 경우가 많습니다. 그리고, 많은 경우 산업 공간에서 제품이나 서비스의 일부로 만들어집니다. 그렇다 보니 가치나 가격을 높이기 위해서 다수의 서로 다른 사람들의 필요를 담으려고 합니다. 이에 따라 자연스럽게 협업이 이루어지는 경향이 있습니다.
2018년 한화 8조 원 상당에 마이크로소프트가 깃허브를 인수한 사건이 있었는데, 프로그래머의 협업의 가치를 보여준 대표적인 사건이라 할 수 있습니다.
하지만, 주변을 보면 협업을 어려워하는 개발자들이나 개발 조직을 어렵지 않게 볼 수 있습니다. 협업 과정에서 배운 소중한 경험을 '개취 인정'이라는 키워드나 '민주적 소통 절차' 따위에 담아서 글로 썼던 배경에는 그러한 어려움에 조금이나마 도움을 줄 수 있을까 하는 마음이 있었습니다.
프로그래밍의 두 가치 가치 생산 방식
여기에 더하여 프로그래밍은 경제적 측면에서 볼 수 있습니다. 직업 프로그래머라면 반드시 그래야 한다고 주장할 수도 있습니다. 최근 켄트 벡의 책을 번역하며 배운 내용 중에서 <소프트웨어는 두 가지 방식으로 가치를 만든다>는 점이 있습니다.
그리고 최근, 개발자 대상 발표를 하면서 '생존 부등식'[1]이란 개념을 개발자 용으로 수정해 본 일이 있습니다.
코드의 가치가 고객 만족도를 초과하도록 시간을 써야 한다는 주장을 부등식 형태로 강조한 내용인데요. 여기서 '고객 만족도'를 높이는 행위는 고객의 필요와 만족스러운 경험을 만드는 일이 주가 되겠지만, 빠른 반영을 위해 코드 구조를 개선하는 일도 간접적으로 기여를 하게 됩니다. 한편, 불필요한 기능을 미리 만들어서 시간을 낭비하지 않는 일 역시 잠재적으로 고객 만족도를 높이는 일이라 할 수 있습니다. 애자일(Agile) 방식이나 문화가 널리 활용되는 이유도 그러한 맥락에서 생각해 볼 수 있습니다.
결론
사람들과 프로그래밍이나 소프트웨어 개발에 대해서 이야기를 나누다 보면 같은 사안을 가지고도 상당히 다른 방향으로 이야기가 전개되곤 합니다. 모두 인식과 관심사가 다르니 당연한 일이기도 하지만, 적어도 다양한 의견을 듣기 위해서는 여러 가지 관점이 존재할 수 있다는 사실을 알고 있는 것이 유리하다는 생각에 짧은 생각을 기록으로 남깁니다.
주석
[1] 요즘IT에 김수보 님이 쓰신 글에서 찾은 개념입니다.
