처음으로 프론트엔드

몇 년 전으로 돌아가서 처음으로 프론트엔드 개발을 시작할 때라면 지금의 나에게 이런 질문을 할 수 있다.

“저도 그 일을 한번 해보려고 하는데요 간단하게 프론트엔드 개발이 뭔가요?”

내가 생각하는 프론트엔드가 당신이 생각하는 것과 다를 수 있다. 오랫동안 어려운 개발을 한 것도 아니어서 정답을 알지도 못한다. 다만 나의 경험을 잠깐 이야기는 할 수는 있겠다. 이 글은 위 질문에 대한 자신을 향한 대답이다.

왜 이 일을 하는가? 예전 프리랜서 일을 할 때 노드(Node.js)를 사용하여 작은 서버를 만든 적이 있다. 그전에 작은 웹 서비스를 만들면서 잠깐 자바스크립트를 사용한 적이 있을 뿐이다. 브라우저가 아닌 컴퓨터에서 동작하는 프로그램을 자바스크립트로 만들 수 있구나 하면서 놀랐다. 생각보다 코드가 읽기도 쉽고 작성하기 쉬웠다. 노드 버전은 0.10으로 기억한다. 한 달 정도의 작업이었는데 잊히지 않았다. 이후 간단한 자바스크립트 서비스를 만들어서 이력서를 돌렸다. 한 참 만에 두어 군데 면접을 보았고 그중 한 회사에서 프론트엔드 개발을 시작했다. 아무도 나를 프론트엔드 개발자라고 부르지 않아서 스스로 부르고 다녔다. 지금도 일부 고객은 프론트엔드 개발이라는 용어를 잘 모른다. 이것이 프론트엔드 개발하게 된 계기다. 계속 프론트엔드 개발을 하는 이유는 무엇일까? 나의 경우 한 가지다.

재미있다.

굳이 나누자면 프로그래밍 언어의 재미와 서비스 관점의 재미 두 가지다. 함수형 프로그래밍 경험이 없던 나는 자바스크립트에서 가능한 것을 알고 너무도 즐거웠다. 내가 언어 전문가도 아니고 이 언어가 함수형 프로그래밍에 완전 적합한 것은 아니다. 그럼에도 시도하는 과정 조차 즐거웠다. 이 후 일하는 방식이 바뀌었다. 서비스 관점으로 보면 사용자 경험을 직접 만들 수 있는 장점이 있다. 피드백을 받고 고치고 다시 릴리즈 하는 주기가 짧아서 사용자 경험을 개선하기에는 딱이다. 앱 개발과 다른 점은 UI 구성이 상대적으로 쉽다는 것이다. 프론트엔드에서는 HTML과 CSS를 사용하는데 너무나도 직관적이다. 여기에 자바스크립트로 비즈니스 로직을 만드는 것은 궁합이 잘 맞는다. DOM 구조가 비 효율적이고 접근이 어렵다는 한계는 여러 도구와 여러 개발 방식을 사용하여 비켜갈 수 있다고 생각한다. 여차 하면 퍼블리싱 작업을 분리하여 일을 나누어서 할 수도 있고 작은 서비스라면 혼자서 다 개발할 수도 있다.

언어

스스로 자바스크립트 개발자라고 생각한다. 프론트엔드는 이 언어를 가지고 작업할 수 있는 일의 한 부분이다. 물론 자바스크립트와 프론트엔드 개발은 밀접하다. 이 언어의 진입 장벽은 낮아서 대부분의 개발자 이력에 등장한다. 만약에 자바스크립트가 너무 어렵다면 아마도 다른 프로그래밍 언어를 사용해 본 적이 없어서 그런지도 모른다. 그렇다면 그건 당신 탓이 아니다. 새로운 언어를 배우는 것은 불편하고 처음 프로그래밍 언어를 배우는 것은 더 불편하다. 내가 생각하는 기능은 왜 없는 거지? 이런 생각을 자꾸 하게 된다. 특정 프로그래밍 언어는 특정 문제를 해결하는데 최적화되어 있고 자바스크립트도 그런 여러 프로그래밍 언어 중에 하나일 뿐이다. 대부분의 브라우저가 이 언어를 지원한다는 특별한 배경이 있다.

HTML CSS을 사용하여 알고리즘을 작성하는 것은 어렵다. 그래서 자바스크립트와 함께 사용한다. 거꾸로 이 두 언어는 자바스크립트가 할 수 없는 일을 대신해준다. 사용자에게 보이는 모양과 웹 콘텐츠를 유지하는 작업을 대신한다. 세 가지를 언어를 모두 배워야 하는 것이 이상하게 보일 수도 있겠지만 안드로이드 개발이나 스프링 개발에서 사용하는 여럿 XML 파일들을 생각해보자. 특정 언어가 순수하게 자신만의 언어로 모든 문제를 해결하는 것은 어렵다. 웹에서 HTML, CSS를 사용하는 것은 자연스럽다.

과정

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

  • 설명서
  • 디자인 화면
  • HTML, CSS 파일

설명서에 특정 버튼을 눌렀을 경우 사용자 목록 보여주는 사용자 경험이 있다고 상상하자. 이 사용자 경험을 제공하기 위해 HTML 파일에 자바스크립트 파일을 추가할 텐데 이 코드는 HTML, CSS 파일과 함께 브라우저에서 동작한다. 자바스크립트 코드는 설명서에 적힌 사용자 경험을 제공하기 위해 여러 동작을 수행한다. 우선, HTML, CSS 파일을 동적으로 수정하여 버튼을 표시한다. 그다음 사용자가 버튼을 클릭하면 어떤 곳에서 사용자 목록을 가져와서 그 데이터를 브라우저 화면에 표시한다. 물론 이 때도 HTML, CSS 파일의 일부를 동적으로 수정한다. 여기서 말하는 어떤 곳은 대부분 멀리 떨어져 있는 서버일 것이다. 서버에 어떻게 접속하는지 알려면 아직 등장하지 않은 서버 개발자에게 물어보아야 한다. 이제 프론트엔드 개발자가 보는 문서가 하나 더 추가되었다. 이 문서는 서버 개발자가 만들어서 제공해야 한다.

  • 서버 접속 방법

웹 데이터를 스크랩하여 사용자 목록을 만든다면 이런 문서가 없을 수도 있다. 필요한 데이터를 얻어오는 방법을 아는 것이 중요하다.

어디서 동작할까?

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

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

하이브리드 앱을 만들 때 사용하는 방식이다. 이런 내장 브라우저는 자바스크립트를 사용하여 앱과 통신하는 방법을 제공한다. 경험상 어떤 브라우저를 지원할지 설명서에 적어서 지원 대상을 제한한다. 그렇지 않으면 끝 없이 이어지는 일 지옥을 경험하게 된다.

무엇을 만드는가?

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

운영체제가 프로그램을 수행하는 것과 비슷하게 브라우저가 자바스크립트를 수행한다. 프론트엔드에서 사용하는 자바스크립트는 브라우저에서 동작한다. 여러 서버 스크립트가 서버에서 동작하는 것과 다르다. JSP, PHP, ASP 등에 포함되어 있는 자바스크립트가 브라우저에서 동작함으로 이런 언어를 사용하는 개발을 프론트엔드 개발이라고 부를 수 있을까? 맞다. 그렇게 볼 수도 있다. 그렇지만 나는 범위를 좁히고 싶다. 이런 개발 방법에서 자바스크립트는 옵션이다. 없어도 된다. 서버 데이터의 일부를 브라우저로 가져가거나 자바스크립트를 사용하여 데이터를 가공하거나 때때로 일부 데이터를 서버에서 가져오기도 한다. 내가 생각하는 프론트엔드 개발은 브라우저에 한번 로딩되면 변하지 않는 자바스크립트를 중심으로 서버와 인터페이스를 통하여 대화하는 방법이다. 서버에 포함되어 있지 않으며 데이터를 주고받는 대상으로 서버를 사용한다. 자바스크립트를 중심으로 본다는 말은 비즈니스 로직을 자바스크립트에서 구현한다는 말이다. 사용자 경험이 변경되면 자바스크립트 중심으로 변경이 이루어진다. 이런 방식을 SPA라고 부르기도 한다.

일의 범위

프론트엔드 개발 일에 대해서 사람마다 다양한 의견이 있어서 일의 범위에 대한 정답은 없다. 예를 들어 백엔드 개발자 딱 한 명 있는 회사에서 프론트엔드 개발자를 한 명 구해서 웹 서비스를 하려 한다면 이 정도 원할 것이다.

  • 아이콘 디자인
  • 기획서를 보고 퍼블리싱 (브라우저 별로 모바일 브라우저 포함, 혹시 웹 뷰일 수도 …)
  • 기획서와 퍼블리싱 결과와 자바스크립트를 사용하여 서버와 통신하고 사용자와 대화하는 서비스 작성

이 일을 다한다면 슈퍼맨이다. 디자이너, 퍼블리셔, 자바스크립트 개발자가 협업하도록 세 분야로 나눌 수 있다. 이상적이긴 하다. 작은 서비스라면 퍼블리싱과 자바스크립트 개발을 함께 할 수 있다.

메모장으로 개발할까?

프론트엔드 대부분의 코드가 텍스트로 존재하고 자바스크립트가 컴파일하지 않는 스크립트 언어라고 해서 메모장 정도로 개발이 될 거라는 생각은 유머다. 메모장을 열어 HTML 코드를 입력하는 방법으로 개발하다가는 정시에 퇴근하지 못하거나 일정을 연기해야 할 것이다. 일자리를 잃을지도 모른다. 인기 있는 시작 코드를 사용하고 생산성 좋은 툴들을 사용해야 한다. 이런 방법을 사용하는 것은 옵션이 아니다. 예를 들면 아래와 같은 툴들을 사용할 수 있다.

프레임워크, 라이브러리 등의 이름으로 불리지만 모두 다른 사람이 잘 만들어 놓은 코드를 재사용하는 것이 목적이다. 어떤 종류를 사용할지 선택해야 한다. 선택하는 것이 기술이다. 성능 좋은 통합 툴을 사용하여 개발하고 싶다면 그렇게 해도 된다.

당신이 통합 툴을 사용하건 메모장을 사용하건 HTML, CSS, 자바스크립트의 서로 간의 경계와 내가 작성하는 코드와 가져다 쓰는 코드의 경계를 명확하게 이해하고 있어야 한다. 구글 질문으로도 해결하지 못하는 복잡한 문제와 마주칠 때 도움이 된다. 시간이 부족하면 더욱 그렇다. 프론트엔드의 개발에는 많은 툴들이 나열된다. 이 툴들 대부분이 Node.js로 개발되었다. 그러므로 Node.js 설치는 필수다. 당신이 사용하는 운영체제에서 Node.js 사용하기 불편하다면 운영체제 변경도 고려하길 바란다. 너무 편해서 본래 쓰던 운영체제를 바꾸게 될지도 모른다. 대표적인 툴로 자바스크립트 프레임워크가 있다. 인기 있는 자바스크립트 프레임워크는 넘쳐난다. 선택을 위해서는 시간과 관심이 필요하다. 아래 사이트가 도움이 된다. 깊숙하게 이해하려면 책을 한 권 사거나 해당 사이트에서 투토리얼을 보는 것이 도움이 된다.

물론 팀에서 결정되었거나 기존 코드에 이미 적용된 프레임워크가 있다면 어쩔 수 없다. 그래도 선택해야 할 때가 온다. 예를 들면 내가 가고 싶은 회사에서 vuejs 개발자를 찾을 때 라든가^^

디버깅하기 위해 당연히 로깅을 사용할 수 있다. 프론트엔드 서비스는 브라우저에서 확인하고 브라우저에서 디버깅한다. 자바스크립트 동작을 멈추게 하고 값을 확인할 수 있다. 함수 호출 스택도 살펴볼 수 있다. HTML이나 CSS 코드도 브라우저에서 직접 변경하여 결과를 바로 확인할 수 있다. 브라우저마다 스타일이 조금씩 달라서 디버깅 용 브라우저를 선택해야 한다. 나는 크롬을 사용한다. 안드로이드 웹 뷰도 디버깅할 수 있으며 WebRTC를 잘 지원하기 때문이다. 대부분의 브라우에서 F12키를 누르면 하단에 많은 탭과 설정 옵션을 보여준다. 개발자 툴이라고 한다. 한 번도 사용하지 않은 기능이 더 많다. 정말 다양하다. 크롬을 사용한다면 크롬 확장을 사용하여 개발 속도를 더 올릴 수 있다.

서비스를 서버에 올리고 싶다.

개인적으로 작성하는 서비스를 무료 서버에 올리고 싶다면 heroku (or openshift) 서비스를 사용하면 된다. 여러 종류의 서버를 지원함으로 웹 서버든 노드 서버든 선택해서 사용할 수 있다. 비용을 더 지불하면 원하는 만큼의 서버를 제공받을 수 있다. Heroku 무료 계정을 만들고 github에 코드를 올리고 heroku 계정에서 github 코드를 연결하면 yourapp.herokuapp.com과 같은 주소로 접속하여 결과를 확인할 수 있다. https 접속은 덤이다. github 무료 계정은 남들이 볼 수 있어서 불편하고 무료 heroku 계정은 가끔 서버 로딩에 10초 정도 걸릴 수 있지만 테스트하기엔 좋다. 딱 한 번만 올릴 내용이 아니라면 heroku와 github를 연결하는 것이 편하다. 웹 주소가 마음에 들지 않는다면 도메인만 하나 사서 변경할 수 있다. 또, heroku 서비스가 마음에 들지 않는다면 다른 서버로 갈아타서 github만 연결하면 된다. 대부분의 클라우드 서비스들은 github 연결을 지원한다. 개발자를 구할 때 기술 블로그나 github 계정을 요구하는 회사들도 늘고 있음으로 코드를 github에 두길 바란다.

오래 이 일을 하지는 않았지만 한 숨 쉬어가려고 한다. 프론트엔드 일을 하면서 나름 했던 일과 다시 하면 잘 할 것 같은 내용을 정리하고 있다. 이 글은 시작이다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중

This site uses Akismet to reduce spam. Learn how your comment data is processed.