Coding Story

자바스크립트는 변수 타입에 대한 설정이 상당히 관대한 언어이다.

어떤 변수 타입에 관한 잘못을 저질렀을때 자바스크립트는 오류를 내보내는 것 대신에

숫자는 문자로, 문자는 또 숫자, 기타 등등 으로 상황에 따라 적절(?)하게 변화시켜준다.

필자가 코딩을 하며 경험한 자바스크립트 변수 타입 오토캐스팅에 관한 몇가지 사실들을 공유하고자 한다.

법칙 1) 문자열 + 숫자 ->숫자가 더해진 문자열

예컨대

var x='abc';

var y=3;

alert(x+y);     // 'abc3' 출력

가장 기본적인 사실로, 대부분의 웹개발자가 할고있는 사실이다.

법칙 2) 비교연산자를 사용할 때 숫자vs문자를비교하면 문자열을 자동으로 숫자로 변환하여 비교해준다.

3>'4'를 비교하면 false라는 결과가 출력될 것이다.

법칙 3) 비교연산자를 사용할 때 문자열인 숫자 둘을 비교할 때,

자릿수가 같으면 올바로 연산을 해주나, 자릿수가 다르면 문자열로 인식하여 비교한다.

예컨대 '3000'>'2500'의 결과는 true이나, '3000'>'500'은 false이다.

----> 자바스크립트에서 문자열을 비교할 때는 문자열의 유니코드 값을 비교한다.

'3000'>'500'인 이유는 3보다 5가 유니코드 값이 더 크기때문이다.

법칙 4) 두 식중 하나가 NaN이면 항상 false를 반환한다.

물론 이경우는 숫자와 문자열을 비교했을때 자바스크립트가 믄자열인쪽을 숫자로

변환하다 NaN이 등장했을 경우이다.

이 바닥에 있으면서 출처가 명확하지 않은 단어들이 업계에서 사용되는 걸 보고 처음에 의아해한 적이 있는데 그게 바로 '서버단', '클라이언트단', '네트워크단'이다. '단'은 여러군데에서 사용되고 있어 그 의미가 정확히 무슨 뜻인지 아느냐고 물어보면 다들 "그냥 그렇게들 쓰고 있는데요?" 하며 개의치 않는 분위기이다.

처음 '단'에 관한 이야기를 들었을 때 어떤 개발 영역의 단체를 뜻하는 것으로 생각했었다.

예를 들어 사람들이 '클라이언트단' 이라고 할 때에는 '클라이언트단에서 처리할 것이 별로 없다. 다만 서버단에 부하가 많다는 게 문제이다'와 같이 이야기한다고 하자. 여기서 쓰이는 '단'은 왠지 '집합'적 의미가 있어 보인다. 그럼 '둥글 단(團)'을 쓰는 게 맞는 것처럼 보인다. 예를 들어 사기단, 사절단, 도박단, 사업단 같은 것처럼. 하지만 '측'이라는 의미도 매우 강해보인다. 인용한 부분을 '측'으로 치환하면 '클라이언트측에서 처리할 것이 별로 없다. 다만 서버측에서 부하가 많다는 게 문제이다'처럼 말이 가능해진다. 그렇다면 '측'이 맞는 말이 아닐까?

아쉽겠지만 위의 논의와는 전혀 상관없이 사실 이 '측'과 '단'의 문제는 실제로는 영어 번역에서 온 문제이다. '측'은 'side'를 번역할 때 온 것으로 한자로는 '곁 측(側)'을 쓴다. '단'은 'level'을 번역할 때 온 것으로 한자로는 '층계 단(段)'을 쓴다. 즉 '클라이언트단', '서버단'은 각각 'client level'과 'server level'의 번역인 셈이다.

'측'은 대립되는 사물의 어느 한 쪽을 나타낼 때, '단'은 '계단'에서처럼 여러 개로 나뉘어진 경우에 쓴다.

따라서 엄밀히 말하면 예로 들었던 '클라이언트단에서 처리할 것이 별로 없다. 다만 서버단에 부하가 많다는 게 문제이다'라는 말은 다시 말하면 '데이터가 클라이언트를 거쳐 서버를 거친 후 어디론가 가는데, 클라이언트를 거칠 때에는 처리할 게 별로 없지만 서버를 거칠 때에는 처리가 많아 부하가 많다.'는 말로 풀어서 쓸 수가 있다.

그런데... 사실 '단'을 쓰는 게 그다지 안 어울리는 건 사실이다. 계단, 상단, 중단, 하단이라는 말은 그간 사용되어 온 말이기 때문에 어울리지만 '클라이언트단'은 왠지 어딘가 모르게 어색하다. '계층'이라는 말은 'layer'라는 말에 대한 번역으로 쓰이고 있기 때문에 이도 어쩔 수 없고 대표적인 level의 한국어 번역인 '수준'이라는 말을 쓸 수도 있지만 '수준'이라는 말이 가져다주는 뉘앙스, 이를테면 '수준이 낮다', '수준이 높다'처럼 상당히 위화적인 표현으로 대한민국 사회에서 굳어져 있어 알맞지 않다.

차라리 '단계'라는 말이 좀더 어울리지 않을까?

아직 수년차에도 접어들지 못한 초보 개발자이지만 직관적이고 익숙해지지 않아도 어색하지 않을수 있는, 입문자들도 쉽게 이해할수 있는 개발용어가 사용되길 기대해본다.

누구나 알다시피 최근 웹 기술의 경향은 단연 클라이언트 쪽에 집중되어 있다.

수 년전을 비교해 보면 엄청난 변화이다. 웹 개발은 크게 프론트엔드와 백엔드로 나누어져 있지만, 국내에서는 프론트엔드 보다 백엔드 개발자 흔히 '웹 프로그래머' 혹은 '웹 개발자'라고 부르는 사람들의 가치가 더 높았다. 다시 말해서 몸값이 더 비쌌다는 이야기다.

하지만, 웹 프론트엔드가 더 복잡해지고 다양한 기술이 쏟아지면서, 프론트엔드 개발자에 대한 수요와 가치가 증가하였고, 이쪽 기술 직군의 정의가 점점 어려워지고있다.

과거 프론트엔드 개발자는 백엔드 개발을 할 기술이 없거나 그 전단계에 하는 견습 정도로 여겨지곤 했었는데, 이와 달리 현재에는 백엔드 개발이 어려워서 이거나 프론트엔드 개발이 쉬워서가 아닌 프론트엔드 개발 자체가 좋아서 프론트에 남아서 개발을 하는 개발자가 많다. 

웹 프론트엔드 직군이란?

2000년대 초반만 하더라도 웹 개발에서는 웹마스터, 웹개발자, 웹디자이너로 나눠져 있었다. 대부분 웹 디자이너가 마크업을 담당했는데, (웹 표준 마크업의 주요성이 덜할 당시) 효율성을 위해 웹 디자이너가 만든 PSD 파일을 짤라서 HTML로 코딩만 하는 'HTML 코더'라는 직종이 있었다.

하지만, 2000년대 중반 부터 웹 표준 마크업의 중요성이 대두되면서 포털 업계를 중심으로 'UI 개발' 직군이 중요한 화두로 떠 오른다. (X)HTML과 CSS를 중심으로 DOM을 핸들링하는 자바스크립트까지 다루는 기술셋을 가진 개발자들이다.

역할에 따른 모델 제안
분명한 사실은 HTML/CSS/JS 기술을 떠난 프론트엔드 개발은 불가능하다. 요즘에는 게임도 웹으로 만들고 2D/3D 그래픽도 웹으로 하는 시대다.

위에서부터 순차적으로 습득 요구 지식이 어느정도 누적 되는 것을 볼수있는데, 

코더 -> 웹퍼블리셔 -> UI개발자 -> (RIA개발자) ->Front-End 개발자

순으로 능력을 덧붙이며 한단계씩 발전한다는 느낌이 강하다.

필자 개인적인 생각으로

HTML 코더나 웹 퍼블리셔 역시도 프론트 엔드 개발자라는 생각은 변함이 없고, HTML,CSS를 등한시 하는것은 아니지만,

HTML,CSS만 할줄 아는 사람과 HTML,CSS,JS를 모두 하는 사람을 동등하게 바라볼 생각은 없기에,

웹 퍼블리셔 까지는(HTML코더는 더더욱,) 미완성의 프론트 엔드 개발자가 아닐까 생각해본다.

[웹 퍼블리셔가 프론트 엔드 개발의 제일 윗단으로, 기획과 디자이너와의 조율을 한다는 견해도 있으나, 필자 경험상 그런 역할은 주로 PL이 맡아서 하는 경우가 대부분이었다.]

웹 FT의 미래는 더 밝다!
프론트엔드 개발자보다 백엔드 개발자들의 몸값이 높고, 백엔드 중에서도 자바나 닷넷 개발자가 PHP나 Python을 쓰는 개발자 보다 몸값이 높은 아이러니한 상황은 국내만의 이상한 현상이다. (웃긴 건 Yahoo, Facebook , Twitter모두 PHP를 주력 개발 언어로 쓴다.)

아직도 "HTML이나 자바스크립트 하는게 뭔 개발이야?"라고 하는 분들께 나는 꼭 이 한마디를 보태 드린다. "구글에서는 아이비리그 나온 박사들도 다 HTML이랑 자바스크립트 해야 하거든요?"

여기까지 인라인, 블록, 인라인 블록에 대하여 살펴보았는데, 여기서 빼놓지 말아야 할 중요한 사실이 있다.

첫째. 바로 블록 요소 또는 인라인 요소 안에 어떤 요소를 중첩 시킬수 있느냐의 문제인데,

위 표에서는 블록 안에는 블록,인라인 모두 가능하고 인라인,안에는 인라인만 가능하다고 쓰여있는데 좀더 생각해볼 필요가 있

다.

1.인라인 내부에 인라인을 쓰더라도 문제가 되는 경우

의미만을 주거나 스타일만을 주는, 예컨대 strong, font, em, b, i등의 인라인 요소 안에는

다른 인라인 요소를 중첩 시켜서는 안된다.

가령, <i><a href="#">여기</a></i>

와 같은 중첩은 잘못이다. (여러의미, 스타일을 동시에 주기위한 중첩은 가능,

가령 <i><b>bold italic</b></i> 로 두효과를 주기위해 사용가능하다.)

2.블록 내부에 블록을 쓰더라도 문제가 되는 경우

다른 문제는 없지만, p,h1~6 류는 블록요소들이지만 다른 블록 요소를 중첩시킬수 없다.'

(+추가, ul,ol,dl 등 목록 밑에는 지정된 요소가 들어가야 한다.

예컨대 ul,ol 밑에는 li만을, dl 밑에는 dt,dd이다. 여담이지만 dt,dd,li 아래로는 예외없이 사용가능하다.)

3.강제로 display를 바꾼 경우의 문제

강제로 display를 바꿨더라도, 그 속성의 원래 속성을 상정한 후, 위 규칙을 따른다.

가령 span이 블록 요소가 되더라도 안에 div, p 등을 중첩해서는 안되고,

div가 인라인 요소가 되더라도 a 태그 안에 중첩될수 없다.

->validator 통과상 문제이기에 유효성 검사기는 그요소의 현재 display를 체크해주지는 않기 때문인데,

단순히 유효성 검사상 문제 떄문에 위 규칙을 지켜야 하는 것은 아니고, 조금 엄격한 브라우저에서는

레이아웃이 뒤틀리게 보여질수 있기 때문이다. 

(필자 같은 경우 span안에 div를 넣고 IE8에서 레이아웃이 틀어지는 것을 보고

무작정 IE8 탓만 한적이 있다. 그것은 IE가 나쁜것이 아닌 필자가 마크업을 잘못했기 때문이다. 아, 물론 IE8이 좋은브라우저 라는것은 아니다..^^;)

둘째는 float에 관한 문제인데,(자세한 이야기는 CSS이야기 탭에서 합시다.^^)

블록 요소에 float을 주기 전에, 기본적으로 width 값을 설정해 주는것이 맞다. 그러나 지정하지 않으면

마치 인라인에서 너비를 결정할 때 컨텐츠 크기로 결정하는 것처럼 컨텐츠 크기가 가로 사이즈가 된다.

(IE6같은 경우는 너비를 주지않고 float할 경우 문제가 발생한다.

----------------------------------------------------------

이상으로 인라인 ,블록 요소에 대해 정리해 보았는데,

나름 필자가 공부하면서 헷갈렸던 것 위주로 정리해보았다. 마크업을 하는데 있어

상당히 중요한 사실이지만 빼놓고 가기 쉬운부분이니 확실하게 알아두도록 하자.