화면설계서를 잘 만들지 않으면 여러 포지션에 타격을 줄 수 있기 때문에, 오늘은 이 뜨거운 감자인 화면설계서에 대해 써보려합니다.

💡 화면설계서엔 어떤 정보가 담겨야 할까?

*1. 화면 코드 (Screen ID) * • 예: USR_01_001

• 개발자가 API 명세를 맞출 때
• QA팀이 어떤 화면에서 버그가 났는지 추적할 때
• 운영자가 로그를 찾을 때

→ 이 Screen ID가 모든 기준점이 됩니다!

뭐 화면명 짓는건 기획자 (혹은 디자이너) 마음이겠지만요. 저같은 경우에는 플랫폼 / 기능을 기준으로 짓습니다.

⸻

2. 화면 설명

가장 핵심인 내용, 화면 설명은 뭐 말그대로 제곧내인데요. 저같은 경우에는 신규 팀원이 와도 빠르게 이해하는 것이 중요하다고 생각하기 때문에, 최대한 쉽고 구체적으로 쓰려고 노력하는 편입니다.

📌 [예시]

• 목적: 회원가입 시 개인정보를 입력받는 화면
• 유입 경로: 온보딩 → 이메일 인증 완료 후 자동 이동
• 대상 사용자: 신규 회원

⸻

3. 데이터 정의

• 입력 필드: 어떤 데이터가 들어오고, 어떤 제약조건이 있는지 • 출력 필드: 어떤 데이터가 사용자에게 보여지는지 • 형식까지 명확히!

📌 [예시]

• 이름: 2~20자, 한글만 허용
• 생년월일: YYYY-MM-DD 형식
• 휴대폰번호: 숫자만 입력, '-' 자동 삽입

이 데이터 정의 저어어엉말 중요한데요. 기획자도 사람이다보니 가끔 데이터 구조를 빠뜨릴때가 있습니다. 여기서 "CRUD" 개념이 참 중요하다고 느끼는 부분입니다.

그래서 저같은 경우는 이런식으로 구조를 짜는데요.

[화면 : 게시글 상세보기]
- Create : "작성" 버튼 클릭 시 게시물 작성 페이지로 이동
- Read : 게시물 상세보기로 이동
- Update: 게시물 수정 페이지로 이동 (권한 :로그인 후, 유저 본인에게만 수정 버튼 노출)
- Delete : "삭제" 버튼 클릭 시 경고 팝업 노출

이렇게 CRUD 개념에 맞춰서 작성한다면, 개발단에서 작성하는 API명세서도 깔끔해지고, 무엇보다 기능 누락이 정말 적어집니다.

기획서를 만들다보면, 디폴트 화면이 아닌 데이터가 꽉꽉 채워져있는 화면을 넣게되는데요.

이럴 때 동료들이 "데이터는 어디 신이 내려주나?" 라는 생각이 안들도록, 데이터가 어떻게 오고 가는지에 대한 기재가 정말 중요합니다.

⸻

4. 권한 & 접근조건

• 관리자만 볼 수 있는지 (관리자페이지의 경우, 접근 권한이 세분화되는게 필수) • 로그인 유저만 접근 가능한지 • 특정 역할(예: 파트너사)에게만 노출되어야 하는지

💡 예시

• 접근 권한: partner, admin 만 진입 가능
• 로그인 필수 여부: O

⸻

5. 버튼 및 인터랙션 설명

• 버튼 클릭 시 어떤 API 호출? • Modal 뜨는 조건은? • Validation 실패 시 에러 메시지?

[저장 버튼]

• API: POST /users
• 성공 시: 알림 “저장되었습니다” + 이전 화면으로 이동
• 실패 시: 필드 옆에 에러 메시지 출력

⸻

6. 에러 케이스 세분화

• 단순히 “에러 발생”이 아니라, • 어떤 조건에서 발생하는지 • 사용자에게는 어떤 메시지를 보여줘야 하는지 • 백엔드에선 어떤 에러코드를 내려주는지

🚨 예시

• 휴대폰번호 중복 시: “이미 등록된 번호입니다” 출력
• 서버 오류(500): “고멘나사이. 일시적인 오류입니다." 출력

이런 게 잘 정리돼 있으면, 디자인 시스템에서 상태별 컴포넌트를 정의하기도 훨씬 수월합니다.

⸻

✨ 모두가 칭찬하는 ‘좋은 화면설계서’의 예시

✔️ 화면코드, 유입 흐름, 요구 기능 정리가 깔끔하게 ✔️ 버튼마다 API 연동 흐름 명시 ✔️ 권한별 UI 동작이 분리되어 있음 ✔️ 성공/실패 시 알림 or 라우팅 정의 ✔️ 오류 상황 명세까지 따로 문서화되어 있음

이 정도만 돼도, “와 기획서 깔끔하다” 소리를 들을 수 있을 것 같습니다. 반대로 이런 게 없으면, 개발단에 수많은 질문을 들을 수 있습니다. 개발할 시간도 촉박하기 때문에, 상세할수록 아주 좋다고 생각이 듭니다.

무엇보다 제일 중요한건, 기획서가 자세하고 명확하지 않을 경우 추가 개발과, 서버측에서 문제가 많이 발생하기 때문에 즈엉말 중요합니다. 기획.. 참 어렵고도 먼 길입니다.

⸻

🧠 마무리하며

화면설계서는 “보는 사람이 문서를 보고 바로 구현 가능할 정도”로 상세하게 쓰는 게 핵심입니다. 깔끔한 설계서 하나가 프로젝트 전체 품질을 좌우해요.

항상 저도 화면설계를 하며, 어떻게 하면 여러가지 기능을 놓치지 않을까.. 고민이 많이듭니다만 ^^; 다양한 동료분들과 얘기하면서 나온 "좋은 화면설계서"에 대한 기준을 기록해봤습니다.

그럼 20000 ! 읽어주셔서 아리가또 고자이마스입니다.

안녕하세요. 조금만 기다리면 기다리던 5월 연휴입니다. 얼마전에 디자인 시스템과 Token, JSON에 연관된 글을 읽었는데요.

디자인 시스템에 대한 다양한 아티클을 읽으며, "디자인 시스템은 왜 필요하며, 개발적으로 어떤점이 이득인가"에 대해 더욱 더 명확하게 기록하고 싶었습니다.

오늘 글은.. 제 경험이 굉장히 많이 담겨있기 때문에 좀 깁니다 ^^;; (스압 ㅁㄹㅈㅅ)

👩🏻‍🎨 디자인 시스템은 어떻게 파생됐을까요?

저는 UI라는 개념을 2018년쯤부터 딥하게 배우기 시작했는데요. 그 당시에는 '디자인 시스템'이라는 단어보다는 '스타일 가이드'라는 표현을 더 많이 썼던 것 같습니다.

또한, 과거에는 디자이너와 프론트엔드 사이에 '퍼블리셔'라는 전문 역할이 있었죠. 퍼블리셔 분들이 JSON, CSS, 마크업과 관련된 영역을 책임졌던 기억이 있습니다.

하지만 현대에 와서는, 프로덕트 디자이너가 이 역할까지 아우르게 되었습니다. 단순히 화면을 꾸미는 것만이 아니라,

• 방대한 컴포넌트를 시스템화할 수 있는지
• 그 시스템을 재사용할 수 있는지

이 능력이 디자이너의 중요한 자질로 평가되고 있습니다.

[그렇다면, 디자인 시스템이 필요한 상황은?]

• 스타트업이 성장해서 신규 팀원이 많이 투입되는 경우
• 다수의 디자이너가 공통 규칙 없이 일하는 팀
• 빠르게 다양한 A/B 테스트를 돌려야 하는 환경

디자인 시스템이 발생하게 된 계기는, 이렇게 여러가지 계기가 있는데요.

여태까지 제가 경험한 것중 가장 많은 사례는 바로 첫번째인 것 같습니다. 사실 작은 규모의 회사나, 스타트업에서는 이 프로덕트가 얼마나 성장할 수 있을지 모르기 때문에 디자인 시스템이 없거나, 혹은 있어도 아주 작은 규모로 존재하게 됩니다.

특히 이렇게 디자인 시스템이 없는 곳에서는, 어김없이 '하드코딩'이라는 단어가 등장하게 됩니다.

예를 들어, "#000000" 이라는 검정색을 'primary_black'으로 변수화하지 않았다면, 개발자는 모든 코드를 뒤져서 "#000000"을 수작업으로 수정해야 합니다.

컬러 하나 바꾸자고 수십, 수백 군데를 수정해야 하는 일이 생기는 거죠.

🤔 그렇다면 하드코딩이 뭔데?

하드코딩이란, 코드 안에 값(예: 폰트, 컬러, 크기 등)을 직접 박아 넣는 것을 말합니다.

📦 폰트 변경이 필요할 때 발생하는 하드코딩 문제

예를 들어, 처음 프로젝트 시작할 때 디자이너가 "Roboto" 폰트를 기본으로 제안했다고 해요. 개발자는 아무런 시스템 설계 없이, 그냥 코드마다 직접 폰트를 지정합니다.

body {
  font-family: 'Roboto', sans-serif;
}

h1 {
  font-family: 'Roboto', sans-serif;
  font-weight: 700;
}

.button {
  font-family: 'Roboto', sans-serif;
}

그러다가, 어느 날 디자이너가 요청합니다. 🧑🏻‍🔧 "저희 브랜드 리뉴얼해서 기본 폰트를 'Pretendard'로 바꿔야 해요!"

근데 개발팀에서는 이렇게 말합니다: ❌ "이거 바꾸려면 페이지 전체 다 뜯어야 해요... 시간이 너무 많이 걸려요."

왜? 폰트를 하드코딩했기 때문이에요.

수십, 수백 군데 폰트 코드가 다 따로따로 박혀 있어서, 일일이 찾아가면서 고쳐야 합니다. (그리고 실제로는 빠뜨리는 곳이 꼭 생겨요… 결국 QA 폭탄🥲)

🙆🏻‍♂️만약, 디자인 시스템이 있었다면?

처음부터 폰트를 이렇게 정의했겠죠.

:root {
  --font-family-base: 'Roboto', sans-serif;
}

그리고 실제 코드에서는 이렇게 정의를 내립니다.

body {
  font-family: var(--font-family-base);
}

h1 {
  font-family: var(--font-family-base);
  font-weight: 700;
}

.button {
  font-family: var(--font-family-base);
}

➡️ 이렇게 했으면, 변경할 때는** --font-family-base** 값만 수정하면 끝! 🎯

*만약 폰트를 Roboto에서 Pretendard로 바꾸고 싶다? *

--font-family-base: 'Pretendard', sans-serif;

👉 단 1줄로 전체 폰트 변경 완료. 아주 간단하죠?

☠️ 그래서, 명확하지 않은 디자인 시스템은 하드코딩을 발생시킨다.

여러 프로젝트를 해본 디자이너라면, 분명 앞의 경험을 해본적이 99.999% 있으셨을거라고 봅니다.

예를 들면 이런 경우인거죠. 디자인 시스템이 없는데, (당연히 하드코딩했겠죠?) 클라이언트가 300개의 화면에 대해 동일한 버튼의 UI를 바꾸고 싶다합니다. -> 🤦🏻‍♀️ 이거 대략 난감인거죠..

그래서, 결국 모든 UI는 개발과 정말 밀접하게 관련이 있다는 말을 하고 싶습니다.

• 화면에 배치한 수많은 UI -> 개발에서 API 명세서의 기준이 됨

• 컴포넌트 명칭 -> 코드에서의 "변수명"

이렇게 우리가 만드는 수많은 UI와, 명칭은 개발에서 가장 중요한 기준의 첫 시초에 해당합니다. 그래서 명확하지 않은 UI 기능과, 컴포넌트 명칭이 많아질수록 개발단계에서는 지레짐작하고 개발하기 때문에 결국 하드코딩(노가다코딩)과 수많은 QA,QC를 야기시킵니다. (윗물이 맑아야,,아랫물도 맑다..)

사용성을 고려한 UX/UI도 정말 중요합니다만, 나무가 아닌 숲을 보기 위해서는

• 사용자에게 더 빠른 업데이트를 제공하기 위해,

• 그리고 프로덕트의 유지보수를 위해,
• 팀원들간의 커뮤니케이션을 위해

스스로 just 디자이너가 아닌** "시스템 아키텍처"라고 생각**하는 것이 디자이너가 한단계 성장하는 발판이라고 생각이 듭니다. :) (사실 디자이너를 국문으로 풀면 설계자이기도 해요.)

💬 그래서 다음편은..

이 디자인 시스템을 어떻게 전달해야 개발팀과 잘 커뮤니케이션 할 수 있을지, 디자인 시스템과 - Token - JSON에 대한 개념과** 디자인 시스템을 잘 전달하는 방법, 그리고 피그마에서는 왜 디자인 시스템과 **관련된 기능을 넣었는지에 대한 유래를 모두 기재해보려합니다!

IT업계는 정말 빨리 바뀌지만, 그렇다고 알짜배기만 배운다고 해서 실무를 잘할 수 있다는 생각은 금물인 것 같습니다. 항상 동료들과 하는 토픽 중 제일 메인은, 결국에는 돌고 돌아 디자인의 개념, 그리고 CS의 개념에 대해 알아야 왜 현재 이런 프로세스가 나왔는지 알 수 있다는 부분인데요.

이러한 부분들을 천천히 탑재해간다면, 어느 순간 기획,디자인,개발을 어울러서 혼자 창업할 수 있지 않을까요? (하하) 자, 그럼 다음편으로 찾아오겠습니다. 읽어주셔서 감사합니다!

어제는 제가 오래 다녔던 스타트업에서 개발 컨퍼런스를 진행해서 다녀왔는데요. 저랑 같이 일했던 천재 서버 개발자 밥께서(닉네임이 bob) 이번 벨로그 주제를 추천해주셨습니다.

어제 서버 속성과외를 해주셔서, 배운 내용대로 3tier 아키텍처와, Nginx에 대한 개념을 쉽게 작성해보려합니다. 백엔드란.. 뭔가 배울수록 재밌는 것 같네요.. ^^

🍔 햄버거 가게로 이해하는 3-Tier 아키텍처!

이 구조를 실무에서 이해할 때, 음식점(햄버거 가게)으로 비유하면 아주 직관적으로 이해할 수 있습니다.

*💁🏻‍♀️ 맥날에서 배우는 3-Tier 아키텍처: *

• ** Web Server = 키오스크**, 고객(유저)이 와서 가장 먼저 마주하는 화면. 주문을 받고, 어떤 메뉴를 요청했는지 알바에게 전달함. 햄버거나 콜라 같은 정적인 건 바로 응답해주는 역할도 가능

• ** WAS = 알바 직원**, 실제로 햄버거를 조리하는 사람 (비즈니스 로직 수행)키오스크가 받은 주문서를 보고 “치즈버거 + 감자튀김 세트”를 만듦. 혼자선 안 되고, 재료가 필요함

• DB = 냉장고(창고), 모든 재료(데이터)가 저장되어 있는 곳. 알바는 이 창고에서 패티, 빵, 감자 등을 꺼내 조리함.

즉,고객이 주문📨 → 키오스크(Web 서버)가 받고 🖥️ → 알바(WAS)가 만들고🧑🏻‍🍳 → 재료(DB)에서 꺼내오는 구조입니다.🚛 요래 이해하니 쉽더군요.

🌀 그럼 Nginx는 뭐냐고요?

Nginx는 웹 서버이자 리버스 프록시 서버입니다. 맥날로 치자면? 👉 키오스크 시스템 + 주문 분산 관리자!라고 볼 수 있어요.

• 줄이 길어질 때 키오스크가 "2번 알바에게 넘겨요~" 라고 분산해서 주문을 넘김
• 너무 주문이 몰리면 순서를 정리하거나, 간단한 건 바로 응답 (ex. 콜라만 주문 등)
• 효율적으로 주방에 요청을 분산시켜주는 역할

☁️ 3-tier 아키텍처와 AWS와는 어떤 관계가 있을까?

우리가 사용하는 3-Tier 아키텍처는 AWS 안에서도 똑같이 구현됩니다.

예를 들어,

1) Web Server (Nginx) : AWS EC2에 설치된 Nginx or AWS ELB (로드밸런서)

*2) WAS *: AWS EC2 / ECS / Lambda 등으로 구성된 애플리케이션 서버

3) DB : AWS RDS (MySQL, PostgreSQL 등 관계형 DB 서비스)

즉, AWS를 쓰면 서버도, 데이터베이스도, 요청 분산도 전부 클라우드에서 관리 가능해요. 그래서 이름이 AWS Cloud라는 것~

디자이너 입장에서 AWS까지 연결해서 이해해보자면,

• "이 요청 어디서 터졌지?" → Web 서버(Nginx)냐, WAS냐, DB냐 판단 가능
• "S3는 어디 들어가?" → 정적 파일 저장소로 Web 서버보다 더 빠르게 처리
• "CloudFront는?" → S3 + Nginx처럼 정적 콘텐츠를 더 빠르게 전송하는 CDN 역할

이렇게 이해해볼 수 있습니다.

📦 디자이너가 이걸 알아야 할 이유는?

• "왜 첫 로딩은 빠른데 로그인 누르면 느려요?" → 아하, WAS가 바쁜 거구나!
• "왜 서버 터졌대요?" → Nginx에서 분산을 못 해줘서!
• "왜 이미지는 바로 뜨는데 버튼 반응은 늦어요?" → 정적 파일 vs 동적 로직 차이!

라고 이해할 수 있습니다. 다양한 에러케이스를 심도있게 이해할 수 있다는거죠! 👊🏻

💡 이 개념을 안다면

API 흐름이나 에러코드(5xx)에 대한 이해도가 높아지면서, 디자인 설계할 때 어디서 병목이 생기는지 예측할 수 있어요. 특히 유저에게 앞에 설명한 에러 케이스를 보여주는 것은 굉장히 치명적이기 때문에, 백엔드에 대한 이해는 필수랍니다. 📓

✍️ 정리!

오늘 배운 내용대로 정리하자면, 3-tier 아키텍처는 Web server / WAS (Web application server) / DB (Data base)로 구분되며, Web server는 요청을 받고, WAS 실제 로직을 처리하고, DB는 데이터를 저장해주고 조회해주는 냉장고 같은 역할이라고 보시면 됩니다!

🔥 마무리!

오늘은 출근하면서 써봤는데요. 백엔드는 뭔가 그 구조만 파악하면 나머지랑 연관되면서 이해하기 쉬운 것 같습니다. 하핫 이게 백엔드의 매력인가요 . . ^^ 다음에도 쉽게 배우는 백엔드편으로 돌아오겠습니다. 제 서버 스싱이신 밥 ,, 샤라웃 ,,🍚🍚

그럼 다음 편에서 또 만나요! (불금 즐기러갈거셈ㅎㅎ)

안녕하세요! 프로덕트 디자이너 메리입니다. 비가 추적추적 오니 막걸리 한사바리 하고 싶은 날이군요.

오늘은 디자이너/기획자도 한 번쯤은 들어봤을 AWS에 대해 아주 기초적인 개념만 콕 집어 정리해보려 합니다. AWS 안에는 정말 많은 기능이 있는데요. 이 기능을 잘 쓰면 주먹밥, 흩어지면 볶음밥이랍니다.(오늘도 피곤해서 걍 아무말이나 뱉는중)

☁️ AWS란?

Amazon Web Services의 줄임말로, 말 그대로 아마존이 제공하는 클라우드 컴퓨팅 서비스입니다. 우리가 흔히 생각하는 '서버'를 직접 사서 관리하는 게 아니라,AWS라는 거대한 공간 안에 있는 컴퓨터(=서버)를 빌려서 사용하는 구조에요.

쉽게 말해:

🧍‍♀️옛날: 회사에서 직접 서버 컴퓨터를 사서 사무실에 설치함 ☁️요즘: AWS에서 서버를 몇 개 클릭만으로 임대함 (필요할 때만 사용료 지불)

라고 볼 수 있습니다. 예전에 전산실 ? 서버실 사진 보셨을련지.. (제가 9n년생이라 전 교과서에서 많이봤어요) 요즘은 세상이 좋아져서 AWS에서 클릭 몇번으로 서버를 빌릴 수 있다는 사실~

1. EC2 (Elastic Compute Cloud)란?

EC2는 AWS에서 가장 기본이 되는 가상의 서버에요. 디자이너 입장에서 EC2는 이렇게 이해하면 좋아요 : 우리가 디자인한 서비스를 실제로 "돌아가게 하는 컴퓨터", 로그인 기능, 결제 기능 등 서버 로직이 돌아가는 공간이라고 볼 수 있죠. EC2를 하나 만든다는 건 = 서버 한 대 빌렸다는 뜻이에요.

2. S3 (Simple Storage Service)

S3는 이미지, 영상, 파일 같은 것들을 저장하는 저장소에요. 우리가 업로드한 유저의 프로필 사진, 배너 이미지, 첨부파일 등을 저장할 때 사용하는 곳입니다. 디자인 시스템에 들어가는 이미지들, 유저가 업로드한 사진이나 첨부파일,앱/웹에서 쓰이는 정적 파일들(css/js 등)이 여기에 들어가죠.

3. 인스턴스란?

EC2를 만들면 생기는 실제 서버의 '작동 중인 상태'를 의미해요. 예시로, 컴퓨터를 샀는데, 전원을 안 켜면 그냥 기계죠? EC2라는 서버를 만들고, 작동시키면 그게 "인스턴스"가 되는 거예요! 인스턴스는 필요할 때만 켜고, 안 쓸 땐 꺼서 비용을 아낄 수도 있어요.(= 그래서 개발자들이 테스트용 인스턴스는 다 꺼놓자~ 같은 얘기 자주 함!)

🧪 스테이징 / 개발 / 상용 서버는 뭐가 다른 거야?

우리가 말하는 "서버 환경"은 AWS 인스턴스를 어떻게 나눠서 관리하느냐에 따라 달라집니다.

• 개발 서버 (Dev): 개발자가 새 기능을 마음껏 테스트하는 곳

• 스테이징 서버 (Stage): 실제 운영 환경이랑 최대한 비슷하게 구성해서 QA나 시연을 해보는 곳
• 상용 서버 (Prod): 진짜 사용자가 접속하는 운영 서버! 실수하면 사고남!

이 각각의 환경도 결국 AWS 인스턴스로 만들어져요. 같은 EC2더라도 목적에 따라 나눠서 관리하는 거죠.

디자이너 입장에선,

🙋🏻‍♀️"이 디자인, 지금 어디에 올라간 거죠?" 🙆"이거는 스테이징이에요, 아직 프로덕션은 아님!" 이런 대화를 이해할 수 있게 되는 것만으로도 협업이 훨씬 수월해집니다.

🗃️ RDS (Relational Database Service)

RDS는 AWS에서 제공하는 데이터베이스 서비스인데요. RDS는 우리가 아는 MySQL, PostgreSQL 같은 데이터베이스를 AWS에서 쉽게 셋업해서 쓸 수 있도록 도와주는 서비스예요.

• 회원가입한 유저 정보
• 유저가 쓴 게시글, 댓글, 좋아요 등의 데이터

-> 이런 것들이 모두 DB(데이터베이스)에 저장되는데, 그걸 쉽게 구축하고 관리할 수 있게 해주는 게 RDS예요.

디자이너 입장에서 이걸 알면, "어떤 데이터가 어디 저장되는지", "이건 프론트에서 저장되는 게 아니구나" 같은 흐름을 이해하는 데 도움이 됩니다!

⚙️ Lambda (람다)

서버 없이도 특정 코드를 실행할 수 있는 기능! = 서버리스라고들 하는데요. 어떤 동작을 자동으로 실행해야 할 때, 굳이 EC2를 돌리지 않아도 되는 방식이에요.

예시)

• 📨 사용자가 가입하면, 환영 이메일 자동 발송
• 💸 결제 완료 시, 관리자에게 알림 보내기

이런 걸 "이벤트 기반으로 트리거 실행"하는 구조인데, 그때 람다 함수를 만들어두면 서버 없이도 필요한 작업이 자동으로 실행돼요!

디자이너 입장에서, 특정 액션이 자동으로 이어지는 로직(UI→알림 등)을 구성할 때 람다 개념을 알면 흐름이 훨씬 명확해집니다.

🔍 그 외에 개발에서 자주 쓰는 AWS 기능은?

• CloudFront : S3에 저장된 이미지나 정적파일을 빠르게 전송해주는 CDN 서비스

• Route 53 : 도메인 주소 관리 서비스 (ex. marykim.design)
• CloudWatch : 서버 로그/모니터링 툴, 장애 감지할 때 씀
• IAM : 권한 관리 기능 (누가 S3를 접근할 수 있는지 등 설정)
• ECS / EKS : 대규모 서비스 운영 시 컨테이너 단위로 배포하는 방식

이 중에서 디자이너와 가장 관련 있는 건 S3, CloudFront, IAM, CloudWatch 정도예요!

특히 IAM 기능의 경우, 피그마의 권한 초대와 굉장히 유사한데요. AWS 계정을 누구에게나 다 알려줄 수 없으니 (보안이슈) IAM 계정을 만들고, 권한을 부여해서 같이 작업할 개발자를 초대하는 방식이라고 보면 될 것 같습니다.

💡 디자이너가 AWS를 알아두면 좋은 이유

1) 이미지 저장 방식이나 URL 구조를 이해할 수 있습니다. 2) 서버와 클라이언트의 구조를 감 잡을 수 있습니다. (중요!) 3) 트래픽이 몰릴 때 무슨 일이 벌어지는지 상상할 수 있어요. 4) 에러코드(5xx)가 왜 생기는지도 연결해서 이해돼요. 5) QA 단계에서 "이건 dev, 이건 prod입니다" 같은 말을 듣고 당황하지 않을 수 있어요.

마지막으로, 디자인 시스템에서 어떤 리소스가 어디에 저장되고, 누가 접근 가능한지 이해할 수 있어요. 특히나 협업할 때, 디자인이 실제로 배포되는 환경을 아는 디자이너는 지존입니다.

큰회사의 경우 자본이 많기(?) 때문에 막대한 서버비용에 대한 감당이 가능하지만, 스타트업이나 규모가 작은 회사의 경우 서버구조를 잘 짜야 서버비용이 많이 안나오기 때문에, 기획과 디자인단에서 서버비용을 고려한 설계가 거의 필수라고 볼 수 있습니다.

🔥 서버비용을 고려하지 않은 디자인 UI 예시

1. 무한 스크롤 + 썸네일 이미지 과다 노출

📌 문제: 홈 화면에 수십 개 썸네일 + 고화질 이미지 무한 로딩 → S3 + CloudFront 트래픽 폭증 🧾 예시: “사용자 피드에 이미지 30개가 한 번에 뜨게 해주세요~!” 💸 결과: CloudFront 요금 급상승, 특히 이미지가 고화질일수록 비용도 같이 늘어남

2. GIF 배너, 영상 자동재생

📌 문제: 첫 화면 진입부터 영상 or GIF 배너 자동재생 → 사용자 당 수십 MB 데이터 요청 발생 🧾 예시: 메인에 ‘움직이는 감성 배너’ 넣고 싶다며 매번 5초짜리 영상 업로드 💸 결과: 트래픽 요금 + CDN 과금 폭발 → 특히 모바일 사용자가 많은 서비스일수록 치명적

3. 검색/필터 기능 과도하게 나눠진 구조

📌 문제: 필터를 변경할 때마다 백엔드 API 여러 번 호출 (Ex. 색상별 + 사이즈별 + 별점정렬) 🧾 예시: “컬러칩 누를 때마다 실시간 반응 보여주세요~!” 💸 결과: EC2 인스턴스 부하 + RDS 호출 과다 → 서버 비용 상승 + 성능 저하

4. 파일 업로드 무제한 UI

📌 문제: 유저가 첨부파일 50개, 100MB 영상도 막 올릴 수 있는 UI 제공 🧾 예시: “유저가 사진 많이 올리면 좋잖아요~!” / “파일 크기 제한요? 그거 있으면 불편해요!” 💸 결과: S3 스토리지 비용 상승 → 특히 사용자가 많을 경우 금방 수백 GB 단위로 용량 차지

5. “좋아요”, “댓글”에 실시간 반응을 주는 구조

📌 문제: 모든 유저에게 알림 + 실시간 숫자 갱신 → Lambda 또는 WebSocket 과부하 💸 결과: 기능 하나에 이벤트 트리거가 과도하게 발생 → Lambda 실행 횟수 증가로 과금↑

💡 그래서 디자이너는? “데이터가 언제, 어디서, 얼마나 불러와지는지”를 고려한 UI 설계가 필요합니다. 또한 클라이언트에서 미리 캐싱해둘 것 vs 서버에서 다시 호출할 것 구분하는 것도 필요하죠. 그래서 UI를 설계할 때, “한 번의 액션이 얼마나 많은 서버 리소스를 부를 수 있을까?” 생각해보는 것이 중요합니다.

예시를 보면 인스타그램, 무신사 같은 서비스가 생각나지 않나요? 이 서비스들은 굉장히 막대한 서버비용이 나올 수 있다고 볼 수 있죠. 하지만 우리 앱에 이 기능들을 넣는다면,, 바로 파산핑 되는겁니다~ (개발자들이 안된다고 하는 이유는 기능 구현이 힘든 것도 있지만, 저 기능을 넣으면 막대한 서버비용과 리소스가 발생하기 때문인거시죠)

👊🏻 마무리!

이번 편에서는 AWS 중에서도 자주 언급되는 EC2, S3, RDS, Lambda, 그리고 인스턴스 개념을 가볍게 정리해봤는데요. 거기에 실무에서 자주 듣는 스테이징/상용 환경 개념과, 개발자들이 자주 쓰는 AWS 기능들도 살짝 소개해봤습니다. 어때요. 그렇게 어렵지 않지 않나요?

다음엔 AWS 배포 구조나, CloudFront를 중심으로 한 성능 최적화 개념도 풀어보도록 하겠습니다. 제 글이 여러분들께 도움이 되길 바라며.. 서버비용을 아낄 수 있는 디자이너가 함 되보자구요? (저도 예전에 AWS 세팅 잘못해서 파산핑될뻔함;;;)

아무튼. 읽어주셔서 감사합니다. 다음 편에서 또 만나요!

오늘의 주제는 코드 리팩토링의 개념과, 디자인 시스템의 연관관계를 써보려합니다. (옥시싹싹 짤과 연관된 내용입니다.)

저 같은 경우엔 연차가 쌓이다보니 자주 하는 일들이 새로운 기능을 개발하기보다, 기존 서비스에 대한 유지보수 작업을 하게 되는 경우가 굉장히 많은데요. (오히려 신입일 때 서비스 런칭을 더 많이한거 같음..)

개발자에겐 유지보수 작업에 꼭 필요한 "코드 리팩토링" 그리고 디자이너들이 주기적으로 하는 하는 "디자인 시스템 정리" 이 작업은 아 다르고 어 다르지만, 유지보수 측면에서 사실 둘 다 같은일을 하고 있는 거라는 생각이 들어요.

자, 그럼 코드 리팩토링은 뭐고,(이게뭐고) 왜 필요할까요?

1. 코드 리팩토링이란?

코드 리팩토링은 기능은 그대로 유지한 채, 내부 코드의 구조를 더 깔끔하게, 읽기 좋게, 유지보수하기 쉽게 다듬는 작업입니다. 주로 코드의 가독성을 높이고, 유지보수를 편하게 하는 작업입니다.

예를 들어 기능은 잘 동작하지만 변수명이 혼란스럽거나 중복된 함수가 많을 때, 에러는 없지만 개발자 본인도 다시 보면 어지러운 코드들... 이런 걸 정리하는 거예요.

리팩토링은 버그 수정이나 새로운 기능 개발과는 다르지만, 결국 전체 개발 생산성을 크게 높여주는 핵심 작업입니다.

특히 IT업계의 경우 다른 업계와 달리 근속연수가 짧고, 처음에 개발한 멤버와 나중에 유지보수하는 멤버가 다른경우가 굉장히 많기 때문에, 다음 작업자를 위해서 알잘딱깔쎈 클린코드를 쓰는게 매너(?)인 것 같아요.

피그마로 치자면 기능 구분없이 한 페이지에 UI 300개를 한번에 냅다 박아버리는 디자이너가 있는 반면, 디자인 시스템 / 기능 01 / 기능 02 이런식으로 잘 구분해놓은 디자이너가 있듯 말이죠. 당연히 후자가 최고겠죵?

2.리팩토링에 사용하는 대표적인 툴들

리팩토링을 할 때는 코드 품질 진단 도구들이 큰 도움이 됩니다. 예시로는,

• SonarQube : 코드 스멜, 중복, 버그 가능성 등 자동 감지해주는 정적 분석 도구

• ESLint / Prettier : 자바스크립트/타입스크립트 코드 스타일 자동 정리
• CodeClimate : 코드 복잡도, 테스트 커버리지까지 종합 관리
• GitHub Actions 와 CI 도구 : 리팩토링 이후 테스트 자동화와 배포까지 연계

이렇게 있는데요. 이런 툴을 통해 '문제 있는 코드'를 빠르게 인지하고, 팀원끼리 리뷰 기준도 통일할 수 있어요. SonarQube는 회사 개발자분께서 쓰시는걸 봤는데, 이야 이거 기가 맥히더군요. 여러분도 써보시길 바랍니다.

3.디자이너의 파일 정리가 코드 품질에 영향을 준다고요?

네. 정말 그렇습니다. 디자이너의 컴포넌트 정리 상태, 버전 관리 방식, 핸드오프 툴 사용법은 개발자가 어떤 구조로 코드를 짤지에 영향을 줍니다. 예를 들자면,

• Figma 파일 내에서 버튼 컴포넌트가 정리되어 있고, 상태별로 Variants가 잘 구성돼 있다면? → 😍 개발자는 이를 기준으로 디자인 시스템 컴포넌트를 만들고, 중복 없이 코드화 가능

• 반대로, 디자이너가 매 화면마다 버튼 스타일이 다르고 명명도 제각각이라면? → 🤬 개발자는 하나의 컴포넌트를 만들 수 없고, 매 화면마다 반복된 코드가 생기고 유지보수도 힘들어집니다.

이건 코드로 보면 마치 매 기능마다 함수와 변수명이 다르게 뒤섞여 있는 느낌과 비슷해요.

또한, 디자이너가 화면별로 버전관리를 잘 관리하지 않으면 개발자는 어떤 디자인이 최신인지, 어떤 브랜치에 반영해야 하는지 혼란스러워지기 쉬워요.

🔁 그래서 실제로 디자이너의 디자인 파일 관리법 = 개발자의 Git 브랜치 전략과 굉장히 닮아 있습니다.

• '메인 디자인 시스템 = main branch'
• '특정 기능 UI 개선안 = feature/...'
• 'QA 결과 반영 = hotfix/...'

이런 구조를 의식하고 디자인 파일을 정리하면, 협업 효율은 상상 이상으로 올라갑니다. 나중에 Github에 대한 개념도 작성할 예정인데요. Github에서 어떻게 코드를 관리하는 지를 알면 디자인 파일도 완즈이 깔끔하게 정리할 수 있다는 4실 !

4.리팩토링을 하지 않으면 어떤 문제가 생길까요?

✅ 신규 기능 개발 시 기존 코드 이해가 어려워서 생산성 저하 ✅ 버그가 발생했을 때 원인 파악이 어려움 ✅ 새로운 팀원이 온보딩할 때 진입장벽이 높아짐 ✅ 디자인이 바뀌었을 때 관련된 모든 컴포넌트를 수정해야 함 (재사용 불가) ✅ 코드 중복 증가 → 파일 커지고, 테스트 어려워지고, 수정 충돌까지

즉, 리팩토링을 하지 않으면 기능은 계속 추가되지만 구조는 점점 무너지는 상황이 되는 거예요. 개발자 입장에서는 '건물이 멀쩡해 보이지만 배선이 엉망이라 나중에 아무 데서나 불 나는 집' 같은 상태죠. 집 컴퓨터 보면 본체 뒷면에 전선 꼬여있어서 풀생각을 안하죠? 그것과 비슷합니다.

마무리 !

리팩토링은 단지 개발자만의 일이 아닙니다. 디자이너가 컴포넌트 단위로 UI를 설계하고, 정리된 파일을 공유하며, 명확한 버전 구조를 유지한다면, 개발자에게는 그게 곧 깨끗한 설계서가 됩니다.

디자인과 코드의 구조는 연결돼 있어요. 서로 깔끔하게 정리하면, 결국 유지보수는 덜 힘들고 팀은 더 빠르게 움직일 수 있습니다.

제가 하는일이 유지보수가 많다보니.. 어떻게 하면 이 유지보수를 퀵하게 끝낼 수 있을까.. 하는 고민에 이런 주제로 찾아오게 되는데요. 다음에는 버전관리의 중요성, 그리고 Github 기능 등등으로 찾아오려합니다!

유지보수 하는 모든이들에게 도움이 됐길 바라며.. (도움이 됐다면 마라탕 한그릇 사주십시오)

그럼 20000

(연어가 강을 거꾸로 올라가듯 .. 기획을 거꾸로 가면 서버라는 뜻의 짤입니다.. 근데 곰 좀 무서운듯 ㄷㄷ)

⸻

프로덕트 기획은 단순히 화면을 구성하고 기능을 나열하는 일이 아니죠. 사용자에게 도달하는 서비스의 흐름을 논리적으로 정의하고, 기능이 실제로 작동할 수 있도록 설계하는 것이 핵심인데요. 이 과정을 구조화하려면 백엔드에 대한 최소한의 이해는 정말 필수입니다.

왜냐하면 우리가 설계하는 거의 모든 화면은 결국 데이터를 “어떻게 저장하고”, “언제 불러오고”, “누가 수정/삭제할 수 있는지”에 대한 흐름으로 만들어지거든요. 이 흐름을 움직이는 심장 같은 존재가 바로 백엔드입니다.

⸻

백엔드를 모르면 이런 일이 생깁니다 💥

1. 기획자는 “이거 리스트만 쭉 보여주면 되죠~“ 했는데,

백엔드는 “리스트가 300개인데… 페이지네이션 안 하면 터집니다” (= 한 화면에 다 나오게 만들었다가 서버와 브라우저 둘 다 사망…)

2. 디자이너는 슬쩍 “좋아요” 기능 넣었는데..

백엔드는 “유저별 좋아요 상태 저장하고, 중복 방지하고, 좋아요 수 카운트하고… 할 게 많아요” (= 버튼 하나가 DB 테이블 하나 생성되는 순간)

3. 화면 흐름은 그럴듯한데,

프론트는 “API를 3번 호출해야 돼요… 이거 무겁고 느려요…”

이런 일, 다들 한 번쯤 겪어보셨죠? 기획자, 디자이너, 개발자 모두 고개를 끄덕이게 되는 대화입니다.

⸻

기획자는 왜 백엔드를 알아야 할까?

기획자는 기능을 나열하는 사람이 아니라 서비스의 데이터 흐름을 설계하는 사람이에요. 아래 상황에서 백엔드 이해는 큰 힘을 발휘합니다.

• 회원가입 플로우를 설계할 때, 입력한 데이터가 어떤 API를 통해 어디에 저장되고, 토큰은 어떻게 발급되고, 이후 인증은 어떤 방식으로 유지되는지 등등.

• 마이페이지나 주문 내역 같은 화면에서 어떤 데이터를 어디에서 가져오는지, 어떻게 업데이트할 수 있는지를 알고 있다면 훨씬 더 구체적인 기획이 가능합니다.

• 그리고 무엇보다도, 서버에서 가능한 일인지, 시간이 오래 걸리는 일인지, 실시간으로 처리해도 되는지 이런 기준을 잡는 눈이 생깁니다.

⸻

디자이너도 백엔드를 알면 좋은 이유

예쁘게 만드는 걸 넘어서서, 동작 가능한 디자인을 하려면 백엔드와 데이터 흐름에 대한 이해가 필요해요.

• 이 버튼을 누르면 어떤 API가 호출돼?
• 이 데이터는 새로고침하면 바뀌는 거야? 아니면 고정된 거야?
• 이 유저, 이걸 삭제할 권한은 있는 거야? (← 진짜 중요!)

이걸 알고 설계하면 디자인 단계에서부터 개발자와의 커뮤니케이션이 훨씬 부드러워지고, 불필요한 재작업도 줄어들어요.

특히 에러 설계! 이거 진짜 다들 마지막에 급하게 팝업 만들잖아요? 근데 실제로는 400, 403, 500 등 상황별로 에러 UI를 미리 설계해두면 디자인 시스템에도 깔끔하게 정리되고, 사용자 경험도 좋아집니다.

⸻

사례: 백엔드를 알면 이렇게 달라집니다.

1. 리뷰 삭제 버튼, 누구한테 보여줄까?

• 내가 쓴 리뷰에만 삭제 버튼 보여줘야 하는데, 이걸 설계 단계에서 생각 못 하면 모두에게 보이는 불상사가 발생합니다. → 백엔드에서 권한 체크 필요!

2. 검색창에 필터 8개 넣었는데, 서버는 3개밖에 못 받아요…

• 프론트는 화려하게 만들었는데 백엔드는 “정규화된 값만 받을 수 있어요…”라고 할 수도 있어요. ex) ‘색상별’, ‘사이즈별’, ‘별점순 정렬’ 등 생각보다 어렵습니다!

3. 등급별 혜택 설계할 때 무리수 두면…

• 실시간 등급 산정은 서버 리소스 많이 먹어요. 매일 밤 12시에 계산되게 설계하는 게 낫기도 해요. 이걸 알고 있으면 UX 설계도 더 똑똑해질 수 있죠.

4. 에러 시나리오 미리 설계하면 멋진 디자이너로 인정받음

• 예: 서버 과부하로 응답이 안 올 수 있음 → “일시적인 오류가 발생했어요. 다시 시도해주세요” + 재시도 버튼 설계 (이거 미리 해두면 ㄹㅇ 알잘딱깔센 디자이너 됩니다.)

5. 화면 로딩은 다 같은 로딩이 아니다

• API 여러 개를 순차 호출해야 할 때는 전체 로딩보다 구역별 스켈레톤 로딩이 낫고, 이걸 고려해서 디자인하면 서비스 속도 체감이 확 좋아져요!

⸻

마무리 ✨

요약하자면 이렇습니다: 기획의 시작은 데이터 흐름이고, 그 중심엔 백엔드가 있다.

백엔드를 이해하면 기능 누락이 줄고, 개발과 디자인 사이에 오해도 적어지고, 결국엔 더 나은 사용자 경험으로 이어집니다.

꼭 코드를 짜지 않아도 괜찮아요. 하지만 적어도, 우리가 그리는 화면이 서버에서는 어떤 식으로 “돌아가는지” 정도는 알면 정말 큰 차이를 만듭니다.

그럼 다음 편에서 또 만나요!

안녕하세요. 프로덕트 디자이너 메리입니다! 오늘은 우리의 혈압을 오르게 만드는 구간.. 바로 "ERROR" 케이스와 HTTP 오류 코드에 관한 부분입니다. (짤은 일부러 감성짤로 넣었어요 하.하)

대부분 디자이너들이 디자인 시스템을 설계할 때 에러 케이스를 명목상 넣는 경우가 많은데요. 예를 들면 유효성 검사에 대한 대략적인 예시 UI와, 에러 팝업을 먼저 만들고 -> 나중에 갑자기 별에별 에러 핵터짐 -> 오 싓 이 화면에 왜 이상한 숫자가 나와!! 이런 순간이 많다는 거죠 🥲

디자이너가 CRUD나 API 호출 흐름을 이해하지 못하면, 예를 들어 사용자에게 삭제(Delete) 권한이 없는데 버튼은 만들고 팝업도 안 띄워놓는 상황이 발생합니다. 자, 그러면 어떻게 해결하면 좋을까요?

1)먼저 에러케이스를 나눠보자

그래서 우리가 에러 팝업을 만들기 전에! 어떤 시나리오에서 어떤 에러가 발생할 수 있는지, 유효성 검사 실패인지? (ex. 비밀번호 미입력) 서버 자체 오류인지? (ex. DB 터짐) 이걸 구분해서 기획부터 반영해야 하는 거예요.

에러케이스는 이렇게 나눠봅시다. 👩🏻‍🏫

*1) 클라이언트 유효성 검사 실패 (Validation) *→ 사용자 입력값 누락, 형식 오류 등 (ex. 이메일 형식이 잘못되었어요)

*2) 권한 부족 / 잘못된 요청 (403 / 404 등) *→ 없는 페이지 요청, 권한 없는 기능 시도 등

*3) 서버 내부 오류 (500번대 에러) *→ 서버 터짐, API 잘못 연결, DB 터짐 등등

[대표적인 서버 에러코드 사례]

• 400 Bad Request: 요청 자체가 잘못됨 (ex. 파라미터 누락)

• 401 Unauthorized: 로그인 안 된 상태에서 인증 필요한 요청함

• 403 Forbidden: 권한 없는 기능에 접근했을 때

• 404 Not Found: 요청한 페이지나 리소스를 찾을 수 없을 때

• 500 Internal Server Error: 서버 내부에서 알 수 없는 에러 발생

• 503 Service Unavailable: 서버가 과부하로 인해 잠시 사용할 수 없음

2)에러케이스를 고려하지 않으면?

그리고 만약 이 에러코드를 디자이너가 고려하지 않으면? 개발할 때 기본 시스템 메시지로 처리해버려서 '알 수 없는 에러가 발생했습니다. 코드: 5001234' 같은 이상한 문구가 그대로 웹사이트에 뜰 수 있어요! 이거 진짜 자주 봤죠? 미리 정리하면 아주 좋답니다.

3)에러케이스, 디자인 시스템으로 CTRL+C/V 하기!

팝업 디자인은 "에러의 종류 + 문구 + 행동 버튼" 조합으로 시스템화해두면, 일일이 새로 만들 필요가 없어요. 예를 들자면,

• 에러 타입: validation / forbidden / not found / server error

• 문구: 상태에 따라 바인딩
• 버튼: 확인 / 다시 시도 / 취소

요렇게 템플릿화하면 디자인시스템에서도 효율적으로 관리 가능!

💡 참고로 토스(Toss)는 에러 상태를 아주 잘 설계한 케이스예요!에러 상황에 따라 문구도 친절하고, 사용자 행동을 고려한 대체 경로(예: '홈으로 돌아가기', '문의하기')도 잘 안내해줘요. 디자이너 입장에서 참고하면 좋습니다.

🧙🏻 결론 : 에러케이스를 먼저 설계하자!

결론은, 에러 디자인은 단순히 예쁘게 팝업 만드는 게 아니라, 기능 흐름 속에서 발생할 수 있는 시나리오를 먼저 생각하고 설계해야 한다는 점! 그리고 그 기반엔 API, CRUD, HTTP 개념들이 꼭 같이 따라붙는다는 사실!

이런 걸 생각하면서 작업하면 '에러 처리까지 완벽한 프로덕트'를 만들 수 있습니다.그럼 다음 편에서 또 봐요 아녕~~

오늘은 디자이너가 알아두면 개발자와 소통이 정말 편해지는 'API'에 대해 함께 알아보려고 합니다! 회의할 때 API라는 단어 정말 많이 들어보시지 않았나요? 자, 오늘도 드가봅시다.

API의 의미에 대하여

API는 'Application Programming Interface'의 약자이며, 쉽게 말해 서로 다른 소프트웨어가 데이터를 주고받을 수 있도록 만들어진 연결 통로라고 생각하면 됩니다. 우리가 배달 앱에서 주소를 입력하면 자동으로 지도가 나타나는 것도 API 덕분이에요!

🔗API를 '엮는다'는 건 무슨 의미일까요?

개발을 진행할 때 "API를 엮는다"는 표현을 쓰는데요, 이건 여러 서비스나 데이터를 연결해서 하나의 기능으로 만드는 걸 의미해요. 예를 들어, 네이버 쇼핑에서 상품을 검색할 때, 네이버 자체 상품뿐만 아니라 다른 쇼핑몰 상품 데이터까지 함께 불러오는 것도 API를 엮어서 사용하는 사례입니다.

간단하게 크롬과 크롬 확장프로그램으로 예시를 들어보려 하는데요. 크롬이 하나의 큰 애플리케이션(서비스)이라면, 크롬 확장 프로그램은 외부에서 제공하는 추가적인 기능(서비스)이죠.

즉, 크롬(본체)과 확장 프로그램(추가기능)을 연결하는 방식을 "API를 엮는다"라고 비유하면 아주 이해하기 쉽습니다. (참 쉽죠?)

예를 들어, 크롬이 기본적으로 없는 기능을 확장 프로그램을 통해 추가하듯, 우리 서비스에 없는 기능을 외부 API를 이용해서 쉽게 추가하는 거라고 보시면 됩니다.

디자이너가 만든 UI와 API는
어떻게 연결될까요?

디자이너가 UI를 설계하면, 개발팀은 그 UI를 실제로 동작하게 만들기 위한 API를 준비합니다. 예를 들어, 디자이너가 소셜 로그인 기능을 만들기 위해 카카오톡 로그인 버튼이나 구글 로그인 버튼을 설계하면, 프론트엔드 개발자는 버튼 클릭 시 카카오톡 또는 구글 로그인 API를 호출하는 코드를 작성합니다. 백엔드 개발자는 이 호출에 따라 로그인 정보의 유효성을 확인하고 사용자 정보를 전달하는 API를 만들어 프론트엔드와 연결합니다.

UI를 만든 후 개발은 어떻게 진행될까요?

디자이너가 UI를 설계한 후에는 프론트엔드와 백엔드 개발자가 함께 'API 명세서'를 작성합니다. 이 API 명세서는 어떤 데이터를 주고받을지, 요청 방식은 어떤지, 응답 데이터는 어떻게 구성될지 상세히 기록하는 문서입니다. 이 과정을 통해 디자이너가 만든 화면을 실제로 작동하게 만드는 구체적인 방법을 명확하게 정리하는 것이죠.

API 명세서는 요렇고롬 생겼는데요. 대부분 노션 혹은 구글 스프레드시트를 통해 관리하시는 듯 합니다. 간단하게 이렇게 들어가는데요.

[API 명세서 항목]

1) 기능명(ex.소셜로그인) 제곧내. 첫번째로 기능명이 들어갑니다.

2) HTTP 메소드 (GET/POST/PUT/DELETE) 저번시간에 배운 개념입니다. 쉽게 말하자면 데이터를 가져오고(GET),생성하고(POST), 수정하고(PUT), 지우고(DELETE) 중에 어떤 항목이냐! 라는 뜻입니다.

*3)요청 파라미터 (Request Parameters) *API를 호출할 때 전달하는 데이터의 항목과 형식입니다. 인스타그램으로 예시를 들자면,유저가 로그인을 할 때 이렇게 데이터가 전달된다고 예시를 들어볼게요.

• 사용자 ID (user_id) : 123456789
• 인증 토큰 (auth_token) : abcdefg12345

*4)응답 데이터 (Response Data) *그러면 요청을 보냈으니, 데이터가 응답해줘야겠죠? 이 응답 데이터는 API 호출 후 반환받는 데이터의 항목과 형식을 뜻합니다.

• 사용자 이름: "mary_kim"
• 팔로워 수: 200
• 팔로잉 수: 150
• 프로필 이미지 URL: "https://example.com/profile.jpg"

이 로직을 파악하면 API 호출도 바로 이해할 수 있습니다! API 호출이란 특정 기능이나 데이터를 요청하는 과정을 뜻하는데요.

예를 들어, 사용자가 ‘내 주문 목록’을 클릭하면 프론트엔드는 '주문 목록 API'를 호출하고, 서버는 이 요청에 따라 주문 목록 데이터를 반환해 줍니다.

이처럼 데이터를 요청하고 응답받는 과정을 ‘API 호출’이라고 합니다.

실제 서비스에서 사용하는 API 사례

우리가 자주 이용하는 쿠팡 사이트를 예로 들면, 결제를 할 때 KG 이니시스 결제 API가 호출되어 결제 정보를 주고받습니다. 또 카카오톡 앱에서는 카카오페이 API를 통해 송금이나 결제를 빠르게 처리할 수 있습니다. 이처럼 많은 서비스가 API를 통해 외부 서비스와 데이터를 연결하고 있어요.

API가 존재하지 않으면 개발이 어려운 기능은?

디자이너 입장에선 간단해 보이지만 개발하기 까다로운 기능들도 있습니다. 예를 들어, 이미지에서 특정 물체나 사람의 얼굴을 인식하거나 음성 인식으로 앱을 조작하는 기능은 이미 만들어진 API가 없다면 개발이 매우 어렵고 비용도 많이 들어갑니다. 이런 기능을 계획할 때는 미리 API가 있는지 반드시 확인해 봐야 해요.

디자이너가 API를 활용할 수 있는 실제 사례

디자이너가 제품에 특정 기능을 넣고 싶을 때, 직접 모든 기능을 개발하는 대신 기존에 제공되는 API를 활용할 수 있습니다. 예를 들어, 제품에 지도 기능을 넣고 싶다면 카카오 지도 API를 활용하면 됩니다. 디자이너는 지도 화면을 설계하고, 개발팀과 API 연동에 대해 명확히 소통하면 훨씬 빠르고 효율적으로 기능을 구현할 수 있죠.

디자이너가 API를 알면 좋은 이유

디자이너가 API와 HTTP 메소드를 알면, 화면 설계나 기능 기획이 훨씬 구체적이고 효율적이게 됩니다. 예를 들어, 버튼이나 메뉴 하나를 설계할 때에도 API에서 어떤 데이터를 주고받는지 명확히 이해하고 있다면, 개발자와의 소통에서 훨씬 효과적으로 의견을 전달할 수 있습니다.

또한, 디자이너 입장에서 기획한 기능이 API로 실현 가능한지 미리 판단할 수 있어, 불필요한 재작업과 시간 낭비를 줄일 수 있답니다!

마무리 👊🏻

이렇게 API와 HTTP 메소드를 이해하고 있으면, 개발팀과의 협업이 더욱 매끄러워지고 업무 효율성도 높아집니다. 우리가 초반에 그리는 IA, 플로우차트는 명목상 만드는게 아닌, "아하! 이렇게 데이터가 왔다갔다 하군! API를 이때 호출하면 되는거군!" 하고 개발자분들이 이해하는 도식이라고 보시면 될 것 같네요.

추가적으로, 이 API개념과 HTTP 메소드를 이해하면 데이터가 제대로 응답하지 않았을 시, 생기는 다양한 에러케이스를 고려해서 기획을 할 수 있답니다. (우리가 냅다 에러 팝업 UI를 만들기 전에, 에러케이스를 사전에 정의하고 꼼꼼하게 작업할 수 있다는 장점이 있죠.)

적다보니 기획이란.. 이런 개념을 잘 알아야 누락없이 잘할 수 있는 것 같네요 🥲 (돈벌기 힘들다) 그럼 다음에도 유익한 내용으로 돌아오겠습니다!

이번엔 개발자와 협업할 때 자주 마주치는 기본 용어, CRUD에 대해 함께 알아보려고 합니다. 예전에 제가 꽤 오래다닌 스타트업이 있었는데, 그때의 대표님께서 저를 앉혀놓고 CRUD 개념을 강의해주셨던 기억이 생각나네요. ㅇㅅㅇ

그때는 이게 머선 내용인가,, 싶었지만은~ 살다보니 배워야 되는 개념이더라구요? 자, 드가봅시다.🏃🏻‍♀️

CRUD그게먼데, 어떡하라고, 어떻하라고, 어뜨카라고.🗣️

CRUD는 데이터 처리의 가장 기본적인 작업 4가지를 의미하는 용어로, 각 글자는 Create (생성) / Read (읽기) / Update (수정) / Delete (삭제) 를 뜻합니다. 이 네 가지 기능의 앞글자를 따서 흔히들 CRUD라고 부릅니다.

CRUD와 HTTP 메소드의 연관성

CRUD 개념은 웹 개발에서 사용하는 HTTP 메소드와 밀접한 연관이 있습니다.디자이너인 저희도 API 문서를 볼 때 이 개념을 알면 정말 유용하답니다. 🙆🏻‍♀️

1)Create → POST: 데이터를 생성할 때 사용합니다. 2)Read → GET: 데이터를 읽거나 조회할 때 사용합니다. 3)Update → PUT 또는 PATCH: 기존 데이터를 수정할 때 사용합니다. 4)Delete → DELETE: 데이터를 삭제할 때 사용합니다.

CRUD가 쓰이는 사례 👩🏻‍🏫

예를 들어 인스타그램을 떠올려보면 아주 쉽게 이해할 수 있습니다. 이 CRUD를 파악하면, 화면설계서에 빠지는 기능 없이 아아주 COOL하게 UI를 짤 수 있답니다?

1) Create: 사진을 새로 올리는 기능 (게시물 생성) 2) Read: 다른 사람들이 올린 게시물을 보는 기능 (게시물 읽기) 3) Update: 내 프로필 정보를 수정하거나 이미 올린 게시물 내용을 편집하는 기능 (정보 수정) 4) Delete: 내가 올린 게시물을 삭제하거나 댓글을 지우는 기능 (게시물 삭제)

이렇게 보니 CRUD가 아주 간단한 개념이죠? (CRUD! 타이어보다 쉽다!)

CRUD를 잘 알면 화면설계를 잘한다!

예. 말그대로 제곧내입니다. 화면 설계서를 작성할 때 CRUD 개념을 미리 생각하면 정말 좋습니다. 왜냐하면 디자인하다 보면 무심코 '수정하기'나 '삭제하기' 같은 중요한 기능을 빠뜨리기 쉬운데, CRUD를 기억하면 기능 누락을 방지할 수 있거든요!

예를 들어, 사용자가 작성한 리뷰를 관리하는 화면을 만든다고 할 때,

1) 리뷰 작성하기 (Create) 2) 리뷰 보기 (Read) 3) 리뷰 수정하기 (Update) 4) 리뷰 삭제하기 (Delete) 이 네 가지를 모두 고려해서 설계하면 더 완성도 높은 화면을 만들 수 있겠죠?

CRUD를 잘 설계하지 않는다면..💦

CRUD를 제대로 설계하지 않으면 다음과 같은 문제가 발생할 수 있습니다:

1) 사용자들이 중요한 데이터를 수정하거나 삭제할 수 없음 (게시물 쓰기는 있는데 삭제는 어딨는데.. 어케하는건데.. 하는 상황 발생) 2) 서비스 유지보수 비용이 증가 (나중에 기능 추가 시 큰 비용이 발생할 수 있어요!). 3) 데이터 관리가 어렵고 복잡해짐

디자이너가 CRUD에 대해 아몰랑 해버릴 경우

만약 CRUD 개념을 잘 모르고 디자인을 하면 이런 일이 벌어질 수 있습니다.

1) 게시물, 사진 업로드는 있는데 삭제 아이콘이 없다.. 2) 화면이 100개가 넘어갈 경우, 내가 수정을 넣었나? 안 넣었나? 넣었나? 초록치매가 올 수 있다. 3) 데이터가 어떻게 이동하는지에 대한 구조를 설계할 수 없다.

요렇게, 사용자가 입력한 정보를 수정하거나 삭제할 수 있는 버튼을 누락하는 케이스가 많이 생기고, 화면설계서를 보는 다른 팀원들이 이잡듯 찾아줘야 하는 빡침이 발생합니다. 그러니 피그마에 CRUD 크게 써놓고 체크해보도록 해용

디자이너가 CRUD를 알면 좋은 점

디자이너가 CRUD 개념을 알게 되면, 개발자와 더 효과적으로 소통할 수 있어요. 우리가 만든 디자인이 실제 서비스에서 어떻게 동작할지 더 명확하게 이해할 수 있고, 빠뜨린 기능 없이 완벽한 디자인을 할 수 있습니다.

또한, 개발팀과 기능에 대해 논의할 때 더욱 구체적으로 요구사항을 전달할 수 있어 협업 과정에서 생기는 오해를 줄일 수 있답니다!

마무리 👊🏻

오늘 알아본 CRUD 개념은 정말 간단하지만, 실제 업무에서 활용도 높은 기본적인 개념입니다. 처음엔 뭔소린가 싶지만, 몇백개의 UI를 만들다보면.. 차암.. 기능을 까먹고 안넣는 내자신이 싫어질 때가 있습니다.. 그럴 때를 대비하여 이 개념을 잘 알면 좋겠지요?

일단 연속으로 2개 썼는데 요즘 퇴근하고 velog 쓰는게 낙입니다. 헤헷 다음시간에 또 만나요 . ^^ (금요일에 만나용 ~)

자, 거두절미하고 이제는 미들(파들~)급 프로덕트 디자이너로 진화하게 되어 이제는 기획/디자인/Some of 프론트엔드 개발을 병행하고 있는데요. ​

개발자 분들과 소통할 때, 여러가지 용어를 알아야 할 것 같아 가끔 채찍피티와 독학을 하고 있습니다.

​ 그래서,, 수도관 파이프는 알겠는데 CI/CD 파이프라인.. 그게먼데....!

​

💿 CI/CD 파이프라인을 알아보자. 콸콸콸~ ~~(like VJ특공대말투)

CI/CD는 지속적 통합(Continuous Integration)과 지속적 배포(Continuous Deployment)를 의미한다고 합니다. 쉽게 말해 개발자가 코드를 작성하고, 그 코드가 실제 사용자에게 빠르고 안정적으로 전달될 수 있도록 자동화된 프로세스라고 이해하시면 됩니다! (빠르게 변하는 애자일 개발 환경에서 CI/CD 구축은 필수)

[💁🏻‍♀️디자이너를 위한 간단설명] 조금 더 친숙한 예시로 설명하면, 피그마에서 우리가 디자인을 업데이트하면 실시간으로 팀원들이 볼 수 있듯이, CI/CD는 코드의 업데이트가 사용자들에게 즉시 전달될 수 있도록 하는 프로세스라고 이해하면 쉽습니다. (성격 급한 한국인들에겐 CI/CD 구축이 필수일듯)

​

🔗 지속적 통합(CI)이란?

지속적 통합이란 개발자가 작업한 코드의 변경 사항을 자주 통합(merge)하여, 문제가 없는지 미리미리 체크하고 테스트하는 과정이라고 합니다. 이런 과정들은 실제로 작은 문제들을 미리 잡아내어 나중에 큰 오류를 방지하는 데 아주 유용하다고 합니다.

[💁🏻‍♀️디자이너를 위한 간단설명] CI는 마치 피그마에서 여러 디자이너들이 작업한 디자인을 자주 합치고 충돌을 미리 예방하는 과정과 비슷합니다. 여러명이서 UI 만들면 당연히 꼬이잖아여? 그래서 미리미리 정리하는 과정이라고 보시면 될 것 같습니다. (J이신 분들께는 최적일 듯 하네여..전 P라..)

​ ​

📩 지속적 배포(CD)란?

지속적 배포는 통합한 코드가 테스트를 통과하면 자동으로 사용자들이 사용할 수 있도록 서비스 환경에 배포(deploy)하는 과정이라고 합니다. 이 과정 덕분에 우리가 디자인한 기능이 사용자들에게 더욱 빠르게 전달된답니다.

[💁🏻‍♀️디자이너를 위한 간단설명] CD를 예시로 설명하기 좋은 디자인 툴은, Framer 인데요. CD는 우리가 Framer에서 디자인 끝내고 바로 Publish 버튼 눌러서 웹사이트가 즉시 배포되는 그 느낌입니다. 유쾌상쾌통쾌하죠. 코드를 짜고 나서 빠르고 자동으로 사용자들에게 전달하는 것이.. 바로 CD의 핵심입니다. (디자인 끝나고 퍼블리시 슥 눌러주는 그 시원함이랄까여 ㅋ)

​

​

🤷🏻‍♂️ 그래서 CI/CD 파이프라인 어케 설계하는건데

CI/CD 파이프라인의 단계는 다음과 같습니다. ​ 1) 계획하기 (Plan) 프로젝트의 목표와 기능을 정의합니다.

2) 개발하기 (Develop) 개발자가 코드를 작성하고, 작은 단위로 자주 올립니다.

3) 빌드하기 (Build) 작성한 코드를 실행 가능한 형태로 변환합니다.

4) 테스트하기 (Test) 빌드된 코드가 문제없이 작동하는지 자동으로 점검합니다.

5) 배포하기 (Deploy) 테스트를 통과한 코드를 실제 서비스 환경에 배포합니다. ** 6)운영하기 (Operate)** 배포 후에도 문제가 없는지 계속 모니터링합니다.

​

​

☑️ CI/CD 관련 툴은 무엇이 있을까?

대표적으로 사용되는 툴에는 Jenkins, GitLab CI/CD, GitHub Actions, Travis CI 등이 있습니다. 이 툴들을 활용하면 코드 작성부터 배포까지 모든 과정이 더욱 효율적으로 관리됩니다. (보니깐 GitHub Actions가 제일 많이 사용되는거 같네요!)

​

🤔 CI/CD 파이프라인이 왜 필요하냐면요..

CI/CD는 특히 앱이나 웹 서비스를 자주 업데이트하거나 빠른 시간 내에 새로운 기능을 추가하고자 할 때 꼭 필요합니다. 예를 들어, 자주 업데이트가 이루어지는 온라인 쇼핑몰, 모바일 앱이나 대규모 웹사이트에서는 CI/CD 파이프라인이 필수적이겠죵? (토스 디자이너분들이 Framer를 쓰는 이유가 아닐까 싶습니다. Just 추측~)

​

🤦🏻‍♂️ 마사카.. CI/CD를 구축하지 않으셨다고여..?

CI/CD 파이프라인을 구축하지 않을 경우, 다음과 같은 문제들이 발생할 수 있습니다:

1) 코드 변경 시 발생하는 오류를 즉각적으로 발견하기 어렵다. (OTL) 2) 배포 작업이 수동으로 이루어져 시간이 많이 걸리고 실수가 발생하기 쉽다. (삽질한 위험 UP) 3) 업데이트 주기가 길어져 사용자에게 빠르게 새로운 기능을 제공하지 못한다.(애자일 하지 않다..) 4) 팀원 간 협업이 어렵고, 작업 효율성이 떨어진다. (팀원 여러명이면 이제 걍 복장터짐)

​

👊🏻 디자이너가 CI/CD를 잘 안다면 좋은 이유

저희가 만드는 모든 디자인 시스템은, 이 CI/CD를 더 효율적으로 하기 위해 만들어졌다고 할 수도 있습니다. 요즘은 세상이 좋아져서(?) 피그마에서 디자인 시스템을 수정하면, 깃허브와 연동시켜 자동으로 빌드/배포가 되는 프로세스가 생겼는데요.

이렇게 CI/CD에 대한 개념을 잘 파악한다면 디자인 시스템을 다 뜯어고쳐도, 자동배포 되잖앙? 완전 럭키비키잖앙? 하는 상황을 만들 수 있습니다.

추가적으로, 추후에 프로덕트 디자이너가 PM으로 성장할 때 WBS를 짜거나, QA를 진행할 때 훠어어얼씬 수월해집니다. 뭐 저도 그 과정인 것 같습니다만..^^

자자, 그럼 다음 시간에는 방금 말씀드린 피그마와 깃허브 연동시켜서 디자인 시스템 자동 배포해버리기. 편! 가져오겠습니다. (이건 좀 연구가 필요해서 다른 편 먼저 가져올 수도 있어여)

​

그럼 SAYONARA 씨유 레이러 🥃

이번엔 iOS 스승님께서 내주신 2번째 숙제인 UI구성에 대해 말해보려합니다. "UI"라.. 개발언어만 구글에서 찾아보다가 UI라는 말에 마음이 살짝 설레네요.

그런데 UI View에 대한 자료가 굉장히 많아서 일단은 관심가는대로 골라서 정리하려 합니다. UI는 디자이너 맴이니깐~

*** 01. UI View와 Auto Layout **

1. UI View 란?

• 참고하기 좋은 선생님: https://www.hohyeonmoon.com/blog/xcode-ui-design/

  • UIView는 가장 기본이 되는 View로, UIComponent들의 조합으로 화면이 구성된다.
  • iOS 화면 구성은 UIView의 집합으로 되어 있다.

2. Auto Layout 이란?

• 참고하기 좋은 선생님 : http://labs.brandi.co.kr/2018/05/30/kimjh.html

  • 오토 레이아웃(Auto Layout)은 제약 조건(Constraints)을 이용해서 뷰의 위치를 지정하는 것
  • 아이폰 8, 아이폰 10, 아이폰 12 pro max같이 디바이스가 다양한 상황에서도 "일정한 제약조건" 을 걸어 알아서 배치를 설정해준다고 생각하면 됨.

그리고, 오늘 개발자분들한테 velog가 핫하다는 얘기를 듣고 부랴부랴 만들었다. 사실 티스토리 UI는 제스탈이 아니였걸랑요

velog.. de"vel"oper와 b"log"의 합성어일까? 네이밍이 굉장히 맘에든다. 내가 iOS 글을 올리지않는다면.. 다들 댓글로 독촉해주시길..

01. Xcode IDE는 뭔가?

Apple의 macOS, iOS, watchOS 및 tvOS용 소프트웨어 개발을 위한 IDE. 엑스코드라 읽으며, macOS 전용이다.

UI 디자이너는 안드로이드, iOS 상관없이 다양한 프로그램으로 디자인 할 수 있으나 안드로이드 개발자는 안드로이드 스튜디오, iOS 개발자는 Xcode를 통해 개발한다고 생각하니 조콤 쉬웠다. 필자는 앱등이니깐 Xcode가 좋다.

**02. Xcode 파헤치기 - *Project Settings - General, Signing & Capabilities, Build Settings, Build Phases

• 참고하기 좋은 선생님 : https://cau-meng2.tistory.com/109

1. Project Settings

   • Xcode의 프로젝트 세팅은 UI 디자인 프로그램보다는 프리미어 프로와 비슷한듯하다. 전반적으로 프로젝트 기본정보 / 프로젝트 세팅 등이 들어가는 듯 하다.

2. Project Settings - General

   • Display name : 디자인으로 치자면 파일명인듯 (ex. 배민 앱 디자인_0708)
   • Bundle identifier : 약간 도메인 느낌? 도메인도 겹치면 안되듯 고유한 식별자를 가지고 있는 번들 아이덴티티.
   • Version : 말그대로 버전. 우리는 처음이니깐 1.0
   • Build : 그냥 말그대로 빌드

3. Project Settings - Signing & Capabilities

   • Signing & Capabilities : 전반적으로 디자인 프로그램에서 시리얼 등록할때의 화면과 비슷한 것 같다. 당신이 개인인지, 팀인지, Apple 계정을 가지고 있는지, 어느 팀에 속해있는지? (디자인 프로그램도 그렇고 어디 회사다니는지 궁금한가봄)
   • Team : 너가 무슨 팀에 속했냐
   • Provisioning Profile : 시스템 프로필 유형. 그냥 Xcode 고정이라 생각하자
   • Signing Certificate : 디자인에서도 있는진 잘 모르겠는데, 예시를 들자면 내 디자인파일에 Adobe XD design : Team mary (고유식별번호) 이렇게 디지털 ID를 만들어주는 느낌. 키체인과 인증서와 관련있다고 한다. 약간 공인인증서 개념인 것 같다.

4. Project Settings - Build Settings

   • Build Settings : 우리가 디자인하기전에 가로, 세로 사이즈와 해상도를 정하듯이 디바이스 설정값을 정하는 화면인 듯 하다. 디자이너는 UI를 디자인 한 후 프로토타입을 돌릴때 즉석으로 되는 경우가 많지만, 개발자들은 코딩을 한 후 프로토타입을 돌릴때 이 과정을 "빌드"라고 부르는 것 같다. 이 화면은 그 "빌드"에 대한 기준을 설정하는 듯 하다. (내용이 너무 길어서 생략하겠음)

5. Project Settings - Build Phases

   • Build Phases : 이 화면은 예를 들자면, 디자인할때 자동으로 생기는 파일들에 대해 설정해주는 화면인 것 같다. 일러, 포토샵은 해당이 안되지만 프리미어를 써 본 디자이너라면 난 분명 프리미어 파일 하나만 만들었을 뿐인데 쭈루룩 다른 파일이 생기는 광경을 봤을것이다! 그 파일들에 대한 기준을 설정해주는 화면인 것 같다.
   • Dependencies : 뭔소린지 모르겠다.
   • Compile source : Swift, Objective-c와 같이 호환가능한 소스 파일을 대상에 연결하는 거라고 한다. 디자인으로 치자면, XD에 Sketch, Figma 소스들이 호환되서 연결되는 느낌?
   • Link binary With Libraries : 다른 대상에서 생성된 라이브러리나, 외부 라이브러리를 연결시킬 수 있음. (디자인으로 치자면 외부 UI KIT?를 연결시킬 수 있다 치면될 것 같음)
   • Copy bundle resource : 리소스를 대상과 연결하고, 적절한 경우 제품 내의 하위폴더에 복사하는거라고 한다. 디자인도 폴더별 분리가 중요하지 않은가.. 원본파일 - 소스파일 - 폰트 / 이미지 파일 요렇게 대 - 중 - 소 분류를 뜻하는 듯 하다.

**03. Xcode 파헤치기 - *Info.plist

• 참고하기 좋은 선생님 : https://velog.io/@twkim8548/iOS-개발을-시작해본다 (아니 잠만 우리회사 개발자분이였음 ㄴㅇㅁㅇㄱ)

  • Info.plist : 솔직히 뭔가 네이밍을 딱 봤을때 개발언어같아서 찾아보기 싫었는데 그냥 찾아봤다. 요약하자면 어플의 "권한"에 대한 정보를 모아서 볼 수 있는 화면이라고 한다. ex) - Application users Wi-Fi : Wi-Fi 사용여부

**04. Xcode 파헤치기 - *Assets.xcassets - icon, image, color

• 참고하기 좋은 선생님 : https://woojin-hwang.github.io/xcode-asset/

  • Assets.xcassets : 간단하게 이 파일은 에셋을 모아논 파일이라 생각하면 편할 것 같다. 앱 아이콘부터 컨텐츠 (이미지, 아이콘..) 등을 모아논 파일이다. 디자인에서 우리도 소스들을 정리해놓듯 개발도 마찬가쥥~ 제플린에서 다운받아서 이 파일안에서 관리하시는 듯 하다. (에셋명이 깔끔하면 좋은게 이것 때문일까?)

**05. Xcode 파헤치기 - *Interface - Storyboard, SwiftUI

• 참고하기 좋은 선생님 : https://blog.nerdfactory.ai/2019/06/09/wwdc-2019.html https://blog.sengwoolee.dev/108

  • Storyboard, SwiftUI : 이 개념은 바야흐로 2019년 WWDC에서 시작된 것 같다. (안맞으면 댓글점) 대체 Storyborard와 Swift UI의 차이점이 뭔데..?

• *1) Storyboard
• *Storyboard는 기존에 동시 협업을 할 경우 충돌이 있는 점이나 빌드가 어려웠나보다. 디자인으로 치자면, XD가 나오기 전 포토샵인 것 같다. 전반적으로 무겁고, 프로토타입하기도 어렵고, 레이어를 복사하는것도 오래걸리고, 무엇보다 동시협업이 거의 불가능하다는 점이 비슷한 것 같다.
• *2) Swift UI
• *Swift UI는 개발자한테도, 디자이너한테도 좋은 프레임워크인듯 하다. 실시간 미리보기를 제공하고, UI 호스팅 컨트롤러를 통해 UI Kit를 사용할 수 있다고 한다. 그리고, 무엇보다 Storyboard보다 빌드가 빠르다는 점이라고 한다. (프리미어인데 실시간 렌더링되는 그런 짜릿함같삼 심지어 영상 템플릿도 제공해주는 고런느낌)

**06. Xcode 파헤치기 - *AppDelegate, SceneDelegate

• 이부분은 도저히 이해가 안가서 iOS 스승님께 물어보고 올 예정~

이 포스트 이후로 포스팅이 없다면 독촉 댓글 남겨주십시오.

독촉댓글 환👨‍🚒영🔥