반나절이면 될 줄 알았습니다

예뻐야 돼. 뭐든지 예뻐야 좋아.

그렇습니다. 요즘 저는 코덱스를 주로 씁니다. 여러 가지 이유가 있지만, 어쩌다 보니 그렇게 되었습니다.

귀는 또 얇아서 온갖 오픈소스와 데스크탑 앱을 다 주워섬겨 봤지만, 결국 실제 빌드에 가장 많이 쓰게 되는 건 코덱스였습니다.

그러다 보면 자연스럽게 한 가지 생각을 하게 됩니다.

매일 보는 건데, 화면도 기왕이면 제 취향이었으면 더 좋겠습니다.

마침 코덱스는 오픈소스로 코드도 공개되어 있습니다. 세상에나. 이것은 커스텀을 하라는 계시나 다름없었습니다.

그럼 제 취향대로 메뉴 몇 개 바꾸고, 버튼 몇 개 손보고, 좋아하는 색 정도만 입히면 되겠네.

간단한 거니까 한 반나절이면 코덱스가 해결해 주겠지?

이게 이 모든 것의 시작이었습니다.

용기는 때론 무모함, 아니 무식함에서 나오는 법입니다.

처음엔 오픈소스를 뒤지기 시작했습니다. 분명 저처럼 코덱스 디자인을 바꾸고 싶은 선구자들이 존재했을 것입니다.

당연히 존재했고, 저는 선구자님들을 따라 커스텀을 시작했습니다.

문제가 있었습니다.

제가 좋아하는 색으로 바꿨는데, 결과물이 썩 마음에 들지 않았습니다.

아, 색 정도 고치는 걸로는 안 되나.

그럼 조금만 더 손대지 뭐.

그러나 곧 수많은 질문 세례에 부딪히기 시작했습니다.

이건 왜 왼쪽에 있는 거지?

다른 세션들 거슬리는데.

왜 에이전트가 읽은 파일과 검색한 내용이 채팅에 끼어 있지?

저는 에이전트의 긴 글이 좋은데, 이건 왜 부차적인 인터페이스처럼 취급되는 거지?

결국 이 질문들은 하나의 큰 질문으로 수렴했습니다.

난 대체 뭘 보고 싶은 거지?

이때부터 개미지옥이 시작되었습니다.

처음에는 그냥 코덱스에 스킨 정도 씌우고 싶었을 뿐이었습니다.

그런데 어쩌다 보니 이건

제가 모델과 일할 때 어떤 작업 공간을 원하는지에 대한 설계에 더 가까워지고 있었습니다.

그래서 그 과정에 대한 기록을 남기려고 합니다.

뭐가 거슬렸고,

그게 왜 거슬렸고,

그래서 뭘 또 바꿔 봤는데,

그러니까 다른 게 또 거슬리기 시작한,

눈만 더럽게 높고 손과 머리는 따라오지 않는

안타까운 사람이 남긴 기록입니다.

여전히 만드는 중이며,

언제 끝날지는 모르겠습니다.

제 기준 거의 사그라다 파밀리아 급입니다.

이 과정을 통해 한 가지는 공감하게 되었습니다.

가우디가 왜 건축가가 되었는지 알 것 같았습니다.

그런 건물은 자기 자신이 아니면 그 누구도 디자인하지 않을 거라서요.

당연히 이 결과물이 그렇다는 건 아니고,

저 또한 제가 아니면 아무도 이런 걸 만들 것 같지 않아서 만들게 되었습니다.

오픈소스는 축복입니다.

왜냐하면 보통 오픈소스를 하시는 분들은 엄청난 능력을 가지고 세상에 기여를 하시는 분들이라, 대부분은 그분들이 만든 것을 흡수하면 됩니다.

문제는 여기에 있었습니다.

제 취향이 대세와 정반대라는 것입니다.

멀티 에이전트, 루프 엔지니어링, 자동화 등등….

1인 취미 빌더인 저에겐 솔직히 그런 걸 할 만한 엄청난 태스크가 없습니다.

전부 오버엔지니어링일 뿐이고, 매달 나가는 디지털 월세도 빠듯한 판입니다.

저는 모델을 주로 학습에 사용하고 있기 때문에, 저에게 중요한 것은 정돈된 하나의 세션과 그 세션에서 포크된 여러 아이디어였습니다.

그리고 모델이 어떻게 사고를 헤쳐 나가는지에 대한 흔적을 보고 싶었습니다. 저의 사고 스파링 상대로서 모델과 공유하는 공간이 필요했습니다.

그런 저에게 현재 대세인 멀티턴이나 모델 라우팅에 최적화된 인터페이스는 당연히 몸에 맞지 않는 옷일 수밖에 없었습니다.

가장 거슬렸던 건 작업하는 동안 너무 많은 것이 눈에 들어온다는 점이었습니다.

저는 이 세션의 주제에 집중하고 싶은데, 왼쪽에는 다른 작업들이 있습니다. 메뉴가 있고, 히스토리가 있고, 계속 존재합니다.

물론 필요한 기능이긴 합니다. 그런데 제가 원하는 기능인가? 그건 좀 의문이었습니다.

왼쪽이 너무 아까웠습니다.

화면을 볼 때 왼쪽은 가장 중요한 곳입니다. 그래서 대부분의 프로그램은 거기에 중요한 메뉴를 둡니다.

파일 탐색기, 대화 목록, 멀티에이전트 세션 등….

하지만 저는 그 자리를 제가 지금 작업하고 있는 것에 쓰고 싶었습니다.

그래서 처음으로 든 생각은 아주 심플했습니다.

채팅을 왼쪽으로 보내자.

에이전트와 대화할 때 제가 가장 많이 보고, 가장 많이 사용하는 곳이 대화창이기 때문입니다.

채팅은 보조가 아니라 저에게 있어서는 가장 메인 인스턴스였습니다.

특히 저는 모델의 말이 길수록 좋습니다. 이유는 단순합니다. 활자 중독이라 그렇습니다. 그냥 글자 읽는 게 좋습니다.

다른 작업들은 안 보였음 합니다.

그거 아니어도 제 주의력은 이미 머릿속의 다른 프로젝트들로 차 있습니다. 물론 접을 수 있다고 하지만, 다른 세션이 눈에 어른거리면 결국 참을 수 없게 됩니다.

억지로라도 이 세션에서 해결하고 싶은 문제 하나만 보고 싶었습니다.

점점 제가 원하는 화면의 문법이 드러나기 시작했습니다.

확실한 점 하나는, 일반적인 IDE의 메인 화면은 아니었다는 것입니다.

채팅을 크게 만든 건 시작에 불과했습니다.

채팅을 메인으로 올리니 다른 문제가 보이기 시작했습니다.

에이전트의 작업 과정에는 굉장히 많은 정보가 나옵니다.

파일을 읽기도 하고, 스킬을 쓰기도 하고, 검색도 하고, 코드를 수정하기도 합니다.

기존 인터페이스에서는 이런 일들이 대체로 대화 흐름 속에 시간순으로 쌓입니다.

처음엔 그게 자연스럽다고 생각했습니다. 대화는 시간순이고, 그에 맞춰 에이전트의 행동이 나열되는 거니까요.

그런데 실제로 제가 확인하는 것은 조금 달랐습니다.

제가 하는 행동은 일부러 코덱스 창이 접어 놓은 에이전트의 행동을 펼쳐서,

무슨 파일을 읽는지 따라가서 읽고, 뭘 검색하는지 관찰하는 일이었습니다.

엥? 그러면 그걸 불편하게 일일이 펴서 읽지 말고, 그냥 펼쳐놓으면 안 되나?

제가 이걸 보는 이유는, 뭐 에이전트가 이상한 파일을 보고 있으면 다시 입력을 수정해서 새 세션을 돌리는 데 쓰이기도 하지만,

기본적으로는 그냥 얘가 뭘 하는지 궁금해서입니다.

그냥, 신기하잖아요.

즉 저에게 필요한 정보는 에이전트의 현재 상태였습니다.

그러면 시간순 기록과 현재 상태는 서로 다른 정보라는 생각에 다다랐습니다.

그래서 처음에는 아주 단순하게, 에이전트가 지금 하고 있는 일을 채팅에서 빼서 별도의 창으로 만들자고 생각했습니다.

생각해보면 저는 에이전트에게 보고를 받기보다,

에이전트가 이 문제를 어떻게 헤매고 있지? 하고 같이 헤맬 수 있는 공간을 원했던 것 같습니다.

물론 저걸 처음 생각했을 땐 당연히 거기까지 생각이 닿진 않았습니다.

그냥 뭔가 마음에 안 들었고,

이건가? 하고 무식하게 하나씩 옮겨보고 있었을 뿐입니다.

제가 원하는 구조를 어렴풋하게 잡았습니다.

좋습니다. 그래서 그게 어떻게 생겼는데?

다행히 이 부분에서는 한 가지 확실한 지향점이 있었습니다.

물론 그것이 문제를 쉽게 만들었다는 뜻은 아닙니다. 오히려 더 복잡하게 만들었습니다.

일반적인 SaaS 대시보드나 IDE는 싫다.

이것이 대원칙이었습니다.

문제는 대부분의 IDE나 대시보드가 그렇게 디자인된 데에는 일종의 수렴진화 같은 어떤 원칙이 있다는 점입니다.

불행히도 저는 이제부터 저 명제와 끊임없이 싸우게 됩니다.

하지만 아직까지는 나만의 코덱스를 만든다는 데 설레서 그딴 깊은 생각은 하지 못하고 있습니다.

그냥 마냥 즐거운 모양입니다.

그럼 don't를 정했으니, 무엇을 추구할지를 정해볼까.

뭔가 제 개인적인 작업 공간 같았음 좋겠고, 정리하고 생각하며 계속 만지고 싶어지고, 뭔가 영감이 샘솟고….

그러다가 잡은 키워드가 다이어리와 저널 같은 거였습니다.

생각해보니 이건 저와 모델이 같이 쓰는 작업 기록 아닌가?

그럼 차라리 저널이라고 생각해 보는 건 어떨까.

그때부터 실제 다이어리와 노트들을 찾아보기 시작했습니다.

호보니치, 미도리 노트, 트래블러스 노트, 여러 저널과 플래너.

그리고 코덱스의 제안에 따라 큐시트나 운행표도 참고했습니다.

이걸 통해 서로 다른 정보를 어떻게 자연스럽게 공존시킬 수 있는지에 대한 단서를 찾고 싶었습니다.

필연적으로 이 화면은 많은 정보를 담을 수밖에 없습니다.

그리고 그 많은 정보를 담는 데 최적화된 IDE의 문법을 탈피하려면, 다른 영역의 레퍼런스를 찾는 수밖에 없었습니다.

호보니치에서는 쪼개져 있는 작은 정보들을 질서정연하게 담는 방식을,

트래블 저널에서는 사진, 메모, 일정 같은 비정형 정보들을 함께 배치하는 방식을,

큐시트에서는 시간에 따라 흘러가는 상태 같은 동적인 정보를 담는 방식을 참고했습니다.

이 과정을 거치면서 모델의 작업 과정을 따로 빼야겠다는 아이디어도 점점 구체화되기 시작했습니다.

아, 그리고 여기에 굿노트 같은 디지털 다이어리의 느낌도 씌우고 싶었습니다.

무거운 개발 툴보단, 제 아이디어를 모델과 같이 끄적이는 느낌으로요.

특히 굿노트 다이어리를 보면 여러 도구나 섹션을 인덱스나 탭처럼 붙여 놓는 경우가 많았습니다.

이 점이 마음에 들었습니다.

제가 구상한 페이지에도 여러 도구가 필연적으로 존재하지만, 그게 주인공일 필요는 없었습니다. 그러면서도 장식적인 요소로 화면을 예쁘게 만들었으면 했습니다.

그래서 각종 메뉴와 도구들은 다이어리의 인덱스처럼 화면 바깥에 배치하도록 했습니다.

이 과정을 거친 뒤에야 제가 만들고자 하는 것의 모양이 드디어 한 문장으로 정리되기 시작했습니다.

모델과 제가 함께 쓰는, 작업 저널.

저는 머릿속으로만 생각해서는 다음 단계로 못 넘어가는 문제를 가지고 있습니다.

눈앞에 존재한 뒤에야 그걸 보고 좋은데? 별론데?를 판단할 수 있습니다.

그리고 제가 설계한 이게 말이 되는지도 궁금했습니다.

그래서 제가 생각한 키워드와 구조를 가지고 이미지를 뽑아보기 시작했습니다.

여러 레퍼런스를 섞어가며 계속 이미지를 만들었습니다.

계속 뽑다 보니 도파민이 터졌습니다.

그래, 바로 이거야.

점점 제가 바라는 이미지가 나오기 시작했습니다.

맞습니다. 나오기 시작했다는 것입니다. 나왔다는 것이 아닙니다.

그럼 언제 나올까?

그런 일은 일어날 수가 없습니다.

전체가 마음에 드는 이미지는 없었습니다.

이건 전체적으로 예쁜데 구조가 별로고, 이건 헤더 디자인은 마음에 드는데 본문이 별로고, 이거는 대체 왜 존재하는지 모르는 그리드가 있고.

이러다 끝이 안 날 것 같았습니다.

프롬프트의 문제는 아니었습니다.

모델이 그려준 예쁜 목업 화면의 문제는 단 하나였습니다.

그럴싸합니다.

그뿐입니다.

버튼도 적당합니다. 탭도 있습니다. 제가 바라는 대로 패널도 있습니다. 그림만 보면 이대로 구현하면 될 것 같은 제품으로 보입니다.

하지만 하나씩 들여다보기 시작하면, 그럴싸한 화면이 답해주는 것은 없습니다.

이 메뉴는 무슨 의미지?

이걸 클릭하면 뭐가 나오는데?

이 버튼은 뭐지?

이건 왜 필요하고?

그렇습니다.

많은 요소들이 인터페이스라면 이런 게 응당 있어야지 하는 평균적인 값으로 들어차 있습니다.

왜?라고 물으면 그냥 평균이 그래서.가 답입니다.

그리고 평균대로 갈 거라면 기존의 IDE를 쓰러 가면 됩니다.

그럼 이 목업 작업이 무의미했냐고 하면 아닙니다.

오히려 더 재미있어졌습니다.

모델이 결과물을 던져주면 저는 그걸 보고

오, 이건 좋음.

여기 이건 절대 안 됨.

이런 건 왜 있는지 모르겠는데.

같은 판단을 하기 시작했습니다.

만일 처음부터 빈 캔버스에서 시작했다면, 저는 아마 아무것도 못했을 것 같습니다.

그런데 일단 그럴싸한 무언가가 눈앞에 있으니까, 저는 싫어싫어를 외치면서 제가 뭘 원하는지 조금씩 알아갈 수 있었습니다.

즉, 제가 문제 공간을 설정하고,

모델이 그걸 기준으로 탐색 공간을 다시 넓히고,

저는 거기서 싫은 것과 좋은 것, 그리고 그게 왜 그런지 설명하면서 다시 문제 공간을 좁힙니다.

그러면 새로 설정된 공간에서 모델은 또 다른 방향으로 결과를 내놓습니다.

이 과정에서 모델과 티키타카를 하며 문제의 방향을 점점 세밀하게 깎아갔던 것 같습니다.

보통은 유저가 초반 설계를 잘해야 한다고 하지만,

이 작업에서는 모델의 출력도 제 문제 공간을 깎는 데 쓰였습니다.

뭐, 그렇게 티키타카가 있었다는 뜻입니다.

이런 목업 작업도 한계가 왔습니다.

마음에 드는 부분은 이미 많이 생겼습니다.

그리고 절대로 저건 아니다 싶은 금지 사항도 많이 생겼습니다.

근데 그걸 한 화면에 합칠 수는 없었습니다.

합쳐달라고 하면 마음에 드는 부분까지 다시 변했습니다.

당연한 일이었습니다.

이쯤 되면 원하는 게 정확하게 있는 사람이 피그마를 켜는 게 빨랐습니다.

문제는 제가 피그마를 거의 다룰 줄 모른다는 사실뿐이었습니다.

단지 머릿속에

모델이 뽑아준 목업을 어떻게 키메라처럼 이어 붙일지에 대한 설계와,

예쁜 코덱스라는 열망만 있는 상태였습니다.

그래서 일단 그리기 시작했습니다.

컴퓨터 유즈는 신이야.

코덱스의 컴퓨터 유즈는 이런 저에게 과외 선생님이 되어주었습니다.

사실 그냥 스크린샷 찍기 귀찮고 그런 것도 있긴 했지만,

저는 제가 원하는 게 정확히 있는 상황이었기 때문에

이걸 그리려면 피그마에서 무엇을 딸깍 해야 하는지 코덱스에게 알려달라고 했습니다.

컴퓨터 유즈는 여기서 진짜 왕초보의 학습 곡선을 엄청나게 단축시켜주었습니다.

이런 복잡한 툴을 배울 때 초보가 가장 막히는 부분은 바로

시키는 대로 했는데 안 됨.

입니다.

분명히 강의나 책에서 시키는 대로 했는데, 제 화면은 뭔가 이상합니다.

이런 경우 99퍼센트는 사용자의 과실입니다.

문제는 초보는 자신이 무슨 과실을 저질렀는지조차 모른다는 것입니다.

그래서 뭘 고쳐야 하는지 몰라 이 단계에서 시간을 엄청 허비하고, 포기하기 일쑤입니다.

이때 컴퓨터 유즈로 코덱스한테

화면 보고 제가 뭘 잘못했는지 알려주세요.

라고 읍소하면

ㅋ 여기 오토레이아웃이 안 되어 있음.

하고 알려줍니다.

이게 진짜 엄청납니다.

거기서부터 저는 그런 메뉴나 단추가 있는지조차 몰랐는데, 일단 그 존재를 알게 됩니다.

그리고 모델에게 엥 그게 뭔데, 왜 이 프레임이 안 움직이게 되는 것이냐고 꼬치꼬치 물어볼 수 있습니다.

벡터처럼 직접 조작하기 힘든 부분은 진짜 코덱스 컴퓨터 유즈의 도움을 많이 받았습니다.

그래서 금방 그렸느냐.

그럴 리가 없습니다.

오히려 그리기 시작하니 새로운 산이 보이기 시작했습니다.

처음에는

아, 그거 마음에 드는 이미지 깔고 트레이싱하면 금방 나오는 거 아니냐?

겸사겸사 피그마 툴도 좀 공부하고. 쫌만 하면 되겠지.

였습니다.

문제는 피그마 조작법 따위가 아니었습니다.

버튼 하나를 그립니다.

그러면,

이 버튼이 그냥 있을 때, 눌렀을 때, 활성화되었을 때를 생각하다가 결과적으로 존재론에 대해 고민하게 됩니다.

이게 왜 있어야 하지?

진짜 있어야만 하나?

크기를 정할 때도 마찬가지였습니다.

이게 그렇게 그만큼 중요해?

오토레이아웃이 처음엔 원망스러웠지만, 익숙해지고 나니

왜 얘들이 한 그룹인데?

이것에 대답할 수 있어야 했습니다.

이미지에서는 그냥 예쁜데? 그냥 들어가면 안 됨? 하고 넘어갈 수 있었던 것들이

제 손으로 직접 배치하기 시작하니 전부 질문이 되어 부메랑처럼 날아오기 시작했습니다.

그리고 여기서부터 또 배움이 시작되었습니다.

피그마는 단순히 목업을 그리는 벡터 툴, 코드 붙어 있는 포토샵 같은 게 아니었습니다.

적어도 지금의 저에게는,

제가 왜 이 화면을 이렇게 만들고 싶은지 설명하게 만드는 도구에 가까웠습니다.

그리고 이 과정에서

왜 디자인 시스템이라는 것이 필요한지 느끼기 시작했습니다.

하지만 그건 그다음의 이야기입니다.