[번역] 2020년에 풀스택 웹 개발자가 되는 방법

 

* 이 글은 Colby Fayock의 'How to Become a Full Stack Web Developer in 2020'을 저자의 허락을 받고 번역한 글입니다.

오역에 대한 조언과 피드백은 댓글로 남겨주시면 감사하겠습니다.

이 글이 누군가에게 도움이 되길 바랍니다 ^^

 

 

---

 

 

 

풀스택 웹 개발자는 코딩 세계에서 맥가이버 칼이나 다름없습니다. 이 칭호를 단다는 건 시장성이 뛰어나며 애자일한 스킬셋인 엔드 투 엔드 솔루션을 고안할 수 있다는 뜻이죠. 그런데 이 경지에 이르기까지 실제로 어떤 게 필요할까요?

 

여러분이 뉴비든 경험자든 한쪽 스택에 특화된 사람이든, 이 글엔 소화해야 할 게 많습니다. 이 글을 처음부터 읽든 가장 필요한 부분을 읽든 여러분 자유입니다.

 

• 먼저, 웹 개발자를 '풀스택'으로 만드는 건 뭘까요?

• 시작 전 주목하세요

• 그래서 뭐부터 시작하죠?

• 프론트엔드

• 백엔드

• 데브옵스(역: 이하 DevOps)와 클라우드

• 디자인은 어떡하죠?

• 갓 시작한 뉴비라면...

• 좀 더 찾아보고 있다면...

 

 

먼저, 웹 개발자를 '풀스택'으로 만드는 건 뭘까요?

'프론트엔드 개발자라면 누구나 풀스택 개발자'란 말은 솔깃하고 흥미로운 얘기죠. 하지만 Netlify에 웹 사이트를 배포할 수 있다고 풀스택 개발자가 되는 건 아닙니다.

좌절시키려는 말이 아닙니다―단지 현실적으로 따져보자는 거죠. 그 경험만으로는 여러분의 다음 입사 면접에서 풀스택 개발자란 이름표를 달고 있기가 버거울 겁니다. 여러분이 처음부터 끝까지 만들고 배포한 게 맞긴 하지만 Netlify, Vercel(역: 구 Zeit 현 Vercel), 그 외 서비스 제공 업체들이 작업의 대부분을 차지하는 마법의 도구를 여러분 손에 쥐어준 거니까요.

그 사실이 프론트엔드 개발자로서 성취할 수 있는 것들을 우리 손에서 뺏어가는 건 아닙니다. 정적 웹 사이트를 컴파일하고 배포하려는 움직임이 점차 늘어나며 배포까지 프로세스가 더욱 간단하게 변하는 등 전반적으로 이점을 누릴 수 있게 됐으니 말입니다. 덧붙여 서버에서 자바스크립트(역: 이하 JS)를 실행하는 것과 같은 툴링 옵션의 유연성을 통해 스킬셋은 보다 많은 사용 사례(use cases)들로 옮길 수 있게 됐죠.

 

지난 행적

웹 개발 환경은 빠르게 변해 왔습니다. 한동안 CMS(Content Management System)의 왕이었던 워드프레스는 CMS를 사용하는 웹 사이트의 1/3 이상을 차지했고 PHP가 유명세를 얻는 것도 도왔습니다. 이 와중에 어떤 사람들은 자체 솔루션을 개발했죠.

https://trends.builtwith.com/cms

이는 LAMP(Linux, Apache, MySQL, PHP)와 같은 전통적인 웹 스택을 나타냅니다. 이 경우 웹 서버는 일종의 콘텐츠 관리 시스템과 데이터베이스와 인터페이스하며 궁극적으로 브라우저에 전해질 코드를 짜는 PHP 같은 서버 사이드 언어를 실행합니다.

뿐만 아니라 CSS로 웹 페이지 디스플레이를 관리하는 대화형 기능을 JS로 만들 수도 있습니다. 지금은 웹 호스팅을 위해 잘 관리되는 워드프레스 서버만 필요한 경우도 있습니다. 하지만 다른 대규모 웹 사이트들은 코드를 실제 프로덕션으로 바꾸기 위해 서비스와 배포 파이프라인을 관리하는 팀이 따로 필요합니다.

 

현재 상황과 향후 방향

워드프레스의 기세는 여전하지만, 서버리스와 JAMStack(Javascript, APIs, Markup stack) 아키텍쳐가 요즘 한창 탄력 받아서 붐입니다. 익숙하지 않은 사람들을 위해 설명하자면, 서버리스는 진짜 서버가 없다는 말이 아니고 클라우드에서 관리해주는 서버를 쓴다는 겁니다.

AWS 람다와 같은 서비스로 간단한 입출력을 처리하는 "함수"를 만들 수 있습니다. API 게이트웨이에 연결하면 실제 서버를 관리할 필요도 없이 즉시 엔드포인트와 인터페이스할 수 있게 됩니다.

S3와 같은 서비스들은 여러분이 HTML, CSS, JS, 이미지, 그 외 정적 자료라면 뭐든지 스토리지에 저장하게 해서 웹 사이트로 바로 전달합니다. 서버에서 프로세싱되는 것도 없습니다. 그냥 그 정적 파일들을 클라이언트에게 제공하는 거죠.

가장 우수한 점은 오버헤드도 더욱 적고 일반적으로 훨씬(훨씬!) 저렴하다는 사실입니다. 대개 눈에 띄는 성능 향상도 덤으로 얻게 되는데, S3에서 웹 사이트를 서비스할 때 브라우저에 보내는 첫 번째 응답을 얻기 위한 처리량이 줄어들기 때문입니다. 이건 사용자 경험(UX) 개선과 직결되는 부분이죠.

 

좋은 UX에 따봉!

JAMStack을 쓰라고 강요하는 건 아닙니다. 풀스택 패러다임이 변화하고 있으니 한 번 살펴볼 가치가 있다는 거죠. 작업의 차이에 대한 관습적 생각이 여전하긴 해도 조금씩 달라지고 있습니다.

이제 DevOps 팀은 클라우드 리소스를 관리하고 배포하는 작업을 도맡고 있습니다. 백엔드 개발자들은 람다 함수와 같은 도구를 이용해 서비스와 인터페이스하는 API를 만들고 코드를 짜고 있죠. 그리고 프론트엔드 개발자는 주로 JS로 작업하는데 백엔드 개발자가 만든 서비스와 연결되는 리액트(역: 이하 React)나 뷰(역: 이하 Vue) 앱을 만듭니다. CSS 같은 걸 포함할 수도 있고 아닐 수도 있지만 그건 "공식적으로" 작업한다는 명목 하에 있는 또다른 문제입니다. (팀에 따라 다릅니다)

일의 영역을 나누는 게 여전하긴 하지만, 그 경계가 서서히 무너지면서 자칫 여러분의 집중력이 쉽게 흐트러질 수 있습니다.

 

 

시작 전 주목하세요

소매 걷어붙이고 바로 뛰어들어 풀스택 개발자가 하는 모든 것들을 다 해보고 싶은 유혹이 크겠지만 집중 얘기를 좀 해야겠습니다. 이것은 "열두 가지 재주에 저녁거리가 없다"(원문: jack of all trades, master of none)라는 격언에 기초한 말입니다. 여러분이 풀스택 개발의 모든 부분을 살짝 찔러만 볼 생각이라면 결국 아무것도 완벽하게 익히지 못할 거란 얘깁니다.

신입 개발자로서 시작하며 강점을 쌓으려고 할 때 위험할 수 있습니다. 그러니 여러분이 어떤 식으로 학습하는지 따져보고 중요한 부분에 초점을 맞추세요. 만약 크게 확장된 커리큘럼으로 난감하다면, 그건 사실 여러분의 첫 직장 혹은 꼭 가고 싶은 꿈의 직장에 갈 수 있는 경험을 쌓는 데 꼭 도움 되는 게 아닐 수도 있습니다.

예를 들면 새로운 접근법으로 개별적 집중을 한다고 쳐 봅시다. 그 강점으로 풀스택 스킬을 쌓을 수도 있습니다. 자기가 만든 웹앱을 배포하고 기본 지식을 바탕으로 계속 만들 수 있는 프론트엔드 개발자가 될 수도 있고요.

덧붙여 풀스택 개발자가 된다는 게 꼭 여러분이 여러 언어를 알아야 한다는 건 아닙니다. 여러분을 좋은 개발자로 만들어 주는 건 코드와 소프트웨어 설계 개념을 이해하고 문제를 해결할 수 있는 능력입니다.

결론입니다: 여러분에게 뭐가 가장 좋을지 알아 보세요. 그리고 여러분의 지나친 의욕이 여러분의 여정을 방해하지 않도록 조심하세요.

 

미야기 선생님이 동의합니다

 

 

그래서 뭐부터 시작하죠?

이 글의 목적상 우리는 스택을 나누는 관습적인 브레이크 포인트를 살펴볼 겁니다. (프론트엔드, 백엔드 등) 혹자는 그건 더 이상 별 거 아니라고 얘기하지만 현실적으로 풀스택 개발자를 위한 일이 어마어마하게 많으며 그들은 날마다 그 '관습적인' 브레이크 포인트를 참조합니다. "풀스택 개발자"는 건재할 거란 얘기죠.

우리는 꾸준히 증가하고 있는 서버리스/JAMStack 아키텍쳐에 잠시 기대볼 겁니다. 여러분이 그걸 배운다면 늘어나는 일자리 숫자와 함께 구직 시장에서 여러분의 위상도 더 높아질 것입니다.

 

붐샤카라카!

밑에서 보겠지만 그게 모든 종류의 데이터베이스와 렌더링 솔루션을 몽땅 다루게 될 거란 얘긴 아닙니다. 좋은 개발자라면 하나의 프레임워크에서만 실력 발휘하는 외곬이 되기보다는 연장이 뭐가 됐든지 유연하게 다루고 작업 개념을 잘 이해할 수 있어야 합니다.

여러분이 React로 작업하고 현 직장에서 편할 수 있는데(그건 괜찮죠) 다음 직장에서는 Vue를 쓰게 되거나... 놀라지 마세요! 팀장이 Svelte로 앱을 다시 짜고 싶다고 할 수도 있습니다! 우선 UI(User Interface) 프레임워크를 쓰는 이유 그리고 그게 어떻게 문제 해결에 도움이 되는지 이해하려 노력해 보세요.

이제 시작해 봅시다.

 

 

프론트엔드

웹 사이트나 앱의 프론트엔드는 통상적으로 사용자가 서비스와 상호작용할 수 있는 UI를 말합니다. 이 판의 1인자는 JS입니다. 일반적으로는 프로젝트 컴포넌트들을 관리하려고 React나 Vue 같은 UI 라이브러리를 쓰죠.

UI 프레임워크를 쓰면 기본적으로 코드 블록인 "컴포넌트"를 만들 수 있습니다. 이를 통해 코드와 상호작용하고 동적 상태를 생성할 수 있는 HTML 파일을 만들 수 있고요. 시작할 땐 굴곡이 있을 수도 있지만 한 번 요령을 터득하고 나면 작업이 아주 즐거워집니다.

여러분이 뉴비든 경험자든 결국엔 제이쿼리(역: 이하 jQuery)와 만나게 될 겁니다. jQuery는 장점도 있고 커뮤니티에도 이바지했지만 JS 자체 기능이 개선되면서 jQuery가 제공해 오던 기능들에 대한 수요도 줄었습니다. 이제 개발자들은 jQuery 대신 UI 프레임워크와 바닐라 JS를 쓰고 있습니다.

jQuery가 뭔지 이해하는 건 좋습니다. 하지만 지금 시점에서 jQuery를 배우려고 일부러 시간 내는 건 추천하지 않습니다. 만약 여러분이 jQuery를 쓰는 직장에 들어간다면 바닐라 JS와 함께 jQuery를 쓰는 이점을 누릴 수 있습니다. 그러니 바닐라 JS를 배우는 게 답입니다.

 

그래서 뭘 배우면 되죠?

만약 여러분이 갓 시작하는 단계라면 기본적인 HTML과 CSS를 배우세요. JS에 바로 뛰어드는 것만큼 즐겁진 않을 수도 있지만 웹을 이루는 기본 원리를 잘 익히고 시작하는 게 좋은 첫걸음이 될 겁니다.

그 다음에 JS를 배우세요. 그리 머지않은 미래에도 JS는 여전히 1인자일 테니까요. JS는 여러분이 만드는 앱이 사용하는 모든 프레임워크나 라이브러리의 기초를 제공합니다. JS라는 언어를 요모조모 뜯어보며 작동하는 방식을 이해하는 게 프론트엔드 기술을 배우려는 여러분의 여정에 날개를 달아줄 겁니다. 여러분이 나중에 쓰게 될 다양한 패턴들이 갖는 복잡성이나 프레임워크 뒷면의 숨은 개념을 이해할 때도 더 쉬울 거고요.

프레임워크 얘기를 하자면, 유명세로 따져봤을 때 React와 Vue가 제일 잘 나가는 유망주들일 겁니다. 그 중에서도 React는 가장 인기가 많고 계속 성장하는 중입니다. 프레임워크를 견고히 하고 빠른 모던 웹앱을 위한 API를 만들려고 꾸준히 노력하는 팀이 뒤에 있거든요. (역: Facebook)

 

2019 JS 프레임워크 상황

React 앱을 만들거나 혹은 Gatsby로 시작한다면 React 앱을 시작(spin up, 역: 클라우드 컴퓨팅 서비스를 이용한 VM이나 인스턴스, 또는 그것을 만드는 것)하고 즉시 코드를 만지는 위치에 오르는 데에도 도움이 될 겁니다.

Sass 같은 CSS 전처리기 사용에 따른 장점이 많긴 하지만 이제는 CSS-in-JS를 포함해 CSS를 위한 솔루션이 한 트럭입니다. JS에 CSS를 집어넣는다는 게 장단점이 좀 있지만, 뭘 쓸지 특정하는 건 딱히 쓸모 있는 일은 아닙니다. 어차피 결정권은 팀에 달려 있으니까요.

CSS의 기본과 강력함 그리고 기본적 형태로 쓰는 방법을 이해하세요. 여러분은 프레임워크에 관계없이 CSS를 쓸 수 있게끔 준비된 사람이 될 수 있을 겁니다.

 

Resources

• freecodecamp.org Responsive Web Design Certification

• "Put Down the Javascript: Learn HTML & CSS first"

• MDN Intro to Javascript

• Just Javascript email course

• JSRobot Learning Game

• reactjs.org Intro to React

• gatsbyjs.org Tutorials

 

 

백엔드

JAMStack 세계에서 백엔드는 보통 프론트엔드가 클라이언트의 엔드포인트와 상호작용해서 동적 경험을 생성하는 데 사용하는 API(CRUD API 같은)를 설계합니다. 클라이언트가 이렇게 요청할 수 있다면 웹 페이지가 브라우저로 전송되기 전에 그 어떤 프로세스도 처리할 필요가 없습니다.

여러분 스스로 '난 한 가지 언어로만 코딩할 수 있어'라고 생각하는 건 곤란하지만 JS로 코드를 짤 수 있다면 이점이 있습니다. 익숙한 언어로 백엔드를 작업하며 기본 원리를 통해 성장할 수 있기 때문이죠. (반대로 프론트엔드 경우도 마찬가지)

NodeJS는 여러 클라우드 환경에서 옵션으로 찾아볼 수 있는 일반적 런타임인 데다가 여러분이 브라우저에 예상하는 것과 유사한 경험을 제공합니다. 주된 차이점이라면 특정 브라우저 API에 접근할 수 없고 window 객체와 이에 연관된 API도 없다는 점입니다.

NodeJS가 좋긴 하지만 데이터 사이언스와 엔지니어링 커뮤니티에서의 인기로 따져보면 파이썬도 꾸준히 성장 중인 또 다른 인기 언어라고 할 수 있습니다. PHP와 Ruby는 아직 정정하고 구직 시장에서 선택지도 있지만 JS와 파이썬만큼 인기 있지도 않고 전반적인 상승세에 있는 것도 아닌 것 같습니다.

 

깃허브의 인기 언어들

언어를 하나 고르고 둘 수 있는 가장 좋은 다음 수는 여러분의 앱이 인터페이스할 수 있는 클라우드 서비스를 만드는 법을 배우는 겁니다. AWS, Netlify, 그 외 어떤 클라우드 서비스든 상관없이 갖고 놀 만한 간단한 람다 함수를 만들면 여러분이 실무에서 기대하는 작업에 대한 좋은 경험이 될 겁니다.

만약 여러분이 구하는 직장에서 바로 람다를 쓰진 않더라도 백엔드로 작업하는 데 있어 근본이 되는 개념들에 한층 더 익숙해질 수는 있습니다. 궁극적으로 그런 기능들을 이용해 다른 서비스와 데이터베이스에 연결해서 동적 서비스를 만들 수 있습니다.

 

그래서 뭘 배우면 되죠?

만약 이미 프론트엔드 쪽에서 JS를 배우고 있다면 백엔드에서도 JS를 쓰세요. Netlify의 Function을 사용해 람다를 시작하면 여러분은 그냥 코드에만 집중하면 되고 Netlify가 람다 빌드와 배포를 해주는 등의 나머지 부차적인 일들을 봐줄 겁니다.

선택한 언어와 첫 번째 람다를 이용해 여러분의 코드 내에서 타 서비스와 작업을 시작하고 서드 파티 API와 작업 경험을 쌓도록 합니다. 어쩌면 트위터 API를 이용(남용하진 마세요)해 트윗할 수 있는 엔드포인트를 구축할 수도 있을 겁니다. 데이터베이스를 구축하고 CRUD 패턴과 인터페이스할 수 있도록 기능을 설정하는 법을 배우세요. 일반적인 앱이 어떻게 백엔드와 상호작용하는지 알려주는, 보다 현실적인 사용 사례를 배울 수 있을 겁니다.

여러분의 목표는 앱 사용자를 위한 작업 수행을 위해 프론트엔드가 엔드포인트를 통해 상호작용하는 서비스를 만드는 겁니다. 좋은 소식은 클라우드의 여세와 무료 플랜, 프리 티어 등을 따져봤을 때 갖고 놀 만한 게 산더미처럼 쌓였다는 사실입니다.

 

Resources

• "Super simple start to serverless"

• "Building Serverless CRUD apps with Netlify Functions & FaunaDB"

 

 

DevOps와 클라우드

DevOps는 개발자들로부터 배포 단계의 코드를 얻는 프로세스를 빠르고 원활히 하는 솔루션을 만들어야 한다는 필요에서 시작했습니다.

이 작업은 작은 책임부터 큰 일에 대한 많은 책임에 이르기까지 다양합니다. 그 일이 커스텀 솔루션을 위해 배시 스크립트를 짜는 일이든 앱 실행에 필요한 모든 리소스들을 만드는 클라우드 포메이션(CloudFormation) 템플릿을 쓰는 일이든 상관없이 말이죠. 일반적으로 대규모 CI/CD(Continuous Integration/Continuous Delivery) 작업 흐름(work flow) 오케스트레이션(orchestration, 역: 다양한 단계의 프로세스나 작업 흐름을 자동화하는 법)의 일부로서 이런 기능들이 포함되어 있습니다. 빌드와 배포 프로세스를 자동화하는 일이죠.

 

CI/CD 파이프라인

그리고 이건 지속적으로 변하고 있습니다! 서버리스의 인기가 계속되는 와중 쉽게 작업할 수 있도록 파이프라인의 상당 부분을 관리해 주는 서버리스 프레임워크가 등장했습니다. AWS는 이를 통해 자체 솔루션인 서버리스 애플리케이션 모델(SAM)까지 만들었죠. 한때 Jenkins와 같은 툴이 CI/CD 부분에 있었지만 이제는 깃허브(역: 이하 Github), Gitlab, 그 외 다른 버전 관리 시스템 제공 업체들이 여러분의 프로젝트에 바로 연결할 수 있는 CircleCI 같은 자체 솔루션과 툴을 제공합니다.

아직 완벽하진 않습니다―클라우드 포메이션 템플릿 작성이 꽤나 진 빠지는 일이거든요. 돌아갈 때 뿌듯함이 정말 크긴 하지만 자동화 스크립트를 짜는 것도 그다지 재밌는 일은 아니고요.

그래도 점점 나아지고는 있습니다. Netlify나 Vercel 같은 게 딱 들어맞는 지점이거든요. 앱을 컴파일해서 스토리지에 두는 정적 웹 호스팅 쪽에 더 깊이 뿌리내리고 있긴 하지만 AWS 람다처럼 잘 작동하는 엔드포인트에 더 쉽게 설치, 배포할 수 있는 Netlify Functions 같은 서비스들이 증가하고 있습니다(이건 그야말로 식은 죽 먹기입니다).

 

그래서 뭘 배우면 되죠?

만약 처음 해본다면 Netlify로 시작해보세요. React 앱이나 아니면 Github 저장소의 간단한 HTML 파일 같은 것이라도 괜찮습니다. Netlify 계정에 연결해서 배포되는 걸 지켜보세요.

 

Netlify 로 하는 쉬운 시작

예전에 조금 다뤄봤더라도 수면 아래 뭐가 있을지 궁금해질 텐데요. Netlify는 여러분의 코드를 끌어와서 가상 환경에서 설정한 명령(yarn build 같은)을 실행하고 S3 같은 스토리지에 파일을 저장합니다. 엔드포인트에서의 서비스를 위해 클라우드 프론트(CloudFront)와 같은 CDN을 앞에 두기까지 하죠.

먼저 여러분의 컴퓨터에서 AWS 콘솔과 CLI로 수동 작업해보세요. 그 다음 Netlify 대신 Github 프로젝트에 Circle CI와 통합되어 모든 프로세스를 자동화하는 스크립트를 짜서 AWS에 배포해 보세요.

한 계단 더 오르고 싶다면 백엔드와 인터페이스할 수 있는 서비스도 만들어 보세요. 서비스에서 이용하는 데이터베이스가 있나요? 클라우드 포메이션이나 배시 스크립트로 데이터베이스를 설정 과정을 자동화할 수 있습니다.

인프라를 쉽게 재생성 가능한 일회용 코드로 처리하는 건 프로젝트 유연성 향상에 도움이 됩니다. 시스템 장애 발생 시 백업하는 능력도 좋아지고요.

이건 AWS나 Circle CI만의 이야기가 아니라 어느 클라우드나 CI/CD 제공 서비스에도 다 통용되는 얘깁니다. 제일 마음에 드는 클라우드 서비스와 작업 흐름 도구를 고르세요. 프로젝트 요구 사항을 파악하고 스택의 자동화된 부분에 무슨 일이 벌어지고 있는지 알아내는 게 중요합니다. 여러분은 이를 통해서 프로젝트 요구 사항에 대해 더 많이 배우고 동시에 리소스를 더 많이 확보할 수 있을 겁니다.

 

Resources

• "A Step-by-Step Guide: Deploying on Netlify"

• "Setting up a Static Website"

• "AWS Certified Cloud Practitioner Training 2019 - A Free 4-hour Video Course"

• 위 프론트엔드의 JS resources

 

 

디자인은 어떡하죠?

기본은 알아야겠죠. 하지만 디자이너가 될 필요는 없습니다.

개발자로서 여러분의 능력을 비행기 태워줄 디자인에 대한 많은 관점들이 있습니다. 시각, UX 디자이너들이 마술을 부린다는 사실은 우리 모두 알고 있지만 기본적 레벨의 이해는 여러분의 앱이 거대한 실망과 좌절 덩어리가 되는 사태를 막을 수 있습니다.

 

미드 <실리콘 밸리>의 가상 서비스 '피리 부는 사나이' (구린 UX 때문에 폭망 위기)

개발 프로세스에 참여하는 모두가 사용자에게 어떤 방식으로든 영향을 주기 위해 공들이고 있습니다. 여러분의 작업이 무슨 요구 사항을 해결하려는 건지, 또 그게 사용자에게 어떤 영향을 주는지 이해한다면 여러분의 팀 전체가 더 포괄적인 솔루션을 개발하는 데 도움이 될 겁니다.

누군가가 앱에서 사용자들을 관리하도록 API를 만드는 백엔드 개발자를 한 번 떠올려 보세요. API는 군더더기 없이 사용자 이름만 요구할 겁니다. "성"과 "이름"으로 나뉘지 않은 하나의 "이름" 필드를 주는 게 일반적으로 생각할 때 제일 직관적인 방법은 아닙니다. 하지만 프론트엔드 개발자가 정보를 UI에 표시하는 방식을 복잡하게 만드는 건 결과적으로 실수일지도 모릅니다. 이로 인해 개발자가 화면에 정보를 띄우는 데 어려움을 겪거나 사용자가 혼란스러워할 수도 있으니까요.

뿐만 아니라 디자인은 전환(conversion)에 직접적으로 영향을 끼칠 수도 있습니다. 만약 이커머스 웹 사이트를 만들고 있는데 별로 버튼 같아 보이지 않는 버튼을 두는 건 사람들이 장바구니에 상품을 담는 걸 막을 수도 있습니다. 당연히 이건 구매 제한과 직결되며 수익을 손해 보게 됩니다. 상식에 겨우 부합하는 정도일지라도 인간 친화적으로 UI를 꾸미는 방법을 안다면 그건 말 그대로 여러분의 프로젝트가 더 많은 수익을 내게 하거나 누군가가 프로젝트를 더 쉽게 사용하도록 합니다.

가장 중요한 이유가 있습니다: 여러분 사이트에 아무도 접근하지 못하는 걸 바라진 않으시겠죠? 많은 사람들이 각자 다른 요구 사항을 갖고 있습니다. 색상을 똑같이 볼 수 없거나 앱에서 나는 소리를 못 들을 때, 이 다른 요구 사항을 파악하고 어떤 식으로든지 모두가 여러분의 앱을 쓸 수 있게끔 디자인하는 게 좋을 겁니다.

 

그래서 뭘 배우면 되죠?

여러분이 모든 코스를 들으리라고 기대하진 않지만 유심히 보고 항상 호기심을 가지세요. 다음엔 freeCodeCamp 트위터에서 보고 지나간 디자인 글을 그냥 넘기지 마시고요.

솔루션을 만들 때 여러분의 작업이 어떻게 쓰일지 상상해 보세요. 여러분의 동료 개발자들이 API에서 필요한 게 뭘까요? 앱 사용자들은 인터페이스에서 뭘 기대할까요?

어쩌면 다른 사람들이 하는 걸 보고 영감을 얻어 볼 수도 있을 겁니다. 유사 기능이 있는 앱의 디자인은 어떨까요? 이게 복사하거나 훔칠 수 있는 특허는 아니지만 여러분은 타 서비스의 솔루션이 해결하는 요구 사항을 이해해야 합니다. 왜 ‘장바구니에 담기’ 버튼이 그렇게 큰지, 왜 상품 사진을 확대해서 볼 수 있게 했는지, 아니면 어떻게 하면 표 디자인을 약간 더 유용하게 만들 수 있을지를 생각해 보세요.

 

Dribbble의 '표' 디자인

웹 접근성을 위해 기초를 배우세요. 다른 사람들의 요구 사항을 이해하는 데 도움이 되는 자료 양은 점점 늘어나고 있습니다. 어떤 장애물이 있고 그게 앱 사용에 어떻게 영향을 끼칠지 생각해 보세요. 이런 고민거리를 해결할 방법에 대한 몇몇 일반적 패턴도 한 번 살펴보세요.

구체화하는 게 그렇게 어렵지 않을 때가 종종 있습니다. 만약 처음부터 구체화하는 습관을 들인다면 다음에 앱을 만들 때는 고민할 필요도 없을 겁니다.

 

Resources

• Design for Developers

• Hack Design

• Design for Hackers

• Intro to Web Accessibility

 

 

갓 시작한 뉴비라면...

이 글의 대부분은 여러분이 깃(역: 이하 git)과 버전 관리가 뭔지, 아니면 코드 에디터 설치 등 기본적인 몇 가지는 아는 사람이라는 가정 하에 쓰였습니다. 만약 정말 갓 시작한 사람이라면 적어도 위의 것들이 뭔지 정도는 알고 가는 게 좋습니다. 아니면 더 어려워질 테니까요.

그리고 터미널을 어떻게 쓰는지도 알아두세요. 여러분이 뉴비라면 GUI를 쓰지 않는다는 사실에 심적 압박을 받을 수 있는데 한 번 알고 나면 터미널을 쓰면서 훨씬 능률이 높아지고 결국엔 많은 프로젝트들이 터미널을 써야 된다는 사실을 깨달을 겁니다.

 

그래서 뭘 배우면 되죠?

가장 먼저 코드 에디터부터 설치합니다. 비주얼 스튜디오 코드(Visual Studio Code)가 지금 인기 가도를 달리고 있지만 기호에 따라 아톰(Atom)이나 서브라임 텍스트(Sublime Text) 같은 에디터를 쓸 수도 있습니다. 심지어는 클라우드 기반 IDE인 Repl.it이나 진입 장벽이 낮고 맘대로 쓸 수 있는 CodePen이나 JSFiddle을 쓸 수도 있을 겁니다.

 

바야흐로 VS CODE 전성기

어쨌거나 코딩할 준비를 마치고 나면 git이 대장 자리를 차지하는 '버전 관리'가 뭔지 궁금하실 텐데요. Git은 코드 변경 사항을 추적하고 다른 개발자들과 협업하는 데 능률을 올려주는 강력한 툴입니다.

변경 사항을 추가하는 등의 기본적인 git 명령어들과 브랜치가 무엇이며 사용법은 어떻게 되는지 같은 것들도 궁금하실 겁니다. Git은 거대한 도장입니다. 모든 무술을 당장 익힐 필요는 없습니다. 곧 여러분은 깃-푸 실력을 갈고 닦아 하산하는 기나긴 수련의 여정에서 배울 거리가 끝도 없다는 사실을 깨달을 겁니다.

툴을 많이 쓸 경우 GitKraken 같은 GUI 툴도 쓸 수 있지만 여러분이 할 수 있는 작업이 조금 제한될 겁니다. PC에서 기본 터미널 사용법을 익히거나 iTerm2(제가 좋아합니다)나 Xterm.js를 다운로드받는 게 좋은 한 수가 될 수 있습니다.

추가: 쓸 때마다 영화 속 해커가 된 기분을 느끼게 됨. (저만 그런가요?)

 

영화 <스워드피쉬>에서 해킹하는 휴잭맨

 

Resources

• Getting Started with Visual Studio Code

• Git resources from Github

• Learn git by branching game

• Intro to the Mac Command Line

 

 

좀 더 찾아보고 있다면...

<이상한 나라의 앨리스>처럼 여러분이 토끼굴에 빠르게 빠져들 방법은 아주 많습니다.

기억하세요: 집중력을 흐트러뜨리지 말고, 너무 본인을 압박하지 마세요. 여러분이 스스로의 상황을 잘 알고 있다면, 현업에서 여러분이 부닥치게 될 문제들에 도움이 될 만한 개념들이 몇 가지 있습니다.

 

테스트와 다양한 방법론들

코드를 짜는 것도 일이지만 효율적인 테스트를 구성하는 건 여러분의 코드를 견고하게 만들고 버그가 나오는 걸 막아 줍니다. 웹 사이트가 다운됐을 때 시간을 낭비하거나 돈까지 쓰고 싶진 않으시겠죠? 테스트 작성 방법과 다양한 접근법들을 익히는 건 코드를 견고히 하는 데 중요합니다.

 

크롬 개발자도구 같은 브라우저 도구

제가 생각하기에 디버깅할 때 여러분이 취할 수 있는 가장 강력한 도구들 중 하나는 앱을 디버깅할 수 있는 브라우저입니다.

DOM이 어떻게 렌더링되는지 보든 CSS 동작을 보든 혹은 네트워크 요청을 디버깅하든 여러분은 곧 어떻게 하면 시간을 아끼고 버그가 발생하는 지점을 더 쉽게 찾아낼지 깨닫게 될 겁니다.

 

HTTP와 네트워크 패널 요청 디버깅하기

웹이 인터넷에 기반한다는 사실로 따져봤을 때 여러분의 앱은 결국 다른 서버에 요청을 보낼 겁니다. 이 때 요청 초크포인트나 요청 방법을 잘 이해하면 여러분의 앱이 버벅대거나 '저장' 버튼이 안 되는 이유를 이해하는 데 도움이 됩니다.

요청 작동 방식과 디버깅 시 요청이 어떻게 시각화되는지 이해하는 것이 이 여정을 도울 것입니다.

 

오픈 소스 소프트웨어와 패키지 매니저

이건 소프트웨어를 배포하는 법만큼 많이 배울 수 있는 기술이나 툴은 아니지만 코드 솔루션을 만들기 시작하면서 여러분은 많은 사람들이 오픈 소스 패키지에 의존한다는 걸 깨달을 겁니다. JS를 쓰고 있다면 대부분 npm을 통해 받게 되는데 이로써 매번 쓸데없이 시간 낭비하지 않고 능률을 올릴 수 있습니다.

충분히 시간을 갖고 오픈 소스의 개념을 이해하고 좋아하는 프로젝트에 기여하는 식으로 돌려주는 것도 생각해 보세요. 누군가 거들어주는 건 보통 정말 고마운 일이고, 여러분이 경험을 쌓는 데에도 도움이 됩니다. 심지어 여러분은 첫 승인된 풀리퀘스트에서 free swag(역: 무료 옷이나 액세사리. 컨트리뷰터들에게 감사 표시를 하거나 사업을 알리고 싶을 때 줌)을 받을 수 있을지도 모릅니다! 그냥 정중히 존중하는 마음으로 하시면 됩니다. 뒤에도 그냥 사람이 있거든요.

 

다른 건요?

코딩 세계는 마르지 않는 샘물 같아서 이 목록은 영원히 길게 이어질 수도 있습니다. 개발 고수가 되기 위한 여정에 또 어떤 게 중요하다고 생각하시나요? 뭔가 중요한 게 빠졌다고 생각하신다면 멘션이나 DM을 보내 주세요!

 

불 붙었네요! 평정을 유지합시다

위와 같은 것으로 쌓을 경험을 생각해 봤을 때, 여러분은 앱을 처음부터 끝까지 만들 수 있는 위치에 도달했을 겁니다. 여러분이 지닌 능력이 과연 어떤 건지 짐작이 가십니까?

 

건틀릿을 쥐어짜는 타노스

재밌는 건 이제부터 시작입니다. 새 앱을 만들어보세요―뭐가 됐든 만들어보세요. 학습을 위해 취할 수 있는 가장 좋은 행동은 직접 하면서 경험을 쌓는 것입니다. 여러분 주위에 널린 수도 없는 todo 튜토리얼 중 하나를 해 보든 인스타그램 CEO처럼 소셜 네트워크를 만들어보며 스스로 코드를 짜는 것이든 상관없습니다.

 

여러분이 만들어 볼 만한 것들:

• 브라우저에서 동작하는 웹앱 프론트엔드
• 웹앱이 엔드포인트로 요청을 만들 수 있는 백엔드 서비스
• 빌드, 배포 프로세스 자동화가 가능하면서 CI/CD 툴과 연결하는 스크립트 짜기
• 추가: 인터페이스 외관을 만들 때 잘 생각할 것. 그래야 사람들이 쓸 수 있겠죠?

 

앞으로 나아가 뭐든 만들어보세요! 여러분의 개발 여정을 트위터에서 #codejourney 해시태그로 공유해 주세요. 여러분이 어떤 길을 거쳐왔고 뭘 만들었는지 또는 어떤 길을 걸을지, 뭘 만들고 싶은지 더 듣고 싶습니다.