서론 길고 긴 네이버 부스트캠프가 끝이 났습니다. 네이버 부스트캠프의 공식적인 마지막 일정은 12/15였고, 수료식은 12/16였습니다. (벌써 한 달이 지났네요;;) 늦게나마 멤버십 수료 회고를 작성해보려고 합니다. 네이버 부스트캠프를 수료한 저는 어떤 점이 달라졌는지를 중점으로 작성해 볼게요. (네이버 부스트캠프 회고도 이 글이 마지막이겠네요. 물론 프로젝트는 꾸준히 유지보수할 예정이기 때문에 moti의 개발일지는 올라올 거 같아요 🙂) 숲을 보는 문제해결력 먼저 문제 해결에 임하는 태도가 바뀌었습니다. 네이버 부스트캠프 이전에는 문제 해결을 주먹구구식으로 진행했던 거 같아요. 당장의 문제 해결에 급급해서 사이드 이펙트, 전반적인 구조, 근본적인 원인 등을 고민하지 않았고, 단순히 문제 해결이 되면 ..

서론 최근 개발에 치여 포스팅을 많이 못했네요.. 어떻게 하면 더 잘 활용할 수 있을지 고민하는 주였던 거 같습니다. 3, 4주 차 회고를 묶어서 어떤 고민을 했는지 작성해 보겠습니다. 점점 커지는 프로젝트 4주 정도 개발하니 프로젝트가 점점 커지고 있습니다. (물론 현업 개발자분들이 보시면 코웃음 칠 사이즈지만요 ㅎ;) 프로젝트가 커지면서 다른 팀원이 작성한 흐름이 잘 안 보이기도 하고, 제가 작성한 흐름을 까먹기도 하고 있습니다. 어떻게 하면 이런 부작용을 줄일 수 있을까 고민하다 네이밍에 더 신경 쓰기로 했습니다. 아키텍처나 디자인패턴이 답일 수 있겠지만.. 마감까지 2주밖에 안 남은 상태에서는 불가능한 선택지였습니다. 그래서 최소한 네이밍이라도 명확하게 쓰자!라고 다짐했습니다. 동시에 extens..

서론 그룹 프로젝트 1주 차에는 기획을 주로 했고, 이를 바탕으로 그룹 프로젝트 2주 차에는 실제 개발에 들어갔습니다. 처음으로 협업을 해보면서 무엇을 느꼈는지 작성하고, 어떤 기술적 고민을 했는지도 적어보겠습니다. 그리고 최근에 도파민 다이어트를 해보고 있는데요. 이에 대한 짧은 이야기도 해보려고 합니다 ㅋㅋ 협업을 나누는 단위 저희 모티메이트 팀의 iOS는 저와 팀원 1명, 총 두 명입니다. 함께 기획하고 디자인한 걸 어떻게 나눠야 좋게 협업할 수 있을지 고민했습니다. 근데 이게 회사의 협업이랑은 성격이 좀 다른거 같더라고요. 회사의 협업은 효율 중심이지만 네이버 부스트캠프는 함께 성장하는 측면을 더 강조하고 있었습니다. 그래서 어떻게 해야 함께 성장하고 앱의 흐름을 모두가 이해하면서 적당히 효율도 ..

서론 11월 6일부터 네이버 부스트캠프 웹・모바일 8기 그룹 프로젝트 1주 차가 시작되었습니다. Mobile/FE 2~3명, BE 2명이 모여 하나의 프로젝트를 진행하는 활동입니다. 네이버 부스트캠프 웹・모바일 8기 그룹 프로젝트는 6주동안 진행되며 마지막 6주 차에는 현업 개발자분들 앞에서 결과 발표를 하게됩니다. 기획 이번 1주 차는 기획 주였습니다. 6주 간 어떤 앱을 만들지 고민하고 기획, 디자인하는 시간이었는데요. 저희 팀은 기획은 다함께, UX는 iOS 파트가, 디자인은 제가 진행했습니다. 기획자가 따로 없고 iOS, BE 개발자가 서로의 기술적 고민을 충족시키기 위한 기능을 생각해내는게 쉽지 않았는데요. 긴 시간 회의하고 각 파트에서 양보하면서 타협점을 잘 찾은 거 같습니다. (사실 아직도 ..

서론 6주 차 회고를 하고 거의 2주 간 포스팅이 없었습니다. 그만큼 네이버 부스트캠프가 바빴고 알찼답니다 ㅎㅎ 이번 7, 8주 차에는 페어 프로그래밍이라는 걸 했습니다. 혼자서 할 때보다 1.5배로 힘들고 2배 재밌었던 경험이었습니다 ㅎㅎㅎ 바로 회고해 봅시다. 페어 프로그래밍 위에서 말했듯 7, 8주 차에는 페어 프로그래밍을 진행했습니다. 두 명이 짝을 지어서 네비게이터, 드라이버로 나눠서 같이 작업하는 방식이에요. 내비게이터는 지시하는 역할, 드라이버는 지시를 듣고 실행하는 역할입니다. 페어 프로그래밍에서 가장 중요한 건 분업이 아니라 하나의 컴퓨터로 같이 작업을 하는 것입니다. 그래서 저희는 한 명이 화면 공유를 해서 작업하는 방식을 선택했어요. 하나의 코드를 두 명이 대화하면서 짠다는 게 괜찮이..

서론 벌써 6주 차가 되었네요. 6주 차에는 새로운 시도를 많이 해봤습니다. 다른 분들의 MVVM 패턴을 보면서 이렇게도 사용할 수 있구나, 이런 방법도 있구나 많이 배웠어요. MVVM + state 첫 번째 시도한건 MVVM에 state를 적용하는 것입니다. 기존에는 MVVM의 데이터를 바인딩해서 사용했습니다. 이렇게 사용하니 데이터 흐름을 파악하기 어렵다는 단점이 있었습니다. View가 예상과 다르게 나올 때 어디가 문제인지 파악하기가 어려웠어요 ㅠㅠ state를 적용한 분의 코드를 보니 ViewController가 특정 state일 때 이렇게 뷰가 변하는구나!라는 흐름이 한 눈에 보여 좋았습니다. 저도 데이터를 직접 바인딩하는 게 아니라 간단하게나마 state를 적용했더니 흐름이 좀 개선이 되더라고..

서론 이번 5주 차에서는 세 번째 앱을 만들고 있습니다. 5주 차는 이미 알고 있던 개념을 더 자세히 알게 된 주차였던 거 같아요. 요즘 너무 피곤해서 핵심적인 내용만 짧고 굵게 다뤄보려고 합니다. UITableView 활용 기존에도 UITableView는 자주 사용했지만 테이블뷰의 다양한 기능을 활용하진 않았습니다. 그냥 텍스트 데이터를 표시하는 정도로 활용했고, 그거보다 복잡해지면 UICollectionView를 사용했던 거 같아요. 하지만 이번 주차에서 UITableView의 능력(?)을 알게 되었습니다. Editing 모드, 슬라이드 메뉴를 기본적으로 지원해줘서 훨씬 편하게 구현할 수 있더라고요. 물론 UIListContentConfiguration라는게 있지만, 그래도 테이블뷰와 콜렉션뷰를 고민..

서론 네이버 부스트캠프 웹・모바일 8기 4주 차가 끝났습니다. 네이버 부스트캠프 웹・모바일 8기 챌린지가 4주 과정이었는데 감회가 새롭네요. 개인적으로 멤버십의 시간이 더 빠른 거 같습니다. 순간순간은 챌린지가 더 빨랐는데 전체로 보면 멤버십이 순식간이네요. 이번주도 많이 힘든 주였기 때문에 핵심만 작성해보겠습니다. 오늘 포스팅에서 다루지는 않지만 8기의 채용 연계 설명을 듣고 정신적으로 많이 힘들었네요. 과정을 마쳤을 땐 취업을 해서 기쁜 마음으로 썰 풀 수 있었으면 좋겠습니다. 피그마 너무 편함 지금까지는 그림을 손으로 그렸습니다. 구조 그림도 손으로 그리다보니 수정이 발생했을 때 보기 힘들어지더라고요. 그래서 리드미를 잘 작성하는 분들께 조언을 구했는데 다들 피그마 혹은 피그잼을 추천해주시더라고요...

서론 이번 3주 차는 정말 너무너무 힘들고 어려웠습니다. 다형성이 어렵다고 생각은 했는데 이 정도일 줄은... 이번 회고도 쓸까 말까 고민했는데 짧게라도 남기기 위해 작성합니다. 이왕 시작한 거 빼먹으면 아쉬우니까요. 프로토콜과 다형성 Swift의 POP와 객체지향 OOP 사이에서 고민하는 주차였습니다. 특히 프로토콜에 프로퍼티를 넣는 것은 객체지향에 어긋나느냐? 하는 주제로 다른 캠퍼들과 의견을 나눴던 거 같아요. 1. Swift의 프로토콜에는 프로퍼티를 넣어도 자연스럽다. 프로토콜에 프로퍼티를 넣지 않으면 getter/setter 메서드를 넣어야 하는데 이건 Swift 스럽지 않다. 2. 프로토콜에 프로퍼티를 넣으면 객체지향의 캡슐화, 은닉화가 약해진다. 따라서 최대한 프로퍼티를 넣지 말아야 한다. ..

서론 네이버 부스트캠프 웹・모바일 8기 멤버십 2주 차를 마쳤습니다. 이번 2주 차에는 기술적인 고민 위주로 진행했습니다. 애니메이션 제네릭과 프로토콜 딥다이브 스터디 이번 포스팅은 위 세 개를 다뤄보겠습니다. (좀 짧을듯?) 애니메이션 이번 멤버십에서는 스위프트가 아니라 iOS를 다루기 때문에 앱과 관련된 기술이 많습니다. 간단한 애니메이션도 있었는데 저는 애니메이션을 처음 해봐서 조금 헤맸어요. 어떤 구조로 동작하는가?에 대해 생각을 했고, 2주 차가 끝난 지금은 여러 애니메이션 방법과 WWDC 테크톡을 보면서 제대로 다루기 위해 공부하고 있습니다. (곧 테크톡 포스팅도 올라오니 꼭 봐주세요 ㅎㅎ) 애니메이션을 처음 해본 입장에서는 좀... 어렵긴 했어요 ㅎㅎ; 이렇게 하면 내 생각대로 되겠지? 하는..