현우, 아카이브

해당 게시글은 제가 읽고 싶은 게시글을 모아놓은 공간으로, 고정 게시물 형태로 계속 업데이트 됩니다. 커리어 프론트엔드 개발자는 연봉 많이 받기 어려운가요? AI 버블 시대 코드를 읽거나 설명할 줄 몰라도, 스펙을 만족하고 버그를 고칠 수 있다면 상관없을까 프론트엔드 React Compiler 딥다이브: 원리부터 결과물까지 :

정리 당근 조직에서는 광고, 모임 등의 기능에서 비즈니스적인 요소들을 어떻게 풀어냈는가에 대한 내용으로 컨퍼런스를 풀어냈습니다. 당근은 기업이 현재 많이 성장했지만, 아직도 기능 단위의 스타트업처럼 발빠르게 움직이고 있었고 기업 자체의 정책이 아니라 그 팀의 정책과 문화를 설립하여 유닛 단위로 움직이는 것처럼 느껴졌습니다. 그래서 각자의 팀은 개별 서비스를 스타트업 SEED 단계처럼 A, B, C, D 등의 레벨 (ex. 중고 마켓은 안정적인 단계라고 판단하여 ‘D’) 매기고 기능을 성장시키기 위한 여러 도전들을 하고 있는 것이 보였습니다. 조금 인상깊게 보았던 부분은 신규로 구성된 팀이 PM이 없는 경우가 종종 있었습니다. 모두가 ‘빌더‘ 라는 명목하에 프로덕트 엔지니어로 AI를 활용하여 직군 간의 경계를 넘나들며 실제로 각자가 문제 해결을 위해 서비스의 대표처럼 움직이는 듯한 느낌이 들었습니다. (팀원 모두가 가설을 세우고 문제 검증부터, 기획, 디자인, 개발까지 모든 과정을 진행) 컨퍼런스에 운이 좋게 타 회사에서 아는 사람들이 많이 왔는데, AX를 진행하는 대부분의 기업들은 프로덕트 엔지니와 플랫폼 엔지니어를 기반으로 나눠지고 있었습니다. (프로덕트 엔지니어는 서비스의 전반적인 개발을 진행한다면, 플랫폼 엔지니어는 이를 위한 웹뷰 브릿지, 인프라 환경 기반들을 구축하는 역할을 담당합니다) 공감되는 내용들이 정말 많았고, 문제에 직접 직면하며 비로소 문제를 잘 해결할 수 있다는 이야기들이 정말 많이 와닿았습니다. 당근은 신규 기능들을 만들면서도 계속해서 실험하는 조직이었습니다. (오늘의 뉴스처럼, 사이드프로젝트를 진행하며 과감하게 사이드 프로젝트를 서비스 앱 내에 삽입하기도 합니다) 실패도 실패가 아니라고 하는 당근의 문화처럼, 발 빠르게 수용하고, 반영되고 움직이는 조직의 수평적 문화도 정말 중요하다는 것을 이번 컨퍼런스를 통해 깨닫게 되었던 좋은 순간이었습니다. 당근 포인트, PM 없이 성장하기 당근 페이팀에서 진행한 발표로 당근 페이팀은 PM이 따로 존재하지 않습니다.

엊그제가 2026년의 시작이었는데 벌써 7월 말을 달리고 있다. 평범한 일상을 보냈고, 여러 열정적인 일들도 마무리가 되었다. 어떻게 보내왔는지 기억이 가물가물한 상반기였지만, 분명했던 것은 여러 마리의 토끼들을 잡으려다가 모두 놓친 것 같은 느낌이다. 사실 상반기에는 커리어적인 고민들이 정말 많았다. 안랩에서 곧 3년, 주임 연구원 안랩에서 시간이 생각보다 빨리간다. 처음에는 조직 내에서 조금 수직적인 분위기로 구성되어있어 적응을 잘 못하고 있다고 생각을 했는데, 인간이 적응의 동물이라는 말이 공감이 가듯 어느새 나도 조직 내에서 부드럽게 융화되고 있었다. 여러 일들을 하고나니까, 벌써 안랩에서만 곧 3년의 시간이 흐르게 된다. 나도 내년이면 주임 연구원이라는 뜻이다. (진짜 시간 빠르다,,) 조직 내에서 무언가를 많이 하려고, 조금 많이 나댔다. "타입 때문에 휴먼 에러가 발생해? → 타입스크립트 도입해", "컴포넌트 추상화가 안되어있어? → 디자인 시스템 도입해" 와 같이 조직 내에 불편한 점들을 개선하려고 노력했다. 그리고 무작정 적용한 기술들에 대해서 회의실을 잡고 리뷰를 하는 등의 많은 나대는(?) 과정들을 진행했다. 그 결과로 정말 많이 바뀌었다. 조직 내에서 신기술을 수용하는 과정들이 전보다 훨씬 부드러워졌고, 신기술을 적용할만한 이유가 타당하다면 조직 내에서는 적극적으로 도입하는 분위기가 되었다. (사실 처음에 보수적인 개발 문화가 형성되어있는 것 같아 개발을 할 때마다 너무 힘들었다) 현재는 백오피스 프론트엔드의 전반적인 부분들을 바꾸면서, 리뉴얼을 힘차게 진행하고 있다. 팀장님에게 인정받아 프론트엔드의 기획과 UX적인 부분들, 그리고 프론트엔드의 전반적인 의사결정권을 얻을 수 있게 되었다. 디자인 시스템 도입부터, 코드 베이스 변경, 전반적인 디자인 톤 변경까지 내가 들어오고나서 백오피스가 정말 많이 좋은 쪽으로 변했다는 칭찬을 들었다. 내년에는 3년이 될 예정이고, 주임 연구원으로 팀 내에 더 선한 영향력을 전파해보고 싶다. 안정적인 환경 vs 도전적인 커리어

사이드 프로젝트를 진행하다보면 신규 팀원이 들어오는 경우에는 환경변수 파일에 대한 내용을 공유한다. 그런데 사실 이미 개발을 진행하다보면, 프로젝트가 점점 커지면서 어떤 환경변수가 구성되어있는지 잘 모르는 경우도 있고, 만약 누군가 새로운 환경변수를 추가한 경우에는 다른 사람에게 알림을 주지 않는 이상 잘 모르고 넘어간다. 그런데 여기서 문제는.. 나중에 빌드 상황에서 누락된 환경변수로 인해 빌드 에러가 발생하거나, 환경변수 히스토리가 누락된 경우에는 어떤 환경 변수가 있었는지에 대한 추적이 불가능하다. 여기서 매번 .env 파일을 공유하다 문득 궁금한 점이 생겼다. "환경 변수를 이렇게 매번 파일로 공유하고, 매번 메신저로 공유해줘야하나?" 클라우드 환경에서 환경변수 가져오기 보통 .env 의 경우에는 파일 내에 정적 정보로 저장된다. 그래서 .env 는 외부로 유출되면 절대적으로 안되며, 정말 중요한 정보들이 들어가는 경우가 많다. 또 실수로 환경변수가 공개된 저장소에 올라가게되면, 잠깐의 찰나라도 공격당하는 경우가 있을 수 있다. (여기서 공격 당하는 경우라고 하면, 중요한 내부 키가 탈취당해 과금이 나오는 경우 ^,^ ..) 그래서 이러한 환경변수들을 클라우드 환경에서 업데이트될 때마다 내려받고, 더이상 개발자는 환경변수가 어떤 것들이 비어져있고, 담당자는 누구인지를 체킹하지 않아도 되는 번거로움을 없앨 수 있다. dotenv-vault로 환경 변수 컨트롤하기 가장 단순하면서 환경변수 파일을 가장 쉽게 관리할 수 있는 오픈소스 솔루션이다. 기존의 .env 워크 플로우를 유지하면서 암호화된 .env.vault파일만을 git 에 올리는 방식이다. 변경사항은 팀원이 pull 을 하면 항상 반영되며 도입 시에 가장 진입 장벽이 낮다. 가장 빠르게 적용 가능하면서, 팀원들이 혼동하지 않도록 하는 방식이 제일 효율적이었다. doppler와 같은 다른 솔루션의 경우에는 권한에 따른 환경변수 부여도 가능하지만, 내가 진행하는 사이드 프로젝트에서는 개발자 모두가 동등한 권한을 가지고 개발을 진행하는 것이기에 dotenv-valut 로 불편한 점들을 먼저 해결하고, 추가적으로 필요할 때 고려해보고자 했다.

최근에 전직장 멘토님과 이야기를 하면서, 전 직장에 AI 플로우가 도입되고 있다는 것을 알게되었다. 이야기 중에 PRD(Product Requirements)와 WRD(Work Requirement Document)를 먼저 정의해놓고 개발을 진행하신다는 이야기를 듣게 되면서, PRD와 WRD가 대체 무엇인지 그리고 이 두가지 문서를 사용하게 되면 어떤 이점들이 있는지 알아보고자 한다. 처음엔 에이전트에게 "기능 만들어줘"라고 입력하는 것으로만 기능 구현을 할 수 있었지만, 프로젝트가 커질수록 담고있어야하는 컨텍스트 크기 뿐만 아니라 기능에 대한 정의가 이전 대화 기록으로 남아있어 사용자는 기억하기 쉽지 않았다. 만약 컨텍스트가 초기화되면 이전 요청한 기능들을 다시 기억하게 해줘야하는 순간들도 생각보다 많다 ^,^.. AI가 앞에서 했던 맥락을 잊어버리거나, 같은 기능을 요청했는데 매번 다른 구조로 짜주거나, 토큰이 터져서 대화 자체가 중단되는 순간들도 빈번하다. AI 기반 개발 방식이 자리를 잡으면서, 프롬프트 한 줄로 코드를 생성하는 것 이상의 체계가 필요해졌다. 그 중심에 PRD(Product Requirements Document)와 WRD(Work Requirement Document)를 먼저 작성하고, 이를 기반으로 AI가 구현하게 만드는 흐름, 일명 "플로우(Flow)" 방식이 있다. 왜 이 방식이 사용되고 있을까? AI 코딩 도구가 처음 나왔을 때, 대부분의 사용법은 단순했다. 프롬프트로 함수 하나를 만들고, 수정하고, 반복하는 식이었다. 그런데 GPT-4 급의 모델이 대화 컨텍스트를 길게 유지하면서 더 복잡한 작업을 하게 되자, 기존 방식의 한계가 드러났다. AI에게 프로젝트 전체를 설명하려면 대화 초반부터 엄청난 토큰을 소모하게 된다. 매 세션마다 같은 배경을 반복 설명해야 하고, 맥락이 흐릿한 상태에서 생성된 코드는 전체 구조와 맞지 않는 경우가 많다. 그 대안으로 나온 것이 문서를 먼저 작성하고, 그 문서를 AI의 참고 자료로 삼는 방식이다. 소프트웨어 개발에서 PM이 작성하던 PRD의 개념을 AI 개발 워크플로우에 끌어들인 것이다. WRD는 그보다 한 단계 더 내려가서, 실제로 어떤 기능들을 만들 것인지를 정리한 문서다.

입사 후에도 사이드 프로젝트를 하실건가요? 면접에서 수차례 받았던 질문이다. 이에 따른 대답은 "YES".. 면접관들의 질문은 그저 궁금한 질문일 수 있었으나, 사이드 프로젝트가 업무 몰입에 방해가 될 수도 있다는 의도로 질문을 했던 면접관도 분명 있을 것이다. 하지만 나는 계속 내가 운영하는 프로덕트들을 그로스할 것이다. 왜냐하면 현업에서 겪지 못하는 것들을 사이드 프로젝트에서 겪을 수 있으니까 사이드 프로젝트의 첫 시작, 무작정 웹 개발 시작하기 나는 사실 창업에 관심이 많은 학생이었다, 2017년에 학교를 입학해서 무작정 웹 개발 동아리에 들어가서 Ruby on Rails로 웹 개발의 첫 한걸음을 하고, 벤쳐 창업 동아리 SOPT에 들어가 엔젤 투자자, 여러 CEO 분들을 보면서 창업에 대한 꿈을 키웠다. "내가 만든 서비스로 돈을 벌고, 내가 만든 서비스를 사랑해준다니.. 이 도대체 멋진 일이 아닌가.." 그런데 막상 현실은 정말 어렵다. 프리랜서가 자신을 PR하기 위해 셀프 브랜딩을 하듯, 창업은 CEO인 자신과 서비스를 동시에 브랜딩하면서 프로덕트의 경쟁성을 키워야한다. 또 가정 형편상 집에서는 그다지 도전적인 분위기를 좋아하지 않았다. 그러면서 안정적으로 학교 생활을 하고, 또 안정적으로 개발자로의 직장생활을 하게 되었다. 그러면서 우연히 현직자들과 함께 빠르게 프로덕트를 런칭할 수 있는 디프만이라는 활동을 하게 되었다. 약 5~6주 동안 기획부터 디자인 · 개발 및 런칭까지의 프로세스를 치열하게 고민하고 밤샘작업하는 과정에서 무언가 조그마한 불씨가 타올랐다. "실패하면 어때, 그냥 시중에 프로덕트로 운영부터 해보자" 그렇게 만들어진게 글을 작성하고, 회고를 좋아하는 나에게 정말 꼭 필요했던 서비스 "레이어" 이다. 그리고 최근에는 빅테크 채용 공고 서비스도 그로스 하는 과정을 겪고 있다. 반짝이고 사라지는 서비스 보다는, 5명이라도 지속적으로 사용할 수 있는 서비스를 만들고싶어. 시작이 창대하면 얼마나 좋을까, 항상 모든 프로덕트의 시작은 그리 창대하지 않다. 디프만에서 처음으로 만들었던 서비스가 "칭찬감옥" 이라는 재미난 요소에서 시작했던 프로덕트였는데, 잠깐 반짝하고 사라지는 서비스가 되어버렸고 그렇게 빠르게 서비스도 종료가 되었다.

내가 예전에 정말 좋아하는 수필이 있었는데, 어쩌다보니 TV에서 접했던 이슬아 작가님의 수필을 좋아했다. 이 작가님의 수필은 특이하게 책으로 출판을 하는 것이 아닌 (현재는 책도 출판을 하신다) 이메일로 저녁 시간에 글을 보내주시곤 한다. 구독료도 온라인으로 보내는 방식이었는데, 구독료를 그렇다고 빡빡하게 가져가시는 것도 아니었다. 구독료가 없다면 나중에라도 보내달라는 메세지가 적혀있었고, 그냥 작가님은 글을 사랑하는 내가 생각하는 작가의 이상적인 모습 그 자체였다. 문득 회사에서 코드를 작성하면서 불편한 점들이 정말 많았다. 몇년 전 코드들을 보면서 그 코드를 작성한 사람이 회사에 남아있다면, 자리로 가서 이 당시의 코드는 어떤 의도를 가지고 만든 코드였는지 조심스레 여쭙곤한다. 그런데 그 코드를 작성한 사람이 퇴사자라면 어떤 의도로 이 코드를 만들고 설계했는지 정말 많은 시간을 가지고 고심해 파악하곤한다. 그래서 중요한 이슈로 인해 추가되는 코드인 경우, 특이사항으로 인해 긴급하게 추가되는 코드인 경우에는 꼭 나의 발자취처럼 주석을 친절하게 남기곤한다. 아래처럼 코드 안에 글을 새기곤한다. 현재 회사에서 3년 가까이 재직을 하면서 이러한 코드들이 점차 쌓여나가고 있다. 개발자로 입성하기 아주 오래 전에는 정말 좋은 코드는 주석 없이도 볼 수 있는 코드라는 말을 들었는데, 나는 사실 서비스를 하는 기업에서 방대한 코드들 속 다양한 개발자와 협업하는 환경에서는 그러기가 정말 쉽지 않다고 생각을 한다. 그래서 쉽사리 공감은 되지 않지만 어느정도는 함수 명을 정말 고심해서 짠다거나 하는 노력을 한다. 내가 입사했을 때의 초창기의 코드들을 회사에서 한번 살펴보자. 정말 엉망이다. "왜 이렇게 설계하고, 왜 이렇게 짰을까?" 라는 생각을 하기도 한다. 또 1~2년 후에 나는 지난 나의 코드들을 보면서 "왜 이렇게 코드를 작성했을까?" 라고 생각을 할 것 같다. 그런데 지난 나날들을 바라보고 평가할 수 있는 자체가 내 스스로 성장했다는 증거가 아닐까 싶기도 하다. 영원히 좋은 코드는 없다. 단지 그 상황에서 가장 적합하고, 문제를 해결할 수 있는 코드를 작성했기에 당시에는 좋은 코드로 평가받을 수 있다고 생각한다.

처음 개발자로 발을 들였을 때, 그때의 느낌은 또 새롭지만 온전히 누군가를 만나 프로젝트를 진행하고, 그 안에서 매번 새로움을 배우는 것이 항상 즐거웠다. 4년차 가까이 개발자를 하면서, 오늘날 느끼는 성장에 대한 정의를 기록해보려고 한다. 최근에 생각이 조금 많아졌다. 도메인이 점차 익숙해지면서, 배우는 과정보다는 원래 하던 일을 익숙하게 하는 느낌.. 이런 느낌이 나는 잘 맞지 않는 듯한 느낌이 든다. 새로운 것을 알게되고 그 과정에서 넘어지고 일어나는 과정들이 정말 재미있는 법인데, 현재는 그런 과정이 생각보다 많이 없다. 사실 사내에서 해답을 찾고 싶지만, 솔직히 말하면 안에서 이러한 갈증을 어떻게 해결할 수 있는지 잘 모르겠다. 새로운 프로젝트를 만들고싶기도 하지만, 돌아오는 것들은 부족한 리소스라는 대답으로 인해 못한다는 말인데.. 혼자 외롭게 프로덕트를 전반적으로 만드려고하니 사이즈가 너무 커서 업무에 지장을 줄까봐 그것도 걱정이 된다. 그래서 내가 체크리스트를 만들어보았다. "내가 정말 원하는 것들을 잘 이뤄내고 있는걸까?", "내가 원하는 조직의 모습은 무엇일까?" 와 같이 내가 성장을 하고자 할때 반드시 확인해야하는 것들을 끄적여봤다. 이직을 할 때는 "탓" 이라는 것을 하지 말라고 하는게 정답이라고 하는데, "탓" 이 없다면 어떻게 다양한 이유들을 만들어낼 수 있겠는가.. 내가 원하는 이상과 결과가 일치하지 않을 때는 반드시 누군가에겐 "탓"으로 다가오게 된다. 내가 만든 체크리스트에서 현재의 내 모습은 어떤지 한번 확인을 해보려고한다. 내가 성장을 하고자 할 때 반드시 확인해야하는 것들 환경적인 요인 얼마나 다양하고 새로운 것들에 대해서 도전을 할 수 있는 환경인가? 처음에 우리 조직은 잘 돌아가는 프로덕트에 무언가 새로운 것을 추가하는데 있어 조금은 방어적이었던 것 같다. 아무래도 플랫폼 리뉴얼을 하고나서 얼마지나지 않아 그런 것일지도 모르겠지만.. 매번 새로운 기술과 트렌드 정보들을 공유하면서 신기술을 도입했었는데 현재는 새로운 것들이 존재하면 바로바로 도입을 할 수 있는 구조가 되었다.

글을 시작하며 사내에서 백오피스 프론트엔드 프로젝트에 타입스크립트가 적용되면서 내부 컨벤션이 정의되며, 구조에 대해 한번 더 생각할 기회가 있었다. 이 과정에서 초기 사내 백오피스 프론트엔드 프로젝트의 폴더 구조는 아래와 같이 도메인 별 1:1 매핑되는 구조로 가져고 있었다. 프로젝트를 진행하다보니 이 구조가 기능 도메인이 점차 커질수록 많은 문제점을 야기한다는 것을 알게되었다. 위에 코드는 실제 프로젝트로 기존에 구성되어있던 구조이다. 초기에는 프로젝트 도메인 별로 구분이 되어있다는 느낌을 받으면서 직관적이고 모든 API는 api/ 폴더 안에, 그리고 모든 페이지를 구성하는 뷰(페이지)는 views/ 폴더 안으로 구성하면되니 일관성을 확보할 수 있었다. 다만 점차 프로젝트의 기능 별 도메인이 많아지면서 백오피스에서 관리해야하는 영역들이 많아지고 있음을 느꼈다. 그리고 이런 문제점들이 발생했다. 기능 별 도메인이 추가될 때마다 views 폴더 안에 관련 폴더를 만들어주고, api , components , composable 과 관련된 폴더들에서도 동일한 이름으로 만들어줘야한다. 이 과정에서 네이밍 규칙이나, lookAlike 라는 기능 도메인을 lookAlikeDomain 과 같이 자유분방한 이름으로 통일성이 지켜지지 않는 경우가 있다. components , util 과 같은 우리가 평소 쓸만한 폴더 명이 아니기도 하면서, 익숙하지 않기 때문이다. 기능이 2~30개 정도가 되면 한 views 폴더 안에서 해당 컴포넌트를 찾기 위해서 여러 파일들을 탐색해야하는 경우가 생기는데, 이 과정이 점점 오래 걸리기 시작한다. 기능을 수정할 때도 동일하다. views 폴더에서 컴포넌트로 이동을 했다가 또 views 파일로 이동을 하는 반복적인 과정들이 생긴다. 레이어(기술 중심) 폴더로 설계를 하다보니, 각 폴더를 "무엇을 하는가" 에 따라 분류하면서 낮은 응집도와 확장성, 그리고 네이밍 중복에 대한 문제가 발생한다. 어떻게 해결할 수 있을까? 처음 백오피스 구조를 살펴보면 여러 컴포넌트들과 컴포저블들은 궁극적으로 views 폴더 안에 존재하는 기능 도메인 파일을 위해 구성되는 여러 요소들이다. 이 목적성에 따라 views 를 기점으로, 그러니까 각 기능 별 도메인을 기준으로 폴더를 구성한다.