이제부터 주 마다 회고를 해볼까 한다.
사실 회고를 적기까지 할 필요가 있나 싶었다. 근데 주말에 아무것도 안하고 푸우우우우욱 휴식하며 놀기로 결정하고 보니 뭔가 불안하다. 아무것도 안하면 문제 있는 것 같아서 이런거라도 하나씩 남기기로 한 것이다.
참고로 이번 주 주말은 데드스페이스 리메이크를 깨고 메탈기어솔리드5 를 플레이했다.
이번주 주말 일정은 이러하다.
이번주 한 일을 몇가지 섹션으로 나누면 생각도 정리되고 가능하다면 다음주 뭐 할지도 정해보도록 하자.
SwiftUI 앱 개발을 열심히
아직 취업이 안된 상황에선 좀 이르다고 생각할 수도 있겠지만, 개인적으로는 준비해야 된다고 생각한다. Flutter 개발자를 구하는 회사가 얼마나 많이 늘어났는지 보면 준비를 안하는 것이 안일한 것 아닌가 하는 생각도 든다.
개인적으로 서비스로 배포하는 것을 목표로 사이드 프로젝트를 진행함과 동시에 SwiftUI 를 공부하는 한 돌맹이로 두 세개의 이득을 보는 궁극의 프로젝트를 진행중이다. 아무래도 아이디어가 미친 것 같다. (내가 안 좋게 미친걸 수도 있다)
이번 프로젝트의 목적을 몇 가지 상기해봐야겠다.
- 서비스 배포
- 적절한 Serverless 서비스를 선정. 현재는 Firebase 사용 중.
- 가장 경제적인 서비스를 찾을 필요가 있음.
- 경제적이란 인건비(나의 인건비)가 적고 서비스 비용이 적어야 함.
- 이에 따른 사용의 불편함은 일부 감수해야 할 것.
- 적어도 iOS, iPadOS 를 타겟팅 함.
- 최대한 HIG 의 지시에 따라 개발.
- 배포 버전은 iOS 13.
- SwiftUI 의 많은 신규 위젯은 iOS 16 버전과 호환됨.
- 이번 프로젝트를 통해 커스텀으로 생성해놓고 오픈 라이브러리 형태로 배포.
거의 하루종일 iOS 개발만 하고 있는데 예전에 하던 코딩테스트 공부는 어떻게 된거지 하는 생각이 든다. 다익스트라 알고리즘 공부하다가 막혀서 많은 부담감을 느낀 것 같은데 브루트 포스 문제라도 하나 풀어보며 머리 식히는 시간 가져볼까? 브루트 포스 문제가 어찌보면 몸은 힘들어도 부담감은 좀 적다.
배운 것
사실 배웠다기보단 뷰 구현에 성공했다고 표현해야 맞는 것 같다.
- Table 뷰 구현
- InputField 공통으로 구현
- Foldable 뷰 구현
- Circle Progress 뷰 구현
- State Binding 이용한 입력 뷰 프로토타입 구현
- Entity 들을 Idnetifiable, Codable 하게 구현
블로그 포스팅도 했다.
https://velog.io/@sanghwi_back/SwiftUI-ForEach
그 외에도 View, Shape 프로토콜의 차이를 공부했다.
취업 서류 작성에 관하여
원래는 취업은 다 이렇게 이뤄진다고 생각했다.
- 내가 열심히 이력서를 작성해서
- 기도메타로 버티다가
- 면접 가면 정해진 답변만 해서
- 입사한다.
그런데 세상에는 여러가지 방법들이 있는 것 같다.
- 인맥으로 면접보기
- 헤드헌터에게 잘 보일 서류를 올려놓기
- 왠지는 모르겠는데 헤드헌터분들은 사람인에서 가장 많이 활동하시는 것 같다.
- 프리랜서로 들어가서 2-3 개월 혼을 갈아넣고 입사하기
원래 회사에 서류를 넣고 되는 회사 들어가는게 일반적이었는데, 내 생각에 그 외의 방법들에서 회사가 불편할 부분은 없는 것 같다.
그런데 어떤 방법을 쓰던 간에 서류를 기가 막히게 잘 써야 한다 는 사실은 변함 없는 것 같다. 그럼 잘 쓴다는 것은 무엇일까?
개인적으론 시뮬레이션을 한번 해봐야 한다고 생각한다. 대부분 취업 플랫폼의 이력서는 미리보기 기능이 제공된다. 그리고 개발자와 비 개발자의 입장으로 봐야한다고 생각한다. 내 개발지식을 비 개발자에게도 효율적으로 전달하는 능력은 입사하고 나서도 중요하다. 만약 내가 대표라면 이력서를 통해 1차적으로 서류를 잘 작성하는 사람을 구분할 수 있을 것 같다.
그렇기 때문에 내 서류들에도 안좋은 점들이 여럿 보인다. 잘한 점도 보인다.
- (단점) 나는 iOS 꿈나무인데 웹 경력이 너무 많다. 나를 iOS 미들급 정도로 판단할 수도 있겠다. 혹자는 나에게 불리한 경력을 빼라고 하는데 내 생각은 다르다. "이녀석 미들급인줄 알았는데 아니잖아?" 라는 생각이 들면 앞에 좋은 것들이 있어도 "이런 사람 어딘가에 있을거야. 떨어뜨려." 라고 할 것 같다. 채용 과정은 좋은 사람을 뽑는게 아니라 안 좋은 사람을 거르는 작업이라는 것을 잘 알아야 한다.
- iOS 개발이 전체 경력의 어느 정도인지 자기소개 앞에 적을 필요가 있겠다.
- (장점) 이력서의 양을 짧게, 길게 모두 적을 수 있었다. 길게 적는 거 좋아할 수도 있다. 내 목표는 잘 적는거지 이력서를 짧게 적는 것이 아니다. 회사에 따라 내 판단으로 양을 이리저리 조절해 보았다.
- (단점) 회사의 자격요건에 부합하는지 어필하는 내용을 좀 더 넣어야겠다. 개인적인 판단인데 회사에서 내리는 인사와 관련된 의사결정은 좀 더 "시스템화" 되었다. 개인의 선택보단 계획에 따라 답을 도출하는 형태인 것 같다는 생각이 든다.
- 기존에는 내가 얼마나 성장가능성이 있는지 어필을 했었다.
- 이제는 자격요건의 항목들에 내가 얼마나 부합하는지 적는다.
- (장점) 서류와 관련있는 부분은 아니지만 깃허브 잔디 좀 심어줬다. 아니 그.... 뭐라도 해야지.
다음 주
대체적인 계획은 이러하다.
- 만들고 있는 앱의 로직을 작성할 차례이다. TCA 드루와.
- 하루 소요를 목표로 한다.
- 오픈 라이브러리를 만드는 방법을 복습한다.
- 구조 짜기 하루
- CocoaPods 에 배포 및 업데이트하는 방법 공부하기 하루
- SPM 에 배포 및 업데이트하는 방법 공부하기 하루
- 위에 언급한 이력서의 단점을 잘 기억하며, 해결방법을 토대로 수정해보기.
