이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
iOS 앱 개발 스터디에서 Swift 프로토콜을 처음 썼을 때, 처음에는 그냥 인터페이스와 비슷한 것이라고 생각했습니다. 실제로 사용해 보니 클래스 상속이 아니라 프로토콜로 기능을 조합하는 패턴이 훨씬 유연하다는 것을 느꼈습니다. 네트워크 요청 레이어를 만들면서 Requestable 프로토콜을 정의하고 각 API 모델이 이를 준수하도록 하였습니다. 처음에는 associated type 개념이 헷갈려서 컴파일 에러를 한참 보았습니다. 이 설계 덕분에 목 객체로 바꿔서 테스트할 때 실제 네트워크 없이도 테스트가 가능했습니다. 프로토콜 지향이 테스트 가능한 설계와 연결된다는 것을 이때 처음 느꼈습니다.
포트폴리오 iOS 앱에서 뷰모델이 특정 클래스에 직접 의존하고 있어서 테스트가 어려웠어요. 코드 리뷰에서 지적을 받아서 프로토콜로 의존성을 역전시키는 방법을 처음 배웠어요. StorageService 프로토콜을 만들고, 실제 구현체와 테스트용 목 구현체를 별도로 만들었어요.
처음엔 프로토콜 선언과 구현 파일을 어디에 둬야 하는지 구조를 잘못 잡아서 import 에러가 났어요. 이틀 동안 구조를 다시 짜고 나서 뷰모델 테스트를 네트워크 없이 돌릴 수 있게 됐어요. 프로토콜은 단순히 타입을 정의하는 게 아니라 설계를 유연하게 만드는 도구라는 걸 직접 느꼈어요.
그 과정이 값진 배움이었습니다.
Swift 공부를 하면서 프로토콜 extension에 기본 구현을 넣을 수 있다는 걸 알게 됐어요. 여러 뷰컨트롤러에서 반복되는 에러 처리 코드를 프로토콜 extension으로 빼봤어요. ErrorPresentable 프로토콜을 만들고 showError(message:) 메서드의 기본 구현을 extension에 넣었더니 6개 뷰컨에서 중복 코드가 사라졌어요. 처음엔 과한 추상화가 아닐까 고민했는데, 코드량이 줄면서 수정할 때도 한 군데만 고치면 되니 편했어요. 단 기본 구현을 너무 많이 쓰면 어떤 구현이 실제로 실행되는지 추적이 어려워지는 단점도 경험했어요.
프로토콜 기본 구현은 공통 패턴에만 쓰는 게 적당하다고 생각하게 됐어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.