도구, 기술, 철학


TL;DL

  • 새로운 도구는 기존 것의 불편함(비효율)을 개선하는 데서 출발한다.
  • 따라서 우리가 사용하고 있는 많은 도구는 대체될 수 있다.
  • 새로운 도구에 대해 꼼꼼히 익힐 시간이 없다면 철학 부분, 해결하고자 하는 문제를 읽어보자

도구와 기술의 차이

도구

소프트웨어 업계에서 도구라는 단어를 많이 보았다. 개발자 인터뷰, 채용 공고, 성장에 대한 글에서 도구는 이렇게 등장한다.

  • 저는 기술을 풀어야 할 문제를 위해 사용하는 하나의 도구라고 생각합니다.
  • 저희는 A, B, C 등의 도구를 사용해요.
  • (우대 사항) 필요에 따라 도구를 적절히 사용하시는 분!

기술과 도구가 주는 단어의 느낌은 엄연히 다르다. 화자가 구태여 '도구'라는 단어를 선택한 이유가 있다고 생각한다. 기술과 도구의 차이를 정리해보자.

기술은 그 자체로서 의미가 있고, 주체로서 느껴진다. 반면 도구는 목적을 달성하기 위해 사용하는 느낌이 있다. 좀 더 이 느낌적인 느낌을 살펴보자. 집을 짓는 과정을 예로 들면, 도면은 기술이다. 건축가가 집의 용도, 용적, 역학적인 측면을 고려해 건축학적 지식을 바탕으로 설계했다. 도면은 집의 형태가 변하지 않는 이상 건축 과정에서 절대적이다. 못, 망치, 시멘트, 나무 등은 도구다. 도면에 크게 어긋나지 않는 선에서 어떤 톱, 망치, 못 등을 사용할지는 엔지니어의 마음이다.

사실 이 전까지 왜 기술과 도구를 구분해 사용하는지 잘 체감하지 못했다. 아래 두 문장이 내포하는 바는 엄연히 다른데, 그 차이를 크게 의식하지 않았다.

  1. React는 웹 프론트엔드 영역의 신 기술이다.
  1. React는 SPA의 구현을 쉽게 도와주는 하나의 도구다.

연장선에서 IT한 기술을 배우기 위해 프로젝트에 도입하거나 살펴본 적이 있다. 새로운 기술이 나오면 반사적으로 배워야 할 것만 같은 강박에서 비롯되었다고 생각한다. 최근 docker와 nest.js를 사용했다. 이 경험에서 도구와 기술에 대해 생각해보게 되었다. 이번 글에서 느낀점을 공유해보고자 한다. 그 전에 도커와 nest.js를 왜 사용하게 되었는지 소개한다.

Docker

현재 개발자로 첫 회사에 입사하며 처음 했던 일 중 하나는 서버를 로컬 환경에 설치하는 것 이었다. 서버 프레임워크로 파이썬 flask를 사용하고 있어, virtualenv로 프로젝트를 위한 환경에 의존하고 있는 라이브러리를 설치하기 시작했다. 인수인계 문서에 requirements.txt 파일을 포함해 redis, celery, nginx 등 설치할 수 있는 명령어가 나와있어 크게 어렵진 않았다. (시간이 오래 걸리지 않았다는 것은 아니다.)

새로운 개발 서버(ubuntu)가 필요했을 때에도 크게 다르지 않았다. 이 때 instance를 CentOS에서 ubuntu로 변경하고 있었는데, 기존 문서는 CentOS 기반으로 작성되었기에 거기에 더해 약간의 추가적인 어려움이 있었다. (시간이 오래 걸렸다.)

이 무렵, Docker의 존재와 개념을 아예 모르고 있었던 것은 아니다. 'Docker 로 실행하면 하나의 프로세스로 운영체제를 띄울 수 있다'는 말을 어디선가 들었었다. 잘 모르겠지만 버전이나, 환경이 다르면 프로그램이 의도한 대로 작동하지 않기 때문에 이를 관리하는 도구라고 생각했다. 약간 결이 다르지만 npm의 package-lock.json 파이썬의 virtualenv와 비슷하다고 생각했다.

하지만 위에서 언급했던 개발 환경을 설정하는 일의 반복과 비효율에 대해 깊게 고민을 해보지 않았기 때문에 도커가 어떤 문제를 해결하기 위해 만들어졌고, 많은 사람으로부터 관심을 받게 되었는지 공감하지 못했다. 한마디로 불편함을 깊게 생각하지 않아, 낫 놓고 기억자도 몰랐다. 자연스레 회사에서도, 개인 프로젝트에서도 도입을 하지 않았고 매번 AWS의 instance를 새로이 생성할 때면 과정을 되풀이 해야 했다.

nest.js

회사에서 파이썬 flask를 사용하고 있고, express를 사용해 사이드 프로젝트에 필요한 서버를 몇차례 구축했다. 사실 express, flask를 사용하며 불편한 점은 크게 느끼지 못했다. express로 처음 서버를 접했고 아리송 했던 폴더 구조는 공식문서 혹은 'express best practice' 검색결과 상단에 나오는 블로그를 참고했다. 최근, 면접 과제로 회원 인증이 포함된 메모 API를 구현해야 했는데, 기술 조건이 nest.js + sequelize을 사용해야 했다. 낯선 개념들 사이에서 nest.js가 제안하는 아키텍쳐가 눈에 들어왔다. 그리고 nest.js가 해결하고 싶은 문제를 어렴풋이 짐작할 수 있었다.

Philosophy

그렇게 nest.js 문서를 읽어보기 시작했다. 아래는 공식문서의 첫 장, Introduction에 나오는 문장이다.

However, while plenty of superb libraries, helpers, and tools exist for Node (and server-side JavaScript), none of them effectively solve the main problem of - Architecture.

구글 개발자 Kamil Mysliwiec 그간 노드 서버 프레임워크 생태계에서 구조에 대한 결핍을 느끼고 있었고, 이를 해결하고자 nest.js를 만들었다.

이어서 도커 공식문서를 살펴보았다. 마찬가지로 Documentation의 첫 페이지, What is a Conatiner 에 도커의 철학이 짧게 명시되어 있었다.

A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.

도커는 새로운 서버를 만들때 빠르고 신뢰할 수 있게 어플리케이션의 의존성과 코드를 묶어준다.

새로운 소프트웨어는 기존 기술을 대체한다. 다만 무에서 유를 창조하는 경우보다, 기존 기술(도구)의 불편함과 비효율성을 개선하는 방향으로 발전한다. 기술 문서에 철학은 어떤 문제를 해결하기 위해 만들어 졌는지를 명시하고 있다.

도구와 기술

다시 도구와 기술, 두 단어의 차이점으로 돌아와보자. 아직도 기술과 도구의 차이점이 명쾌하지 않다면 필자의 설명이 부족했다고 생각한다. 한번 더 정리하자면, 우리는 일상생활의 문제를 해결하기 위해 소프트웨어를 개발한다. 우리의 문제를 해결해주는 완성된 프로그램을 '기술'이라고 생각한다. 프로그램은 언어, 프레임워크, 라이브러리 등으로 구성되어 있다. 그리고 이 '도구' 들은 기존 도구의 불편함과 비효율성을 바탕으로 발전하고, 대체된다.

따라서 우리가 가장 관심을 가지고 고민해야 할 문제는 해결하고자 하는 문제 그 자체다. 어떤 도구를 사용해 해결해야 할 지는 그 다음이다. 다만 아이러니하게도 훌륭한 도구는 생산성에 많은 도움을 주고, 우리가 문제 그 자체에 더 집중할 수 있게 도와준다.

반복의 느린 變化
oowgnoj github
© 2022, by oowgnoj