나는 왜 앱 대신 환경을 만들고 있었을까

아카데미에서 보낸 시간은, 앱을 만든 시간이라기보다는 환경을 만든 시간이었던 것 같다. 개발자라면 ‘앱을 잘 만드는 것’, ‘탄탄한 CS 지식을 쌓는 것’이 우선이 되어야 하지 않을까? 그런데 나는 왜 브랜치 전략을 고민하고, 커밋 규칙을 문서화하며, 자동화 스크립트를 짜고 있었을까?

이 회고는 그 의문에서 출발한다. 내가 무엇을 좋아했고, 어떤 일을 반복했으며, 어떤 갈증을 느꼈는지에 대한 기록이다. 앱을 잘 만드는 것보다 흐름을 만들어 내는 것이 더 좋았던 나의 이야기이다.

1. 프렐류드: 브랜치 전략의 시작#

아카데미 입학 직후인, 프렐류드 기간. 한 러너가 나에게 물었다.

“현업 했으면 GitFlow 써봤어요? 나 GitFlow 좀 알려줘요.”

GitFlow? 브랜치 전략? 당연히 적용해봤고, 써봤다. 그런데 알려달라는 말에 선뜻 대답하기가 어려웠다. 어느정도 규모의 프로젝트를 하시려는 걸까? 프로젝트 규모에 따라 브랜치 전략은 달라지지 않나? 심지어 이야기를 듣자하니 1인 개발인 것 같은데 굳이 필요한가? 괜히 내 조언으로, 귀찮은 절차만 생기는 거 아닌가?

평소엔 그냥 넘겼을 질문인데, 그날따라 꽂혔다. 혼자서 빠르게 개발하고 싶다면 오히려 브랜치 전략이 독이 되지 않을까?

그런데 동시에 묘한 감정이 올라왔다. 이미 3년차 개발자가 되어버렸고, 팀에서도 프로젝트에 Git 전략을 정하고 힘들지 않게 ‘적용’해왔었다. 그런데 막상 누군가 내게 브랜치 전략을 물었을 때, 설명을 망설이고 있는 나를 보며 문득 스스로를 의심하게 됐다.

“나 정말 이걸 잘 알고 있는 걸까?”

익숙하다고 생각했던 것이 실은 깊이 이해하지 못한 영역일지도 모른다는 감각. 그 순간, 약간의 임포스터 증후군과 비슷한 찜찜함이 스쳤다.

그 질문은 단순한 기술적 고민을 넘어서, 나의 ‘기초 체력’을 돌아보게 했다. 그리고 어쩌면 그게, 내가 환경을 다시 뜯어보려 했던 첫 출발점이었는지도 모른다.

2. C1: Swift도 낯선데, 왜 나는 린트를 고민했을까#

Swift는 오랜만이었다. 예전에 조금 다뤘을 땐 UIKit이 전부였는데, 이제는 SwiftUI라는 녀석이 새 얼굴처럼 반기더라. 모두가 낯설었고, 나도 낯설었다. 그런데 그런 와중에도 나는 lint부터 살폈다.

C1은 공식적으로는 앱 산출물이 나오지 않아도 괜찮은 유일한 챌린지다. 다만 팀원들이 앱 산출물을 원하면 이야기는 달라진다. 우리 팀은 짧은 개발기간(2일) 동안 iOS 앱을 만들기로 했고, 간단한 브랜치 전략과 PR을 통한 코드 통합을 하자고 구두 약속을 나누며 협업을 시작했다.

PR을 살피면서, 간단한 문제점들이 보였다. id로 할 건지, ID로 할 건지… 변수명이 통일되지 않았고, PascalCase의 파일명 사이에 누군가의 파일명은 camelCase였다.

말을 꺼냈다. “Swift는 파일명을 Pascal로 짓는 게 맞아요, 그리고 변수명도 수정해주세요.” 그런데 설명하고 납득시키는 게 생각보다 에너지가 많이 든다. 그러다 문득 든 생각.

‘그냥 이 정도는 나 말고 린트가 말해주면 좋지 않을까?’

그래서 SwiftLint와 SwiftFormat을 찾아보고 적용하기로 했다. 규칙이 있으면, 사람은 덜 싸운다. 이건 내가 팀에서 반복해 겪어온 깨달음이기도 했다.

3. C2: gh-yaml-sync의 탄생과 자동화의 필요성#

C2는 개인 프로젝트 챌린지였고, 나는 본격적으로 세팅쟁이가 되기로 했다. 전에 다녔던 회사에서 쓰던 협업 프로세스들을 떠올렸다. 커밋 템플릿, PR 규칙, 마일스톤 설계… 더불어 이전 챌린지의 경험으로 새로 학습한 swift의 lint와 format까지. 익숙한 것들을 하나하나 복원하고 적용하면서 완전히 내 것으로 만들고 싶었다.

그런데, 혼자 하려니 번거롭다. 누군가 만들어주던 마일스톤과 이슈를 내가 전부 만들고, 브랜치 따고… 무의미한 클릭들이 너무 많게 느껴졌다.

그래서 gh-yaml-sync라는 npm 프로젝트를 만들었다. YAML로 마일스톤과 이슈를 정의해 한번에 등록하는 CLI. 별 거 아닌 도구였지만, 반복되는 수고를 덜어주는 건 언제나 짜릿했다.

그때쯤, 나와 비슷한 고민을 하는 팀들을 자주 보게 됐다. Git이 아직 낯설거나 브랜치 전략을 어렵게 느끼는 사람들. 그래서 소규모로 Git 실습형 강의를 열었다.
협업 흐름에서 Git을 어떻게 써야 덜 막히는지를 중심으로, 현업에서의 경험을 바탕으로 설명했다. ‘코드만 잘 쓰는 사람’이 아니라, ‘코드를 같이 쓰기 쉽게 만드는 사람’이 되고 싶었다.

4. C3: 강제화 실험 – 커밋 메시지, 브랜치 네이밍#

C3부터는 다시 팀 프로젝트. 연습한 것들을 실전에서 써볼 차례였다. 규칙을 만들고, 문서를 쓰고, 이제는 지키게 만들어야겠다는 생각이 들었다.

그래서 shell script를 이용해 pre-commit 훅을 작성했다. 커밋 메시지가 규격에 맞지 않으면 커밋 자체가 안 되도록 만들었다. 문서 내에 브랜치 전략을 설명했고, SwiftFormat으로 코드 스타일도 맞췄다.

그런데… 그래도 사람은 실수한다.

브랜치 이름에 # 붙이고
PascalCase로 써버리고
develop에 PR 없이 직접 push하고…

그래서 remote에서도 막아야겠다는 결론. GitHub Branch Ruleset을 학습했고, 보호 브랜치의 개념을 익혔다.

5. C4: Ruleset과 Makefile을 통한 “누구나 개발자처럼”의 시도#

강제화만으로는 충분하지 않았다. 사람은 실수한다. 그렇다면 비개발자는 어떨까?

C4에서는 비개발자 팀원의 참여도가 높았던 만큼, 자동화가 더욱 중요했다. 또, C3 때 매번 팀원 있는 곳으로 출장을 가서 환경 세팅을 도와주는 일이 꽤나 에너지가 들었던 기억이 강렬했던 터라… shell script보다 직관적인 Makefile을 도입했다. make setup 한 줄이면 커밋 훅, SwiftLint, SwiftFormat까지 자동으로 세팅되게 만들었다.

이건 꽤 반응이 좋았다. 개발 경험이 없던 팀원도 “이제 나도 뭔가 개발하는 느낌이 들어요”라고 말했다. 팀 전체가 같은 규칙을 공유하는 순간, 팀워크가 단단해지는 느낌이 있었다.

6. 나는 앱 개발자가 맞나?#

그럼에도 문제는 계속 생겼다. Xcode 프로젝트 파일은 팀원마다 자꾸 달라졌고, 빌드 실패도 반복됐다. 누군가는 기존 프로젝트를 삭제한 뒤 다시 clone을 받았지만, Makefile 실행을 빠뜨리는 순간 ‘강제화 시스템’은 무력해졌다.

처음엔 당황했지만, 곧 받아들이게 됐다.
다음번엔 clone 직후 자동으로 스크립트를 실행하게 할 수는 없을까?
그런 즐거운 질문들이 하나둘 떠오르기 시작했다.

팀원들을 계속 괴롭히던 의존성 문제를 해결하기 위해 Tuist라는 도구를 탐색했다. 프로젝트 파일 충돌 문제를 해소하고, 팀원마다 달랐던 설정도 일관되게 만들 수 있다는 점에서 매력적인 해결책이었다.

하지만 테스트 과정에서 기존 Build Script에 연결된 SwiftFormat이 제대로 작동하지 않는 문제를 발견했다. Tuist와 기존 세팅을 함께 사용하려면 더 많은 학습과 테스트가 필요했고, 완전한 해결까지는 아직 갈 길이 남아 있었다. 결국 이건 다음 챌린지로 미뤄진 숙제가 되었다.

환경을 고치고, 구조를 다듬고, 자동화를 붙이고… 그 모든 과정을 거친 끝에 문득, 이런 생각이 들었다.

나는 앱 개발자가 맞나?

7. 나는 왜 앱을 만드는 대신 환경을 만들고 있었을까?#

앱을 만드는 시간보다, 흐름을 만드는 시간이 길었다. 문서 쓰고, CLI 만들고, 린트 강제화하고…

왜?

생각보다 대답은 간단했다. 이게 더 재밌었기 때문이다.

개발에 참여하고 싶어하는 디자이너와 기획자가 스크립트 한 줄로 환경을 셋업하는 걸 보면 짜릿했다. 그 작은 개선들이 팀 전체의 리듬을 바꾸는 순간, 묘한 성취감이 들었다.

문제에 대응하고, 흐름을 설계하며, 협업이 매끄럽게 이어지는 구조를 만드는 것. 그 과정에서 나는 ‘앱’보다 ‘구조’를 더 좋아하는 사람이란 걸 알게 됐다. iOS의 단축어를 이용해 출석 앱 자동 실행 방법을 정리해 알린 것도, GitHub 템플릿을 만들어 배포한 것도 모두 그런 맥락이었을지도 모른다. 불편을 줄이면, 그만큼 하고 싶은 일에 집중할 수 있으니까.

비로소 내 관심의 방향이 명확해졌다. 내가 가장 몰입했던 순간은 결국 ‘일이 잘 굴러가게 만드는 일’에 있었다.

8. 나는 결국 무엇이 되고 싶었던 걸까?#

C5가 끝날 무렵, 다시 처음으로 돌아갔다. 나는 아카데미가 끝나고 다시 단순한 앱 개발자가 되도 괜찮은 걸까?

DevOps라는 단어가 떠올랐고, 그 순간 오랜만에 배움에 대한 열정이 피어올랐다. 환경을 만들고 흐름을 설계하는 일, 그게 내게는 진짜 ‘재미’였다. 하지만 동시에 불안했다. 나는 CS 지식도, 인프라 경험도 부족하다. 이건 그냥 일시적인 도피일까?

그럼에도, 나는 알고 있다. 모두가 나 때문에 더 수월해졌다고 느끼는 순간들. 시스템이 스스로 작동하는 모습을 지켜보며 느낀 짜릿함. 그것은 단순한 앱 출시보다 오래 남았고, 더 깊이 몰입하게 했다.

나는 이제 무엇을 해야 할까?
정답은 아직 없다. 다만, 적어도 나는 내가 언제 몰입하는 사람인지를 알게 되었다.
그걸 중심으로, 다시 나아가 보면 된다.