소프트웨어 설계의 단순화 가능성

저는 엔지니어 관점에서 가장 충격 받은 사건은 일론머스크의 스페이스 엑스에서 만든 랩터 엔진입니다.

그 중 랩터3 엔진을 보면서, 기존 랩터 1엔진에 비해서 엄청나게 단순화된 파이프라인과 단순화된 엔지니어링 뿐만 아니라, 가격, 추력, 무게 3가지를 모두 가진 엄청난 장점의 엔진을 개발했다 라는 것 자체가 저에게는 신선한 충격이었습니다.

불가능의 영역을 가능의 영역으로 끌어올렸다고 저는 생각했습니다.

물론 엔진은 단순화 하고, 로켓 내부의 복잡성을 늘렸을수도 있습니다.

저도 내부자가 아닌지라 자세한 사정은 모르지만, 아무튼 중요한건 어떤 식으로 단순화를 했느냐, 그리고 불가능의 영역을 가능의 영역으로 끌고 온것 자체를 의미합니다.

그렇다면 소프트웨어는?

비공개 프로젝트로 제가 많이 진행해서, 사실 GitHub 활동이 뜸해보이지만, 사실 저는 GitHub은 잘 안쓰고, 내부 GitLab을 제 서버에 설치해서 사용중입니다.

실제 작년부터 해서 커밋 자체는 꾸준히 진행하고 있었습니다.

개인 메모앱(이에 대한 내용은 블로그에 작성 예정), 차량 정비 SasS(사업 서포트) 등등 개발을 진행하면서, 클로드 코드와 많은 대화를 하면서 토큰도 많이 써가면서 진행했습니다. 이젠 MAX없이는 못살ㅇ..

ai를 써가면서 느끼는점은 토큰을 태울 수록, 그리고 내가 만들려고 하는 시스템의 복잡도가 늘어날 수록 나의 통제력이 약해진다 입니다.

통제력을 어떻게 올릴 것인가

사실 ai를 지속적으로 사용하다보면서, 드는 생각은 결국은 ai와 같이 협업을 하면서 일을 하다보면, 내가 ai를 제대로 통제하려고 한다면, 즉, 프로젝트가 원할히 되게 하려고 노력했던 결과를 찾아보면, 뭐 보통 하네스? 라고 하는 것 같은데

그 하네스를 점차 우리가 흔히 대기업의 업무 프로세스 라고 하는 그 실제 업무 보고 프로세스, 결재 프로세스 처럼 변질 되고있는 모습을 목격했고, 실제 그런 형태로 쓰고 있습니다.

예를 들자면, 마음 급한 ai는 설계를 조금이라도 한다면, 바로 개발할까요? 라고 물어보고 아무 생각이 없는 사람들은 바로 개발에 착수합니다.

하지만, 우리가 실제 일할때는 조그만 설계를 진행한다고 바로 개발에 들어가진 않습니다.
그래서 이걸 왜 설계 했고, 최종 목적은 뭐고 등등의 보고서를 올립니다.
즉, 보고서가 기안이 통과 되고, 실제 개발까지 여정, 과정, 목적 등등이 모두 경영진 혹은 결정권자가 이해한다면, 개발 승인 이후 개발에 들어가죠

그 이후에도 어떤 기술을 쓸거고 라는 과정이 진행됩니다.

결국 저도 그러한 형태로 보고 하고 개발하고, 목적을 잃어버리는 행위를 하면 다시 바로잡고 하는 행동을 하고 반복되는 실수는 하네스로 바로 잡고 하는 과정을 겪으면서, 점점 회사처럼 승인 절차, 확정 절차를 거치게 되어가고 있었습니다.

AI의 역설

실제 조직은 붕괴되고 있습니다. ai가 나오고 나서 부터는 속도가 빠르게 가속화 됐고, 실제 그 속도는 경영진과 결정권자들의 결정 속도를 추월하기 시작했습니다.

그리고 투자자들도 빠른 결정을 요구합니다.

그리고 고급 개발자 한 사람에게 ai를 붙이는 것이 주니어를 키우는 기회 비용 보다 쌉니다.

그래서 실제로 조직은 축소 되고, 쪼그라듭니다, 방향성은 더욱 잡기 힘들어졌습니다.

그러나, 역설적으로 우리는 AI에게는 방향성을 잡아줘야하고, 프로세서 절차를 알려줘야하고, 이관해야하고 그래야지 일이 진행됩니다.

어쩌면 우리는 이미 우리의 자원을 AI에게 빼앗기고 있는지 모릅니다.

우리가 일하는 방식을 말입니다.

결론

결국 소프트웨어도 복잡성이 올라갈수록 단순화된 아키텍처 혹은 구성이 없을지는 탐구해보려고 합니다. 결국은 내가 현재 ai가 작업하고 있는 프로젝트의 통제력을 높이기 위해서는 복잡성을 늘리는 방향이 아닌, 단순하게 만드는 작업이 되어야한다고 생각이 듭니다.

이에 대한 결론과 과정에 대해서도 블로그로 꾸준히 기록해보겠습니다.