# AI 시대에도 좋은 엔지니어로 성장하기 나의 업무 원칙 AI 시대에도 좋은 엔지니어로 성장하기 AI가 개발과 업무 전반에 깊숙이 들어오면서 생산성은 빠르게 높아지고 있다. 예전에는 몇 시간씩 걸리던 조사, 코드 작성, 테스트 작성, 문서화 같은 일을 이제는 AI와 함께 훨씬 짧은 시간에 끝낼 수 있다. 이 변화는 분명 기회다. 하지만 한편으로는 경계해야 할 부분도 있다. AI에게 코드를 작성하게 하는 것이 문제가 아니라, 내가 문제를 이해하지 않은 채 문제 정의까지 넘기는 것이 문제다. AI에게 자료 조사를 맡기는 것이 문제가 아니라, 무엇을 믿고 무엇을 의심해야 하는지 판단하지 않는 것이 문제다. 따라서 앞으로의 목표는 AI를 적게 사용하는 것이 아니다. 오히려 AI는 적극적으로 사용한다. 대신 AI가 대신해도 되는 것과 내가 끝까지 소유해야 하는 것을 분명하게 구분한다. 내가 지향하는 모습은 단순한 "AI Engineer"도 아니고, AI를 거부하면서 모든 것을 직접 하는 개발자도 아니다. 내 목표는 다음과 같다. «복잡한 문제를 정확하게 이해하고, 적절한 해결책을 설계하며, AI가 유용하다면 적극적으로 활용하고, 최종 결과와 판단에 책임질 수 있는 엔지니어가 된다.» AI는 내 전문성의 중심이 아니라 내 전문성을 증폭시키는 도구다. * * * 1. 기술보다 먼저 문제를 본다 AI 시대에는 새로운 기술이 너무 빠르게 등장한다. LLM, RAG, Agent, MCP, 새로운 모델과 프레임워크가 계속 나오기 때문에 조금만 방심하면 사고의 출발점이 기술이 된다. «이걸 Agent로 만들어볼까? 여기 LLM을 넣으면 어떨까? 새로운 모델을 적용해볼까?» 하지만 기술에서 출발하면 실제로 존재하지 않는 문제를 만들어낼 수 있다. 따라서 앞으로 나는 프로젝트를 시작할 때 기술보다 먼저 문제를 본다. 먼저 묻는다. «지금 해결하려는 문제가 정확히 무엇인가? 이 문제는 실제로 얼마나 큰가? 지금은 어떤 방식으로 처리하고 있는가? 개선된다면 무엇이 좋아지는가?» 그리고 가능하다면 현재 상태를 수치로 확인한다. Baseline이 이미 있다면 그것을 사용한다. Baseline이 없다면 프로젝트를 멈추는 것이 아니라 첫 번째 작업을 Baseline 측정으로 삼는다. 완벽한 Baseline을 얻기 어렵다면 현재 확보할 수 있는 Proxy Metric이라도 정의한다. 그다음 목표를 정한다. 그리고 마지막에야 질문한다. «이 문제를 해결하기 위한 가장 좋은 수단은 무엇인가?» 그 답이 AI일 수도 있고 아닐 수도 있다. 일반적인 코드가 더 적합할 수도 있고, 정해진 Workflow가 더 안전할 수도 있고, 사람이 판단하는 것이 더 경제적일 수도 있다. 따라서 내가 지킬 첫 번째 원칙은 단순하다. «Problem Before Technology.» AI를 위한 프로젝트를 만들지 않는다. 문제를 해결한다. * * * 2. AI에게 실행은 맡겨도 판단은 맡기지 않는다 AI 시대에 모든 코드를 직접 작성하려는 것은 좋은 전략이 아니다. DTO, Mapper, CRUD, 반복적인 테스트 코드, SQL 초안, 문서화, 코드 변환, 정규식, CLI 명령 같은 작업에 계속 시간을 사용하는 것은 생산적인 마찰이 아니다. 이런 작업은 적극적으로 AI에게 맡긴다. AI를 사용해서 2시간짜리 일을 20분에 끝낼 수 있다면 그렇게 한다. AI에게 맡겼다는 이유로 죄책감을 가질 필요도 없다. 반면 다음 영역은 내가 끝까지 소유한다. * 해결해야 하는 문제 * Requirement * Business Rule * Constraint * Architecture * 중요한 데이터 구조 * Security * Trade-off * Acceptance Criteria * Evaluation 기준 * 중요한 장애의 Root Cause 구현 코드를 AI가 작성해도 괜찮다. 하지만 무엇을 구현해야 하는지까지 AI에게 결정하게 하지 않는다. 테스트 코드도 AI가 만들 수 있다. 그러나 어떤 상황을 검증해야 하는지, 어떤 Edge Case가 중요한지, 어떤 Business Rule이 절대로 깨져서는 안 되는지는 내가 결정한다. 앞으로 좋은 개발자의 차이는 코드 타이핑 속도보다 이런 곳에서 만들어질 가능성이 높다. 따라서 두 번째 원칙은 다음이다. «Execution can be delegated. Judgment cannot.» * * * 3. 중요한 문제에서는 AI보다 먼저 가설을 만든다 AI가 특히 위험하게 느껴지는 순간은 장애가 발생했을 때다. 로그를 복사해서 AI에게 붙이고 «원인 찾아줘.» 라고 하면 몇 초 안에 그럴듯한 답이 나온다. 문제를 해결하는 것만이 목적이라면 매우 편리하다. 하지만 이것을 반복하면 내가 직접 현상을 관찰하고 가설을 만드는 경험이 줄어들 수 있다. 그렇다고 AI 없이 디버깅할 필요는 없다. 내가 유지하고 싶은 것은 단 하나다. AI에게 묻기 전에 내 가설을 하나 만든다. 완벽한 가설일 필요는 없다. 한 줄이면 된다. «DB Connection Pool 부족 가능성이 가장 높아 보인다. Kafka consumer보다 downstream API가 병목일 가능성이 높다. Transaction boundary 때문에 lock 시간이 늘어난 것 같다.» 그다음 AI에게 로그와 내 가설을 함께 준다. 그리고 묻는다. «내 가설이 맞는지 검토하고 다른 가능성을 제시해줘.» 이렇게 하면 AI는 생각을 대신하는 존재가 아니라 내 가설과 경쟁하는 두 번째 분석가가 된다. 디버깅의 흐름은 다음과 같이 가져간다. 현상 → 내 가설 → AI의 가설 → Evidence → Experiment → Root Cause 여기서 중요한 것은 AI가 Root Cause를 말했다는 사실이 아니다. 어떤 증거 때문에 그것이 Root Cause라고 판단했는지 내가 이해하는 것이다. 올해 가장 먼저 습관으로 만들고 싶은 것이 바로 이것이다. «중요한 문제를 만나면 AI보다 먼저 내 가설 한 줄을 만든다.» * * * 4. 모든 것을 이해하려 하지 않고, 중요한 것을 깊게 이해한다 AI가 만든 모든 코드를 내부 동작까지 공부하려고 하면 AI를 사용하는 의미가 줄어든다. 따라서 모든 곳에 인위적인 어려움을 만들 필요는 없다. DTO가 어떻게 만들어졌는지 매번 분석할 필요는 없다. Framework의 모든 Annotation을 암기할 필요도 없다. CLI 옵션과 SDK Parameter도 필요할 때 찾으면 된다. 반대로 다음 영역은 시간이 걸리더라도 이해한다. * Transaction * Concurrency * Database * Network * Distributed System * Messaging * Authentication / Authorization * Security * Data Consistency * Performance * 핵심 Business Logic 내가 중요하게 가져갈 질문은 이것이다. «이 부분이 잘못되었을 때 중요한 문제를 내가 책임져야 하는가?» 그렇다면 내부 동작을 이해한다. 그렇지 않은 것은 필요한 만큼만 알고 AI와 문서를 활용한다. 결국 중요한 것은 지식의 양이 아니라 어떤 지식을 내 머릿속 Mental Model로 가져가야 하는지 판단하는 능력이다. * * * 5. 코드를 쓰는 능력보다 읽고 판단하는 능력을 더 중요하게 본다 AI가 코드를 많이 작성하게 되면 내가 직접 타이핑하는 코드의 비중은 자연스럽게 감소할 것이다. 그렇다고 Software Engineering 역량의 중요성이 줄어드는 것은 아니다. 오히려 AI와 다른 사람이 작성한 코드를 읽고 다음을 판단할 수 있어야 한다. * Abstraction이 적절한가 * Dependency가 이상하지 않은가 * Transaction Boundary가 맞는가 * Side Effect가 숨어 있지 않은가 * Race Condition 가능성이 있는가 * Security Risk가 있는가 * Complexity가 필요 이상으로 증가하지 않았는가 따라서 앞으로도 CS와 Backend 기본기를 유지한다. 다만 시험을 위한 암기식 공부로 하지 않는다. 목표는 하나다. «내가 운영하는 시스템이 왜 동작하고, 어떤 조건에서 깨질 수 있는지를 설명할 수 있는 Mental Model을 가진다.» Spring Annotation을 몇 개 더 아는 것보다 Transaction과 IoC가 왜 필요한지 이해하는 것이 중요하다. 특정 Framework 사용법보다 객체의 책임과 경계, Dependency, DDD, Architecture 원리를 이해하는 것이 오래 남는다. * * * 6. 만드는 능력보다 평가하는 능력을 먼저 키운다 앞으로 AI를 계속 다루겠지만, Agent Framework를 많이 써보는 것을 목표로 삼지는 않는다. AI 분야에서 가장 먼저 깊게 가져갈 것은 Evaluation이다. 중요한 질문은 «이 AI가 멋진가?» 가 아니다. «이 시스템이 실제로 잘 작동한다는 것을 어떻게 증명할 것인가?» 다. 이를 위해 다음을 익힌다. * 무엇을 정답 또는 좋은 결과라고 볼 것인가 * Golden Case를 어떻게 구성할 것인가 * 수정 후 Regression을 어떻게 확인할 것인가 * Human Evaluation이 필요한 영역은 어디인가 * 시스템 품질과 Business KPI를 어떻게 연결할 것인가 그리고 이 능력을 AI에만 적용하지 않는다. 정답이 하나로 고정되지 않는 추천 시스템, 최적화 알고리즘, 비즈니스 의사결정 로직 역시 같은 방식으로 평가할 수 있다. 따라서 이것을 단순한 "AI Evaluation"이 아니라 Evaluation Engineering이라고 생각한다. 새로운 것을 빠르게 만드는 사람은 계속 많아질 것이다. 반면 «그것이 실제로 잘 작동한다는 것을 증명할 수 있는 사람» 은 훨씬 희소할 가능성이 높다. * * * 7. 도메인은 문서, 시스템, 사람에게서 함께 배운다 앞으로 내 경쟁력을 기술 하나에만 두지 않는다. 특정 Framework의 전문성은 시간이 지나면서 가치가 크게 변할 수 있다. 반면 도메인을 깊게 이해하면서 시스템과 AI를 함께 다룰 수 있는 능력은 훨씬 오래 남는다. 도메인 지식도 하나의 출처에서 나오지 않는다. 공식 문서에는 공식 규칙이 있다. 코드와 데이터에는 실제로 시스템화된 규칙이 있다. 현업 사람들에게는 문서에 적혀 있지 않은 예외와 암묵지가 있다. 따라서 새로운 업무 문제를 다룰 때 문서만 보지 않는다. 현업과 이야기하면서 특히 다음을 확인한다. «실제로 가장 자주 발생하는 예외는 무엇인가? 문서상 프로세스와 실제 업무가 다른 부분은 어디인가? 숙련자는 어떤 정보를 보고 판단하는가? 시스템 때문에 우회해서 처리하는 업무는 무엇인가?» 월별 인터뷰 같은 새로운 의식을 만드는 것보다, 현재 맡은 문제를 해결할 때 실제 예외와 판단 기준을 현업에게 직접 물어본다. 목표는 요구사항을 전달받아 구현하는 개발자가 아니다. «현업과 함께 문제를 정의할 수 있는 엔지니어가 된다.» * * * 8. AI가 절약해준 시간을 다시 전문성에 투자한다 AI가 생산성을 높였다고 해서 내 능력이 자동으로 높아지는 것은 아니다. 예를 들어 AI 덕분에 3시간 걸리던 일을 30분에 끝냈다고 하자. 그렇게 확보한 시간을 모두 다른 반복 업무 처리에 사용하면 회사 입장에서는 생산성이 높아진다. 하지만 내 전문성이 반드시 함께 높아지는 것은 아니다. 따라서 AI가 절약해준 시간의 일부는 의도적으로 다음에 투자한다. * 시스템을 더 깊게 이해하기 * 내가 놓친 Business Rule 확인하기 * 장애의 Root Cause 복기하기 * Architecture Trade-off 생각하기 * 현업과 이야기하기 * 한 가지 중요한 개념 깊게 공부하기 AI를 통해 얻는 것은 단순히 더 많은 Output이어서는 안 된다. 일부는 반드시 더 높은 Capability로 전환한다. * * * 9. 학습을 위한 의식을 많이 만들지 않는다 좋은 원칙도 너무 많아지면 지키지 못한다. Daily Note, Weekly Deep Dive, Retrieval Test, 회고, 동료 발표를 전부 의무화하지 않는다. 올해 실제로 유지할 습관은 두 가지뿐이다. 첫 번째 습관 — Hypothesis First 중요한 장애나 설계 문제를 만났을 때: «AI에게 묻기 전에 내 가설 하나를 만든다.» 별도의 공부 시간이 필요하지 않는다. 실제 업무에 붙여서 한다. * * * 두 번째 습관 — Weekly Learning Review 기본적으로 금요일에 15~20분 정도만 돌아본다. 세 질문만 적는다. «이번 주 내가 틀렸던 것은 무엇인가?» «이번 주 새롭게 이해한 것은 무엇인가?» «다음 주 실제 업무에서 확인해보고 싶은 것은 무엇인가?» 금요일에 업무 일정이나 배포 때문에 하지 못했다면 다음 주 월요일 업무 시작 전에 이월한다. 요일을 지키는 것보다 습관을 유지하는 것이 중요하다. Deep Dive나 No-AI Test는 정기적인 의무로 만들지 않는다. Weekly Review에서 이해가 부족한 것이 발견되었을 때만 꺼내 쓴다. * * * 10. 혼자만의 판단에 갇히지 않는다 내가 이해했다고 생각하는 것과 실제로 이해한 것은 다를 수 있다. 특히 내가 무엇을 모르는지조차 모르는 영역은 혼자 확인하기 어렵다. 따라서 중요한 설계나 새로운 개념에서는 외부의 시각을 사용한다. 새로운 정기 행사를 만들지는 않는다. 실제 업무에 붙인다. 동료에게: «이 설계에서 내가 가장 잘못 생각했을 가능성이 높은 부분 하나만 찾아봐줘.» 라고 요청할 수 있다. 장애를 해결했다면: «나는 Root Cause를 이렇게 판단했는데 다른 설명이 가능한지 봐줘.» 라고 할 수 있다. 새로운 개념을 공부했다면 내가 먼저 설명한 뒤 질문을 받아본다. AI 역시 같은 방식으로 활용한다. 중요한 것은 설명을 다시 받는 것이 아니라 «내 설명을 보여주고 틀린 부분과 빠진 부분을 공격하도록 하는 것» 이다. AI를 정답 자판기가 아니라 Reviewer, Sparring Partner, Teacher로 활용한다. * * * 11. 올해 내가 투자할 세 가지 성장 축 많은 영역을 동시에 공부하려 하지 않는다. 올해는 세 가지 축을 중심으로 가져간다. 첫 번째 — Evaluation Engineering 무언가를 만들었을 때 그것이 잘 작동한다고 증명할 수 있는 능력을 키운다. AI뿐 아니라 추천, 자동화, 최적화, 비결정적 비즈니스 알고리즘에도 적용한다. 첫 착지점 현재 내가 직접 소유한 알고리즘 또는 추천 시스템 하나를 대상으로: * 대표적인 Golden Case를 만든다. * 좋은 결과와 나쁜 결과를 판단하는 기준을 정의한다. * 수정 이후 Regression을 확인할 수 있도록 한다. * 가능하다면 Business Metric과 연결한다. 처음부터 거대한 Evaluation Platform을 만들지 않는다. 실제 사례를 평가하는 작은 데이터셋 하나부터 시작한다. * * * 두 번째 — Software / System Fundamentals 실제 업무에서 부딪히는 영역을 중심으로 깊게 가져간다. * Database * Transaction * Concurrency * Messaging * Distributed System * Architecture * Security * Observability Framework 자체보다 그 뒤의 원리를 이해한다. 첫 착지점 올해 실제 운영 과정에서 발생하는 장애나 중요한 기술 문제 중 하나를 선택해: 현상 → 내 Hypothesis → Evidence → Experiment → Root Cause → 재발 방지 까지 끝까지 분석한 기록을 남긴다. 실제 업무를 그대로 공부의 재료로 사용한다. * * * 세 번째 — Domain + Business 도메인 전체 흐름과 Business Rule을 이해하고 기술적인 성공을 Business Outcome과 연결한다. 모든 중요한 프로젝트에서 최소한 다음을 설명할 수 있도록 한다. «어떤 문제였는가? 이전에는 어느 정도였는가? 무엇을 바꿨는가? 실제로 무엇이 얼마나 개선됐는가?» 첫 착지점 현재 맡은 업무 하나를 선택해 현업과 이야기하면서: * 문서에 없는 예외 * 실제 숙련자의 판단 기준 * 시스템과 실제 업무의 차이 * 현재 가장 큰 Pain Point 를 찾아내고 실제 시스템의 Rule 또는 설계와 연결한다. * * * 12. 현재 업무 밖의 성장은 Career Capital로 관리한다 "Learn From Real Work"는 매우 좋은 원칙이지만 한계가 있다. 현재 업무가 제공하지 않는 역량은 실제 업무만으로는 배울 수 없다. 특히 다음 역할이나 이직을 위해 필요한 기술은 의도적으로 준비해야 한다. 따라서 세 가지 업무 성장 축과 별도로 Career Capital Track을 둔다. 이 트랙에는 현재 업무에서 자연스럽게 얻을 수 없는 다음 역량이 들어갈 수 있다. * 목표 기술 스택 * Java / Spring 실전 경험 * 객체지향 설계 * IoC / DI * DDD * Transaction Boundary * Layered / Hexagonal Architecture * System Design * 기술 면접에 필요한 핵심 역량 여기서 Framework API 암기를 목표로 하지 않는다. «Framework를 이용해 실제 시스템을 설계하고 그 설계 원리를 설명할 수 있는 상태» 를 목표로 한다. 현재 업무에서 배우는 것과 미래 커리어를 위해 의도적으로 준비해야 하는 것을 섞지 않는다. 둘 다 필요하다. Career Capital의 첫 착지점 내가 이미 충분히 이해하고 있는 실제 업무 또는 도메인 기능 하나를 선택해 목표 기술 스택으로 다시 설계하고 구현한다. 새로운 도메인을 배우는 프로젝트가 아니라 익숙한 문제를 새로운 방식으로 설계함으로써 다음을 훈련하는 프로젝트로 만든다. * 객체의 책임과 경계 * Dependency 방향 * IoC / DI * Domain Model * Aggregate * Transaction Boundary * Layering * Hexagonal Architecture * Error Handling * Test Strategy 단순히 실행되는 코드가 만들어지는 것을 완료 기준으로 삼지 않는다. 프로젝트가 끝났을 때 다음을 설명할 수 있어야 한다. «왜 이 객체에 이 책임을 주었는가? 왜 이 Domain Boundary를 선택했는가? Transaction은 왜 여기에서 시작하고 끝나는가? Dependency 방향을 왜 이렇게 만들었는가? 기존 방식과 비교하면 무엇이 좋아졌고 무엇이 나빠졌는가? 요구사항이 변경된다면 어디가 가장 먼저 영향을 받는가? 트래픽이나 데이터 규모가 커진다면 무엇을 바꿔야 하는가?» 코드보다 설계 판단이 남는 프로젝트를 만든다. Career Capital에서의 AI 사용 원칙 이 트랙에서는 결과물을 빠르게 만드는 것보다 과정에서 설계 판단 능력을 얻는 것이 중요하다. 따라서 학습하려는 핵심 설계와 판단은 내가 직접 수행한다. AI에게 맡겨도 되는 것은 적극적으로 맡긴다. 예를 들면: * Boilerplate * 반복적인 Mapping * Test Fixture * 단순 Configuration * 반복 코드 * 문서 정리 등이다. 반대로 다음은 먼저 내가 생각한다. * Domain Boundary * 객체 책임 * Aggregate * Dependency * Transaction Boundary * Architecture * Trade-off AI가 제시한 핵심 코드를 내가 설명할 수 없는 상태로 받아들이지 않는다. 이 트랙에서 AI는 구현자보다 다음 역할을 우선한다. * 내 설계를 공격하는 Reviewer * 다른 대안을 제시하는 Sparring Partner * 이해하지 못한 원리를 설명하는 Teacher 원칙은 간단하다. «AI 사용을 금지하는 것이 아니라, 학습 목표가 되는 사고를 위임하지 않는다.» Career Capital을 위한 시간 Evaluation, System, Domain은 실제 업무 속에서 어느 정도 자연스럽게 훈련된다. Career Capital은 그렇지 않다. 따라서 주 1회 약 3시간 정도의 집중 시간을 기본값으로 확보한다. 한 주를 놓쳤다고 다음 주에 6시간을 하려고 하지 않는다. 못한 것은 실패로 기록하고 다음 주에 다시 원래 리듬으로 돌아간다. 목표는 완벽한 연속성이 아니라 장기간 살아남는 학습 구조를 만드는 것이다. * * * 13. 올해 의도적으로 하지 않을 것 반대로 시간을 덜 쓰는 영역도 명확하게 정한다. * Syntax 암기 * Framework 최신 기능 무한 추적 * Prompt Technique 수집 * Agent Framework 무한 비교 * 새로운 AI 모델이 나올 때마다 테스트하기 * AI 뉴스 무한 소비 * 의미 없이 노트를 많이 만드는 것 * 학습 시스템 자체를 계속 최적화하는 것 새로운 정보가 많다는 이유로 모두 알아야 하는 것은 아니다. 나는 쉽게 사라지는 지식보다 오래 남는 판단 구조에 투자한다. 특히 이 문서 자체를 계속 다듬는 것을 또 하나의 생산성 활동으로 만들지 않는다. 현재 버전을 실제 업무에서 충분히 사용하기 전에는 새로운 원칙을 계속 추가하지 않는다. * * * 14. 이 성장 시스템 자체도 검증한다 프로젝트에는 Baseline과 Evaluation을 요구하면서 내 성장 방식은 감으로 판단해서는 안 된다. 하지만 복잡한 KPI를 만들지는 않는다. 분기에 한 번 몇 분만 확인한다. 질문은 «얼마나 열심히 했는가?» 가 아니다. «실제로 무엇이 남았는가?» 다. 다음과 같은 Artifact의 존재 여부를 본다. Hypothesis 최근 중요한 장애나 설계에서 AI보다 먼저 내가 적은 가설이 실제로 남아 있는가? Weekly Review 최근 몇 주의 Learning Review 기록이 존재하는가? Evaluation Golden Case, Evaluation Criteria, Regression 결과처럼 실제로 만들어진 평가 자산이 있는가? System 실제 문제 하나에 대해 Root Cause와 재발 방지까지 설명할 수 있는 기록이 있는가? Domain 현업에게서 새롭게 배운 예외나 판단 기준이 시스템 이해 또는 설계에 반영된 사례가 있는가? Career Capital 현재 업무 밖의 미래 역량을 위해 실제로 만든 코드, 프로젝트 또는 결과물이 있는가? 없다면 나 자신을 탓하기보다 현재 성장 방식이 작동하지 않는다고 판단하고 수정한다. 분기 점검은 자책을 위한 도구가 아니라 Feedback Loop다. * * * 15. 올해 말에는 능력을 주장하지 않고 Evidence를 본다 올해 말에는 몇 권을 읽었는지, 몇 개의 Framework를 배웠는지로 성장 여부를 판단하지 않는다. 실제로 무엇을 했는지 확인한다. Problem Solving 기술부터 선택하지 않고 문제와 Baseline부터 정의했던 프로젝트가 실제로 있는가? Judgment AI가 제시한 답과 다른 판단을 내렸고, 그 이유를 실제로 설명한 사례가 있는가? System 내가 담당하는 시스템의 중요한 동작이나 설계 판단을 실제로 다른 개발자에게 설명한 사례가 있는가? Debugging AI가 Root Cause를 말하기 전에 내가 의미 있는 가설을 세우고 검증했던 장애 사례가 있는가? Evaluation 내가 직접 만든 Golden Case, Evaluation Criteria 또는 Regression 결과가 있는가? Domain 현업과 Business Rule이나 예외를 논의하면서 내가 먼저 질문하거나 새로운 문제를 발견한 사례가 있는가? Business 내가 만든 시스템이 처리시간, 품질, 비용, 전환율, Risk 등 실제 지표에 어떤 변화를 만들었는지 설명한 사례가 있는가? Career 현재 업무만으로 채워지지 않는 역량을 위해 실제로 만든 시스템이나 코드가 있는가? 그리고 그 코드에서 핵심 설계 판단을 다른 개발자에게 설명한 적이 있는가? 능력을 “가지고 있다”고 주장하기보다 그 능력이 실제로 사용된 흔적을 찾는다. * * * 16. 실제 업무에서는 다섯 가지만 기억한다 이 문서 전체를 매일 기억할 필요는 없다. 실제 업무에서는 다음 다섯 가지만 기억한다. 1. Problem Before Technology 기술을 고르기 전에 문제를 이해한다. 2. Hypothesis Before AI 중요한 문제에서는 AI보다 먼저 내 생각을 하나 만든다. 3. Delegate Execution, Own Judgment 실행은 적극적으로 위임하지만 중요한 판단은 내가 한다. 4. Measure Before Believing AI든 사람이든 결과를 감으로 믿지 않고 가능한 한 측정한다. 5. Learn From Real Work 실제 장애, 설계, 프로젝트, 현업 문제를 가장 중요한 학습 재료로 사용한다. 다만 현재 업무가 주지 못하는 미래 역량은 Career Capital Track을 통해 의도적으로 확보한다. * * * 맺음말 AI 시대를 준비한다는 것은 AI 관련 기술을 가장 많이 아는 사람이 되는 것이 아니다. AI를 거부하면서 예전 방식만 고집하는 것도 아니다. 내가 만들고 싶은 경쟁력은 훨씬 단순하다. «문제를 잘 이해하고, 좋은 판단을 하고, 견고한 시스템을 만들며, 내가 일하는 도메인을 깊게 이해하는 것.» 그리고 AI가 나보다 잘할 수 있는 일은 적극적으로 맡긴다. 그렇게 확보한 시간과 여력을 다시 내 전문성에 투자한다. AI에게 생각하지 않아도 되는 일을 넘기되, «생각해야 하는 문제에서는 AI 때문에 생각을 덜 하는 것이 아니라 오히려 더 깊게 생각한다.» 앞으로 내가 확인할 것은 얼마나 많은 공부를 했는지가 아니다. 무엇을 실제로 만들었는지, 어떤 판단을 했는지, 어디에서 틀렸고 무엇을 새롭게 이해했는지다. 현재 업무에서는 실제 문제를 통해 성장하고, 현재 업무가 줄 수 없는 미래의 역량은 별도의 Career Capital로 의도적으로 만든다. AI를 썼는지 여부보다 중요한 것은 어떤 사고를 내가 했고 어떤 사고를 위임했는가다. 결국 목표는 AI 시대에 살아남는 것이 아니다. «AI가 있든 없든 좋은 엔지니어가 되고, AI가 있을 때 그 능력을 훨씬 크게 증폭시킬 수 있는 사람이 되는 것.» 이 문서는 그 목표를 위한 완성된 방법론이 아니다. 실제 업무에서 실행하고, 결과를 남기고, 실패를 확인하기 위한 현재의 Operating Principle이다. 이제 당분간 문서를 고치기보다 실제로 사용한다. 다음 개정은 더 좋은 문장을 발견했을 때가 아니라, 실제 업무에서 이 원칙이 작동하지 않았다는 Evidence가 생겼을 때 한다.