재사용 가능한 과정과 건축 - 2
2025. 08. 05.
그간 개발을 공부하며 얻은 기술들을 생각해본다. 처음에는 작은 기능을 만드는 것부터 시작했다. 예를 들어, 계산기의 더하기 기능을 파이썬으로 구현해보는 것이다. 입력과 출력이 정해져 있고, 이 조건만 지키면 구현은 어떻게 해도 상관 없다. 내 컴퓨터에서 작동하기만 하면 된다는 측면에서 아직까지는 코드 자체에만 집중하면 되고, 코드가 돌아가는 환경에 대해서는 신경쓰지 않아도 괜찮다. 그러다가 웹서비스쪽 개발을 시도해보거나 다른 컴퓨터에서도 쓸 수 있는 패키지 개발을 시도해보는 순간 갑자기 코드가 돌아가는 환경에 신경을 쓸 일이 생긴다. 내 컴퓨터에 설치된 파이썬이 3.13이라고 해서 이 코드를 돌릴 다른 컴퓨터에도 같은 버전의 파이썬이 설치되어있을 거라고 보장할 수 없다. 어떤 패키지는 윈도우와 리눅스 환경에서 내보내는 결과가 소수점 아래 10자리 정도부터는 차이가 나서 이 패키지의 기능을 활용할 경우 윈도우 환경에서 문제 없이 돌던 코드가 리눅스 환경에서는 각종 버그를 발생시킬 수도 있다. 이런 문제들에 맞닥뜨리는 순간 우리는 코드가 잘 돌아야 할 뿐만 아니라 코드가 도는 환경에 대한 일관성을 보장하거나, 여러 환경에서 코드를 돌려도 일관된 결과가 나올 수 있도록 구현해야 한다는 것을 깨닫는다.
어떻게 코드가 도는 환경의 일관성을 유지할 수 있을까? 파이썬의 venv나 노드의 npm 같은 도구들은 필요한 패키지들만 설치된 환경에서 코드를 돌릴 수 있도록 도와준다. 아무 패키지도 설치되지 않은 상황에서 버전이 지정되어 있는 패키지를 하나씩 차근차근 설치한 다음 코드를 돌린다면 적어도 내 컴퓨터에서는 shapely 2.1버전을 써서 기능을 개발했는데 다른 컴퓨터에는 shapely 1.8버전이 깔려있어서 코드가 돌다가 터졌다- 같은 일이 발생하지는 않는 것이다. 하지만 가장 좋은 방법은 OS만 설치된 백지 상태의 기기에서 필요한 언어부터 설치한 다음 내 코드가 돌아갈 거라고 생각하는 것이겠다. 예를 들어, 방금 포맷한 윈도우 컴퓨터에 파이썬 3.13 버전을 설치하고, 내 파이썬 코드를 돌리기 위해 필요한 특정 버전의 패키지들을 설치한 다음 내가 작성한 코드를 돌리는 것이다. 개발자들이 이야기하는 도커(docker)가 해주는 것이 대략적으로 이런 작업이라고 보면 되겠다. 백지같은 환경에 필요한 것들만 설치해서 내 코드를 돌리기. 그런데, 포맷 없이.
이 글을 통해 주장하고 싶은 것은 개발자의 능력은 기능 개발 뿐만 아니라 개발한 기능이 돌 수 있는 환경을 관리하는 것까지로 보아야 한다는 것이다. 여기부터가 본론인데, 내가 관심가지고 보고 있는 것은 이 당연한 이야기가 왜 개발을 공부하는 건축가들, 혹은, 컴퓨테이셔널 디자이너들에게는 자칫 생소한 주제로 보일 수 있느냐이다. 그래스호퍼를 사용해서 어떤 형태를 만드는 기능을 구현했다고 치자. 이후에 다음과 같은 일이 자주 발생한다.
- 친구가 내가 만든 기능에 관심을 보여서 친구에게 내가 만든 그래스호퍼 파일을 보내주었는데 뭔가... 뭔가 missing 되었다고 뜨면서 작동하지 않는다.
- 외장 하드에 그래스호퍼 파일을 저장해두었다가 나중에 포트폴리오에 쓸 이미지를 다시 만들기 위해 다시 열어보았는데 또 무언가의 문제로 작동하지 않는다.
기껏 기능을 만들었는데 딱 이 기능을 만든 시점의 내 컴퓨터에서만 작동한다니, 아주 환장할 노릇인 것이다. 나는 이로부터 다음과 같은 문제들이 발생했다고 생각한다.
- 컴퓨테이셔널 디자이너들이 어떤 기능을 구현함에 있어서 이 기능이 다른 누군가에 의해 재사용 될 것이라는 것을 가정하지 않고 작업을 한다. 본인도 본인이 만든 기능을 이후에 다시 사용할 수 없을 지도 모른다고 생각하면서 작업하는데 재사용에 신경 쓸 겨를이 있겠는가.
- 재사용을 신경쓰지 않으니 작업하는 스코프가 특정한 프로젝트, 혹은 특정한 상황으로 제한된다. 일반적인 상황에 대한 문제를 푸는 등의 큰 규모의 작업을 하지 않는 경향이 자리잡는 것이다.
- 모두가 재사용을 신경쓰지 않기 때문에 수많은 사람들이 같은 기능을 수없이 다시 구현해서 사용한다(reinventing the wheel). 이는 업계 전반의 발전 속도를 더디게 한다.
물론 이 세상에는 플러그인을 개발하는 컴퓨테이셔널 디자이너들이 존재하고, 이들은 위와 같은 문제로부터 벗어난 사람들일 것이라고 믿는다. 하지만 모든 사람들이 플러그인을 개발하는 것은 아니지 않는가. 위와 같은 문제를 안고 있는 사람들로 인해 업계에 자리잡은 일종의 문화, 혹은 경향이 있을 것이고, 나는 이러한 요소들이 업계의 발전을 저해한다고 이야기하고 싶다. 그러니까, 컴퓨테이셔널 디자이너들이 개발을 겉핥기로만 배우고 본인들도 '개발을 할 수 있다'고 주장하는 것이 개발자들의 세계에서 그간 열심히 발전시켜온 정수들을 업계에 가져와서 적용시키는 데에 방해가 된다는 말이다.
한편으로는 이러한 문제가 있음에도 불구하고 사람들이 불편함을 많이 느끼지 않는 데에는 다음과 같은 이유가 있을 것이라는 생각도 든다.
- 건축에서의 프로젝트들은 보통 확장이 어렵다. 한 곳에서 만든 기능을 그대로 다른 곳으로 들고 가서 쓰기 어렵다는 말이다. 서버가 설치될 기기는 모두 거의 비슷한 규격을 따를 것이라고 기대할 수 있는 것과는 달리 건축이 이루어지는 땅은 모두 다르고, 땅들에 올라가는 건축물의 형태는 모두 다르며, 건축에는 땅과 건물 형태를 일반화하지 않는 것을 통해 가치를 만들어내는 문화가 있다.
- 확장이 어려우니 처음부터 확장을 할 생각을 할 필요가 없을 수도 있다. 그러니까, 처음부터 일회용으로 사용할 기능을 만들고 해당 프로젝트에만 적용한 다음 로그라이크 게임을 하듯이 경험만 얻고 이후에 또 다른 프로젝트를 위한 기능을 새로 구현하는 것이다.