몇 년 전으로 돌아가서 처음으로 프런트엔드 개발을 시작할 때라면 지금의 나에게 이런 질문을 할 수 있다. “간단하게 프런트엔드 개발이 뭔가요?” 내가 생각하는 프런트엔드 개발이 당신이 생각하는 것과 다를 수 있다. 오랫동안 어려운 개발을 한 것도 아니고 정답을 아는 것도 아니지만 나의 경험을 잠깐 이야기하겠다.
어떻게 이일을 하게 되었는가?
노드 Node.js를 사용하여 작은 서버를 만든 적이 있다. 컴퓨터에서 동작하는 프로그램을 자바스크립트로 만들 수 있구나 하면서 놀랐다. 브라우저에서만 자바스크립트를 사용할 수 있다고 생각했었다. 생각보다 코드가 읽기도 쉽고 작성하기 쉬웠다. 한 달 정도의 작업이었는데 잊히지 않았다. 이후 간단한 자바스크립트 서비스를 만들어서 이력서를 돌렸다. 한 참 만에 두어 군데 면접을 보았고 그중 한 회사에서 프런트엔드 개발을 시작했다. 그때는 아무도 나를 프런트엔드 개발자라고 부르지 않아서 스스로 부르고 다녔다.
왜 이 일을 하는가?
계속 프런트엔드 개발을 하는 이유는 재미있기 때문이다. 프로그래밍 언어의 재미와 서비스 관점의 재미 두 가지다. 함수형 프로그래밍 경험이 없던 나는 자바스크립트에서 가능한 것을 알고 신났다. 내가 언어 전문가도 아니고 이 언어가 함수형 프로그래밍에 정말 적합한 것도 아니다. 그럼에도 시도하는 과정이 즐거웠다. 덕분에 생각하는 방식이 조금 바뀌었다. 서비스 관점으로 보면 사용자 경험을 직접 만들 수 있는 장점이 있다. 피드백을 받고 고치고 다시 릴리즈 하는 주기가 짧아서 사용자 경험을 개선하기에는 딱이다. 앱 개발과 다른 점은 UI 구성이 상대적으로 쉽다는 것이다. HTML과 CSS를 사용하는데 직관적이다. 자바스크립트를 사용해서 비즈니스 로직을 만든다. DOM 구조가 비 효율적이고 접근이 어렵다는 한계는 여러 도구와 여러 개발 방식을 사용하여 비켜갈 수 있다고 생각한다.
JavaScript
스스로 자바스크립트 개발자라고 생각한다. 프런트엔드는 이 언어를 가지고 작업할 수 있는 일의 한 부분이다. 물론 자바스크립트와 프런트엔드 개발은 밀접하다. 이 언어의 진입 장벽은 낮아서 대부분의 개발자 이력에 등장한다. 특정 프로그래밍 언어는 특정 문제를 해결하는데 최적화되어 있고 자바스크립트도 비슷하게 그런 여러 프로그래밍 언어 중에 하나일 뿐이다. 대부분의 브라우저가 이 언어를 지원한다는 특별한 배경이 있긴 하다.
HTML과 CSS를 사용하여 알고리즘을 작성하는 어렵기 때문에 자바스크립트와 함께 사용한다. 거꾸로 이 두 언어는 자바스크립트가 하기 어려운 일, 사용자에게 보이는 모양과 웹 콘텐츠를 유지하는 일을 대신한다. 세 언어를 모두 배워야 하는 것이 이상하게 보일 수도 있겠지만 안드로이드 애플리케이션을 개발하거나 스프링 프레임워크를 사용하여 개발할 때 사용하는 여럿 XML 파일들을 생각해보자. 특정 언어가 순수하게 자신만의 언어로 모든 문제를 해결하는 것은 드물다. 일부 자바스크립트 프레임워크는 HTML, CSS 코드를 포함하려는 노력을 하고 있긴 하다. 웹에서 HTML, CSS를 사용하는 것은 필수적이다.
과정
어떤 서비스를 어떻게 제공할지 문서로 만든다. 서비스 개발을 의뢰하는 고객이나 사내 기획자가 이 문서를 전해주기도 한다. 디자이너가 이 문서를 보고 그래픽 툴을 사용하여 화면을 그린다. 동시에 테스트 개발자가 이 문서를 사용하여 테스트 항목을 만든다. 디자이너가 만든 화면을 보고 퍼블리셔가 HTML과 CSS 파일을 만든다. 프런트엔드 개발자가 이 일을 하기도 한다. 이 파일을 브라우저에서 읽어 들여 모양을 확인한다. 그다음 디자이너가 만든 화면과 퍼블리셔가 만든 브라우저의 화면을 비교하게 된다. 똑같을 수도 있지만 때때로 조금 다르기도 하다. 디자이너가 사용한 그래픽 툴은 하나지만 브라우저는 여러 종류가 있기 때문이다. 여러 브라우저에서도 동일한 모양을 유지한다면 브라우저 호환성을 가지는 HTML, CSS 파일을 만들었다고 말한다. 기획서와 조금 다르게 사용자가 제공받을 서비스를 정리한 문서를 설명서라고 하고 설명서에 말하는 모양과 동작을 합쳐서 사용자 경험이라고 하면 프런트엔드 개발자는 사용자 경험 목록을 서비스로 만드는 일을 한다고 볼 수 있다.
- 설명서
- 디자인 화면
- 테스트 목록
- HTML, CSS 파일
설명서에 특정 버튼을 눌렀을 경우 사용자 목록 보여주는 사용자 경험이 있다고 상상하자. 이 사용자 경험을 제공하기 위해 HTML 파일에 자바스크립트 파일을 추가할 텐데 이 자바스크립트 코드는 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, 웹 소켓, 사용자 데이터 저장 등이 가능하다. 갈수록 사용자는 웹과 앱을 구분하기 힘들 것이다. 서로 완전 대체도 힘들 것이라고 생각한다. 웹 서비스를 개발한다는 말도 맞고 앱 서비스를 개발한다는 말도 맞다.
프런트엔드에서 사용하는 자바스크립트는 브라우저에서 동작한다. 여러 서버 스크립트가 서버에서 동작하는 것과 다르다. JSP, PHP, ASP 등에 포함되어 있는 자바스크립트가 브라우저에서 동작함으로 이런 언어를 사용하는 개발을 프런트엔드 개발이라고 부를 수 있을까? 맞다. 그렇게 볼 수도 있다. 그렇지만 나는 범위를 좁히고 싶다. 이런 개발 방법에서는 자바스크립트가 옵션이어서 없어도 된다. 서버 데이터의 일부를 브라우저로 가져가거나 자바스크립트를 사용하여 데이터를 가공하거나 때때로 일부 데이터를 서버에서 가져오기도 한다. 내가 생각하는 프런트엔드 개발은 브라우저에 한번 로딩되면 변하지 않는 자바스크립트를 중심으로 서버와 인터페이스를 통하여 대화하는 방법이다. 서버에 포함되어 있지 않으며 데이터를 주고받는 대상으로 서버를 사용한다. 자바스크립트를 중심으로 본다는 말은 비즈니스 로직을 자바스크립트에서 구현한다는 말이다. 사용자 경험이 변경되면 자바스크립트 중심으로 변경이 이루어진다. 이런 방식을 SPA라고 부르기도 한다.
메모장으로 개발하지 않는다
대부분의 코드가 텍스트로 존재하고 자바스크립트가 컴파일하지 않는 스크립트 언어라서 메모장을 이용해서 개발해도 되지만 아무도 그렇게 개발하지 않는다. 인기 있는 시작 코드를 사용하고 생산성 좋은 툴을 사용해야 한다. 아래와 같은 툴들을 사용할 수 있다.
- html5 Boilerplate (HTML)
- Bulma (CSS)
- React (자바스크립트)
프레임워크, 라이브러리 등의 이름으로 불리지만 모두 다른 사람이 잘 만들어 놓은 코드를 재사용하는 것이 목적인 코드 집합이다. 어떤 종류를 사용할지 선택하는 것이 기술이다. 성능 좋은 통합 툴을 사용하여 개발하고 싶다면 그렇게 해도 된다.
당신이 통합 툴을 사용하건 메모장을 사용하건 HTML, CSS, 자바스크립트의 서로 간의 경계와 내가 작성하는 코드와 가져다 쓰는 코드의 경계를 명확하게 이해하고 있어야 한다. 구글 질문으로도 해결하지 못하는 복잡한 문제와 마주칠 때 도움이 된다. 시간이 부족하면 더욱 그렇다. 프런트엔드의 개발에는 많은 툴들이 나열된다. 이 툴들 대부분이 Node.js로 개발되었다. 그러므로 Node.js 설치는 필수다. 당신이 사용하는 운영체제에서 Node.js 사용하기 불편하다면 운영체제 변경도 고려하길 바란다. 너무 편해서 본래 쓰던 운영체제를 바꾸게 될지도 모른다. 대표적인 툴로 자바스크립트 프레임워크가 있다. 인기 있는 자바스크립트 프레임워크는 넘쳐난다. 선택을 위해서는 시간과 관심이 필요하다. 아래 사이트가 도움이 된다. 깊숙하게 이해하려면 책을 한 권 사거나 해당 사이트에서 투토리얼을 보는 것이 도움이 된다.
물론 팀에서 결정되었거나 기존 코드에 이미 적용된 프레임워크가 있다면 어쩔 수 없다. 그래도 선택해야 할 때가 온다. 예를 들면 내가 가고 싶은 회사에서 vuejs 개발자를 찾을 때 라든가^^
디버깅하기 위해 당연히 로깅을 사용할 수 있다. 프런트엔드 서비스는 브라우저에서 확인하고 브라우저에서 디버깅한다. 자바스크립트 동작을 멈추게 하고 값을 확인할 수 있다. 함수 호출 스택도 살펴볼 수 있다. HTML이나 CSS 코드도 브라우저에서 직접 변경하여 결과를 바로 확인할 수 있다. 브라우저마다 스타일이 조금씩 달라서 디버깅 용 브라우저를 선택해야 한다. 나는 크롬을 주로 사용한다. 안드로이드 웹 뷰도 디버깅할 수 있으며 WebRTC를 잘 지원하기 때문이다. 대부분의 브라우에서 F12키를 누르면 하단에 많은 탭과 설정 옵션을 보여준다. 개발자 툴이라고 한다. 한 번도 사용하지 않은 기능이 더 많다. 정말 다양하다. 크롬을 사용한다면 크롬 확장을 사용하여 개발 속도를 더 올릴 수 있다.
프런트엔드 일을 간단하게 정리했다. 다음 글에서는 자바스크립트로 만든 작은 서비스를 취미로 만드는 일을 정리할 예정이다.
