1년만에 작성하는 회고글 입니다.
왜 회고를 하게 되었나요 ?
저는 최근 MBTI 검사 결과 P (무계획인 사람) 94%가 나왔습니다. 항상 100%를 유지했는데 조금은 계획적으로 성장했네요. (농담..🥲) 하지만 이런 저라도 정리를 해야겠다 싶었습니다. 인턴 회고도 아닌, 무언가의 합격 회고도 아닌 겨우 동아리 회고를 하게 된 이유는 이렇습니다.
어느덧 1년이 다 되어가지만, 현재까지도 꾸준하게 서비스를 유지하고 있는 팀입니다. 저는 이 iOS 개발 공부를 시작한지 1년이 다 되었는데, 혼자 개발을 했다면 이룰수 없는 성장 이었을 것입니다. 만약 제가 iOS 분야로 취업을 한다면 이 프로젝트에서 배운것이 저의 시작점이라고 느꼈기 때문입니다.
실제로 저는 올해 초에 짧지만, 인턴 기간동안 iOS 현업을 경험했고, 이 프로젝트에서 배운 것을 실무에 적용할 기회를 얻었습니다. 생각보다 제가 이곳에서 배운것이 많았고, 이것저것 부딪쳐보다보니 막히는 것이 있더라도 해결할 수 있다는 자신감이 있었습니다.
저는 운이 좋아서 좋은 팀을 만났다고 생각합니다. 하지만, 이런 운을 얻기 위해서 여러 활동들을 달려왔고, 좋은 기회가 왔을때 제가 그곳에 있었다고 생각합니다.
제가 활동 기간동안 작성한 코드의 줄 수는 3만 6천 줄입니다. 저의 회고는 노력기반으로 작성할 것입니다. 모든 배움은 저의 노력으로부터 출발했고, 노력호소인의 글 시작합니다. 재밌게 읽어주세요 😇
깃허브 주소입니다.
면접의 기억으로 돌아가 보려고 합니다
면접을 보던 시기는 제가 iOS 개발을 시작한지 2–3개월 정도 되던 시기였습니다. 넥스터즈 동아리는 잘하는 사람이 많다는 소문이 많아서, 너무 붙고 싶었습니다.
분명 저는 당시에 View도 잘 못 만들고, 아키텍쳐도 잘 모르고 모르는 것 투성이었지만 걱정은 없었습니다. 왜냐면 열심히 노력할 자신이 있었고 열정은 지지 않는다고 생각했습니다. 솔직히 말하면 당시에 팀플을 할 정도의 실력은 아니었다고 생각합니다. 하지만, 끝까지 가면 제가 팀에 좋은 역할을 하고 있을 거라고 확신했습니다. 처음 마음가짐 그대로 끝까지 가져갈 수 있다고 생각했습니다.
면접 30분 전에 일어나서 얼른 씻고 모니터 앞에 앉았습니다. 이때는 면접 준비를 많이 하지 못했습니다. 한다고는 했는데, 기술 면접을 어떻게 준비해야하는지 몰랐고 당시에 원리를 이해하고 개발하기 보다는 일단 돌아가는 코드를 작성하고 이해해보려는 단계 였습니다. 역시 깊이 있게 공부하지 않았다는 것은 이런 면접과정에서 다 드러났습니다. 제가 답변을 못했던 부분은 너무나도 기초적인 질문이었습니다.
- SOLID 원칙
- RxSwift에서 bind와 subscribe의 차이
잘한점: 면접이 끝나고 찾아서 공부를 했다는 점
못한점: 아주 기초적인 공부가 안되어 있던 점
저는 면접이 떨어졌다고 생각했습니다. 하지만 면접이 떨어지더라도 좋은 경험으로 가져가고 싶어서 면접이 끝나고 대답 못했던 부분을 찾아보고 공부하였습니다. 슬퍼하지 말고 앞으로 나아가면 됩니다. 왜냐면 동아리는 넘쳐나고, 회사도 넘쳐 납니다. 내가 잘하는 사람이라면 기회가 넘쳐 납니다.
감당할 수 있다면 하고싶은대로 하자
사실 저는 당시에 CMC 라는 동아리에서 iOS 개발을 하고 있었습니다. 여기에서는 혼자 개발을 했고, 이 동아리와 넥스터즈 동아리가 한달 정도 기간이 겹치는 것을 알고 있었습니다.
그때의 저는 혼자 개발하다보니, 이렇게 하는게 맞나 ? 싶은 점이 매순간 있었습니다. 누군가와 같이 개발을 한다면 너무 좋겠다 싶었습니다. 하지만 이미 하고 있는 동아리가 안끝난 상태에서 다른 동아리를 한다는 것이 마음에 걸렸습니다. 도의적으로 맞는 것인가 싶었습니다.
그래서 팀장님께 사실대로 말씀을 드렸습니다. 제가 개발을 더 배우고 싶어서 다른 동아리에 들어가고 싶은데 일정이 한달 정도 겹치는데 지원을 해도 되겠냐고 여쭤봤습니다. 저는 여기 이 동아리의 개발을 밀리지 않고 다 해내겠다고 말씀 드렸습니다. 다행히 허락을 해주셨고, 지금 생각해보면 스스로가 감당이 가능하면 허락을 맡지 않아도 되는 일이 었습니다. 저는 당시에 이런 행동이 양다리를 걸치는 일이라고 생각해서 머뭇거렸는데, 저와 같은 고민이 있다면 책임을 질 수 있으면, 하고싶은대로 하라고 조언 해드리고 싶습니다.
사실 동아리가 토요일 일정이어서 이날이 겹치는 것 때문에 고민을 했던 것이지, 제 일정상 하고 있던 활동은 더 있었습니다. 스마일 게이트 AI 멤버십, 42서울 본 과정, SW마에스트로 Expert 였습니다. 거기에 동아리 2개와 사이드 프로젝트를 하고 있었는데, 이 당시에 저는 지금 생각해도 믿기 힘들정도의 삶을 살았습니다. 밤을 너무 많이 샜고, 너무 힘들었습니다. 🥲 하지만 울지는 않았습니다. 왜냐면 열심히 사는 것 같아서 좋았기 때문입니다.
잘한점: 욕심을 내서, 동아리 두개를 참여한 점과, 이 사실을 팀원들한테 잘 말한점, 고민을 혼자하지 않고 팀장님과 같이 한점. 벌인 일에 대한 책임을 지고 두 동아리 모두 출시를 완료 한점.
못한점: 너무 무리한 일정을 가져가려 한점. 몸을 너무 혹사 시킨 점. (사실 이때 밤을 엄청 샜습니다. 죽는 줄 알았어요.)
코드 리뷰는 상대방이 그만큼의 시간을 나에게 투자해주는 것을 깨달았습니다
처음에 저는 막연한 두려움이 있었습니다. git을 잘 다룰줄 몰랐고, github는 그냥 파일을 저장하는 용도로만 사용하고 있었습니다. <code> 탭에서 벗어난 적이 없었습니다.
같은 팀으로 활동했던 누나는 현업자셨는데, 저에게 아주 많은 것들을 알려주셨습니다. issue를 생성하는 것과 branch를 어떻게 만들어야 할지, PR을 왜 사용해야하는지 등등 아이패드를 꺼내서 그림을 그려가며 설명해주셨는데, 감사합니다. 배울 점이 너무 많았고, 저도 누군가에게 도움을 주고싶다는 생각이 들었습니다.
제 코드가 남한테 보여진다는 것이 좀 두려웠습니다. 이제부터 작성하는 모든 코드들이 다른사람이 꼼꼼하게 읽을 생각에 떨렸습니다. 저의 실력이 탄로나면 어쩌지 하는 마음이 컸습니다. 처음에 한 1–2주 동안은 리뷰를 받기만 했었습니다. 제가 감히 어떻게.. 선배님 코드에 토를 달 수 있을까 ? 하는 마음이었습니다.
상대방의 코드를 리뷰하는 것은 꽤 많은 시간 투자가 필요한 일임을 알게 되었습니다. 그리고 그 사람의 잘못된 점을 부각시키려는 목적이 아니라, 더 좋은 방향으로 도와주려고 하는 일임을 깨닫게 되었습니다.
반면 저는 제 시간을 리뷰에 쓰지 않고 있었던 것이었습니다. 그래서 제가 틀리든 맞든, 저의 생각을 전달하려고 노력했습니다. 나름대로 고민을 많이 해보고 리뷰를 진행했습니다. 이렇게 저의 생각이 공유되면 한번 더 생각하고 넘어갈 수 있어서 그 자체로 의미가 있었습니다.
잘한점: 초반에 모르는 것을 많이 물어보고 배우려는 자세를 가진점
못한점: 가끔은 그냥 넘어간 것도 있었음. 직접 브랜치로 들어가서 한번 돌려보면서 꼼꼼하게 살펴볼 수 있었는데 눈으로만 거의 확인한 점.
현재 실력에 비해 너무 어려운 View를 담당했을 때 해결하는 법
제가 살면서 이것보다 어려운 View를 마주칠 수 있을까요 ? 물론 있겠지만, 당시에 저의 실력에 비해 너무 어려운 View를 담당하게 되었습니다. 사실 이 화면을 보고 만들어보고 싶다는 도전 정신이 들어서 제가 만들겠다고 했습니다.
UICollectionView는 반복되는 모든 View들을 작성할 수 있다는 사실을 알게되었습니다. 활용범위가 너무 넓고, 아주 많은 것들을 할 수 있었습니다. 처음 구조는 Cell안에 Cell을 집어넣으려고 코드를 작성했지만, 단순 생각해봐도 이 구조는 너무나 많은 복잡성을 요구해서 잘못된 접근법인 것을 깨달았습니다. 어떻게 해결할 수 있을지, 누나와 많이 얘기했던게 생각이 납니다. 저는 CompositionLayout을 알게 되었고 꽤 복잡한 것들을 단순하게 처리할 수 있었습니다. 문제점은 ReactorKit을 사용중이었어서, Cell안에 Reactor을 넣고, CompositionLayout으로 구성하는 것이 어려웠습니다.
정규세션이 토요일이었는데, 이 뷰를 끝내고 활동을 참여하고 싶었습니다. 그래서 금요일 새벽까지 밤을 새다가 잠깐 졸았는데, 세션에 1시간 정도 늦게 도착했었습니다.
어려운 것을 마치면 얻는 것은 자신감이었습니다. 저에게는 두가지의 자신감이 생겼는데요. 첫번째로는 이것보다 쉬운 View들은 금방 만든다. 두번째로는 어려운 View도 만들 수 있다. 라는 자신감이었습니다.
UI를 만드는 개발자로서 View에 대한 자신감을 갖게 되었고, 이 이후부터는 다양한 것들에 관심을 두기 시작했습니다. 실력적인 여유가 생겼어서, CI/CD 라던가, Architecture, Network, Moduler 등등 어떻게 하면 더 잘 코드를 구성할 수 있을지에 대한 고민을 하기 시작했습니다.
이 View를 만드는데 30시간 이상을 쏟아부었습니다. 저에게는 너무 벅찬 작업이었고 힘들었습니다. 하지만 완성했을때 그 이상의 뿌듯함과 성장이 있었고, 저는 이 화면을 개발하게 된 것이 좋은 기회였다고 생각합니다. (지금 보니깐 실선 사이에 틈이 생겨버렸네요 .. 전에 이거 고치다가 실수한듯.. 이거 회고글 다 쓰고 고쳐보겠습니다.. 🥲)
더 좋은 코드를 발견했지만 적용하기 위해선 다 뒤집어 엎어야 하는 상황에서 어떻게 했나요 ?
저희는 ReactorKit을 사용하고 있었는데, DI 문제점과 Navigation 문제점이 항상 해소되지 않았습니다. 다음 뷰로 넘어가는 것을 어떻게 하면 잘 작성할 수 있을까 에 대한 고민을 하다 하다가 ReactorKit을 만드신 전수열님의 reactorKit 예제 코드에서 CompositionRoot라는 파일을 발견했습니다. 이 개념에 대한 충분한 이해가 없었고, 코드를 읽어봤을때 모든 것을 여기에서 다 생성하고 주입하고 있었습니다.
당시에는 이 방식을 적용하는 것이 지금 코드보다 더 나아가는 방향이라고 생각했습니다. 하지만 일이 너무 많았습니다. 왜냐면, 뷰는 거의 다 작성이 끝났고 네트워크를 연결하고 있던 시기였어서 고민을 했습니다. 새로운 것을 적용할것인지 아니면 그냥 기존꺼로 갈 것인지. 그래서 저는 제가 다 뒤집어 엎어보기로 했습니다. 먼저 제가 작성한 모든 코드들 부터 적용해서 예제를 만들고 팀원의 코드를 서서히 적용시켜나가면 되겠다고 생각했습니다.
생각보다 너무나도 큰 작업이었습니다. 그리고 너무 많은 시행착오를 겪었습니다. escaping 문도 제대로 이해하지 않은 채로 실 적용부터 했고, 헤매고 헤매다가 PR이 너무 커져버렸습니다. 파일이 43개가 변경이 되었는데 작게 변경된것도 아니고 큼지막하게 변경이 있었습니다. 이건 아주 죄송스러운 일이었습니다.
어쩌면 이 결정은 좋은 결정이 아니었을 수도 있습니다. 왜냐면 중간에 좋은 코드를 발견했더라도 그냥 하던대로 짜고, 넘어갈 수도 있었는데 출시가 미뤄진 상황에서 코드의 품질까지 신경쓸 필요는 없었기 때문입니다. 하지만, 마음에 너무 걸렸어요. 차라리 이 코드를 발견하지나 말지. 봤는데 모른척하기가 제 성격상 너무 어려운 일이었습니다. 저는 그냥 통째로 갈아 엎어버렸습니다. 다른 것은 모르겠고, 노력으로 해결가능한 범위라고 생각했습니다. 아마도 이거는 15시간이 넘는 작업이었을 거예요.
잘한점: 앞으로부터는 PR을 쪼개는 습관을 들인점. 스스로와 타협하지 않고 코드를 다 뒤집어 엎어버린점.
못한점: 혼자서 다 뒤집어 엎어버리려 한 점. 서서히 변경하는 다른 방법들도 있었는데, 급하게 적용시키려 한 점. 팀원간의 충분한 협의가 없었음. (누나 내가 이거 한번 고쳐볼게. 정도 였음.)
많은 실패 끝에 CI/CD를 해결했고, 부딪히는 노력을 좋아하기로 했습니다
당시에 ‘두려움 없이’ 라는 키워드에 꽂혀서 이렇게 앞에다가 붙였는데, 다들 그냥 딱 제가 글 쓴 것 같다고 말해주었습니다. 길을 걷다가 헤이딜러 ? 광고 판에서 본 문구가 너무 멋있어서 그때부터 꽂혔습니다.
‘두려움 없이. iOS 시작하기.’ 나중에 책 제목이 이렇게 출판된다면 제가 책을 낸것이라고 생각해주세요. 😇
62번 정도의 실패가 있었고, 저는 로컬에서는 잘 동작했던게 머신에서는 잘 안돌아갔던 이유를 못 찾았었습니다. 샤워를 하던 도중 생각이 머신에서 키체인에 인증서들을 저장하지 않았다는 사실을 깨닫고 이부분을 추가해주었고 동작이 되었습니다. (평상시에 이런 개발 생각만 하면서 살진 않습니다.. 한때 스트레스였어서 이렇게 된거입니다.)
3일 정도 동안 아무 진전이 없었고, 주말동안 진전이 하나도 없었을때는 조금 속상했습니다. 참고자료가 너무 없다보니깐, 제가 혼자 해결하는 수밖에 없었습니다.
잘한점: 포기하지 않고 끝까지 무언가를 해결해보려 한 점
못한점: 주변에 도움을 구하지 않아본 점
일을 키우는 사람도 저였고, 감당해야 할 사람도 저였고, 많이 배워가는 것도 저였습니다
저는 일을 할 때 다 할 수 있다고 말하는 사람이었습니다. 그러다 보니 개발해야할 양은 너무 많아졌고, 결국 누군가는 책임을 져야 했습니다. 적당한 타협이 있어야 했지만 저의 당시 개발 실력에 비해서 너무 많은 책임이었고 감당할 수 있다고 생각했습니다.
사실 요즘 프로젝트에서도 이러고 있는 것을 보면, 저는 원래부터 일을 키우는 사람이고 이것을 고칠 생각이 없습니다. 그래서 제 주변에는 브레이크 역할을 하는 사람이 필요하고, 브레이크 역할을 하는 사람이 있다면 엑셀을 밟는 사람이 필요하다고 생각하고 그게 저의 역할이 아닐까 라는 생각을 했습니다.
현재 새로운 동아리에서도 일을 키우는 역할을 담당했습니다. 저는 제가 아닌 다른 사람들이 하는 프로젝트는 일을 줄이려고 피드백을 하는데, 제가 참여하는 프로젝트는 일을 키우려는 피드백만 합니다. 저의 경험상 일을 키우면, 배워가는 것이 많았습니다. (어쩌면 당연할지도..)
저는 오히려 걱정입니다. 저의 이런 마인드가 언젠가는 현실이랑 타협하면서 꺾일텐데, 그러기는 너무 싫을 것 같아요. 미래의 저는 일을 키우는 사람으로 남아있었으면 좋겠습니다.
좋은점: 일을 키운점. 스스로를 좋게 생각한점.
못한점: 팀원을 생각하면서 일을 키웠어야 했는데, 당시에 너무 하겠다고만 말했던 점이 못했습니다.
회고 후기
이렇게 까지 회고한 적은 처음이지만, 제게는 너무 좋은 경험이었습니다. 회고를 하면서 좋은 점은 무엇을 배웠고, 앞으로 어떤 마음으로 나아가야 할지였습니다. 긴 글 읽어주셔서 감사합니다.
이제 iOS 공부 1년차이기 때문에 앞으로 더 성장해서, iOS 생태계에 큰 기여를 하고 싶습니다.
