iOS 개발 공부

벌써 7개월, 끝이 보이지 않는 취업 준비취업 준비를 계속하다 보니 어느새 벌써 7~8개월이라는 시간이 지나 있었다. 부스트캠프가 6개월이었는데 그보다 더 긴 시간을 취업 준비에 쓰고 있다는 것이 잘 믿기지 않았다.8기 캠퍼들과는 종종 만났는데 취업에 성공한 친구들은 극소수였고 다들 힘들어했다. 그만큼 취업 시장이 너무 좋지 않았다. 오랜만에 만나서 벌써 부스트캠프 9기가 시작한다는 이야기가 나오자 다들 풀스택 챕터로 다시 들어가야 하나 하는 우스갯소리를 하기도 했다.취업 준비가 길어지다 보니 이제는 더 이상 뭘 해야 할지 모르겠는 상황이 왔다. 1분기에 리멤버 리드님이 다양한 것을 해보라고 조언해주셔서 시중에 나와 있는 앱들을 분석하고 카피해보거나 기술적으로 고민이 필요한 것들을 만들어보기도 했는데, ..

대기업 공채 준비의 시작2분기에도 계속 취업 준비를 이어갔다. 한두 군데를 지원하더라도 채용 프로세스가 워낙 길다 보니 시간이 참 빠르게 지나갔던 것 같다.이때는 주로 대기업 공채 위주로 준비했다. 코딩테스트 준비도 올해 처음 해보는 것이었고 자기소개서도 제대로 써본 적이 없다 보니 하루 종일 코딩테스트와 자기소개서만 붙잡고 있었다.네이버, 카카오, 올리브영 등 여러 곳에 지원했고 서류 전형을 통과한 뒤에는 코딩테스트를 보고 또 면접을 준비했다. 공채는 채용 프로세스의 텀이 굉장히 길어서 한 곳의 결과를 기다리는 동안 또 다른 곳을 준비하다 보면 어느새 시간이 훌쩍 지나가 있었다.다시 카페 아르바이트를 시작하다부스트캠프에 들어오기 전 거의 2년 동안 일했던 카페가 있었는데 그곳에서 취업하기 전까지 다시 ..

취업 준비의 시작, 그리고 얼어붙은 시장부스트캠프를 수료하고 나서 본격적으로 취업 준비를 시작했다. 이력서를 작성하고 코딩테스트와 기술 면접을 준비하며 하루하루를 보냈다.사실 부스트캠프와 취업 사이에서 부스트캠프를 선택했던 이유 중 하나는 대기업과의 취업 연계가 있었기 때문이었다. 그런데 막상 내가 수료했을 때는 상황이 좋지 않았다. 코로나 시기가 끝나면서 IT 업계들이 신입 채용을 하지 않는 시기와 맞물려 기대했던 채용 연계가 없어져버린 것이다.특히 iOS 개발자는 pool 자체가 작다 보니 신입, 주니어, 시니어 할 것 없이 채용 공고 자체가 적었고 그나마 있는 것들도 대부분 미들, 시니어 공고였다. 그래도 나는 주니어와 미들 개발자 공고에 지원했고 그중 몇 곳은 면접까지 볼 수 있었다.첫 과제 전형..

6개월을 마치며그룹프로젝트 발표를 끝으로 6개월간 이어온 네이버 부스트캠프를 모두 수료하게 되었다. 그룹프로젝트 결과물을 공유하는 날이기도 했지만 무엇보다 긴 여정을 마무리하는 날이었기에 정말 감명 깊었다.6개월 동안 주 5일 하루 8시간이 넘는 시간을 기술적 고민과 개발, 그리고 캠퍼들과의 소통으로 보냈는데 이 시간들이 평생 기억에 남을 것 같다.취업 VS 네이버 부스트캠프내가 목표로 했던 것들을 이루고 난 뒤 취업 준비를 하며 최종 면접까지 볼 수 있었고 결과를 기다리던 중 네이버 부스트캠프의 모집 공고를 보게 되었다. 네이버 부스트캠프가 워낙 유명하여 궁금하기도 했고 다른 iOS 개발자들을 만나본 경험이 없었기 때문에 회사에서 불합격한다면 한번 해봐야지 하는 생각으로 지원하게 되었다.그런데 운이 좋..

6주간의 결과물을 공유하는 네트워킹 데이드디어 6주간 개발한 결과물을 공유하는 네트워킹 데이가 되었다. 네트워킹 데이는 오프라인으로 진행되었고 iOS 파트, Android 파트, Frontend 파트 모두가 모여 각자 6주 동안 개발한 결과물을 공유하는 시간이었다.같은 기간 동안 각 파트가 어떤 고민을 하고 어떤 것들을 만들어왔는지 직접 보고 들을 수 있어서 정말 의미 있는 시간이었다. 우리 팀이 만든 것을 다른 파트 사람들에게 보여주는 것도 뿌듯했고 다른 팀들이 만든 결과물을 보면서 자극을 받기도 했다.현업 개발자분들과의 커피챗네트워킹 데이에는 실제 현업 개발자분들과 멘토분들이 오셔서 커피챗을 하는 시간도 가졌다. 취업에 관한 질문이나 현업에서는 실제로 어떻게 개발을 하는지에 대해 편하게 물어볼 수 있..

다른 사람의 작업 이어하기개발을 시작할 당시 우리는 화면 단위로 작업을 나누어서 개발을 진행했다. 그런데 마스터 클래스에서 이렇게 화면을 나누어 개발하는 건 다른 곳에서도 얼마든지 할 수 있으니 페어프로그래밍 같은 것을 한번 고민해보라는 이야기를 들었다.팀원들끼리 이야기한 결과 우리는 서로 작업하던 영역을 바꾸어서 이어서 개발해보기로 했다. 그동안 PR을 통해 다른 사람의 코드를 어느 정도 이해하고 있다고 생각했지만 사실 완벽하게 이해하고 있는 것은 아니었다.막상 작업을 바꾸어서 남이 개발하던 부분을 직접 이어받아 개발해보니 PR만 볼 때와는 이해의 깊이가 완전히 달랐다. 코드를 눈으로 읽는 것과 직접 손대서 수정하는 것은 다르다는 걸 체감했고 덕분에 프로젝트 전체 구조에 대한 이해도가 굉장히 많이 향상..

점점 깊어져가는 뷰들RIBs 아키텍처를 사용하다 보니 뷰를 각각의 리블렛으로 나누게 되었는데 이러다 보니 뷰의 깊이가 점점 깊어지는 문제가 생겼다. 깊이가 깊어지니 하위 리블렛에서 발생한 이벤트를 상위 리블렛으로 보내고 그 상위 리블렛에서 또 상위로 보내는 식으로 이벤트를 계속 타고 올려보내야 했다.이 부분을 stream을 따로 두어서 해결할까도 고민했지만 데이터 전달이 stream을 둘 만큼 자주 일어나지는 않아서 우선은 지금처럼 타고타고 올라가는 방식으로 두는 것이 최선이라고 판단했다.다만 이렇게 이벤트가 여러 리블렛을 거쳐서 올라가다 보니 내가 작성한 코드는 흐름을 알 수 있어도 남이 작성한 코드를 보면 이벤트가 어디서 시작해서 어디로 흘러가는지 한눈에 파악하기가 힘들었다. RIBs로 책임을 잘게 ..

검색 기능, 설계를 몇 번이나 바꿨다이번 주에는 검색 기능을 맡아서 개발했다. 검색은 단순히 검색어를 입력하고 결과를 보여주는 것이라 생각해서 어렵지 않을 줄 알았다. 하지만 막상 개발을 시작하니 검색어를 입력하기 전, 입력하는 중, 입력하고 난 뒤에 각각 다른 화면을 보여줘야 했다.처음엔 이걸 하나의 RIB으로 처리하려고 했다. 굳이 나누지 않아도 상태만 바꿔주면 되겠다고 생각했기 때문이다. 그런데 상태별로 다뤄야 하는 데이터와 UI가 늘어나다 보니 하나의 RIB에 너무 많은 책임이 몰리게 되었다. 정작 모듈 분리와 책임 분리를 위해 RIBs를 선택한 것인데 오히려 massive한 RIB이 되어버린 것이다. 내가 RIBs를 쓰는 이유와 정반대의 결과가 나온 셈이라 여기서 설계를 다시 하기로 했다.그래서..

rxSwift와 combine의 비동기 흐름은 아래와 같다 Observable → 이벤트 생성 → 전달 → Observer RxSwift의 경우Observable → 이벤트 생성 → 전달 → Observer subscribe(on:) observe(on:) 이벤트가 생성되는 쪽의 실행 스레드를 지정해주는 것이 subscribe(on:)생성된 이벤트를 전달받아 처리하는 쪽의 실행 스레드를 지정해주는 것이 observe(on:)이다.Observable .create { observer in // Subscription 영역 } ..