1. 일상 속 CTA: 3가지 방법
CTA는 2-3분이라는 짧은 시간에도 얼마든지 할 수 있어요. 어떻게 가능할까요?
우리는 CTA를 "인터뷰"라고 생각하는 경향이 있어요. 전문가한테 질문하고 답을 듣는 거라고요. 그런데 CTA의 본질은 질문이 아니에요. 전문가의 인지적 구조에 접근하는 모든 행위예요. 세 가지 방식으로 할 수 있어요.
1) 관찰 - 눈으로 보는 전문가
탁구 유튜브 영상을 볼게요. 잘 치는 사람을 관찰해요. 눈이 공을 계속 따라다니네? 손목이 일정한 스냅으로 움직이네? 숫자를 세는구나. 한 번의 수행 단위를 만들고 있는 건가?
이게 다 CTA예요. 관찰하고, 추론하고, "왜 그럴까?" 계속 생각해보는 거요. 전문가한테 직접 물어보지 않았어요. 그냥 영상을 봤을 뿐이에요. 2분이면 충분해요. 그런데 이미 배우고 있는 거예요.
2) 역추론 - 결과물에서 의도 읽기
vlookup을 CTA 해볼게요. 왜 이름이 'vlookup'일까? vertical(세로) + lookup(찾기). 아, 설계자는 표를 세로로 탐색한다고 생각했구나. 왜 4개 파라미터일까? 찾을 값, 범위, 열 번호, 정확히 일치하는지... 최소한의 정보로 동작하게 만들었네.
vlookup이라는 함수는 그냥 도구가 아니에요. 누군가의 사고과정이 응고된 거예요. 설계자를 만난 적도 없어요. 그 사람이 누군지도 몰라요. 그런데 그 사람의 멘탈모델을 이해하고 있어요.
모든 게 CTA 대상이에요. 전문가를 "사람"으로만 생각하면 협력할 수 있는 범위가 너무 좁아져요.
누군가 남겨놓은 코드에서도 사고의 흔적을 읽을 수 있어요. 변수명이 data, info 이런 식이면 "아, 이 사람 도메인 잘 모르는구나" 느껴지잖아요. 반대로 unpaidInvoices, settledTransactions 이런 식이면 "아, 이 사람 금융 도메인 좀 아는구나" 보이고요.
에러 메시지도 마찬가지예요. "Error occurred"만 던지는 코드 있고, "Payment failed: Insufficient funds in account" 던지는 코드 있고. 후자 보면 "이 사람, 실제로 결제 실패 케이스들 많이 겪어봤구나" 느껴져요.
누군가의 결정이 담긴 모든 게 전문가예요. 그 사람을 직접 만날 수 없어도, 그 사람이 만든 결과물 보면 어떻게 생각했는지 알 수 있어요. 섭외 필요 없어요. 영상, 코드, 제품은 이미 있으니까요. 원할 때마다 다시 볼 수 있고요.
3) 대화 - 직접 물어보기
어떤 백엔드 팀 얘기를 들어봤어요. 주니어 개발자가 있었는데, 시니어 개발자가 퇴사하기 전에 전문성을 전이시키고 싶었대요.
20줄짜리 짧은 코드를 준비했어요. 일부러 문제가 있는 코드로요. 그리고 퀴즈를 냈대요. "이 코드 리팩토링하면서, 당신 머릿속에서 일어나는 일을 써보세요. 뭘 먼저 봤나요? 왜 그렇게 생각했나요?"
시니어 개발자도 같은 퀴즈를 풀었고요. 그럼 비교가 되잖아요. 주니어는 변수명부터 봤대요. 함수가 너무 길다고 느꼈고요. 시니어는 함수의 return 타입이랑 파라미터부터 봤대요. "이 함수가 두 가지 일 하네" 바로 판단했고요.
이게 멘탈모델 차이예요. 주니어는 변수명(표면)을 먼저 봤어요. 시니어는 함수 시그니처(구조)를 먼저 봤고요. 주니어는 길이에 반응했어요. 시니어는 책임 개수에 반응했고요. 시니어는 핵심을 먼저 봤고, 주니어는 순서를 몰랐던 거죠.
금요일 회고 때 이런 얘기가 나왔대요. "예전 주니어 때는 벌벌 떨면서 코드리뷰 했거든요. 근데 지금은 서로 멘탈모델이 어떻게 다른지 비교하니까 학습 관점에서 모든 리뷰가 일어나서 너무 좋아요."
2. 습관으로 만들기
1) 오늘 할 일 앞에 10분 붙이기
CTA를 습관으로 만드는 가장 쉬운 방법은 오늘 할 일 앞에 붙이는 거예요.
아침에 오늘 처리해야 할 일들을 보죠. 그중에서 내가 잘하는 게 정말 중요한 일을 하나 고르고요. 그리고 질문해요. "이 일을 시작하기 전에 10-20분 동안 뭘 관찰/비교/질문하면 더 잘할 수 있을까?"
예를 들어볼게요. 오늘 중요한 일이 "복잡한 컴포넌트 리팩토링"이라고 쳐요. 바로 시작하는 대신 이렇게 물어보는 거예요. "리팩토링 시작하기 전에 뭘 보면 도움이 될까?"
시니어가 코드 리뷰하는 동안 옆에서 10분 관찰하고, 5분 이유를 물어볼까요? 잘 설계된 컴포넌트를 보고 "왜 이렇게 만들었을까?" 역추론해볼까요?
2시간짜리 리팩토링이면 15분 먼저 쓰는 거예요. 그럼 실제 작업이 훨씬 쉬워져요.
2) 숫자로 측정하기
한 주니어가 이렇게 했어요. "리팩토링을 잘하고 싶다" 목표를 세웠대요. 매일 시니어가 코드 리뷰하는 걸 옆에서 관찰하기 시작했고요.
첫 주 월요일에 200줄짜리 컴포넌트를 리팩토링했어요. 3시간 걸렸대요. 힘들었죠. "어디서부터 손대야 하지?" 계속 고민했고요.
그 주 내내 매일 시니어 옆에 앉아서 10분씩 관찰했대요. 시니어가 코드 리뷰하는 동안요. "어? 변수명은 안 보고 함수 시그니처부터 보네?" "먼저 이게 뭘 하는 함수인지 파악하는구나." 그리고 5분 정도 물어봤어요. "방금 왜 파라미터부터 보셨어요?" "아, 책임이 몇 개인지 먼저 봐야 하니까."
둘째 주 월요일에 비슷한 복잡도의 컴포넌트를 또 리팩토링했어요. 이번엔 2시간 걸렸대요. "어? 빨라졌네?" 계속 관찰하고 물어보고 적용했어요.
셋째 주 월요일. 같은 복잡도. 1시간 30분. "확실히 나아지고 있네!"
숫자로 보이니까 "아, 나 제대로 가고 있구나" 확인이 되는 거죠. 다른 지표도 가능해요. "리팩토링 후 버그가 몇 개 나왔나", "동료가 내 코드 이해하는 데 얼마나 걸렸나", "코드 리뷰에서 코멘트 몇 개 받았나".
3) 쉬워지면 난이도 올리기
그 주니어가 계속 CTA를 했어요. 넷째 주쯤 되니까 이상한 느낌이 들었대요. "어? 이제 쉬운데?"
200줄 컴포넌트 리팩토링이 이제 1시간이면 돼요. 예전엔 머리 싸매고 고민했는데, 이제는 거의 자동으로 손이 가요. "여기 책임이 섞였네, 여기 함수 쪼개야겠네" 보이거든요.
이게 신호예요. 하나하나 의식하던 판단들이 절차기억으로 저장되고, 자동화되고, 작업기억에 공간이 생긴 거죠. 그럼 어떻게 해야 할까요? 난이도를 올려야 해요.
그 주니어가 주제를 바꿨대요. "변수명 짓기"는 이제 쉬워요. "함수 분리 판단"으로 바꿨죠. 이건 어려워요. 다시 머리 써야 해요. "이 함수를 어떤 기준으로 쪼개지? 책임이 뭐지?" 몇 주 지나니까 이것도 쉬워졌어요. 그럼 또 올려요. "책임 분리 설계", "도메인 모델링", "아키텍처 결정"...
계속 "머리에 땀나는" 수준을 유지하는 거예요. 너무 쉬우면? 성장이 멈춰요. 이미 아는 걸 반복하는 거니까요. 초보 때는 20줄 코드 CTA 했다면, 이제는 100줄로. 단순한 함수였다면, 이제는 복잡한 모듈로. 한 단계씩 올라가는 거죠.
그 주니어가 3개월 후에 이런 말을 했대요. "신기한 게, 월요일에 고민했던 문제가 금요일에는 쉬워요. 그 한 주 동안 CTA 하고 적용하고 하다 보면, 저도 모르게 실력이 올라가 있어요. 그럼 다음 주 월요일에는 더 어려운 걸 시도할 수 있고요. 점점 유리한 입장이 되는 느낌이에요."
하나 배우면 → 다음이 쉬워지고 → 또 배우면 → 그다음이 쉬워지고. 이게 전문가가 되는 과정이에요.
3. 지금 바로 시작하세요
저는 반년 전, 6시간 동안 허덕이며 코드를 폭발시켰어요. 지금은 2시간 만에 같은 일을 해요.
비결은 단순했어요. 전문가가 어떻게 생각하는지 관찰했습니다.
당신도 할 수 있어요. 영상을 2분 보거나, PR을 10분 뜯어보거나, 시니어에게 짧게 물어보세요. 오늘 할 일 앞에 10분만 붙이세요.
매일 조금씩. 측정하면서. 쉬워지면 올리면서.
3개월 후, 당신도 달라진 자신을 발견하게 될 거예요.
