C4가 오늘 부스 활동 끝으로 마무리되었다.
아카데미 기간이 140일도 채 남지 않았다. C6까지밖에 챌린지가 없다는 현실이 실감나면서 "아, 이제 정말 마무리를 향해 가고 있구나"하는 생각이 들었다. 취준을 제대로 시작하려면 남은 시간 동안 얼마나 많은 성장을 이뤄낼 수 있을지가 관건일 텐데.
그런 생각들이 꼬리에 꼬리를 물면서, 문득 이전까지는 별로 와닿지 않았던 회고의 필요성이 절실하게 느껴졌다. 그냥 "해야 한다"는 의무감이 아니라, 정말로 "이 경험들을 놓치면 안 되겠다"는 마음으로.
그래서 이번 회고를 통해서는 정말 C4를 통해 어떤 것들을 배웠는지 잘 정리하고 가려고 한다. 그 과정에서 아쉬웠던 점들도 솔직하게 되돌아보면서, 다음 챌린지에서는 좀 더 나은 모습으로 임할 수 있도록 말이다.
먼저 C4를 통해서 배운 점들부터 차근차근 정리해보자.
기술스택 정하기
일단 기술스택을 정해야 했다. Apple Academy 내에서 UI 구현은 SwiftUI로 정해져 있었고, 그 외의 것들을 결정해야 했다.
아키텍처 패턴, 데이터 저장방식, 비동기 처리 방식 등 여러 방식들에 대해서 "왜 이걸 써야 하는지?", "어떤 게 더 효율적인지?"에 대해 각자 하루 동안 조사를 해왔다.
그리고 세션 시간에 이를 공유하면서 하나씩 정리해나갈 수 있었다. 단순히 "이거 쓰자"가 아니라, 각각의 선택에 대한 근거와 장단점을 함께 논의하는 과정이 좋았다.
개발에서의 협업
이번에는 좀 더 개발을 각각 완성해서 붙이는 퍼즐형식이 아니라, 함께 맞춰가는 토의가 같이 이루어졌다.
단순히 누군가 "이렇게 만들어왔어요! 이렇게 할게요!" 하던게 아니라, 실제로 함께 고민하는 과정들 말이다.
간단한 예시를 들어보자.
isFirstShoot과 guide의 nil 여부에 대한 논의가 있었다. isFirstShoot이라는 Bool 값을 다음 페이지로 넘겨주는 경우가 있었는데, 첫번째 클립 영상을 기반으로 프레임을 따주고, 윤곽선 오버레이가 있는 카메라와 없는 카메라에 대한 분기 처리를 하기 위함이었다.
이걸 그냥 이렇게 쓰자!가 아니라
이미 guide라는 첫번째 클립에 대한 기울기, 높이, 윤곽선 정보가 다 들어있는데... 그러면 파라미터 guide를 nil로 해주고, guide의 존재 여부만으로 판단한다면 isFirstShoot이 필요 없는 거 아닌가?
이런식으로 세션 시간에는 코딩을 하기보다는 어떤 게 더 효율적이고 이상적인가?에 대한 의견을 나누는 시간이 되었던 것 같다.
아쉬운 점도 있었다. 아직 경험이 많지 않아서 정말 효율적이고 이상적인 코드에 대해 고민해본 경험이 적다는 것이다. 이런 아쉬움을 느끼면서 더 많은 것들을 경험하고 싶다는 욕심이 생기기도 했다.
아키텍처 패턴 MVVM
이번 챌린지에서 MVVM을 경험할 수 있었던 점이 좋았다. 웹 개발 당시에는 그냥 간단하게 View/Components/Static 정도로, 내가 확연히 구분되는 정도로만 분리를 진행했었는데, 이번에는 Manager와 ViewModel, View를 분리하여 각각의 역할과 책임을 구분하고자 했다.
처음에는 좀 번거롭기도 하고, 스프린트 기한이 빡빡해서 일단 돌아가는 코드가 중요한게 아닌가? 생각을 잠시 했지만 몇 번의 오류를 잡으면서, 혹은 기능을 추가하고 디자인 변경 사항을 반영할 때마다 차이를 느낄 수 있었다.
이전에는 엄청난 덩어리의 파일 속에서 억지로 분리해놓은 주석을 찾고, 스크롤을 거듭하면서 어렵게 수정해나갔다면...
이번에는 확실하게 분리가 되어있다 보니 이런 공수가 확연히 줄어든 게 느껴졌다. 어디를 수정해야 할지 명확하고, 다른 부분에 영향을 주지 않고 독립적으로 작업할 수 있어서 유지보수 측면에서 정말 큰 차이를 경험했다.
유동적인 패턴 ?!
결국 이렇게 패턴 사용의 장점들을 정말 크게 느끼면서도 한편으로는 아쉬움이 남기도 했다. 아직 여러 패턴에 대한 정보가 없어서 더 나은 코드 구조를 만들기 위한 움직임을 수행하기에는 경직되어 있었다는 점이다.
설명을 덧붙이자면, 카메라 View를 구성할 때 CameraViewModel, CameraManager, CameraView 이렇게 나눈 채로 개발을 수행했을 때를 사례로 들 수 있을 것 같다.
물론 SubViews라는 폴더를 만들어서 관리를 해주긴 했지만, 문제는 이 SubViews 폴더 안에 무분별하게 많은 파일이 들어가 있었다는 점이다.
방 청소가 아니라 그냥 서랍 안에 다 짱박은 느낌이 들기도..
간단히 우리 앱의 카메라 View를 가져와서 보면 다음과 같다.
CameraView 안에는 촬영 Frame을 담당하는 VideoPreviewView, 상단의 기본 카메라 기능들을 설정할 수 있게 도와주는 CameraBaseFeatureSelectView, 하단의 RecordView 외에도 타이머 설정에 따른 카운트다운, 수평계, 초점/노출 설정, Zoom 설정을 위한 View들이 존재했다.
디렉토리 구조를 가져오자면 다음과 같다.
Presentation/Camera/SubViews/ ├── CameraBaseFeatureSelectView.swift ├── CameraBottomControlView.swift ├── CameraDefaultTopControlView.swift ├── CameraRecordView.swift ├── CameraTopControlView.swift ├── CameraZoomControlView.swift ├── CircleIconButton.swift ├── HorizontalLevelIndicator.swift ├── RecordButton.swift ├── ZoomButton.swift ├── ZoomButtonGestureModifier.swift └── ZoomSlider.swift
결과적으로 Presentation/Camera/CameraView만 있어야 했던 게 정말 많은 SubView가 탄생하게 되었다. "일단 분리하자"는 생각으로 접근하다 보니 각 컴포넌트를 어떤 기준으로 분리할지에 대한 명확한 가이드라인 없이 파일만 많아지고 전체적인 구조를 파악하기 어려워진 느낌이었다.
문제점
- 계층 관계 불명확: 부모-자식 관계가 있는 View들이 같은 레벨에 위치
- 기능별 분류의 부재: UI 오버레이와 하드웨어 컨트롤이 섞여 있음
- 확장성?!: 카메라 관련 기능들이 추가될수록 분리된 파일내에서도 늘어나는 파일과 길어지는 파일..
개선을 해보자면..!
그래서 SubView들을 역할과 기능에 따라 한 번 더 재구성이 필요하다고 느꼈다.
이제 여기에서 어떤 기준으로 나눌것이냐? 가 또 설계상 고민해볼점이라고 생각을 하는데, 일단 CameraView파트에서는 다음과 같이 느꼈다.
CameraPreview와 Camera를 나누자! 여기서 CameraPreview란 카메라의 뷰파인더라고 이해하시면된다. 촬영되는게 유저에게 보여지는 Frame부분과 카메라View를 분리하는 것이다.
개선 설계도
1. CameraPreview
Camera뷰파인더 위에 표시되어야만하는 시각적 요소들
- Grid
- 초점 포인트
- 타이머 카운트다운
- 수평계
2. CameraView
카메라 하드웨어 설정을 직접 제어하는 요소들
- 전환 버튼
- 녹화 컨트롤
- 줌 설정
약간 소프트한 설정들은 Preview 위에, 카메라 전환/녹화/줌과 같은 하드 설정들은 Camera에 귀속되는 구조였다.
여기서 "소프트하다"라는 단어를 썼는데, 이 부분에 대해서는 나도 감만 있지 디테일한 기준이 아직 미흡한 것 같아서 이 부분도 좀 고민을 해볼 부분이라 느꼈다.
일단 이렇게 하면 CameraPreview로 나눌 수도 있겠지만, 오히려 CameraControls에 HardSetting과 SoftSetting을 나눠야 하나? 싶으면서도... (이게 결국 View에 포함된 애들이니까 이렇게까지 분리해줄 필요가 없을 것 같기도 하고... 좀 더 고민을 해봐야 할 것 같다.)
결국 이런 고민들이 생겨나는 이유는 명확한 분류 기준이 없었기 때문이었다. 당장 MVVM이니까 일단 View를 분리했는데, 딱 거기까지였던 것이다. 좀 더 유동적으로 변경될 필요성을 깨달았고, 분리의 기준 역시 명확하게 있어야한다는 점 역시 함께 깨달을 수 있었다. 지금 당장 개선안을 이야기할 때도 이렇게 "소프트/하드하다"라는 기준 역시 모호한 것을 보니 이 부분도 결국 다듬어야 하는 것이다. 이런 모호한 기준으로는 일관성 있는 구조가 만들어지기 어렵다는 것을 체감했다.
잘하는 개발자란?
잘하는에 해당하는 게 무엇일까? 항상 고민해왔다. 특히 최근 AI가 어느 정도 양질의 코드를 생산할 수 있게 되면서, 더욱더 경쟁력 있는 개발자가 되려면 어떻게 해야 할지 생각이 많아졌다.
그런데 이제야 조금 깨달은 것이 있다. '잘하는 개발자'라는 기준에는 절댓값이 없고, 그 기준 자체가 계속 변화한다는 것이다.
개인적으로 느낀 건, 이제는 "이걸 못 해봐서 못해"라는 마인드보다는 "안 해봤으니까 해보고 싶다"는 마인드가 더 중요한 것 같다. 새로운 기술이나 도메인에 대한 두려움보다는 호기심이 앞서는 사람. 그리고 정말 처음 접하는 것도 빠르게 습득해서 바로 적용할 수 있는 사람이 강하다고 생각한다.
또 하나는 넓게 볼 줄 아는 능력이다. 단순히 내가 맡은 기능만 구현하는 게 아니라, 전체 프로젝트의 흐름을 파악하고 그 흐름을 이끌어갈 수 있는 시각을 가진 사람. 기술적인 디테일도 중요하지만, 큰 그림을 그리면서 "지금 우리가 어디로 가고 있는지" "다음에 뭘 해야 하는지"를 제시할 수 있는 능력이 점점 더 중요해지는 것 같다.
물론 당연히 기저에 깔려야 하는 건 어느 정도의 개발 실력이다. 아무리 마인드가 좋고 시야가 넓어도, 코드를 제대로 못 짜면 말이 안 되니까. 하지만 그 '어느 정도'의 기준도 예전처럼 모든 걸 완벽하게 알아야 한다는 건 아닌 것 같다.
결국 완벽한 개발자보다는, 계속 성장하려는 의지와 전체를 바라보는 관점을 가진 개발자가 되는 게 목표인 것 같다.
마무리
C4에서 배운 점들을 정리해보니 생각보다 많은 것들이 있었다. 기술적인 부분에서는 MVVM 패턴을 제대로 경험해볼 수 있었고, 협업 과정에서는 단순히 각자 만든 걸 붙이는 게 아니라 함께 고민하고 토의하는 시간들이 정말 값졌다.
특히 팀원들이 너무 친절하게 대해줘서 부족한 부분도 많이 배울 수 있었고, 혼자였다면 그냥 넘어갔을 법한 것들도 함께 깊이 있게 파볼 수 있어서 좋았다. 코드 한 줄 한 줄에 대해서도 "왜 이렇게 했을까?" "더 좋은 방법은 없을까?"를 함께 고민하는 분위기가 정말 인상적이었다.
아직 C5, C6가 남아있다. 이제 아카데미가 130일 정도가 남았는데, 시간이 생각보다 빠르게 지나가고 있어서 조금 아쉽기도 하지만, 그만큼 남은 시간 동안 더 많은 것들을 흡수하고 성장할 수 있도록 노력해야겠다는 생각이 든다.
이번 회고를 통해 내가 어떤 부분에서 성장했는지, 어떤 부분이 아쉬웠는지 정리할 수 있어서 좋았다. C5에서는 이런 아쉬운 점들을 조금이나마 개선해보고, 새로운 도전들도 해볼 수 있기를 기대한다.
