2024 01. 아티클 읽기

1월 11일: 웹 접근성 준수를 통한 모두에게 배달되는 일상의 행복

원문 보기

퍼블리셔로 일했을 때는 정적인 사용자 페이지 위주라서 웹 접근성 준수에 큰 어려움이 없었고, 몇몇 프로젝트에서는 웹 접근성 인증을 받았다. 그러나 현재는 백오피스를 맡고 있다 보니 웹 접근성에 대한 인식이 떨어진 것 같다.. 사내 운영진에는 장애인이 없다는 확고한 편견이 있었던 게 아닐까? 나 같은 개발자들이 장애인 분들의 직업 폭을 좁히는데 기여하고 있는 게 아닐까라는 생각이 들어 부끄러움을 느꼈다.

 

이전에 웹 접근성을 위해 대체 텍스트, 올바른 태그, 태그의 순서, 탭 인덱스 정도만 신경 썼었고, WAI-ARIA는 크게 활용하지 않았다. 아티클을 읽고 다시 생각해 보니 "웹 접근성을 잘 지키고 있었다"라는 말도 못 할 것 같다..

아티클 예기로 넘어가면, Landmark role 중에서 HTML로 구분하기 힘든 banner, search를 가장 유용하게 사용할 것 같다.

예시로 나온 컨펌창과 금액 충전 같은 일상적인 UI도 보조기기를 통해 사용하려면 얼마나 어려울지 상상조차 가지 않는다. 장애인, 비장애인 모두 사용하기 편한 UI와 보조기기를 통해 사용하는 경우에도 불편함을 없애는 고민을 하는 게 프론트엔드 개발자의 숙명이 아닐까 생각했다.

 

가장 기본적이지만 가장 중요한 웹 접근성 준수에 관해 좋을 자극을 얻었다. 하루아침에 이루어질 수 없는 것이기 때문에 평소 개발할 때 신경 쓰면서 하는 습관을 길러야겠다. 진행 중인 토이 프로젝트부터 당장 적용해야지!

 

1월 13일: [번역] 그것을 위해 자바스크립트를 사용할 필요는 없습니다

원문 보기

CSS :has()를 알게 되었을 때, 더 이상 style을 위한 script를 작성하지 않아도 된다는 것에 큰 기쁨을 느꼈었다.
이번 아티클을 통해 새롭게 알게 된 유용한 HTML tag와 CSS 속성이 있었다.

 

마우스로 상호작용 할 때 focus 스타일이 적용되는 게 가끔 거슬렸었는데, :focus-visible을 사용해서 고민을 해결이 해결될 것 같다. deatil/summary는 아코디언을 구성할 수 있는 편리한 방법이지만, 스타일과 기능 커스텀이 얼마나 쉬운지에 따라 사용 여부가 결정될 것 같다.

모르는 태그와 속성이 아직도 많다니! 시간 날 때 MDN 좀 읽어야겠다.. 일단 MDN 뉴스레터 구독 완💌

가장 적은 힘의 원칙(Rule of Least Power)
웹 개발의 핵심 원칙 중 하나로, 주어진 목적에 가장 적합한 가장 낮은 수준의 언어를 선택해야 한다는 의미

 

1월 14일: 나쁜 자바스크립트 작성 습관과 작별하기

원문 보기

알면서도 못 고치는 나쁜 습관들.. 특히! 매개변수에 객체를 할당하는 걸 버릴 수가 없다..

조금의 변명을 해보자면 협업을 하는 프로젝트니까 통일성을 위해 객체를 버릴 수 없다..! 그리고 처음부터 객체를 할당해서 사용하다 보니 습관이 된 것 같다 ㅜ 그래도 고쳐야지.. 팀원들을 설득할 수 없다면 개인 프로젝트에서라도 실천해야겠다.

 

if (!!x) {}

이전에 빈 값을 확인하기 위해 아티클에 나온 예시처럼 길게 썼다가 undefined를 누락했던 적이 있었는데, 앞으로 이 약어를 쓰면 실수하는 일이 없을 것 같다.👍

 

1월 16일: 모지또 글로벌 지점 내기

원문 보기

프로젝트를 리뉴얼하고 구성하는걸 기획자 입장에서 볼 수 있었고, 문구 번역 이슈 등 실제로 겪지 않으면 알지 못하는 부분도 간접적으로 경험할 수 있어 좋았다.

같은 기능이지만 UI 구성, 위치에 따라서 사용성이 좋아진 것도 눈에 보였다. 기획은 아무나 하는 게 아니구나.. UI/UX 재밌고 멋있으면서도 어려운 길..

해외 출시를 위해 어플을 갈아엎는다는 게 쉬운 결정은 아니었을 텐데 그걸 지지해 주고 따라준 팀원들이 있다는 것도 부러웠다.

나도 언젠가 사이드 프로젝트로 제품을 만들고 출시, 운영하는 날이 올까?

 

1월 18일: REST API 제대로 알고 사용하기

원문 보기

REST API! 밥 먹듯 사용하지만, 무엇인지 설명하지 못한다.. 이제야 REST API가 무엇인지 알게 된 것도 많이 부끄럽다.

이제 REST API가 뭔지 알게 되었다! 하지만 한 문장으로 설명하라고 하면 아직 좀 어려운 것 같다. 설명하지 못하면 아는 게 아니라는 마음으로 반복학습을 해야겠다..!

REST(Representational State Transfer) API
REST API는 자원(Resource)을 고유한 URI로 식별하고, HTTP 메서드를 사용하여 해당 자원의 상태를 표현하며, 표준 데이터 형식(JSON 또는 XML)을 통해 클라이언트와 서버 간 통신하는 웹 서비스 아키텍처 스타일이다.

 

1월 22일: 송금할 때 은행 이름을 꼭 입력해야 할까요?

원문 보기

내가 토스를 좋아하는 이유. 나에게 토스란 UX를 선도하는 기업이다.

실제로 토스를 사용하고 있는데 최근 송금 UI가 변경된 걸 보고 큰 충격을 받았었다.

은행마다 정해진 계좌번호 규약이 있을텐데, 계좌번호로 은행을 역추론할 생각을 왜 이제껏 못했을까? 

상식이라고 생각하던게 상식이 아니었다니..! 아티클을 읽으면서 같이 뒤통수를 맞은 기분이었다. 역시 토스👍

 

1월 24일: Cors 에러

원문 보기

CORS.. 들어만 봤지 찾아보기는 이번이 처음이다. CORS 에러를 한 번도 겪어보지 않았다는 것 자체가 내가 하는 일의 깊이를 보여주는 것같아 오늘도 역시 부끄러움을 느낀다..

미들웨어나 백엔드 연결를 연결하는 부분은 나중에 공부해야지 하고 미뤄둔 부분이 있었는데, 그것부터 먼저 봐야겠다.

다음 공부는 무조건 HTTP를 공부하는걸로!

 

1월 25일: 업무 효율을 높이는 메모, 기록 방법은?

원문 보기

나는 메모를 많이 하긴 하지만 정리를 못하는 편인 것 같다. 많은 앱(메모 앱, 노션(계정 2개), 다이어리, 최근엔 옵시디언까지!)을 사용 중이고, 당연히 두서없이 정리되어 있다.

파편화된 메모들을 모아 옵시디언으로 정착할 계획인데 어떻게 분류를 해야 할지 막막했는데 이 아티클에서 답을 찾았다.

바로 PARA! 분류 기준이 명확해 부담스럽지 않고, 카테고리에 스트레스 받지 않아도 돼서 좋은 것 같다. 메모의 양이 많아도 옵시디언을 쓰니까 검색에도 문제가 없을 것 같다. 당장 이번 주말부터 메모 정리를 시작해야겠다.

 

1월 26일: 그 많은 개발 문서는 누가 다 만들었을까

원문 보기 (1) 토스페이먼츠 테키니컬 라이터가 하는 일

원문 보기 (2) 개발자의 학습을 돕는 모든 것

이전에는 테크니컬 라이터 직업에 대해 단순히 기술 관련 문서를 작성하거나, 개발자들의 글을 첨삭/작성하는 직업이라고만 생각했다.

그러나 이번 아티클을 통해 테크니컬 라이터가 어떤 직업인지, 그리고 얼마나 중요한 역할을 하는지 깨달았다. 테크니컬 라이터가 하는 일은 단순히 글쓰기만이 아니라, 개발과 관련된 다양한 영역에 영향력을 끼치고 있었다!

 

특히 토스페이먼츠의 튜토리얼의 스크롤 연동부분과 API 리뷰에 참여하는 과정에서 그 영향력을 명확히 느낄 수 있었다. 멀리서 큰 그림을 바라보며 개발자의 시야를 넓혀주는 멋진 일이라고 생각했다.

요즘에는 UX만큼이나 중요한 개발 경험(DX)을 위해 테크니컬 라이터가 꼭 필요한 직업이라고 생각한다. 이런 멋있고 다양한 직업들이 생기고 같이 협업을 할 수 있다면 정말 좋은 경험일 것같다🙏