나는 호텔관광경영학을 전공했다. 코드를 짜본 적이 없다. 지금도 못 짠다. 그런데 내 커리어에서 가장 큰 전환점은, 개발자들과 일하면서 그들의 사고방식을 빌려온 순간이었다.
스카이스캐너에서 처음 개발팀과 협업했을 때, 회의에서 모르는 단어가 절반이었다. 추상화, 관측 가능성, 테스트 주도 개발. 처음엔 그냥 기술 용어라고 넘겼다. 그런데 듣다 보니 깨달았다. 이건 기술 용어가 아니라 사고방식이었다. 그리고 그 사고방식은 코드 바깥에서도 작동했다.
추상화와 구체화
개발자가 가장 먼저 배우는 것 중 하나가 추상화다. 복잡한 시스템을 단순한 원칙으로 압축하는 것. 자동차를 운전하려고 엔진의 작동 원리를 알 필요는 없다. "액셀을 밟으면 간다"로 추상화하면 된다.
그로스 전략에서도 추상화 레벨이 판단의 질을 결정한다. "이 캠페인의 CTR이 낮아요"는 낮은 추상화다. "우리 퍼널에서 인지-관심 단계의 전환이 막혀 있다"는 한 단계 높은 추상화다. "타겟 고객의 문제 인식 자체가 형성되지 않았다"는 더 높은 추상화다. 같은 현상을 어떤 높이에서 보느냐에 따라 해결책이 완전히 달라진다.
반대 방향도 중요하다. 추상적 원칙을 실행 가능한 액션으로 내리는 것. 구체화. "고객 중심으로 일하자"는 좋은 말이지만, 그게 내일 아침 내가 할 첫 번째 행동으로 번역되지 않으면 그냥 슬로건이다.
좋은 사고는 이 두 방향을 오간다. 올라가서 패턴을 보고, 내려가서 실행한다. 다시 올라가서 결과의 패턴을 보고, 다시 내려가서 조정한다. 개발자들은 이 수직 이동을 하루에도 수십 번 한다. 코드를 몰라도 이 이동법은 배울 수 있다.
Local Maxima의 함정
산을 오르는 중이라고 상상해보자. 안개가 짙어서 주변만 보인다. 발밑의 경사를 따라 올라가면 어느 순간 꼭대기에 도달한다. 더 이상 올라갈 곳이 없다. 그런데 안개가 걷히면, 옆에 훨씬 높은 봉우리가 보인다.
개발자들이 최적화 알고리즘에서 말하는 local maxima가 이거다. 지금 하는 방식 안에서의 최고점. 거기에 도달하면 모든 방향이 하향이니까, "지금이 최선이야"라고 착각한다.
그로스에서 이 함정에 빠지는 걸 수없이 봤다. 페이스북 광고가 잘 되니까 페이스북만 최적화한다. CTR을 0.1% 올리고, CPA를 100원 줄이고. 그게 나쁜 건 아니다. 하지만 그 채널의 천장이 있다는 걸 보지 못한다. 진짜 성장은 완전히 다른 채널이나 전략에 있을 수 있다.
문제는 global maxima를 찾으러 가려면, 일시적으로 성과가 떨어지는 구간을 견뎌야 한다는 거다. 지금 잘 되는 걸 놓고 불확실한 곳에 자원을 써야 한다. 대부분의 팀이 이걸 못 한다. 분기 목표가 있고, KPI가 있고, 당장 숫자를 보여줘야 하니까.
하지만 local maxima에 머무르는 건, 장기적으로는 가장 위험한 전략이다. 시장이 바뀌면 그 봉우리 자체가 사라질 수 있으니까.
그렇다면 어떻게 빠져나오는가? 이건 한 번의 점프가 아니라 반복되는 사이클이다.
첫 번째 단계는 **발산(diverging)**이다. 지금 서 있는 봉우리에서 고개를 들고, 현재 기준의 글로벌 맥시마가 어디에 있을지 탐색한다. 새로운 채널, 새로운 시장, 완전히 다른 접근법. 이 단계에서는 판단을 유보하고 가능성을 넓힌다. 방향을 정하는 단계다.
두 번째 단계는 **수렴(converging)**이다. 탐색한 것 중 가장 유망한 방향을 골라 포커스한다. 자원을 집중하고, 빠르게 실험하고, 그 방향이 진짜 더 높은 봉우리인지 검증한다. 발산만 하고 수렴하지 않으면 아무 데도 도착하지 못한다.
세 번째 단계는 **회고와 언러닝(unlearning)**이다. 새로운 봉우리에 올라섰으면, 이전에 최적이었던 것들을 돌아본다. 지금의 위치에서 보면, 이전의 local maxima에서 배운 최적화 방법들이 오히려 걸림돌이 될 수 있다. 페이스북 광고의 CTR 최적화에 능숙했던 감각이, 새로운 채널에서는 잘못된 직관으로 작동할 수 있다. 이전 것을 의식적으로 버리고, 새로운 맥락에서 다시 배워야 한다.
그리고 이 사이클은 끝나지 않는다. 새로운 봉우리도 결국 local maxima가 된다. 시장이 바뀌고, 기술이 바뀌고, 고객이 바뀐다. 발산하고, 수렴하고, 회고하고, 언러닝하는 것. 이걸 반복할 수 있는 팀이 계속 성장하는 팀이다.
관측 가능성을 설치하라
개발에서 observability라는 개념이 있다. 시스템 내부에서 무슨 일이 벌어지는지 바깥에서 볼 수 있게 만드는 것. 서버가 죽었을 때 "왜 죽었지?" 하고 추측하는 게 아니라, 로그와 지표를 미리 심어놔서 정확히 어디서 문제가 생겼는지 추적할 수 있게 하는 것이다.
이걸 처음 알았을 때, 가장 먼저 든 생각은 "나한테도 이게 없다"였다.
나는 왜 어떤 날은 생산적이고 어떤 날은 아닌지 몰랐다. 왜 어떤 미팅 후엔 에너지가 차오르고, 어떤 미팅 후엔 바닥나는지 몰랐다. 왜 어떤 결정은 좋은 결과를 냈고, 비슷해 보이는 결정은 나쁜 결과를 냈는지 설명하지 못했다.
시스템이 보이지 않으면 개선할 수 없다.
나는 간단한 관측 장치들을 설치하기 시작했다. 주간 회고에서 "이번 주 최고의 결정/최악의 결정"을 쓰고, 왜 그 결정을 했는지 기록했다. 미팅 후 에너지 레벨을 1-5로 매기기 시작했다. 거창한 시스템이 아니다. 하지만 몇 달 지나니 패턴이 보이기 시작했다. 내가 에너지를 얻는 일과 잃는 일이 명확해졌고, 좋은 결정에 공통적으로 있던 조건이 드러났다.
개선하려면 먼저 관측해야 한다. 관측하려면 의도적으로 장치를 심어야 한다.
결과를 먼저 정의하라
TDD, 테스트 주도 개발이라는 방법론이 있다. 코드를 쓰기 전에 "이 코드가 성공하면 어떤 결과가 나와야 하는가"를 먼저 정의하는 것이다. 테스트를 먼저 쓰고, 그 테스트를 통과하는 코드를 나중에 쓴다.
처음 들었을 때 직관에 반했다. 아직 만들지도 않은 걸 어떻게 먼저 테스트하나? 하지만 곰곰이 생각해보니, 이건 그로스 실험의 핵심과 같은 원리였다.
좋은 그로스 실험은 실행 전에 성공 기준을 정의한다. "이 실험이 성공이면 전환율이 X% 이상이어야 한다"를 먼저 정하고, 실험을 돌리고, 결과를 그 기준에 비추어 판단한다. 기준 없이 실험을 돌리면, 어떤 결과가 나와도 "잘 됐네" 혹은 "이 정도면 괜찮지"로 자기합리화할 수 있다.
커리어에도 적용된다. "1년 후에 이 역할에서 성공했다면 무엇이 달라져 있을까?"를 먼저 정의하면, 매일의 행동이 거기에 맞춰 정렬된다. 정의하지 않으면, 바쁘게 움직이되 어디로 가는지 모르는 상태가 된다.
결과를 먼저 정의하는 건 예측이 아니다. 방향 설정이다. 그리고 방향이 있어야 경로를 수정할 수 있다. 방향 없이 수정하는 건 그냥 표류다.
복리로 쌓이는 것들
개발자들이 좋은 코드를 쓰려고 집착하는 이유가 있다. 나쁜 코드 위에 코드를 쌓으면, 시간이 갈수록 속도가 기하급수적으로 느려진다. 기술 부채라고 부른다. 반대로, 잘 설계된 코드 위에 쌓으면 속도가 유지되거나 오히려 빨라진다.
제임스 클리어가 《아주 작은 습관의 힘》에서 말한 것과 같은 원리다. 매일 1% 나아지면 1년 후 37배가 된다는 그 계산. 숫자의 정확성보다 중요한 건 원리다. 작은 개선이 복리로 쌓인다.
하지만 여기서 놓치기 쉬운 게 있다. 복리가 작동하려면 이전 것 위에 쌓여야 한다. 매번 리셋하면 복리가 안 된다. 기록하고, 시스템화하고, 그 위에 다음 것을 올려야 한다. 내가 배운 것을 글로 쓰고, 프레임워크로 정리하고, 그 프레임워크를 다음 프로젝트에 적용하는 것 — 이게 지식의 복리다.
AI가 바꾸는 지식의 지형
여기서 지금 벌어지고 있는 변화를 얘기해야 한다.
예전에는 전문 지식의 상당 부분이 암묵지였다. 말로 설명하기 어렵고, 오래 일해야만 체득할 수 있는 것들. 장인의 손끝 감각, 시니어 개발자의 코드 리뷰 눈, 그로스 전문가의 "이 지표가 이상한데" 하는 촉. 이런 것들은 구전으로만 전해졌다.
AI가 이 지형을 뒤흔들고 있다. 암묵지가 명시지로 전환되고 있다. 코딩을 예로 들면, 시니어 개발자의 머릿속에만 있던 설계 패턴과 디버깅 접근법이 AI를 통해 검색 가능하고 재사용 가능한 형태로 풀려나고 있다. 나처럼 코드를 모르는 사람도 개발적 사고의 원칙을 AI와의 대화를 통해 배우고 적용할 수 있게 됐다.
여기서 한 가지 더 주목할 게 있다. 인지 과업 분석(Cognitive Task Analysis, CTA)이라는 방법론이다. CTA는 전문가의 암묵지를 구조화된 인터뷰와 관찰을 통해 끄집어내는 기법이다. 장인이 "그냥 감으로 안다"고 말하는 것을, "어떤 상황에서 어떤 단서를 보고 어떤 판단을 내리는가"로 분해하는 것이다.
왜 이게 AI 시대에 중요한가? 암묵지가 CTA를 통해 명시지로 전환되면, 그걸 시스템 프롬프트, 평가 기준(eval), 루브릭(rubric)으로 만들 수 있다. AI에게 "좋은 코드 리뷰란 이런 것"이라고 기준을 줄 수 있고, "이 광고 카피가 좋은지 나쁜지 이 기준으로 판단해"라고 시킬 수 있다. 전문가의 판단력 자체가 복제 가능해지는 것이다.
이건 단순히 작업을 대체하는 수준이 아니다. 전문성 자체를 스케일링하는 것이다. 한 명의 시니어가 가진 판단 기준이 CTA를 통해 추출되고, AI에 장착되면, 그 판단력이 조직 전체로 퍼진다. 예전에는 "경험 10년 이상"이 필요했던 판단을, 적절한 프롬프트와 평가 체계를 가진 사람이라면 AI와 함께 내릴 수 있게 된다.
이건 위협이 아니라 기회다. 단, 사고방식을 가진 사람에게. AI는 도구다. 추상화할 줄 아는 사람이 AI를 쓰면 추상화의 속도가 빨라진다. 추상화할 줄 모르는 사람이 AI를 쓰면 그냥 빠르게 잘못된 방향으로 간다.
개발자처럼 생각하는 법을 배우라는 건, 코딩을 배우라는 말이 아니다. 문제를 분해하고, 관측 장치를 설치하고, 결과를 먼저 정의하고, 복리로 쌓이는 시스템을 만드는 것. 이 사고방식은 코드 없이도 작동한다.
호텔관광경영학을 전공하고, 코드 한 줄 못 쓰는 사람이 개발자들 사이에서 일하면서 배운 것. 코드가 아니라 코드 뒤에 있는 사고방식이 진짜 도구였다.
추상화하고, 구체화하고, 관측하고, 테스트하고, 쌓아라. 코드를 몰라도 이건 할 수 있다. 아니, 코드를 모르기 때문에 오히려 이 사고방식의 보편성이 더 잘 보일 때가 있다.
개발자처럼 생각하라. 코드가 아니라 사고의 운영체제를 업데이트하는 거다.
← Ch 4. 머릿속 도구상자 | Ch 6. 확언하는 사람을 경계하라 →
💼 비즈니스 문의
강연, 컨설팅, 협업 제안은 simpson.sim@retn.kr으로 보내주세요.