안녕 👋 오늘은 iOS 취준생이랑 주니어 Swift 개발자들이 제일 많이 묻는 그거,
"포트폴리오 어떻게 만들어야 붙어요?"를 아주 현실적으로 파헤쳐볼 거야.

미리 스포하자면 핵심은 이거야.
포트폴리오는 "앱 자랑"이 아니라 "의사결정 기록"이다.

면접관이 궁금한 건 네가 만든 화면이 예쁜지가 아니야.
"이 사람을 우리 팀 코드베이스에 넣었을 때 사고 안 치고 잘 굴러갈까?"
딱 이거 하나야. 자, 그럼 하나씩 뜯어보자.

1. 개수의 함정 — 앱 5개 < 잘 만든 앱 2개

제일 먼저 깨야 할 미신부터.
"프로젝트 많으면 유리하겠지?" → 아니야. 오히려 마이너스인 경우가 많아.

왜냐면 프로젝트가 5개인데 전부 '로그인 + 리스트 + 상세화면'이면,
면접관 입장에선 같은 난이도 문제를 5번 푼 것으로 보여.
성장 곡선이 안 보이는 거지.

여기서 메인 프로젝트는 반드시 "왜 이걸 만들었는가"에 답이 있어야 해.
"내가 매일 겪는 불편함을 해결하려고" 같은 개인적 동기면 충분해.
오히려 그런 동기가 있는 앱이 기능 설계도 더 뾰족하거든.

2. README가 곧 포트폴리오다 (진심으로)

냉정하게 말하면, 채용 담당자가 네 Xcode 프로젝트를 클론해서 빌드해볼 확률은 낮아.
거의 모든 판단이 GitHub README 스크롤 한 번에서 끝난다.

README에 반드시 들어가야 할 8가지

봐봐, 마지막에 "남은 과제"까지 쓴 거 포인트야.
자기 코드의 한계를 아는 사람 = 성장할 사람. 면접관이 제일 좋아하는 시그널이거든.

3. UIKit이냐 SwiftUI냐, 그 영원한 떡밥

2025년 기준 현실적인 답은 "둘 다, 단 비중을 나눠서"야.

그래서 추천 조합은 이래.

👉 메인 프로젝트는 SwiftUI로 (트렌드 + 생산성 어필)
👉 서브 프로젝트 하나는 UIKit 코드베이스 오토레이아웃으로 (기본기 어필)

특히 UIKit 프로젝트는 스토리보드 말고 코드 베이스를 권장해.
스토리보드는 협업 시 머지 충돌 지옥이라 실무에서 기피하는 곳이 많고,
코드로 짜면 Auto Layout 제약 이해도가 그대로 드러나거든.

SwiftUI 쓴다면 이건 알고 써야 해

// ❌ 흔한 실수: 뷰가 그려질 때마다 객체가 새로 생성됨
struct FeedView: View {
    @StateObject private var vm = FeedViewModel()   // ✅ 소유는 StateObject
    // @ObservedObject private var vm = FeedViewModel()  // ❌ 재생성 위험
    var body: some View { ... }
}

// ✅ iOS 17+ 라면 Observation 매크로
@Observable
final class FeedViewModel {
    private(set) var items: [Feed] = []
    func load() async { ... }
}

면접에서 "@State / @StateObject / @ObservedObject / @Binding 차이 설명해보세요"는
거의 고정 질문이야. 네 프로젝트 코드로 설명할 수 있어야 해.

4. 아키텍처: MVVM만 쓰면 되냐고? 반은 맞아

주니어 포트폴리오의 90%가 MVVM이야. 그건 문제가 아니야.
문제는 "MVVM 썼습니다"라고만 써놓고 실제론 ViewModel이 1500줄짜리 신(God) 객체인 경우.

그래서 아키텍처를 말할 땐 항상 "테스트 가능성"과 세트로 가야 해.
네트워크 레이어를 프로토콜로 추상화해두면 자연스럽게 답이 나와.

protocol FeedRepository {
    func fetchFeeds(page: Int) async throws -> [Feed]
}

final class DefaultFeedRepository: FeedRepository { /* URLSession */ }
final class MockFeedRepository: FeedRepository { /* 고정 데이터 */ }

// ViewModel은 구체 타입을 모른다 → 테스트에서 Mock 주입 가능
final class FeedViewModel {
    private let repository: FeedRepository
    init(repository: FeedRepository) { self.repository = repository }
}

이렇게만 해놔도 README에 이렇게 쓸 수 있어.

이 한 문장이 "MVVM 적용함" 백 번보다 강해.

5. 동시성(Concurrency)은 이제 선택이 아니다

Swift 6 이후 Strict Concurrency Checking이 본격화되면서,
async/await와 actor를 모르면 실무 코드 읽기 자체가 어려워졌어.

포트폴리오에 이거 하나만 녹여도 차별화돼.

// 이미지 캐시를 actor로 → 데이터 레이스 원천 차단
actor ImageCache {
    private var storage: [URL: UIImage] = [:]

    func image(for url: URL) -> UIImage? { storage[url] }
    func insert(_ image: UIImage, for url: URL) { storage[url] = image }
}

// 병렬 요청은 async let / TaskGroup
func loadProfile() async throws -> Profile {
    async let user = api.fetchUser()
    async let posts = api.fetchPosts()
    return try await Profile(user: user, posts: posts)   // 두 요청 동시 실행
}

여기서 중요한 건, "썼다"가 아니라 "왜 여기에 썼는지"야.
단순 API 호출 하나에 TaskGroup 쓰면 오히려 과설계로 감점당해.
기술은 문제에 맞게 쓸 때만 실력으로 보인다.

6. 테스트 코드 — 커버리지 80%는 필요 없다

주니어 포트폴리오에서 테스트가 있는 비율은 체감상 20%도 안 돼.
그 말은 테스트 몇 개만 있어도 상위권이라는 뜻이야. 가성비 최고의 항목.

@Test("네트워크 실패 시 error 상태로 전이한다")
func fetchFailure() async {
    let sut = FeedViewModel(repository: MockFeedRepository(result: .failure(.timeout)))
    await sut.load()
    #expect(sut.state == .error(.timeout))
}

참고로 Xcode 16부터는 Swift Testing(@Test, #expect)이 정식 포함됐어.
XCTest만 알던 사람이 Swift Testing까지 쓰면 "최신 흐름 따라가는 사람"으로 보여. 작은 디테일이지만 효과 좋아.

7. 커밋과 브랜치, 네 성실함의 지문

은근히 많이 보는 게 커밋 히스토리야.
왜냐면 코드는 베껴도, 커밋 로그는 못 베끼거든.

혼자 하는 프로젝트여도 PR을 열고 셀프 리뷰 코멘트를 달아두면
"협업 프로세스를 이해하고 있다"는 강력한 신호가 돼.
Conventional Commits(feat/fix/refactor/chore) 규칙 하나만 지켜도 인상이 확 달라져.

8. 앱스토어 배포 — 있으면 압도적으로 유리한 이유

배포 경험이 있으면 '완성시켜본 사람' 카테고리로 분류돼.
이게 생각보다 어마어마한 차이야. 왜냐면 배포엔 코딩 말고도 넘어야 할 산이 많거든.

"심사에서 Guideline 4.3(스팸)으로 리젝당했고, 기능 차별점을 보강해서 재제출로 통과했습니다"
이런 스토리 하나면 면접 10분은 그냥 채워. 진짜로.

앱 출시가 부담스러우면 TestFlight 링크라도 README에 넣자.
면접관이 직접 설치해볼 수 있는 앱은 신뢰도가 다르다.

9. 이력서에 쓰는 문장, 이렇게 바꿔봐

같은 작업도 표현에 따라 체급이 달라져. 실제 예시로 비교해볼게.

패턴 보이지? 맥락(왜) + 선택(무엇) + 근거(대안 비교) + 결과(수치).
이 네 박자만 지키면 어떤 기술이든 설득력이 생겨.

10. 면접에서 무너지지 않으려면

포트폴리오의 마지막 관문은 "본인이 쓴 코드를 방어할 수 있는가"야.
그래서 제출 전에 스스로 이 질문들에 답해봐.

여기서 "지금 다시 만든다면" 질문이 특히 중요해.
자기 코드의 부족함을 스스로 짚는 사람은 리뷰를 받아들일 사람으로 보이거든.
팀 입장에서 이건 기술력만큼 중요한 조건이야.

11. 흔한 지뢰 모음 (이건 진짜 피하자)

12. 4주 완성 실행 로드맵

"알겠는데 뭐부터 해요?" 하는 사람을 위한 현실 일정표.

새 앱을 만드는 것보다 있는 앱을 제대로 끝까지 밀어붙이는 게 훨씬 빠르고 강력해.
0에서 1은 오래 걸리지만, 1에서 10은 4주면 되거든.

마무리 — 결국 보여줘야 하는 건 '사고 과정'

정리해보자.

포트폴리오는 완성품 전시회가 아니라 네 머릿속을 보여주는 창문이야.
화려한 UI보다, 문제를 만나서 고민하고 근거를 들어 선택한 흔적이 훨씬 오래 남아.

그러니까 오늘은 새 프로젝트 만들지 말고,
이미 있는 레포의 README부터 열어보자. 거기가 시작이야. 🚀

화이팅! 다음에 또 유용한 Swift 이야기로 돌아올게 👋