← 글 목록

책을 읽고 바뀐 업무 기준

스킬이 많다고 일을 잘하는 것은 아니었다

내가 가진 능력보다, 그 능력으로 누구의 어떤 상태를 바꾸는지가 더 중요하다는 생각.

『일을 잘한다는 것』을 공부하며, 지식과 기술을 많이 가진 사람이 아니라 진짜 문제를 정의하고 필요한 능력을 엮어 타인의 상태를 바꾸는 사람이 일을 잘하는 사람이라는 생각을 정리했다.

나는 원래 일을 잘하는 사람을 떠올리면 몇 가지 모습을 생각했다.

계속 학습하고 기록하는 사람, 아는 것이 많아 여러 의견을 낼 수 있는 사람, 누구와도 원활하게 대화하는 사람, 자신의 지식으로 다른 사람을 돕는 사람.

지금도 이런 능력이 중요하다는 생각은 바뀌지 않았다. 다만 『일을 잘한다는 것』을 공부하면서, 이것만으로는 일을 잘한다는 말을 충분히 설명하지 못한다는 생각이 들었다.

내가 중요하다고 생각했던 것들은 대부분 한 사람이 보유한 지식과 기술, 태도에 가까웠다. 반면 일은 혼자 잘 알고 있는 것으로 끝나지 않는다. 내가 가진 것을 사용해 누군가에게 필요한 변화를 만들어야 한다.

결국 일을 잘한다는 것은 내가 무엇을 많이 가지고 있는지가 아니라, 그것을 어디에 어떻게 써서 어떤 결과를 남기는가에 더 가까웠다.

일은 누군가의 상태를 바꾸는 일이다

취미는 나를 위해 할 수 있지만, 일은 기본적으로 나 아닌 누군가를 위해 가치를 만드는 활동이다. 그 누군가는 고객일 수도 있고, 동료나 상사, 협력사일 수도 있다.

그래서 열심히 했다는 사실만으로는 충분하지 않다. 문서를 잘 만들었고, 코드를 많이 작성했고, 회의를 원활하게 진행했더라도 상대방의 상태가 달라지지 않았다면 최종적인 성과가 만들어졌다고 보기는 어렵다.

예를 들어 결제 기능을 개선하는 일을 생각해볼 수 있다.

이 구분을 하면서 내가 일을 보는 기준도 조금 달라졌다.

예전에는 문제를 체계적으로 분석하고, 빠르게 구현하고, 배운 내용을 잘 공유하면 일을 잘한 것이라고 생각했다. 물론 이런 과정은 여전히 중요하다. 하지만 최종 질문은 따로 있었다.

내가 좋은 방식으로 일했는가가 아니라, 상대방의 상태가 실제로 좋아졌는가.

일을 잘하는 사람에게 생기는 신뢰도 여기에서 나오는 것 같다. “이 사람은 아는 것이 많다”보다 “이 사람에게 맡기면 문제가 앞으로 나아간다”는 믿음이 더 중요하다.

스킬은 도구이고, 감각은 도구를 고르는 판단이다

책에서 가장 오래 생각하게 된 개념은 스킬과 감각의 차이였다.

프로그래밍, 데이터 분석, 문서 작성, 발표, 커뮤니케이션, 일정 관리 같은 능력은 각각 설명하고 연습할 수 있는 스킬이다. 하드 스킬뿐 아니라 소프트 스킬도 여기에 포함될 수 있다.

반면 감각은 개별 능력 하나를 뜻하지 않는다.

지금 정말 풀어야 하는 문제가 무엇인지, 많은 정보 가운데 무엇을 보고 무엇을 버릴지, 어떤 기술과 사람이 필요한지, 무엇을 먼저 하고 무엇을 나중에 할지 판단하는 능력에 가깝다. 어디까지 직접 하고 언제 도움을 요청할지, 지금 선택한 행동이 최종 성과와 어떻게 연결되는지를 보는 것도 포함한다.

하드·소프트 스킬이 각각 사용할 수 있는 도구라면, 감각은 어떤 도구를 언제, 왜, 어떤 순서로 사용할지 정하는 판단이다.

기술을 많이 아는 개발자와 필요한 기술을 조직에 맞게 도입해 실제 성과를 만드는 개발자는 다를 수 있다. 후자에게는 기술 지식 외에도 문제와 맥락, 사람과 순서를 함께 보는 판단이 필요하다.

이런 감각은 관리자만의 능력도 아니다. 개인 기여자라도 모호한 문제를 구조화하고, 중요한 기술적 방향을 정하고, 필요한 사람을 움직이며 결과까지 책임진다면 충분히 감각을 발휘하고 있다고 볼 수 있다.

주어진 문제를 바로 풀지 않는 것

감각이 있는 사람은 문제를 빠르게 푸는 사람이라고만 생각하기 쉽다. 하지만 책을 공부하며 오히려 그 반대의 모습이 떠올랐다.

문제를 잘 푸는 사람은 주어진 문제를 바로 풀기 전에, 그것이 정말 풀어야 할 문제인지 먼저 확인한다.

사용자 반응이 좋지 않다는 이유로 기능부터 추가한다고 해보자. 눈에 보이는 요청을 따라 가이드를 만들고, 화면을 단순화하고, 튜토리얼을 넣을 수 있다. 각각은 그럴듯한 해결책이다.

하지만 사용자가 실제로 겪는 문제는 기능 부족이 아닐 수도 있다.

설정이 어렵고 단계가 많으며 어디에 쓰는 서비스인지 모르겠다는 여러 반응은, 한 단계 위에서 보면 “사용자가 서비스의 가치와 사용 흐름을 이해하지 못하고 있다”는 하나의 문제일 수 있다. 더 올라가면 “누구를 위한 서비스이고 어떤 핵심 가치를 주려는지가 불명확하다”는 문제일 수도 있다.

여기서 중요한 것이 구체와 추상을 왕복하는 능력이다.

구체적인 사건을 그대로 처리하는 데서 멈추지 않고, 여러 현상에서 공통된 원리를 찾아낸다. 그리고 다시 구체적인 실행으로 내려온다. 타깃을 명확히 하고, 그 사람이 해결하려는 문제를 정의한 뒤, 가장 작은 행동으로 핵심 가치를 경험하게 하는 흐름을 설계하는 식이다.

문제를 정의한다는 것은 거창한 문서를 오래 쓰는 일이 아니었다. 무엇을 만들기 전에 다음 질문에 답하는 일에 가까웠다.

큰 그림은 할 일 목록이 아니라 인과관계다

나는 책의 감각 개념을 제품과 개발 업무에 적용하면서 다음과 같은 흐름으로 정리했다.

문제 파악과 정의 → 큰 그림 정렬 → 작은 구현과 실험 → 결과 확인 → 피드백 반영

이것이 책에서 제시한 보편적인 공식은 아니다. 내가 실무에 적용하기 위해 만든 방식이다.

여기서 큰 그림은 목표와 할 일을 많이 적은 문서가 아니다. 행동과 결과가 시간 순서에 따라 연결된 하나의 이야기여야 한다.

“가이드를 만든다, UI를 단순화한다, 튜토리얼을 추가한다, 캠페인을 진행한다”는 목록만으로는 각 일이 왜 필요한지, 무엇이 먼저인지, 최종 성과와 어떻게 연결되는지 알기 어렵다.

반면 “타깃의 핵심 문제를 확인한다 → 가장 작은 행동을 유도한다 → 즉시 가치를 느끼게 한다 → 필요할 때 다음 기능을 보여준다”는 흐름에는 순서와 인과관계가 있다.

할 일을 많이 만들어내는 것보다, 하지 않아도 될 일을 골라내는 판단이 더 중요할 수도 있다.

이 생각은 요즘처럼 새로운 기술과 유행어가 빠르게 등장하는 환경에서 더 중요하게 느껴졌다. 문제가 분명하지 않은데 “AI 에이전트가 대세이니 우리도 도입하자”고 시작하면, 해결책을 먼저 고른 뒤 적용할 문제를 찾게 된다.

문제 정의에서 출발해 적합한 도구를 선택해야 하는데, 도구 도입 자체가 목적과 성과가 되어버리는 것이다.

코드, 문서, 회의, 분석 자료처럼 눈에 보이는 산출물은 일을 하고 있다는 느낌을 준다. 반대로 잘못된 일을 하지 않기로 결정하거나, 불필요한 구현을 멈추거나, 우선순위를 바꾸는 판단은 잘 보이지 않는다.

하지만 발생하지 않은 낭비도 분명한 성과일 수 있다.

완벽히 이해한 뒤 움직이겠다는 함정

문제 정의가 중요하다고 해서 모든 정보를 완벽하게 모을 때까지 실행을 미뤄야 한다는 뜻은 아니다.

이 부분도 처음에는 헷갈렸다. 문제를 제대로 파악해야 한다는 말을 강하게 받아들이면, 정의가 완성될 때까지 움직이지 않거나 모두의 의견이 일치할 때까지 기다릴 수 있다. 분석 자료와 문서는 늘어나지만 실제 변화는 만들지 못하는 상태가 된다.

감각은 완벽한 답을 알아내는 능력보다, 불완전한 정보 속에서 현재 가장 가능성이 높은 가설을 세우는 능력에 가깝다. 그리고 작고 되돌릴 수 있는 실행으로 그 가설을 확인한다.

그래서 합의의 범위도 나눌 필요가 있다.

팀은 누구의 어떤 상태를 바꿀지, 성공을 무엇으로 판단할지, 반드시 지켜야 할 제약이 무엇인지 정렬해야 한다. 반면 어떤 가설부터 검증할지, 어떤 순서로 실행할지, 가장 작은 실험이 무엇인지는 담당자가 판단할 수 있다.

비용이 크거나 되돌리기 어렵고 다른 팀에 큰 영향을 주는 결정이라면 다시 합의해야 한다.

자기 의지는 독단이 아니고, 정렬은 만장일치가 아니다.

시키는 일을 정확히 하는 데서 멈추지 않고, 조직의 목적 안에서 내가 책임질 문제와 만들 변화를 제안하는 것. 이것이 책을 공부하며 새롭게 이해한 자기 의지였다.

좋은 결과가 항상 좋은 판단을 증명하지는 않는다

성과를 중요하게 보려다 보면 또 다른 함정에 빠질 수 있다. 결과가 좋으면 그 과정과 판단도 모두 좋았다고 생각하는 결과 편향이다.

잘못 판단했지만 시장 상황이나 경쟁사의 실수 덕분에 성공할 수 있다. 반대로 좋은 판단을 했어도 예상하지 못한 외부 변수 때문에 실패할 수 있다.

특히 나쁜 과정에서 좋은 결과가 나온 경우가 위험하다. 성공했다는 이유로 잘못된 방식이 조직의 표준으로 굳을 수 있기 때문이다.

그래서 결과를 확인하되, 판단과 과정을 분리해 돌아봐야 한다.

이렇게 보면 일을 잘하는지는 한 번의 성공보다 반복되는 판단의 질에서 더 잘 드러난다.

시간이 지날수록 더 모호한 문제를 다룰 수 있는지, 작은 과제에서 큰 과제로 신뢰가 넓어지는지, 여러 상황에서도 판단의 질이 유지되는지, 자기 한계를 알고 필요한 시점에 도움을 요청하는지를 함께 봐야 한다.

경험을 감각으로 바꾸는 일

감각은 시험이나 자격증처럼 일을 맡기기 전에 확인하기 어렵다. 실제로 일을 맡긴 뒤 어떤 판단을 하고 어떤 결과를 만드는지 봐야 드러나는 경우가 많다.

그렇다고 감각이 타고난 촉이고 배울 수 없는 능력이라는 뜻은 아니다.

경험이 자동으로 감각이 되지는 않지만, 경험을 돌아보고 원리를 뽑아 다음 상황에 적용하는 연습은 할 수 있다.

경험 → 기록 → 피드백 → 원리 추출 → 다음 업무에 적용 → 결과 확인

업무가 끝난 뒤 당시 무엇을 문제라고 판단했는지, 어떤 근거로 결정했는지, 무엇을 하고 무엇을 하지 않았는지, 실제 결과는 어땠는지를 기록할 수 있다. 예상과 달랐던 점과 운의 영향, 다음에 다르게 할 행동도 남길 수 있다.

기록만 쌓으면 정보에 머문다. 거기에서 반복 가능한 원리를 뽑고, 다른 구체적인 상황에 적용한 뒤 결과를 확인할 때 감각으로 이어진다.

일을 잘하는 사람을 관찰하는 방법도 달라져야 한다.

그 사람의 말투나 문서 형식, 사용하는 도구를 따라 하기보다 일을 받자마자 무엇을 묻는지 봐야 한다. 많은 정보 중 무엇을 중요하게 보고 무엇을 버리는지, 어떤 순서로 사람과 자원을 움직이는지, 언제 직접 하고 언제 도움을 요청하는지를 관찰해야 한다.

겉으로 보이는 스타일이 아니라 판단의 구조를 배우는 것이다.

물론 감각이라는 말이 권위를 정당화하는 표현이 되어서는 안 된다. “오래 해봐서 안다”거나 “내 촉을 믿으라”는 말만으로는 좋은 판단인지 알 수 없다.

감각 있는 판단은 관찰과 인과관계를 설명하고, 불확실성과 반례를 인정하며, 작은 실험으로 검증하려 한다. 결과가 예상과 다르면 판단도 수정한다. 검증에 닫힌 촉은 감각이라기보다 권위에 가깝다.

이제 일을 시작할 때 다르게 묻고 싶다

이 책을 공부했다고 갑자기 감각이 생기는 것은 아닐 것이다. 여전히 하드 스킬과 소프트 스킬을 꾸준히 익혀야 하고, 실제 업무에서 여러 번 판단하고 실패하며 배워야 한다.

다만 일을 시작하고 끝낼 때 던질 질문은 조금 달라졌다.

일을 시작하기 전에는 누구의 문제인지, 현재와 원하는 상태의 차이가 무엇인지, 성공을 어떤 결과로 확인할지를 먼저 묻고 싶다.

일을 진행할 때는 할 일을 병렬로 늘어놓기보다 어떤 순서와 인과관계로 이어지는지 보고 싶다. 가장 작고 되돌릴 수 있는 실행부터 시작하고, 부족한 스킬은 직접 배우거나 다른 사람에게 도움을 요청하고 싶다.

일을 끝낸 뒤에는 산출물을 완성했다는 사실에서 멈추지 않고 상대방의 상태가 실제로 달라졌는지 확인하고 싶다. 결과에 운이 얼마나 섞였는지 돌아보고, 이번 경험에서 다음에도 쓸 수 있는 원리를 남기고 싶다.

처음에는 일을 잘하는 사람이 많은 것을 알고, 빠르게 실행하고, 원활하게 대화하는 사람이라고 생각했다.

지금은 그 능력들이 여전히 중요하지만, 그 자체가 목적은 아니라고 생각한다.

일을 잘한다는 것은 타인에게 필요한 변화를 위해 진짜 문제를 정의하고, 전체 맥락과 순서를 설계하며, 자신과 타인의 능력을 적절하게 엮어 검증 가능한 성과와 반복되는 신뢰를 만드는 일이다.

조금 더 실무적으로 줄이면 이렇다.

문제를 제대로 정의하고, 큰 그림을 팀과 맞춘 뒤, 필요한 기술과 사람을 선택해 작은 실행으로 검증하고, 그 결과와 피드백을 다음 판단에 반영하는 것.

앞으로 내가 일을 잘하고 있는지 궁금할 때는 얼마나 바빴는지보다 이 흐름을 만들었는지를 먼저 돌아보게 될 것 같다.