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


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


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


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


법칙 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의 한국어 번역인 '수준'이라는 말을 쓸 수도 있지만 '수준'이라는 말이 가져다주는 뉘앙스, 이를테면 '수준이 낮다', '수준이 높다'처럼 상당히 위화적인 표현으로 대한민국 사회에서 굳어져 있어 알맞지 않다.

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


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

  • 지나가는사람 2013.03.27 22:30

    현장에서는 그 '단'을 무지 많이 사용하죠.ㅋ
    프레임워크단, 어플리케이션단, 화면단, DB단, 내딴 니딴 ...

  • 신입사원 2013.09.23 16:53

    회사에서 과제로 서버단에 대해서 발표하라고 해서 무슨말인지 인터넷을 한참을 찾아다녔는데

    정말 좋은 답변입니다.

    감사합니다. ^^

  • Aris 2014.05.03 11:39

    번역상에서 오는 문제들과 업계들간의 용어 남발로 절차가 뒤죽박죽 되는 경우가 많긴 하죠 mvc 방법론에서 모델단 뷰단 컨트롤러단 등으로 시작된게 아닌가 싶은데 확실치는 않군요... 글 재미있게 보고 있습니다. 감사합니다.

  • 유분수 2014.10.01 16:47

    백번 공감하고 갑니다. 괜히 원서로 공부한번 더 하는게 아니죠 기술서나 표준절차성등, ㅋ 잘 보규 가요

  • 하헤히호후 2015.11.30 14:52

    서버 클라이언트도 우리나라 말이 아닌데 레벨붙여서 서버레벨 클라이언트레벨 하면 안되나요 ??

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

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

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

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


웹 프론트엔드 직군이란?

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

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


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

 

 

습득 요구 지식

특징 

   HTML 코더

 HTML, CSS

 테이블 기반 코딩을 주로 하는 2000년대 초반의 프론트 엔드 개발자가 주로 HTML 코더였는데, 현재 업계에서도 어느정도 남아있는것 같다.

   웹 퍼블리셔

 HTML, CSS, 

웹표준, 웹접근성, 크로스 브라우징

 웹 표준이 중시되면서 생기기 시작한 직군. HTML,CSS를 이용한 페이지를 출판하는 일을 한다. 

   UI 개발자

 HTML,CSS, 웹표준, JavaScript

웹 표준에 기반한 사용자 UI를 개발한다 

   RIA 개발자

 플래시, FLEX, AIR, Silverlight

데스크탑 리치기술을 이용하여 보다 다양하고 인터랙티브한 웹사이트를 만드는 직군. 

   프론트 엔드 개발자

상위 능력 전반과 백엔드 영역 능통 

프론트 엔드 개발자라고 적어놓고 위 능력들을 고루 갖추었다고 써놓았는데, 사실 그렇다고 위에 있는 개발자들이 프론트 엔드 개발자가 아니라는 것은아니다. 필자 개인적인 생각으로 이정도는 해야..진정한 프론트엔드 개발자라고 할수있지않을까하는 개인적은 생각을 반영하여 작성해보았다. 



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


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


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


필자 개인적인 생각으로


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


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


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


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



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

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







  • 진실을 말해줄게 2013.07.22 00:55

    에효~ 하지만 실상은 당신이 말한 프론트 엔드 개발자 정도 되면 역관광 당합니다.
    그리고 당신이 말한 프론트 엔드 개발자 정도의 스킬이면 백엔드 개발자는 대체 뭘합니까?
    설계하는 것도 아니구요.
    비즈니스 로직이 아니고 일반적인 웹 개발자로서의 로직은 매우 단순합니다.
    게시판 말고 특별히 뭐 있나요? 다양한 환경에서 게시판 만드는게 다 아닌가요??
    저기까지 선 그어놓으면 오히려 백엔드 개발자는 뭐합니까?
    뭐 자바 만지면 대단한 벼슬입니까?
    PHP 든 코볼이든 자바든 C 든 어떤 언어든 무시할 건 못됩니다.
    해당 언어는 도구일 뿐이지 그 도구를 안다고 해서 당신이 크리에이티브한 사람이 되는건 아닙니다.
    이러니 웹 개발자가 무시당합니다.
    퍼블리셔 있는걸 고맙게 생각하세요.
    그 사람들 없으면 그거 다 백엔드가 해야하니까

    • 이나라학생 2013.07.22 21:47 신고

      난독증이있으신거같네요^^

  • script_kiddie 2015.06.20 18:39

    ㅋㅋㅋ 난독증 있으신듯


항목 

인라인 

블록

인라인-블록

   영역

 컨텐츠 크기 만큼

지정 값 또는

지정 안할시 너비는 부모의 가로 크기, 세로는 컨텐츠 크기

지정 값 또는 지정 안할시 너비는 

   정렬

텍스트 정렬에 영향 받음.

(텍스트의 위치를 지정하는 모든 속성) 

마진(auto), 패딩 이용

(테이블 내의 경우 verertical aline)

 텍스트 정렬에 영향 받음.

(텍스트의 위치를 지정하는 모든 속성) 

   박스모델

margin-left,right / padding, border ,float

margin(width 값 고정일 때 auto 지정 가능),

padding,border ,float

margin(auto 불가),padding,border ,float

   중첩 요소

 인라인만 가능

블록,인라인 모두 가능 

인라인만 가능 

   특징

포지션이 텍스트와 

유사하게 처리된다.

(vertical-align 영향 받음)

 양 옆에 요소를 둘수 없다.

포지션이 텍스트와 유사하게 처리된다.

(vertical-align 영향 받음) 

   대표 엘리먼트

span, a, strong, em 

div, h1~6, p,  ul, li 

img, input 



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


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

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

다.


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할 경우 문제가 발생한다.

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


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


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


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

  • 러브박스 2016.08.22 13:52

    블록요소인 li안에 div를 넣어도 되는건가요?

    • 이나라학생 2016.10.08 00:32

      됩니다.^^

  • 질문질문 2018.02.12 20:46

    질문이 있습니다.
    인라인 중에 a 요소는 블럭이든 인라인이든 상관없이 쓸수 있나요?
    레이아웃 짜다보면....
    접근성때문이라도 블럭요소를 a 로 감싸야 할때가 있는데
    이럴땐 어떻게 하는게 제일 좋은 방법인가요?

    • 이나라학생 2018.03.21 00:14

      a요소는 블럭인라인 상관없이 가능합니다.
      (HTML5상에서)

      display:block 후에
      a안에 div 넣고 해도 됩니다.

*문자 인코딩


<meta http-equiv="Content-Type" content="text/html; charset=euc-kr">

 

*일정 시간이 지난 후 자동으로 페이지 새로고침


<meta http-equiv="Refresh" content="시간(초)">

 

*일정 시간이 지난 후 자동으로 페이지 이동


<meta http-equiv="Refresh" content="시간(초);url=주소">

 

*검색엔진에서 검색되는 키워드


<meta name="Keywords" content="html,tag,mata,메타,태그">

 

*캐쉬 막기


<meta http-equiv="Pragma" content="no-cache">


*캐쉬 만료(파기)일


<meta http-equiv="Expires" content="Mon, 08 Sep 2003 10:10:10 GMT">

** 보통 캐쉬막을때 <meta http-equiv="Expires" content="0"> 사용

 

페이지 들어갈때 나갈때  트랜지션 효과


<meta http-equiv="Page-Enter" content="revealtrans(duration=1,transition=12)">
<meta http-equiv="Page-Exit" content="revealtrans(duration=1,transition=12)">

 

페이지에 대한 정보


<meta name="Description" content="META 태그에 관한 정보">

 

컨텐츠 제작자


<meta name="Author" content="이름">

 

제작 툴


<meta name="Generator" content="Ultra Edit">


저작권 정보


<meta name="Copyright" content="2012 이나라학생">


<meta name="format-detection" content="telephone=no">

 

[출처] meta tag 총정리|작성자 노원오디

  • sr 2016.04.15 14:05

    감사합니다블로그에 출처 난ㅁ겨서 옮기도록 하겠습니다


아규먼트(argument) 와 파라미터(parameter) 흔히들 구분하지 않고 사용한다.

하지만 이 둘은 분명히 차이가 있다.


PARAMETER란?


한글 그대로 번역하면 '매개변수'란 뜻이다. 즉,


함수를 정의 할 때

외부로부터 받아들이는 임의의 값을 의미한다.

가령 

function f(x,y){

return x+y;

};

에서 x,y가 파라미터라고 할수 있다.

 그럼 ARGUMENT란?

우리말로는 '인수' 라고 번역되는데,

함수를 호출할 때 이 때 사용하게 되는 일련의 값들을 아규먼트라고 부른다.

예컨대 위에 파라미터의 예를 들었던 함수를 호출한다고 하면,

f(3,4);

에서 3,4등이 아규먼트이다.


즉, '파라미터의 값으로 아규먼트 3과 4를 대입하였다'

라는 의미가 성립하는것이다.


이처럼 파라미터와 아규먼트는 분명 같은위치에 있지만 다른의미로 쓰이는 것을 알수 있다.



 

국내 시장 특성상 아직은 IE의 점유율이 떨어질줄 모르지만

개발자 입장으로선 IE7만 사라져 준다면........

(사실 2년 전만해도 'IE6만 사라져준다면......'하고 빌었었는데.

사람의 욕심이란 이렇게 무섭다.)

지금 IE7의 점유율을 보니 국내에서 IE7이 사라질날도 머지않은듯 하다.

그래도 아직은.......IE8까지는..사라져주었으면 하는 욕심이.......

아니 IE보다는 다른 Modern Browser가 우리나라에서도 적극적으로

이용되는 날이 왔으면 하는 바램이다.

나는 front-end 개발자 일까? back-end 개발자 일까?


IT관련 일을 해보신 분들은 많이 들어본 이야기 일것 같다.

왜 FE(front-end) 와 BE(back-end) 를 나누어 놓았을까?

개발자로서의 기술적 능력의 높고 낮음을 구분하고 싶어서 였을까?


다른 분류 방법을 제외 하고 단순 FE 와 BE 만을 가지고 이야기 하고자 한다.

FE 와 BE 개발자는 조금씩 다른 언어로 개발을 한다고 생각한다.


일반적으로 다음과 같이 통용된다.

FE : html, css, javascript

BE : server side scripts(asp, php, jsp ..),  java 


이런 분류법이 꼭 맞는건 아니다.

다만 내가 경험해본 IT 쪽 사람들이 자기는 FE 개발자고 BE 개발자라고 말하는 사람들의 개발 언어를 살펴본 내용을 바탕으로 정리를 해본 것이다.


과거에는 FE 라 하면.. 크게 기술을 요하지 않는다고 생각을 많이들 했었다고 생각 한다.

(논란이 있지만 사실이기도 하다. UI적인 대부분은 플래시가 담당하고 있었고, 레이아웃은 소위 말하는 '테이블 코딩'이 

모든걸 해결해주고 있었다.)

BE 는 특정한 기술을 요구하고 또한 개발하는데 어려움이 많다고도 여겼던게 사실인것 같다.


그럼 지금은 어떤가?

지금은 개발자간 기술의 벽이 많이 허물어 지고 그 차이도 크지 않다고 생각 한다.

이제는 프론트엔드의 영역이 웹 표준과 접근성에서부터 dynamic UI/UX에 web Application까지 다양해지며
프론트 영역이 결코 만만한 부분이 아님을 다들 인정하는 분위기다.

다만  FE 와 BE 를 구분짓고 나는 BE 개발자이니 FE 는 내가 알바 아니다 라고 얘기 하는 사람, FE 개발자이니 BE 는 내가 알바 아니다 라고 얘기 하는 사람이 있다면 당장 생각을 고쳐 먹어야 한다고 생각 한다.

적어도 IT 에서 일을 하는 사람이라면 말이다.


서비스를 만드는데 FE 가 어딨고 BE 가 어딨겠는가.

서로 서비스에 대한 needs 와 requirements 를 잘 이해하고 user interaction 에 잘 부함되는 서비스가 될수 있도록 상호 긴밀한 협동을 해야 하는게 아닌가.


분야의 다양성과 각자의 능력에는 차이가 있다는것은 분명히 인정하는 부분이다.

하지만 같은 서비스를 만들면서 FE 니 BE 니 설왕설래 하는건 에너지 낭비며 web2.0 시대에 개발자가 가져서는 안되는 정신 같다.


서로 같은 분야에 종사하며 개발자로서의 삶을 살아 간다면 다 같이 win win 하는 그럼 마음 가짐을 가졌으면 좋겠다.