스스로를 의심하던 그 즈음

예상보다 취준이 길어졌다. 개발자 직무가 과연 나한테 잘 맞는지 고민도 깊어졌다. 그 즈음 2026 오픈소스 컨트리뷰션 아카데미에 멘티 신청서를 냈다.

AI에 기대지 않고 코드를 읽는 눈을 기르고 싶었다. 코어를 이해하고, 무엇보다 개발을 정말 즐기는지 확인하고 싶었다. 경력에도 능력에도 자신이 없던 시기였다. 선발되면 열심히 해보고, 안 되면 디자이너 프리랜서로 돌아갈 생각까지 했다.

한 달 반쯤 지나 선발 문자를 받았다. 처음엔 믿기지 않았다. 이메일로 확인하고 나서야 마음껏 기뻐했다.

발대식 전까지 멘티 가이드 노션을 몇 번이나 다시 봤는지 모르겠다. 7월 중순부터 한 달간 이어지는 Challengers 기간은 기본 강의와 세팅, 온보딩으로 채워진다.
이 설렘과 긴장을 안고 알찬 시간을 보내자고 다짐했다.

발대식날 도착하니 생각보다 많은 인원에 놀랐다. 이런 큰 프로그램에 함께하게 되어 뿌듯했다.

우리 팀은 대학생, 취준생, 현직자가 고루 섞였다. 이미 오픈소스에 기여하던 사람도, 작년 아카데미를 거친 사람도 있었다.
멘토님과는 첫 만남 아닌 첫 만남이었다. 예전 온라인 기여 모임에서 뵀고, 그때 운영진이던 멘토님께 작은 기여와 후원을 했었다.

오탈자 대신 로직으로 기여

이번에 맡은 첫 작업은 문서 오탈자가 아니라 내부 로직 보완이었다. 이렇게 시작한 기여가 나중에 기능 구현에 자신감을 줬다.
멘토님이 골라주신 good first issue 중 ESLint eqeqeq 룰에 에러 위치를 추가하는 작업이었다.

작은 수정이었다. 그래도 전 세계가 쓰는 오픈소스에 문서가 아닌 로직으로 기여한다는 사실에 긴장됐다. 제대로 하고 싶어 파고들었다. 왜 테스트에 위치 조건을 넣어야 하는지, 각 프로퍼티가 무엇을 의미하는지 공부했다.

작업을 끝내고 나니 다른 룰은 어떤 성격인지 궁금해졌다. 공식 문서를 하나씩 훑었다. 그러다 복사·붙여넣기 과정에서 미처 고쳐지지 않은 문장이 눈에 띄었다.
별도 이슈 없이 바로 문서 수정에 기여했다.

내부 로직을 이해하는 눈은 멘토님 강의에서 크게 늘었다. AST와 ESLint 코어를 직접 그려가며 설명해 주셨다. 이후 다시 그려가며 들었던 강의를 복기했고, 블로그 글로 정리했다.
언젠가 나도 누군가에게 내 지식을 알기 쉽게 설명하는 날이 오면 좋겠다.

AI는 쓰되, 검토는 내 몫

ESLint 생태계는 AI 활용을 조건부로만 허용한다. 활용은 하되 책임은 컨트리뷰터 몫이다.
그래서 PR을 올릴 때마다, 별것 아닌 내용이어도 긴장됐다.

나는 이 원칙이 오히려 편했다. 시작할 때부터 AI에 기대지 않고 코드를 읽고 싶었기 때문이다.
하지만 방대한 레퍼런스를 찾는 일은 AI가 나보다 낫다. 이런 부분은 적극 활용한다.
코어 로직에서는 AI 코드를 그대로 쓰기 어려웠다. 과하거나 부족한 부분이 계속 보였다. 결국 제안을 의심하고, 직접 문서를 확인하고, 왜 이렇게 되는지 따지는 과정은 내 몫이었다.

도구는 도구로 쓰고 판단은 사람이 한다. 지금은 이 방식이 맞다고 느낀다.

린트 규칙은 어디까지 잡아야 할까

멘토님이 운영하는 eslint-markdown 플러그인에 기능을 구현할 기회가 생겼다.

eslint-markdown
ESLint로 markdown을 린트하는 서드파티 플러그인이다. ESLint 공식 @eslint/markdown 위에 얹어 쓰는 보조 패키지로, 문법 검사보다 문법 스타일의 일관성을 중시한다.

작업하며 부딪힌 질문은 하나였다. 어디까지 오류로 잡고, 어디부터 사용자 취향으로 둘 것인가.

예를 들어 # Heading ©은 문법상 틀리지 않는다. # Heading :smile:도 마찬가지다. 규칙이 이런 입력까지 막으면 사용자는 답답하다. 그렇다고 다 열어두면 규칙을 만든 의미가 없다.
사용자의 입력으로 들어오는 모든 문자열을 정규식으로 모두 잡기란 어렵고, 마크다운은 특히 취향과 패턴 영역이 넓다.

경계를 정하려면 먼저 입력이 어떻게 해석되는지 알아야 했다. MDX playground로 mdast를 뜯어보며 노드를 하나씩 파악했다.
이 경계는 멘토님과도 함께 고민했던 부분이다.
결국 eslint-markdown은 문법상 오류를 일으키는 입력만 문제로 잡고, 나머지는 사용자 입력에 맞춘 스타일로 두기로 했다.

이슈에서 배포까지

배정받은 이슈를 먼저 분석했다. 참고 문서도 많고 레퍼런스도 찾아야 해서, 어떻게 작업할지 확답을 얻기까지 시간이 걸렸다.
멘토님께서 참고하라고 알려준 feat, fix PR을 확인하고 ESLint에서는 어떤 부분을 고려해야할지 띵킹 포인트를 잡아갔다. 정규식 순회, 어떤 노드를 볼지 고려하기, 엣지 케이스, markdownlint 레퍼런스 체크.

기능 구현 PR을 열고 2주 동안 멘토님과 리뷰를 주고받았다. 코멘트를 기준으로 로직을 보완하고, 오프라인 모임에서 놓친 부분을 질문하고, 엣지케이스를 추가했다. 그리고 같이 고민한 기능이 메인에 머지되어 배포됐다.

코드 작업부터 기여, 메인테이너와 리뷰, 메인 배포까지. 한 번도 겪어보지 못한 플로우라 감회가 새로웠다. 그사이 멘토님이 리드멘티를 제안해 주셨다. 내가 맡아도 될지 망설였지만, 기회는 왔을 때 잡기로 했다.

Challengers를 마무리하며

한 달의 Challengers 기간에 PR 네 개가 머지됐다. 작년 오픈소스 기여 모임에서 시작한 인연이 여기까지 왔다.
재밌게 할 수 있을지, 어렵진 않을지 고민했다. 그런데 한 달이 훅 지날 만큼 코드에 몰입했다. 코어 로직과 남들의 PR을 살피며 배운 점도 많다.

'나는 개발이 잘 맞는가'라는 고민은 이제 다른 자리로 옮겨갔다.
개발은 좋아한다. 다만 서비스뿐 아니라 이런 코어단에 기여할 때도 재미를 느꼈다. 꼭 서비스 개발자여야 내가 좋아하는 개발을 할 수 있는 건 아니었다.
이제 목표는 어느 쪽이냐가 아니라, 내가 즐겁게 개발할 방법을 찾는 쪽이다.

그리고 오늘, 또 이슈를 배정받았다.
다시 달려야겠다. 🏃🏼‍♂️‍➡️

---

기여 목록

• eslint/eslint #21090
• eslint/eslint #21093
• lumirlumir/npm-eslint-markdown #639
• lumirlumir/npm-eslint-markdown #632