https://v6xcareer.notion.site/2f61a1b40c81495eaf564cde9efc6089
사용하는 어플이 잘만들어서 어디서 만들었나 궁금해서 회사를 찾아보니까, 보이저 엑스라는 곳이였습니다. 맥 어플 사용성이 좋아서 ios 팀이 어떤곳인가 사이트에서 보다보니, 채용 공고도 있어서 한번 쭉 봤는데요.
회사 입사후에 오랜만에 면접 문제를 보니까 새롭더라구요 대답을 잘 못할거 같지만, 제 생각이랑 찾아서 공부한거 내용 좀 적어보겠습니다.
아래의 대답을 잘 할 수 있어야 한다 합니다.
연봉도 대충 나오던데요, 요즘 대기업 기준으로 나쁘지 않은거 같습니다 ~
보이저엑스 개발자 연봉
- 보이저엑스의 (2022년 현재) 개발자 연봉 (삼각형을 클릭하세요)
- 인턴: 3,840만원 (모두 동일)
- 신입: 4,800만원 이상
- 2년 이상 경력: 5,200만원 이상
- 5년 이상 경력: 6,500만원 이상
- 10년 이상 경력: 8,500만원 이상
- 참고) 정직원 개발자의 20% 정도는 연봉 1억원 이상
지원 전 자가점검 목록
보이저엑스는 보이저엑스와 잘 맞는 개발자를 찾고 있습니다. 아래 리스트는 채용 지원자가 보이저엑스의 개발자 포지션에 얼마나 잘 맞을지 스스로 체크해 볼 수 있도록 작성 되었습니다.
정직원 개발자 지원 요건
iOS 개발자 기술 질문: 9개 중 5개 이상 잘 대답할 수 있어야 함 (삼각형을 클릭하세요)
- [ ] Q1. Auto Layout의 장단점은?
이 질문은 제가 회사에서 일하면서 한번 생각 해본적 있는 주제긴 합니다. 오토레이아웃을 사용하는 방법과 일일이 frame을 계산해서 뷰를 위치 시키는 방법이 있다고 생각했습니다.
음 일단 저는 둘다 해봤는데요, 오토레이아웃이 사실 편해서 좋다고 생각했는데, 어떤 분이 오토레이 아웃은 잘못 그려졌을때 디버깅과 원인 분석이 어렵다고 하시더라구요? 경험한적은 없어서 잘 모르지만 그런가 보다 하고 일단 프레임 계산 방법으로 뷰를 일일이 구현했는데, 케이스에 따라 일일이 분류하느라 난리가 났습니다...
https://velog.io/@wonhee010/Auto-Layout-vs-Frame-Based-Layout
사실 저도 진짜 프레임 계산법이 더 정확하고 오토레이아웃이 부정확한가 궁금해서 찾아봤는데, 이걸 보면 오히려 정확성은 오토레이아웃이 좋은거 같고, 뷰 그리는 속도가 프레임 계산법이 더 좋은거 같습니다... 저도 확실하진 않은데 다른분 의견도 오토레이아웃이 왜 틀릴 수 도 있냐 했는데, 저도 몰라서 그냥 했지만 지나고 보니 저도 오토레이아웃이 더 정확한거 같습니다. 저는 그냥 이제 오토레이아웃을 선호할거 같아요. 프레임 계산하기 방법이 더 빠르다는 점은 숙지하도록 해야겠네요.
추가로 autoresizing-mask 방법도 있다는데, 이건 음 딱히 뭔가 내가 조절해서 의도적으로 사용한적은 없는거 같다.
아마 면접에서 물어봤으면, 다른분한테 들은대로 말했으면 큰일날 뻔 한거 같다 ㅋㅋ;
추가!!
애플 공식 문서인데, auto layout에 대한, 오토레이아웃은 관계로 레이아웃을 정의하는거고, 프레임 계산법은 레이아웃 변형 자유도가 높은 방법!
- [ ] Q2. MVC 패턴이란?
음음 이건 진짜 유명한 단골 질문이긴 한데, 내가 잘 말할 수 있을까...
모델, 뷰, 컨트롤러 죠?
음 이제 이걸 제가 0부터 설명한다 해보면, 아이폰 앱에서는 흔히 데이터가 있고 데이터를 이용해 뷰를 그리고, 데이터를 어떻게 뷰에 그려줄지 조절하는 컨트롤러가 있다고 생각하고 있습니다.
여기서 모델은 데이터에 관한 가공과 보관의 역할을 하고
뷰는 오로지 보여주는 것 뷰에 대한 것을 책임진다 하고 싶은데, 이러면 컨트롤러랑 약간 말로 책임이 섞여서, 저는 약간 뷰를 진짜 보여지는 뷰만을 지칭한다 생각합니다.
컨트롤러는 여기서 뷰에 대한 노출 여부 조절과, 데이터를 뷰에 넣어주는 역할을 한다 생각합니다.
후 이게 맞는 걸까요? !!
- [ ] Q3. KVC와 KVO란?
https://velog.io/@sainkr/iOS-KVC-KVO
kvc는 지나가다 본적은 있는데 키 또는 키패스를 사용해서 간접적으로 값을 가져오거나 지정하는 문법을 사용한는 것을 본적이 있었습니다. key value coding
kvo는 노티피케이션 패턴?이라 해서 논리적으로 떨어진 부분간에 연결을 할때 주로 사용하다고 알고 있었습니다.
일단 제가 사용했던 적은 음, 딱 기억나진 않는데, 객체 a에 observer를 추가해서 변화를 감지해야 될때가 있습니다. 사실 combine이 나오기 전에 swift에서는 객체의 변화에 대한 감지를 rxswift나 kvo를 이용해서 해왔다 생각하는데, 저 방식들을 사용하지 않고서는 객체에 대한 변화를 감지하는게 종종 어려웠습니다. 몇초마다 확인하는것이 아니라면?
kvo가 어떻게 구현되어있었는지 항상 궁금하긴했는데, 어쨌든 변화에 대한 감지를 위한 수단중에 한개라고 생각하고 사용해왔습니다.
- [ ] Q4. Swift의 특징은?
그냥 저에게 지금 딱 물어보면 인상 깊었던 특징에 대해 얘기할거 같은데요.
지금은 swift에서 struct가 value type으로 사용된다는게 큰 특징이라 생각합니다. 이로 인해 struct 타입들은 레퍼런스로 값을 확인하는게 아니라 값을 복사해서 다룬다는 점이 특징인거 같습니다. Int등 많은 타입도 struct 타입이라 하는데요 그래서 우리가 새로운 값들을 대입하는 것은 그것의 레퍼런스를 연결해주는 것인 경우보다는, 복사해서 사용하는 경우들이 많습니다. 함수도 마찬가지구요. 그래서 swift에서는 고차원 함수의 사용이 자연스러운거 같다고 생각한 적이 있는데 이후로 고차원 함수에 대한 막연한 부담감이 덜어진거 같습니다.
- [ ] Q5. Higher Order Function이란?
이건 뭔가 전에는 알았는데, 2년 정도 고차원 함수를 사용하면서 정의를 잊어버렸는데요.
오랜만에 다시 찾아봤습니다.
컴퓨터 과학에서 하나이상의 함수를 인자로 받거나 함수를 반환하면 고차원 함수라 합니다.
음 맞아요 뭔가 어느순간부터 filter, map, reduce가 고차원 함수라고 생각했는데 주로 이것만 사용해서. 잘 생각해보면 저게 기능땜에 그런게 아니라 저걸 사용하면 쉽게 함수를 인자로 받아 처리할 수 있어서 그랬죠 ㅎㅎ;
- [ ] Q6. Method Swizzling이란?
이건 실무에서 한번 들었었는데, 이런게 있는줄 그 당시에 몰랐습니다. 제가 특정 클래스의 메소드를 항상 다른 제가 생성한 또는 다른 특정 메소드로 교체해서 실행할 수 있게하는 방법입니다.
https://babbab2.tistory.com/76
- [ ] Q7. HTTP/2의 특징은?
이건 음 사실 아예 몰랐다. http 프로토콜 버전에 따른 차이가 있던데 싱기... 그냥 썼는데 ㅠㅠ
- [ ] Q8. Memory Leak의 대처방법은?
이건 원래 입사 면접 대비 공부 많이 했었는데, 사실 내가 실무에서 크게 생각하지 않고 구현 중이 였다는 충격적인 사실을 알게되었다...
일단 큰 맥락에서 스위프트가 메모리를 관리하는 방식이 ARC이고, 자바 같은 언어는 가비지 컬렉션인데
가비지 컬렉션은 사람이 인지할 만큼의 딱 원칙이 있지는 않다더라, ARC는 원칙이 있는데, strong reference로 연결되어 사용중인 메모리 영역에 연결된 갯수 만큼 카운트를 올리는데 0이면 메모리를 해제한다는 원리. 이게 참 사람이 이해하기 명확한 규칙이긴 한거 같다.
그래서 메모리 릭은 언제 발생하냐면 retain cycle 때문에 발생한다.
이 사진이 딱 적절한 예시 같다. 일단 이걸 이해하기 위해서 class에 대한 저장 공간은 힙 영역이고, 이에 대한 객체가 생성되면 레퍼런스를 클래스로 잡는데, 클래스의 프로퍼티는 남아 있게 되는 상황이 문젠거...
그리고 사전 지식으로 ARC도 알아야 되는데
다시 공부할때 보니까, 내가 놓친 부분이 컴파일 타임때 메모리에 대한 retain, release 타임을 정하게 된다는거 같다.
retain이 release되지 않게 잡고 있으면 메모리 릭이 생기게 되는듯. 아직도 막 100% 모든 상황을 이해한거 같진 않다. 위에 경우는 너무 명확한데 서로 잡고 있는게
여기 나오는 케이스는 뷰컨트롤러 인스턴스가 delegatingView랑 delegate가 뷰컨트롤러 인스턴스를 레퍼런스해서, 뷰컨트롤러 카운트가 2라 dismiss되도 인스턴스의 메모리가 release되지 않는게 문제인가 싶다.
- [ ] Q9. 이미지 리스트의 성능 향상법은?
일단 이미지 관련된건 기본적으로 캐싱이 요즘 필수로 들어가니까 캐싱 한다고 할거 같다. 그러면 사실 뭐라 물어보실지 모르겠는데, 나는 맨첨에 코코아에 라이브러리 있는줄 모르고 캐싱도 일일이 딕셔너리 형태로 로컬 이미지에 저장하게 구현했었다. 나중에 sd web image 라이브러리인가? 봤는데, 나는 이미지 유효기간은 빼먹고 개발했었는데, 역시 라이브러리가 좋더라 ㅎㅎ
일단 이미지는 그럴거 같고? 리스트의 성능 향상이라 하면 음, 딱히 생각해보진 않았었다. 나는 그냥 tableView 셀 로드 될때 이미지도 로드되게 했었는데, 지금 생각해보면 하얀 공간 보일바에 좀 미리 빨리 가져올 수 있는 방법이 있을 수도 있겠다 싶긴한데, 이걸 요구하는 건지는 모르겠음... ㅎㅎ;
이미지 리스트의 성능이 뭔지 먼저 알아야 될거 같은데, 내 기준에서는 이미지 빨리 불러오고 그런게 아닐까 싶다.