긍정적 사고, 음식의 절제, 규칙적인 운동

자신보다 뛰어난 사람을 채용하는 법

https://news.hada.io/topic?id=28923

• CEO가 자신이 잘 모르는 분야의 임원급 인재를 평가해야 할 때, 전문성 대신 판단할 수 있는 실질적 기준들을 제시하는 채용 가이드
• 면접 후 후보자의 아이디어를 당장 실행하고 싶은 충동이 드는지가 핵심 신호이며, 이는 문화 적합성과 맥락 이해를 동시에 검증하는 지표
• 뛰어난 리더는 자기 부서만이 아니라 조직 전체의 수준을 끌어올리는 역량을 보유해야 하며, 면접에서 이를 직접 테스트할 수 있음
• 레퍼런스 체크는 전문성이 아닌 문화 적합성 평가에 활용해야 하며, "이 사람이 최고로 빛나는 환경"과 "최악의 환경"을 묻는 방식이 효과적
• 잘못된 채용은 불가피하지만, 오판을 방치하는 것이 진짜 비용이며 즉각적인 조치가 필수

자신보다 뛰어난 사람을 채용해야 하는 이유

• 자신보다 뛰어난 사람을 채용하지 않으면 조직은 커지기만 할 뿐 나아지지 않음
• 규모가 커질수록 오버헤드, 회의, 커뮤니케이션 비용만 증가하고 개인 역량의 비례적 향상이 없음
• 뛰어난 인재는 평범한 사람보다 10배가 아니라 무한히 더 나은 존재로, 평범한 100명이 절대 떠올리지 못할 아이디어와 구현을 만들어냄
• 100명 규모에서 CEO가 여전히 어떤 영역에서든 사내 최고 역량자라면, 채용을 잘못한 것이며 회사가 피해를 보고 있는 상태
• 위임만으로는 창업자보다 나은 팀을 만들 수 없으므로, 자신이 모르는 분야의 후보를 어떻게 평가할 것인지가 핵심 과제

면접 후 그들의 아이디어를 실행하고 싶어지는가

• 면접이 끝난 뒤 "채용 여부와 관계없이 저 사람이 말한 것의 절반은 당장 해야 한다"는 생각이 드는지가 핵심 판단 기준
• 후보자의 조언이 실제로 현명한지 검증할 수는 없지만, 이 감정은 아이디어가 자사의 상황과 제약 조건에 맞닿았다는 의미
• 진정한 전문성은 해당 맥락에 맞춤형으로 느껴지는 구체적이고 실행 가능한 아이디어를 만들어냄
• 반대로, 마케팅 프레임워크에 대해 유창하게 말하면서도 5분 전 설명한 구체적 과제와 연결하지 못하는 후보자는 단순히 들은 것을 앵무새처럼 반복하는 것
  • ChatGPT도 그 정도는 할 수 있으며, 그것이 자사에 맞는지에 대한 확신은 동일하게 없음
• "이 사람이 경쟁사에 갔다면 걱정될 것인가?"라는 질문도 유효한 테스트
  • "큰일 났다"는 생각이 들면 좋은 신호, "뭘 할지 모르겠다"면 나쁜 신호

이미 그들에게서 배우고 있는가

• Zuckerberg의 유명한 채용 원칙은 "그 사람 밑에서 일할 의향이 있을 때만 채용하라"는 것
  • 문자 그대로는 맞지 않지만(Zuckerberg 본인은 다른 사람 밑에서 일한 적이 없음), 그 정신을 실제 관찰 가능한 기준으로 변환 가능
• 가장 약한 버전: 이 사람 밑에서 일하는 게 불편하다면 품질이 아닌 편의를 위해 채용하는 것
• 더 나은 버전: 이 사람에게서 배울 수 있는가, 회사의 다른 사람들도 배울 수 있는가
  • 면접 중 이미 몰랐던 것을 알게 되고, 이후 확인해보니 새로운 분야의 래빗홀에 빠진 경험이 실제 신호
• 진정한 테스트: 6개월 안식년 후 돌아왔을 때 해당 부서가 그들의 리더십 하에 측정 가능하게 더 나아져 있을 것인가
  • 프로세스 개선, 팀 강화, 산출물 향상이 그 기준

조직 전체를 끌어올리는 인재

• 훌륭한 리더는 자기 사일로만 개선하지 않음
• 인사 문제, 커뮤니케이션, 의사결정, 목표 설정, 연간 계획, 조직 구조 등 회사 전반에 유용한 역량을 보유
• 훌륭한 VP Marketing은 TypeScript 전용 CLAUDE.md에 기여할 수 없지만, 다음과 같은 영역에서 이론과 경험을 가짐
  • 3개 팀에서 30개 팀으로 성장하는 방법
  • 연간 목표를 설정하면서도 현재에 집중하게 하는 방법
  • 어려운 소식을 전사에 전달하는 방법
  • "대기업 정책"을 도입할 적절한 시점 판단
  • 이틀간의 전략 리트릿 구성 방법
  • 두 직원 간 갈등 해결 방법
  • 성과 관리를 최대한 객관적이고 인간적으로 운영하는 방법
• 면접에서 현재 직면 중이거나 곧 닥칠 것 같은 실제 상황을 제시해 이를 직접 테스트 가능

실제 문제를 풀어보게 할 것

• 회사가 실제로 겪고 있는 과제를 후보자에게 제시
  • 목표 설정에 어려움이 있다면, 목표가 없던 문화에 어떻게 도입할지 질문
  • 고객 이탈이 높다면 원인을 어떻게 진단할지 질문
  • 직원 이직률이 높다면 사람들이 말하기 꺼리는 상황에서 어떻게 파악할지 질문
• 답변의 세부 내용을 평가하는 것이 아님(평가할 역량이 없으므로), 사고 방식과 직접 경험을 관찰하는 것
  • 본질을 파고드는 명확한 질문을 하는가
  • 아직 모르는 부분을 인정하는가
  • 프레임워크를 이름만 대는 게 아니라 실제 적용 경험을 설명하는가
  • 직접 해본 것인지, 블로그 글을 그대로 따라 말하는 것인지 구분 가능

레퍼런스 체크는 문화 적합성 평가에 활용

• 일반적인 레퍼런스 체크는 전문성 평가에 무용함
  • 후보자가 좋은 말만 할 사람을 골라 제공하므로, 정제된 추천에는 가치가 없음
• 그러나 이 사람이 이 회사, 이 단계에서 잘할 것인지 평가하는 데는 강력한 도구
• 효과적인 질문 세 가지:
  • "이 사람이 최고로 빛나는 이상적 환경을 구성해 주세요" — 주제, 목표, 팀 구성, 방향성, 인센티브 등 모든 조건을 완벽하게 갖춘 상황
    • 예: "목표가 있어야 하고, 그 후엔 알아서 하게 두세요, 창의적이고 빠르게 탐색함" → "목표 지향적"이고 "탐색 욕구가 강함"이라는 속성 추출 가능
    • 이 경우 성숙한 제품보다 초기 스타트업이 적합할 수 있음
  • "이 사람이 무너지고, 모든 걸 망치고, 모두를 화나게 하는 시나리오를 구성해 주세요"
    • 묻기 재미있고 답하기 쉬우며, 부정적으로 느껴지지 않음 — 누구에게나 개인적 지옥이 있으므로
  • "본인이 인식하지 못하는 강점은 무엇인가요? 너무 자연스러워서 다른 사람도 그런 줄 아는 것"
    • 가장 자연스럽고 강력한 능력이며, 정의상 본인은 볼 수 없음
    • 가장 짜증나면서도 사랑스러운 특성이기도 함
• 약점이 없는 사람을 찾는 게 아니라, 지금 회사에 필요한 특별한 강점을 가진 사람을 찾는 것
  • 단순 역량이 아닌 초능력이 자리 채우기와 진짜 임팩트의 차이를 만듦

잘못된 채용은 불가피하지만 방치는 금물

• 면접에서 훌륭했지만 실제로 못하는 사람, 면접에서 인상적이지 않았지만 10년간 성과를 낸 사람 모두 존재
• 두 가지 오류 중 하나만 비용이 큼
  • 위음성(false negative, 좋은 사람을 놓침): 계속 탐색하면 됨
  • 위양성(false positive, 잘못된 사람을 채용): 팀에 피해, 적합한 사람 영입 지연, 본인에게도 끔찍한 상황(직장을 그만둔 경우 다음 탐색 기간도 문제)
• 잘못된 채용 후 통제할 수 있는 것은 얼마나 빨리 대응하는가
  • 1년간 방치하면 최고 인재들이 불만을 쌓고(이들은 다른 직장을 가장 쉽게 찾을 수 있음), 해당 부서 발전이 지연됨
• 직접 하는 게 더 쉽다고 느끼면 잘못 채용한 것
• 최고 인재들이 영감 대신 불평만 하고 있다면 잘못 채용한 것
• 즉각적 개선이 시작되지 않으면 잘못 채용한 것
• 팀원 모두가 이미 알고 있으며, 본인보다 더 일찍, 더 강하게 체감하고 있음
  • 그러나 이를 해결할 수 있는 사람은 오직 본인뿐이므로 깔끔하게 정리하고 즉시 행동해야 함 — 이미 3개월 늦은 상태

면접은 세부 사항이 아닌 사람 자체에 대한 것

• VP Marketing 면접에서 마케팅 역량을 평가하려 했지만, 그것은 평가할 수 없는 영역
• 1년 후에도 그들의 수요 창출 전략이 최적이었는지, 다른 사람이 매출을 더 빨리 키웠을지 반사실적 비교는 불가능
• 알 수 있는 것: 그들이 회사에 대한 시각을 바꿨는지, 몰랐던 문제를 발견했는지, 생각지 못한 것을 만들었는지, 주변 사람들을 더 날카롭게 만들었는지
• 이 단서들은 면접 중에 이미 관찰 가능했고, 문화 적합성은 레퍼런스 체크에서 확인 가능했음
• 완벽하지 않지만, 이것이 할 수 있는 최선

경험은 적지만 잠재력이 높은 사람 채용하기

• 자신의 역할에서 두드러진 성과를 찾기: 후보자가 참여한 일이 그들 없이는 훨씬 못했을 것임을 보여주는 이야기를 통해 개인의 재능과 주도성을 확인함.
• 자신만의 방식으로 세상을 탐색하기: 높은 잠재력을 가진 젊은 인재들은 종종 비전통적인 방식을 따름. 그들의 이례적인 접근 방식에 대한 합리적인 설명을 할 수 있어야 함.
• 어깨에 힘을 가진 사람 찾기: 무언가를 증명하고 싶어 하는가? 세상이 오해하는 명백한 재능과 동기를 가진 사람들은 자신의 내면적인 자아와 외부 인식을 조화시키기 위해 벽을 뚫고 나갈 것임.
• 높은 EQ와 설득력: 상황을 명확하게 이해하고, 환경을 자신의 의지대로 바꿀 수 있는 부드러운 기술/영향력을 가진 사람들은 특히 가치가 있음.
• 탁월함에 대한 이론: 어떤 것에서든 탁월했던 사람들은 관련 없는 다른 일에서도 우수함을 발휘할 가능성이 높음.
• 개방성: 완성된 제품을 채용하는 것이 아니므로, 개선과 새로운 아이디어에 열려 있는지 확인해야 함.
• 자신을 너무 심각하게 받아들이지 않는 사람들: 성공하기 위해서는 자신을 비웃을 줄 아는 사람이어야 함.

https://news.hada.io/topic?id=13261

https://www.joanwestenberg.com/collaboration-is-bullshit/

• 2차 대전 당시 실제로 총을 쏜 병사는 15~20%에 불과했다는 연구처럼, 조직 내 대부분의 실질적 성과는 소수가 만들어냄
• 테크 업계는 이 문제의 해법으로 "협업"을 내세웠지만, 실제로는 업무 조율 도구만 늘어나고 산출물은 거의 나오지 않는 구조가 고착화
• 집단이 커질수록 의사소통 비용과 조정 비용이 폭증하며, 회의가 회의를 낳는 책임 확산 현상이 반복됨
• 투명성이 진척과 혼동되고, 가시성이 책임감과 혼동되면서, 협업 문화가 개인 책임을 희석하는 메커니즘으로 작동 중
• 실제 복잡하고 질 높은 작업은 대부분 명확한 권한과 책임을 가진 개인 또는 소규모 그룹이 수행하며, 협업은 이를 포장하는 언어로만 기능함
• 진짜 필요한 것은 협업 인프라가 아니라 개인의 주체적 판단과 책임(ownership) 이며, 조직은 이를 신뢰하는 방향으로 전환 필요

협업이라는 허상

• 협업(collaboration) 은 현대 조직에서 생산성의 상징처럼 여겨지지만, 실제로는 책임 회피와 비효율의 구조로 작동함
  • 제2차 세계대전 중 S.L.A. Marshall의 연구에 따르면, 전투 중 실제로 총을 쏜 병사는 15~20%에 불과했음
  • IBM이 1960년대에 발견한 “80%의 사용량이 20%의 기능에서 나온다”는 패턴과 유사하게, 소수의 구성원이 대부분의 결과를 만들어냄
  • 나머지는 “구조적 지원(structural support)”만 제공하며, 조직 내 노력의 불균형이 반복적으로 나타남
• 기술 산업은 이 문제를 해결하기 위해 ‘협업’이라는 개념을 신앙처럼 추종하게 되었음
  • Notion, ClickUp, Slack, Jira, Monday, Teams 등 수많은 협업 도구가 등장했지만, 생산물(output) 보다 활동(activity) 이 늘어남
  • 투명성과 가시성이 곧 진전이나 책임으로 오인되며, “스레드에 포함되는 것”이 “결과를 소유하는 것”과 동일시됨
  • 이로 인해 협업은 실제 결과보다 참여의 시뮬레이션으로 변질됨
• 책임의 확산(diffusion of responsibility) 은 오래전부터 관찰된 현상임
  • 1913년 Ringelmann 효과는 집단 규모가 커질수록 개인의 노력 비율이 감소함을 보여줌
  • Frederick Brooks는 1975년 IBM System/360 사례를 통해, 늦은 프로젝트에 인원을 추가하면 더 늦어진다는 법칙을 제시
  • 인원이 늘수록 의사소통 비용과 조정 비용이 기하급수적으로 증가하며, 회의가 회의를 낳는 악순환이 발생
• 협업 산업은 이 구조적 문제를 감추기 위해 막대한 자원을 투입했지만, 실제 고품질 작업은 소수의 개인 또는 작은 팀이 수행함
  • Dostoevsky는 『카라마조프가의 형제들』을 혼자 썼고, Apollo Guidance Computer는 MIT의 소규모 팀이 명확한 책임 체계 아래 개발
  • 진정한 성과는 명확한 권한과 개인적 책임에서 비롯되며, 협업은 그 결과를 포장하는 언어로만 작동함
  • 반면 현대 조직은 소셜 관리(social management) 를 위한 복잡한 협업 인프라를 구축했을 뿐, 실제 작업은 뒷전으로 밀려남
• 진짜 소유(ownership) 는 개인이 스스로 결정을 내리고 결과를 감수하는 형태로 존재함
  • 그러나 협업이 문화적 규범이 된 환경에서는 단독 결정이 비협조적 행위로 간주됨
  • 협업 이데올로기는 책임과 주도성을 반사회적 행위처럼 느끼게 만들었으며, 이는 생산의 핵심 메커니즘을 약화시킴
  • 회의, 문서, 회고, 킥오프 등은 끝없이 반복되지만, 실제 실행과 연결되지 않은 ‘조정의 과잉’ 만 남음

개인 책임으로의 회귀 필요성

• 대부분의 프로젝트가 조정 시간 > 실행 시간의 구조로 변했고, 실패 시 해법은 “더 많은 협업”으로 귀결됨
  • 그러나 진짜 질문은 “우리가 실제로 무엇을 만들고 있으며, 누가 그것에 책임을 지는가”임
  • 어떤 일에 대해서든 최종 책임자는 한 명이어야 함, 협업 구조가 그 존재를 가리더라도
• 개인의 신뢰 회복이 필요함
  • 모든 책임을 조직 전체가 감시할 필요는 없음
  • 과도한 관리와 메트릭 중심 문화 대신, 개인이 자신의 작업을 스스로 관리하고 결과로 평가받아야 함
  • 실패 시 그 책임을 명확히 개인에게 귀속시키는 구조가 필요함
• 집단적 노력의 허상을 버리고, 실제 행동하는 사람을 식별할 수 있는 환경으로 돌아가야 함
  • 각자가 자신의 할 일을 스스로 관리하고, 그 결과로 평가받는 단순한 구조로 복귀
  • “협업”이라는 따뜻하지만 비싼 허구를 내려놓을 때, 누가 실제로 방아쇠를 당기고 있는지 명확히 볼 수 있음

PyQt5의 웹 엔진 모듈인 QtWebEngineWidgets를 사용하여 특정 URL을 임베디드 창(아이프레임 형태)으로 보여주고, 새로고침 기능을 포함한 프로그램을 제작

카카오맵과 같은 복잡한 웹 페이지를 렌더링하기 위해서는 단순한 GUI 구성 외에 WebEngine 설정이 필요

PyQt5에서 웹 브라우저 기능을 사용하려면 기본 패키지 외에 PyQtWebEngine을 추가로 설치

pip install PyQt5 PyQtWebEngine

import sys
from PyQt5.QtWidgets import (QApplication, QWidget, QVBoxLayout, 
                             QPushButton, QHBoxLayout)
from PyQt5.QtWebEngineWidgets import QWebEngineView
from PyQt5.QtCore import QUrl

class MapViewer(QWidget):
    def __init__(self):
        super().__init__()
        self.target_url = "https://place.map.kakao.com/SES0331"
        self.initUI()

    def initUI(self):
        # 1. 전체 레이아웃 (수직)
        layout = QVBoxLayout()

        # 2. 컨트롤 레이아웃 (상단 가로)
        control_layout = QHBoxLayout()
        
        # 새로고침 버튼 생성
        self.btn_refresh = QPushButton('🔄 페이지 새로고침')
        self.btn_refresh.setFixedHeight(40) # 버튼 높이 조절
        self.btn_refresh.setStyleSheet("""
            QPushButton {
                background-color: #fee500; /* 카카오 테마색 */
                border-radius: 5px;
                font-weight: bold;
            }
            QPushButton:hover {
                background-color: #fada00;
            }
        """)
        self.btn_refresh.clicked.connect(self.reload_page)
        
        control_layout.addWidget(self.btn_refresh)

        # 3. 웹 엔진 뷰 (아이프레임 역할)
        self.web_view = QWebEngineView()
        self.web_view.setUrl(QUrl(self.target_url))

        # 4. 레이아웃에 위젯 추가
        layout.addLayout(control_layout)
        layout.addWidget(self.web_view)

        self.setLayout(layout)
        self.setWindowTitle('Kakao Map Place Viewer')
        self.setGeometry(100, 100, 1000, 800) # 기본 창 크기 설정
        self.show()

    def reload_page(self):
        """페이지를 다시 불러옵니다."""
        self.web_view.reload()

if __name__ == '__main__':
    app = QApplication(sys.argv)
    
    # 웹 엔진 초기화 (일부 환경에서 필요)
    ex = MapViewer()
    sys.exit(app.exec_())

Spring Boot 프로젝트의 CI/CD 파이프라인

[Git Push] → [Jenkins Trigger] → [Build & Test] → [Docker Build & Push] → [Deploy to Server]

• 1. 소스 코드 관리 (GitHub): 코드를 저장소(Repository)에 커밋 및 푸시합니다.
• 2. CI 서버 설정 (Jenkins/GitHub Actions):
  • GitHub Actions: .github/workflows 디렉토리에 YAML 파일로 파이프라인(빌드, 테스트, 푸시)을 정의합니다.
  • Jenkins: Jenkinsfile을 프로젝트 루트에 작성하여 파이프라인을 자동화합니다.
• 3. 빌드 및 테스트: JDK를 설치하고, Gradle(gradlew build) 또는 Maven을 사용하여 프로젝트를 빌드하고 테스트를 수행합니다.
• 4. 컨테이너화 (Docker): 애플리케이션을 Docker 이미지로 빌드하고 도커 허브(DockerHub) 등 레지스트리에 푸시합니다.
• 5. 배포 (CD): 빌드된 이미지를 운영 환경(AWS EC2, 쿠버네티스 등)에 배포합니다.
  • Jib를 사용하면 Docker Daemon 없이도 효율적으로 컨테이너 이미지를 빌드할 수 있습니다. 

• 소스(Source): 개발자가 원격 리포지토리(GitHub, GitLab 등)에 코드를 푸시하여 파이프라인을 트리거.
• 빌드(Build): 소스 코드를 컴파일하고 의존성을 해결하여 실행 가능한 아티팩트(바이너리, 컨테이너 이미지) 생성.
• 테스트(Test): 유닛 테스트, 통합 테스트, 보안 검사 등을 자동화하여 코드 품질 검증.
• 배포(Deploy): 검증된 애플리케이션을 스테이징 또는 운영 서버(Kubernetes, 클라우드 환경 등)에 자동 배포. 

https://youtu.be/F3gEkZirFMU?si=bCl4CKoP8bb5O0ZJ

• CI (Continuous Integration, 지속적 통합): 여러 개발자가 작성한 코드를 정기적으로 통합하고, 자동화된 빌드와 테스트를 통해 코드의 결함을 조기에 발견하는 프로세스입니다.
• CD (Continuous Delivery/Deployment, 지속적 제공/배포):
  • Continuous Delivery: 통합된 코드를 검증 후 배포 가능한 상태로 유지하며, 실제 배포는 수동으로 승인합니다.
  • Continuous Deployment: 검증된 코드를 고객이 사용하는 운영 환경에 자동으로 배포합니다. 

1. 소스 (Source): 코드 변경(Commit)이 발생하면 파이프라인이 이를 감지하고 최신 코드를 가져옵니다.
2. 빌드 (Build): 코드를 컴파일하고 실행 가능한 형태(Artifact)로 변환하며, 필요한 종속성을 해결합니다.
3. 테스트 (Test): 유닛 테스트, 통합 테스트 등을 자동 실행하여 코드의 품질과 비즈니스 로직을 검증합니다.
4. 배포 (Deploy): 검증이 완료된 결과물을 스테이징 또는 운영 서버에 반영합니다. 

• 빠른 출시: 수동 작업을 줄여 새로운 기능이나 버그 수정을 신속하게 배포할 수 있습니다.
• 품질 향상: 자동화된 테스트를 통해 휴먼 에러를 방지하고 소프트웨어의 안정성을 높입니다.
• 협업 효율화: 코드 통합 과정의 충돌을 줄여 개발팀 간의 협업이 원활해집니다.

당신이 커리어를 설계하지 않으면, 누군가가 대신 설계할 것이다 (2014)

If You Don't Design Your Career, Someone Else Will - Greg McKeown

• 일상과 업무에 몰두한 나머지 자신의 커리어를 성찰하지 못하는 함정을 지적하며, 이를 벗어나기 위한 구체적 절차를 제시
• 지난 12개월을 검토하고 주요 프로젝트·성과를 목록화한 뒤, 그 안의 흐름과 의미를 분석하도록 권장
• 제한 없는 사고로 이상적인 커리어 방향을 구상하고, 현실적 제약으로 지나치게 빨리 포기하지 말 것을 강조
• 목표를 여섯 가지로 정리한 후 단 하나의 핵심 목표만 남기고 집중하며, 이를 방해하는 ‘좋은 일들’을 과감히 거절해야 함
• 짧은 시간의 성찰이 향후 수천 시간의 삶의 질을 바꿀 수 있음을 강조하며, 스스로 커리어를 설계할 필요성을 환기

커리어를 스스로 설계해야 하는 이유

• 사람들은 종종 삶을 사느라 바빠서 삶을 생각하지 못하는 함정에 빠짐
  • 커리어에서도 마찬가지로, 일에 몰두한 나머지 커리어 자체를 돌아보지 못하는 경우가 많음
• 이러한 상태를 피하기 위해 휴일 중 몇 시간을 투자해 커리어를 성찰하는 과정을 제안

8단계 커리어 성찰 프로세스

• 1단계: 지난 12개월 검토
  • 한 해를 월별로 돌아보며 시간 사용처, 주요 프로젝트, 책임, 성과를 목록화
  • 복잡하게 만들 필요 없이 단순한 기록으로 충분함
• 2단계: ‘무슨 일이 일어나고 있는가?’ 질문
  • 목록을 검토하며 실제로 어떤 일이 진행 중인지, 왜 중요한지, 어떤 추세가 있는지 분석
  • 이러한 추세가 계속될 경우의 결과를 생각
• 3단계: ‘무엇이든 할 수 있다면 무엇을 할 것인가?’ 질문
  • 비판 없이 자유롭게 아이디어를 적어내며, 제약 없는 사고를 유도
• 4단계: 3단계 아이디어 확장
  • 현실적 제약 때문에 지나치게 빨리 포기하지 말고, 진정 원하는 방향을 더 깊이 탐색
  • “비현실적이다”라는 이유로 배제된 길이 실제로는 정당한 커리어 경로일 수 있음
• 5단계: 향후 12개월 목표 6가지 작성
  • 달성하고 싶은 주요 커리어 목표를 우선순위에 따라 정리
• 6단계: 하위 5개 목표 삭제
  • 단 하나의 ‘진정한 북극성’ 목표에 집중
  • 업무의 소용돌이 속에서도 방향을 잃지 않게 함
• 7단계: 이번 달 실행 계획 수립
  • 3~4주 내 달성 가능한 단기 성과(quick wins) 를 설정
• 8단계: ‘무엇을 거절할 것인가’ 결정
  • 핵심 목표 달성을 방해하는 ‘좋은 일들’을 목록화하고, 삭제·연기·위임 방안을 마련
  • Ralph Waldo Emerson의 말을 인용해, “주된 목적에서 벗어나 여기저기 일하는 것이 개인과 국가를 파산시킨다”고 경고
  •