도리

FE Conf 2025 후기

도리[Dori] — Sun, 24 Aug 2025 18:23:30 +0900

FE CONF 2025

일시:8월 23일 (토)
장소: 세종대학교 광개토관 B2
홈페이지: https://2025.feconf.kr/
트위터: https://x.com/feconf

FE Conf 2025에 다녀왔다.

NHN Forward 2022 이후 3년 만에 참가한 오프라인 개발자 컨퍼런스였다.

특히 프론트엔드 개발자위주의 행사라는 점, 유튜브로 꾸준히 챙겨보던 행사라는 점 때문에 더 기대가 됐다.

결론부터 말하면 매우 즐거웠고 개발에 열정 가득한 많은 사람을 만나는 게 건강한 자극이 되었다.

메인 프로그램

B홀 광경 (시작 전 광고)

메인 프로그램은 A, B 홀에서 병렬로 진행되었다. A는 모바일 관련 내용이 많아 보여서 나는 주로 B 홀에서 발표를 시청했다.

세부 내용은 유튜브에 공개될 예정이라, 여기서는 기억에 남은 발표만 간단히 정리했다.

스벨트를 통해 리액트 이해하기

`다른 프레임워크를 통해 리액트를 더 깊이 이해할 수 있다`

스벨트의 장점을 소개하고 리액트에도 적용시키는 예시들을 보여주었다.

발표 구성이 매끄럽고 실무 적용까지 고민해볼 만한 주제라 인상 깊었다.

메모를 지울 결심

간단히 리액트 컴파일러를 소개하는 발표일 거라 예상했지만 리액트 컴파일러의 작동 원리와 실제 캐싱의 차이까지 보여주었다.

새로운 기술적 측면을 알 수 있었고, 우리 코드에도 적용할 수 있게 된다면 캐시를 잘 쓰기 위해 어떤 고민을 해야 할지 배울 수 있었다.

라이트닝 토크

라이트닝 토크 일부

C 홀은 초반엔 골드 티켓을 위한 리더토크가 있었고 14:30부터 라이트닝 토크가 진행되었다.

나는 중간쯤부터 라이트닝 토크를 시청했고, 부스에도 왔다 갔다 하며 들었다.

라이트닝 토크는 메인 프로그램보다는 좀 더 가벼운 주제들과 짧은 발표들로 구성되어 있다.

덕분에 가볍게, 부담 없이 즐길 수 있었다.

기술적인 이야기 외에도 개발자와 개발 팀으로서 고민과 어떻게 해나가고 있는지에 대한 얘기들도 많았다.

팀 규모가 커지고 줄어드는 것에 대한 이야기
팀 빌딩과 팀이 성공하는 습관 만들기
AI 시대에 FE 개발자로 살아남기
오픈 소스에 기여하기
최신 CSS 동향
...

부스

오늘의 집, 강남언니, AWS, Moyo 네 곳의 부스가 C홀 입구 쪽에서 진행됐다.

각 부스별로 이벤트도 하는데 오픈 초반에 사람이 많았고 이후에는 사은품이 많이 소진되어 사람이 줄었던 것 같다.

부스별 커피챗도 진행해서 관심 기업이 있거나 다른 회사의 개발팀은 어떤 걸 하고 있는지 궁금하면 가서 편하게 얘기해 볼 수 있다.

당장 이직을 준비하고 있진 않지만, 어떤 개발 문화를 가진 팀들인지 궁금해 방문해 보았다.

자기 기술에 철학이 있는 사람
기능을 만드는 것뿐만 아니라 제품을 성장시키고, 안정적으로 운영할 수 있는 사람
좋은 제품을 만들기 위해 적극적으로 고민하고 눈치 보지 않고 의견을 낼 수 있는 사람

개발 역량은 당연하고 그 너머로 제품을 성장시킬 수 있는 개발자를 원하는 것 같았다.

앞으로는 그런 부분에 대해 더 고민하고 준비해야겠다고 생각했다.

네트워킹

당근 모임으로 네트워킹을 신청하여 다른 개발자분들과 네트워킹을 할 수 있었다.

우리는 4명이 모였고 약 30분 정도 대화했다.

내향형인 나에게 이런 자리가 어색하긴 하지만 요즘 다른 분들의 개발 이야기나 이직 고민에 대해 이야기 나눌 수 있어서 좋았다.

비슷한 연차의 개발자들이 있었다면 더 공감할 수 있었을 텐데, 그래도 충분히 유익했다.

애프터파티

토스 프라이빗 애프터파티

행사 끝나고 여운이 남았던 건지 저녁을 같이 먹으려는 사람들도 보이고 활기찼다.

나는 운 좋게도 토스 애프터파티에 당첨되어서 거기에 참여하게 되었다.

거기서 토스 개발자 분들과 스피커분들, 그리고 애프터파티 당첨자분들과 함께 즐거운 시간을 보냈다.

조별로 앉아 개발 문화 이야기, 업계 분위기 이야기 등등 다양한 이야기가 오갔다.

이후엔 맛있는 식사와 함께 토스의 FE 모닥불을 눈앞에서 볼 수 있었고, 조원들과도 랜덤주제 토론을 했다.

우리 조는 스타트업과 대기업, 매니저와 IC가 적절히 섞여있어서 양측의 관점을 모두 들을 수 있어서 정말 흥미로웠다.

파티 중에 토스에서는 이런 토론을 언제든지 할 수 있다 라고 하신 말이 기억에 남는다.

토스라는 회사에 대해 자부심과 함께, FE에 대한 관심과 열정이 높은 사람들이 모여 일하는 곳이라는 인상을 받았다.

경품이벤트 같은 걸로 배민 쿠폰도 받았다 ☺️

이런 자리를 마련하고 기획하고 초대해 주신 토스팀에 감사를!

멋있게 재밌게 일하는 회사들과 개발자들이 많은 것 같다.

다들 끊임없이 고민하고 소통하면서 "좋은 제품"을 만들기 위해 노력하고 있었다.

웹서비스를 개발하는 사람으로서 나에게도 굉장히 자극이 되고 에너지를 얻어가는 그런 행사였다.

이 날 얻은 에너지로 하반기도 열심히, 잘해야겠다. 내년에 또 가야지~

<프로그래머의 뇌> 정리

도리[Dori] — Sat, 16 Aug 2025 19:02:11 +0900

https://www.yes24.com/product/goods/105911017

프로그래머의 뇌 - 예스24

인지과학을 활용한 개발자의 일머리 개선법 이 책은 인지과학에 기반을 둔 각종 방법론으로 개발자가 새로운 언어나 프레임워크를 빠르게 배워 생산성을 향상하도록 돕는다. 코드를 더 잘 이해

www.yes24.com

프로그래머의 뇌 - 훌륭한 프로그래머가 알아야할 인지과학의 모든 것

크게 네 파트로 구성되어, 개발하면서 겪는 어려움을 인지 과학의 관점에서 분류한다.
이를 분석하여 어떻게 해야 코드를 잘 읽고 좋은 코드를 작성할지에 대해 설명한다.

공감되는 부분도 많고 머릿속으로만 느끼던 부분들에 대해 구체적으로 설명해주기 때문에 실무에서도 도움이 될 것 같다.

내가 짠 코드를 상대방에게 설명하거나, PR을 작성할 때
좋은 코드, 안좋은 코드 느낌은 있지만 설명을 잘 못하겠을 때
이해하기 쉬운 코드를 작성하기 위해 고민할 때

내가 이해한 흐름으로 큰 내용을 재구성하여 짧게 정리해보았다.

인지과학적 관점의 프로그래밍

인지과학에서 우리 뇌는 크게 세 부분으로 구분된다.

LTM(Long term memory) - 장기 기억 공간 (지식) - 하드 디스크
STM(Short term memory) - 단기 기억 공간 (정보) - 메모리
작업 기억 공간 - 지식과 정보를 통해 처리. 생각, 아이디어, 해결책 등이 만들어짐. - 프로세서

코드를 읽는 것은 LTM, STM, 작업 기억 공간의 복합적인 작용이다.
코드를 읽을 때 뇌는 LTM, STM에서 정보를 인출하여 작업 기억 공간에서 처리한다.

하지만, 작업 기억 공간에 들어갈 수 있는 정보의 개수는 한정되어있고, 굉장히 적다.
그럼 어떻게 해야 코딩처럼 많은 정보를 처리하는 일을 잘 할 수 있을까?

LTM 더 활용하기

먼저 "청크"를 활용하는 것이다.
정보의 개수가 한정되어있다고 했지만, 어떤 사람들은 굉장히 많은 정보를 처리한다.
이는 작업 기억 공간에 정보가 들어갈 때, 관련된 정보들이 청크 단위로 함께 들어가기 때문이다.

ex) 트리를 활용한 코드를 읽을 때
트리와 관련된 지식들이 청크로 작업 기억 공간에 들어감.
트리 관련 메서드, 프로퍼티 등은 이미 알고 있기 때문에 다른 부분을 더 파악할 여지가 큼
그런 지식이 없을 때는 트리 관련된 정보를 읽는 것부터 부하가 생김

청크를 잘 꺼내 쓰려면 "표식"이 중요하다.
표식은 이 코드가 어떤 지식과 연관되어 있는지를 나타내는 어떤 표지이다.
변수명이나 문자열, 또는 코드 구조가 될 수 있다.

ex) 트리 구조
root, left, right 등을 통해 tree 구조와 관련된 지식을 떠올릴 수 있다.

위의 내용처럼, 코드를 잘 읽으려면 LTM에 지식이 쌓여있는 것이 좋다.
반복/인출/정교화를 통해 LTM의 지식을 강화할 수 있다.

반복 - 반복을 통해 장기 기억으로 저장
인출 - 의도적으로 떠올리는 연습을 통해 인출력 강화 - LTM에서 잘 꺼낼 수 있어짐
정교화 - 기존 지식과의 연결을 통해 강화 - 청크 활용을 강화

작업 기억 공간 부하 줄이기

작업 기억 공간에 많은 정보가 들어가면 부하가 생겨 처리에 어려움을 겪는다.
이걸 "인지 부하"라고 한다.
높아진 인지부하를 감소시키는데엔 보조도구를 사용하는 것이 도움이 된다.

머릿속 실행 결과를 주석으로 달아두기
모델링하여 그래프로 그려보기
상태변화를 상태표로 나타내보기
어려운 코드를 읽기 쉽게 리팩토링 해보기 (임시라도)

코드에 적용하기

이 장에서는 앞서 배운 개념들을 토대로

코드를 더 잘 이해하기
코딩 문제를 잘 해결하기

에 대해 공부한다.

코드 이해

코드를 읽고 이해하는 것은 개발자가 가장 많이 하는 일이다.
역시 여기에도 LTM을 활용할 수 있다.

"변수의 역할"을 분류하여 어떤 변수가 어떻게 동작하는지에 대한 지식이 미리 있다면,
코드를 읽을 때 미리 관련 청크를 가져와 작업 처리 공간을 더 효율적으로 사용할 수 있다.

ex) Stepper 변수
i, j, k 등의 변수는 반복문 내의 stepper로 사용되므로, 반복문과 관련된 기억을 가져올 수 있다.

코드를 읽는 것은 또한 텍스트 읽는 것과 유사하다.
긴 글을 읽을 때 처럼 스캔을 한다면 미리 필요한 지식 청크들을 가져올 수 있기 때문에 이해에 도움이 된다.

문제 해결

복잡한 문제는 인지부하가 커진다.
그렇다면 LTM을 활용하고, 작업 기억 공간의 부하를 줄여 문제 해결에 도움을 줄 수 있다.

멘탈 모델을 통해 문제의 일부를 추상화하면 인지부하를 줄일 수 있다.

1) 추상화를 통해 복잡한 디테일은 숨긴다.
2) 추상화와 관련된 기억을 LTM에서 가져올 수 있다.

ex)
네트워크도 추상화 레이어가 없다면, 물리적으로 데이터를 전송하는 방법까지 생각해야한다.
하지만 그런 복잡한 디테일은 숨겨져 있으므로 더 쉽게 네트워크를 다루고 이해할 수 있다.

ex)
DP 문제를 자주 풀어본 사람은 문제를 읽고 DP의 풀이법을 떠올려서 쉽게 풀 수 있다.

어떤 문제를 해결하는것에 익숙해지면, 그 문제를 해결할 때에는 인지능력이 거의 사용되지 않는다.
이런 종류의 기억을 암시적 기억, 이걸 활용하는 것을 자동화 (automization)라고 한다.

암시적 기억이 많아지면, 복잡한 문제의 많은 디테일에 집중하지 않아 인지 부하가 줄어든다.
그러면 문제해결 자체에 집중할 수 있기 때문에 크고 복잡한 문제의 해결에도 도움이된다.

의도적인 반복 연습
다른 좋은 코드를 분석 및 학습

좋은 코드 작성하기

좋은 코드를 작성하기 위해서는 이름을 잘 지어야한다. 실제로 코드 베이스의 상당 부분이 "이름"에 해당한다.

좋은 이름 사용
- 이름을 통해 이미 알고 있는 정보를 LTM에서 가져옴
- 코드내에서 정보를 제공하는 "문서"의 역할을 할 수 있음
나쁜 이름 사용
- 코드에 대한 잘못된 추측, 오개념 생기게 함
- 이름에서 정보를 찾지 못하면 다른 곳에서 정보를 찾게되어 인지 부하 증가.
- 나쁜 이름과 버그는 상관관계가 있다.

좋은 이름이란?

이해하기 쉽도록, 너무 짧거나 길지 않은 이름
코드베이스 내의 규칙에 따라 일관성있게 지은 이름

코드베이스 내에서 일관성 있게 명명한 변수는 협업하는 사람들의 인지부하를 줄이는데에 도움이 된다.
다만, 코드베이스의 규칙을 바꾸는 것은 쉽지 않으니 초기에 잘 정해야한다.

언어적 안티패턴

코드가 실제 수행하는 작업과 맞지 않는 이름을 가질 때 "언어적 안티패턴"이라 칭한다.
이런 "나쁜 이름"은 LTM의 최적화와 오히려 반대로 작용하여 더 높은 인지부하를 줄 수 있다.

e.g. isValid라는 변수가 불리언 값 대신 정숫값을 가지면 기존 정보와 달라 헷갈릴 수 있다.

식별자가 그 이름보다 더 많거나, 적은 역할, 또는 반대의 역할을 하지 않도록 주의해야한다.

업무 중단에 대응하기

업무가 중단되면 작업 기억 공간이 작업 중이던 중요한 정보를 잃어버린다.
작업으로 되돌아가기 위해서는 의도적으로 노력하는 워밍업의 단계가 필요하다.

개발자 업무 시간의 약 20%가 업무 중단에 사용된다.
또한, 중단은 짜증, 불안, 실수의 정도도 높인다.
이런 업무 중단에 잘 대응할 수 있다면 더 효율적으로 일하여 생산성을 높일 수 있다.

대응

중단 시, 진행 상황에 대한 정신 모델을 작성해두기 (메모, 주석 등)
큰 task를 미리 subtask로 나누고 계획해두기
멀티 태스킹 피하기 (메신저, 음악 듣기 등)

책을 읽으며 중요하다고 느낀 부분들을 간단히 정리해보았다.
책에는 더 디테일한 부분들과 설명들, 그리고 관련 연구 자료와 근거들이 나와있다.
또한 이런 이론들을 연습해 볼 연습 방법들도 수록되어있다.
그러므로 관심이 생긴다면 한번 직접 읽어보는 것 추천한다.

[Github MCP] Github 작업은 AI에게 맡겨보자

도리[Dori] — Tue, 29 Apr 2025 21:35:58 +0900

개발하다보면 Git은 뗄레야 뗄 수 없다. 특히, Github에서 해야할 일이 굉장히 많다.

여러 Repository에 걸쳐서 다양한 PR과 코멘트를 상대하다보면, 어디까지 리뷰했고 어디를 하다 말았고 헷갈리는 경우도 종종 있다.

이런 파편화된 업무를 한마디면 척척 정리해주고, 나 대신 코멘트도 달아주는 친구(?)가 있으면 좋겠다는 생각을 하게된다.

마침 최근에 Github 공식 MCP 서버가 나왔고, 우리 Copilot에 활용이 가능했기 때문에 바로 적용해보았다.

https://github.com/github/github-mcp-server

GitHub - github/github-mcp-server: GitHub's official MCP Server

GitHub's official MCP Server. Contribute to github/github-mcp-server development by creating an account on GitHub.

github.com

아래 예시는 Copilot을 위주로 작성되었지만, Claude 등 다른 MCP 클라이언트와도 동작한다.

결과 미리보기

먼저 적용 결과를 보면 다음과 같다.

PR 대시보드

여러 Repo의 내가 연 PR의 상태, 내가 리뷰 요청받은 PR을 한 눈에 볼 수 있는 대시보드

MCP를 통해 조회한 PR 대시보드

대신 코드리뷰

내용은 가렸지만, 코드 라인에 이렇게 바로 리뷰댓글을 남기는 것도 가능하다.

라인별 코드 리뷰

연동하기

준비물

docker

서버가 docker로 실행된다.
docker가 아니어도 podman 처럼 docker같은 기능을 할 수 있으면 가능하다.

Github Access 토큰

깃헙 설정 > 개발자 설정에서 토큰 발급
사용자 인증 및 기능 사용에 필요

Github MCP 설치

설치는 원클릭으로 가능하다. github-mcp-server에서 아래 버튼을 클릭하고 따라가면 된다.

Install Server 버튼

잘 안되거나 수동을 선호한다면

1) Command Palette (cmd + shift + p) > Open Settings (JSON) 으로 이동
2) 아래 설정 추가 (<personal_token> = 위에서 발급한 토큰)

{
  ...
  "mcp": {
    "servers": {
      "github": {
        "command": "docker",
        "args": [
          "run",
          "-i",
          "--rm",
          "-e",
          "GITHUB_PERSONAL_ACCESS_TOKEN",
          "ghcr.io/github/github-mcp-server"
        ],
        "env": {
          "GITHUB_PERSONAL_ACCESS_TOKEN": "<personal_token>",
        }
      }
    }
  }
}

cf) Github Enterprise인 경우

mcp.servers.github.args에 추가: "-e", "GITHUB_HOST",
mcp.servers.github.env에 추가: "GITHUB_HOST": "https://<enterprise-domain>"

cf) docker 실행이 안되는 경우

docker 실행파일이 위치한 전체 경로를 넣어주면 된다.
podman 사용 시에도 마찬가지

3) 설치 확인

정상적으로 서버가 떴다면 Running이라는 표시가 뜬다.

server가 실행중인 경우

그렇지 않다면 VSCode를 재실행해보자.

Copilot Chat > Agent 모드로 변경해보면 Chat input 좌상단에 Github MCP 도구 36개가 활성화된 것을 볼 수 있다.

tools가 활성화된 경우

누르면 어떤 기능들이 가능한지 확인할 수 있다.

Repository 조회
PR 조회, 생성 등
브랜치 조회, 생성 등
코멘트/리뷰 달기

github mcp server tools

등 기능 목록은 Tools 섹션에 잘 나와있으니 참고

프롬프트 팁

조직 단위의 Repository에서 일하는 경우, 조직명을 줘야 잘 찾는다.
조직의 Repo에서 조회해야하는데 개인 Repo를 조회하는 경우가 있었다.

조회하고 싶은 Repository가 여러개인 경우, 필요한 Repository를 전달해주면 더 빠르다.
전달해주지 않으면 현재 작업중인 디렉토리의 PR만 찾는 경우가 있었다.

전달 받은 내용을 테이블 형식 등으로 출력 받으면 좋은 대시보드가 된다.
PR 번호에 PR 링크도 걸어달라고 하면 바로 필요한 PR을 열어볼 수 있다.
approve 여부 등도 조회할 수 있으니, 다양하게 활용해보면 좋을것이다.

개인적으론 오전에 전날 들어오거나 놓친 리뷰등을 파악할 때 굉장히 유용하게 사용하고 있다.

뚝뚝 끊기는 이미지 UX 개선 - Progressive 이미지

도리[Dori] — Sun, 27 Apr 2025 17:25:40 +0900

TL;DR

Progressive 이미지를 통해 느린 이미지 로드로 인해 저하된 사용자 경험을 개선할 수 있다.
JPG, PNG로 한번 만들어보기

이미지의 용량이 크거나 네트워크가 느릴 때, 이미지가 위에서 아래로 끊기듯이 로드되어 사용자 경험을 저해할 수 있다.
이 문제를 해결하기 위한 방법을 보다가 Progressive 방식을 알게 되었다.

인터넷을 사용하다보면 이미지를 로드하는 방식에 차이가 있다.

1) 앞서 말한 것처럼 이미지가 끊어지면서 로딩
2) 흐린 이미지가 점점 선명해지면서 로딩

후자가 바로 progressive 방식의 이미지이다.

장점

Progressive 방식의 이미지는 UX 상의 이점이 있다.

저사양 환경에서도 빠른 시각적 피드백
사용자가 로딩 중임을 인지하게 함으로써 이탈율 감소

단점

좋은 점만 있는 것은 아니다. UX 적으로는 분명 이점이 있지만, 몇가지 고려할 포인트가 있다.

오버헤드 증가 (파일 크기, 디코드 시간)
일부 브라우저 미지원 (Safari, IE8)

하지만 체감 성능 차이에 오버헤드가 주는 영향은 다른 요소들에 비해 미미하다고 한다.
특히, 주 고객층의 네트워크 환경이 느리거나 큰 이미지를 많이 사용하는 서비스의 경우 이미지 UX 최적화의 일환으로 사용할 수 있다.

만들어보기

준비물

큰 이미지 - 클수록 느린게 티나기 때문에 좋다.

진행 과정

원하는 경로로 이동
프로젝트 생성
sharp 설치

https://sharp.pixelplumbing.com/

High performance Node.js image processing

High performance Node.js image processing. The fastest module to resize JPEG, PNG, WebP and TIFF images.

sharp.pixelplumbing.com

nodejs의 이미지 처리 라이브러리
sharp를 통해 progressive 형식 이미지를 만들것이다.

npm install sharp

converter.js 작성

#!/usr/bin/env node  

const path = require("path");  
const sharp = require("sharp");  
const args = process.argv.slice(2);  
let input, output;

// arg 파싱  
for (let i = 0; i < args.length; i++) {  
  if ((args\[i\] === "-i" || args\[i\] === "--input") && args\[i + 1\]) {  
    input = args\[i + 1\];  
    i++;  
  } else if ((args\[i\] === "-o" || args\[i\] === "--output") && args\[i + 1\]) {  
    output = args\[i + 1\];  
    i++;  
  }  
}  

if (!input || !output) {  
  console.error("Usage: node converter.js -i input.jpg/png -o output.jpg/png");  
  process.exit(1);  
}  

// Determine output format by extension  
const ext = path.extname(output).toLowerCase();  
let pipeline = sharp(input);

// progressive로 output을 만든다.  
if (ext === ".jpg" || ext === ".jpeg") {  
  pipeline = pipeline.jpeg({ progressive: true });  
} else if (ext === ".png") {  
  pipeline = pipeline.png({ progressive: true }); // interlaced PNG  
} else {  
  console.error("Unsupported output format:", ext);  
  process.exit(1);  
}  

pipeline  
  .toFile(output)  
  .then(() => console.log(\`Converted and saved to ${output}\`))  
  .catch((err) => {  
    console.error("Error generating output image:", err);  
    process.exit(1);  
  });

index.html 생성

<!doctype html>  
<html lang="en">  
  <head>  
    <meta charset="UTF-8" />  
    <title>Progressive JPEG Test</title>  
  </head>  
  <body>  
    <h1>Progressive JPEG Test</h1>  
    <img src="http://localhost:8000/image.png" alt="Progressive JPEG example" />  
  </body>  
</html>

서버 생성 및 실행

const express = require("express");  
const app = express();  
app.use(express.static("."));  
app.listen(8000, () => console.log("http://localhost:8000"));

# 이미지 변환  
node converter.js -i input.jpg -o output.jpeg  
node converter.js -i input.png -o output.png

# 서버 실행  
node server.js

로컬호스트에 들어가보면 이미지를 확인할 수 있다.
네트워크 throttle을 걸어두고 느린환경에서 실행해보면, 두 방식의 차이를 확연히 알 수 있다.
확대해보면 더 잘 보이는데, 다음과 같이 점짐적으로 이미지가 차오르는 것을 볼 수 있다.

progressive 이미지 로딩

FE 개발하면서 직접 사용할 일은 많지 않아 보이지만, 알아두면 이미지 개선 요청 등에 대응하기 좋을 것이다.

Neovim에서 Copilot 사용하기

도리[Dori] — Fri, 28 Feb 2025 19:08:28 +0900

회사에서 Copilot 지원이 시작되었다. 바로 신청해서 사용해보았지만 너무 큰 문제가 있었다.
VSCode와 Neovim의 싱크가 깨지는 문제였다.

Vscode Neovim 익스텐션은 VScode 탭과 Neovim 인스턴스 사이에서 싱크를 맞춘다.
이 때, 코파일럿의 자동완성을 사용하면 간할적으로 Neovim의 싱크가 깨졌다.
키들이 동작하지 않았고 매번 익스텐션을 재시작 해야했다.

Sync가 깨져 발생하는 오류

아래 등록된 이슈로 확인할 수 있는데, 25.02.28 기준 아직 진행 중으로 확인된다.

Github 이슈 참고: https://github.com/vscode-neovim/vscode-neovim/issues/2184

bug: "Syncing layout: Syncing active editor" keeps running forever · Issue #2184 · vscode-neovim/vscode-neovim

Check the following: I have checked the behavior after setting "vscode-neovim.neovimClean" in VSCode settings. I have read the vscode-neovim docs. I have searched existing issues. Neovim version (n...

github.com

Copilot in Neovim

그래서, 다시 Neovim으로 돌아갈 생각은 없었지만 잠시 Copilot을 사용해보기위해 Neovim으로 돌아갔다.

다행히, 내가 사용하는 Lazyvim에서는 쉽게 Copilot과 Copilot-chat을 지원하고 있다.

:LazyExtras로 extra 플러그인 설치로 진입하여 Copilot과 Copilot-chat을 설치해주면 된다.

LazyExtras 플러그인 설치 화면

사용하는 플러그인은

lazyvim이 아니라도 위 깃헙을 참고하면 쉽게 설정할 수 있다.

주의!
Copilot 플러그인은 Node >= 18에서 동작한다.
vim.g.node\_host\_prog = "/path/to/node"를 통해 적당한 노드 버전을 지정해줘야한다.

설치 후, :Copilot Auth를 실행하면 깃헙 인증 링크가 열린다. 인증하면 성공.

Inline Suggestion

개인 프로젝트에서 inline suggestion이 잘 되는지 실행해보았다.

아래 gif를 보면, handle까지 입력했을때 현재 구현이 안되어있는 handleUpload에 대한 제안이 나온다.
2개의 후보를 제시해줘서 next, prev 키를 통해 둘 중 고를 수 있다.

입력에 즉각적으로 추천을 제시하는것을 보고, 출시 초기보다 많이 발전했음을 느꼈다.

Handle Upload에 대한 inline suggestion 예시

기본적으로 lazyvim에서는 blink.cmp (또는 nvim.cmp)를 통해 auto complete에 copilot suggestion이 통합되어있다.
개인적으로는 VSCode에서처럼 inline suggestion을 사용하는 것이 편해서 이 부분만 따로 설정해주었다.

아래 값을 false로 수정해주면 inline으로 사용가능하다.

-- init.lua
vim.g.ai_cmp = false

Github 이슈 참고: https://github.com/LazyVim/LazyVim/discussions/4830

I want to use Copilot suggestion with <Tab> but it does not work properly · LazyVim LazyVim · Discussion #4830

Hi, I am using LazyVim almost bare bones with plugins; however, I wanted to have copilot suggestions to be completed with <Tab> instead of going to the autocomplete panel and being mixed with varia...

github.com

Suggestion에서는 아직 얼마전 출시한 Copilot의 GPT-4o 모델을 지원하지 않는다.
(개발 예정 https://github.com/zbirenbaum/copilot.lua/issues/365)

Copilot Chat

VSCode의 코파일럿 패널처럼 동작하는 Neovim 플러그인이다.
여러 파일에 대한 분석 및 수정, 커밋 메시지 동작 등 생각보다 Copilot의 기능들을 충실히 제공한다.

플러그인에서 제공한 영상링크를 보면 프로젝트에서 수정할 파일들을 분석해서 적용하고, 커밋메시지까지 작성해준다.

영상 링크 참고

단계별로 실행하는 과정은 다음과 같다.

1. 코파일럿 챗 열기

챗은 기본적으로 추가 버퍼를 통해 열린다.
창에서 모델 선택, 컨텍스트 입력, 명령 입력을 통해 동작한다.

2. 모델 선택 (생략 가능)

다양한 모델을 선택할 수 있다.

AI 모델 선택

3. 컨텍스트 입력 (생략 가능)

컨텍스트는 코드에 사용할 맥락을 제공한다. buffers를 통해 열린 buffer에서 맥락을 얻을 수 있고, files를 통해 workspace 내의 모든 파일에 접근하거나, file으로 특정 파일을 제공할 수도 있다.

컨텍스트 입력

4. 질문

마지막으로 질문 프롬프트를 입력한다.
전체 예시를 보기 위해 코딩을 잘하기로 유명한 Claude 3.7 Sonnet을 사용해서 간단한 코드 작성을 요청해보았다.

전체 과정 진행 예시

Thinking 모델을 사용하여 조금 오래걸려서 결과까지는 녹화하지 않았다.
코파일럿이 코드를 개선해주고, 아래에 간단한 설명과 참고한 파일을 보여준다.

<C-y> 단축키를 통해 제안 사항을 바로 반영할 수 있다는 것이 굉장히 편리하다.

수정 내용

설명 및 참고 파일

 // 변경사항
 
 const FileUploadButton = () => {
    ...
    function formatFileSize(bytes: number) {
        if (bytes < 1024) return `${bytes} Bytes`;
        else if (bytes < 1048576) return `${(bytes / 1024).toFixed(1)} KB`;
        else return `${(bytes / 1048576).toFixed(1)} MB`;
    }

    return ( 
      ...
      {file && (
        <div className="mt-3 flex items-center p-3 rounded-md bg-slate-50 dark:bg-slate-800 border border-slate-200 dark:border-slate-700">
          <FileIcon className="mr-2 h-4 w-4 text-slate-500 dark:text-slate-400" />
          <div className="flex flex-col">
            <span className="text-sm font-medium">{file.name}</span>
            <span className="text-xs text-slate-500 dark:text-slate-400">
              {formatFileSize(file.size)}
            </span>
          </div>
        </div>
      )}
      ...
    )}

5. 기타

프롬프트 기능을 통해, 미리 정의된 기능들을 사용할 수 있다.

Fix, Commit, Tests, Explain, Docs, Optimize, Review 가 현재 정의되어 있다.
각각의 목적에 맞는 기능을 제공하는데 개발 시 자주 사용할 수 있는 기능들이 모여있어서 유용하다.

코파일럿 프롬프트 액션 창

마무리

Neovim에서도 Copilot을 생각보다 더 자연스럽게 쓸 수 있다.
특히, Chat 기능들도 너무 잘돼서 이정도면 실무에서 써볼만 하다는 생각을 했다.

아쉬움이 있다면, 아직 4o를 미지원한다는 것과, Neovim 기반이기 때문에 VSCode 만큼의 UI는 지원하지 않는다는 점이 있다.

개인적으로도 사용할만한 것 같아서 한 한달정도 사용하면서 장단점을 파악해볼 예정이다.

[Naver D2] 고급 타입스크립트 세션 정리

도리[Dori] — Tue, 25 Feb 2025 23:41:50 +0900

Typescript 홈페이지 소개글

권세규님의 네이버 엔지니어링 데이 세션 infer, never만 보면 두려워지는 당신을 위한 고급 TypeScript를 보았다.

이 세션을 통해 아래 개념들을 더 명확히 익힐 수 있었다.

타입의 대소 비교
타입의 종류
제네릭 타입 검사

또한 아래 과정들을 시각적으로, 단계별로 보여준다.

타입스크립트의 타입 검사가 이뤄지는 과정
실제 라이브러리 코드에서 타입을 개발하는 과정

1시간 12분으로 짧지 않지만 내용이 밀도 있고, 발표자료가 준비가 잘 되어 있기에,
타입스크립트를 잘 사용하고 싶다면 꼭 한번 보는 것을 추천한다.

infer, never만 보면 두려워지는 당신을 위한 고급 TypeScript

이를 아래에 간단히 정리해보았다. (많은 내용 생략)

타입의 대소 비교

타입 A와 B의 대소는 서브타입 관계에 따라 달라진다.

서브타입의 정의

A가 B의 서브타입이다 = 모든 p에 대해, p가 B의 prop이면 p는 A의 prop이다.

타입은 네가지 대소관계가 있다.

a는 b의 슈퍼타입
a는 b의 서브타입
a와 b는 서로 서브타입
a와 b는 무관계

A가 B의 서브타입일 때, B에 A를 대입할 수 있다.
즉, 넓은 타입에 좁은 타입을 대입할 수 있다.

타입의 종류

원시 타입

boolean, number, string, symbol, null, undefined
서로 무관계

리터럴 타입

어떤 타입에 속한 값 하나로 구성하는 타입. 본래 타입의 서브타입으로 간주.
as const를 통해 특정 값을 리터럴 타입으로 선언할 수 있음.

const a: number = 1; // number type
const a: 6 = 1; // '6' 그 자체가 타입 (리터럴 타입)
const a = 6 as const; // a의 타입은 '6' (리터럴 타입)

객체 타입

L의 모든 속성 P에 대하여 L[P] > R[P] 이면 L > R

// ex)
L: { x: number; y?: string; z?: boolean; }
R: { x: number;             z: false; a: 'foo' }

위 예시에서, R의 속성들을 살펴보면

x는 R의 L.x의 서브타입
y(undefined)는 L.y (string | undefined)의 서브타입
z는 R.z (boolean | undefined)의 서브타입
으로, 모두 서브타입 관계를 만족한다.
즉, R은 L의 서브타입이다.

배열/튜플 타입

객체와 동일하나, number를 키로 갖는다.
튜플은 length가 상수 리터럴 타입으로 고정된다.

키 타입 (keyof)

객체 타입의 속성의 Union으로 이루어진 타입
가질 수 있는 가장 넓은 타입 - number | string | symbol
명시적 타입이 주어질 경우, 필드명의 union

함수 타입

반환형과 인자형의 대입 조건을 모두 만족해야함.

반환형에 대해서 공변적 (Covariant)
인자형에 대해서 반변적 (Contravariant)

인자형이 같은 경우, A가 B의 서브타입이라면, A를 반환하는 함수는 B를 반환하는 함수의 서브타입이다.
반환형이 같은 경우, A가 B의 서브타입이라면, B를 인자로 하는 함수는 A를 인자로 하는 함수의 서브타입이다.
인자가 적은 함수를 인자가 많은 함수에 대입할 수 있다.

특수 타입

never, unknown, any, void

unknown: 모든 T에 대해, never < T < unknown
반면 any: never 제외한 모든 T에 대해 any는 T와 서로 서브타입. never는 any의 서브타입

퀴즈!
존재할 수 있는 함수 타입 중 가장 넓은 타입은?

type Wide = (...args: never[]) => unknown

타입스크립트 공식문서에도 종종 등장하는 타입이라고 한다.

제네릭 타입 검사

명시적 타입 전달

제네릭에 명시적으로 타입을 전달한 경우.
제네릭이 선언된 심볼 다음부터는 전달한 타입 그대로 간주

타입 인자 추론

타입 선언 안 한 경우, 제네릭 타입 인자 생략한 경우, infer 문 사용한 경우
컨트롤 플로우 분석으로 수집한 전제로, 해당 타입 인자를 추론. (Greedy)
최대한 비관적, 보수적 분석

느낀 점

라이브러리 개발의 시선에서는 타입 시스템을 작성하는 것도 큰 이슈라고 생각했다.
서비스 코드에서는 마지막 예시같은 극한의 상황은 아직 못겪어봤다.

하지만 공용 유틸 함수 등의 개발에서는 복잡한 타입의 활용도가 높을 수 있다.
그러므로 서비스 개발자도 다양한 복잡한 타입 케이스에 대응하는 연습을 해보면 좋다.
이를 통해 전체 코드베이스의 안정성을 향상할 수 있을 것이다.

JS 글자 수 세기 문제

도리[Dori] — Tue, 18 Feb 2025 23:16:16 +0900

글자 수 문제

JS에서 글자 수를 validation을 하는 경우 보통 length를 사용한다.

const MAX_LENGTH = 10;
const validate = (value: string) => value.length <= MAX_LENGTH;

// ex)
validate('1234567890') // true

하지만, 아래 경우는 어떨까?

validate('정답을 맞춰보세요 ');

띄어쓰기 포함 10글자이지만, false를 출력하는것을 볼 수 있다.

'정답을 맞춰보세요 '.length; // 11

emoji가 길이 2로 계산되기 때문이다.

해결책

[...'정답을 맞춰보세요 '].length; // 10

위와 같이 spread 연산자를 사용하면 결과가 10으로 정상적으로 나오는 것을 알 수 있다.

원인

문자열은 인덱싱, 길이연산 등에서 기본적으로 UTF-16 코드 유닛 기반으로 동작한다.

'정답을 맞춰보세요 '[9]; // '\uD83D' (코드 유닛)

반면 문자열의 이터레이션은 Unicode 코드 포인트 기반으로 동작한다.

Mdn
Strings are iterated by Unicode code points. This means grapheme clusters will be split, but surrogate pairs will be preserved.

즉, spread 연산자나, for ... of를 통해서 반복문을 사용하면, 이모지에 대해서도 정상적으로 사용 가능하다.

iterator로 순회하는 경우

‍

하지만 이렇게 간단하게 끝나지 않는다!
이모지는 더 다양한 형태로 존재하기 때문이다.

이모지 출처: https://emojipedia.org/man-cook-light-skin-tone

위 이모지는 길이가 몇일까?

' ‍ '.length; // 7

사실, 이 이모지는 여러 이모지의 조합이다.

' ‍ '.substring(0, 2); //  
' ‍ '.substring(0, 5); //  ‍
' ‍ '.substring(5, 7); //

밝은 피부톤의 남자 + 후라이와 후라이팬의 조합인데,
밝은 피부톤의 남자도 남자 + 밝은 톤의 조합이기 때문이다.

실제로, spread 연산자로 길이 계산해보면, 다음과 같이 분해되서 (깨진채로) 나타난다.

[...' ‍ '] // [' ', ' ', '‍', ' ']

이런 애들은 console에서 입력 후 backspace로 지울 때도, 한번에 지워지지 않는다.
(남자로 변했다가 지워짐)

한번에 지워지지 않는 이모지

원인

실제 유니코드 문자와, 사용자가 인식하는 문자의 단위는 다르다.
사용자가 인식하는 문자의 단위를 Grapheme cluster라고 부른다.
이는 여러 코드 포인트의 조합이 될 수 있다.

해결책

Intl.Segmenter

Intl.Segmenter - JavaScript | MDN

The Intl.Segmenter object enables locale-sensitive text segmentation, enabling you to get meaningful items (graphemes, words or sentences) from a string.

developer.mozilla.org

위 스펙을 사용해서 이런 문제도 해결 가능하다.

const segmenter = new Intl.Segmenter();
const segment = segmenter.segment(' ‍ ‍ ‍ ‍ 의 길이는?');
console.log([...segment].length); // 10

또는 https://github.com/orling/grapheme-splitter 같은 라이브러리를 사용할 수 있다.

정리

UTF-16 코드 유닛 - 16비트 단위로, 문자를 나타내는 Atom 역할

Unicode Codepoint - UTF-16 인코딩에서는 코드 유닛 1~2개로 나타냄. 약 2²¹ 개

Unicode Grapheme cluster - 하나 이상의 코드 포인트 조합으로, 시각적으로 하나로 인식되는 문자를 나타냄.

결론

상황마다 다르겠지만 이모지 등 Grapheme cluster 문자를 많이 쓰는 서비스에서는 글자 수를 검증하기 쉽지 않다.
특히 길이 제한이 짧은 경우 사용자의 기대와 다른 경험을 줄 가능성이 크다.
반대로 DB에는 일반 텍스트 기준으로 길이 제한이 걸려있는데 FE에서만 Grapheme cluster 기준으로 검증한다면 저장된 데이터가 잘리는 문제가 발생할 수도 있다.

사용자 인식을 기준으로 글자 수 검증이 중요한 서비스라면 Grapheme Cluster 단위로 계산하는 방식을 고려해보자.
길이의 제한은 필요하지만 꼭 글자수일 필요가 없는 경우에는 사용자에게 보여주는 제한을 byte로 보여주는 방법도 있다.

더 이상 메인 에디터로 Neovim을 쓰지 않는 이유

도리[Dori] — Sat, 23 Nov 2024 16:18:09 +0900

이전 글 - https://blue-tang.tistory.com/97

Neovim

Intro 요새 코드에디터로 Neovim을 사용하려는 시도를 하고있다. Vim 자체가 익숙치 않아서 초기에 좀 어려움을 겪었다. Vim motion부터 좀 익숙해지고, 개인 프로젝트 개발할 때는 급하지 않으니 최대

blue-tang.tistory.com

Neovim은 약 1년이 넘는 기간동안 나의 메인 코드 에디터였다. 키보드만으로도 모든 것을 제어할 수 있는 강력한 기능과 속도는 나에게 큰 즐거움을 주었다. 그러나 시간이 지나면서, 나는 점점 Neovim을 메인 에디터로 사용하는 것에 대한 한계를 느끼게 되었다. 이번 글에서는 내가 왜 Neovim을 더 이상 메인 에디터로 사용하지 않게 되었는지에 대해 이야기해보려고 한다.

Neovim의 장점

먼저, Neovim이 제공하는 뛰어난 기능들에 대해 짚고 넘어가자.

• Vim motion: hjkl + 기능키의 조합으로 모든 것을 제어할 수 있다는 것은 코드 작성에 있어 큰 효율성을 가져다준다. 일하면서도 게임을 하는 듯한 재미는 덤.

• 다양한 플러그인: 대부분의 작업을, 심지어 깃 클라이언트까지도 플러그인으로 제공한다. 덕분에 이런 기능들도 키보드로 수행할 수 있어 손을 마우스로 옮길 필요가 없다. 이는 작업 흐름을 끊김없이 유지하는 데 큰 도움이 된다.

• Tmux와의 유연한 연동: Tmux와 결합하여 터미널 내에서 동시에 많은 세션 관리가 가능하다. 여러 프로젝트를 동시에 진행할 때 매우 유용하다. 로컬 개발 서버 등 터미널에서 작업하는 여러 기능들과의 결합이 부드럽다.

• 빠른 시작 속도: 가벼운 무게 덕분에 에디터의 로딩이 매우 빠르다.

• 필요할 때 마우스 사용 가능: 비록 잘 사용하지는 않지만, 필요할 때는 마우스로도 조작할 수 있다.

Neovim의 단점

하지만 Neovim을 사용하면서 몇 가지 단점들도 분명히 존재했다.

• 에디팅 외적인 부분의 부족한 UI: 현대적인 IDE들이 제공하는 편리한 UI가 Neovim에는 부족하다. 디버깅, 소스컨트롤 등의 기능을 이용할 때 불편함이 있었다.

• 그래픽적인 UI의 한계: 텍스트 기반의 인터페이스로 인해 이미지나 마크다운 등 그래픽적으로 표현되는 정보들을 효과적으로 전달받기 어려웠다.

• 마우스 부재: 분명 마우스로 편한 작업들이 있다. 파일을 드래그해서 한번에 옮길 때 등 종종 그 필요성이 생길 때 단점으로 다가왔다.

• IDE와의 기능 격차: IDE들은 계속해서 발전하고 있는데, Neovim은 그런 발전 속도를 따라가지 못하는 느낌이었다.

• 유지보수 되지 않는 플러그인들: 많은 플러그인들이 시간이 지나면서 업데이트가 중단되거나 버그가 존재하는 경우가 있었고, 이는 안정성에 문제를 가져왔다.

• 설정을 위한 Lua 학습 필요성: 깊이 있는 설정을 위해서는 Lua 언어를 알아야 한다. 추가적인 학습 비용이 된다.

• Monorepo에서의 TS 서버 구동 어려움: 대규모의 Monorepo 환경에서 TypeScript 서버를 제대로 구동하기가 어려웠다.

• 큰 파일 작업 시 속도 저하: 큰 파일을 열 때의 최적화가 되어있지 않아 오히려 VSCode보다 느린 경우가 발생했다.

해결책 찾아보기

이러한 단점들을 보완하면서도 Neovim의 장점을 유지할 수 있는 방법을 찾기 시작했다. 그리고 시도한 방식은 VSCode의 Neovim 익스텐션을 사용하는 것이었다.

편리한 점

앞서 나열한 단점들을 대부분 해소하면서도 장점을 찾을 수 있었다.

• 간편한 설치: VSCode 익스텐션 형태로 제공되기 때문에 설치와 설정이 간단했다.

• Neovim 플러그인 사용 가능: 기존에 사용하던 Neovim의 플러그인들도 일부 활용할 수 있었다.

남은 불편함들

하지만 완벽한 해결책은 아니었다.

• Neovim과 VSCode의 싱크 문제: 두 환경 간의 싱크가 깨지는 문제가 발생했다. 이는 작업 흐름에 큰 지장을 주었다.

• 버퍼 이동 오류: 버퍼 싱크가 깨지면서 단축키로 버퍼를 이동할 때 엉뚱한 파일로 이동하는 문제가 있었다.

이러한 문제들은 사용에 꽤나 치명적인 경험이었고, 이로 인해 새로운 환경에 완전히 적응하기가 쉽지 않았다.

결론

Neovim은 여전히 훌륭한 에디터이지만, 나의 작업 환경과 요구사항에 완벽히 부합하지는 않았다. 하지만 키보드를 통한 만족스러운 개발 경험은 Neovim 사용을 완전히 포기할 순 없게 만든다.

VSCode 내에서 Neovim을 더욱 자연스럽게 사용할 수 있는 방법이 발전하기를 기원하며, 최대한 Neovim의 싱크를 깨지 않을 수 있는 방법을 찾아 볼 것이다.

SSE 토이 프로젝트 - 프롬프터 만들기

도리[Dori] — Thu, 18 Jul 2024 00:13:11 +0900

SSE(Server Sent Event)를 사용해보자.

서버에서 입력한 내용을 화면에 마크다운으로 띄워주는 프롬프터를 만들어본다.

github: https://github.com/JAAAAAEMKIM/practice/tree/main/sse-practice

스펙

1. 서버

사용자 입력을 받아 라인별로 클라이언트에 전송한다.
SSE를 통해 구현한다.

2. 클라이언트

서버와 연결되어, 사용자 입력을 화면에 표시한다.
Markdown을 사용해서 실시간으로 보여준다.

서버 개발하기

기술 스택: Bun, Typescript

Bun 선정 이유

Typescript 바로 실행 가능
간단한 서버 실행

서버 실행

구현은 SSE 관련 내용의 bun github issue를 참고했다.
https://github.com/oven-sh/bun/issues/2443

Bun.serve({
  port: 8080,
  fetch(req) {
    if (new URL(req.url).pathname === "/sse") {
      // sse 요청 핸들링
      return sse(req);
    }
    return new Response("Not Found", { status: 404 });
  },
});

`sse`요청 처리

function sse(req: Request) {
  const { signal } = req;
  return new Response(

    // Stream을 응답으로 준다.
    new ReadableStream({
      start(controller) {
        eventEmitter.on("message", (data) => {
          // stdin에서 입력 data를 message event에 담에 eventEmitter로 보낸다.
          // sendSseMessage 내에서 stream의 controller를 통해 data를 클라이언트로 전송한다.
          sendSseMessage(controller, data);
        });

        signal.onabort = () => {
          controller.close();
        };
      },
    }),
    {
      status: 200,
      headers: {
        // SSE에 필요한 헤더 (중요)
        "Content-Type": "text/event-stream",
        "Cache-Control": "no-cache",
        Connection: "keep-alive",
      },
    },
  );
}

stdin 처리

const prompt = "Type prompt: ";
process.stdout.write(prompt);

// user input을 line 단위로 읽는다.
for await (const line of console) {
  console.log(`You typed: ${line}`);
  // eventEmitter에 입력 데이터를 전달.
  eventEmitter.emit("message", line);
  process.stdout.write(prompt);
}

`sendSseMessage` 구현

function sendSseMessage(
  controller: Bun.ReadableStreamController<Uint8Array>,
  data: string,
) {
  const payload = data
    .split("\n")
      // 입력 데이터를 sse 형식에 맞게 수정 (data: [data]\n\n)
    .map((line) => `data: ${line}\n\n`)
    .join("");

  controller.enqueue(Buffer.from(payload));
}

클라이언트 구현

클라이언트 구현은 간단하여 짧게 넘어간다.

pnpm create vite 를 사용하여 빠른 시작
Prompter 구현
proxy 설정

import { useEffect, useRef, useState } from "react";

import Markdown from "react-markdown";
import styles from "./Prompter.module.css";

const SERVER_URL = "/sse";

const Prompter = () => {
  const [content, setContent] = useState("");
  const eventSourceRef = useRef<EventSource>();
  const articleRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    try {
      // EventSource를 통해 sse 이벤트를 받을 수 있다.
      eventSourceRef.current = new EventSource(SERVER_URL);
      eventSourceRef.current.onmessage = (ev) => {

        // 기존 content와 연결해준다.
        setContent((prev) => `${prev}\n${ev.data}`);
      };

      return () => {
        eventSourceRef.current?.close();
      };
    } catch {
      setContent("Error");
    }
  }, []);

  useEffect(() => {
    if (articleRef.current) {
      // 새로운 data가 화면에 표시될 때 보이도록 스크롤
      articleRef.current.scrollIntoView({ block: "end" });
    }
  }, [content]);

  return (
    <article className={styles.article}>
      <div ref={articleRef}>
        <Markdown>{content}</Markdown>
      </div>
    </article>
  );
};

export default Prompter;

완성하면 처음에 봤던 화면을 사용해볼 수 있다.

[React Conf 2024] Demystifying Accessibility in React Apps

도리[Dori] — Wed, 3 Jul 2024 22:37:34 +0900

https://youtu.be/0ckOUBiuxVY

React Conf 2024에서 Demystifying Accessibility in React Apps라는 발표가 있었다.

이번 포스팅에서는 발표 내용을 정리하며 React 앱에서 접근성을 어떻게 구현할 수 있는지 알아본다.

접근성의 정의

Accessibility: 장애가 있는 사람들도 동일하게 접근하고 사용할 수 있도록 하는 것.
실생활 예시: 휠체어 경사로, 점자 블록 등.
디지털 환경: 스크린 리더 등이 해당됨.

접근성의 동작 방식

웹 문서는 HTML로 받아 DOM 트리로 파싱하고 UI로 사용자에게 보여진다.
이 때, DOM 트리를 기반으로 접근성 트리(Accessibility Tree)가 생성된다.
접근성 트리는 개발자 도구에서 확인할 수 있다.

출처: 하단 발표 자료 링크

개발자 도구 접근성 트리 캡쳐

DOM 노드처럼 접근성 tree의 노드도 name, role, focusable, description 등 다양한 속성을 가진다.
이 트리를 통해 보조 기술(Assistive Technology)이 동작한다.
ex) 스크린 리더는 접근성 트리를 순회하며 각 노드의 정보를 읽는다.

Semantic HTML이 중요한 이유는 여기에 있다.
모든 요소가 <div>로만 구성되어 있다면 각 노드의 의미를 알기 힘들어지고 접근성이 떨어진다.

ARIA - Accessible Rich Internet Applications

ARIA는 접근성 트리를 제어할 수 있는 도구이다.
요소의 동작이나 외관을 변경하지 않고도 접근성을 향상시킬 수 있다.
ex) aria-placeholder, aria-label 등

주의!

대부분의 경우 기본 HTML만 잘 사용해도 충분하다.
통계적으로 ARIA를 사용하는 곳에서 접근성 오류가 더 많이 발생한다.

예시 1: 아이콘 버튼

icon + text

아이콘의 경우 접근성 관점에서 불필요할 수 있다.
이 경우 icon을 aria-hidden을 통해 접근성 tree에서 숨길 수 있다.

<button>
  <span aria-hidden="true"> </span>
  Submit
</button>

icon만 있는 버튼

텍스트가 없는 아이콘 버튼 UI는 접근 가능한 이름이 없어서 스크린 리더가 "button"이라고만 읽는다.
aria-label을 통해 이름을 줄 수 있지만 번역은 되지 않는다.
대신 버튼 안에 span 태그로 텍스트를 넣고 CSS로 숨길 수 있다.

const VisuallyHidden = ({ children }) => (
  <span style={{
    position: 'absolute',
    height: '1px',
    width: '1px',
    padding: 0,
    margin: '-1px',
    overflow: 'hidden',
    clip: 'rect(0 0 0 0)',
    whiteSpace: 'nowrap'
    border: 0,
  }}>
    {children}
  </span>
);

const IconButton = () => (
  <button>
    <span aria-hidden="true"> </span>
    <VisuallyHidden>Submit</VisuallyHidden>
  </button>
);

예시 2: 텍스트 입력

input 만으로는 어떤 값을 입력하는지 알 수 없기 때문에 반드시 연관된 label이 필요하다.
input과 label을 연결하기 위해 htmlFor 속성을 사용해야 한다.

// input의 name을 찾지못함.
<label>Username</label>
<input type="text" name="username" />

// input이 label과 연결되어 어떤 input인지 찾을 수 있음.
<label htmlFor={inputId}>Username</label>
<input type="text" name="username" id={inputId} />

라벨을 UI에서 숨기고 placeholder를 통해 노출하는 경우도 있다.
이때, 아까 만든 VisuallyHidden 컴포넌트를 활용할 수도 있다.

// as를 통해 태그 다형성 지원
const VisuallyHidden = ({ as: Tag = "span", ...props }) => {
  return <Tag className="visually-hidden" {...props} />;
}

<VisuallyHidden as="label" htmlFor={inputId}>Username</VisuallyHidden>
<input type="text" name="username" id={inputId} placeholder="Username" />

인풋 하단에 인풋에 대한 설명을 보여줄 때가 있다.
ARIA를 활용해 이 설명이 해당 인풋의 설명인 것을 명시해줄 수 있다.
접근성 트리의 input 노드의 description 속성에 해당 설명이 들어가서 스크린 리더가 읽을 수 있다.

<label htmlFor={inputId}>Username</label>
<input
  type="text"
  name="username"
  id={inputId}
  aria-describedby={hintId}
/>
<span id={hintId}>
  Must be between 3 and 20 characters long
</span>

input의 오류 상태는 aria-invalid를 통해 나타내줄 수 있다.
aria-invalid는 스타일링에도 사용할 수 있다.
오류 메시지또한 aria-describedby에 추가해줄 수 있다. 여러 id가 가능하다.

<input
  type="text"
  name="username"
  id={inputId}
  aria-describedby={[errorId, hintId].join(' ')}
/>
<span id={errorId}>
  Must be between 3 and 20 characters long
</span>

.input[aria-invalid="true"] {
  border-color: red;
}

예시 3: 알림

알림은 보통 어떤 동작이 일어날 때 화면에 나타난다.
스크린 리더는 화면을 순차적으로 읽기 때문에 이를 바로 읽지 못할 수 있다.
이때 aria-live 영역을 사용할 수 있다.
페이지의 특정 부분을 라이브 영역으로 지정하면, 그 부분은 모니터링되며 스크린 리더에 의해 읽혀진다.
aria-live="polite"와 aria-atomic="true"가 합쳐진role="status" 을 사용해도 된다.

aria-live = 
	| "off"
	| "polite" // user가 idle 한 경우. 가장 많이 사용
	| "assertive" // 변화 시 즉각적으로 읽기. 즉시 전달해야할 때 사용

// 이 영역에 변화가 생기면, screen reader에 전달되어 내용이 읽어진다.
<div aria-live="polite">
  {message}
</div>

// 또는, 
<div role="status">
  {message}
</div>

맺음말

접근성은 하나의 스펙트럼이다. 완벽하게 구현하지 않아도 조금씩 개선해 나가는 것이 중요하다. 접근성을 고려하여 React 앱을 개발하면 더 많은 사용자가 편리하게 이용할 수 있다. 모두가 접근 가능한 웹을 함께 만들어 나가자.

발표 자료

Demystifying accessibility in React apps

도리

FE Conf 2025 후기

메인 프로그램

스벨트를 통해 리액트 이해하기

메모를 지울 결심

라이트닝 토크

부스

네트워킹

애프터파티

<프로그래머의 뇌> 정리

인지과학적 관점의 프로그래밍

LTM 더 활용하기

작업 기억 공간 부하 줄이기

코드에 적용하기

코드 이해

문제 해결

좋은 코드 작성하기

좋은 이름이란?

언어적 안티패턴

업무 중단에 대응하기

대응

[Github MCP] Github 작업은 AI에게 맡겨보자

결과 미리보기

PR 대시보드

대신 코드리뷰

연동하기

준비물

docker

Github Access 토큰

Github MCP 설치

프롬프트 팁

뚝뚝 끊기는 이미지 UX 개선 - Progressive 이미지

TL;DR

장점

단점

만들어보기

준비물

진행 과정

Neovim에서 Copilot 사용하기

Copilot in Neovim

Inline Suggestion

Copilot Chat

1. 코파일럿 챗 열기

2. 모델 선택 (생략 가능)

3. 컨텍스트 입력 (생략 가능)

4. 질문

5. 기타

마무리

[Naver D2] 고급 타입스크립트 세션 정리

타입의 대소 비교

타입의 종류

원시 타입

리터럴 타입

객체 타입

배열/튜플 타입

키 타입 (keyof)

함수 타입

특수 타입

제네릭 타입 검사

느낀 점

JS 글자 수 세기 문제

글자 수 문제

해결책

원인

‍

원인

해결책

정리

결론

더 이상 메인 에디터로 Neovim을 쓰지 않는 이유

SSE 토이 프로젝트 - 프롬프터 만들기

스펙

1. 서버

2. 클라이언트

서버 개발하기

Bun 선정 이유

서버 실행

sse요청 처리

stdin 처리

sendSseMessage 구현

`sse`요청 처리

`sendSseMessage` 구현