오늘도 개발자가 안 된다고 말했다.

윤뿔소·2022년 11월 27일

목록 보기

1/1

내용정리 시작! 한 Part당 소제목 1개씩 읽을 것이다!
번호나 • 뒤에 나오는 내용만 읽어도 파악되게 써봤다.
개발 자체의 기술보단 업계 흐름과 가져야하는 마인드? 이런 걸 주로 기술한 책이다.

Part1. 가깝고도 먼 개발자

1. 어딘가 이상한 비전공자의 협업(p18~p36) : 22/10/03

IT업계 회사엔 개발, 기획, 디자인 등 다양한 인력들이 모여 협업을 이룬다. 그 중 개발자와의 협업을 제일 어려워 하는 이야기가 많이들 나온다. 왜 이런 것일까? 그 답은 개발 언어가 거의 외국어 수준이여서 소통이 안되는 점, 개발이 어떻게 되는지에 대한 과정 및 구조를 전혀 알 수 없어서 나온다. 결국 기획하고자 하는 의도, 웹 구조에 의한 웹 디자인 등 기본적인 개발을 알아야 원활한 소통이 가능하다. 즉 협업의 기본은 최소한 개발에 대해 과정과 구조를 겉으로도, 피상적인 이해가 있어야 협업이 가능하다. 그러므로 자신의 회사에 필요한 기술 스택을 알고, 협업에 필요한 개발 지식을 학습하여 원활한 협업을 요하는 것이 중요하다!

전체 내용 정리

이런식으로 쓰여진다.

어딘가 이상한 비전공자의 협업

기획자 김 군의 협업

행정학과 김 군, 교내 스타트업 스타팅 멤버로 PT 할 수 있다는 이유로 취업, 서투른 기획서로 서비스 기획을 하며 개발자와 협업, 규모가 작아 서로의 의도를 잘 파악할 수 있는 구조라 원만한 협업 가능, 협업 중 기획하고자 하는 의도, 즉 '메시지'가 중요하다는 걸 김 군은 깨달음

하지만 클라이언트(고객)와도 소통이 필요, 만일 WIFI를 사용하는데 광고를 봐야 사용 가능케 하는 서비스를 제작해 팔아 지점마다 설치하는 서비스를 김 군이 기획, 영업, 유지•관리함, 그런데 만일 클라이언트에 문제가 생기거나 해주지 못할 요청사항 등 김 군이 커트해야할 문제들을 관리해야하는데 화면 관리의 프론트엔드, 서버의 백엔드, WIFI의 펌웨어, 네트워크 등 다양한 기술 문제를 모른다면 관리하지 못함

또한 개발자들끼리의 생각이 달라 기획자로서 조율해아하는 문제에 부닥칠 수도 있음, '프엔 개발자는 된다지만 백엔 개발자는 기능 구현이 안된다.' 식의 문제에 직면할 수도 있음, 하지만 백엔드 개발자가 기능 성장을 저해한다든지 그런 의미가 아님, 서비스 운용의 관점이 다르거나 어떠한 문제로 부딪혀 부정적인 생각을 내비치는 것일 수도 있음

즉! 기획자는 개발 구조를 이해해 전체적인 개발 흐름을 알고, 개발자와의 소통을 하는데 있어 문제의 대안이나 더 좋은 서비스로 성장하자는 의도 등 유연한 사고방식을 가져 개발자와 보다 더 나은 파트너의 관계로 발전해 나갈 수 있다.

디자이너 김 양의 협업

중장기 계획을 짜고 사업의 전체적인 전략을 짜는 소규모 IT기업의 전략기획부로 입사한 김 양, 하지만 김 양은 디자인 툴과 블로그 경험이 있어 입사한 터라 간단한 디자인 업무와 마케팅 업무를 도맡아 했음, 그러다 대행 판매 건을 맡게 됐고 페이지가 필요해 개발이 필요한 '랜딩 페이지'를 디자인해 개발팀에게 전달했고 당연히 반려당함 - 웹 개발에 기반하지않은 디자인 기획(구역, 모션 등), 프로젝트가 어떻게 진행되는지 파악 어려움

그러면서 깨닫게 됨

웹 디자인은 웹이 동작하는 원리를 알고 그에 맞는 디자인 기획을 짜야함
기본적인 개발 구조 파악 : 프엔, 백엔, DB 등 개발자들이 하는 일이 다 다르다는 걸 인식하게 됨

이러한 점을 깨달으며 프로젝트의 어떤 기능에 대해 맞는 개발자와 얘기해야할지, 일정 내 구현이 가능한지에 대해 생각하게 됨

결국 웹 개발에 대해 다시 알아야하는 김 양은 HTML, CSS, JS를 공부하며 기초를 다졌고, 자신이 배운 데까지만 기능과 디자인 구현을 하게 됨. '프엔 개발자가 되볼까?' 하는 생각도 들었지만 결국 디자이너로서 가지는 디자인 관점을 포기하고 코드로만 생각하게 되는 자신을 보고 깨달음. 개발 언어, 프로그램 개발 자체가 아니라 나의 회사에서 개발되는 구조, 과정 등을 알고 나의 디자인이 어떻게 구축되는지만 알면 이 관점을 유지하면서 원만히 협업할 수 있구나~하고.

결국 디자이너는 사용자에게 어떻게 보이는지, 어떠한 환경에서 어떻게 관리하며 경험 상 어떻게 사용할지 등을 알아 내가 보는 게 아닌 사용자가 실제로 접근하는 것이 최종완성본이란 걸 아는 게 중요함. 그래서 그 이전 개발에 대해 이해하여 개발자와의 소통을 원활히 하면서 디자이너로서 이런 부분을 함께 체크한다면 좋은 협업이 가능할 것임

우리가 협업을 할 수 있었던 이유

위 김 군이 처음 협업할 시 협업을 가능케 했던 이유는 '하얀색 도화지'였고 소규모였음, 그래서 서로의 포지션에서 서로의 말을 경청하고 의도를 보다 쉽게 파악할 수 있어 이해 되지 않은 내용은 반복적인 질문, 필요한 정보를 파악 후 빠른 대처가 가능했었음. 즉, 협업의 기본을 다 할 수 있어 원만한 소통이 가능했음.
하지만 일반적인 회사에서 근속하며 그러기엔 쉽지 않음. 그러므로 개발자에게 질문을 해 협업에 필요한 개발 지식 습득 등 자신의 회사에 필요한 개발 기술 지식이 무엇인지 빠르게 알아 개발자와의 원만한 협업을 위해 노력하자

2. 온몸으로 느낀 개발자(p37~p47) : 22/10/06

여기선 개발자가 아닌 포지션이 개발자를 관찰하여 알게된 것을 사례로 3가지를 들며 서술하고있다.

자주 부정적 개발자(상황을 고려해 대안 제시)
매우 긍정적 개발자(오히려 무서움, 확실한 조건 걸기)
대안 제시 개발자(상황 인지해 대안 제시)

다양한 유형이 있지만 쨌든 좋은 개발자는 '회사의 성장을 위해 협업해 문제를 해결하는 개발자'라는 것이다. 그런 개발자의 특징을 4가지로 나눈다.

집요한 문제 해결(문제 해결에 집요, 해결함으로써 즐거움을 느낌)
비즈니스 이해하는 눈(고객 관점 중시, 비즈니스 모델 추구 및 빠른 테스트)
5살배기도 이해하는 소통의 기술(어려운 개발 용어를 쉽게 풀어서) 4. 체계적 업무 관리와 빠른 피드백(업무 일정 내 마감, 변수에 빠른 피드백)

또한 다른 포지션들에게도 3가지 교훈을 던져준다. 개발자들이 그냥 말에도 그렇게 '느낄 수 있는' 포인트를 던져준다.

간단하죠? 해주세요(상대방 역할 무시 어투, 하나 버튼 추가에 복잡한 기능 연결)
~까지 해주세요(개발자 입장 고려 X)
타 서비스는 제공하던데요?(타 개발자와 비교 어투, 안된다는 것엔 여러 이유 존재)

3. 협업을 위한 준비물(p48~p52) : 22/10/14

그렇다면 IT 기업에서의 협업을 위해 어떻게 준비해야할까?

협업에 대한 이유: 즉! 서로 다름을 알고 과정을 공유, 입장을 이해
- 갈등이 일어나도 같은 목표를 공유한다면 그 목적을 향해 겪는 과정이란 걸 이해한다.
- 서로 다른 포지션의 업무를 이해하기
  - 기획자: 업무상 논리적이고 객관적, 그러므로 기획자를 대할 땐 객관적 논거나 근거자료를 제시해 이야기하기
  - 디자이너: 기획된 내용을 바탕으로 EX를 중시하다보니 의도되지않은 디자인이나 1px의 오차나 색상 등 세심한 디테일을 캐치하는 등 자신의 디자인에 민감하다. 이를 알고 상처받지말기.
  - 개발자: 실제 기획을 구현, 문제 해결에 초점을 두다보니 자신의 것 외에 관심이 없을 수도 있고, 직무의 몰입도가 매우 큼
필요한 개발 지식 습득: 개발자와의 소통은 어려워! 그러니 조금의 이해를 요하자
- 자주 알려주는 개발자와 친해지기
- 물어봐 개발 언어 자체보단 회사의 서비스 구조, 개발 프로세스, 자주 쓰는 용어 등을 먼저 파악하기
  - 개발자도 설명하기 모호한 용어들이 있다. 메모해서 구글링 必
- 그렇게 기초를 다져 그제서야 관심이 생긴다면 대중적이고 쉬운 언어부터 학습하기

Part2. 기획자의 일

1. 서비스 기획 들여다보기(p53~p65) : 22/10/15

파트1은 개발자 얘기였고, 이제 기획자를 보도록 하자. 2-1은 기획의 정의와 범위, 유형, 실제 기획 개발 과정 등을 얘기한다.

범위: 기업마다 환경, 규모 등 다르기에 딱 잘라 정의하기 애매
- 사전적인 의미로 정의: 서비스 방향성에 따른 목적, 기준을 정하고 그거에 맞춰 실행 설계 및 제안
  - '대상에 따른 변화에 맞는 목적 확인': 시장 분석, 예비 고객 타겟팅
  - '목적 성취를 위한 적합한 행동 찾기': 목적에 맞춰 핵심 니즈에 방향성을 둠(스케치)
  - '설계하기': 스케치를 실제로 구현하기 위한 설계서 작성
유형: 서비스 유형에 나뉨, 장단점이 다르기에 커리어를 어떻게 쌓을지 고민
- 인하우스(자체 서비스 운영 기획): 주로 서비스 성장을 위해 고객 데이터를 보며 분석하고 기획하는 걸 반복, 직무 수행하며 더더욱 폭이 좁아지는 경향이 있어 다양한 경험 X
- 에이전시(외주, SI): 제안요청서(RFP)에 따라 세부 기획하고 처음과 끝까지 기획해 빠르게 성장하고 다양한 경험, 양질의 레퍼런스를 얻을 수 있음, 데드라인이 정해져 있어 시간에 쫓기고, 야근이 잦음
기획 프로세스: 사소한 아이디어가 떠오른 뒤 해야할
1. 리서치/분석: 시장에서 경쟁력? 가치 유무? 시장규모, 경쟁업체 등
2. 방향성 설정: 서비스 주요 타깃을 정해 얻는 효용, 행동을 예측하기, 가설 세우기
3. 컨셉 도출: PoC(Product of Concept)를 짜서 가설을 이미지화 하기
4. 설계/기획: IA, 와이어프레임을 짜 서비스 구조 구축, 개발자와 협업 시작
5. 디자인/개발: 정한 방향성을 유지하며 예쁨-기능(디자인-개발)의 균형을 맞추는 게 중요!
결론: 방향성이 제일 중요, 방향성에 맞는 서비스와 그 기준을 세워 디자이너, 개발자 등 모두를 충족시킬 수 있게 조정하는 것이 기획자의 일, 또 기획안의 프로토타입을 만들어 시각화해 구체화하는 것도 중요, 방향성의 구체화와 사용자 관점에서 볼 수 있어 좋음

2. 협업을 위한 사전 준비(p66~p83) : 22/10/16

기획자로서 가져야하는 협업의 자세를 보자. 전에는 기획자는 화면 그리기나 기능 구현이 아닌 방향성 설정과 유지를 보는 포지션이라고 배웠다. 그러므로 이번 목차엔 전체적인 틀을 짜는 기술을 서술했다. 서비스 전체 구조를 보는 IA를 웹사이트 구조에 기반해 구조화해 방향성을 구체적으로 설정한다. 근데 또 IA를 그리기위해 기능들을 구체적으로 리스트업해야하는데 MECE와 하이라키 기법이 있다.

MECE: 맥킨지에서 개발한 기법, 목록화된 기능들을 유사한 성질끼리 묶어주는 역할을 함, 거창하게 기법어쩌구 했지만 경험적으로 체득한 사람도 많음
하이라키: 부모-자식 관계 등 상하 위계 구조를 의미, 디자인(UI/UX)에서 많이 쓰이는 계층 구조화의 일환으로 IA에 Depth(Level)로 같이 기획한다.

구현해야할 기능들을 일단 관찰하고 MECE로 비슷한 기능들을 모아 카테고리화하고 하이라키로 구현 중요도부터 기능들을 매겨 Depth로 나타낸다.이렇게 기준을 나눠 유사한 기능을 모아둠과 동시에 세부적인 기능을 기획에 맞춰 IA를 짜서 방향성을 맞춘다.

3. 협업을 돕는 화면 설계서(p84~p96) : 22/10/19

협업에 뭐가 중요한지 알았다. 본격적으로 기획자에게 정말 중요한 화면 설계서가 협업에 중요한 이유, 쓰는 방법 등에 대해 고찰해보자!

설계서를 작성하는 이유: 설계서 중심으로 모든 협업이 가능하게
- 개발 요청서 뿐만 아니라 이슈가 생길 시의 상황도 담겨져 있어야 설계서 중심 협업이 가능, 히스토리 등을 정리하여 설계서 중심으로 소통이 가능하게
목적을 명확하게 전달: 설계서 작성 중 기획의 의도가 제대로 전달돼야함, 그래야 구체적인 방안을 같이 모색하는 등 수월한 협업 가능
설계서 타이틀: 리뷰 회의 이전 다른 포지션이 설계서를 안봤을 확률도 높고, 빠른 소통을 위해 타이틀을 함축적이지만 자세하게 작성
- 제목만 있으면 방향이 뒤틀릴 수도 그래서 추가해야함: 1. 작성 날짜 2. 플랫폼 3. 기능 상세 명칭 및 기획방향(신규/개션 등) 4. 문서 버전
- 문서제목: 상품 검색 기획 설계서 => 문서제목(신규): 2022/10/31_A몰_상품 검색 신규 기획 설계서_v1.0 ~~ 문서제목(고도화): 2022/10/31_A몰_상품 검색 고도화 기획(고급 옵션) 설계서_v1.0
설계서 속 스토리텔링: 설계서에서 탄탄하게 구성되면 설득력 업
- 타이틀(기능 소개), 목차, 버전 이력 관리(히스토리 공유), 설계목적 및 기대효과(기획배경 및 목적 공유), 정책 및 프로세스 정의(범위 공유), UI 설계 방향
리뷰 요청 방법: 리뷰 회의 전 회의 참석자들에게 공유하는데 지키면 좋을 예의들, 기획 의도를 제대로 전달 위함
- '설계서 작성하는데 미리 고려해야할 부분이 있을까요?' 같은 말로 미리 언질
- 그 후 리뷰 회의 건 설계서 발송하는 데 있어 간 회의 일정 및 기획 배경, 세부 내용 등을 메일 내용에 포함시켜 발송하기

이런 식으로 설계서를 작성하면 협업에 한층 수월해질 것이다. 부탁의 자세를 가지되 자신을 낮추는 것만이 아닌 자신의 과정을 공유하는 것만으로도 도움이 될 것이다.

Part3. 디자이너의 일

1. 디자이너의 마인드셋(p97~p110) : 22/10/22

IT기업의 디자이너는 생각한대로 디자인하는 것이 아닌 기획의 의도나 목적을 중점으로 디자인해야한다. 예술이 아니라 주어진 목적을 조형적으로 실체화해야한다. 왜!? 미적 기준은 사람마다 달라 통일할 수 없으며 각 기능, 페이지의 목적마다 중점적으로 둬야하는 포인트가 다르기에 기획안을 기준으로 디자인해야한다.

웹/앱 디자인의 핵심: UI/UX - 사용자 중심의 경험이 중요하다!
예: 하인즈 이전 케찹들은 뚜껑이 위로 가게 UI가 디자인 됐다. 하지만 UX적인 관점에서 케챱이 뚜껑과 반대로 있다면 케챱이 뚜껑에 뭉치는 등 별로였다. 하인즈 케찹은 UI를 뚜껑 아래로 가게 만들어 짜기 편하게(내용물 적어져도, 뚜껑 안굳음)만들어 UX를 향상시켰다!
UI/UX 관련 개발 방법: 사용자 중심, 편한 지 안편한지
- 구글 애널리틱스 툴: 기획, 개발 등 대부분 도움되는 툴, 신규 방문, 재방문 등과 어느 페이지에서 이탈률이 높은지 분석해주는 툴, 이 걸 기준으로 디자인하면 좋음
- 툴, 구조 등을 분석하는 것이 디자이너 하나만 하기엔 버거워서 협업 필요
디자이너로서 경쟁력 갖추기: 감각 늘려 트렌드 잡기, 개발 구조 이해
- 감각 늘리기, 트렌드 잡기: 다양한 레퍼런스 관찰(드리블, 핀터레스트, Muzli 등), 트렌디한 툴 사용(피그마, 스케치, 제플린 등)
- 개발을 아는 디자이너는 치명적!: 기초 퍼블리싱 지식을 익혀둬 가능, 불가능 기능들을 디자인해 효율적인 디자인을 하자. 그 이상 개발을 하고싶고 한다면 프리랜서로 하는게 더 효율적

2. 정확한 시각화를 위한 개발 지식(p111~p135) : 22/10/24

디자이너의 관점에서 보는 정확한 시각 표현의 필요 조건인 개발 지식에 대해 알아보자!

색상: 웹을 구동시키는 환경마다 다르게 표현될 수 있음, 그러므로 색상이 적용된 이후에 생각보다 다르다면 개발자와 협업해 조정
- 디자인은 CMYK를 따르고 있지만 웹에선 RGB를 따르고 있음, 환경에 따라 다르기에 그 폭을 줄여주는 'sRGB'로 설정해 색상을 정해야함
- 개발자에게 HEX(#시작), RGB(A) 등의 표기법으로 전달해야함, 적용키 어려운 부분은 CSS 사이트를 빌려 코드로 제공하기(cssgradient.io)
이미지 및 영상: 상황에 따른 파일 크기 조절, 포맷(JPG 등) 설정
- 크기: 트래픽을 고려해 파일 크기는 최대한 낮게, 픽셀 수에 따라 크기 차이는 어마어마, 손실 압축(JPG)을 하더라도 티가 나지 않는다면 압축 ㄱ
- 형식
  - 비트맵: JPG- 손실 압축, 화질 저하가 일어나지만 트래픽 ⬇️, PNG- 무손실 압축, 크기 크고, 배경 투명도를 넣을 수 있어 한번 불러오는 로고 등에 쓰임
  - 벡터: SVG- 확대, 축소해도 화질 손실 x, XML로 작성돼 코드로 수정, 애니메이션 제작 가능, 복잡한 구현은 어렵기에 단순한 로고, 로딩에 쓰임
폰트: 상황에 따라 적절한 폰트 사용, 크기도 압축, 행간-자간도 필수
- 내장(시스템) 폰트, 이미지 폰트, 웹 폰트(CDN)을 이용해 적절한 폰트 사용
- 폰트로 아이콘도 사용 가능(구글 머터리얼, Fontello)
프로토타이핑: 시장 반응 예상위해 시제품을 만듦, 개발자에게 말로 표현하기 어려운 걸 프로토타입으로 표현
- Hi-Fi(High Fidelity), Lo-Fi(Low): 실제 서비스만큼의 구현 정도에 따라 나뉨, 빠른 시일 내 소통을 이뤄 협업을 이루고 싶다면 Lo-Fi, 시장 반응을 예상하고 싶다면 Hi-Fi로
- 원시적인 페이퍼 프로토타입으로도 가능하지만 프로토타이핑 툴을 이용하자!
  - 와이어프레임 - 코드 기반에 따라 툴들이 나뉨, 요즘은 피그마로도 가능하더라??

3. 협업을 위한 개발 지식(p136~p164) : 22/10/29

전 목차엔 디자인 기획부터 프로토타입까지의 과정을 봤고, 이번엔 웹에서 어떻게 구동되는지의 기본 지식으 알아보겠다.

웹표준, 웹접근성: WC3의 웹 표준로 개발하고 웹에 취약한 장애인, 노약자 등을 위해 웹 접근성 연구소의 접근성 지침에 따라 디자인해야함
크로스 브라우징: 다양한 브라우저 플랫폼 위에서 개발해야함, 익스, 크롬, 사파리 등
- 익스: 한국은 특히 익스플로러를 아직 많이 쓰고있는 경향이 있음, 그래서 익스플로러까지 간다면 꼭 따로 익스플로러의 사용자도구를 통해 개발해야함
- 크롬: 크롬의 개발자 도구가 세계 제일!
  1. 왼쪽 상단 커서 옆 메뉴로 다양한 디바이스의 픽셀들을 볼 수 있음, 디자인 틀어진 게 없는지 확인
  2. 도구 탭 Elements로 요소 조작 및 CSS 코드 수정이 가능해 실시간으로 디자인할 수 있음
시멘틱: header, nav, content, footer 등 다양한 시멘틱 태그로 레이아웃을 잡아 개발하기
모바일 웹: 모바일은 다양한 디바이스 크기를 가져 적응형/반응형 웹으로 개발해야함
- 모바일 퍼스트: 모바일도 타겟이라면 모바일 퍼스트 방식으로 개발하여 모바일-PC 순으로 기획하여 확장식으로 개발할 때가 많음, 왜냐면 정보를 함축시키는 것보다 확장하는 것이 편하기에
그리드: UI를 배치하는데 일정한 비율로 배치하기 위한 웹디자인, Margin, Column, Gutter로 구성돼있다. 이거 했었다?
- 칼럼 기준 모바일 4개, 태블릿 8개, PC 12개로 잡아 개발하기, 반응형 만드는 데 굿!
안드, IOS: 각자 해상도가 다르고 / PC에선 px이 각각 DP, PT임 / 뒤로가기 UI는 각각 우하단, 좌상단 이렇게 다르기에 유념하여 개발하자
놓치기 쉬운 것들
- 빈페이지, 에러페이지(404 등) 제작: 빈페이지는 로딩 등 의도적으로 비워야할 때, 에러페이지는 지원하지않는 브라우저나 404 등
- 오픈그래프 제작: URL을 복사해 SNS로 전달할 때 나오는 것들, 설명, 이미지 등을 개발자에게 전달
- 파비콘
- 파일 네이밍: 배경(bg), 아이콘(ic, ico), 버튼(btn), 이미지(img) 등 컨벤션을 잘 지켜 개발자에게 전달

Part4. 개발자의 일

1. 개발자 이해하기(p165~p184) : 22/10/30

기획, 디자인을 봤고 이제 개발을 볼 차례다. 아무래도 일상에 자주 쓰는 단어, 문화가 많이 다르기에 가볍게 알아두기만 해도 협업에 수월하다.

웹개발자: 프론트엔드, 백엔드, 풀스택
- 프론트엔드: JS가 기본. 퍼블리싱(HTML, CSS로 페이지 단위 개발) 부문과 프론트엔드(JS 등 앱과 기능 개발 담당) 부문으로 나뉨. UI 컴포넌트 단위로 개발하는게 유행이라 React.js, Vue.js 등의 라이브러리를 사용함. 그렇기에 어떤 라이브러리를 사용하는지, 어느 브라우저까지 가는지, 디자인 리소스는 어떻게 전달하는지 유념
- 백엔드: Java, Python, PHP, Node.js 등의 언어와 기반한 프레임워크를 사용. 데이터베이스와 연동해 서버에서 쓰기/읽기/수정 등을 연결하는 역할, API 제공, 외부 시스템과 연동 및 관리, 네트워크 보안 처리 등을 담당함. 그러므로 백엔드 개발자가 어떤 언어, 어떤 프레임워크를 사용하는지, 서비스의 방향과 맞는지 유념
- 풀스택: 둘다 하는 개발자, 그렇기에 깊이가 부족한 경우가 있어 충분한 협의가 필요
모바일개발자: IOS, 안드로이드, 하이브리드
- IOS: Swift, Objective-C가 기본. 쓰는 언어가 Mac에서만 구동되기에 모두 Mac으로 개발. 애플의 폐쇄성으로 어려운 애플의 테스트만을 거쳐야하기에 다 같이 QA를 진행하면서 테스트를 통과해야함
- 안드로이드: Java, Kotlin이 기본. Kotlin이 쉽고, 거의 모든 기능을 가진 안드로이드 스튜디오로 애플보단 편하게 개발이 가능함. 테스트가 그리 어렵진 않아 편하게 개발
- 하이브리드: 둘다! 원래는 힘들었는데 모바일 안 앱(하이브리드앱) 방식으로 개발과 네이티브 빌더 방식이 생겼어서 가능하다!
  - 하이브리드앱: 웹뷰패키징이라는 말로도 쓰이는데 앱과 동일하지만 웹처럼 HTML, CSS같은 방식이 쓰여지는 형태. 당연히 네이티브보단 느리고 UI가 뒤틀리는 등 어려움이 있음
  - 네이티브 빌더 방식: 요즘은 JS 라이브러리가 잘나와서 React Native나 Vue Native 등과 같이 비슷한 문법으로 어렵게 네이티브 앱을 만들 수 있지만 커뮤니티가 적어 문제가 생기면 비교적 해결하기 힘든 편
  - 플러터?: 이건 내 사담임. 하이브리드로서 요즘 플러터 엄청 좋아졌고 커뮤니티도 커졌다고 하니 나중에 해보자!
참고: 소통이 필요한 용어들, 너무 많아서 내가 모호하게 알고있는 것만 위주로
- 호스팅: 클라이언트에게 리소스를 주는 역할을 하는게 서버, 그 서버를 빌리는 행위를 호스팅(회사가 작으면)
- 트래픽: 서버가 리소스를 주는데 그 양을 트래픽이라 명명. 사용자가 보내는 트래픽 양보다 트래픽 용량이 작다면 서버가 다운되니 관리하기
- API: 개발자가 만든 특정 기능을 다른 사람이 사용할 수 있도록 모듈화한 것, 오픈 API는 누구나 사용 가능하게
- ⚠️빌드: 개발 코드 파일들을 나눠져있음. 압축시켜 하나로 만들거나 컴파일된 코드로 실행시킬 수 있게 만드는 작업. 결과물을 '번들'이라고 명함. 대표적인 툴들은 웹팩, 그레이들 등이 있음

2. 생산성 향상을 위한 협업 툴(p185~p212) : 22/10/31

개발자를 이해하려면 아는 것도 중요하지만 있는 그대로 소통도 중요하다. 그래서 다양한 협업 툴이 있다. 알아보자

슬랙: 실리콘밸리에서 유행타 오게된 협업 툴. 슬랙 봇을 만들고 구글 캘린더, 깃헙 등의 API 데이터를 연동할 수 있어 회사만의 커스터마이징이 가능함. 워크스페이스를 만들고 다양한 채널을 만들어 부서 별로 관리가 가능. 국내는 잔디, 라인웍스 등이 있음
지라: 프로젝트 관리 툴. 프로젝트의 계획을 수립하고 각 프로젝트마다 '에픽'이라는 항목을 설정해 세부화도 가능. 또한 프로젝트를 진행하며 생긴 이슈, 버그와 완료 등을 기록하고 공유할 수 있어 방향성을 제시하기에 딱! '트렐로'도 비슷한 프로젝트 관리 툴이고 더 가벼운 편임
컨플루언스: 위키 소프트웨어('위키' 백과 같은 거). 회사의 규율, 내부 공유 사항과 프로젝트 기획안, 일정 등을 써놔 신입의 온보딩 과정 중 사용할 수 있음. 지라와 함께 사용해 프로젝트의 진행 상태와 설명을 같이 볼 수 있음
노션: 노션이 최고임, 다양한 템플릿이 있어 툴들을 다 씹어먹음
스케치: UI/UX 디자인 툴. 디자인하여 만든 이미지를 바로 추출 가능하고 코드도 작성 가능함. 제플린 사용 가능
제플린: 디자인 가이드를 자동 생성해주거나 통일해주고 버전 관리해주는 툴. 보통 스케치에서 그리고 제플린으로 가이드를 맞춤. 디자인 계의 깃헙. 프로젝트를 공유하면 가이드를 자동으로 세워주고 수정하면 버전 관리해줘 꼭 써야하는 툴
인비전: 프로토타이핑 툴. 스케치랑 연동 가능
피그마: 싹다 필요없고 이거 하나면 제플린, 인비전 등 모두 씹어먹음, 피그잼으로 기획하고, 피그마로 다양한 와이어프레임 안에서 UI를 제작해 배치할 수도 있어 프로토타이핑도 좋음.

3. 개발자가 말하는 협업(p213~p233) : 22/11/02

협업 준비는 끝났다. 실제 개발자들은 어떻게 협업하는지 살펴보자.

2년차 대기업 개발자: 스타트업과 다르게 사업팀을 중심으로 기획자, 디자이너, 개발자를 선발해 TF팀을 만듦. 기획 초안이 만들어지고 UI 등의 디자인 시스템이 구축됨. 개발자는 기획안을 보고 기본적인 로직을 짜고, 디자인이 되면 디자인을 입혀 구현 완성함. 그 이후 QA를 걸쳐 운영 서버에 최종 배포
- 장점은 직무가 세분화 돼있어 기획 이런 거에 신경 안쓰고 개발만 신경 쓰면 됨. 단점은 TF팀으로 매번 구성되다보니 팀원이 바뀌고 만약 팀원이 협업툴을 사용하지 않는다면 직접 포토샵을 열어 디자인 파일을 추출하고.. 이런 문제가 있음.
- TF팀으로 일하기에 '지라'를 사용해 기록된 것들을 공유함. 즉, 협업 초반엔 목표를 같게끔 공유해야함.
- 개발 요청은 논리적으로 요청, 요청하는 이유가 중요함. 서비스를 구현하는 건 개발자이기에 먼저 문제, 해결, 대안 등을 물어보고 소통하는 것이 좋음.
4년차 중견기업 프엔 개발자: 프엔이라 기획 단계에서 기능 명세 기획부터 개발자가 들어와 같이 기획하면 좋겠다 생각.
- 초보 기획자들은 간단한 기획조차 개발자에겐 복잡한 코드로 다가오기에 기획 단계에서 개발자를 참여시켜 기능 정의를 함께 논의하는 것이 좋음. 기획을 아는 노련한 개발자들은 적극적으로 도움 줄 것.
- 초보 디자이너들은 이미지 별로 해상도 차이가 있다면 깨진다는 걸 모르고 그냥 이미지 파일을 줄 때가 있음. 다양한 크기의 이미지를 제공해야함. 또한 규칙성있는 네이밍으로 리소스를 제작해야함. 반드시 영어로 작성하고 자주 사용되는 항목은 통일하는 등으로.
- 협업할 시 최대한 붙어있어 협업스타일, 서로의 성격이나 특징을 알아 수월한 협업을 도모, 원격이라면 약속을 정해 화상 등으로 논의해야하고 '간단해요'같이 개발자들의 일을 단정시키지 말아야함. 불통의 원인임
- 서로의 분야의 기본 지식은 쌓아두는 걸 권장. 간단한 마크업 언어라든지 구조에 대해 인지
6년차 프리랜서: 주도적인 개발 가능, 원하는 프로젝트 참여 가능.
- 탄탄한 기획과 디자인이 있어야함. 계약이 기본 조건이기에 초반에 제대로 잡고 개발에 들어가야 기간 내에 완수 가능.
- 아예 다른 회사, 프리랜서들과 일하기에 천차만별임. 그래서 기획 단계부터 PM, 디자이너 등과 개발자가 함께 초기 미팅때부터, 협업 툴부터 맞춰가야함. 그래야 기간 안에 다 끝내고 프리랜서로 좋은 커리어를 얻어가니 WinWin임
- (실무 관련)요즘 롱스크롤 인터랙션이 많아져 그에 관련해 팁을 줌. GIF같은 이미지는 무거우므로 디자이너들은 SVG 코드를 추출해주는 애프터이펙트 내 bodymovin 플러그인을 사용해 코드를 개발자들에게 주고 개발자는 Lottie 라이브러리를 사용하면 애니메이션을 구현할 수 있으니까 활용하길 바람.
10년차 에이전시 개발 CTO: 에이전시에선 기획/구현 두가지로 나눠 개발함. 에이전시에게 맡기는 회사들은 사내에 개발 관련 인력이 없기 때문에 요구사항을 초기에 확실히 잡아둘 것

후기

되게 재밌었다. 기획자와 디자이너가 IT기업에서 겪는 좌충우돌 우당탕탕 사건들을 겪으며 깨달은 것들을 편찬한 책인데 다양한 관점에서 볼 수 있어서 좋았다. 특히 현업자가 보면 좋을 듯 하다.
물론 기획자와 디자이너 입장에서 쓴 것이라 개발자를 약간 동떨어져 보는 것도 있긴 하다. 나도 그렇게 생각하는 건 있다. 왜냐면 개발자는 여타 포지션과는 다르게 용어도 매우 다르고 사고방식 자체가 개발에 포커싱되다 보니 구현에 상상과는 차이가 있다보니 이 특성에 모른다면 조금 더 대하기 어렵고 충돌도 발생할 수 있는 것이다. 그래서 그런 관점의 차이를 알게 되어 매우 유익했다.
또 나같은 비전공 신입도 현업에 대해 맛을 볼 수 있어 은근 괜찮은 책이었다! 좋아따!

윤뿔소

코뿔소처럼 저돌적으로