URL: https://linear.app/now/design-is-more-than-code

디자인은 코드 그 이상이다

코드로 디자인하는 것은 반복해서 등장하는 논쟁이고, 최근 다시 불붙었습니다. 저는 이 주제에 대해 이미 두 번 글을 썼습니다. 파이프라인이 아닌 탐색으로서의 디자인. 도구가 어떻게 ‘의견’을 담는지, 그리고 그 의견이 무엇을 시도하는 것이 “합리적”으로 느껴지는지까지 어떻게 형성하는지. 너무 이른 시점에 들어오는 제약이, 아직 가능성을 찾기도 전에 가능성의 문을 닫아버릴 수 있다는 점. 저는 업계가 ‘대통합’을 향해 달려가며, 미묘하고 섬세한 과정을 코드로 납작하게 접어 넣고 이를 진보라고 부르는 흐름에 회의적입니다.

최근의 담론은 디자이너가 코딩을 해야 하는지, 코드가 디자인에 적절한 매체인지, 코드가 디자인의 “진실”을 어떻게 보여주는지 등으로 집중되어 왔습니다. 하지만 저는 이 논쟁을 코드와 도구 중심으로 놓는 것 자체가 환원적이라고 생각합니다.

저에게 더 큰 질문은, 특히 지금처럼 AI와 새로운 도구들이 등장한 상황에서 앞으로 디자이너의 기여를 어떻게 보게 될 것인가입니다. 역할은 어떻게 진화하고, 각 역할에 대해 무엇을 기대하게 될까요?

이제 디자이너는 엔지니어가 되었고, 같은 기대치를 가져야 할까요? 엔지니어는 디자이너에게도 같은 기대를 하기 시작할까요? 여전히 “엔지니어링 총괄(head of engineering)”과 “디자인 총괄(head of design)”이 존재할까요, 아니면 “크래프트 총괄(head of craft)” 같은 형태로 바뀔까요? 직함 자체는 그렇게 중요하지 않지만, 이런 질문들은 우리가 무엇을 가치 있게 여기고 일이 어떻게 이루어진다고 생각하는지를 드러내기 때문에 유용합니다.

그리고 실용적인 질문이 뒤따릅니다. 디자이너가 엔지니어링 쪽으로 흡수되듯 흐르고, 코드를 통해 직접 디자인하게 된다면, 그것은 좋은 방향일까요? 우리는 무엇을 잃고 무엇을 얻게 될까요?

이 논의가 종종 엉키는 이유 중 하나는 ‘디자인’이 사람마다 다른 의미를 갖기 때문입니다. 디자인을 어떻게 바라보는지는 어떤 종류의 디자인을 하는지, 그리고 디자인을 하나의 실천(practice)으로 어떻게 이해하는지에 달려 있습니다.

저는 디자인이 여러 가지 “맛”으로 존재한다고 믿습니다. 디자이너 개인, 도메인, 시장, 고객에 의해 영향을 받죠. 소비자 제품에서는 동기를 예측하기 어렵기 때문에 아이디어를 빠르게 실험해야 할 수도 있습니다. B2B나 엔터프라이즈에서는 보통 더 많은 맥락이 있고, 그 맥락을 바탕으로 설계할 수 있습니다. 어떤 산업은 극도의 신뢰성과 명확성을 요구합니다. 환경도 중요합니다. 이해관계자, 클라이언트, 회사 문화, 그리고 디자이너로서의 당신의 역량까지. 시각적 역량이 강하면 시각에서 출발해 이끌고, 코드에 강하면 더 이른 단계에서 코드를 사용할 수도 있습니다.

그리고 어떤 사람에게는 디자인이란 그저 버튼을 화면에 올리고 다음으로 넘어가는 일일 뿐이기도 합니다.

즉 소프트웨어 디자인이라는 넓은 영역이 있고, 그 안에는 다양한 도구와 방법이 존재합니다. 코드 vs 노코드 논쟁은 종종 핵심을 놓치고, 오히려 사람들을 양극화하는 힘이 됩니다.

제가 말하고 싶은 것은, 이 논의를 도구를 넘어서는 수준으로 끌어올리고, 도구가 디자인의 미래를 장악하지 않도록 하는 것입니다. 새로운 도구가 실행을 더 쉽게 만든다는 이유로, 개념적 사고와 확산적 사고(divergent thinking)를 불필요하게 평가절하하는 일은 원치 않습니다.

코드로 하루 종일 일하는 엔지니어조차도 코드에서 벗어납니다. 아키텍처를 그려보고, 시스템을 계획하고, 트레이드오프를 따져 보죠. 소프트웨어는 코드에 “살고” 있지만, 모든 결정을 코드에서 내려야 하는 것은 아닙니다.

제가 무슨 뜻인지 설명하려면, 제가 디자인을 어떻게 이해하고 어떻게 실천해 왔는지부터 시작해야 합니다.

문제를 디자인하기⁠

먼저 저는 정규 교육을 받은 디자이너가 아닙니다. 지난 20년 동안 수백 개의 디자인 프로젝트를 하며 독학으로 배웠습니다. 그래서 저는 게이트키핑을 옹호하거나, 디자인의 “정답”이 하나뿐이라고 주장하려는 것이 아닙니다. 다만 저는 디자인이 대체로 선형적이지 않다고 생각합니다. 서로 다른 추상화 수준에서 작업하고, 그 사이를 오가죠. 결과물이 목표이긴 하지만, 그 여정에 시간을 쓰는 것이 결과를 더 좋게 만들 수 있습니다.

그 과정에서 저는 문제를 먼저 의심하는 법을 배웠습니다. 문제를 전제로 받아들이지 않는 거죠. 어떤 일을 요청받으면 저는 이렇게 시작합니다. 이게 정말 문제인가? 우리가 이걸 하지 않으면 어떻게 되지? 누가 이 문제를 정의했지?

철학적으로 들릴 수 있지만, 제가 발견한 바로는 디자인 프로젝트가 늘어지거나 실패하는 가장 흔한 이유는 문제가 명확하지 않았기 때문입니다. 사람들은 서로 다른 문제를 머릿속에 두고 있기 때문에 해결책에 동의하지 못합니다. 해결책은 하나의 큰 문제에 대한 깔끔한 답이 아니라, 여러 가지 다른 문제들의 타협안이 되어 버립니다. 이해관계자가 많을수록 이 현상은 더 심해집니다.

이를 해결하기 위해 저는 두 가지를 했습니다. 제가 이해한 방식으로 문제를 문서로 쓰고, 이해관계자가 누구인지 묻는 것입니다. 그리고 그 이해관계자들에게 해결책을 제시할 때, 문제를 다시 반복해서 말해 반응이 일어나는지 확인합니다. 반응이 있다면 멈추고, 그 자리에서 문제 정의에 대해 모두가 정렬(alignment)되도록 합니다. 여기까지 들으면 “이게 디자인과 무슨 상관이지? 좀 기업적인(corporate)데?”라고 느낄 수 있습니다.

하지만 이해관계자는 언제나 존재합니다. 동료가 없더라도 고객이 있죠. 피드백이 ‘해결책이 좋지 않아서’ 진짜로 나온 것인지, 아니면 ‘문제에 대한 합의가 없어서’ 나온 것인지 이해해야 합니다. 때로는 잘못된 문제를 상대로 디자인하고 있을 수도 있습니다. 문제는 방정식의 첫 번째 항입니다. 당신이 디자인하고 만들려는 것의 기초입니다.

Linear에서는 회사에 프로젝트가 필요하다는 점을 빠르게 알았습니다. 그래서 로드맵에는 “프로젝트를 만든다(build projects)”가 올라갑니다. 모두가 필요하다고 동의하죠. 하지만 조금 더 생각해 보면, 왜 회사들은 일을 프로젝트 단위로 조직할까요? 다음 할 일(task)만 하면 안 될까요? 프로젝트가 없으면 무슨 일이 생길까요?

프로젝트 관리는 깊게 파고들 수 있는 주제입니다. 그 뒤에는 하나의 학문 분야가 있고, 수행 방식도 다양합니다. 하지만 ‘소프트웨어 회사를 위한 목적형 도구(purpose-built tool)’를 만들겠다는 비전이 있다면, 범위는 점점 좁혀집니다. 그들이 वास्तव로 중요하게 여기는 것은 무엇일까요?

간단히 말하면, 프로젝트는 회사가 업무의 흐름(streams of work)을 관리하기 위한 자연스러운 추상화입니다. 책임(accountability), 소유권(ownership), 팀 간 협업(cross-team collaboration), 예측 가능성(predictability), 가시성(visibility)에 도움이 됩니다.

그렇다면 왜 이렇게 기본적이거나 잘 이해된 것을 굳이 조사하냐고 물을 수 있습니다. 때로는 그럴 필요가 없습니다. 하지만 지형과 역사를 배우면 방향 감각이 생깁니다. 도전할 수 있는 가정을 발견하거나, 어떤 전통을 따를지 결정하게 되죠.

가장 중요한 것은, 먼저 문제를 학습하면 그 문제에 대해 무엇을 할지 결정하는 데 도움이 된다는 점입니다. 제품 비전이 어떤 방향으로 당신을 끌어당기는지, 무엇을 최적화하고 어떤 영향을 미치고 싶은지가 분명해집니다.

Linear에서는 프로젝트가 어쩌면 가장 중요한 업무 단위일 수 있다고 보았습니다. 제품은 프로젝트로 만들어지고, 조직은 프로젝트를 중심으로 정렬되며, 프로젝트가 출시되면 이를 축하합니다. 이런 이해는 우리가 어떤 문제를 풀고 있는지에 대한 방향을 제공해 주었습니다.

해결책을 디자인하기⁠

저는 해결책을 디자인하는 과정을 두 단계로 봅니다. 개념 단계(conceptual stage)와 실행 단계(execution stage)입니다. 개념 단계는 디자인이 취할 전체적인 형태를 찾아가는 과정입니다. 실행 단계는 그것을 구체화해 실제로 만들고 화면에 올리는 일입니다.

이슈 트래킹 도구에서 ‘프로젝트’를 예로 들면, 이를 하위 이슈를 가진 하나의 큰 이슈로 다룰 수도 있고, 이슈들의 폴더나 라벨로 다룰 수도 있으며, 이슈와 연결된 독립된 엔터티(entity)로 만들 수도 있습니다. 이런 것들은 화면에 아무것도 올리지 않아도 고려할 수 있는 개념적 아이디어입니다. 어떤 결정을 내릴지는 사용자, 회사, 그리고 당신이 원하는 비전에 대한 이해로 귀결됩니다. 이 모든 개념은 성립 가능하고, 실제 제품에서도 찾아볼 수 있습니다.

우리는 프로젝트를 중요하게 보았고, 이슈와는 다르다고 보았기 때문에, 프로젝트는 고유한 형태를 가진 독립된 엔터티여야 했습니다. 프로젝트는 상태(status), 근거(reasoning), 사용자 피드백(user feedback), 우선순위(prioritization), 타이밍(timing), 더 큰 이니셔티브(initiatives)와의 연결을 전달할 수 있는 알아볼 수 있는 형태와 기능을 가져야 합니다. 프로젝트를 라벨이나 느슨한 이슈 모음으로 격하시키는 것은 맞지 않다고 느꼈습니다.

이 개념 단계는 글로, 종이에, 디자인 도구에서, 혹은 코드에서 이루어질 수 있습니다. 중요한 것은 아이디어에 형태를 부여하고, 다양한 방향을 시도하다가 결국 문제와 제품 비전에 가장 잘 맞는 방향을 선택하는 일입니다.

제가 믿을 만한 방향을 잡으면, 더 넓은 피드백을 받을 준비가 된 것입니다. 그리고 그 개념을 ‘만들어’ 보며 테스트합니다.

이는 최종 결과물에 가장 가까운 단계입니다. 디자인 개념이 실제로 작동하도록 만들고, 그것을 현실적인 무언가로 빚어냅니다. 코드, 혹은 재료(material)와 직접 작업하는 것은 이 단계에서 필수적입니다. 그리고 때로는 새로운 통찰을 얻어 문제나 개념으로 되돌아가 다시 검토해야 하기도 합니다.

이 단계에서 코드를 사용하는 방식도 여러 가지입니다. 도구를 만들 수도 있고, 버려도 되는 코드로 “스케치”할 수도 있습니다. 이는 프로덕션 코드의 일부 제약을 제거해 과정을 더 탐색적으로(exploratory) 만듭니다. 제 요지는, 실행 단계가 디자인의 ‘진짜’ 부분처럼 보일 수는 있지만, 그 이전에 이미 맥락과 확신의 기반을 쌓아 두었다는 것입니다. 재료가 저항할 때도, 당신은 그 확신을 바탕으로 밀고 나갑니다.

이를 LLM 용어로 생각해 보세요. 사전에 수행하는 디자인 작업은 에이전트가 문제를 해결하도록 만드는 목표(goal), 맥락(context), 프롬프트(prompt)를 만드는 일입니다. 실행 작업은 구체적인 의사결정을 통해 에이전트를 안내하는 단계입니다.

여기까지 읽으면 “누가 이런 걸 할 시간이 있어? 출시해야 하잖아. 그냥 바로 만들고 가면서 맞추면 안 돼?”라고 생각할 수도 있습니다. 저는 이것이 시간의 문제라고 생각하지 않습니다. 제 설명은 길었지만, 과정 자체는 빠를 수 있습니다. 필요한 만큼만 시간을 쓰면 됩니다.

제 느낌은, 그런 맥락과 목표 없이 시작하면 어떤 방향으로든 반복(iteration)하고 있을 수는 있지만, 의도적으로 선택된 방향을 향해 가는 것은 아닐 수 있다는 것입니다.

이 지점에서 처음 이야기로 돌아옵니다. 우리 업계는 인내심이 많지 않습니다. 그리고 기본값으로 ‘프로덕션에 바로 들어가는 디자인’을 만들기 시작하면, 문제, 개념, 의도를 숙고할 문화적·조직적 이유가 빠르게 증발합니다. 우리는 결과물(output)을 위해 디자인의 ‘왜(why)’를 평가절하하기 시작합니다.

제 걱정은 코드나 도구 그 자체가 아닙니다. 숙고의 감소, 그리고 그로 인한 독창적이고 잘 디자인된 제품의 감소입니다. 새로운 도구와 기술이 등장해도, 이를 어떻게 살아 있게 유지할지가 질문입니다.

저에게 디자인은 버튼이 무엇인지/무엇을 하는지, 혹은 어떤 매체에서 작업하는지에 관한 것이 아니었습니다. 그리고 지금도 아닙니다. 디자인은 올바른 문제, 올바른 의도, 올바른 비전을 찾는 일입니다. 오늘 당신이 디자인하고 만드는 기능은 그 비전을 향한 숙고된 한 걸음이어야 합니다.

이 주제에 대한 코멘트와 논의를 제공해 준 Charlie Aufmann, Tuhin Kumar, Ramon Marc, Conor Muirhead, Gavin Nelson, Raphael Schaad, Jeff Smith, 그리고 Soleio에게 감사드립니다.