2025년 상반기 개발회고

들어가기 앞서...

---

2024년 8월부터, 이전 회고들은 어디로?

 이전 회고들은 일상 블로그에 있었다. 과거형으로 작성한 이유는 이제는 일상 블로그가 없기 때문. 없애버린 이유는 여러가지다. 일기를 작성할 여건도 안되고 의미가 퇴색되기도 하여 없애버렸다. 내가 일기에 올리는 내용들은 대부분 나의 사생활이다. 내가 보라고 공개한 사생활이긴 하지만 어디까지나 보라고의 의미지 보고 멋대로 판단하라는 의미는 아니었다. 하지만 내가 거기까지 막을 수 는 없기도 하고 그 판단의 영역부터는 나의 손을 벗어난 일이다. 그래서 내가 조절할 수 없는 영역들에 대해 스트레스를 느낄 바에 없애는게 맞다고 생각해서 없앴다.

 

 없애긴 했지만 (전)일상 블로그에는 12월 까지의 회고밖에 없다. 최근 6개월간은 꽤나 바빴기 때문에 회고를 올리지 않았다. 그렇지만 바쁘다라는 이유로 회고를 멈추는 것은 좋지 않은 것 같아 상반기와 하반기로 나누어 올리려고 한다.

 

 

본격적인 웹 개발 공부 시작

---

Flutter보다는 웹을 좀 더 해보고 싶다

웹 개발자로 전직하고 싶은 마음

 Flutter 개발자로 일을 한 지 거의 1년이 다 됐다. 앱 개발자가 내가 그동안 원하는 진로인 줄 알았으나, 최근에 웹 개발을 배우고 적용을 해보다 보니 웹 개발이 조금 더 재밌게 느껴지고 있다. 대학 다닐 때는 웹 개발이 죽도록 하기 싫어서 알고리즘이나 게임 개발, 그래픽스, 앱 같은 것만 했는데 졸업하고서 웹을 접해보니 생각보다 꽤 재밌었다.

 

 다만 조금 걸리는 것은 아직은 스타일링에 있어서, 프로젝트 구조에 있어서 어떤 것이 효율적인지 가늠이 잘 안선다는 것이다. 아무래도 이제 막 1년차니까 구조 짜는게 서툴 수 밖에 없다지만, 앱 개발로 1년차라 그동안의 축적된 경험도 많지가 않은게 문제다. 나름대로 공부는 하고 있지만 왜 이 라이브러리를 골랐는지를 물어보면 확실하게 무엇 때문이다 라고 말 하기가 어렵다.

 

부분 웹 앱 방식을 구현해보고 싶다

 그렇지만 앞으로의 목표는 확실하다. 토스에서 많이 하고 있는 방식인 부분 웹 앱 방식을 구현하는 것이다. Flutter나 ReactNative, 혹은 네이티브 코드로 기틀만 짜놓고 내부에서 자주 바뀌는 이벤트 페이지들을 웹 배포를 하는 방식으로 갈아끼우는 것을 하는 것이다. 취업 시장에 들고갈 개발 스택으로 Flutter를 고른 이유는 개발의 효율성 때문이었다. 앱 개발에서 네이티브 방식은 개발자가 두 명 필요하기도 하고, 둘의 합을 잘 맞춰야하기 때문에 개발 시간이 오래걸렸는데 Flutter나 RN같은 크로스 플랫폼 프레임워크를 사용하게 되면 그럴 필요도 없어지고 코드 하나로 둘을 관리할 수 있기 때문이다.

 

 그런데 부분 웹 앱 방식은 효율성의 끝판왕이라고 볼 수 있다는 생각이 들었다. RN의 장점인 코드 푸쉬의 성격도 챙겨가면서 네이티브의 기기 권한 설정들과 어느정도의 성능을 챙겨갈 수 있다. 이런 방식에 매력을 크게 느껴 더더욱 웹 개발을 배우고 싶다는 생각을 했다. Flutter도 할 줄 알고, 웹 개발도 할 줄 알면 효율적인 앱 구성을 할 수 있다는 것이니 말이다.

 

블로그에 웹 개발 글은 많이 못올렸다

작년에 웹 개발 공부 글을 올리고 Flutter 개발자로 입사를 한 뒤, 2025년이 되어서야 다시 웹 개발 공부를 시작했다. 입사한 이후로 글을 거의 못올리긴 했는데, React글은 더더욱 못올렸다. 2024년 7월에 하나, 그리고 2025년 2월에 하나를 쓸 정도로 그 간극이 상당히 길었다. ▼

2024년 7월 글

[React][개발기] 10. 무한 슬라이드 개발

 

2025년 2월 글

[React] Tailwind-css를 써보면서 느낀점

 

 

그럼에도 프로젝트는 진행중

글을 작성하지 않는다고 해서 공부를 하지 않는건 아니다. 공부도 꾸준히 하고 있고, 개발도 하고 있다. 나는 공부를 프로젝트를 통해 하곤 한다. 그래야 실제 개발에 필요한 부분들을 빠르게 체화할 수 있다고 생각해서이다. 

 

그래서 간단하게 아래의 하이아크 웹사이트를 하나 만들었고, ▼

HI-ARC

 

1D1S 프로젝트를 진행중이며, laiteu 프로젝트에 참여했다.(1D1S는 현 시점 아직 배포가 안됐다...) ▼

Laiteu

 

 이것 외에도 하이아크 플랫폼 개발을 하고 있다. 모노레포도 도입하고, 하이아크 관련 모든 프론트엔드를 하나로 통합하는 프로젝트를 진행하고 있다. 플젝 자체를 배포부터 시작해서 웹사이트가 올라가있긴 하지만 아직 보여줄 정도는 아니다.

 

 나는 즐겁게 하고 있지만 아직 포트폴리오나 이력서에 적을만한 성과가 나오지 않아서 조금은 아쉽다. 1D1S의 경우 나의 숙원사업과 같은 느낌이었기에 현재 배포도 안된 상태가 상당히 안타깝다.

 

 

프로젝트에서의 갈등

---

갈등이야 늘 있다

 프로젝트를 진행하면서 갈등이 없다는 것은 팀원 모두가 고민을 안했다는 증거고, 갈등이 너무 많다는 것은 팀원 중 어느 한 쪽이 고민을 안했다는 증거라고 생각한다. 하지만 적절한 수준의 갈등은 어떤 프로젝트에서나 존재한다고, 그리고 존재해야만한다고 생각한다.

 

 앞서 이야기한 프로젝트들에서도 갈등은 다 있었다. Laiteu의 경우 참여한 지 얼마 안돼서 갈등은 없었지만, 코드 리뷰는 빡세게 진행되고 있다. 코드 리뷰도 어떻게 보면 하나의 갈등이라고도 할 수 있다고 생각한다. 내 코드에 대해 어떠한 불만 혹은 개선점을 찾았다는 것이고 그걸 나에게 고쳐야한다고 부딪히는 과정이니 말이다.

 

1D1S

 그 중에서 1D1S가 갈등이 가장 컸다. 1D1S는 나의 숙원 사업이라고도 할 수 있을 정도로 애정이 있는 프로젝트다. 실제로 단체도 반년간 운영했고, 마지막 시즌 운영때에는 모집 폼을 계속 열어놨다면 끊임없이 사람이 유입될 정도로 사람이 많이 모였다. 그래서 이를 서비스화 하기 위해 팀을 꾸렸고, 개발을 시작하게 됐다.

 

인원

 처음에는 오래 알고 지낸 친구와 둘이서 하려고 했었다. 사실 그보다 더 처음에는 팀을 꾸려서 할 생각이었는데 그 친구가 그렇게 사람 많이 데려다가 하면 인원 관리도 안되고 업무 분담도 제대로 안돼서 프로젝트가 쉽지 않아진다고 하여 둘이서 하는걸로 하려했다. 하지만 친구의 취업준비로 인해 시간이 나지 않게 됐고, 기획 자체의 볼륨도 꽤 큰 편이라 인원을 구하게 됐다.

 

 내가 원하는 인원 편성은 이러했다.

• PM, 기획, 디자인 - 나
• 프론트 팀장 - 1명
• 프론트 팀원 - 나 포함 2명 ~ 3명
• 백엔드 팀장 - 1명
• 백엔드 팀원 - 2명 ~ 3명

 팀장급의 사람을 구할 때는 어느정도의 실력이 뒷받침되는 사람이었으면 좋겠다고 생각을 했다. 그렇게 공고를 지인들에게 우선 뿌렸는데 생각보다 하겠다는 인원이 많아서 지인들로 구성이 되게 됐다. 프론트 인원은 내가 생각한대로 구성이 잘 됐다. 내가 Nextjs를 배우는 단계였기에 실력적으로 뛰어난 사람이, 리드해 줄 사람이 필요했는데 딱 적절하게 잘하는 지인이 참여해줬다.

 

 문제는 백엔드였다. 다들 프로젝트 경험은 있지만 실력적으로 검증된 인원이 없었다. 약간의 걱정은 있었지만 내가 잘 관리를 하면 된다고 생각을 해서 대면 회의를 진행하고 역할분담과 해야할 것들을 알려줬다.

 

관리 소홀

 팀장들에게 역할을 다 맡기고 나서 갑자기 일이 생겼다. 외주가 하나 들어왔는데 그 일만 하면 경제적으로 여유가 생겼기에 프로젝트에 집중할 수 있고, 약간의 투자도 할 수 있게 됐기에 외주를 잡았다. 외주를 잡게 되면서 개인적인 일정이 빠듯해졌고, 팀장들에게 관리를 잠시 위임했다. 어차피 그 때는 프로젝트 구조를 짜고 컨벤션을 정하는 단계였기 때문에 큰 문제가 될거라고 생각하지 않았다. 그리고 이게 내 엄청난 실수였다는것을 한 달 뒤에 깨달았다.

 

 외주를 얼추 마무리하고 돌아왔을 때, 프론트엔드는 husky설정을 통한 commit convetion 강제와 eslint, prettier을 통한 코드 자동 정렬, 그리고 클린 아키텍쳐 적용까지 다 잡혀있었다. 또한 radix ui를 이용하여 기본적인 컴포넌트들까지 얼추 다 구현이 되어있어서 사실상 페이지에 컴포넌트 배치를 하고 API만 연결하면 끝이 나는 상태였다. 배포역시도 되어있었다.

 

 하지만 백엔드는 깜깜무소식이었다. 어련히 잘 하고 있을거라고 생각했는데 시험기간이라는 이유로 작업이 중단되어 난감했다. 또한 백엔드에서는 GraphQl을 처음 도입한 상태였기에 더더욱 진전이 안되는 상태였다. 그래서 우선은 임시로 통신 연결과 데이터 파싱 메소드 테스트를 하기 위해 배포를 부탁했는데 배포 역시도 제대로 진행되지 않았다.

 

인내의 끝

 그래도 대학생들은 학점이 중요하니 시험기간을 봐줬다. 어차피 그동안에 프론트엔드는 페이지를 짜야했으니까 일이 막히는 상태는 아니었다. 그렇게 팀장과 함께 UI를 짜고 폼 검증도 했는데, 그게 다 끝날 동안에도 백엔드에서는 나온게 하나도 없었다. 스키마만 있고 API와 배포는 아무것도 나오지 않은 상태였다. 이 때가 배포를 부탁한 지 한달이 넘어가는 시점이었다.

 

 회사에 다니고 있기에 프로젝트가 길어질 거라는 생각은 하고 있었다. 하지만 이렇게 길어질 줄은 몰랐다. 이렇게 늘어지는 것에 대해 더 이상 봐줄 수가 없었고, 팀원들에게 반 협박성 경고 공지를 올렸다. 기한을 이렇게나 많이 줬는데 작업 진행이 7월 초까지 끝나지 않는다면 프로젝트는 폭파고 새 인원을 구하겠다고.

 

 그랬더니 API가 나오고 개발 속도가 빨라졌다. 코어타임을 갖고 빠르게 개발을 시작했다. 이걸 보고 내가 관리를 소홀히 했구나를 뼈저리게 느꼈다. 처음부터 이렇게 관리를 했어야했는데... 하고 말이다.

 

엉망진창 배포와 브랜치

 그렇게 경고를 하고 나서 프론트 팀은 프론트의 할 일을 마쳤다. API와 배포만 되면 바로 연결을 할 준비를 하고 있었다. 그런데 배포가 계속 안됐다. 배포를 부탁한 지 두달이 넘어갔는데 아직도 배포가 안됐다. 그러다가 배포가 됐다길래, 도대체 뭘 하느라 이렇게 늦은건가 싶어 aws에 들어가봤는데, 충격적인게 기다리고 있었다. aws를 가동시킨 지 3~4일밖에 안됐는데 30달러가 넘게 찍힌것이었다.

 

 배포 담당자에게 경위를 물었는데 돌아오는 대답은 자기도 잘 모른다는 대답뿐. 지금 우리 서비스는 배포도 안해서 사용자가 0명인데 매일 10달러가 넘게 나가고 있었다. 대처를 하라고 했으나, 계속 미루다가 결국 일주일이 넘어갔고 총 70달러가 넘게 찍혔다. 개인 사비로 운영하는 것이었는데 아무런 성과 없이 테스트로 10만원을 날리지 화가 머리 끝까지 났다.

• 배포 요청한 지 2개월 가량 됨
• 데드라인을 계속 어김
• 막상 배포한 서버는 사용자가 0명인데 매일 10달러씩 부과되는 중
• 해결하라고 했더니 해결 못함
• 해결해야 할 배포 담당자는 다른 부트 캠프 준비나 하고 있음

이런 상황에서 화가 안 날 사람이 있을까 하면 난 절대 없다고 생각한다. 이 상황에서 내가 무엇을 할 수 있을 지 생각을 하다가, 현직자 지인에게 부탁해서 배포만 한 번 손봐달라고 부탁하기로 했다. 다행히 지인은 흔쾌히 부탁을 들어줬고, 임시방편으로 해결안을 제안해줬다.

 

 어찌저찌 배포는 성공했으나 백엔드 깃허브에는 문제가 정말 많았다. 커밋 컨벤션도 안지켜져있고 문서화도 하나도 안돼있었다. 아무리 GraphQl이라도 API 명세서를 작성해달라고 했으나 API 명세서도 불완전한 상태였다. 브랜치 역시도 dev브랜치보다 main 브랜치가 최신인 상태였고, 굉장히 이상한 브랜치 규칙을 가지고 있었다. main에서 개발을 하고 deploy에 main의 내용을 넣는다는 말같지도 않은 소리를 하고 있었다. 사실상 main이 dev라는 이야기인데, 그러면 dev라고 이름을 바꾸던가 했어야했는데 그런게 하나도 적용되지 않았다.

 

재정비와 해결

 왜 나에게 이런 시련이 오는가 생각을 하다가 결국 내가 관리를 제대로 안한게 문제라는 결론에 도달했다. 개발자지만 PM 역할을 하기로 했는데 상황 파악을 제대로 하지 못한 나의 잘못이 크다고 생각을 했다. 그래서 내 책임을 다 하기 위해 모두 불러다 놓고 상황에 대해 이야기를 하고 추후에 어떻게 할 것인지 정했다.

 

 잘못을 한 팀원에 대해서는 질책을 하기 보다 얻어간 점이 있었으면 좋겠다는 말만 했다. 나에게 사과할 게 아니라 팀원들에게 사과하라고 했으나 사과를 했는지는 모르겠다. 아무래도 안한거 같은데... 난 잘 모르겠다.

 

 그래서 이후에는 문제점들을 다 지적하고(나의 문제점 포함) 해결 방안을 도출한 다음, 그 해결 방안대로 개발을 진행하기로 했다. 그래도 갈등이 잘 해결되어 다행이라고 생각한다. 다 같이 모여서 이야기를 하는게 역시 갈등 해결에 도움이 많이 된다. 이런 갈등 상황들이 앞으로도 많을 예정인데 해결하는 방법을 익힐 수 있어 다행이라고 생각한다.

 

 

마무리

---

 아무래도 이번 상반기 개발 회고의 핵심 주제는 갈등인듯 하다. 개발에 있어서 성장하고 학습한 것도 있지만 프로젝트 전반에 대한 갈등과 그 해결에 대한 부분으로도 성장한 부분이 많다. 개발이 컴퓨터로 하는거라고 해도 결국 다른 사람들과 같이 하는 거다. 혼자서 다 개발 할 수 있을 거라는 오만함을 가지고 있다면 그 프로젝트는 결코 완성될 수 없다. 나의 부족함을 다른 팀원이 채워고 그 팀원의 부족함을 내가 채워주는 식으로 상호 보완적 개발이 진행되어야 완성도 높은 프로젝트가 나오게 된다고 생각한다.

 

 작성하다보니 이번 상반기에 그래도 꽤 많은걸 학습한 거 같아 다행이다. 얻은게 없으면 어떡하나 했는데 건져간 것들이 꽤 있어 그래도 활동들이 의미있었다고 생각한다. 이제 하반기에도 더 성장하여 더 능력있는 개발자가 되어야겠다.