🧑🏼‍🔬 더 “자잘한 것”을 신경쓰지 않게 돕는 도구에 대해

oop, gui ide, fp, llm...

llm 시대엔 정말 소프트웨어 개발의 복잡도가 낮아졌을까?

oop시대엔 개발의 복잡도가 많이 낮아졌던가? gui시대엔? ide의 발전엔?

…모두 별로 그렇지 않았었다. 물론 개선된 부분들이 있었지만, 어떤 부분에서는 오히려 새롭게 변화한 패러다임으로 인해서 더 늘어났던 부분이 분명히 존재했다.

llm의 시대에도 마찬가지 같다. 처음 시도를 하기 가능해 보이는건 실은 과거 vb6 정도의 gui/ide 시대에도 마찬가지였다.

제대로 인공지능을 활용하기 위한 SKILLS.md 등은 결국 과거에도 자기가 뭘 하는지, 뭘 어떻게 해야 하는지, 그리고 그걸 어떻게 문서화하고 정리할 수 있는 능력이 여전히 필요하다는걸 시사한다.

어째서 더 직관적이고, 목적을 이루기 쉬워진 언어/프레임웍을 쓰는 제품이 더 완성도가 떨어질까?

어째서, 더 현대적인 프로그래밍언어, 프레임웍으로 만든 앱이 더 흔하게 완성도가 떨어지고, 그에 비해 구닥다리, 혹은 더 “자잘한 세부사항”을 신경써야 하는 언어나 프레임웍으로 만든 애플리케이션이 항상 더 빠르고 안정적이고 심지어 더 강력한가.

분명히, 전자의 언어/프레임웍은 훨씬 더 “높은 수준의 추상화”를 제공하고, 수많은 편의기능을 제공하고, 그런 특징으로 “몰라도 될 자잘한 사항들을 감춰주는 것” 같은데 말이다.

하지만 두 가지 잘못 판단하는 것이 있다. 바로 어떤 능력수준의 사람이 그걸 사용하는가에 대한 생각과, 또 하나는 정말 추상화가 모든걸 신경쓰지 않게 돕는가에 대한 생각이다.

전자를 사용하는 사람은, 알아서 자신이 “정말 중요한 것”이라고 생각하는 일에만 집중할 수 있어야 한다고 믿는다. 맞는 생각이다. 하지만 어느 정도는 경계해야 하는 생각이다.

자신이 하려는 일, 목적을 완수하는 것 자체에 집중할 수 있는 도구는 중요하다. 하지만 함정이 있다. 그렇게 해주리라고 기대하고 믿는 도구가 실은 그렇게 해주는 것에 정말로 충실하기 보다는, 오히려 사람들이 그렇게 믿도록 만드는데에 더 열중한 도구라는 점이다.

그리고 인정하고 싶어하지 않는 진실도 있다. 그런 믿음에 기대고 싶어하는, 그게 검증되었건 아니건, 이들은 더 깊은 내용, 더 소프트웨어 개발에 대한 진지한 내용을 이해하려 하거나 시도도 하지 않았던 이들이란 점이다.

결국 아무리 손쉬운 도구라고 하더라도 그걸 사용하는 사람의 역량의 차이를 고려해 본다면, 결국 자기가 뭘 하고 있고, 그 일이 어떻게 구현되고 하는지를 잘 이해하는 사람이 항상 더 나을 수 밖엔 없다.

반면, 후자의 언어/프레임웍 같이 “자잘한 세부사항”에 대해서 이해하는것은 실제로 도움이 되기도 하고, 그런 이해하기 위한 노력을 들였던 사람의 그런 성향, 이해력, 학습능력이 더 나은 것이다. 야속한 이야기지만 사실이다.

그리고 조금 깊이 전자의 편리하고 현대적인 언어들/프레임웍들을 쓰다보면, 완벽히 그들이 제공하는 ‘샌드박스(sandbox)’ 안에서 영원히 편안하기는 어렵다. 그 외부, 즉 시스템이 어떻게 동작하는지 제대로 이해하는것이 훨씬 더 도움이 된다.

예전에 인터넷에서 본 어떤 댓글이 이런 생각을 절묘하게 표현한것 같다:

“…좋은 웹개발자를 구하고 있다면, 타입스크립트, 리액트, 일렉트론을 잘 안다는 사람보다는, 차라리 HTML/CSS/JS의 fundamentals을 잘 이해하고 있고 XYZ에 대해서도 잘 이해하고 있는 사람을 구해라. 어차피 그걸 이해하고 있는 사람이라면, 그렇지 않은 <웹개발자>들보다 나은 웹개발자가 된다”1

그린스펀의 10번째 규칙, 그리고 리습의 저주

이제 대부분의 언어들이 사실상 어느 정도의 리습이 되었다고 생각한다. 그리고 그런 이유로 다른 언어들도 리습의 저주-를 받게 되었다고 생각하는게 맞을거 같다.

모든 “자잘한 기술적인 문제”들을 위대한 리습이 해결해줬으므로, 우리는 “중요한 일들”에만 집중하면 된다고 착각하기 시작하는것 말이다.

그런데 때로는 그냥 멍청해 보이는 일들을 해버리는게 더 나은거 같다. 예를 들어, 그린스펀의 열번째 규칙대로, 어느 정도 성공적인, 오랬동안 관리되어온 오픈소스 프로젝트들의 코드베이스는 각자의 방식으로 문자열, 리스트, 해시맵, 혹은 메모리관리 등을 해결해 나간다. 언어와 그 언어의 내장라이브러리, 혹은 커뮤니티 표준적인 라이브러리가 어떻게 제공되는가에 따라 편차는 있지만.

그린스펀의 이 규칙이 제안하는 바를 예전에는 ‘그러니 커먼리습을 써라’라고 생각했었다. 그러나 이제는 반대로 생각한다. 그러니 그냥 ‘○○○으로 너 쓰고 싶은대로 잘 써라’–라고. 그리고 그게 멍청해 보이고, 비효율적으로 보이더라도, 그게 더 낫다. 그리고 preprocessor이나 텍스트매크로 등으로 충분히 리습의 장점을 상회하고도 너 나을 수 있는거 같다.

경계해야 할 생각과 말들

이렇게 생각해보면, 도구나 표현방식이 더 수월해진거 같다고, 완전히 태도가 변해야 한다거나, 이제는 어떠어떠한 식으로만 해야 한다는게 오히려 독이 되는 생각이지 않을까 싶다.

Footnotes


1

그 “XYZ”이 뭔지는 언급하지 않겠다. 🙃