"interview" 태그로 연결된 3개 게시물개의 게시물이 있습니다.

안녕하세요! 저는 현재 Line에서 오픈챗 백엔드 엔지니어로 근무 중인 김인제라고 합니다. 🙂
오픈 소스에 관심이 있다 보니, 여러 오픈소스 프로젝트에 참여하고 있습니다.
주로 기여하는 라이브러리는 LINE/armeria, spring-framework, spring-batch, reactor-core 등이 있는데요,
현재는 오픈소스 생태계의 확산과 성장을 위해 오픈소스 멘토링과 모각코^!를 진행하고 있습니다.

저는 개발자라면, "오픈소스에 기여하고 싶다는 마음"을 한 번쯤은 가지게 되는 것 같아요.
그래서 저도 여러 가지 시도를 해보았습니다.

초창기에는 스프링(Spring)에 기여를 시도하거나, 오픈소스 코드 읽기 스터디를 1년 동안 운영했었어요.
그런데 오픈소스의 코드를 읽는 등 여러 가지를 해보았지만, 어떻게 기여하면 좋을지 몰라 어려움을 겪었어요.

그러다가 라인 오픈 소스 스프린트라는 이벤트를 알게 되었는데요,
개발자들이 기여할 프로젝트를 선정하고, 멘토링을 통해 기여를 이끌어 내는 이벤트였어요.
저도 이 이벤트에 참여하여 오픈소스 메인테이너분께 도움을 받아 오픈소스 기여에 성공할 수 있었어요.
처음에 시도했을 때에는 정보도 없었고 도움도 받기 어려워 실패했었지만 이 기회를 통해 기여를 할 수 있었죠.
그 덕에 첫발을 내밀게 되면서 지금까지 이어올 수 있었던 것 같습니다 😊

제가 느낀 가장 큰 어려움은, 오픈소스에 처음 들어갈 때의 진입 장벽이었어요.
우선 모든 문서나 커뮤니케이션이 영어로 진행되잖아요.
게다가 커뮤니케이션이 비동기로 진행되고, 해외 개발자가 많아 문화적 차이가 있다고 생각해요.
그래서 “이분들과 어떤 방식으로 소통해야 할까?”를 고민하는 게, 실제로 코드를 작성하는 것보다 더 어려웠던 것 같아요.

제가 기여를 시작한 게 한 3년 전쯤이었는데, 그땐 지금처럼 AI 기술이 발달해 있지 않았어요.
그래서 번역 도구나 챗봇 같은 걸 사용해 보는 게 쉽지 않았죠.
대신, 저는 클래스 다이어그램이나 시퀀스 다이어그램을 활용해서, 텍스트 대신 시각적인 자료로, 기능을 설명했어요.

시각적 자료를 첨부해서 커뮤니케이션을 하는 인제님 댓글 일부

“이런 걸 만들어보려고 한다”라고 그림으로 보여주니까, 말로 장황하게 설명하는 것보다 훨씬 수월하더라고요.

저는 비동기 서버 쪽에 관심이 많아서, LINE/armeria라는 비동기 서버 오픈소스 프로젝트에 기여를 많이 했어요.
거기서 여러 가지 비동기 구현체 관련 기능을 추가했는데, 그 중 제가 새로 추가한 기능이 하나 있었거든요.
그런데 몇 주 뒤에 저한테 멘션과 함께 메일 알림이 온 거예요.
“이거 네가 추가한 기능 같은데, 버그가 있는 것 같다. 고쳐줄 수 있겠니?”라는 내용이었죠. 그 순간이 정말 기억에 남아요.

제가 만든 코드를 지구 반대편에 있는 누군가가 실제 서비스에서 사용하고 있었고,
그 API가 기존 기능이 아니라 완전히 새로 추가한 기능이었는데도
업데이트 버전을 사용하면서 다양한 케이스를 거치다 보니 버그가 발견된 거예요.
저한테 “이 부분에서 문제가 생긴 것 같다”라고 피드백을 주니까, 고치면서 “오픈소스는 이런 과정을 통해 발전하는구나!” 하고 많이 느꼈어요.

특히나 리뷰어 분들조차도 예상 못 한 케이스였는데, 릴리스하자마자 불과 몇 주 만에 보고되고,
또 빠르게 수정할 수 있다는 게 오픈소스의 큰 장점이라는 생각이 들었어요.
그래서 그 기억이 아직까지도 가장 인상 깊게 남아있습니다.

커뮤니케이션이 제일 중요한 것 같아요.
회사에서 코드 리뷰를 할 때는, 서로 같은 팀이고 같은 서비스를 개발하니까 맥락을 다 알고 있잖아요?
그래서 리뷰가 좀 복잡해도 옆자리에 가서 물어보면 되지만, 오픈소스는 서로 이름도 모르고, 어느 나라 사람인지도 모르고, 시간대도 전부 달라요.

이렇듯 컨텍스트가 전혀 공유되지 않았는데, 서로 간에 신뢰도가 낮은 상태에서 리뷰를 주고받아야 하잖아요.
그래서 리뷰를 받을 때나 할 때 가장 중요한 건, 가능한 한 컨텍스트를 잘 정리해서 신뢰감을 주는 것이라고 생각해요.

단순히 PR만 올려두고, 디스크립션에 간단한 내용만 적는 게 아니라, 이 PR에서 어떤 문제를 어떻게 해결하려고 했는지를 상세히 써주고,
시각화 자료(예: 클래스 다이어그램, 시퀀스 다이어그램 등)도 첨부해 주면 훨씬 좋아요.
또, 내가 생각했던 관점이나 예시 코드가 있다면 “나는 이렇게 생각했는데, 너는 어떻게 보니?” 하고 미리 물어보는 과정도 중요하고요.

즉, 이 PR로 인해 생기는 변화를 상대방이 한 번에 이해할 수 있도록 시각화하고,
배경 설명도 전해주는 게 오픈소스 리뷰에서 가장 핵심적인 부분이라고 생각해요.
참고로 저는 다이어그램을 그릴 때, draw.io이나 PlantUML와 같은 도구를 사용해요.

draw.io와 PlantUML 로고

저는 “재미있어 보이고, 관심이 가는 것”을 선정하는 것 같아요!
멋있거나 유명한 오픈소스도 물론 좋지만, 결국 저는 오픈소스를 취미 중 하나라고 생각하거든요.

예를 들어, 운동을 취미로 삼으려고 할 때도 멋있어 보이는 운동보다는 내가 끌리는 운동을 고르잖아요?
그런 것처럼, 오픈소스도 내가 애정이 가고, 그냥 재밌어 보이는 것에 기여하는 편이에요.

그래서 평소 뉴스레터 등을 보다가 “오, 이 오픈소스 재밌어 보이네?” 싶으면 들어가 보기도 하고,
최근에 제가 직접 써본 것 중에 “와, 이거 정말 잘 만들어졌다!” 싶으면 또 그 프로젝트에 기여해보곤 해요.

저는 커뮤니케이션이 가장 중요한 요소라고 생각해요.
그런데 오픈소스 환경은 정말 극단적인 커뮤니케이션 상황이라고 볼 수 있거든요.
아까 말씀드렸듯이, 서로가 처음 보는 사람이고, 어느 나라 사람인지도 모르고, 문화적 차이도 크고,
기존에 쌓인 신뢰감도 전혀 없는 상태에서 나의 의견을 설득해야 하잖아요.

이런 상황은 사실 오픈소스 기여를 할 때 외에는 거의 평생 한 번도 안 겪어볼 정도로 독특하다고 봐요.
그래서 당연히 처음엔 어렵게 느껴질 수 있어요.
처음부터 잘하시는 분도 계시겠지만, 만약 어렵게 느껴지신다면 오픈소스 레포에서 비슷한 이슈나 PR을 살펴보는 걸 추천해요.
이미 이슈(Issue), PR(Pull Request), 그리고 논의 과정이 모두 공개되어 있으니까,
다른 사람들이 어떻게 의사소통했는지 열람해 보고, 그걸 그대로 따라 해보는 것도 좋습니다.

오픈소스에서 살펴보면 좋은 탭 (이슈/PR/토론)

오픈소스는 단순히 코드만 오픈되어 있는 게 아니라, 협업 과정(이슈, PR, 논의 과정)까지 전부 오픈되어 있잖아요.
바로 그 부분을 참고하면, 커뮤니케이션 스킬도 자연스럽게 습득할 수 있으니까 활용해보시면 좋을 것 같아요.

저는 커리어적으로도 직접적인 도움이 된다고 생각해요!
가장 좋은 건 “이 기여를 안 했다면 아예 알지 못했을 새로운 관점이나 경험할 수 없었던 기회들”이 생긴다는 거예요.
일단 기여를 지속한다는 건, 저희가 현대 문명에 어떤 식으로든 ‘기여’를 하고 있는 거잖아요? 그 부분만으로도 너무 좋고요.

또, 커리어적으로 도움이 되는 건 “내가 기여했다”는 흔적이 전부 남아있다는 점이에요.
예를 들어, 면접 상황에서 더 이상 증명할 필요도 없이 제가 기여한 PR을 통해 이야기를 하면 되거든요.
이미 머지가 됐고, 검증된 자료니까 굉장히 직접적으로 도움이 되죠.

그리고 기여하면서 더 좋은 것은 새로운 인연들이 많이 생긴다는 거예요.
오픈소스를 안 했다면, 지구 반대편에 있는 개발자랑 이야기할 기회가 없었을 텐데 오픈소스를 통해서 인연이 생기고,
서로 관심사가 맞거나 재밌는 주제가 있으면 협력하면서 관계를 이어나갈 수 있더라고요.

게다가 기여하는 사람들이 생각보다 많지 않잖아요. 그래서 오픈소스 기여자들끼리 서로 도움 주고받으면서 신뢰를 쌓으면,
거기서 더 많은 기회가 생기고 새로운 사람들을 만나게 돼요. 저에게는 그게 가장 큰 장점이라고 생각해요.

저는 3년 넘게 꾸준히 기여를 이어오고 있어요.
그리고 그 과정에서 오픈소스 기여가 10년, 20년 먼저 개발해오신 분들이 우리를 위해 남겨놓은 소중한 문화라는 걸 느꼈어요.

우리가 이렇게 개발자로 살 수 있는 것도, 인터넷이 처음 만들어질 때부터 모두가 지식을 공유하고 서로 도우면서 발전시켰기 때문이잖아요.
운영체제(OS)도 세계 각지의 사람들이 함께 기여하고 협력한 결과로 만들어졌고요.
그렇기 때문에 지금 우리가 개발자라는 커리어로, 상대적으로 편하게 생활하고 좋은 보수를 받으면서 일할 수 있다고 생각해요.
그게 정말 소중한 문화이자 중요한 유산인데, 최근에는 기여 문화가 점차 사라지고, 기여에 대한 존중 또한 예전만 못한 모습을 종종 보게 되어서 안타깝더라고요.

그래서 저는 이 문화를 더 많은 사람들에게 알리고, 가치를 높이기 위해 기여를 이어가고 있어요.
또, 오픈소스 멘토링을 통해 다른 분들의 기여를 돕는 이유도 이 귀한 문화가 계속 이어지길 바라기 때문입니다.

진행했던 오픈소스 멘토링 목록 캡처

“나도 이 문화를 후대 개발자들에게 물려주고 싶다”라는 마음이 정말 커서, 그 마음 하나로 지금도 열심히 활동하고 있습니다.

일단 기술적으로 많이 성장했어요. 사이드 프로젝트나 회사 서비스 개발로는 볼 수 없었던 훨씬 더 넓은 세상이 오픈소스에 있더라고요.
다양한 관점을 접할 수 있었고, 현대 문명을 지탱하는 소프트웨어들이 어떻게 만들어지고
진화해가는지 오픈소스 기여를 통해 처음으로 깨닫게 됐어요.

또, 새로운 인연도 정말 많이 만났고요. 그리고 방금 말씀드렸듯이,
이 오픈소스 기여 문화 자체가 결국 10년, 20년 먼저 개발하신 분들이 우리에게 남겨준 귀중한 유산이잖아요.
그래서 “우리가 지금 그 길을 이어가고 있다면, 적어도 소멸은 막아야 하지 않을까” 하는 가치관도 생긴 것 같아요.

오픈소스를 “혼자서 해야 한다”는 고정관념을 과감히 버려보시면 좋을 것 같아요.
정말 도움을 받아보는 것을 적극 권장하고 싶습니다.
저도 혼자 기여를 시작해보려고 1년 넘게 고생하다가, 결국 도움을 받고 나서야 본격적으로 기여를 시작할 수 있었거든요.

사실 오픈소스라는 영역은 혼자 하는 것보다, 조금이라도 남의 도움을 받으면서 함께 하면 생각보다 훨씬 쉽게 도전할 수 있더라고요.
예를 들어, 음악을 처음 배울 때도 거의 대부분 레슨을 받잖아요?
그런데 오픈소스는 이상하게도 다들 혼자서만 열심히 하려고 하시더라고요. 그래서 저는 “도움을 꼭 받아보시라”고 말씀드리고 싶어요.

도움이 필요하신 분은 오픈소스 멘토링 블로그에 오셔서 멘토링에 참여해 보시면 좋을 것 같습니다.

안녕하세요! 저는 현재 AI 엔지니어로 일하고 있는 강병진이라고 합니다. 🙂
지금은 GS라는 회사에서 AI Experience(AX)^! 프로젝트들을 진행하고 있는데요. 이 팀에 합류하기 전에는 스타트업에서 약 4년 정도 근무하면서, 처음에는 혼자 모든 개발을 담당하는 ‘1인 개발자’로 시작했습니다. 그러다 스타트업이 시리즈 C 투자 단계까지 성장하면서 자연스럽게 팀을 리딩하는 역할까지 맡게 되었어요.

그 과정에서 다양한 프로젝트를 진행했고, 문제를 빠르고 효율적으로 해결하기 위해 오픈소스를 많이 활용하게 됐습니다.
결과적으로 오픈소스를 적극적으로 도입하면서, 확장성과 생산성을 동시에 잡을 수 있었던 점이 큰 도움이 됐어요.

저는 오픈소스에 기여하는 이유가 제 필요 때문인 것 같아요! 🤔
일하다 보면, 이 기능이 정말 편리한데, 조금 부족한 부분이 있을 때가 있잖아요?
그럴 때 부족한 부분을 채우기 위해 기여하게 되는 것 같아요.

예를 들어, A 기능에 B가 추가되어 있으면 훨씬 편할 텐데, B가 누락되어 있으면 직접 구현해서 기여하는 방식이에요.
한 번은 플러터(Flutter)에서 드롭다운 리스트를 만들어야 했는데, 디자인 요구사항상 “버튼을 클릭한 후, 살짝 떼면 드롭다운이 보여야 한다”라는 기능이 필요했어요. 하지만 기본 기능으로는 지원되지 않더라고요. 😥

결국 새로 드롭다운 기능을 구현할 수밖에 없었고, 그 과정을 이슈(issue)로 정리해서 “이런 기능이 필요한데, 혹시 관심 있는 분 있나요?” 하고 제안했어요. 이런 식으로 대화를 주고받으며 기여한 경험이 많았어요.

기능을 제안하고 PR을 제출하신 병진님

주로 기여하는 오픈소스가 따로 정해져 있진 않아요. 저는 프로젝트를 진행할 때 필요한 부분에서 기여를 하는 편이에요!

예를 들어, 자바스크립트 쪽에서는 패브릭(FabricJS)^! 라이브러리를 사용했었어요. 이 라이브러리는 캔버스(Canvas)를 좀 더 편하게 다룰 수 있게 해주는데, 당시 제가 진행하던 프로젝트에서는 캔버스 기능을 정말 많이 활용해야 했거든요. 🎨 그 과정에서 타입스크립트(Typescript)와 관련된 기능 기획이 필요해졌고, 부족한 부분을 채워나가면서 자연스럽게 기여로 이어졌습니다.

지금은 AI 쪽에 집중하다 보니, 관련된 프레임워크를 찾아보면서 필요한 기능이나 개선할 점이 있으면 기여하고 있어요.
필요한 게 있을 때마다, 그런 부분을 찾아서 기여하는 방식이에요. 🚀

기술적인 챌린지보다는, 컨트리뷰터들의 답장이 느릴 때가 가장 어렵더라고요. 😅
저는 빨리 머지(Merge)해서 프로젝트에 반영하고 싶은데, 답변이 늦으면 아무래도 계속 기다려야 하니까요.
특히 해외 커뮤니티의 경우엔 시차가 있어서, 최소 12시간은 기본이고 3~4일씩 걸리는 경우도 종종 있거든요.

최근에 플러터(Flutter) 프로젝트에 기여했을 때도 유사한 경험이 있었어요.
플러터 팀은 전 세계적으로 분포되어 있어서 미국, 독일 등 다양한 국가에 계신 분들이 함께 작업하시더라고요.
그런데 해당 팀 정책상 두 명이 리뷰를 해야 머지가 되는데, 한 명의 리뷰를 받았지만 두 번째 리뷰어의 답변이 늦어져서, 지난달에 릴리즈가 되었어요. 😥

가장 인상 깊었던 순간을 꼽으라면, 테스트 코드 수정 요청을 받았을 때인 거 같아요.
왜냐하면 보통 PR을 올릴 때 CI 테스트가 전부 통과하면 머지까지 이어지잖아요.
그런데, 막상 컨트리뷰터들과 커뮤니케이션을 시작해보면, 더욱 세밀한 요구사항이 나오기도 하거든요.

게다가 메인테이너 A와 B의 의견이 서로 다를 때도 있어요.
어떤 분은 “더 많은 상황을 커버해야 한다”고 주장하고, 다른 분은 “이미 충분히 커버된 것 같다”고 느낄 수도 있잖아요.
그럴 때는 제가 “이런 테스트로도 작업이 충분히 검증되지 않을까요?” 하고 제 의견을 말씀드리면서
서로 조율하는 과정을 거치게 되는데, 바로 그 순간들이 가장 기억에 남아요.

결과적으로는 “이 사람들은 이 부분에 왜 이렇게 중요성을 두는지”
또 “내가 생각했던 방향과 뭐가 다른지” 서로 이해해가는 시간이 되어서 좋았던 것 같아요.

저는 코드의 품질과 유지보수성을 위해서, 메인테이너가 제시하는 컨벤션(Convention)을 최대한 잘 지키려고 노력해요.

그래서 PR을 올리기 전에, 이슈(Issue) 영역에서 미리 커뮤니케이션을 많이 해두는 편이에요.
“이렇게 구현해보려고 하는데, 괜찮을까요?” 같은 식으로 대화를 충분히 나눈 뒤에, 최종적으로 확신이 들면 그때 PR을 올려요.
왜냐하면 말씀드린 것처럼, 한 번 PR을 올리고 나면 소통하는 데 시간이 오래 걸리기도 하거든요.

또, PR을 올리고 나서 코드 수정을 하게 되면, CI 테스트나 코드 체크를 다시 통과해야 하는데,
예를 들어 플러터(Flutter) 같은 경우는 체크해야 할 항목이 70~80개 정도나 되거든요.
다시 수정하고 검증하려면 그만큼 시간이 더 걸릴 수밖에 없어요.

커밋시 70개 이상의 체크를 진행하는 flutter

그래서 가능한 한 이슈에서 방향을 먼저 정하고, 그다음에 PR을 올리는 방식을 취하고 있습니다.
결국 이렇게 기여하는 오픈소스들은 규모도 크고 영향 범위도 넓은 프로젝트들이 많잖아요. 그래서 더욱 더 꼼꼼히 신경 써야 한다고 생각해요.

저에게 기여란, 맡은 프로젝트를 안정적으로 운영하는 게 목적이라고 볼 수 있어요! 🚀
결국 엔지니어는 문제를 해결하는 사람이니까, 내가 문제를 해결하는 데 어떤 수단을 쓰느냐는 그다지 중요한 차이가 아닌 것 같아요.
중요한 건 해결하는 방법보다는 문제를 해결하는 과정이라고 생각해요 😊.

저는 번역 작업이 좋은 시작이 될 수 있을 것 같아요.
번역은 비교적 접근성이 좋아서, 오픈소스에 기여하는 첫 걸음으로 적합하다고 생각해요.

또, 제가 경험한 것처럼, 본인이 당면한 문제를 해결하기 위해 직접 기여를 시도해보는 것도 좋은 방법이에요.
실제로 생각보다 어렵지 않게 시작할 수 있고, 문제를 해결하는 과정에서 많은 배울 점이 있을 거예요.
그래서 이런 방식도 충분히 좋은 선택이 될 수 있다고 생각합니다.

안녕하세요 🙂 저는 현재 6년 차 프론트엔드 개발자 이상철입니다. 지금은 우아한 형제들에서 즐겁게 개발하고 있어요.
제 커리어는 서버 개발자로 시작했는데, 그 당시 서버를 Node.js로 작업하면서 자바스크립트에 흥미를 가지게 되었어요.

그래서 자연스럽게 프론트엔드 개발자로 전향하게 되었답니다. 평소에 오픈소스에도 많은 관심을 가지고 있었고,
특히 Node.js가 오픈소스에 큰 영향을 미쳤다는 점에서 더 큰 관심을 가지게 된 것 같아요

처음 오픈소스를 시작할 때는 사실 많이 어려웠어요 😅. 특히 프로젝트 규모가 커서 어디서부터 시작해야 할지 막막했죠.
그러던 중 이전 회사에서 웹팩의 한글화를 진행하게 되었고, 어깨너머로 조금씩 참여하게 되었어요.
그 과정에서 오픈소스 번역 작업에 기여하게 된 거죠. 또, 그 회사에서는 '오픈소스 스프린트'라는 활동이 있었는데,
거기서 MDN에 기여할 기회가 생겼어요.

그 회사에 MDN의 메인테이너^!가 계셔서 그분의 도움으로 첫 기여를 할 수 있었고,
그 경험 덕분에 두 번째부터는 훨씬 수월하다는 걸 알게 되었어요 😊. 첫 발을 내딛는 데 도움을 주셔서 그 이후로 혼자서도 꾸준히 기여할 수 있었고, 지금은 MDN 한국 오거나이저로 활동하게 되었습니다 🚀.

MDN 한국 멤버로 활동 중인 상철님

오픈소스 번역 작업을 하다 보면, 기여자들이 용례나 문서 관리 방법에 대해 궁금해하는 경우가 많아요 🤔.
예를 들어, '이터레이터'라는 단어를 어떻게 번역할지 고민될 때가 있죠. '반복자'라고 해야 할지, '순회자'가 맞는지, 아니면 그냥 '순회'라고 해야 할지 정말 어려워요.

저는 테크니컬 라이터^!가 아니라 개발자니까, 이런 표현을 정하는 게 항상 어려웠어요.
그래서 이 부분에 대한 가이드를 만드는 과정이 꽤 고충이 있었죠. 다행히 제가 MDN에 합류할 때는 이미 어느 정도 가이드라인이 정해져 있었어요. 한 예로 '국어 국립 한국어 의문 규범'을 따르기도 해요.

MDN 한국어 번역 가이드라인 예시

그런데, 정해진 규칙을 따르더라도 때때로 '이건 정말 이상하다'라고 느낄 때가 있어요.
그런 경우에는 퍼블릭 한 이슈로 등록해서 공개적으로 논의를 시작하죠. 이렇게 공개 논의를 통해 최종 결정을 내리게 되면,
그 결정이 이후 번역 작업에 영향을 주기 때문에 그 과정 자체가 가장 어려운 부분이었던 것 같아요 😅.

제가 MDN의 메인테이너로 합류하게 된 과정이 가장 기억에 남아요 😊.
처음 MDN 합류 제의를 받았을 때, 온보딩 과정을 거쳤는데, 그 과정이 공개 이슈로 진행되었어요.
그래서 어떤 사람이 메인테이너가 될 건지, 그 사람이 어떤 과제를 할지, 모두가 지켜볼 수 있었죠.

팀에 합류하게 된 모습

이렇게 모든 과정이 투명하게 진행되는 모습이 정말 인상 깊었어요.
그래서 제가 어떻게 MDN에 합류하게 되었는지, 그 모든 과정은 누구나 볼 수 있어요.
그만큼 오픈소스의 투명함을 직접 느낄 수 있었고, 특히 단어에 대한 논의나 이슈화가 모두 공개적으로 이루어지는 과정이 정말 오픈소스답다고 생각했어요. 이 과정이 정말 인상 깊었고, 제게는 많은 의미가 있는 순간이었어요 ✨

번역 프로젝트는 초심자분들이 기여하기에 정말 좋은 오픈소스 프로젝트예요.
그래서 MDN뿐만 아니라 다른 생태계에도 기여할 수 있도록 돕는 데 큰 의미가 있다고 생각합니다 😊.
첫 PR을 제출하는 순간은 누구에게나 설레고 긴장되는 순간이죠. 저도 첫 PR을 올릴 때 느꼈던 두근거림과 기대감을 아직도 잊을 수 없어요.

그래서 리뷰 과정에서는 기여자들이 긍정적인 경험을 할 수 있도록 따뜻한 피드백을 주려고 노력하고 있어요.
특히 번역 프로젝트에 처음 기여하는 분들께는 친절한 가이드를 제공하고, 이모지 하나를 더 쓰거나 따뜻한 말을 한마디 덧붙이는 등 작은 배려로 기여자들이 더 큰 동기부여를 받을 수 있도록 신경 쓰고 있답니다 ✨.

일을 할 때도 마찬가지지만, 저는 커뮤니케이션이 가장 중요하다고 생각해요 😊.
결국 이 모든 일이 사람들 간의 협업이기 때문에, 서로 간의 태도가 가장 중요한 것 같아요.
그래서 좋은 커뮤니케이션과 소프트 스킬을 갖추는 것이 정말 중요하다고 느껴요.

저는 이 일이 꽤 재미있다고 느껴요 😊. 특히 초심자분들이 많다고 했잖아요.
그런 분들을 돕는 역할을 하면서 뭔가 사회적 환원을 한다는 자부심도 느끼고요. 사명감까지는 아니지만,
재미를 가지고 이 일을 잘 해나갈 수 있는 힘이 되는 것 같아요.

또, 문서를 계속 읽다 보니 제가 세 줄 요약이 정말 잘 되어 있었는데,
긴 문서를 읽을 때도 참을성 있게 집중할 수 있는 능력이 많이 향상된 것 같아요 📚.

하나의 웹 문서를 만들기 위해 어떤 작업들이 뒷단에서 이루어지는지 알게 되었고, 그 덕분에 웹 문서의 변화와 트렌드를 모두 지켜볼 수 있게 됐어요 🌐. 예전에는 MDN이 나무위키처럼 바로 수정할 수 있는 형태였는데, 그때는 관리가 잘 되지 않았어요.

이제는 PR(풀 리퀘스트) 방식으로 바뀌면서, 온전한 중앙 집중식 관리 체계로 발전했어요. 그리고 문서의 기반을 만들 때 '야리'라는 타입스크립트로 작업했죠. 최근에는 '야리'가 아니라 러스트로 리라이트하는 방향으로 가고 있는데, 트렌드에 맞춰 점차 바뀌고 있어요 🔄.
이런 변화들을 보면서, 저도 자연스럽게 '앞으로 뭘 해야 할까?' 또는 '저런 부분에 기여해 보고 싶다'는 자극을 계속 받게 되는 것 같아요.