나는 호텔관광경영학을 전공했다. 전문 개발자로 일한 적이 없다. 그런데 내 커리어에서 중요한 전환은 개발자들과 함께 일하면서 일어났다.
스카이스캐너에서 처음 개발팀과 협업할 때는 회의에서 모르는 단어가 많았다. 추상화, 관측 가능성, 테스트 주도 개발. 처음에는 기술 용어라고 넘겼다. 그런데 뜻을 이해할수록 내가 하던 그로스 업무와 닿아 있다는 것을 알게 됐다. 복잡한 문제를 나누고, 무엇이 달라졌는지 확인하고, 결과에 따라 다음 행동을 바꾸는 방식이었다.
코드를 몰라도 배울 수 있는 것이 많았다. 오히려 코드 바깥에 가져와보니 그 사고방식이 더 선명하게 보일 때도 있었다.
올라가서 보고, 내려와서 해보기
광고를 본 사람 중 클릭하는 비율이 낮다고 하자. 광고 문구를 고치자는 답이 바로 떠오른다. 그런데 문제를 조금 넓게 보면 다른 질문이 생긴다. 이 광고를 보는 사람은 우리 상품이 필요한 사람인가. 상품의 가치를 이해할 만큼 설명하고 있는가.
같은 현상을 어떤 범위에서 보느냐에 따라 해결책이 달라진다.
개발에서 말하는 추상화는 복잡한 세부 사항 중 지금 필요한 것을 골라 이해하기 쉬운 형태로 표현하는 일이다. 한 고객의 행동을 보고 구매 과정의 어느 단계에서 문제가 생기는지 생각할 수 있다. 반대 방향도 필요하다. ‘고객 중심으로 일하자’는 원칙을 내일 바꿀 화면의 문장이나 행동 하나로 옮기는 것이다.
내게는 이 두 방향을 오가는 일이 중요했다. 가까이서 보면 고칠 수 있는 것이 보이고, 멀리서 보면 그것을 왜 고쳐야 하는지 보인다. 큰 설명만 있으면 실행이 멀어지고, 눈앞의 숫자만 보면 잘못된 부분을 열심히 개선할 수 있다.
지금의 최선이 전부는 아니다
페이스북 광고가 잘되면 계속 페이스북 광고를 고치게 된다. 클릭하는 비율을 조금 올리고, 고객 한 명을 데려오는 비용을 줄인다. 익숙하고 결과를 설명하기도 쉽다.
그런데 그 방식 안에서 좋아지는 것과 사업 전체에 더 좋은 방법을 찾는 것은 다른 일이다. 광고에 쓸 힘의 일부를 고객의 사용 경험이나 다른 판매 경로에 쓰는 편이 나을 수도 있다.
최적화라는 수학적 문제에는 국소 최댓값(local maximum)이라는 말이 있다. 가까운 범위에서는 가장 높은 값이지만 더 넓게 보면 다른 가능성이 있다는 뜻이다. 안개 속에서 주변의 경사를 따라 오르다가 작은 봉우리 위에서 멈추는 모습을 떠올리면 이해하기 쉽다.
그로스 업무에서 이 개념을 자주 생각했다. 지금의 방법을 조금씩 개선하는 데만 익숙해지면 다른 방향을 볼 시간을 내기 어렵다. 당장 채워야 하는 목표도 있다. 새로운 시도는 처음부터 익숙한 일만큼 잘되지 않는다.
그래서 탐색에 쓸 자원을 따로 생각해야 한다. 잘되는 일을 전부 버리지 않아도 된다. 작은 범위에서 다른 방법을 해보고, 반응이 있으면 더 살펴볼 수 있다. 중요한 것은 익숙한 선택지 밖에도 질문을 남겨두는 것이다.
나에게도 기록이 필요했다
개발자들은 서비스에 오류가 생겼을 때 원인을 찾을 수 있도록 기록을 남긴다. 어느 단계에서 시간이 오래 걸렸는지, 어떤 요청 뒤에 문제가 생겼는지 살핀다. 이런 자료로 시스템 안의 상태를 이해할 수 있게 하는 것이 관측 가능성(observability)이다.
이 개념을 알고 나서 나 자신에게도 질문이 생겼다. 왜 어떤 날은 일이 잘되고 어떤 날은 잘되지 않을까. 왜 어떤 미팅 후에는 기운이 나고 어떤 미팅 후에는 지칠까. 그저 오늘은 좋았고 오늘은 나빴다는 느낌으로만 남겨두고 있지는 않을까.
감정일기는 이런 차이를 살펴보는 한 방법이다. 무슨 일이 있었고, 어떻게 느꼈고, 무엇을 했는지 짧게 남긴다. 며칠 뒤에 돌아보면 그날의 강렬한 감정과 반복되는 패턴을 조금씩 구별할 수 있다.
작은 변화는 기억만으로 놓치기 쉽다. 아침에 명상을 한 번 했다고 하루가 극적으로 달라지지는 않는다. 여러 번 시도하며 그날의 상태를 남기면 나에게 어떤 변화가 있는지 살펴볼 자료가 생긴다. 신체 상태를 기록하는 기기를 쓸 수도 있고, 간단한 메모로 시작할 수도 있다.
일이 끝난 뒤에만 돌아볼 필요도 없다. 대화가 예상과 다르게 흘러가는 도중에 내가 서두르고 있다는 것을 알아차리면 다음 질문을 바꿀 수 있다. 도널드 쇤이 말한 행위 중 성찰(reflection-in-action)은 이렇게 행동하면서 상황과 내 판단을 돌아보는 일과 연결된다.[1]
내가 원하는 것은 자신을 하루 종일 점수 매기는 생활이 아니다. 다음에 같은 상황을 만났을 때 다른 선택을 할 수 있을 만큼 알아차리는 것이다.
알고 있지만 말하지 않은 것
AI에게 일을 맡길 때도 보이지 않는 것이 있다. 바로 내 머릿속의 기준이다.
초안을 받아보고 ‘이건 아닌데’라고 느낄 때가 있다. 처음 요청할 때는 말하지 않았지만 결과를 보니 떠오르는 기준이 있는 것이다. 원하는 말투, 고객이 이미 아는 내용, 굳이 설명할 필요가 없다고 여겼던 업무 관행이 여기에 들어간다.
나는 이런 상황에서 알고 있는 것과 모르는 것을 네 가지로 나눠본다. 앤트로픽의 개발자 타리크 시히파르도 AI와 협업할 때 이 구분을 활용한다.[2]
| 구분 | 내가 할 수 있는 질문 |
|---|---|
| 알고 있다는 것을 아는 것 | 지금 분명하게 설명할 수 있는 목표와 조건은 무엇인가? |
| 모른다는 것을 아는 것 | 무엇을 확인해야 하는지 알고 있는가? |
| 알지만 꺼내 쓰지 않은 것 | 내게 너무 당연해서 설명을 생략한 기준은 무엇인가? |
| 모른다는 사실도 모르는 것 | 이 분야의 경험자라면 무엇부터 물어볼까? |
세 번째를 unknown knowns, 네 번째를 unknown unknowns라고 부른다. 한국어로도 쉽게 말하기 어려운 구분이지만, 실제 일을 맡길 때는 차이가 크다.
고객용 제안서를 만든다고 해보자. 누가 읽을지는 안다. 어느 제안에 더 관심을 보일지는 아직 모른다. 평소 고객에게 쓰지 않는 말투가 있다는 것은 초안을 보고서야 설명할 수도 있다. 처음 하는 업종이라면 제안 전에 확인해야 할 관행 자체를 모를 수도 있다.
모든 것을 미리 설명하려고 오래 준비하는 것보다 작은 초안을 받아보는 편이 빠를 때가 있다. 초안에 반응하다 보면 나도 말하지 않았던 기준을 찾는다. 낯선 분야에서는 경험자나 AI에게 내가 놓친 질문을 찾아달라고 할 수 있다. 그런 다음 실제 자료와 상황에 맞춰본다.
AI가 스스로 일을 이어가게 하려면 사람이 가진 맥락이 필요하다. 내가 이미 아는 것을 매번 다시 설명하지 않아도 되도록 기록을 남기면, 다음 작업에서는 더 중요한 판단에 시간을 쓸 수 있다.
다음 결과를 먼저 생각하기
테스트 주도 개발(TDD)은 다음에 만들 작은 기능이 어떤 결과를 내야 하는지 확인하는 코드를 먼저 쓰는 방식이다. 그 검사를 통과하도록 기능을 만들고 구조를 정리하는 일을 반복한다.[3]
처음 들었을 때는 아직 만들지도 않은 것을 어떻게 검사하나 싶었다. 그런데 그로스 실험에서도 비슷한 일을 하고 있었다. 무엇이 달라지면 이 시도가 도움이 됐다고 볼지 먼저 생각하는 것이다.
기준 없이 실행하면 결과를 보고 나서 설명을 바꾸기 쉽다. 시간이 줄었다고 기뻐하면서 수정에 쓴 시간을 빠뜨릴 수도 있고, 사람들이 좋아했다고 말하면서 실제로 사용했는지는 확인하지 않을 수도 있다.
회의 뒤의 일을 AI에게 맡긴다면 ‘요약이 좋다’보다 ‘팀원이 결정된 내용과 남은 질문을 구별할 수 있다’는 기준이 더 구체적이다. 새 서비스를 탐색하는 중이라면 처음부터 성공 수치를 정하기 어려울 수 있다. 그럴 때는 이번 시도에서 알아낼 질문부터 정하면 된다.
이렇게 작은 결과를 보며 다음 일을 정하면 계획도 조금씩 구체화된다. 처음부터 끝까지 정확하게 예측해야만 시작할 수 있는 것은 아니다.
다음번의 나에게 남길 것
개발자가 읽기 쉬운 코드를 남기려는 이유 중 하나는 다음 작업 때문이다. 오늘만 작동하게 만든 것을 다른 사람이 고치려면, 무엇을 왜 했는지 다시 알아내야 한다. 미래의 나도 그 다른 사람이 될 수 있다.
내 일에서도 비슷하다. 결과물만 저장하면 다음번에 같은 질문을 다시 풀게 된다. 왜 그렇게 했는지, 무엇은 해봤지만 잘되지 않았는지, 어떤 조건에서 다시 쓸 수 있는지 남기면 경험을 이어갈 수 있다.
스카이스캐너에서 배운 것을 블로그에 쓰던 습관도 그렇게 내게 남았다. 설명하면서 빈틈을 보고, 다음 프로젝트에서 다시 써보고, 맞지 않으면 고친다. AI가 그 기록을 읽고 일을 이어갈 수 있게 되면서 기록의 쓰임도 늘었다.
막힌 일 하나를 골라보자. 지금 관찰한 것, 내가 붙인 설명, 다음에 확인할 작은 행동을 적는다. 한 번 해본 뒤 그 기록으로 돌아온다. 설명이 맞았는지, 다음에는 무엇을 달리할지 살핀다.
개발자들과 일하며 배운 것은 코드를 다룰 때만 쓰는 기술이 아니었다. 모르는 것이 있어도 작은 결과를 만들고, 그것을 보며 다음 판단을 하는 방식이었다. 코드를 몰라도 그 방식은 배울 수 있다.
주석과 더 읽기
- Donald A. Schön, 《The Reflective Practitioner: How Professionals Think in Action》. 책 소개.
- Thariq Shihipar, 「A field guide to Claude Fable 5: Finding your unknowns」(2026-07-06). 말하지 않은 기준과 미처 발견하지 못한 문제를 AI와 함께 살피는 방법을 다룬다.
- Martin Fowler, 「Test Driven Development」(2023).
💼 비즈니스 문의
강연, 컨설팅, 협업 제안은 simpson.sim@retn.kr으로 보내주세요.