본문 바로가기

댓글0
번역beta

Translated by kakao i

번역할 언어 선택

뷰 본문

ㅍㅍㅅㅅ

포토샵은 디자인 툴이 아닌 ‘커뮤니케이션 툴’이다

포토샵 파일은 이야기가 시작되는 지점이고, 참고 대상일 뿐이다.

1,969 읽음
댓글0
번역beta

Translated by kakao i

번역할 언어 선택

※ 리 타일러(Leigh Taylor)의 「Photoshop is not a design tool」을 허가 아래 번역한 글입니다. 타일러는 그라비타 크리에이티브의 디자이너로 미디엄옵비어스 벤처스에서 근무했습니다.


난 그동안 일해오며 포토샵을 빡세게 써왔고, 나 자신, 그리고 동료들에게 보여줄 ‘궁극의’ 디자인 표현을 위해 매일 연습하고 다듬어 왔다. 그 결과 난 자랑스러운 영광의 배지를 달았고, 더 이상 배울 게 없었다. 늘 되고 싶어하던 장인이 된 것이다. 퀄리티에 집중하고 효율적으로 많은 결과를 쏟아냈다. 친구들 사이에선 “포토샵에 문제 생기면 걔한테 물어보면 돼” 하는 수준에 이르렀다.


하지만, 난 결코 결과물에 만족할 수 없었다. 뭔가 덜 완성된 것 같았고, 정적이었으며, 연약했다. 난 이 섬세한 이미지가 팀으로부터의 의문들, 그리고 불확실성과 싸워야 한다는 걸 알았다. 이런 대화를 거친 뒤에야, 얼마간의 타협을 거쳐 실제로 디자인이 구축되기 시작한다.


이런 리뷰들을 받고 나면 난 종종 패배감에 빠지게 된다. 멘탈이 바닥나고 불만이 쌓이고 뭘 어떻게 해야 할지 갈피를 못 잡게 된다. 대체 난 그렇게 많은 시간 동안 이런 소리를 들을 것을 만들고자 노력했던 건가.


깨닫는 데까지 정말 오랜 시간이 걸렸다. 내가 그렇게 열심히 디자인한다고 들인 그 시간은, 사실은 픽셀을 잘 보여주려는 노력에 불과했던 것이다.


불편한 진실은 이러하다. 당신이 포토샵으로 디자인하는 것은 그냥 불필요한 일일 뿐이다. (포토샵 파일은) 이야기가 시작되는 지점이고, 이야기할 때 필요한 참고 대상이거나, 만들어 나갈 플랫폼이 될 뿐이다. 그것은 결코 결정적인 조각이 아니다.


디자인은 여러 기술을 합쳐 만들어진다. 협력 과정이다. 불명확한 것을 명확하게 하고, 불확실성을 지우며 앞으로 함께 나아갈 목표를 만드는 데에는 시간이 걸린다.


우리는 포토샵 말고도 여러 과정을 통해 디자인하고 있다. 이는 모호한 경계 위에서 사람들이 협업하며 이루어진다. 대화, 스케치, 문서, 다이어그램, 피드백을 통해 말이다. 결국 디자인 툴로서 포토샵의 한계를 느끼는 것으로부터, 우리는 그것의 커뮤니케이션 툴로서의 강점을 발견하게 된다.


내게 있어서 포토샵의 중요성은 많이 사라졌다. 난 디자인에 숨을 불어넣기를 갈망해왔다. 그것이 코드화되길 바랬다. 애니메이션의 뉘앙스나, 실시간 피드백을 포토샵에서는 그려낼 수 없다. 시도해볼 수는 있지만, 결국은 빠르게 움직이는 스토리보드에 올라가는 이미지 프리뷰나 만들 뿐이다. 나도 해봤다!


다음 단계는 코드로 한걸음 더 나아가는 것이다. 난 프론트엔드 코드는 짤 줄 알지만 하지 않기로 했다. 별로 좋아하지 않는다. 텍스트 에디터와 비쥬얼 피드백 사이의 간극은 나에게 너무 넓다. 난 좀 더 빠르고, 덜 어려운 것을 택하기로 했다.


쿼츠 컴포저(주: Quartz Composer; 애플의 개발 툴에 포함된 스크린 세이버나 인터랙티브 그래픽을 표현하는 데 최적화된 툴, 참조 링크)가 일말의 희망을 안겨줬다. 그 툴은 포토샵이 할 수 있던것 보다 더 HCI를 잘 설명해낼 수 있었다. 하지만 프로토타입만 만들 수 있었고, 언제 지원이 끊길 지 모른다는 루머로 인해 두려웠다.



디자이너들은 코드 기반의 세계에서는 무력하다


우리는 아이디어를 공유하고, 잠재적인 솔루션과 픽셀을 표현하기 위해 시간을 들이지만, 결국 우리의 디자인을 현실화 하기 위해서는 남의 기술이 필요하다.


애플의 다양한 디자인 그룹에 몸담았던 브렛 빅터(Bret Victor)는 아래와 같이 탄식했다. 

(전략) 이런 뛰어난 디자이너들이 실제 물건을 못 만들어내요. 제안만 할 수 있는거예요. 포토샵으로 목업(주: Mock-Up; 실제 제품 생산 전 형상과 기능을 확인하기 위한 샘플 제작) 을 그리지만 그대로 출하되는 제품은 만들지 못하죠. 대신에 그들은 엔지니어들에 의존합니다. 아이디어를 텍스트로 만들어 달라고 말이예요. 디자인이 대우받는 애플에서조차, 미묘한 무력함이 흘러요. 스스로 해결할 수 없기 때문이죠. 뭐 듣기 좋으라고 이런 걸 “보완적인 기술 세트”라고 말할수는 있겠죠. 하지만 진실은 뭐냐면요. 작가는 책을 내고, 뮤지션은 노래를 만들고, 애니메이터는 단편을 만들고, 화가는 그림을 내는데, 대부분의 (UI) 디자이너들은 창조물을 현실로 못 만들어내는거예요. 이게 내 마음을 찢어놓죠.

이 갭을 줄이기 위해 블로그들에 “디자이너도 코딩을 할 줄 알아야한다” 라는 주장들이 마치 해답처럼 나돌곤 했다. 하지만 많은 디자이너들을 만나 이야기를 해본 결과, 난 코딩도 해답이 아니라는 결론에 이르렀다.


코드를 한줄 한 줄 늘릴 때마다 상황은 악화되고, 복잡도만 늘어간다. 코드가 늘어갈수록 리팩토링(주: refactoring; 결과 변경 없이 코드를 재조정하는 과정으로, 속도를 빠르게 하는 등의 유지보수 역할을 함)을 해야 하고, 버그가 늘어가며 신입들은 배울 게 늘어간다. 결국에는 스파게티 코드가 되어버리고 마는 것이다.


실제 문제는, 우리의 지식이 부족해서 생기거나, 이해나 기술이 부족해서 생기는 것이 아니다. 협력적인 환경이 제대로 갖춰져 있지 않아서 생긴다. 디자인부터 소프트웨어 개발의 복잡성에도 잘 대응하며, 제품 생산을 위한 하나의 플랫폼을 제공하는 그런 툴 말이다. 이건 디자인과 코드의 대결이 아니고, 디자인과 코드의 화합인 것이다.


복잡한 코드를 담으면서도 좀 더 접근이 쉬운, 디자인을 해나가며 같이 개발을 할 수 있는, 그런 툴 말이다.


줄리 주가 언급한 대로, 쿼츠 컴포저는 이 두 세계를 통합하는 데 가장 가까이 갔다. 하지만 여전히 프로토타입은 프로토타입인 채 멈춰있다. 제안 이상의 것이 될 수 없다. 누군가는 여전히 따로 제로부터 코드를 짜야한다.


이런 툴의 제약은 더 협력할 수 있는 우리의 잠재력을 제한해버린다. 디자인과 개발 팀을 나눠서 일하는 게 아니라, 프로젝트 자체에만 집중하고 팀 내의 기술을 충분히 활용해서 제품을 만들 수 있는 그런 툴이 필요하다.



디자인, 협력, 그리고 만들기


이 문제를 해결하기 위해 만든 툴이 바로 노플로(NoFlo)이다. 디자인과 개발의 커뮤니케이션 격차를 줄이고, 실제로 효과적인 협력을 가능하게 하는 플랫폼을 제공하는 툴이다.


쿼츠 컴포저와 달리, NoFlo로 당신은 제품화할 수 있는 결과물을 만들 수 있다. 곧바로 개발, 인터랙션, 디자인 간 피드백을 공유하며 제품을 만들어나갈 수 있는 환경인 것이다.

16,471라인의 코드로 표현한 Jekyll이,

NoFlo에선 이렇게 표현된다

Contextual Cards

예를 들어보자. 지킬(주: Jekyll; 여러 텍스트와 테마를 소스로 정적 HTML 웹사이트를 쉽게 만드는 툴, 참조 링크) 안의 16,471줄에 이르는 코드를 표현하기는 누구에게나 막막한 일이겠지만, NoFlo에서는 상호 독립적인 요소들이 그래프 내에 연결되어 있는 구조이기 때문에 논리적인 부분에서 말이 되는지, 그리고 서로 어떻게 연결되어 있는지 확인해볼 수 있다. 앱을 만들기 위해 코딩을 할 필요가 없다.


UI레이어 덕에 코딩 능력에의 의존이 줄게 되었다. (코딩은) 여전히 존재하긴 하지만, 비주얼 스택(주: 시각적 요소) 깊숙한 곳에 숨어 있다. 코드는 좀 더 관리하기 좋고 적절한 조합으로 분리되었다. (분리되었지만) 논리의 맥락도 놓치지 않는다.


코딩하고 싶다면 할 수 있다. 그 덕에 다른 역할의 사람들, 혹은 새로 온 사람들이 좀 더 많은 이해를 가지고 제품을 만들 수 있게 된다. 실제 돌아가는 코드 위에서 디자인이 실현될 수 있게 할 수도 있을 것이고. 진정한 디자인-개발 환경이 주어지기 때문에 각 직군 간의 모호함의 층이 최소화된다. 통역이 안되어서 엇갈리는 일은 줄고, 진정한 협력이 일어날 것이다. 제 4의 시스템을 제공하여 사람들의 삶에 극적인 영향을 끼치는 것만큼 개인적으로, 경제적으로 큰 보상은 없다고 생각한다.


완전히 새로운 방식은 아니다. 플로우 기반의 프로그래밍은 우리 곁에 수 십년 동안 있어왔다. 헐리웃, 게임, 인공지능 같은 영역에서 이미 많이 쓰이고 있고, 웹에도 적용하려는 시도가 있었다.


그렇다면 왜 하필 지금, 내가 NoFlo를 만들려고 노력하고 있는것일까?


수백년 전만 해도 대서양을 비행기로 가로지른다는 라이트 형제의 아이디어는 웃음거리에 불과했을 것이다. 하지만, 누군가는 가능성을 타진했을 것이고 어떤 이는 같은 비전을 가졌을지도 모른다. 미래의 여행 방식으로 너무도 당연한 방법처럼 느껴졌을 것이다. 단지 이뤄내기가 어려웠을 뿐. 수십년 간의 실패와 시도 끝에 우리는 드디어 대륙간 비행의 꿈을 이뤄냈다. 그리고 오늘날 엄청난 사람들은 원래 이랬다는 것마냥 수천 마일을 날아다닌다.


가끔은 새로운 패러다임이 적용되길 기다려야 하는 때가 있다. 우리의 환경, 기술, 그리고 믿음이 우리의 비전과 발맞추길 기다려야 하는 것이다.


그리고 우린 이제 때가 되었다고, 변화의 시작이 무르익었다고 생각한다. 우리는 단지 디자인하고, 개발하는 툴이 아니라 무언가를 창조하고 만들어내는 데 있어 최고의 툴을 만들려고 한다.



NoFlo를 실현하기


아직은 NoFlo의 초기 디자인 개발 단계에 있지만, 비전에는 자신이 있다. 단지 당신의 도움이 필요할 뿐이다. 모든 질문에 대한 답을 가지고 있지 않다, 당신의 도움이 필요하다. 우린 플로우 기반의 프로그래밍 패러다임이 디지털 세계에 어떤 가능성을 가져올 지 열심히 탐색하고 있다. 당신도 우리의 탐험에 함께 해주길 바란다.


우리의 킥스타터 페이지에 방문해서, 지지를 보여주길! (역자 주: 킥스타터는 이미 펀딩이 성공적으로 완료되었습니다. 그래도 한 번 방문해보세요!)


실시간 인기

    번역중 Now in translation
    잠시 후 다시 시도해 주세요 Please try again in a moment