이롭게 현명하게
[ㄱ-LOG] 혼자서 시작해 팀으로 완성하기까지의 개발일지 본문
업데이트 기록
[9화] 기능보다 중요한 것, 왜 이렇게 구현해야 하는가 (업데이트 일시 2025년 10월 24일 금요일)
[8화] 코드 분석과 리팩토링 (업데이트 일시 2025년 10월 24일 금요일)
[7화] 또 다른 임무 (업데이트 일시 2025년 9월 25일 목요일)
[6화] lock파일.. 이것 뭐에오? (업데이트 일시 2025년 9월 25일 목요일)
[5화] 협업 속에서 발견한 나의 역할 : 리더의 신뢰 (업데이트 일시 2025년 9월 25일 목요일)
[4화] 첫 임무 (업데이트 일시 2025년 9월 25일 목요일)
[3화] 팀원들과 첫 회의 (업데이트 일시 2025년 9월 25일 목요일)
[2화] 팀원들과의 첫 만남 (업데이트 일시 2025년 9월 25일 목요일)
[1화] 모험 중 (업데이트 일시 2025년 9월 25일 목요일)
프롤로그 (업데이트 일시 2025년 9월 25일 목요일)
🍀오늘의 작은 발걸음이 내일의 큰 도약이 된다.
[프롤로그]
<2025년 8월 10일>
계속되는 서류 탈락과 최종 면접 탈락을 겪으면서 '나는 무엇이 부족할까?' 하는 고민이 깊어졌다.
그래서 여러 지원자와 합격자의 서류를 살펴보고, 현직자분들께 피드백을 받았다.
돌아보니 내 이력서는 단순히 기술을 나열하고 구현 경험만 적혀있었다.
개인 프로젝트는 많았지만 협업 경험이 부족했고, 자기소개서에서도 내 강점이 뚜렷하게 드러나지 않았다.
결국 '나라는 개발자의 매력'이 보이지 않는다는 점이 가장 큰 문제였다.
그렇게 서류를 전체적으로 수정하며 스스로를 돌아보는 시간을 가졌다.
그리고 협업 경험을 쌓아 나의 역량을 끌어올리겠다고 다짐했다.
그 첫걸음으로 개발자 오프라인 모임에 참여하게 되었다.
이곳에서 만난 팀원들과 함께 성장할 생각에 너무 기대된다.
나는... 어떤 팀원들을 만나게 될까?
[1화] 모험 중
<2025년 8월 23일>
사이드 프로젝트를 함께할 팀원을 찾기 위해 개발자 라운지에 참여했다.
처음에는 새로운 프로젝트를 시작하는 게 좋을지, 아니면 기존 프로젝트를 보완하는 게 좋을지 고민이 많았다.
그러다 문득 '내 프로젝트에 다른 팀원들이 합류하고 싶어 할까?' 하는 생각도 들었다.
그래서 무엇보다도 팀원의 의견을 존중하기 위해, 만약 새로운 팀프로젝트를 진행한다면 어떤 아이디어가 좋을지 미리 구상해 보았다.
점심시간이 지난 뒤 라운지에 도착했지만 사람이 거의 없었다.🥲
처음에는 단순히 다들 늦게 오시는 줄 알았다.
오늘 대부분 해커톤에 참가하셔서 라운지에 많은 분들이 오지 못했다고 한다. 😂
그래서 혼자 개발을 하면서 라운지에 있던 분들과 이런저런 대화를 나누었다.
그 과정에서 프론트엔드 팀원을 구하고 계신 분이 있다는 것도 알게 되었다.
그 덕분에 내일 한 번 더 나오기로 했다.
나와 함께할 동료! 자네는 누구인가!!
[2화] 팀원들과의 첫 만남
<2025년 8월 24일>
으으 오늘은 라운지에 많은 분들이 올까? 하는 기대를 안고 라운지에 도착했다.
다행히 많은 분들이 오셔서 분위기가 활기찼다.
이번에 새로운 프로젝트를 진행한다면 일정 관리 프로젝트로 하루 일정 성취를 관리하는 웹 서비스를 기획했었다.
그러던 중 어제 프론트엔드 팀원을 구하고 계신 PM분을 만나게 되었다.
이미 프로젝트는 진행 중이었고 내가 중간에 합류하는 상황이었다.
괜히 끼어들어 민폐만 되는 건 아닐까 걱정했지만 오히려 주제와 목표가 겹쳐 자연스럽게 참여할 수 있었다.
항상 개인 프로젝트만 해왔던 나에게 협업 환경 자체가 낯설고 중요하게 느껴졌다.
그래서 조심스럽게 접근하며 모르는 점은 PM분께 질문을 많이 했다.
다행히 깃 사용법부터 진행 방식까지 차근차근 설명해 주셔서 한결 안심이 되었다.
프로젝트는 pnpm을 패키지 매니저로 사용하고 있었는데 처음 접하다 보니 시행착오가 있었다.
특히 powershell에서 실행했을 때 스크립트 권한 문제로 오류가 발생했다.
관리자 권한으로 실행하거나 Node cmd 환경에서 돌리면 해결할 수 있다는 걸 알게 되었다.
작은 문제였지만 덕분에 배움이 하나 더 쌓였다.
프로젝트 인수인계를 받으며 목적과 방향성을 파악했다.
이미 팀원들이 문서를 잘 정리해 둔 덕분에 빠르게 이해할 수 있었다.
이 과정에서 문서화의 중요성을 느꼈다.
그리고 프로젝트 구조도 분석해 봤다.
어떤 UI 라이브러리를 사용하는지 Next.js의 버전은 무엇인지, 전역 상태관리나 API 연결은 어떻게 되어있는지 살펴봤다.
전역 상태 관리와 API 연결은 아직 구현되지 않은 상태였다.
그렇게 팀 프로젝트에 합류하게 되었고 디스코드에서 팀원들과 인사를 나누었다.
중간에 들어온 입장이라 '내가 잘할 수 있을까?' 하는 걱정이 많았는데 PM분이 팀원들과 잘 소통하며 도움을 주시려는 모습을 보고 나도 적극적으로 질문하고 협업해야겠다고 느꼈다.
프로젝트 방향과 개발은 직접 부딪히면서 진행해야 하지만 팀원들과의 소통이 중요하다고 생각해서 PM분께 팀원들 소개를 요청드렸다.
어떤 분이 어떤 파트를 맡고 계신지가 궁금했다.
걱정 반 설렘 반이다!
[3화] 팀원들과 첫 회의
프로젝트 참여하면서 첫 회의를 가졌다.
회의는 디스코드에서 원격회의로 진행했다.
서로 진행 상황과 다음 안건에 대해 회의를 했다.
그리고 팀원들 소개를 받았다.
헤헤 넘모 부끄러운 것
우리 팀은 나 포함 총 6명으로 이루어진 팀이다.
프론트 2 + 1 (나) , 백엔드 2, 서버 1로 구성되어 있다.
회의가 끝나고 내가 맡은 부분에 대해 개발을 진행했다.
빨리 적응해서 프로젝트의 속도를 높여보고 싶다.
[4화] 첫 임무
첫 임무로 계정 설정 페이지의 프로필과 소셜링크 화면 구현부터 시작하였다.
일단 맡은 부분을 만들어보면서 적응하고, 나중에 코드 리뷰를 받으면서 수정하면 될 것 같다.
그렇게 성장하는 거니까~
우선 화면에 보이는 UI부터 구현하고 브랜치 이슈에 내가 작업한 내용을 작성하였다.
하지만 알고 보니 계정 설정 브랜치와 소셜 링크 브랜치가 따로 있었는데 나는 그걸 브랜치 하나에 다 만들어버렸다...
엄청난 실수를 한 거 같아서 손 벌벌 떨면서 질문했다. ㅠㅠ
알고 보니 코드 리뷰를 더 잘할 수 있게 브랜치를 나눈 것이었다.
그래서 이번 작업이 끝나고서는 브랜치를 더 잘 사용해야겠다.
그리고 주석의 중요성도 알게 되었다.
작업 내용을 기록해 두니 코드 리뷰도 훨씬 수월해졌다.
계정 설정 페이지 라우팅을 처음 /profile로 해두었다.
페이지 이름과 잘 안 맞는 것 같아 고민이 됐다.
그래서 팀원들에게 /account로 바꾸는 게 좋을지 아니면 profile을 그대로 쓰는 게 좋을지 의견을 물어봤다.
탭 구조라 account가 더 편해 보인다는 답변을 받았고 의견을 반영해 /account로 수정했다.
사소한 부분이지만 이렇게 팀원들과 소통하면서 방향을 정하니 훨씬 든든했다.
[5화] 협업 속에서 발견한 나의 역할 : 리더의 신뢰
디스코드에서 배포 오류가 생기고 깃에서는 충돌이 계속 생기는 상황을 목격했다.
처음에는 단순히 프로젝트를 진행하며 자연스럽게 발생하는 현상인 줄 알았다.
하지만 배포 오류와 충돌이 해결되지 않자, 그 이유가 궁금해졌고 먼저 해결하는 것이 팀원들의 개발 환경과 속도를 높이는 데 도움이 될 것이라고 판단했다.
깃 충돌 문제를 살펴보던 중, 팀원들의 코드에서 저장 단축키를 누르면 코드 정렬이 되면서 저장이 되는 현상을 발견했다.
이것으로 프로젝트에 prettier가 적용되지 않았다는 것을 알게 되었다.
프로젝트에 prettier가 적용되지 않아 팀원들이 각각 다른 스타일로 코드를 작성하고 있었기 때문에 충돌이 일어난 게 아닐까?라고 조심스래 예상했다.
그래서 먼저 팀원들의 prettier 설정을 확인하고 프로젝트에 일관되게 적용되도록 환경을 구성했다.
모두 다르게 prettier 설정이 되어있었다.
그래서 지금 진행 중인 프로젝트에 prettier가 적용될 수 있도록 환경을 구성하였다.
배포 오류도 확인했다.
pnpm build 과정에서 lint 오류가 있어 배포가 되지 않았던 것이다.
이 내용을 문서화하여 팀원들에게 공유하고, 프로젝트를 진행하면서 오류를 하나씩 고쳐나가기로 했다.
[TMI]
Warning: In HTML, ‹div> cannot be a descendant of <p›. 오류를 발견했다.
HTML 표준에 따르면 p 태그는 택스트 콘텐츠를 위한 것이다.
그래서 div 태그와 같은 다른 블록 요소들을 포함하는 것은 옳지 않다.
그래서 팀원에게 오류의 원인을 알려주어 문제를 해결했다.
이것으로 HTML 표준에 대해 알게 되었다.
또한 로그인 후 페이지들 사이에 반복되는 사이드바와 헤더 문제를 발견했다.
여러 페이지에 반복 적용되어 팀원들의 작업이 비효율적이라고 느껴졌다.
이 과정에서 컴포넌트를 재활용하여 ui를 한 번만 설정하면 모든 화면에 적용할 수 있도록 구조를 바꿔 팀원들의 불필요한 작업을 줄이고 개발속도를 높이는 것을 목표로 하였다.
메뉴와 사이드바를 그룹라우팅을 활용하여 layout.tsx에서 헤더와 사이드바를 한 번만 렌더링 되도록 구조를 개선하였다.
그 결과 팀원들의 반복 작업이 줄어들어 개발 속도가 크게 향상되었고 관련 오류가 줄어들었다.
이 과정에서 팀원들에게 많은 도움을 주고 신뢰를 얻어 프론트엔드 파트에서 리더 역할을 맡을 수 있게 되었다.
[6화] lock파일.. 이것 뭐에오?
서버 쪽에서 배포 오류가 발생했다.
react는 19.1.1 버전을 사용하는데 react-dom은 19.1.0을 사용해서 생긴 문제였다.
그래서 단순하게 react-dom을 react버전에 맞춰서 설정하면 된다고 생각했다.
그런데,,, 단순히 생각하면 안 됐다.
react-dom을 업데이트하고 나서 lock 파일 의존성에 문제가 생겨 깃 충돌이 일어났다.
그 과정에서 PM과 함께 멘탈이 나가며 겨우 해결했다.
솔직히 어떻게 해결했는지도 잘 모르겠다.
단지 버전 업그레이드가 쉬운 일이 아니라는 건 알게 되었다.
순간 당황해서 이 문제를 어떻게 해결해야 할지 몰랐다.
PM분이 침착하게 문제를 해결하는 모습을 보면서 안심할 수 있었다.
리더가 있다는 것이 얼마나 든든한 일인지 새삼 느꼈다.
이 과정을 통해 협업의 필요성과 팀워크의 중요성도 실감할 수 있었다.
항상 느끼지만 리더의 존재가 팀 분위기와 성과에 큰 영향을 미친다는 것을 다시 깨달았다.
PM분이 팀원을 생각하고 어려움에 처했을 때 적극적으로 도움을 주는 모습을 보며 많은 것을 배우게 되었다.
그래서 PM이 아닌 '대장'이라고 부르기로 했다. ㅋㅅㅋ
대장을 보며 많은 걸 배우는 중이다.
갑자기 정팀장님이 생각난다.
나으 첫 리더
나으 뮤즈 정팀장님!
보고시뻐오 정팀장님~
[7화] 또 다른 임무
나에게 또 다른 임무가 주어졌다.
그것은 바로 프로젝트 폴더 구조 바꾸기!
원래는 FSD 아키텍처로 진행했었는데 구조가 어려워 이해하는 것에 어려움을 느껴 좀처럼 진행이 되지 않은 상태였다.
그래서 팀원들과의 의논 끝에 깃 충돌을 줄이고 유지보수 하기 쉬운 구조로 변경하기로 하였다.
그래서 나는 도메인 아키텍처로 구조를 수정하는 작업을 진행 중이다.
괜히 혼자 판단해서 바꿨다가 불편해지는 건 아닐지 걱정이 된다.
그래도 지금까지 경험한 걸 바탕으로 최대한 협업하기 좋은 구조로 만들고 싶다.
완성되면 팀원들에게 보여주고 피드백을 받아야 할 거 같다.
프로젝트 구조를 변경하면서 코드 리뷰를 어떻게 해야 할지를 알게 되었고
팀원들이 코드 작성을 어떻게 하는지 알게 되었다.
코드를 분석하는 일은 항상 재밌다.
[8화] 코드 분석과 리팩토링
프로젝트 폴더 구조를 도메인 아키텍처로 수정하는 리팩토링 작업을 진행했다.
사실 단순히 폴더를 옮기고 이름을 바꾸는 일이었기도 하지만
팀 전체의 코드 흐름과 구조를 다시 바라보는 과정이었다.
리팩토링을 빨리 끝내고 싶었는데 중간에 건강 이슈로 작업을 제대로 하지 못했다. 🫠
동료들의 코드를 보면서 많은 깨달음을 얻을 수 있었다.
코드를 분석하다 보니 각자 다른 스타일로 작성된 코드들이 눈에 띄었다.
코드 리뷰와 코드 컨벤션이 왜 중요한지 알게 되었다.
컨벤션이 맞춰져 있지 않으면 유지보수가 어렵고 리뷰 과정에서 불필요한 피로감이 쌓이게 된다.
그래서 지금부터라도 통일해야겠다는 생각으로 코드 컨벤션 문서를 작성해 팀원들과 공유했다.
단순한 형식 통일이 아니라 우리 팀의 개발 문화를 하나로 모으는 시작이 되었다.
그리고 새롭게 정리한 폴더 구조와 컨벤션 내용을 README에 문서로 작성해 두었다.
누가 봐도 이해하기 쉬운 구조를 목표로 동료들이 언제든 참고할 수 있도록 정리했다.
이 문서를 통해 개발 속도향상에 도움이 되었으면 한다.
리팩토링을 진행하다 보니 빌드와 배포 과정에서 발생하는 오류들도 함께 발견하게 되었다.
이 부분은 단순히 코드 문제가 아니라 타입 오류와 렌더링 문제였다.
그래서 오류의 원인들을 모아 문서로 정리해 팀원들에게 공유했다.
빌드 오류가 발생해서 서버 쪽에서도 배포를 진행할 수 없었기 때문에 서버 쪽에서도 문제를 해결할 수 있도록 프론트에서 우선순위를 정해 문제를 해결하기로 했다.
이번 경험은 단순한 코드 수정이 아니라 팀 전체가 더 나은 방향으로 나아가기 위한 구조적 성장의 과정이었다.
혼자 하는 프로젝트였다면 그냥 넘어갔을지도 모르는 부분들이 협업 속에서는 모두가 함께 고민해야 할 부분이 된다는 걸 알게 되었다.
리팩토링을 통해 좋은 코드란 단지 깔끔한 코드라고 생각했는데 다른 사람이 이해하기 쉬운 코드라는 것을 알게 되었다.
[9화] 기능보다 중요한 것, 왜 이렇게 구현해야 하는가
리팩토링이 끝나고 나서 merge 후 빌드 오류를 해결하는 작업을 진행했다.
나는 동료들이 오류를 해결하는 동안 API 연결 테스트를 겸해서 회원가입 기능을 직접 구현해 보기로 했다.
처음에는 단순히 POST 요청이 잘 가는지만 확인하려 했다.
생각해 보니 리팩토링 이후 구조가 많이 바뀌었기 때문에 팀원들이 참고할 수 있는 예시 코드를 만들어두면 좋을 것 같았다.
그래서 React-Query를 사용하여 회원가입 예시 코드를 작성했다.
API 요청과 상태 관리가 한눈에 보이도록 정리하고 유효성 검사와 예외 처리도 추가했다.
그리고 동료들이 잘 이해할 수 있도록 주석으로 코드 설명을 해두었다.
회원가입 기능이 정상적으로 작동하는 걸 확인하고 API 연결이 잘 되었다는 걸 확인할 수 있었다.
회원가입에 이어 두 번째로 로그인 기능을 구현했다.
JWT 토큰을 사용하여 인증을 처리했다.
처음에는 API 연결 테스트와 로그인 로그아웃, 라우터 관리를 위해 로컬 스토리지에 저장하는 방식으로 구현했다.
그런데 막상 구현을 마치고 나니 '이렇게 하는 게 맞나...?' 라는 생각이 들었다.
그중에서 로컬 스토리지는 보안상 취약점이 있다는 점이 마음에 걸렸다.
이 문제를 혼자 고민하다 보니 점점 머리가 복잡해졌다.
'쿠키에 저장하는 게 좋을거 같은데 백엔드에서는 어떻게 처리를하지? 리프레시 토큰은 어떻게 관리해야하지?'
이런 생각이 꼬리에 꼬리를 물었다.
그래서 결국 팀원들과 상의하기로 했다.
논의 끝에 현재는 개발 단계로 임시로 로컬스토리지를 사용하고 출시 전에는 쿠키로 전환하기로 결정했다.
이 과정에서 단순히 구현하기 보다 보안과 유지보수까지 고려해야 한다는 중요성을 느꼈다.
이번 작업은 단순한 기능 구현이 아니라 "왜 이렇게 구현해야 하는지"를 고민하면서 성장하였다.
그리고 모든 걸 해결하려고 애쓰기 보다 팀원들과 함께 고민하고 의견을 나누는 것이 중요하다는 것도 느꼈다.
그리고 로그인 pr을 올렸다.
'T-LOG > ㄱ-LOG' 카테고리의 다른 글
| [ㄱ-LOG] 한빛미디어 베타 리딩 참여 후기 / 패턴으로 익히고 설계로 완성하는 리액트 / 리액트 안티패턴 (2) | 2025.02.10 |
|---|---|
| [ㄱ-LOG] 2024 회고록 (2) | 2024.12.31 |
