세상이 바뀌었습니다. 그야말로 상전벽해!

이렇게 말했지만 front end가 웹 개발 세계에 등장한 지는 생각보다 오래되었습니다.
(아주 굉장한 뒷북이지요. 둥둥둥)

그렇지만 국내 개발환경에서 SI,SM에서 프론트엔드가 온전하게 이해되기 까지는 많은 시간이 걸렸고, 솔직히 말하면 요즘에도 B2C 위주의 비즈니스가 아니면 프론트엔드를 제대로 이해하지 못하고 있습니다.

전 직장에서 만났던 현장의 시니어 SI개발자, 프로젝트 리더 분들은 프론트엔드 개발자가 무엇이냐고 제게 묻곤 했습니다.

그분들은 프론트엔드 개발자와 퍼블리셔의 차이에 대해서도 혼동하셨습니다.
(퍼블리셔와 프론트엔드 개발자 양쪽 다 서로에 대해서 이견이 있는 첨예한 분야이긴 합니다.)

잘 모르는 것이 이해가 가는 것이, 예나 지금이나 B2B에서는 자바스크립트를 경험적으로 배제하거나 서버 사이드 렌더링에 혼용하거나 하는 식으로 부가적인 것으로 취급해 최소화 하는 것이 일반적이었기 때문입니다. 즉, B2B에선 프론트엔드는 잘 모르는 기술입니다.

4skcofasa1p01
JS가 얼마나 심오한 지 보여주는 단적인 예 ↑

좀 더 변호하자면 스크립트의 동작원리는 생각보다 심오해 단기간에 올바르게 구현하기 어려웠을 뿐더러, 웹 표준이 정착되기 전이라 그 분들의 선택과 견해는 당시 기준으로 틀렸던 것은 아닙니다.

조금만 옆동네인 비 웹 개발자들과 이야기하면 Java Script와 Java의 차이를 모르는 개발자들도 있습니다.

369px-Grimm_Household_Stories
Java Script와 Java가 연관 관계가 있다고 생각하는 건, 그림 형제가 쓴 그림 동화를 그림이 그려진 동화라고 생각하는 것처럼 아주 잘못된 생각 입니다.


아무튼 몇 해 전부터 다양한 변화 끝에 웹 시장은 모바일 위주로 재편되었습니다.
그렇게 시장과 고객이 변화하는 동안 B2B의 SI,SM은 "아주아주아주" 극소수의 프로젝트 리더들만이 프론트엔드가 무엇인지 온전하게 경험하고 깨닫게 되었습니다.

예전에는 "데이터 중심"으로 설계해서 비교적 구현이 용이했던 모든 것들이 훨씬 복잡한 사용자 관점의 "이벤트 중심"으로 설계하고 처리하게 끔 바뀌었습니다.

800px-Cable_salad
더 이상 화면은 일괄적으로 처리하는 부분이 아닙니다. 오늘날의 웹 화면은 입력 필드 또는 그것보다 조금 큰 덩어리들의 집합인 화면 요소(component)들이 사용자 행태에 따라 순서와 상황에 걸맞게 즉각적인 대응을 해야합니다. 이 말은 하나의 화면 속에 아주 작은 여러 개의 화면에 준하는 것들이 상호작용하며 존재한다고 보시면 됩니다.


불친절한 과거의 UI를 떠올려보면 차이가 더 쉽게 이해될 겁니다.
모든 데이터를 다 입력하고 저장 버튼을 눌렀을 때 서버에서 필수값이 누락되었거나 중복되었다는 메시지가 날아오던 경험이 과거의 것이라면,

요즘(이미 당연해진)의 웹들은 특정 필드를 입력하고 손을 떼는 바로 그 순간 몇 가지 정보를 조합하여 미리 검증을 태운다거나 미리 저장을 호출하거나,
사용자가 뒤늦게 느끼는 불편함을 줄이고 재사용 가능하게 구현하는데 주안점을 둡니다.

관련 간단 비교영상 <- 이런거 십수개가 모여서 하나의 화면이 되는 것이 모던 웹입니다. A가 입력되면 B가 바뀌고 다시 B에 의해서 A가 다시 바뀌거나 C, D, E가 그려지거나 갱신되고는 합니다. 실제 서비스 수준에는 복잡하고 재귀적인 상태트리가 그려진다고 보시면 됩니다.

당연히 코드는 더욱 길어지고 섬세해집니다.
왜 그러느냐고 묻는다면.

그것이 기술적으로 가능해졌기 때문입니다.

잠시 과거로 돌아가서 제가 학부생 시절이었던 2006년 무렵부터 2010년 사이를 보자면.
그 무렵에는 서점가에는 프론트엔드를 다루는 책들은 별로 없었고 JSP나 PHP 뭐 이런것들이 주를 이루고 있었습니다. 프론트엔드에서 독립적이며 체계적으로 무언가가 가능하다는 것을 앞서 보여주는 이들이 별로 없었습니다.

그러다가 플래시가 없어도 얼마든지 웹 표준을 이용해 구현하면 된다
(그게 더럽게 어렵다는 건 공공연한 비밀이었습니다!)고
잡스가 천명한 무렵 전후 (관련링크)로 웹 표준을 준수하는 프론트엔드 진영은 엄청난 성장을 이루었습니다.

이 무렵에 표준 준수에 열성적으로 활동한 프론트엔드 개발자들의 희생과 고행 덕에 진정으로 많은 부분이 표준화 되었습니다.

반대로 표준 대신에 독자적인 RIA(Rich Internet Application)를 표방하던 녀석들은 비슷한 시기에 망했습니다. (제가 학부생이던 시절 flex와 silverlight가 국내에 2006년 무렵부터 서점가에 유행 했으나 2010년 무렵에는 이미 사양길이었습니다.)

저는 프론트엔드의 기술영역과 직업군의 확립에 모바일 시장의 성장과 애플의 정책이 한 자리를 차지 했다고 봅니다.

그렇지만 잡스의 발언은 그저 대변혁 시기의 하나의 이벤트일 뿐입니다. 오히려 codepen, jsbin, github 등등 여러가지 서비스들을 통해 좋은 아이디어를 표출하고 수용할 수 있는 다양한 수단의 등장으로 지속적으로 전세계의 개발자들끼리 대화가 활발해 진 것이 사실 더 큰 원인일 겁니다. 혁신은 하루 아침에 이뤄지지 않습니다.


과거에서 다시 현재를 보자면
웹 서비스가 비즈니스 자체인 IT 기업들은 이제 너나 할 것 없이 순수 JS를 이용해 얼마나 멋진 것들을 만들 수 있는지 우리에게 보여주고 있습니다.

이런 선구자들 덕분에 복잡하지만 사용자들에게 잔잔한 감동을 주는 프론트엔드 기술들은 대중의 삶 깊숙이 자리 잡았습니다. (진입 장벽은 낮아졌으나 여전히 어렵습니다!)

그렇지만 SI,SM의 현실은 이와는 반대로, 아직도 프론트엔드나 디자인에 대해서 값어치를 인정하지 않는 이들이 상위에 포진해 있습니다.

그 동안 한 명이 하던 걸 여럿이서 한다니 그 동네에선 기가 찰 노릇이지요.

(만약 SI, SM에서 상사가 풀스택에 준하는 것들에 대해서 논하면서, 자존심을 긁는 말로 모든 것을 요구하며, 임금은 기존과 동일한 걸 요구한다면, 그가 당신의 기술을 얼마나 하찮게 여기고 얼마나 세상 변화에 둔감한지 여실히 보여주는 대사라고 볼 수 있습니다.)


마무리로는 저처럼 기업 전산실 같이 낙후된 환경에서 일하시는 분들 또는 웹 개발을 시작하는 분들께 공유하고 싶은 프론트엔드와 백엔드를 분리해서 작업을 해 본 제 짧은 감상입니다.

  1. 백엔드와 프론트엔드 분리는 개발 분량이 줄어드는 것은 아니었다.
    : 사용자 중심으로 API를 구성하는 것 만으로도 개발분량이 늘어납니다.
    그렇지만 불필요하고 반복적인 개발이 줄어드는 건 금방 체감 할 수 있습니다.

  2. 많은 것이 비슷하지만 전부 다르다.
    : 이 유사성 때문에 시행착오가 많았습니다. 대부분의 고통은 데이터 중심의 설계와 구현 습관을 버리지 못해서 찾아옵니다. 화면 이벤트 관점으로 API와 클래스와 테이블을 설계하는 것이 효율적입니다.

  3. 리팩토링과 설계 변경이 "너무" 유연하게 잘 된다.
    : 과거 방식이면 꿈도 못 꿀 변화입니다. 백엔드와 프론트엔드를 확실하게 분리하는 것 만으로도 프로젝트 전체적인 구조 변경이 유려하게 잘 진행됩니다.

  4. 많은 부분의 자동화가 가능해진다.
    : 백엔드, 프론트엔드가 정밀하게 분리되어 있기에 프론트엔드 뿐만 아니라 정적분석, 테스트, 자동빌드, 배포, 모니터링 등이 가능합니다. (할 수 있는 능력과 여유만 있다면 하세요.)

  5. 화면 개발만 하더라도 과거보다 "훨씬" 많은 것들을 알아야 한다.
    : 과거에는 몰라도 되거나 거기까지 안가던 것들 진짜 수단과 방법을 모두 동원해서 해결해야 합니다. 서버나 DB한테 위임하던 것들을 클라이언트인 프론트엔드에서 해결을 해야하므로 거기에 준하는 구현과 주의사항을 알아야 합니다.

  6. 개발이 즐겁다: 새로운 걸 배우고 응용하려 고민하고 시도해보는 쾌감이 생깁니다. (그 어떤 것 보다 이게 제일 좋습니다!)


관련자료 : 웹 개발자 로드맵