최근 한 개발자 커뮤니티 대나무숲에서 자기소개에 대한 고민 글을 보게 되었습니다. “내일 면접인데 혹시 자기소개는 보통 어떤 식으로 하나요? 무슨 말로 자기소개를 해야 할지, 어느 정도 문장으로 구성해야 할지 고민이네요.” 이 글을 보고 나서 예전에 면접 볼 때 자기소개를 어떻게 했었는지 다시 한번 떠올려봤습니다. 사실 마지막으로 면접을 본 게 거의 3년 전이다 보니, 만약 지금 당장 면접을 본다면 저를 어떻게 소개해야 할지 생각하게 됐습니다. 일반적으로 면접의 시작은 1분 자기소개와 함께하니까요. 1분이라는 시간이 누군가에게는 짧게, 또 누군가에게는 길게 느껴질 수도 있는데요. 이 시간에 나의 장점을 잘 어필하기 위해서는 구조를 다듬고 표현을 정제하는 과정이 필요하며, 철저히 준비해야 실수를 줄일 수 있습니다. 오늘은 이 질문에 대한 답변을 바탕으로 이야기해 보려고 합니다.

개발자로 살아가면서 어려움을 겪는 것은 피할 수 없는 일입니다. 기술적 실력이 모자라서 그럴 수도 있고, 개발하고 있는 분야에 대한 도메인 지식이 부족해서 그럴 수도 있죠. 또한 동료와의 커뮤니케이션, 정치적인 요소, 일정의 압박, 회사의 재정 상태처럼, 개발 그 자체와는 직접적으로 상관이 없는 외부적인 요소로 인해 어려움을 겪기도 합니다. 오늘은 이러한 어려움의 유형 중에서도 문제 해결(Problem solving) 과정에서 겪는 어려움에 대해 집중해 보려고 합니다. 왜냐하면 외부적인 요인은 개발자 개인의 노력과 능력만으로는 통제할 수 없는 상황이 많으니까요. 반면 문제 해결 과정에서 겪는 어려움을 분석한다면 내가 어떤 이유로 인해 혼란스러움을 겪고 있는 상태인지 알 수 있고, 그에 맞는 적절한 해결 방법을 선택할 수 있을 것입니다.

MacOS와 같은 유닉스 계열 운영체제에서 개발하게 되면 터미널 환경에서 텍스트를 수정할 일이 많이 생기곤 합니다. 물론 요즘은 VSCode, Webstorm 같은 코드 에디터나 IDE가 잘 되어 있어서 이를 활용할 수도 있지만, 운영체제의 기본 텍스트 에디터가 Vim이다 보니 부득이하게 사용해야만 하는 경우가 있죠. 오늘은 Vimtutor에서 제공해 주는 튜토리얼을 한번 쭉 훑어보면서 Vim 명령어를 다시 상기해 보려고 합니다. 이번 글을 통해 Vim 사용법이 익숙하지 않은 분들에게 도움이 되면 좋겠습니다.

실제로 디버깅을 해보면 브라우저에서 인식할 수 없는 파일이라고 해도 코드 라인의 위치를 정확히 짚어주는 것을 확인할 수 있습니다. 이것이 가능한 이유는 우리가 브라우저에게 원본 소스 코드와 변환된 소스 코드의 관계를 맺어주는 정보인 소스 맵(Source map) 을 제공하기 때문입니다. 그렇다면 소스 맵은 어떤 방식으로 그러한 정보를 저장하고 있는 걸까요? 오늘은 웹 개발에서 디버깅을 훨씬 쉽게 만들어주는 필수적인 파일인 소스 맵에 대해 알아보겠습니다.

OTT 콘텐츠 많이들 보시나요? 지금 당장 생각나는 것만 해도 넷플릭스, 유튜브, 웨이브, 티빙, 왓챠 같은 많은 OTT 서비스들이 떠오르네요. 그런데 프론트엔드 개발을 조금이라도 해봤다면 웹 브라우저에서 저작권에 민감한 콘텐츠를 재생할 수 있다는 것이 매우 이상하게 느껴질 것입니다. 왜일까요? 개발자 도구를 쓸 줄 안다면 비디오 파일의 원본 URL을 쉽게 확인할 수 있고, 심지어 다운로드까지 할 수 있기 때문입니다. 그렇다면 여러 OTT 서비스들은 콘텐츠의 저작권을 보호하기 위해 어떤 기술을 사용하고 있을까요? 웹 브라우저에서 OTT 콘텐츠를 안전하게 재생하기 위해서 어떤 절차를 거쳐야 할까요?

코드 리뷰는 어렵습니다. 주는 입장에서도 그렇고, 받는 입장에서도 그렇습니다. 만약 코드 리뷰를 난생처음 해보거나, 익숙하지 않은 환경에서 코드 리뷰에 참여해야 한다면 혼란스러움은 더 커지곤 하죠. 저는 이를 극복하기 위해 저만의 멘탈 모델을 만들게 되었습니다. 처음에는 코드 리뷰를 창과 방패의 싸움이라고 단순하게 생각했는데, 개념을 계속 확장하다 보니 어느 순간 코드 리뷰의 목표가 스포츠맨십과 크게 다르지 않다는 생각이 들었습니다. 이러한 멘탈 모델을 떠올린 덕분에 코드 리뷰에 참여하는 사람의 태도와 철학에 대해서도 고민을 해볼 수 있었죠.

프론트엔드에서 날짜와 시간을 다루는 작업은 매우 흔한 일입니다. 그래서 ‘자바스크립트(JavaScript)’에서는 Date 객체가 빌트인으로 존재하죠. 하지만 JavaScript의 Date만으로 날짜를 다루는 것은 생각보다 쉽지 않습니다. 그래서 오늘은 JavaScript의 Date 가 시간을 다루는 방식에 대해 좀 더 깊게 알아보고자 합니다. 이 포스트에서는 표준 시간대가 왜 필요하고, JavaScript의 날짜와 시간 처리 방식은 무엇이며, 이것이 왜 다루기 어려운지를 알아봅시다.

하나의 웹 사이트에서 왜 이렇게 다른 버전의 HTTP가 사용되고 있는 걸까요? 각 버전에는 무슨 차이가 있는 걸까요? 왜 HTTP의 버전은 1, 2, 3으로 딱 나누어 떨어지지 않을까요? 그래서 오늘은 HTTP의 각 버전이 등장하게 된 배경과 버전 별 특징을 정리해보고자 합니다. 이번 글을 통해 HTTP의 각 버전에 대해 자세하게 알고 싶은 분 들게 도움이 되기를 바랍니다.

여러분이 자주 방문하는 웹사이트에 접속하여 개발자 도구를 한 번 켜서 HTML 요소 검사기에서 하이퍼링크(<a>, 앵커 태그)들을 한 번 살펴보시기 바랍니다. 아마 전부는 아니지만, 일부 하이퍼링크에는 rel이라는 속성의 값으로 noopener, noreferrer 또는 nofollow가 들어있을 겁니다. 이러한 속성은 왜 들어있으며 어떤 역할을 하는 걸까요? 오늘은 그 이유에 대해 간단히 알아보고자 합니다.

자바스크립트(JavaScript)는 ECMAScript를 준수하는 언어이기 때문에, 이번 발표는 JavaScript 사양의 변경으로도 해석할 수 있습니다. 사실 표준이 되기 전에도 이미 대부분의 브라우저가 이를 지원하고 있었기에 여러분도 이미 해당 제안(Proposal)을 써봤을 수도 있습니다. 저처럼 JavaScript를 주력 언어로 쓰시는 분들께는 이러한 ECMAScript의 발표가 굉장히 흥미로운(?) 이벤트인데요, 그래서 오늘은 ECMAScript 2022를 기점으로 새롭게 표준이 된 제안을 정리해보고자 합니다.