쉽고 빠르게 배우는 시대, 과연 충분한가?
강의 프로그램, 유튜브 팁 영상 그리고 블로그 등 다양한 곳에서 원하는 것을 배울 수 있습니다. 그런데 최근에는 다양한 콘텐츠의 90%에서
'쉽게', '간단하게'
라는 키워드가 반복되고 있죠. 많은 콘텐츠는 아주 간편하게 원하는 것을 할 수 있는 방법을 짧은 시간 안에 알려주려 합니다. 하지만 과연 그것만으로 충분한지는 고민해볼 필요가 있습니다.
이러한 콘텐츠는 높은 확률로 필요한 배경 지식과 이해를 생략한 채, 단순히 ‘딸깍’하는 방법만을 전달하곤 합니다. 실제로 실무 환경에서 보면, 원리와 구조에 대한 이해없이 단순히 주입된 '딸깍' 방식으로 작업하는 사람들을 자주 마주하게 됩니다. 이러한 방식은 잘못된 것은 아니지만, 실무에서는 명확한 한계가 드러납니다.
앞으로 HTML/CSS를 순차적으로 복습하며 그 내용을 정리해 나갈 예정입니다. 불필요해 보일 수 있는 내용도 있고 반드시 알아야 할 개념도 있지만, 저는 이해가 되지 않으면 기억하지 못하는 성향이기 때문에 ‘모두의 연구소’에서 제공하는 교재를 정독하며 천천히 정리해보려 합니다.
단축키는 도구가 아니라 ‘효율’이다
Visual Studio Code는 소스 코드 편집기이며, 전 세계에서 많이 사용되는 인기 있는 개발 도구입니다. Extension(확장 프로그램)을 통해 다양한 기능을 추가할 수 있고, 지속적인 업데이트를 통해 개발 효율을 높일 수 있습니다.
디자인 툴과 마찬가지로, 다양한 단축키가 제공되며 단축키 사용은 작업 속도 향상에 매우 큰 도움이 됩니다. 어느 프로그램이든 단축키를 많이 익히고 습관화 할수록 생산성이 올라갑니다.
제가 현재 사용하며 익히고 있는 주요 단축키는 다음과 같습니다:
1. command(ctrl) + B : VSC 왼쪽 탐색창 열기 / 닫기
2. command(ctrl) + shift + S : 다른 이름으로 저장
3. Shift + option(alt) + ↑ / ↓ : 선택한 줄 복사
4. option(alt) + ↑ / ↓ : 선택한 줄 이동
5. command(ctrl) + shift + K : 한 줄 삭제
6. command(ctrl) + option(alt) + ↑ / ↓ : 다중 라인 수정
아직 학습한 기간이 길지 않아 6가지 밖에 되지 않지만, 계속해서 늘어난다면 작업 효율이 높아지겠죠? 추가로, 아래 링크에서 더 다양한 단축키 정리를 참고할 수 있습니다.
VS Code 단축키 정리 – 데문 개발자 블로그
단축키 - Visual Studio Code tutorial
단축키 파일 > 기본 설정 > 바로가기 키 에서 현재 활성화된 키보드 단축키를 볼 수 있습니다 . 기본 편집 키 명령 명령 ID ctrl+X 행 삭제 (빈 선택) editor.action.clipboardCutAction ctrl+C 행 복사 (빈 선택) e
demun.github.io
파일명과 확장자, 협업의 기본부터 바로잡기
많은 사람들이 실무에서뿐만 아니라 학습할 때에도 파일명을 대충 짓는 실수를 하곤 합니다. 저도 학생 시절엔 그랬지만, 실무에서는 제가 만든 파일이라도 다양한 팀원, 회사, 클라이언트와 공유될 수 있기 때문에 파일명을 명확하게 정하는 습관을 들이게 되었습니다.
회사에서 디자인팀 팀장으로 근무할 당시, 신입 교육자료와 업무 프로세스를 정리하면서 파일명 작성 규칙을 명확히 지정했던 경험이 있습니다. 간혹 파일명이 잘못되어 오류가 발생하는 경우도 있었기 때문에 더욱 중요하게 느껴졌죠.
예를 들어 디자이너들은 습관적으로 파일명에 _
(언더바)를 사용하는 경우가 많은데, 웹 환경에서는 이러한 특수문자나 공백, 대소문자 혼용이 웹 서버 및 브라우저와의 호환성 문제를 야기할 수 있습니다.
따라서 파일명은 다음과 같이 작성하는 것이 바람직합니다:
- 공백 없이
- 영문 소문자만 사용
- 특수문자 지양
이번에 프론트엔드를 공부하면서 느낀 점인데, 디자인 결과물을 만들 때에도 이런 네이밍 규칙을 적용할 필요성을 강하게 느꼈습니다.
VSC(Visual Studio Code)에서는 파일명 뒤에 .html
, .css
, .js
같은 확장자를 붙이면 자동으로 해당 언어에 맞는 문법으로 편집 가능한 파일이 생성됩니다.
이는 어도비 파일의 확장자(.ai
, .psd
, .pdf
)와 개념상 유사합니다. 다만 어도비 파일은 각각의 적합한 프로그램에서 편집하는 것이 효율적이지만, HTML, CSS, JS는 모두 VSC 하나에서 자유롭게 편집이 가능하죠. (사실 저는 처음에 각각 다른 편집 툴이 필요한 줄 알았답니다 😅)
상대경로와 절대경로
실제로 다양한 서비스를 보면 브레드 크럼에서 ‘... / OOO / OOO’ 와 같은 경로 정보를 본 적이 있습니다. 이건 상대 경로에서 유래한 방식일까요? 한번 찾아봐야겠네요...
상대 경로란 현재 제가 사용하고 있는 파일을 기준으로 다른 파일의 경로를 작성할 때 사용할 수 있습니다. ./
은 현재 폴더를 기준으로 하고, ../
는 현재 파일의 상위 폴더를 기준으로 경로를 찾을 수 있습니다.
절대 경로는 http://
, https://
와 같은 도메인 네임에 포함된 것으로, 인터넷상의 유일한 절대적인 경로(URL)입니다.
프론트엔드 작업 중 파일 정리는 필수적입니다. 파일끼리 연결도 필요하고, 이미지 파일을 불러올 수도 있기 때문에 파일명과 파일 경로를 사전에 꼼꼼히 정리하는 것이 필요합니다.
많은 실무 환경에서 파일구조 및 정리는 필수적인 요소이며, 직군과 무관하게 잘하는 것이 좋다고 생각합니다. 처음 한 번 신경 써서 잘 정리해 놓으면 프로젝트 기간 내내 편하답니다?
개발자 도구
개발자 도구의 경우 크롬에서 ‘F12’ 키를 누르거나, ‘마우스 오른쪽 클릭 > 검사’를 통해 사용할 수 있습니다. 일반 웹사이트에서 개발자 도구를 열면 해당 사이트의 코드를 직접 확인해볼 수 있습니다.
또한 Extension(확장)을 통해 ‘Go live’를 사용하면 디자인 툴의 프로토타입 또는 프리뷰처럼 실시간 확인이 가능한 환경을 만들 수 있습니다.
개발자 도구는 디자이너도 실무에서 기능 테스트 및 디자인 검수를 위해 사용하는 경우가 있습니다. 대부분의 디자이너는 잘 모르는 부분이지만, 실무에서 함께 일하는 디자이너가 개발자 도구 사용법을 모른다면 간단히 실행하는 법만 알려줘도 잘 사용할 수 있을 겁니다.
디자이너는 대부분 툴을 공식적으로 학습하지 않죠. 그냥 들이박으면서 하나씩 알아가는 부류가 대부분이라 금방 적응합니다. (지금 저도 ‘VSC’를 배우면서 그러고 있는 중이죠… 후후)
HTML, CSS, JS를 배우며 깨달은 디자인과 개발의 차이
실제 업무 중 개발자 분들께 HTML, CSS, JavaScript에 대해 종종 들어본 적이 있습니다. HTML은 구조를 짜는 것이며 가장 기본적인 언어, CSS는 스타일을 입히는 것, JavaScript는 기능을 넣는 것이라고 설명해주셨죠. 그리고 그중 JS가 가장 어렵다고 했습니다.
그때 저는 장난삼아 ‘너희가 하는 일이 그건데 잘해야지’라고 말했지만, 지금은 배우면서 제 입을 때리고 싶었습니다. 정말 어렵더군요.
사실 디자이너는 ‘구조를 짠다’, ‘스타일을 입힌다’, ‘기능을 넣는다’는 차이점을 명확히 인지하지 못합니다. 디자이너에게는 이 모든 행위가 그저 사용성과 심미성을 위한 디자인 작업일 뿐입니다.
- ‘구조를 짠다’ → 가독성과 심미성을 고려한 레이아웃과 그리드
- ‘기능을 넣는다’ → 인터랙션으로 기능성과 심미성을 표현
- ‘스타일을 입힌다’ → 모든 화면 요소에 시각적 통일성을 부여
개발자 분들은 디자이너와 이야기할 때 “다른 요소 때문에 심미성을 포기해야 한다”는 표현은 조심해 주세요.
생각보다 여기서 트러블이 많이 생깁니다. 디자이너의 역린이에요.
1. HTML?
HTML은 ‘HyperText Markup Language’의 줄임말입니다. 여기서 중요한 것은 ‘Markup Language’라는 점입니다. HTML은 콘텐츠 구조를 정의하는 마크업 언어이며, <>
태그를 사용해 문서의 구조를 정의합니다. 예를 들어, 제목, 부제목, 텍스트, 이미지, 버튼 등 각각의 요소가 <body>
태그 안에 '있다'는 걸 정의하는 역할을 하죠.
2. CSS?
CSS는 ‘Cascading Style Sheets’의 줄임말입니다. 말 그대로 웹페이지의 모든 스타일을 정의하는 언어입니다. HTML에서 구조를 정의한 후, 그 구조에 생김새를 입히는 역할을 합니다. 쉽게 말하면, 디자인 시스템에서 정의된 색상, 폰트, 여백, 크기 등 대부분의 시각 요소를 CSS를 통해 구현합니다.
3. JS?
JS는 ‘JavaScript’의 줄임말로, 웹페이지에 기능과 동작을 부여하는 언어입니다. 사용자의 상호작용에 반응하거나, 동적인 동작을 추가할 수 있습니다. 버튼 클릭, 메뉴 토글, 팝업 노출 등 디자이너가 흔히 말하는 ‘인터랙션’은 대부분 JavaScript로 구현됩니다.
Figma와 VSC, HTML/CSS/JS는 결국 닮아 있다
이렇게 정리해서 공부해보니, 디자이너가 이해하지 못할 영역은 정말 없다는 생각이 듭니다. 대부분의 작업은 이미 디자인 툴 내에서도 유사하게 수행하고 있기 때문이죠.
예를 들어 Figma를 기준으로 보면:
- 좌측의 ‘Pages’ 영역은 VSC의 탐색창과 유사합니다. 화면, 디자인 시스템, 컴포넌트 등을 분리해두는 구조는 각각의
.html
,.css
,.js
파일 구성과 비슷합니다. - ‘Layers’ 영역은 HTML 구조처럼 볼 수 있습니다. 전체 UI 구성요소가 트리 구조로 정리되어 있고, 순서나 명명에 따라 구성 요소가 정의 되어있죠.
- 우측의 속성 지정 영역은 CSS 역할과 흡사합니다. Position, Layout, Color, Font 등 스타일 속성을 지정하는 영역이니까요.
- 그리고 우측 상단의 ‘Prototype’, ‘Preview’ 기능은 JS와 비슷한 위치에 있다고 생각됩니다. 인터랙션과 동적 미리보기 기능이니까요.
이렇게 보니, 유사한 작업을 하면서도 전혀 다른 도구를 사용하고 있다는 게 정말 흥미로웠습니다.
실무에서 디자인 교육을 할 당시 저는 ‘Layers’ 정리를 매우 중요하게 여겼습니다. 실제로 현업에서 접하는 많은 디자인 파일은 레이어가 복잡하게 얽혀 있고, 정리가 되어있지 않아 협업이 어려운 경우가 많습니다.
그래서 신입 디자이너에게는 항상 이렇게 말했습니다. “그룹핑만 잘해도 협업이 쉬워진다.”
같은 맥락으로 개발자 분들에게는 이렇게 이야기했죠. “그룹핑만 이해하면 디자인 파일 해석이 쉬워진다.”
HTML과 CSS를 복습하며 더 자주 이야기하겠지만, 현업에서 일하며 더욱 확신하게 된 것은 이겁니다:
디자이너는 자신이 만든 면 하나, 점 하나, 선 하나를 모두 정의하고 정렬하고 정리할 수 있어야 한다.
그리고 개발자 역시 디자인 툴의 최소한의 기능은 이해해야 한다.
제가 실무를 처음 시작했을 당시에는 (psd로 UI 디자인을 하던 시절) 디자이너가 버튼/아이콘의 크기, 여백(margin, padding), width, height 등 모든 수치를 ‘px’ 단위로 화면설계서에 적어서 전달했었습니다. 개발자는 디자인 파일 없이 화면설계서만으로 개발을 할 수 있었죠.
하지만 시대는 변했고, Figma는 이제 디자인 툴을 넘어 협업 툴이 되었습니다. 더 이상 디자이너는 친절하지 않습니다. 개발자는 스스로 Figma를 열어 수치를 확인하고, 아이콘과 이미지를 추출할 수 있어야 하는 시대가 온 것이죠.
마무리하며 – 개발 공부, 결국 나를 위한 기록
생각보다 글이 길어져서 혹시 지루하게 느껴졌을지도 모르겠습니다. 하지만 이번 글은 단순한 지식 전달보다는 공부하면서 느낀 점을 직접 풀어내는 기록이 되고 싶었습니다. 공감하신 분들도, 잘 이해가 되지 않았던 분들도 계시겠지만, 이런 복잡하고 긴 여정이 결국 제게 큰 의미가 될 거라 믿습니다.
다음 글에서는 HTML에 대한 복습으로 다시 찾아오겠습니다.
'Design & Front-end' 카테고리의 다른 글
디자이너의 손에서 코딩까지 – HTML의 첫걸음 (5) | 2025.06.26 |
---|---|
8년 차 UX 디자이너, 왜 프론트엔드를 배우기 시작했을까? (3) | 2025.06.05 |