필요한 사람들의 세상 - omocon 후기

이전 잡생각인 <너만의 월남쌈을 싸> 와 맥락적으로 이어지는 부분이 있지만, 꼭 가서 볼 필요는 없습니다.

나는 10년이라는 시간 동안 장편과 단편 소설을 썼다. 하지만 5년 전 어느 순간부터 더 이상 써야 할 이야기가 남지 않았다는 느낌을 받았고, 그 이후로는 단 한 번도 완성된 형태의 이야기를 끝까지 써내지 못했다. 한때는 자연스럽게 이어지던 문장들이 중간에서 멈춰 서기 시작했고, 그 멈춤은 단순한 슬럼프라기보다 이미 할 말을 다 해버린 사람에게 찾아오는 고요한 정적에 가까웠다. 그래서 나는 더 이상 쓰지 않게 되었고, 그 사실을 특별히 아쉽게 여기지도 않게 되었다.

AI와 바이브 코딩은 이제 '요즘 이슈'라고 부르기도 민망하다. 아주 많은 것이 바뀌고 있으며 그 여파 속에서 주니어 개발자 취업 시장은 궤멸에 가까운 타격을 입었다. 미들급조차 이전처럼 자연스럽게 이직을 이어가기 어려운 상황이다. 그렇다고 손 놓고 있을 수는 없는 노릇이니 다들 어떻게든 AI-Native 한 개발자가 되기 위해 노력한다. 방법이 정해진 것도 아니고 방향이 정해진 것도 아니다. 하지만 어떤 흐름이 존재한다는 것 만큼은 누구도 부정할 수 없으리라.

지난 주말 서울 강남에서 진행된 omocon에 참석했다. 개인적으로는 에이전트나 하네스 엔지니어링 방법론에 대한 보다 깊이 있는 논의가 오가기를 기대했지만, 발표 세션들은 대체로 연사들이 만들어낸 결과물과 사례를 소개하는 데에 머물러 있었고, 그 이면의 설계 과정이나 선택의 기준, 실패와 수정의 맥락까지는 충분히 드러나지 않은 듯하여 조금 아쉽게 느껴졌다.

그렇지만 그 자리에서 나는 조금 다른 종류의 깨달음을 얻을 수 있었다. 개발 면접에서는 종종 ‘스스로 문제를 정의하고 해결하는 능력’에 대한 이야기를 나누게 되는데, 나는 여태껏 그 말을 "단순히 주어진 과제를 잘 풀어내는 수준을 넘어, 무엇을 문제로 볼 것인지부터 스스로 결정하는 태도"에 대한 것이라 생각했었다. 그런데 연사자들의 발표와 그들이 만들어낸 것들을 보면서 생각이 바뀌게 되었다.

리액트의 전역 상태 관리 도구 중에 Zustand 라는 것이 있다. 나는 Zustand를 쓸 때마다 그에 대응되는 타입을 직접 정의해야 한다는 점이 불편했고, 여러 미들웨어를 조합해 사용할 수록 코드가 빠르게 지저분해진다는 점이 마음에 들지 않았다.

나는 이를 해결해야 한다는 '필요'를 느껴서 @ilokesto/state를 만들었고, 회사에서 같은 문제로 고통받는 동료와 함께 zustand-middleware-pipe를 만들었다. 불편하고 문제라는 사실을 인지하는 것과, 그것을 반드시 해결해야 할 ‘필요’로 받아들이는 것은 전혀 다른 차원의 이야기이며, 만약 그 필요를 느끼지 못했다면 이런 라이브러리는 애초에 만들어지지도 않았을 것이다. 결국 무언가를 만든다는 것은 단순한 기술적 역량의 문제가 아니라, 문제를 문제로 받아들이는 감각과 그것을 더 이상 방치할 수 없다는 상태까지 밀어붙이는 태도에서 비롯된다는 생각이 들었다.

소설을 쓰던 당시 내가 자주 듣던 말이 하나 있다. “ayden 님의 소설은 문장이 너무 좋아요”라는 말이었다. 나는 김훈의 문장에 많은 영향을 받았고, 그래서 문장력을 기르는 데 상당한 시간을 쏟았다. 그 결과 문장은 분명히 정교해졌지만, 정작 “소설이 너무 재미있다”는 피드백은 거의 받아본 적이 없었다. 몇몇 단편에서만 드물게 좋은 반응을 얻었을 뿐인데, 돌이켜보면 나는 이야기를 전달하는 것보다 문장을 다듬는 일에 더 집착했던 것 같다.

개발자 중에서는 코드 퀄리티에 집착하는 사람들이 꽤 있다. 나도 한때는 그런 부류의 개발자였다. 물론 코드 퀄리티는 중요하다. 하지만 그보다 더 중요한 게 있다. 그 코드가 해결해야하는 문제는 무엇이고, 어떤 방식으로 그 문제를 해결하고자 하느냐는 것이다. 아무리 정제되고 우아한 코드라 하더라도 해결해야 할 문제와 맞닿아 있지 않다면 그 가치는 제한적일 수밖에 없으며, 결국 좋은 코드는 형태의 완성도가 아니라 문제 해결 과정 속에서의 적합성과 유효성으로 판단되어야 한다.

내가 잘못 알고 있는 것일지도 모르지만, 이 업계에서 문제를 정의하는 일은 주로 기획자의 역할로 여겨져 왔다고 생각한다. 개발자는 그 문제를 전달받아 구현하는 사람에 가까웠고, 무엇을 만들지보다는 어떻게 만들지를 고민하는 데 더 많은 시간을 써왔다. 하지만 지금의 환경에서는 그 경계가 점점 흐려지고 있으며, 오히려 개발자에게도 문제를 발견하고 정의하는 역할이 자연스럽게 요구되고 있다.

그래서 이제는 주어진 요구사항을 정확히 구현하는 것만으로는 충분하지 않고, 아직 이름 붙지 않은 불편이나 가능성을 포착하고 그것을 구체적인 문제로 끌어내는 감각이 더 중요한 역량이 되고 있으며, 그 차이가 앞으로의 개발자를 구분 짓는 기준이 될 것이라는 느낌이 들었다. 그리고 그 시작은 아마도 자기 자신의 불편함을 개선하는 것으로부터 아닐까.

불편함이라는 게 꼭 ─ 앞서 Zustand의 사례에서 언급한 바와 같이 ─ 타이핑을 더 많이 해야 한다는 식의 명확하고 가시적인 문제로만 드러나는 것은 아니다. 때로는 반복되는 흐름 속에서 설명하기 어려운 미묘한 이질감으로 나타나기도 하고, 별다른 문제 없이 동작하고 있음에도 계속해서 손을 대고 싶어지는 감각으로 남기도 한다.

혹은 이런 경우도 있을 수 있다. 나는 레거시 데코레이터에 의존하는 백엔드 프레임워크 Nest.js의 대안이 사실상 부재한 상황이 자바스크립트 커뮤니티 전반에 걸쳐 하나의 구조적인 제약처럼 작용하고 있다고 느꼈다. 당장 불편하다고 말하기는 어렵지만, 언어와 생태계가 나아가는 방향과 어딘가 어긋나 있는 감각이 지속적으로 쌓이고 있었고, 내게는 그것이 반드시 해결해야 할 '필요'가 있다고 느껴졌다. 어디서 공개적으로 말한 적은 없지만, 표준 우선 타입스크립트 백엔드 프레임워크 @fluojs는 그런 이유로 시작되었다.

그 어느 때보다 구현 비용이 저렴해진 시절이다. omocon 현장에서 나는 "이제는 '필요'를 더 잘 느끼는 개발자가 살아남겠구나" 하는 생각을 했다. 예전처럼 구현 자체가 경쟁력이던 시대는 지나가고 있고, 이제는 무엇을 만들어야 하는지를 먼저 감각하는 사람이 앞서 나가는 흐름에 가까워 보인다. 기술은 점점 더 빠르게 평준화되고 있지만, 무엇이 진짜 문제인지, 무엇이 굳이 해결되어야 하는지에 대한 판단은 여전히 개인의 몫으로 남아 있기 때문이다.

그래서 앞으로는 잘 만드는 사람보다, 만들어야 할 것을 정확히 느끼는 사람이 더 중요해질지도 모른다. 바야흐로 필요한 사람들의 세상이고, 그 감각이야말로 쉽게 대체되지 않는 마지막 영역일지도 모르겠다.