FEConf 접근성 발표 자료를 퇴고하면서 아쉽게 삭제한 몇 내용을 하나로 재구성하여 A11YKR 블로그에 게시했습니다.

디지털 접근성 포용하기 - A11YKR

웹 접근성을 고려한 콘텐츠 제작기법 2.2 개정판 W3C 저작 웹 콘텐츠 접근성 지침(WCAG)에 대한 국내 사례집이라 생각하시면 됩니다.

디지털 접근성의 4가지 원칙인 인지 · 조작 · 이해 · 견고 마다 실용적인 예제가 실려져 있습니다. FE 하시는 분이라면 꼭 읽어보세요.

부연설명을 하자면. Git에선 브랜치 자체로는 '변경 사항'이라는 의미가 없습니다. 왜냐면 끝점만 있고 시작점만 있으니까요. 변경 사항을 논하려면 비교 대상인 커밋이 필요합니다.

Rebase를 하는 이유는 연속된 커밋들로(예쁩니다) '변경 사항'을 나타내기 위해서입니다. 그 의도한 '변경 사항'을 만들기 위해, 비교 대상이 될 커밋을 바꾸는게 리베이스입니다. 그러니까 개발자가 의도한 diff를 그대로 표현하지 못해서, diff = head - x니까 이 방정식을 만족시키는 x 커밋을 찾아서 diff를 의도한데로 계산되게 만드는거지요.

참 뻘스럽습니다.

FEConf 접근성 발표 슬라이드 뷰 수가 천회가 넘었네요. 이렇게 무수한 관심은 기술 자료 만들면서 처음입니다.

적어도 먼저 졸업 하신 선배 중심의 네트워크가 있다는 게 다행이라고 생각한다.

우연히 학교 선배님 몇 분을 링크드인이나 오프라인 행사를 통해 만나보았는데, 그런 인연으로 도움에 필요할 때다마 연락드리면 응해주시는 편이다.

졸업 이전부터 일찍 깜지 내가 원하는 바를 주도하고 있다는 만족감은 있는데, 학교 간판 없이 하는 교외 경험 중심이라 소속감을 별로 느껴 본적이 없어 평소 많이 아쉽다고 느낀다. 🥹

Level Of Detail (LOD) 라는 렌더링 최적화 기법으로 실제로 렌더링 하는 범위를 넘어선 지역을 추상화하여 렌더 거리를 가상으로 늘리는 모드입니다.

Minecraft Distance Horizon 모드 최고네...

@resistanHyunjin Cho Fluid Layout 중에 Font Size, Padding 에 대한 국내 사례로 @disjukrㄹ 님이 SASS 환경 위에서 고안한 쪼그라드는 웹페이지 방법론이 있습니다.

이력서 업데이트로 외부 발표 이력을 추가했습니다. 2019년부터 자료가 꽤 있어서, 가장 최근 3가지를 추려 요약하고 추가 자료는 외부를 참고해달라고 적었습니다. 지난 자료에 많은 관심 부탁드립니다.

Smart layouts at CSS Day 2025 aka. Fluid Layout - 폴더블의 보편화로 스크린 화면 비율이 정적이지 않고 가변적이게 변하는 추세에 적합한 방법론인 것 같다.

뷰포트 너비마다 레이아웃을 변하는 breakpoint 방식에서 벗어나 단일한 Fluid Layout 을 지향하는 시점이 되었나 싶다.

CSSWG Draft Issues에서 다루는 목록 보니 서드파티 폼 컨트롤을 만들기 위한 수고가 많이 줄어들겠다고 기대가 된다.

현재 열린 문제 70개, 해결되거나 닫힌 문제 34개

https://youtu.be/WgSiqSqxTxw?t=1437 오 writing-mode: vertical-lr (왼쪽에서-오른쪽 세로쓰기) 레이아웃에서 텍스트 입력, 선택 입력 등 Form Control Element 도 세로로 배치되어 보여주네

cc @hongminhee洪 民憙 (Hong Minhee) 마음에 들어하실 기능일 것 같아 참조 겁니다!

폼 컨트롤 스타일링 발표 녹화 영상의 맨 하단 댓글의 닉네임이 @danil-old-web 인데, 컨셉이 제대로다...

드림위버 MX/8 진짜 오랜만에 듣는다.

남은 방학 기간에 뭘 할까나 싶다가 올해 CSS Day 공개 셰션 먼저 보고, 99달러라 비싸서 괜찮다 싶으면 학습 비용 지원으로 모든 세션 봐야겠다... https://cssday.nl/2025-recordings.html

10~7년 전에 마인크래프트 모딩으로 만난 그룹이 이제 같은 업계에서 일하고 있고, 오랜만에 만나서 나누는 이야기:

??: 어이 거기 이직한 곳은 평안하시나요?

내 주변 사람 타임라인 연령대가 올라갔다고 느꼈다.

사용자의 인지 흐름을 다시 돌아본 경험이었어요. 직접 스크린리더를 켜고 눈을 감고 탐색해보며 “내가 과연 이 흐름을 이해할 수 있을까?” 를 계속 되묻는 시간이었죠.

접근성은 특정 상황에 놓인 사용자만을 위한 기능이 아니었어요. 오히려 모든 사용자에게 더 명확하고, 더 친절한 흐름을 설계하는 일이라는 걸 깊이 느낄 수 있었어요.

https://toss.tech/article/38743 토스 챗봇의 스크린리더 지원 과정이 적흰 글입니다.

이번 FEConf 연사로 "모두를 위한 웹 접근성은 무엇이고, 어떻게 하나요? 💬 🔉" 웹 접근성의 가치와 실천 방법론에 대해 말했습니다.

제가 있는 A11YKR 커뮤니티의 자문으로 주어진 2개월 동안 알찬 자료를 만들어낼 수 있어 정말 감사했습니다. cc @resistanHyunjin Cho @stelo_kim김태희

지난 참석한 파이콘 연도 2016, 2017, 2018, 2019, 2023, 2025 (올해)

돌이켜보니 두번만 오프라인 행사에 미참했다.

파이콘 1일차 참가. 이제 9년이나 된 2016년 APAC 노랑 파랑 팔찌 굿즈 차고 제주공항에서 넘어 와 당일에 참석했습니다.

들으려 온 발표 시간 외에는, 지인이 운영하는 페디버스 부스에 머물러서 오는 분 마다 연합우주를 간단히 소개했습니다.

다양한 WAI-ARIA 표준이 여러 스크린리더와 브라우저 조합 환경과 잘 맞물리는지 테스트 결과를 확인하는 웹 페이지. 아직 작업 중이라네요. https://a11ysupport.io/

어제 "이 정도면 괜찮겠지…." 라는 착각을 하고 정반대의 반응을 마주해서
마치 마인크래프트의 실패한 천국 포탈을 만든 기분을 느꼈다 ㅋㅋ….

3년 전에 @disjukrㄹ 님에게 받아 묵혀두었던 misaka.moe 도메인 어디 쓸만한데 없을까 계속 미루만 있다가 임시로 제 레포지토리에 리다이렉션 걸었습니다. 예) https://misaka.moe/.dotfiles

제가 추천하는 라프텔 온리 애니메이션 『내가 사랑했던 모든 너에게』, 또 다른 편으로 『너를 사랑했던 한 사람의 나에게』가 있는데요, 보는 순서에 따라 이야기의 관점이 "이루어지는 로맨스"이냐, "이뤄지지 않은 로맨스"로 끝나는 차이가 있습니다.

저는 먼저 언급한 "내가 사랑했던 모든 너에게"를 이제 막 다 시청했는데, 다음 편을 보아도 이 편의 이야기가 여전히 더 여운에 남을 것 같네요.

무손실 음원을 그대로 들어보고 싶던 와중에 얼마 전에 마침 젠하이저에서 7세대 동글을 새로 출시해서 하루 사용해보았다.

MacBook에 끼워 Apple Music 청취를 해보았는데 내 귀로는 aptX™ Adaptive연결이 기존 AAC 코덱과 품질 차이를 아직 잘 모르겠다...

"모든 사람을 위한 웹 접근성 지원과 설계, 제대로 알아봅시다."

아래 명제에 대한 제 생각이 궁금하시면 꼭 이번 FEConf 2025에서 보러 와주세요!

• 웹 접근성은 장애 사용자만을 위한 특수한 사용자 경험을 지칭하는 기술 분야이다.
• 따라서 접근성은 보조 기술 지원을 위한 추가 사용자 인터페이스로, 웹 서비스의 구현 양이 그만큼 더 늘어날 것이다.

@chalk 오랜만이라 더 반갑습니다~ 초크님

https://maximizemaxwell.com/stm 동시성, 공유 메모리 할당 이거 학부 운영체제 이야기인데?

어떤 애플리케이션 개발이라도 모두가 참여하는 기획 단계에서 무슨 정보를 다룰지 가장 먼저 논의가 필요로 합니다.

저는 이 단계에서 정보 접근성에 대한 팀의 태도가 반영된다고 생각합니다.

여러분은 접근성과 UI 개발의 관계가 별개가 아니라는설명에 바로 동의하실 수 있나요? 평소 별로 관심이 없었다면 뜬구름 잡는 질문처럼 들릴 것입니다.

아무튼 FE 프로그래머라면 한번 읽어보시는 걸 권해드립니다.

@hongminhee洪 民憙 (Hong Minhee)

1. 파도처럼 출렁이는 연합우주의 분산 네트워크를 통해
2. 이제는 파이콘 한국 2025 행사에서 다 같이 처음 만나
3. 콘서트보다 더 뜨거운 분위기를 기대하겠습니다!

Javascript/Typescript 생태계에는 소스코드 간 의존관계를 유향그래프(Direct Graph)로 시각화하는 CLI 도구가 있다는 사실... 알고 계신가요? madge, 적극적으로 추천합니다.

그냥 JS/TS 프로젝트 뿐만이 아니라, jsx 파일이 들어간 경우도 의존관계를 아름답게 시각화해줍니다. fedify 소스코드 통독하면서 이걸 적극적으로 써볼까 합니다. 마치.... 탐정이 사건 추적하면서 지도에 X 표시하는 감성으로...

대학교 4학년, 마지막 방학에 스팀 여름 할인으로 《마법사의 밤》 구매해서 며칠 동안 계속 읽고 있는 중.

오타쿠 같은 감상인데 첫 번째 배틀 연출에서 정말 훌륭한 레이어 전환 같은 애니메이션이 재생되어 나와 감탄스러웠다. 이게 2010년대 초에 처음 개발되었다고요…?

하느님 추운 겨울이 되기 전에 제가 희망하는 도메인의 FE 자리를 PULL 주세요.

새로 읽으시는 분은 https://www.frontend.moe/resume/ 이쪽 이력서를 확인 부탁드립니다.

본문 내 아웃링크로 걸어둔 경력기술서 겸 포트폴리오 정보량이 너무 많다는 의견을 자주 받아서, 약식화한 RESUME 페이지를 새로 만들었습니다.

헛소리 - 평소 자주 지나드는 제주공항이나 김포공항 역에 누가 학부 졸업 축하 광고 내주면 어떨까 생각함.

"제주대 컴공 학부 졸업 및 다시 재외재주도민이 되어 하는 직장생활에 걸 건승 드립니다."

@bglbgl gwyng 7월 2일에 만나고자 하셨는데 장소 협의에 대한 메일 회신이 없으셔서 멘션 남깁니다~

내일(7월 1일) 개인 용무로 잠시 제주를 벗어나 서울에 이틀간 머물 예정인데요, 이날 5시 이후부터 여유 시간이 많아 만나서 이야기 나눌 분을 찾습니다.

자기소개 - 블로그 소개 및 Gravatar 프로필 참고

• 10여 년 전부터 웹 프로그래밍을 생산성과 취미로 즐겨하고 있는 컴퓨터 전공 4학년 학부생입니다.
• 이번 1학기에 졸업 요건을 대부분 만족하여 프런트엔드 개발 직군으로 구직 활동을 시작했습니다.

토스페이먼츠 결제 시스템 연동을 돕는 MCP 서버 구현기

토스페이먼츠 문서를 로컬 MCP로 제공하고자 거친 모든 의사 결정 과정이 공유되어 있습니다.

문서 내 키워드 관련성 분석을 미리 거친 Machine-Readable 한 청크 저장소를 구축하는 노력이 가장 흥미로웠네요.

오픈소스 프로젝트에 여러분의 gemini cli(등등)의 무료 사용량을 기여하세요

오픈소스 소프트웨어라는 소프트웨어 개발 방법은 그동안 대성공을 거두어 오고 있습니다. 여기에는 여러 요인이 있지만, 중요한 요인 중 하나는 이것입니다. 상업 소프트웨어든 오픈소스 소프트웨어든 공평하게 프로그래머의 시간을 들인 만큼 개발된다는 것이지요. 능력 있는 소프트웨어 개발자가 시간을 기여하면 오픈소스 소프트웨어는 상업 소프트웨어만큼이나 빠르게 성장할 수 있었습니다.

하지만 AI 프로그래밍의 시대가 빠르게 다가오고 있습니다. 앞으로 소프트웨어 개발은 프로그래머의 시간만으로 개발되지 않습니다. 상업소프트웨어는 AI 프로그래밍을 적극적으로 사용하여 이전과 다른 생산성으로 개발되기 시작할 것입니다. 상업 소프트웨어와 달리 오픈소스 소프트웨어는 언제나 그럴 수는 없습니다. 프로젝트의 성장과 유지를 위해 훌륭한 프로그래머들의 시간을 들이는 것을 넘어서, 훌륭한 프로그래머들이 시간에 더해 비용까지 들여야 한다면요.

상업 소프트웨어와 오픈소스 소프트웨어 사이의 불균등한 생산성의 시대가 코앞까지 다가오고 있습니다.

새로운 기여자 확보의 문제

문제는 여기서 그치지 않습니다. 오픈소스 프로젝트는 새 기여자를 얻기 더 힘들어져가고 있습니다. 왜냐하면 이제 'good first issue'라는 것은 의미가 없기 때문입니다. 그 정도로 쉬운 일은 새로운 기여자 대신 로봇이 해결할 가능성이 높고, 그 로봇은 새로운 기여자의 로봇일 수도 있습니다. 결국 AI 프로그래밍으로 기여하는 새 기여자는 이 프로젝트에 대해 거의 배우지 못하게 됩니다.

전통적인 오픈소스 생태계에서 'good first issue'는 단순히 쉬운 문제를 해결하는 것이 아니었습니다. 새로운 기여자가 프로젝트의 코드베이스를 이해하고, 개발 프로세스를 익히며, 커뮤니티와 소통하는 법을 배우는 학습 과정이었습니다. 하지만 AI가 이런 단순한 작업들을 대신 처리하게 되면, 새로운 기여자들은 진입 기회를 잃게 됩니다.

AI 프로그래밍의 현재 위치

AI 프로그래밍은 완벽하지 않습니다. 숙련된 전문가가 숙련된 도메인에서 작업하는 것만큼 잘하지는 못합니다. 하지만 비숙련된 프로그래머가 처음 보는 프로젝트에서 작업하는 것보다는 잘할 때가 많습니다.

그러나 많은 오픈소스 소프트웨어는 바로 이런 비숙련 기여가 성장의 한 축을 차지합니다. 처음 프로젝트에 참여하는 개발자들의 작은 기여들이 모여 거대한 프로젝트가 됩니다. 그리고 이런 비숙련 기여의 일부는 손쉽게 AI가 대체할 수 있는 기여입니다.

다행히도 지금은 AI 프로그래밍의 초창기입니다. Gemini CLI가 무료 사용량을 제공하듯이, 앞으로 여러 회사들이 비슷한 기회를 제공할 것입니다. Claude, ChatGPT, Copilot 등 다양한 AI 도구들이 개인 사용자에게 무료 크레딧을 제공하고 있습니다.

이것은 오픈소스 프로젝트에 기여할 새로운 기회로 삼을 수 있을까요?

주의: 이 글은 아무 프로젝트에나 방문해서 AI로 적당한 코드를 생성한 다음 패치를 보내라는 뜻이 아닙니다.

AI 프로그래밍은 (아직은) 마법이 아닙니다. "이 프로젝트를 겁나 멋지게 만들 기능을 추가해주세요"라고 한다고 해서 그런 패치가 나오는 식으로는 동작하지 않습니다.

이상적인 경우: AI 친화적 프로젝트

가장 좋은 방법은 프로젝트가 AI 친화적으로 준비되는 것입니다. 바로 작업할 수 있을 만큼 잘 정의된 이슈들이 있는 프로젝트라면, "nnn 번 이슈에 대해 작업해 주세요"라는 요청만으로도 누구나 기여할 수 있을 것입니다.

하지만 (적어도 아직은) 그런 프로젝트가 많지는 않을 것입니다.

현실적인 접근: AI가 잘하는 일들에 집중

대신 AI는 인간과 비대칭적으로 잘하는 기능이 있습니다.

이를테면 이슈에 minimal reproducible case가 보고되어 있지만 아직 구체적으로 발생하는 원인이 밝혀져 있지 않은 경우를 생각해봅시다. 버그를 고치는 사람이 해야하는 지루한 작업 가운데 하나는, 이 문제를 어떻게 수정할지를 생각하기에 앞서 이 문제가 어디서 발생하는지 찾는 것입니다. 디버거를 써야 할 수도 있고, 코드에 많은 trace log를 남겨야 할 수도 있습니다.

하지만 AI 코딩 에이전트는 테스트가 재현 가능하기만 하다면, 문제를 발생시키는 정확한 줄을 찾아내는 데 탁월합니다. 지치지 않고 정석적인 지루한 방법으로 꾸준히 로그를 추가하고 테스트를 다시 실행하면서 문제를 찾아내거든요.

어쩌면 문제의 원인이 아주 단순해서, 문제를 바로 수정할 수 있을지도 모릅니다! 그렇다면 패치를 제출해도 좋겠지요. 하지만 바로 수정하기까지는 어렵더라도 괜찮습니다. 버그 리포트와 실제 코드의 문제를 매핑하는 것은 그 자체로 지루하고 시간이 걸리는 일입니다. 이것을 대신하는 것으로도 큰 작업을 대신하는 것입니다.

주의: 모든 프로젝트가 AI 기여를 환영할 리는 없습니다. 충분히 유용하게 다듬어지지 못한 유형의 AI 기여는 스팸처럼 느껴질 가능성이 있음을 유의해야 합니다.

미래

사실 누구나 자기 라이브러리를 뚝딱 만들어낼 수 있게 되었다는 점에서 오픈소스 프로젝트에 참여하는 사람들의 동기와 기여 방식 자체가 크게 뒤바뀔 가능성이 높습니다.

AI 프로그래밍을 누구나 거의 무료로 사용할 수 있는 시대가 올까요? 아마 어느 정도의 사용량까지는 그럴 것입니다. 그것이 얼마나 많은 양일지에 따라서 오픈소스 프로젝트의 미래는 크게 바뀌겠지요.

만일 정말로 AI 프로그래밍을 누구나 무제한적으로 사용할 수 있다면, 대규모가 아닌 대부분의 오픈소스 프로젝트에는 더이상 협력이 필요하지 않을 것입니다. 진정으로 '어떻게'보다 '무엇을'이 더 중요한 시대가 온다면, 프로젝트의 목표를 확고하게 가진 사람이 극한의 완성도까지 프로젝트를 밀어붙이는 편이 훨씬 좋은 결과를 만들겠지요.

그런 시대가 올지 오지 않을지 모르겠습니다. 하지만 그 전까지는, AI 프로그래밍이 누구에게나 주어지는 기회이지만 프로젝트를 단숨에 완성할만큼 주어지지는 않는 시대가 유지되는 동안에는, 다음 세대의 오픈소스 기여의 방법은 AI 프로그래밍 사용량을 기여하는 것이 하나의 큰 축이 될 것입니다.

"해외 참가자"의 경우, 지원 가능한 최대 금액은 $200 입니다. https://2025.pycon.kr/fa

• 바다 건너 비행기로 가야 하는 지역인가 ⭕️
• 항공편 이용료가 유동적인 싯가인가 ⭕️
• 사용하는 언어가 다른가 ⭕️

= 해외

오호라

• 8월 16일-17일 파이콘 일반 참가
• 8월 23일 FEConf 발표 참가

휴가철이라 제주 ↔️ 김포 항공료 너부 부담되는데;;

Anthropic 팀들은 어떻게 Claude Code를 사용하는가?

@lqezPark Hyunwoo @robin_makirobin 오 이전에 소개드린 지인이였는데 드디어 만나셨군요.

@hongminhee洪 民憙 (Hong Minhee) 제 블로그에서 인용한 W3C CSS3 명세 내용에 따르면 범용성이 높은 클래스를 남용하기보다, 마크업의 구조를 따라 작성하라고 권장하고 있습니다. 꽤나 오래된 권장 사항으로 블로그 글의 레퍼런스를 조사하면서 저 명세를 CSS2 명세(2004년)로부터 알게 되었습니다.

data 어트리뷰트를 WAI-ARIA로 치환해서 같은 결과를 내놓을 수 있는데요, 이 방법의 장점은 좀 더 마크업 및 CSS Rules 작성에 대해 웹 표준을 근거로 명확한 디자인시스템을 만들 수 있다고 생각합니다.

 - my-card:state(loading) { 
+ my-card[aria-busy="true"] {
  background: url(./spinner.svg)
} 

- my-card:state(loaded) {
+ my-card[aria-busy="false"] {
  border: 2px solid green;
}

https://sorto.me/posts/2021-02-18--alt #a11y

https://tech.kakaopay.com/post/home-hexagonal-architecture/ 이야 이런 글 귀하다.

아 정확히는 SvelteKit...

https://issue.daum.net/election/2025 이번 대선 통해 처음 알았는데 다음 뉴스 포털 전체에서 Svelte 쓰나 보네...

이북으로도 정발 https://ridibooks.com/books/4403013496

이전부터 쭉 관리하고 있는 경력기술서 겸 포트폴리오 정보량이 너무 많다는 의견을 자주 받아서,
약식화한 별개의 RESUME 페이지를 새로 만들었다. https://www.frontend.moe/resume/