회고를 쓴다면 '개발자는 글이 아니라 코드로 말한다'며 github 링크 한 줄만 올리는 상상을 했는데, 역시 그러기엔 할 말이 많다. 쓰다보면 너무 길어질 것 같아서 공백 포함 만자 내외로 맞추겠다는 다짐을 하며 글을 시작해본다.
무엇을 했는가?
당근에서 프론트엔드코어팀이자 Lynx tf로써 lynx 개발을 했다.
Lynx란?
아마 이 글을 읽는 대부분의 사람은 Lynx가 무엇인지 모를 것이다. 간단하게 말하자면, 틱톡을 만든 회사인 ByteDance가 만든 React 기반 모바일 앱 개발 프레임워크이다.
(더 자세한 정보를 알고 싶다면, 이전에 업로드한 Lynx란 무엇인가? 게시글을 참고하길 바란다.)
긱뉴스 링크도 첨부
https://news.hada.io/topic?id=19688
Lynx - 웹 기술 기반 네이티브 앱 개발 도구 | GeekNews
틱톡(ByteDance)이 만든 더 빠르고 부드러운 React Native 대체제Lynx는 웹 기술을 사용해 네이티브 UI를 생성할 수 있도록 돕는 기술 패밀리하나의 코드베이스에서 모바일과 웹등 다양한 플랫폼에 대응
news.hada.io
당근에는 많은 서비스가 웹뷰로 구현되어 있다. 웹뷰는 빠르게 개발하고 빠르게 배포할 수 있지만 속도가 느리고 네이티브에 가까운 경험을 제공하기 어렵다는 단점이 있다.
이런 문제를 해결하기 위해 웹뷰와 비슷하게 빠르게 개발하고 배포하지만, 빌드 시 네이티브가 이해할 수 있는 번들이 되어 네이티브에 가깝게 동작하는 Lynx를 도입하게 되었다.
입사 후 '당근에 Lynx를 도입한다'라는 일을 맡게 되었고, Lynx로 서비스 페이지도 만들고 Lynx 개발의 불편한 점을 해결할 수 있는 패키지도 만들었다.
Lynx console
https://github.com/daangn/lynx-console
GitHub - daangn/lynx-console
Contribute to daangn/lynx-console development by creating an account on GitHub.
github.com
온보딩 과제로 Lynx console을 만들었다. 당근에서는 모바일에서 웹뷰의 콘솔 로그, 네트워크 요청 등을 디버깅하기 위해 vConsole이라는 디버깅 도구를 사용하는데, lynx는 아직 생태계가 작아 이런 모바일용 디버깅 도구가 존재하지 않았다. 그래서 lynx용 디버깅 도구인 lynx-console을 만들었다.
콘솔 로그와 네트워크 요청을 모두 하이재킹 하려면 어떻게 설계해야 할까? vConsole의 구현 방식을 보고 많이 고민했다.
lynx-console이 "vConsole의 lynx 버전"인게 아니라 vConsole이 "lynx-console의 웹뷰 버전"이 되었으면 해서 UX에 상당히 공을 들였는데, 다른 팀 프론트엔드 엔지니어에게 내가 만든 lynx-console이 vConsole보다 보기 편하다는 말을 들었을 때 무척 기뻤다. (기뻐서 다이어리에도 써놨다. 사실.... vConsole을 압도적으로 이기고 싶었다)
Lynx 개발을 하며 힘들었던 점 중 첫번째는 '레퍼런스가 없다'는 점이었다. 구글에 lynx를 검색해보면 알겠지만 적어도 국내에선 아무도 Lynx로 개발을 하지 않는다. 공식 문서도 업데이트 되지 않은 부분이 많고 코드에만 있고 문서에는 아예 없는 내용도 많다. 나는 이때까지 문서를 믿고 의지하며 살아왔는데 이제 문서를 불신하게 되었고 글이 아니라 라이브러리의 살아있는 코드만을 믿으며 살게 되었다. 그런데 이렇게 문서 없이 코드를 믿고 개발하다보니 점점 레퍼런스가 필요하지 않게 되었다 (!) 나름 성장?이라면 성장하게 된 점.
두번째로는, Lynx는 메인 스레드와 백그라운드 스레드가 분리되어 있는데 메인 스레드에서 발생한 에러는 에러메시지가 부정확해서 디버깅이 힘들다는 점이다. (그치만 이 메인스레드의 존재가 Lynx의 엄청난 매력이라고 생각한다.) 그리고 이것도 비슷한 에러메시지를 몇번 보다 보니 __SnapShot__에서 에러난다고 뜨는 걸 보니 어디서 뭐가 빠져있을 확률이 높겠군... 하고 때려 맞추기가 가능해졌다.
아무도 걸어보지 않은 길을 걷는 것. 어려워 보이지만 나름 할 만하다. 그리고 꽤 재미있기도 하다.
Lynx 개발은 황무지를 개척하고 아무도 밟지 않는 눈밭을 밟는 일과 비슷하다. 막막해보일 수도 있겠지만 나는 조금 설렜던 것 같다.
웹뷰/Lynx 실험 진행
그 다음으로 했던 일은 당근 내의 중고거래 서비스 중 한 페이지를 Lynx로 만든 다음 웹뷰와 A/B 테스트를 진행해서 웹뷰에 비해 정말 괜찮은 지표가 나오는지 확인하는 일이었다.

Lynx로 UI 작업부터 시작해서 api 연동도 하고, 이벤트 로깅도 하고, 배포하고, QA도 하고, 실험 지표 확인하고 지표가 이상하면 왜 이상한지 확인하고 수정하고 이슈 대응도 했다... 이슈 대응하느라 새벽 1시에 퇴근해보기도 하고... (함께 남아서 도와준 최고의 버디 아나킨에게 고마운 마음이 있다.)
당근의 대부분의 서비스는 당근의 디자인시스템인 seed-design을 이용해서 구현되는데, lynx용 seed-design은 존재하지 않았으므로 최대한 유사하게 (비공식) 디자인시스템 컴포넌트를 만드는 일도 했다. 공식 디자인시스템 컴포넌트가 나왔을 때 import 문만 바꾸면 되도록 인터페이스를 맞추려고 seed-design 레포지토리를 엄청 들여다보고 분석했는데 도움이 많이 된 것 같다.
뭐가 안되는데 어떻게 확인해야하는지도 모르겠고 뭐가 문제인지도 모르겠고 혼란스러운 상황이 많았다. 그럴 때 마다 늘 그런 생각을 했다. 힘들고 못하겠다고 나에게 주어진 내 일을 다른 사람한테 대신 해달라고 할 것인가? 토니가 생각했을 때 나 혼자 할 수 있는 일이라고 생각했으니까 나에게 맡겼겠지? 나를 믿어준 토니를 믿으며 어떻게든 한 것 같다. 우리 팀원들과 다른 팀 사람들에게 도움 요청을 많이 했고 다들 많이 도와주셔서 무사히 프로덕션 배포까지 나갔다.
당근에는 Lynx 개발자가 토니 외에는 나밖에 없었다. 토니가 없으면 내가 해야만 한다. 내가 쓴 내 코드기도 하고...
레퍼런스도 없고 ai도 해결하지 못하는 버그를 많이 마주치다 보니 이걸 시간 내에 할 수 있을까? 라는 걱정이 아니라 이게 가능한긴 한가? 라는 걱정이 더 잦았다. 그러나 내 힘으로 해내고 싶었고 불안하고 무섭지만 그래서 더 재밌었다.
Lynx가 살아남기
내가 당근에서 살아남는 것은 둘째치고 어떻게 하면 Lynx가 당근에서 잘 살아남을 수 있을까에 대해 생각했다.
당근의 프론트엔드 코어팀은 프론트엔드 개발자들이 쉽고 빠르게 개발할 수 있도록 도로를 깔아주는 일을 한다. 프론트엔드 코어팀이자 Lynx tf로써 사람들이 당근에서 Lynx 개발을 쉽게 할 수 있도록 도로를 깔아주고 싶었다. 사내에서 Lynx 개발을 하는 사람이 1명이라도 더 생겼으면 했고, 생긴다면 열심히 도와서 부스터를 달아주고 싶었다.
미팅 때 "플랫폼 개발이 있는 이유"라는 말을 듣고 그에 대해서도 생각을 많이 했다.

Lynx 개발을 하며 불편한 점이 무엇인지 생각했고, 그런 불편함을 해결할 수 있는 패키지와 플러그인을 만들었다. Lynx 개발을 하고싶다는 사람이 나타난다면 바로 프로젝트를 세팅할 수 있게 내가 만든 패키지들을 미리 세팅해둔 앱 스캐폴딩(create-react-app 같은거)도 만들었다. (그러나 안타깝게도 Lynx 개발을 하고 싶다는 사람이 먼저 나타나지는 않았기에, Lynx 써보라고 발표도 하고 다른 미팅에 꼽껴서 영업도 했다....)
왜 Lynx로 개발하고 싶지 않은지, 무엇이 힘든지에 대해서도 이야기를 많이 들었고, 그 문제를 해결하기 위해 이런저런 노력을 했다. lynx 디자인 시스템이 없어서 힘들 것 같다는 말을 제일 많이 들었기 때문에 디자인 시스템 팀과 미팅도 하고 레포지토리에 PR도 올렸다...
Lynx 개발을 하면 할 수록 성능도 잘 나오고 재미도 있고 매력적인 기술이라는 생각이 들어서 다른 사람들도 이 매력을 느꼈으면 했다. 그래서 더 열심히 했던 것 같다. ㅋㅋ
여기선 아무도 지나를 인턴이라고 생각하지 않아요
입사 첫날 토니에게 들은 말이다.
Q: 제게 주어진 과제가 인턴에게 맡기기에 어렵고 중요한 일 같은데... 저같은 인턴에게 맡기는 이유가 있나요?
A: 여기선 아무도 지나를 인턴이라고 생각하지 않아요. (중략) 그리고 솔직히 저는 그렇게 어렵지 않다고 생각해요 ㅋㅋ
아하! 내 과제는 어렵지 않은 일이구나. 어려워 보이지만 하면 되겠지. 그렇게 믿어왔다. 몇 달 후 다른 팀 프론트엔드 엔지니어에게 "너무 어려운 일을 인턴에게 맡긴다고 생각했어요"라는 말을 듣기 전까지는...
플라시보 효과일까? 어렵지 않다고 믿었더니 어렵지 않았다. 솔직히 조금 어렵긴 했지만 너무너무 어렵고 힘들어서 못할 정도는 아니었다. 그리고 아무도 나를 인턴이라고 생각하지 않는다 믿었더니 그만큼 더 힘이 났다. 나는 코어팀의 인턴 지나가 아니라 코어팀에서 Lynx를 담당하는 지나라는 생각으로 살았다. 책임이 생기니까 더 열심히 하게 됐고, 일이 더 즐거워졌다. 🎵
미팅 때 곧 퇴사한다고 이야기하자 "지나 없으면 Lynx는 누가 해요?"라는 말을 들었다. 원래라면 다들 당연히 토니가 한다고 생각했을 텐데... 나름 Lynx 개발자로서 신뢰가 있으니까 나를 먼저 찾아주나보다 싶어 뿌듯했던 기억이 있다.
입사 첫 날에는 "대한민국에서 Lynx를 제일 잘하는 사람이 되어야겠다"고 다짐했고 퇴사 날이 가까워질 수록 "프론트엔드 챕터의 모두가 코어 팀에서 Lynx를 개발하는 지나를 알았으면 좋겠다"고 생각했다. Lynx를 제일 잘하진 못해도 Lynx에 대해 궁금한게 생기면 물어볼 수 있는 사람은 된 것 같다. 프론트엔드 챕터의 모두가 나를 알진 못해도 Lynx에 관심있는 사람이라면 다 나를 알지 않았을까? ㅋㅋ
내 좌우명은 "절대 후회하지 말자"이다. 그래서 나중에 후회하지 않도록 매 순간 최선을 다했다. 야근을 안 한 날이 손에 꼽았다. 그럼에도 후회가 남긴 한다. 누군가 Lynx에서 이거 돼요? 라고 물어봤을 때 좀 더 확실히 알고 대답해야 했는데... 이런 것들. 코드 퀄리티도 아쉽다. 그만큼 배운 것도 많다. 쓰는 기술에 대해 정확하게 알아야 한다는 것. 코드를 쓸 때 자아를 넣을 부분과 뺄 부분을 구분하기. 고민하지 않아도 될 부분은 빠르게 실행하고 고민 해야할 부분을 더 고민하기. 등등...

즐거웠던 일도 많다. 저녁먹고 다같이 태고의 달인을 했던 것도 즐거웠고, 팀원들이 졸업식 날에 몰래 현수막을 걸어줬던 일도 기억에 남는다. 아침에 다같이 소금빵을 하나씩 먹으면서 티타임 했던 것도 즐거웠다. 다른 팀 프론트엔드 엔지니어와 원온원하며 행복이란 무엇일까?에 대해 생각해보기도 했다. 열심히 만든 lynx-console을 daangn org에 오픈소싱 한 날도 엄청 기뻤었다.
나 자신에 대해서
나 자신에 대해서도 많이 알게 됐다.
제품 퀄리티에 대한 집착이 있다는 것과, 남들이 어려워하는 일도 크게 어렵다고 생각하지 않고 그냥 한다는 것? 겁이 없는 편이다. 대체로 아래 사진 속 '겁없는 쥐'와 비슷한 상태로 살아온 것 같다. 하면 된다!

프로덕션 배포가 나간 후에 많은 사람들이 어려운 일을 잘 해냈다며 축하해주었다. 그러나 그 많은 사람들이 도와주지 않았다면 불가능했을 것이다. 해결하기 어려운 버그가 있으면 자신의 일인 것 처럼 함께 디버깅하고 도와준 프론트엔드코어 팀원들, 뭐가 안된다고 멘션하면 연휴에도 확인하고 바로 고쳐준 Lynx tf 모바일 엔지니어들, 타이트한 일정에도 실험을 진행해주고 문제가 있으면 함께 분석해준 중고거래실 팀원들...
많이 감사했고, 많이 배웠다. 그리고 재밌었다!

'회고' 카테고리의 다른 글
| 입사 1.5개월차 기록 (0) | 2026.06.01 |
|---|---|
| 2025 연말 회고 (3) | 2026.01.05 |
| 인생의 타임라인 (0) | 2025.09.23 |
| 2025년 상반기를 마무리하며... (0) | 2025.06.08 |
| 6개월 간의 프론트엔드 현장실습 인턴 회고 (0) | 2024.12.17 |