프런트엔드 일을 설명한다면

어떻게 이일을 하게 되었는가?

노드 Node.js를 사용하여 작은 서버를 만든 적이 있다. 컴퓨터에서 동작하는 프로그램을 자바스크립트로 만들 수 있구나 하면서 놀랐다. 브라우저에서만 자바스크립트를 사용할 수 있다고 생각했었다. 생각보다 코드가 읽기도 쉽고 작성하기 쉬웠다. 한 달 정도의 작업이었는데 잊히지 않았다. 이후 간단한 자바스크립트 서비스를 만들어서 이력서를 돌렸다. 한 참 만에 두어 군데 면접을 보았고 그중 한 회사에서 프런트엔드 개발을 시작했다. 그때는 아무도 나를 프런트엔드 개발자라고 부르지 않아서 스스로 부르고 다녔다.

왜 이 일을 하는가?

계속 프런트엔드 개발을 하는 이유는 재미있기 때문이다. 프로그래밍 언어의 재미와 서비스 관점의 재미 두 가지다. 함수형 프로그래밍 경험이 없던 나는 자바스크립트에서 가능한 것을 알고 신났다. 내가 언어 전문가도 아니고 이 언어가 함수형 프로그래밍에 정말 적합한 것도 아니다. 그럼에도 시도하는 과정이 즐거웠다. 덕분에 생각하는 방식이 조금 바뀌었다. 서비스 관점으로 보면 사용자 경험을 직접 만들 수 있는 장점이 있다. 피드백을 받고 고치고 다시 릴리즈 하는 주기가 짧아서 사용자 경험을 개선하기에는 딱이다. 앱 개발과 다른 점은 UI 구성이 상대적으로 쉽다는 것이다. HTML과 CSS를 사용하는데 직관적이다. 자바스크립트를 사용해서 비즈니스 로직을 만든다. DOM 구조가 비 효율적이고 접근이 어렵다는 한계는 여러 도구와 여러 개발 방식을 사용하여 비켜갈 수 있다고 생각한다.

JavaScript

스스로 자바스크립트 개발자라고 생각한다. 프런트엔드는 이 언어를 가지고 작업할 수 있는 일의 한 부분이다. 물론 자바스크립트와 프런트엔드 개발은 밀접하다. 이 언어의 진입 장벽은 낮아서 대부분의 개발자 이력에 등장한다. 특정 프로그래밍 언어는 특정 문제를 해결하는데 최적화되어 있고 자바스크립트도 비슷하게 그런 여러 프로그래밍 언어 중에 하나일 뿐이다. 대부분의 브라우저가 이 언어를 지원한다는 특별한 배경이 있긴 하다.

과정

어떤 서비스를 어떻게 제공할지 문서로 만든다. 서비스 개발을 의뢰하는 고객이나 사내 기획자가 이 문서를 전해주기도 한다. 디자이너가 이 문서를 보고 그래픽 툴을 사용하여 화면을 그린다. 동시에 테스트 개발자가 이 문서를 사용하여 테스트 항목을 만든다. 디자이너가 만든 화면을 보고 퍼블리셔가 HTML과 CSS 파일을 만든다. 프런트엔드 개발자가 이 일을 하기도 한다. 이 파일을 브라우저에서 읽어 들여 모양을 확인한다. 그다음 디자이너가 만든 화면과 퍼블리셔가 만든 브라우저의 화면을 비교하게 된다. 똑같을 수도 있지만 때때로 조금 다르기도 하다. 디자이너가 사용한 그래픽 툴은 하나지만 브라우저는 여러 종류가 있기 때문이다. 여러 브라우저에서도 동일한 모양을 유지한다면 브라우저 호환성을 가지는 HTML, CSS 파일을 만들었다고 말한다. 기획서와 조금 다르게 사용자가 제공받을 서비스를 정리한 문서를 설명서라고 하고 설명서에 말하는 모양과 동작을 합쳐서 사용자 경험이라고 하면 프런트엔드 개발자는 사용자 경험 목록을 서비스로 만드는 일을 한다고 볼 수 있다.

  • 설명서
  • 디자인 화면
  • 테스트 목록
  • HTML, CSS 파일
  • 서버 접속 방법

어디서 동작할까?

브라우저는 HTML, CSS, 자바스크립트 파일을 읽어 들여 모두 해석하고 내부에 정의된 순서대로 동작한다. 이 파일이 모든 브라우저에서 동일하게 해석되고 동일하게 동작한다는 보장은 없다. 보장은 못하지만 대부분 비슷하게 동작하는 것은 표준 덕분이다. HTML, CSS 파일은 W3C에서 표준을 만들고 자바스크립트는 ECMAScript에서 표준을 만든다. 표준은 여러 종류의 지켜야 될 규칙 모음인데 언어의 문법이나 동작 방식 등을 정의한다. 표준과 브라우저의 구현이 모두 일치하는 것은 아니라서 이런 차이점을 구분해 주는 사이트도 따로 있다. 브라우저가 모든 표준을 구현하는 것도 아니고 표준만 구현하는 것도 아니다. 각각의 브라우저가 같은 표준을 지킨다고 하더라도 내부 성능이나 처리 방식은 다를 수 있다. 프런트엔드 개발자는 이런 문제점을 고려해야 한다. 크롬, 오페라, 사파리, Edge는 대표적인 브라우저 이름이다. 대부분 브라우저는 데스크톱 브라우저에 대응하는 모바일 버전을 따로 가지고 있다. 말하자면 안드로이드용 브라우저 앱이나 아이폰용 브라우저 앱이 따로 있는 샘이다. 안드로이드의 경우 출시될 때 미리 내장되는 특별한 브라우저 앱이 따로 있기도 하다. 장치에 연관된 브라우저 말고도 또 다른 브라우저가 있다. 이 브라우저는 앱에 내장될 수 있는데 안드로이드와 아이폰에서 비슷한 이름으로 부른다. 안드로이드는 WebView라고 하고 아이폰에선 UIWebView라고 한다. 설명도 비슷하다.

  • A View that displays web pages. (안드로이드)
  • A view that embeds web content in your app. (아이폰)

무엇을 만드는가?

프런트엔드 개발자는 웹 페이지를 만든다기보다는 서비스를 만든다고 보는 것이 맞다. 보통 브라우저에서 웹 페이지를 본다고 말한다. 그렇지만, 우리는 구글 메일을 보고 웹 페이지라거나 혹은 게시판이라거나 블로그라고 하지 않는다. 웹 콘텐츠라고도 하지 않는다. 그 서비스는 "구글 메일" 일 뿐이다. 구글 메일이라는 이름을 가지는 서비스다. 앱이건 브라우저 건 서비스를 제공하는 목표가 동일하다면 사용자는 지금 보고 있는 화면의 버튼이 앱의 버튼이건 웹의 버튼이건 관심 없다. 그러므로 프런트엔드 개발자는 앱 서비스를 만든다고 봐도 된다. 웹 뷰를 사용하는 하이브리드 앱의 경우 서비스 제공자는 일부러 앱의 고유 기능과 웹 뷰의 기능을 구분하지 않는다. 오히려 모든 사용자 경험을 부드럽게 서로 연결하려고 한다. 웹 서비스는 점점 앱 서비스처럼 사용자에게 다가가고 있다. HTML5 같은 기술 지원이 그것을 가능하게 하고 있다. 사용자 경험을 동일하게 유지한다면 앱이나 웹을 사용하는 것은 단지 선택이다. 지도 보기, 영상 통화, 2D, 3D, 웹 소켓, 사용자 데이터 저장 등이 가능하다. 갈수록 사용자는 웹과 앱을 구분하기 힘들 것이다. 서로 완전 대체도 힘들 것이라고 생각한다. 웹 서비스를 개발한다는 말도 맞고 앱 서비스를 개발한다는 말도 맞다.

메모장으로 개발하지 않는다

대부분의 코드가 텍스트로 존재하고 자바스크립트가 컴파일하지 않는 스크립트 언어라서 메모장을 이용해서 개발해도 되지만 아무도 그렇게 개발하지 않는다. 인기 있는 시작 코드를 사용하고 생산성 좋은 툴을 사용해야 한다. 아래와 같은 툴들을 사용할 수 있다.

--

--

JavaScript Developer, https://afrontend.github.io/

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store