Study + Daily = Steadily 자세히보기
반응형

탈출하고 싶었던 회사에서, 나는 왜 더 열심히 하기로 했나

이 블로그에 올라올 글들은 내가 안드로이드 리드로 이직한 이후 마주한 문제들을 어떻게 해결했는지에 대한 기록이다.근데 그 전에 하나 솔직하게 써두고 싶은 게 있다. 입사 전부터 이 회사의 인상은 좋지 않았다. 회사 규모, 잡플래닛 평점, 재직자 리뷰, 연봉 협상 과정까지 어느 하나 좋게 볼 만한 게 없었다. 그럼에도 입사한 건 단순한 이유였다. 마냥 노는 것보다는 어디서든 일을 하는 게 낫겠다 싶었고, 실무 감각이 떨어지는 게 더 무서웠다. 들어와서 보니 예상이 틀리지 않았다. 개발 문화나 프로세스를 파악하는 데 오래 걸리지 않았다. 일정은 탑다운으로 찍혀서 내려왔고, 기획이 다 확정됐다고 해서 개발을 마쳐놨더니 막판에 뒤집히는 일도 있었다. 중간에 기능이 예고 없이 추가됐고, 그 와중에 릴리즈가 병렬로..

Development 2026.07.10 0

묵묵히 채웠더니 팀이 따라왔다: 팀 위키를 만든 기록

들어가며코드 컨벤션을 만들고, CI/CD를 구축했다. 그런데 돌아보면 그것들보다 먼저 마주쳤던 문제가 있었다. 아무것도 기록되어 있지 않았다는 것.온보딩이 두 배로 걸렸다입사하고 나서 업무를 파악하는 과정이 유독 힘들었다. 문서화가 되어있지 않으니 필요한 것들을 하나씩 직접 물어봐야 했다. 그런데 팀원들도 뭘 알려줘야 하는지 몰랐다. 체계가 없으니 범위도 없었다.돌아오는 답변의 방식도 문제였다. 질문을 하면 본인이 직접 설명하는 대신 AI에게 물어봐서 그 답을 그대로 던져줬다. 검증 없이. 당연히 이해가 안 되는 내용이 섞여있었고, 할루시네이션 때문에 실제와 다른 내용도 있었다. 그걸 하나씩 걸러내면서 파악하다 보니 다른 회사에 입사했을 때보다 온보딩에 체감상 두 배는 걸렸던 것 같다.문제를 어떻게 봤는..

Development 2026.07.09 0

CI/CD 구축기: 계획대로 되지 않았다

들어가며브랜치 전략을 잡고, 컨벤션을 만들고, 코드 리뷰를 도입했다. 다음은 CI/CD였다. 이 글은 그 과정에서 어떤 판단을 내렸고, 계획이 어떻게 바뀌었고, 결국 무엇을 만들었는지에 대한 기록이다.당시 상황CI/CD는 당연히 없었다. 배포는 개발자가 로컬에서 직접 빌드해서 올리는 방식이었다.QA팀이 빌드를 요청하면 Android나 iOS 개발자가 로컬에서 직접 빌드하고, VPN으로 접속해서 보안 래핑까지 직접 처리한 뒤 Firebase에 올렸다. 멀티모듈 구조 때문에 gradle 명령어를 직접 입력해야 하는 과정도 있었다. 요청 하나에 개발자의 컨텍스트가 통째로 끊겼다. QA팀은 빌드가 올라왔는지 알 방법이 없어서 개발자에게 직접 물어봐야 했다.팀원들은 CI/CD가 무엇인지, 왜 필요한지에 대한 개념..

Development 2026.07.08 0

브랜치 전략, 사고 나고 나서야 빛을 발했다

들어가며이 글은 레거시 베이스 코드 상속 제한 규칙 도입과 같은 시기에 내린 결정이다.코드 구조를 정비하면서 동시에 진행한 작업이고, 순서상으로는 이쪽이 먼저다. 브랜치 전략이 없으면 히스토리 추적도, PR 리뷰도, 나중에 짤 CI/CD도 기반 자체가 없기 때문이다.당시 팀원에게도 왜 이런 결정을 내렸는지 정리해서 공유하였다. 이 글은 그 내용을 좀 더 구체적으로 기록해두는 것이기도 하다.당시 상황브랜치 전략이 아예 없었던 건 아니다. 문서는 있었지만 실무와 맞지 않았고, 실제로는 지켜지지 않고 있었다.현실은 개발자 한 명이 브랜치 하나를 파서 여러 티켓의 작업을 전부 처리하고, 릴리즈 직전에 그걸 하나의 PR로 develop에 올린다.리뷰는 없고, 티켓 관리도 당연히 되지 않았다. 전혀 다른 기능을 구..

Development 2026.07.07 0

Android 리드로 이직 후 처음 한 일

들어가며이직한 지 1달 반쯤 됐다. 이 글은 그 기간 동안 Android 리드로서 코드베이스의 구조적 문제를 마주하고, 어떤 판단을 내렸고, 실제로 무엇을 바꿨는지에 대한 기록이다.전면 리팩토링 성공담이 아니다. 레거시는 지금도 그대로 있다. 다만 더 이상 같은 방식으로 늘어나지는 않고 있다.당시 상황입사하고 보니 기존 Android 개발자 한 명이 퇴사한 직후였다. 팀 구성은 Android 2명(나 포함), iOS 2명, 팀장 1명이었다. 팀장은 iOS 개발자 출신이지만 지금은 PM 역할에 집중하고 있어서, Android 코드 구조나 아키텍처에 대한 개입은 없는 상태였다.코드를 열어보니 패키지 구조부터 눈에 띄었다. 같은 화면의 패키지가 세 개 나란히 있었고, 그중 하나에는 Jetpack Compose..

Development 2026.07.06 0

Android 배포자동화(fastlane + github actions) - Part.4

< Prev 로컬 환경에서 fastlane이 잘 동작하는걸 확인했다면 깃헙 레파지토리로 이동하자 Github Action 설정에 앞서.. 자동화를 하려는 프로젝트의 branch 전략에 대해 명확히 파악하는 것이 중요하다. (보통 이미 브런치 전략은 파악하고 있겠지만..) Github Action이 실행되는 조건(트리거)은 설정하기 나름이겠지만, 일반적으로 특정 브런치에 푸쉬 혹은 PR 됐을 때를 기준으로 Job을 실행시키기 때문에, 어떤 브런치에 어떤 상황에서 트리거가 발생할지 고민하고 설정해보기를 바란다. 브랜치 전략에 대해 모른다면 해당 글을 참고하도록 하자. 알기쉽게 잘 설명되어 있다 참고로 해당 프로젝트는 git-flow 전략을 사용하며 release 브런치에 PR이 발생했을 때 workflow가..

Android 2022.04.20 0

Android 배포자동화(fastlane + github actions) - Part.3

이제 실제로 fastlane을 사용하여 앱을 빌드하고 빌드 된 앱을 App Distribution을 사용해 QA팀에게 배포하는 과정이다.굉장히 지난한 과정 같지만 해당 과정만 잘 동작하면 나머지는 깃 헙 액션을 통해 트리거를 만들어 특정 상황에서 fastlane을 실행시켜주는 과정만이 남았다. 물론 현업에서 실제로 사용할 만큼의 Fastfile을 작성하고 빌드 환경에 맞춰 수정하려면 다른 사람들이 작성한 Fastfile을 찾아보며 본인에 게 맞게 작성해 줘야하겠지만 git에 많은 reference가 존재하므로 크게 어려운 작업은 아닐것이다. 프로젝트 root 디렉토리에서 다음 명령어를 입력하여 app distribution 플러그인을 설치한다fastlane add_plugin firebase_app_di..

Android 2022.04.11 0
반응형