러닝커브는 노력보다 비용의 문제다

한동안 나는 러닝커브가 높은 기술을 우선해서 선택했다.
잘되고 있는 회사가 쓰는 기술이면 좋은 선택일 거라고 생각했고,
어려운 기술일수록 미리 익혀두면 언젠가 큰 자산이 된다고 믿었다.

혼자 개발하거나 소규모 팀에서 일할 때는 이 방식이 크게 문제 되지 않았다.
내가 가장 많이 써본 기술이었고, 장점도 잘 설명할 수 있었기 때문에
자연스럽게 그 선택이 제품에 반영됐다.

지금 돌아보면, 그때 내가 놓친 건 기술 자체가 아니라 러닝커브의 주체였다.
나는 늘 "내가 감당할 수 있는가"를 기준으로 판단했고,
"처음 들어온 동료가 이 맥락에 얼마나 빨리 적응할 수 있는가"는 충분히 보지 못했다.

내가 지나온 러닝커브

iOS 개발을 하며 다음 흐름을 거쳤다.

• RxSwift를 배우며 MVVM과 반응형 프로그래밍을 익혔다.
• ReactorKit을 배우며 MVI와 단방향 데이터 흐름의 장점을 봤다.
• RIBs를 배우며 프로토콜 기반 설계와 경계 분리를 경험했다.
• TCA를 배우며 의존성 주입, 테스트, 상태 관리의 일관성을 배웠다.

각 단계는 분명히 의미가 있었다.
무엇이 더 예측 가능하게 만들고, 무엇이 유지보수를 쉽게 만드는지 배울 수 있었다.
문제는 "배움의 가치"와 "팀 적용 비용"을 같은 것으로 본 점이었다.

러닝커브를 노력으로 보면 생기는 일

예전의 나는 "어렵지만 해보면 된다"고 자주 말했다.
하지만 팀 관점에서 이것은 격려가 아니라 비용 전가에 가까웠다.

• 현재 팀이 학습하는 시간
• 새로 합류할 사람이 온보딩하는 시간
• 기술 키워드 때문에 지원을 망설이는 후보군의 기회비용

러닝커브는 의지의 문제가 아니라,
팀이 실제로 지불해야 하는 시간과 채용 풀의 문제였다.

채용 공고를 보면 기준이 보인다

채용 공고의 자격요건/우대사항은 팀의 공통 언어를 보여준다.
예를 들어 "반응형 프로그래밍 이해"가 있다면,
팀은 RxSwift나 Combine 같은 개념을 기본 전제로 소통한다.

"모듈화(Tuist) 이해"도 비슷하다.
모듈 경계, 의존성 관리, 설계 분리 같은 공통 기반을 기대한다.

이 지점에서 내가 다시 보게 된 질문은 이것이다.
특정 프레임워크 지식이 없으면 팀의 기본 대화에 참여하기 어려운가?
그렇다면 그 선택은 생산성 도구이면서 동시에 진입 장벽이 된다.

TCA는 강력하고 잘 만든 프레임워크다.
실제로 학습과 실무 모두에서 얻는 것도 많다.
다만 반응형 프로그래밍이나 모듈화처럼
비교적 넓게 공유된 기반 지식과는 성격이 조금 다르다.
그래서 선택 시점에는 장점뿐 아니라 "팀 전체 확산 비용"을 같이 계산해야 했다.

내가 지금 쓰는 기준

러닝커브를 0으로 만드는 선택은 없다.
대신 기준선을 어디에 둘지는 정할 수 있다.

내 기준에서 iOS 개발자가 공통으로 갖춰야 할 축은 다음에 가깝다.

• 동시성 프로그래밍
• 반응형 프로그래밍
• 프로토콜 지향/객체 지향 설계 감각
• 의존성 주입과 테스트
• Swift 언어 이해
• 모듈화 경험(팀 상황에 따라 선택)

이 위에 어떤 프레임워크를 올릴지는 팀의 문제 맥락으로 결정해야 한다.
"좋은 기술"보다 "우리 팀이 지속 가능하게 다룰 수 있는 기술"이 먼저다.

정리

나는 기술 선택에서 러닝커브를 오랫동안 "노력"으로만 해석했다.
지금은 그것을 "비용"으로 본다.

개인에게는 도전이지만,
팀에는 온보딩과 협업, 채용까지 연결되는 운영 변수다.

수학을 잘하고 싶다고 해서 덧셈과 뺄셈만 반복할 수는 없다.
그렇다고 연구실 수준의 공식을 입문 기준으로 둘 수도 없다.
결국 중요한 것은 현재 팀에 맞는 기준선을 정하고,
그 기준선 위에서 필요한 난이도를 단계적으로 올리는 일이라고 생각한다.