[책리뷰] 오늘도 개발자가 안된다고 말했다

 책 소개

많은 IT 종사자들이 안 된다고 말하는 개발자로 인해 협업에 어려움을 겪는다. 우리는 IT 비전공자로서 소통을 잘하기 위해 개발자의 입장에서 많이 생각하게 됐고, 이 과정을 통해 개발자의 안 된다는 말에 담겨 있는 여러 가지 의미를 깨달았다. 이 책에는 우리의 성장 과정에서 발견한 협업 노하우들을 담아냈다.

2021년 03월 25일 출간

240쪽, 김종철, 김수저 저

 

 리뷰

완독일: 2022-04-17

 개발자로 회사에 취직한 지가 벌써 13개월이 지났다. 첫 일본계회사도 13개월을 다니고 관뒀었는데 인생에서 개발자로 일한 기간이 가장 긴 셈이다. 이전 회사에서 나는 내 담당일만 했고 내 팀원들과 대화를 나눴지만 다른 팀과는 가끔 점심 식사를 함께하거나 할 뿐이었다. 하지만 개발자는 달랐다. 프론트엔드 개발자로서 백엔드와의 협업은 말할 필요도 없고 더 큰 회사로 이직하고 IT부문에 직원이 많아 백엔드 개발자 외 디자이너, 기획자 더 나아가 QA분들이랑도 슬랙으로 dm을 보내거나 프로젝트 채널에서 질문하고 답변하고 소통하고 있다.

 이 책은 개발자, 기획자, 디자이너가 어떻게 협업하고 일하면 좋을지에 대해 쓰여진 책이다. 어쩌면 개발자를 위한 책이라기 보다는 신입 기획자나 신입 디자이너에게 더 도움이 될 책이다. 개발자 입장에서 이 책은 협업을 어떻게 해야할 지 보다 기획자와 디자이너들은 무슨 일을 어떻게 하고 있는 지에 대해 알 수 있다. 다시 말해 개발자와의 협업 과정에서 시행착오를 줄이고 서로 다른 관점을 이해하는 것을 돕는 책이라고 말하고 싶다.

 

 요약

PART 01 가깝고도 먼 개발자

p.43~45 협업을 잘하는 개발자

 협업을 잘하는 개발자는 문제를 해결하는 데 상당히 집요한 점이 있다. 기획자가 제시한 문제나 개발자 스스로 발굴한 문제를 해결할 때까지 집요하게 분석하고 수정하여 원하는 결과를 만들어낸다. 비지니스를 이해하는 개발자는 고객의 관점에서 먼저 생각하고, 회사에 이익을 가져다 줄 수 있는 것이 무엇인지를 고민하여 더 좋은 대안을 제시하기도 한다. 그러면 자연스럽게 커뮤니케이션 비용은 줄어들고, 서비스를 빠르게 실행하고 검증하는 과정을 통해 여러 가지 비지니스 모델을 시험해볼 수 있다. 스스로 비즈니스를 운영할 수 있는 정도의 능력을 갖추었다고 볼 수 있기 때문에 많은 회사에서 찾는 인재상이다. 협업에서는 모두가 이해하기 쉽게 소통하는 것이 중요하다. 협업을 잘하는 개발자들은 보통 누구나 이해하기 쉽게 말하는 기술을 갖고 있다. 개발자는 요청을 받은 업무를 마지막에 처리하기 때문에 항상 일이 쌓인 상태로 일을 하게 된다. 거의 매일 새로운 일이 생기기 때문에 업무를 체계적으로 관리하는 습관이 매우 중요하다. 업무 관리는 업무를 정리하는 것뿐만 아니라 업무 일정을 조율하는 것, 담당한 업무를 정해진 시간 내에 끝내는 것, 변하는 상황에 따라 피드백을 하는 것까지 모든 과정을 포함한다. 협업을 잘하는 개발자는 자신의 업무 현황을 잘 알고 있다. 체계적인 업무 관리와 빠른 피드백은 업무에 대한 책임감과도 깊은 연관성을 가진다.

=> 집요한 문제 해결, 비지니스를 이해하는 눈, 쉽게 말하는 소통의 기술, 체계적인 업무 관리와 빠른 피드백

 

p.48~50 원활한 협업을 위한 준비

 가장 먼저 해야 할 일은 함께 일하는 사람들끼리 공동의 목표를 공유하고 달성하기 위해 노력하는 것이다. 중요한 것은 설정한 목표를 팀 모두에게 공유하는 것이다. 때때로 설득이 되지 않아 얼굴을 붉히는 경우도 생긴다. 그럼에도 같은 목표를 공유하고 있다면 대부분의 갈등은 목표를 달성하는 과정에 불과하다. 그럴 때일수록 같은 목표를 공유한 팀이라는 생각을 심어주는 것이 중요하다. 팀의 목표를 중심으로 협업을 하다 보면 언제 그랬냐는 듯 원활하게 협업하고 있는 자신을 경험하게 될 것이다.

 기획자는 서비스를 개발하기 위해서 경영진부터 디자이너, 개발자까지 가장 폭넓게 소통을 한다. 디자이너는 기획된 내용을 토대로 사용자의 사용 경험과 시각적인 경험을 디자인한다. 개발자는 기획과 디자인 시안을 토대로 실제 서비스를 구현한다. 프론트엔드 개발자가 서비스의 뼈대와 동작을 구현하면, 백엔드 개발자는 서버와 데이터베이스 등을 구축하여 서비스를 완성한다. 기획자, 디자이너, 개발자는 함께 일을 하지만 너무나 다른 사고 방식을 갖고있다. 어쩌면 이들이 부딪히는 일이 생기는 건 당연할지도 모른다. 서로의 일을 이해하고 존중하면서 소통해나가자.

=> 목표를 공유한 동료되기, 다른 업무 이해하기

PART 02. 기획자의 일

p.55~56

 첫 번째로 서비스의 비지니스 방향을 찾고 두 번째로 앞서 발견한 방향성과 목적에 맞게 구체화할 방안을 찾은 다음 마지막으로 스케치를 실제 산출물로 만드는 단계를 거쳐 일한다. 서비스 기획자의 최종 산출물은 화면 설계서다. 즉, 서비스 기획자는 서비스의 방향성에 따라 목적과 기준을 정하고 구체적인 실행 방법을 설계하고 제안하는 역할을 한다.

 

p.61

 서비스의 주요 기능들을 정리하고 핵심 기능 중심으로 PoC(Product of Concept)를 만들어 실제 예상되는 서비스의 형태를 시각화하함으로써 한 번 더 방향성을 검증하고 서비스 진행 유무를 최종적으로 판단한다. 실제 서비스를 개발하기 위해 상세한 기능 명세서를 작성하고 서비스의 구조를 잡는 IA(Information Architecture)를 작성한다. 개발자와 긴밀한 협의가 진행되고 개발 범위, 일정, R&R(Role and Responsibilities) 등을 확정한 최종 WBS(Work Breakdown Structure) 문서를 작성한다. 스타트업은 기본적인 시장 조사와 타깃을 정해서 일단 빠르게 MVP(Minimum Viable Product)를 출시하는 데 주력하는 경우가 많다.

 

p.66

 협업을 잘하기 위해서는 서비스 전체를 볼 수 있는 IA(Information Architecutre)를 작성할 수 있어야 한다. IA는 서비스 전체를 체계적으로 구조화한 문서다. 

 

p.69

 기능 리스트업이 끝났으면 해당 기능들을 토대로 구조화를 시작한다. 이때 사용하는 개념은 2가지로, MECE와 하이라키 구조 기법이 있다. MECE(Mutually Exclusive Collectively Exhaustive)는 '항목들이 상호 배타적이면서 모였을 때는 완전히 전체를 이루는 것'을 의미하는데 문제 해결 기법으로 사용하는 유명한 전략적 사고 기법이다. 하이라키(Hierarchy)는 상하 위계 구조를 의미하는데 각각의 정보들이 부모-자식 관계를 갖는 구조화된 형태를 말한다. IA에서 하이라키 위계는 Depth 또는 Level로 구분한다.

 

p.78~79

 웹 사이트를 기획할 때 처음 하는 일은 사이트의 전체적인 구조를 잡는 것이다. 기본적으로 웹 사이트의 구조는 GNB - LNB - SNB - CONTENTS - FNB 순으로 구분된다.

메뉴 구조 용어 정리
GNB: Global Navigation Bar의 약자로 웹 사이트에서 가장 최상위 메뉴를 정의하는 역할
LNB: Local Navigation Bar의 약자로 GNB의 아래 단계인 서브 메뉴를 구성
SNB: Side Navigation Bar의 약자로 GNB와 LNB를 제외한 나머지 메뉴들을 지칭할 때 사용
CONTENTS: 웹 사이트 화면의 콘텐츠 영역
FNB: Foot Navigation Bar의 약자로 기업의 정보나 저작권, 사이트맵, 법률 정보 등을 표기하는 용도

 

p.84

 화면 설계서 작성(기획팀) -> 기술 검토(개발팀) -> 디자인 진행(디자인팀) -> 디자인 시안 협의(기획팀) -> 개발 진행(개발팀) -> QA/QC (QA/QC팀) -> 운영 서버 배포(개발팀)

 

p.86

 As - Is 현재 상황 => To - Be 개선 방향

PART 03. 디자이너의 일

p.101

UX(User Experience): 사용자가 시스템, 제품, 서비스를 직간접적으로 이용하며 느끼고 생각하게 되는 총체적인 경험
UI(User Interface): 사람과 사물 또는 시스템, 기계, 컴퓨터 프로그램 등 사이에서 의사소통을 할 수 있도록 만들어진 매개체

 

p.112

 색 공간은 CMYK, RGB, HSL이 있으며 편집 디자인에는 CMYK 색 공간을, 웹 디자인에는 RGB 색 공간을 사용하고 있다. CMYK는 C(Cyan), M(Magenta), Y(Yellow), K(blacK)의 약자로 인쇄에서 사용되는 색 공간이다. 디지털에 사용되는 색상인 RGB보다 표현 가능한색상이 적기 때문에 정확한 색상을 출력하기 위해 Pantone의 컬러 칩을 사용하기도 한다. HSL은 (Hue 색상, Saturation 채도, Lightness 명도)의 약자로 빛의 삼원색을 표현하는 RGB(Red, Green, Blue)와 다르다. RGB는 CMYK보다 더 많은 색상을 지원한다.

 

p.113

 웹에서 보이는 색상이 사용자마다 다르게 보일 수 있는데 모든 기기와 브라우저에 표준적으로 사용되는 sRGB 컬러 프로파일을 사용하는 방법으로 문제를 최소화할 수 있다.

sRGB: 표준적으로 사용되는 RGB 프로파일
P3: sRGB보다 25% 더 넓은 색 표현이 가능하며 애플 기기에서 사용되는 프로파일
Adobe RGB(ARGB): sRGB보다 더 넓은 색 영역을 이용할 수 있지만 일반적인 모니터로는 색을 표시하기가 어려운 프로파일

 

p.114

 개발자에게 색상 코드를 전달해줄 때는 HEX, RGB, HSL 등 다양한 표기법이 있다. HEX(16진수) 표기법은 웹 컬러 적용 시 가장 많이 사용되는 표기법으로, #을 작성하고 여섯 자리 16진수를 입력하는 방법이다. (#FF5733) RGB 표기 방법은 R(적), G(녹), B(청) 세 가지 색상을 표기하는 방법으로 각 256개 숫자로 표시하며 가장 낮은 색의 값은 0, 높은 값은 22로 작성한다. (rgb(255, 87, 51)) 그외 hsl, rgba, hsla가 있고 가장 흔하게 쓰이는 표기법은 HEX이고, 그밖에는 RGB/ RGBA 표기법으로 많이 사용한다.

 

p.118

 이미지 포맷은 비트맵과 벡터 방식으로 나누어진다. 비트맵 이미지는 작은 픽셀들이 모여 하나의 이미지를 만드는 형태로, 확대하게 되면 깨져보이는 특징을 가지고 있다. 벡터 이미지는 점과 선으로 이루어진 이미지로, 확대를 해도 깨지지 않는 점이 특징이다. 비트맵 방식의 이미지는 JPG(JPEG), GIF, PNG가 있고 벡터 방식은 SVG가 있다. JPG(JPEG)는 대표적인 손실 압축 포맷으로 압축할 경우 이미지 품질은 떨어지지만 용량을 많이 줄일 수 있다는 장점이 있고 PNG는 대표적인 무손실 압축 포맷으로 이미지 품질의 손실이 없으며 투명도 표현이 가능하지만 JPG보다 용량이 크다는 단점이 있다. SVG는 이미지를 확대하거나 축소해도 깨지는 현상이 없고 XML로 작성이 되어 코드로 색상을 수정하거나 여러 가지 애니메이션 동작을 만들어낼 수 있다는 장점이 있다.

 

p.124~126

 폰트 파일 중 경량화된 서브셋(Subset) 웹 폰트 파일이 있다. 이는 사람들이 자주 사용하지 않는 글자들을 줄인 것으로 파일 용량을 줄여줄 수 있지만 자주 사용하지 않는 글자여도 가끔 쓰일 수 있는 게시판이나 커뮤니티 서비스 등에 올바르게 나타나지 않으므로 고려해서 사용해야 한다.

 폰트 파일의 포맷은 다양하다. 그중에서 일반적으로 모든 브라우저를 지원하는 형식의 포맷은 EOT, TTF, WOFF, WOFF2이다. 용량 순으로 정리하면 TTF > EOT > WOFF > WOFF2가 된다. TTF 파일이 용량이 가장 크며 WOFF2 파일이 용량이 가장 적다. 구글에서 제공하는 웹 폰트를 활용하는 방법도 있다. 개발자에게 별도의 폰트 파일을 넘겨주지 않아도 된다. 이런 웹 폰트 방식을 CDN(Content Delivery Network)라고 하는데, 이를 활용하면 폰트 파일을 서버에 직접 업로드하지 않기 때문에 트래픽 면에서 더 효율적이다.

 

p.143

크롬의 개발자 도구
Elements: HTML, CSS 코드를 보며 디자인 수정을 할 수 있는 패널
Console: 로그 확인 및 스크립트 명령어를 입력하는 패널
Sources: 자바스크립트 디버깅(Debugging)을 할 수 있는 패널
Network: 네트워크 모니터링 패널
Performance: 웹 페이지에서 발생하는 이벤트 탐색 채널
Memory: 메모리 사용 상태를 확인하는 패널
Application: 웹 페이지에 사용된 리소스를 확인하는 패널
Security: 인증서, 보안과 관련된 패널
Lighthouse: 웹 품질, 성능 검사 및 개선 패널

 

p.148~151

 적응형 웹은 사용 중인 기기를 감지하여 그에 최적화된 웹을 보여준다. 따라서 사용자가 접속한 기기에 맞는 리소스만 내려받아 사용 속도가 빠른 장점이 있지만 PC/태블릿/모바일 등 기기에 따라 별도로 디자인과 개발을 해야 한다는 단점도 있다. 반면 반응형 웹은 CSS3의 미디어 쿼리 코드를 사용하여 사용자의 디바이스 크기를 확인하고 크기에 맞게 UI가 변경되는 형태이다. 따라서 기기마다 개발을 하지 않아도 되지만, 모든 리소스를 담고 있어서 사용 속도가 느리다는 단점이 있다. 적응형은 웹 버전, 모바일 버전을 각각 디자인하게 되는데, 반응형은 화면 크기에 따라 UI가 바뀌므로 바뀌는 시점마다 콘텐츠를 어떻게 배열할지 개발자에게 전달해주어야 하며 그리드를 활용하면 배열을 쉽게 할 수 있다.

 그리드는 마진(Margin), 칼럼(Columns), 거터(Gutter)의 구조로 이루어진다. 마진은 그리드의 좌우 끝 여백, 칼럼은 글자나 이미지 등 콘텐츠를 포함하는 부분, 거터는 칼럼의 간격을 말한다.

 

p.153

 스탯카운터에서 통계한 모바일 기기 해상도는 2019-2020년 국내 점유율을 보면 412x846 크기는 14.27%, 412x869 크기는 13.9%, 360x740 크기는 7.53% 등 점유율이 크게 차이가 나진 않는다. 하지만 전 세계 기준으로 차트를 보면 360x640 크기는 15.28% 다른 해상도는 6%대로 차이가 있다. (https://screensiz.es)

 

p.158

 놓치기 쉬운 항목에는 첫째로 빈 페이지, 에러 페이지 디자인하기가 있다. 그리고 오픈 그래프(og, open graph)는 웹 사이트의 URL를 복사하여 공유하면 썸네일 이미지, 타이틀, 간단한 페이지 설명 등이 나오는데 이 부분을 가리킨다. HTML 문서 상단의 <head> 태그 안에는 <meta>라는 태그를 활용할 수 있다. og:image, og:title, og:description. 이미지의 크기는 800x800 픽셀의 PNG 이미지에 저장 용량은 15KB 내외로 제작하는 것이 적당하다. 파비콘(favicon)은 'favorites icon'을 줄인 말로 웹 페이지에 상단 탭과 즐겨찾기를 추가했을 때 보이는 아이콘을 말한다. 기본적으로 웹에 적용되는 파비콘의 크기는 16x16 픽셀로 제작하며 배경은 투명으로 설정하여 PNG로 저장한다. 파비콘의 기본 확장자는 ICO 파일이라 포토샵으로 PNG 파일로 제작한 뒤 ICO 변환 사이트를 통해 변환할 수 있다. (PNG 파일도 가능)

PART 04. 개발자의 일

p.166

 웹 개발자는 크게 프론트엔드 개발자, 백엔드 개발자로 나누어볼 수 있다. 프론트엔드 개발자는 사용자에게 보이는 영역인 클라이언트 화면을 개발하며 디자이너가 만든 시안을 토대로 퍼블리싱을 하거나, 다양한 기능을 제공하는 웹 애플리케이션 개발을 하기도 한다. 백엔드 개발자는 사용자에게 보이지 않는 서버를 구축하고 데이터베이스, 데이터 관리, API 등의 개발을 하며 다양한 서버 기반 언어로 클라이언트에서 요청하는 데이터를 전달하는 작업을 한다.

 

p.168

 프론트엔드 개발의 대표적인 개발 언어는 자바스크립트가 있다. 객체 기반 스크립트 언어로 웹 사이트에서 문서 객체 모델(DOM: HTML 문서의 태그를 객체화하여 스크립트로 제어)과 브라우저 객체 모델(BOM: 뒤로 가기, 북마크, 즐겨찾기, 히스토리, 주소, 스크롤 등 브라우저의 기능을 스크립트로 제어) 두 가지 모델을 제공하여 HTML의 문서와 브라우저 기능을 제어할 수 있다.

 

p.171

 프론트엔드와 백엔드 언어가 동일한 경우 여러 가지의 프레임워크를 활용하여 효율적으로 서비스를 구축할 수 있는데, 대표적으로 MEAN Stack(민 스택)이 있다. MEAN Stack은 MongoDB(데이터베이스), Express.js(웹서버개발), Angular.js(프론트엔드), Node.js(서버구축)로 구성된 웹 프레임워크를 말하며 각각의 기술의 철자 앞 글자를 따와 지어진 것이다. 자바스크립트 언어만 익히고 있어도 4가지 프레임워크를 어렵지 않게 배울 수 있어, 혼자 개발하는 풀스택 개발자들에게 용이하게 사용되고 있다.

 

p.172~173

 애플에서는 iOS, macOS, watchOS, tvOS라는 4가지 운영체제를 제공한다. iOS의 애플리케이션은 Swift 혹은 Objective-C 언어로 개발을 한다. Objective-C는 앱의 안전성을 보장할 순 있지만 최근 기술 문서나 관련 자료가 많이 없는 반면에 Swift는 최근에 각광을 받는 언어이다. Swift는 애플에서 직접 개발한 언어이며 오픈 소스로 공개되었다. Mac 환경에서만 개발할 수 있고 배포 또한 XCode라는 Mac 전용 개발 도구에서 가능하다. 개발 도구인 XCode는 스토리보드라는 UI 편집도구를 제공한다. 보이는 대로 UI를 편집할 수 있으며, View와 View 간에 이벤트를 코딩 없이 개발할 수 있다. 테스트플라이트(TestFlight)는 애플에서 공식으로 제작한 앱으로, 내부 테스트로 활용할 수 있고 실제 사용자 대상으로 외부 테스트(CBT, Closed Beta Test)로도 활용할 수 있다. QA를 진행하고 테스트를 꼼꼼하게 진행한 후 스트어에 앱을 배포하고 협업하는 과정이 필요하다.

 

p.174

 iOS + 안드로이드 개발을 합친 하이브리드 앱 개발자 방식이 생겼다. 바로 웹뷰 패키징 방식과 네이티브 빌더 방식이다. 웹뷰 패키징 방식은 모바일 웹을 개발하고 안드로이드와 iOS의 웹뷰 UI에 연결하는 방식이다. 일반 모바일 웹 브라우저에서도 동일하게 보이지만 UI 정보를 웹 서버에서 디자인 소스를 요청하여 보여주기 때문에 네이티브보다 느리다. UI의 모션도 네이티브보다 자연스럽지 않을 수 있고 블루투스, 와이파이, 카메라, NPC, GPS, 로컬 스토리지 등 디바이스의 기능을 사용하기가 매우 힘들다는 단점도 있다. 네이티브 빌더 방식은 네이티브 빌더 프레임워크를 이용하여 환경에 맞게 네이티브 빌더로 앱을 제작하는 방식이다. React Native와 Vue Native가 있다. 빌드 및 배포를 하면 네이티브와 동일한 기능을 제공한다.

 

p.176~184 소통에 필요한 개발 용어

- 서버와 호스팅: 웹 페이지가 브라우저에 나타나려면 서버가 필요하다. 서버는 인터넷과 연결된 컴퓨터를 말하며 호스팅은 서버를 임대해주는 서비스를 말한다. 대체로 큰 규모의 회사는 직접 서버를 관리하지만, 소규모 회사나 개인이 운영하는 경우에는 유지 비용이 많이 드니 전문 웹 호스팅 회사에서 운영하는 서버를 사용하기도 한다.
- 프로토콜: 컴퓨터, 서버, 네트워크 장비가 통신할 수 있도록 공용화된 언어를 프로토콜(Protocol)이라 한다. 대표적인 프로토콜로는 HTTP, HTTPS, FTP, TCP/IP, POP 등이 있다.
- HTTP/HTTPS: HTTP는 하이퍼텍스트 전송 프로토콜(HyperText Transfer Protocol)의 약자로 서버에서 데이터를 전송해주는 가장 기본적인 프로토콜 중에 하나이다. 하지만 HTTP는 전송되는 데이터가 암호화되지 않아 내용이 노출될 수 있다. 이러한 보안 문제를 보완해주는 프로토콜이 HTTPS(HyperText Transfer Protocol Secure)이다.
- SSL(Secure Socket Layer): 보안 소켓 레이어의 약자로 Netscape사에서 서버와 브라우저 사이의 데이터 보안을 위해 만들어졌다. 웹 사이트에 개인 정보를 취급하는 모든 사이트는 SSL 인증을 필수로 해야 하고 SSL을 구축하면 HTTPS 프로토콜을 구성할 수 있다.
- FTP(File Transfer Protocol): 서버에 파일을 전송하기 위한 프로토콜을 말한다. 서버를 구축하거나 호스팅 업체를 통해 대여한 서버에 웹 페이지 구축에 필요한 이미지, 코드 파일 등을 업로드할 수 있다.
- DNS(Domain Name Server): 네트워크에 연결된 컴퓨터나 스마트폰 등의 장치들은 서로 구분할 수 있는 IP 주소를 가진다. IP 주소를 문자로 변환하여 사람들이 쉽게 접속할 수 있도록 만든다.
- 클라이언트와 서버: 클라이언트(Client)는 서비스를 제공 받는 유저를 말하고 서버(Server)는 서비스를 제공하고 데이터를 저장하는 컴퓨터를 말한다. 클라이언트 개발 영역을 프론트엔드, 서버 개발 영역을 백엔드라고 부르기도 한다.
- 프레임워크(Framework): 특정 개발 언어를 개발하고자 하는 목적에 맞게 쉽게 작성할 수 있도록 뼈대를 갖추어 개발자가 손쉽게 빠르게 구현할 수 있도록 만든 것으로 프레임워크 안에는 '라이브러리' 코드가 포함되어 있다.
- 라이브러리(Library): 필요한 기능을 모아둔 도구를 말한다. 프레임워크를 지정했다면, 그에 맞는 기능을 구현하기 위해 미리 짜여진 '라이브러리' 코드를 가져와서 더 쉽고 빠르게 개발할 수 있다.
- 리팩토링(Refactoring): 개발 코드의 기능을 바꾸지 않으면서 코드의 가독성을 높이고 수정하기 쉽게 만드는 과정을 말한다. 리팩토링을 진행하면 버그를 발견하거나 줄일 수 있고 개발 속도를 단축할 수 있다.
- 디버깅(Debugging): 서비스에서 나타나는 오류인 버그의 원인을 찾안애고 수정하는 작업 과정을 말한다. 개발하는데 가장 많은 시간을 할애하는 과정이기도 한다.
- API(Application Programming Interface): 개발자가 만든 특정 기능을 다른 사람이 사용할 수 있도록 모듈화한 것을 말한다. 오픈 API는 누구나 사용할 수 있도록 공개한 것이지만 사용된 코드는 숨겨서 공유할 수 있다. (소셜 로그인 API, 지도 API 등)
- 예외 처리: 사용자가 원활하게 사용할 수 있도록, 예외가 발생할 경우를 미리 예상하고 에러 메시지나 페이지를 띄워주는 등으로 대응하는 것을 말한다.
- 컴파일(Compile): 작성한 코드를 컴퓨터가 이해할 수 있는 기계어로 변환하는 작업을 말한다. 컴퓨터가 이해할 수 있는 언어로 변환시키기 때문에 실행 속도가 빠르다.
- 빌드(Build): 개발 코드 파일은 하나로 작성되는 것이 아니라 여러 개의 파일로 만들어진다. 이 파일들을 모아 압축시켜 하나의 실행 파일로 만들거나, 컴파일된 코드를 실행할 수 있는 상태로 만드는 작업이다.
- 배포(Deploy): 빌드가 완성된 실행 파일을 사용자가 실행할 수 있는 환경에 업로드하는 것을 말한다. 
- 핫픽스(Hotfix): 서비스에 버그, 오류, 장애가 발생했을 때 긴급 배포를 하기 위한 코드 작업을 말한다.
- SDK(Software Develpment Kit): 개발, 디버깅 프로그램, API 등 응용 프로그램을 만들 수 있게 해주는 개발 도구.
- APK(Android Package Kit)/IPA(iOS App Store Package): 안드로이드/iOS에서 동작하는 애플리케이션 확장자다. 두 가지 모두 디바이스에 앱을 설치하는 역할을 한다.
- IDE(Integrated Develpment Environment): 개발을 할 때 소스 코드 작성, 디버깅, Git, 컴파일 등의 작업을 한 곳에서 할 수 있게 만든 프로그램을 말한다. (인텔리J, Xcode, Visual Studio 등)
- 리눅스(Linux): 컴퓨터 운영체제 중 하나로 유닉스(UNIX) 운영체제 기반으로 만들어졌다. 적은 비용으로 웹 서버, 메일 서버, FTP 등을 구축할 수 있어 개인이나 중소기업에서 많이 사용되는 서버이다. 공개 운영체제와 오픈 소스로 누구나 자유롭게 수정하고 배포할 수 있는 것이 특징이다.
- 동기 방식(Synchronous)/비동기 방식(Asynchronous): 서버에서 데이터를 처리하는 방법으로 동기 방식은 요청한 순서대로 데이터를 처리하고 하나의 데이터를 처리하는 동안 다른 데이터는 정지한다. 비동기 방식은 요청한 순서에 상관없이 데이터를 처리하는 동안 다른 데이터도 요청할 수 있는 개발 방식을 말한다.
- 워터폴 방법론/애자일 방법론: 워터폴은 완전히 기획이 끝난 이후에 개발을 하는 개발 방법론이고, 애자일은 서비스를 단위로 쪼개어 특정 기간 안에 개발 범위를 세분화하고, 점진적으로 고도화하는 개발 방법론을 말한다.
- 모듈(Module): 프로그램을 구성하는 요소의 일부로, 기능별로 나누어지는 프로그램을 말한다. 개발을 하다 보면 코드의 양이 방대해지는데, 많은 코드를 한 페이지에 넣는다면 유지 보수를 하거나 다른 개발자와 공유를 하기 힘들어진다. 그래서 기능별로 코드를 작성하는데, 이를 모듈화(Modularization) 프로그래밍이라 말한다. 자체적으로 모듈을 지원하는 언어로는 Python, Ruby, Pascal 등이 있다.
- 하이브리드 앱(Hybrid App): HTML 기반으로 제작된 모바일 웹앱을 네이티브 앱으로 제작한 것을 말한다. 네이티브 앱과 모바일 앱의 특성이 공존하는 앱 형태이다.