UI 디자이너에게 개발환경 설명하기

개발하는 디자이너 챌린지 - 05

챌린지 소개

'개발하는 디자인 챌린지'는 스레드(threads)에서 모집한 10명의 디자이너 참가자들과 개발 스터디. 실습을 진행하기 위해 매주 1회 발행하는 교육자료로 쓰이는 글입니다. 이 챌린지는 자세한 문법을 처음부터 알려주는 방식이 아닌 디자인-개발 플로우의 연관성 및 기본 개념을 알려주고 과감히 바로 예제부터 시작하는 튜터링 방식을 취하고 있습니다.

0. 프롤로그

네번째 에피소드까지는 v0라는 온라인 생성형 코드툴을 이용해서 예제를 작업해봤습니다. 그 이유는 react.js의 개념이 Figma의 각 기능과 어떻게 매칭이되느지를 가장 빠르고 쉽게 확인할 수 있었기 때문입니다. 하지만 v0를 실무에서 활용하기에는 몇가지 제한 사항들이 있습니다. 이제 기본적인 개념들을 실제 예제를 통해 확인해봤으니, 이제는 각자 로컬에서 개발환경을 구축하기 위해 꼭 알아야할 개념들을 살펴보겠습니다.

1. 개발환경은 왜 중요한가?

개발환경은 조금 포괄적인 의미지만 보통 다음 사항들을 얘기합니다.

사용할 언어 (eg. react.js)

사용할 툴 (eg. curosr, vsc)

코드 작성 규칙 (eg. eslint)

사용할 라이브러리 (eg. mui)

개발환경이 중요한 이유는 사실 디자이너의 프로젝트 세팅이 중요한 것과 거의 일치합니다. 신규 프로젝트라면 맨땅에 해딩하듯이 모든걸 처음부터 만들계획을 세우진 않을겁니다. 어떤 UI 라이브러리 혹은 템플렛이 프로젝트 성격과 핏할지, 그리고 같이 협업할 사람들간의 업무 규칙, 컴퍼넌트등의 네이밍룰 같은 것을 사전에 협의할 필요가 있겠죠.

개발 환경도 이러한 맥락에서 생각하시면 됩니다. 하지만 협업을 위한 개발환경보다는 일단은 작동하기 위한 개발환경 세팅을 먼서 설명드리려하며 다음 몇가지 개념들은 꼭 이해하셔야 합니다.

1-1 Node.js

요약하자면 node.js는 javascript가 범용적으로 동작하기 위한 환경입니다. 예전에는 JavaScript가 동적인 화면을 만들기 위해 브라우저 안에서만 동작했지만 점차 넓은 영역에서 동작하기 위한 환경이 필요했습니다. 이를 기술적으로 다 설명하자면 내용이 길고 어렵습니다.

노드 js는 터미널에 커멘드를 통해 혹은 직접 다운로드 받아서 설치하는 방법이 있습니다.

그치만 2번째 에피소드에서 언급했던 모던프레임 워크에 영향을 주었던 UX 디자이너 제시 제임스의 사례를 다시 살펴보면 왜 node.js가 등장했는지 좀더 쉽게 설명이 가능합니다. (이글을 처음보시는 분들은 2번째글을 읽어보시기 바랍니다.)

당시 제시가 주장했듯이 프론트와 서버 사이의 통신이 비동기적이고, 더 일괄된 사용자 경험을 주기 위해서는 두 영역의 언어를 통일할 필요가 있었습니다. 즉 화면을 움직이고 데이터를 서버에 보낼때 필요한 언어, 그리고 서버에서 이를 관리하고 처리하는 언어가 같으면 좋다는 뜻입니다. 결국

유저가 필요한 그대로의 데이터를 갖고 클라이언트와 서버가 얘기하자

로 요약할 수 있겠습니다.위 내용으로 node.js의 모든걸 설명하긴 힘들지만, 탄생 배경과 써야하는 이유는 이정도로 정리할 수 있겠습니다. 결국에 React.js를 사용하려면 반드시 node.js를 로컬 컴퓨터에 설치해야합니다.

1-3 NPM (node package manager)

node.js를 꼭 설치해야하는 또 다른 이유는 NPM을 사용해야 하기때문입니다. 정말 쉽게 설명하자면 npm은 피그마의 커뮤니티와 같은 기능입니다. 우리는 피그마의 커뮤니티에서 누군가 미리 만들어 놓은 디자인 템플릿과 플러그인을 사용해서 디자인 생산성을 높입니다.

피그마가 이러한 디자인 생태계를 구축하기 훨씬전 node.js 기반의 NPM을 통해 수많은 개발 라이브러리들이 배포되고 있었습니다. 크게는 react.js와 같은 프레임워크도 결국 NPM을 통해 설치되며, MUI와 같은 UI library, 날짜의 포맷을 바꿔주는 유틸형 패키지 등등 온갖 기능들의 패캐지들이 있습니다.

날짜 포맷과 관련된 package를 npm 공식 사이트에서 검색한 결과

config 2024에서 대만 출신 디자이너 Lichin Lin이 자신이 개발한 플러그인을 발표하고 있다.

작년 config2024에서 피그마는 훌륭한 플러그인을 만들어 배포한 유저들에게 발표의 기회를 주기도 했습니다. 이처럼 개발 커뮤니티에서도 사람들이 많이 사용한 패키지를 만든 개발자들은 자신의 커리어에서 매우 좋은 포트폴리오로 남길 수 있습니다.

1-4 Terminal

터미널은 사용자가 GUI가 아닌 텍스트로 직접 운영체제 명령을 내리는 창을 얘기합니다. 터미널은 컴퓨터와 소통하는 마지막 지점'터미널'이라는 뜻도 있으며 과거에 최초로 출시된 텍스트 화면과 키보드를 탑제한 컴퓨터 모델 이름이기도 합니다.

react.js 프로젝트를 생성할때도 터미널을 사용한다.

터미널은 운영체제에서 직접 불러올 수 있고, 개발툴 (IDE)에서 다수의 터미널 창을 띄워서 작업할 수 있습니다. 어째든 터미널이 필요한 이유는 위에서 언급한 node.js와 npm을 통한 패키지 설치는 GUI 프로그램이 아닌 터미널에서 직접 명령어를 입력해야하기 때문입니다.

1-4 IDE (Integrated Development Environment)

IDE는 개발 툴을 얘기합니다. 제가 초등학교때 컴퓨터 학원을 가면 메모장에 html을 알려주는 시절도 있었는데요, 여러 과정을 거쳐 지금의 IDE툴들까지 발전했고 이 툴은 다음과 같은 역할을 합니니다.

프로젝트 폴더 및 파일 관리

프로젝트 패키지 관리

분할 화면, 코파일럿 (코딩 보조 도구)등의 개발 환경 제공

코딩 컨벤션 설정 (들여쓰기 개행과 같은 코딩 작성 방식)

협업을 위한 git 연동

실제 제가 작업중인 프로젝트의 cursor 화면입니다. 우측 영역의 프롬프트는 BarChart 컴퍼넌트를 부모의 width에 따라 반응형으로 만들어달라는 prmopt의 결과입니다.

등이 있지만 일단 시작 단계에서는 처음 3개 정도만 알고 계시면 됩니다. 가장 유명한 IDE는 마이크로 소프트에서 만든 VSC (Visual Studio Code)가 있으며 최근에 가장 핫한 AI prompt 기반의cursor AI가 개발 커뮤니티에서 엄청난 관심을 받고 있습니다.

2. 논란의 중심 cursor ai

작년(2024) 개발 커뮤니티에서 가장 최고의 화두는 바로 cursor ai였습니다. cursor의 외관은 vsc와 거의 동일합니다. 차이점은 chat GPT, cluade등의 LLM 모델을 선택하여 코드 자동 생성 및 개선 작업에 AI를 개입시킬 수 있다는점입니다. 믈론 이 모든 작업은 프롬프트로 진행되며, chat GPT 또한 상황에 맞게 환경 설정을 하듯 cursor또한 이러한 과정을 거치면 더 정확한 결과물을 얻을 수 있습니디.

그런데 개발을 처음 공부하는 사람의 cursor의 활용을 두고 여러가지 이견과 논란이 분분합니다. 이 이유에 대해서 설명하는 것이 앞으로 미래의 개발환경을 이해하는데 도움이 될거라 생각합니다.

2-1 비판적 입장

저는 작년부터 cursor를 너무 잘쓰고 있는데 생각보다 비판적인 입장이 많아서 사실 조금 놀랐습니다. 이러한 입장은 주니어 개발자를 관리하는 시니어 입장에서 바라본 부작용들이 반영된 것입니다.

즉 개발 경험이 충분히 쌓이지 않은 상태에서 prompt로 만든 코드는, 예상치 못한 오류를 수정하거나 기존 코드와의 컨벤션을 맞추는 과정에서 프로젝트 전반적인 흐름일 깨는 경우가 발생하기 때문입니다. 그리고 개발자의 성장 차원에서도 처음부터 AI의 의존도가 높아지면 좋지 않다는 관점이죠.

2-2 찬성하는 입장

그럼에도 불구하고 저는 개발을 배우는 시점부터 cursor를 이용하면 좋다는 입장입니다. 더 정확히 얘기하면 단순히 좋다 보다 prompt를 활용하는 능력을 지금부터 키워야 한다는 강경한 의견입니다. 그 이유는 아이러니 하게 AI의 장점을 극대화 하기 위해서는 프로그래밍의 본질적인 특징에 더 집중할 수 밖에 없기 때문이죠.

예를들어 모든 알고리즘을 직접 작성하는 시간을 줄이고 코드의 패턴화와 전체 구조를 어떻게 설계할지 더 신경써야 한다는 점입니다. cursor의 Prompt로 만든 코드들이 제 각각인 이유는 애초에 그런 고민 없이 '묘사적인 프롬프트'를 사용했기 때문입니다.

따라서 프로그래밍의 기본적인 소양과 이를 기반으로 프롬프트 생산성을 극대화 하는 방식을 같이 고민해하는게 next generation programer가 되는 적합한 접근이라 생각합니다.

3. 이 챌린지에서 cursor를 선택한 이유.

앞선 에피소드에서는 빠르게 react.js의 개념들을 확인해보기 위해 v0라는 온라인 툴을 사용했습니다. 하지만 저는 '개발하는 디자이너' 챌린지에 가장 적합한 IDE는 cursor라고 생각하고, 앞으로 예제에서 계속 활용할 생각입니다. 그 이유는 적잡한 가이드 아래에서 cursor를 활용하면 figma에서 만든 디자인 가이드를 그대로 react.js에서 구현할 수 있는 가장 정확하고 효과적인 방식이 될 수 있기 때문입니다.

이러한 과정은 최근 여러 노코드 툴들에서 시도하고 있지만 아직은 부분적인 인터랙션을 코드로 전환해주는 수준이지 전반적인 웹서비스 전체를 개발하기에는 무리가 있어 보입니다.

여하튼 제가 세운 몇가지 가이드는 다음과 같습니다.

3-1. 준비된 UI 라이브러리와 활용한다.

이전 예제에서는 MUI를 활용했는데, 이처럼 준비된 라이브러리를 활용하는 것이 훨씬 패턴화된 코드를 작성하는데 도움이 됩니다. 기본 컴퍼넌트들을 직접 만들 필요도 업으며, 디자인 토큰을 수정해서 디자인을 커스텀하는 방식 또한 충분히 가능하기 때문이죠. 무엇보다도 이미 AI 학습한 UI 라이브러리는 마치 미드저니의 각종 레퍼런스 파라미터 처럼, 정확한 결과물을 예측할 수 있는 레퍼런스 역할을 해줍니다.

3-2. 내가 이해하지 못하는 코드는 생성하지 않는다.

특정 상황을 묘사하듯한 프롬프트 보다는, 작은 단위의 컴퍼넌트들을 확실하게 설명하는 방식이 더 안정적입니다. 이를 위해서는 이 프롬프트를 통해 대략 이런방식의 코드를 짜주겠구나를 예상 가능할 정도의 명확한 프롬프트를 작성해야합니다.

잘 이해가 가지 않는 코드의 리뷰를 부탁할 수 있다. 이 과정을 반복하면서 상황에 더 적합한 방식을 점진적으로 좁혀가면서 찾아야 한다.

3-3. 혹은 생성된 코드가 모두 이해하기 전까지는 넘어가지 않는다.

하지만 그럼에도 불구하고 내가 이해하지 못하는 코드가 생성될 경우가 있습니다. 이때는 반드시 코드 리뷰를 cursor에 직접 부탁하거나 혹은 코드를 복사해서 chat gpt에 물어보는 방법도 있습니다. 단순히 설명만 한번 읽고 끝나는 것이 아닌 javascript나 react.js의 공식 문서에서 해당 문법에 대한 설명을 다시 읽어보는 식으로 반드시 생성된 코드를 다 이해한 상태에서 넘어가야 합니다.

3-4. 데이터와 컴퍼넌트의 조합으로 프롬프트를 구성한다.

결국 2,3번을 잘하기 위해서는 데이터와 컴퍼넌트의 조합으로 프롬프트를 작성하는 것이 제일 좋습니다. 이전 레피소드에서 만들었던 스타벅스 예제 웹사이트를 예시로 들자면 처음에는 스타벅스 스페셜 메뉴에 해당하는 데이터셋을 만들었고, 이 데이터들이 어떤 컴퍼넌트와 결합되고 각 데이터가 컴퍼넌트의 어떤 props에 들어가고 어떤 역할을 하는지 설명이 필요합니다.

이 과정을 더욱 원활하기 위해 데이터 셋의 각 키값과 매칭되는 Props 이름을 애초에 동일하게 설정하는 것이 중요합니다. 그리고 각 컴퍼넌트들도 애초에 MUI에 등록이 된것들이나, 혹은 이를 조합해서 필요한 UI를 먼저 cursor에 인지시키는것이 중요합니다. 이 자세한 방식은 다음 에피소드에서 다루겠습니다.

4. AI 시대에 필요한 사고방식

제가 좋은 프롬프트를 작성하기 위해 가장 중요하게 생각하는 2가지 사고 방식이 있습니다.

4-1. 발산형 사고와 수렴형 사고를 나누어 접근하라

디자이너에게는 익숙한 더블다이아몬드 모델이라는 사고방식이 있습니다. 발산과 수렴을 두번 반복한다고 해서 더블 다이아몬드라는 이름이 붙여졌는데 팬을 만드는 과정을 예로들어보겠습니다.

Discover (발견)

일단 이세상에 어떤 팬들이 있는지 조사를 해봐야됩니다. 첫번째 발산입니다.

Define (정의)

이제 조사한 팬들의 핵심적인 특징들을 뽑아서 정리하고 그중 기회영역을 정의합니다. 첫번째 수렴입니다.

Ideate (발현)

이제 정의한 문제점을 해결하기 위해 어떤 아이디어가 좋을지 브레인 스토밍을 해봅니다. 두번째 발산입니다.

Deliver (전달)

마지막으로 아이디어들을 다 모아서 이 팬을 실질적으로 만들 방법을 정하고 실행에 옮깁니다. 두번째 수렴입니다.

만약 팬을 만드는 과정에서 이러한 단계적인 절차가 없다면 의중을 파악하기 힘든 팬을 상당히 비효율적인 방식으로 만들었을 것입니다.

이는 AI와 소통할때도 마찬가지입니다. 예를들어 prompt로 "이세상에 없는 팬을 만들어줘"라고 하면 어떻게든 결과물은 나오겠지만 의도가 무엇인지 파악하기 힘든 결과물이 나올것입니다. 그 이유는 발산과 수렴과정을 한번에 해결해려 했기때문이죠.

그리고 cursor는 결국 개발을 위한 툴이기 때문에 가급적 어떤 아이디어를 대신 만들어줄 용도의 프롬프트는 적합하지 않다고 생각합니다. 다만 어떤 목적을 이루기 위한 적합한 방식들에는 무엇이 있는지는 충분히 물어볼 수 있습니다.

4-2. 작은 지시사항들로 쪼개서 설명하라.

결국 2번도 비슷한 맥락입니다. 건축 디자이너가 건물을 디자인할때 뼈대를 설계하고, 동선을 고려해서 파티션을 나누고, 마지막에 인테리어를 합니다. 그런데 이 모든 과정이 항상 매끄럽지는 않습니다. 뼈대를 설계하고 동선을 고려하다보면 다시 뼈대를 고쳐야하는 경우가 생기죠.

바로 이러한 필연적으로 발생할 수 밖에 없는 수정사항때문에 프롬프트 역시 작은 단위로 쪼개서 작성하는 연습이 필요합니다. 저같은 경우는 보통 웹서비스를 만들때 정보구조 문서에 명시된 데이터 모델을 먼저 정의하고 이를 학습 시킵니다. 그리고 이와 매칭되는 가장 작은 컴퍼넌트들을 먼저 만듭니다. 그 이후에 특정 상황에 발생하는 데이터셋과 컴퍼넌트와의 조합으로 템플렛을 만들도록 시키면 이제 각 페이지에 들어갈 기본 섹션들이 미리 준비된 환경을 효과적으로 구축할 수 있습니다.

5. 마치며

이번 에피소드는 본격적으로 로컬환경에서 개발을 하기 위해 꼭 알아야할 개념들과 앞으로 사용할 cursor를 잘 쓰기 위해 갖춰야할 몇가지 사고방식을 다뤄봤습니다. 원래는 node.js와 npm을 이용한 react.js 프로젝트 생성까지 포함시키려 했는데 내용이 길어져서 둘로 나눴습니다. 다음 에피소드에서는 튜토리얼식으로 위의 과정을 거쳐 개발화경을 세팅하는 내용을 다룰 예정입니다.

Data Driven Design 공식 홈페이지: http://dddesign.io

dddd의 스레드: https://www.threads.net/@dddesign.io