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

[System] Everything I know about good system design, 좋은 시스템 설계

• 
  좋은 시스템 설계란 복잡해 보이지 않고 오랜 기간 별다른 문제가 발생하지 않는 형태
• 상태(state) 를 다루는 것이 시스템 설계에서 가장 어려운 부분이며, 가능한 한 상태를 저장하는 컴포넌트 수를 줄이는 방향이 중요
• 데이터베이스는 주로 상태가 보관되는 위치로, 스키마 설계와 인덱싱, 병목 해소에 중점을 둔 접근이 필요
• 캐싱, 이벤트 처리, 백그라운드 작업 등은 성능 및 유지보수를 위해 신중하게 도입해야 하며, 남용을 피하는 것이 좋음
• 복잡한 설계보다는 충분히 검증된 간단한 컴포넌트 및 방법론을 적절하게 사용하는 것이 지속 가능하고 안정적인 시스템 구축에 핵심

시스템 설계의 정의와 전체적인 접근

• 소프트웨어 설계가 코드의 조립이라면, 시스템 설계는 다양한 서비스를 조합하는 과정
• 시스템 설계의 주요 구성 요소는 앱 서버, 데이터베이스, 캐시, 큐, 이벤트 버스, 프록시 등
• 좋은 설계는 "특별한 문제가 없다", "생각보다 쉽게 끝나다", "이 부분은 신경 쓸 필요가 없다"와 같은 반응을 이끌어냄
• 반대로 복잡하고 눈에 띄는 설계는 근본 문제를 감추거나, 과도한 설계를 나타낼 수 있음
• 복잡한 시스템은 초기부터 바로 도입하기보다는, 최소한의 작동 가능한 단순한 구조에서 점차 발전하는 방향이 유리함

상태(state)와 무상태(stateless)의 구분

• 소프트웨어 설계에서 가장 까다로운 부분이 바로 상태 관리
• 정보를 저장하지 않고 즉시 결과를 반환하는 서비스(GitHub의 PDF 렌더링과 같은)는 무상태적임
• 반면 데이터베이스에 쓰기를 수행하는 서비스는 상태를 관리함
• 시스템 내 상태 저장 컴포넌트를 최대한 줄이는 것이 좋음. 이는 시스템의 복잡도와 장애 발생 가능성을 낮춤
• 상태 관리를 한 서비스에서만 수행하고, 나머지 서비스는 API 호출 혹은 이벤트 발생 등 무상태 역할에 집중하는 구조가 권장됨

데이터베이스 설계와 병목 지점

스키마 및 인덱스 설계

• 데이터 보관을 위해서는 사람이 읽기 쉬운 형태의 스키마 설계가 필요함
• 너무 유연한 스키마(예: 전체를 JSON 컬럼에 저장)는 애플리케이션 코드 및 성능에 부담을 줄 수 있음
• 쿼리가 빈번하게 발생할 컬럼을 기준으로 적절한 인덱스를 설정해야 함. 모든 것에 인덱스를 거는 것은 오히려 쓸데없는 오버헤드 발생

병목 해결 방법

• 데이터베이스 접근이 종종 무거운 병목이 됨
• 가능한 한 복잡한 데이터를 애플리케이션에서가 아닌 데이터베이스 내에서 조인(JOIN) 등으로 처리하는 것이 성능상 유리함
• ORM 사용 시, 루프 안에서 쿼리를 발생시키는 실수를 주의해야 함
• 필요에 따라 쿼리를 분할하여, 데이터베이스의 부담이나 쿼리 복잡도를 조절하는 것도 한 방법
• 읽기 쿼리는 복제본(read-replica)으로 분산하여, 주(Write) 노드의 부하를 줄이는 전략이 효과적
• 대량의 쿼리가 몰릴 때 트랜잭션 및 쓰기 연산은 데이터베이스를 쉽게 과부하 상태로 만들 수 있으므로, 쿼리 스로틀링(제한) 처리를 고려해야 함

느린 작업과 빠른 작업의 분리

• 사용자가 인터랙션하는 작업은 수백 밀리초 내 응답이 필요
• 시간이 오래 걸리는 작업(예: 대용량 PDF 변환 등)은 최소한의 작업만 프론트에서 즉시 제공하고, 나머지는 백그라운드로 넘기는 패턴이 효과적
• 백그라운드 작업은 일반적으로 큐(예: Redis)와 잡 러너가 묶여 동작
• 멀리 예약된 작업 처리는 Redis보다 DB 테이블을 별도로 만들어 관리하고, 스케줄러를 이용하여 실행하는 형태가 실용적

캐싱

• 캐싱은 동일하거나 비싼 연산을 반복하는 경우 비용 절감과 성능 향상에 기여
• 보통 캐시를 처음 배운 주니어 엔지니어는 모든 것을 캐시하고 싶어하고, 경험 많은 엔지니어일수록 캐시 도입은 신중
• 캐시는 새로운 상태를 도입하므로, 동기화 이슈/오류/스테일 데이터 등의 위험이 존재
• 먼저 쿼리의 인덱스 추가 같은 성능 개선을 시도한 뒤 캐싱을 적용하는 것이 바람직
• 대용량 캐시는 Redis/Memcached가 아니라 S3/Azure Blob Storage와 같은 문서 저장소에 주기적으로 저장하는 방식도 활용 가능

이벤트 처리

• 대부분의 기업은 이벤트 허브(예: Kafka) 를 갖추고, 다양한 서비스가 이벤트 기반으로 분산 처리
• 이벤트의 남발보다는, 단순한 요청–응답 API 설계가 로깅과 문제 해결 면에서 더 유용
• 이벤트 기반 처리는 발신자가 수신자 동작에 신경 쓰지 않아도 될 때, 혹은 고용량·지연 허용 시나리오에 적합

데이터의 전달 방식: 푸시와 풀

• 데이터 전달에는 Pull(요청 후 응답) 과 Push(변경 시 자동 전달) 두 방식이 있음
• Pull 방식은 단순하지만 반복 요청/과부하 문제가 발생
• Push 방식은 서버에서 데이터 변경 시 클라이언트에 즉시 전달하므로, 효율적이며 최신 데이터 유지에 유리
• 대량 클라이언트 처리에는 각각 방식에 맞게 인프라(이벤트 큐, 여러 캐시 서버 등) 확장이 필요

핫패스(Hot Paths) 집중

• 핫패스란 시스템 내에서 가장 중요하고 데이터가 많이 흐르는 경로를 의미
• 핫패스는 선택지가 적고, 설계 실패 시 서비스 전체에 심각한 문제를 유발할 수 있으므로, 신중한 설계가 필수
• 옵션이 다양한 마이너 기능보다, 핫패스에 집중하여 설계 및 테스트에 자원을 배분하는 것이 효과적

로깅, 메트릭, 추적

• 장애 발생 시 원인 진단을 위해, 비정상 경로(unhappy path)에 대한 상세 로그 기록을 적극적으로 해야 함
• 시스템 자원(CPU/메모리), 큐 크기, 요청/작업 시간 등 기본적인 관측성 지표 수집이 필요
• 평균값만 보는 대신 p95, p99 지연 시간 같은 분포 지표도 반드시 관찰해야 함. 상위 소수의 느린 요청이 핵심 사용자의 문제일 수 있음

킬스위치, 재시도, 장애 복구

• 킬스위치(시스템 일시 차단) , 재시도의 전략적 활용이 중요함
• 무작정 재시도는 다른 서비스에 부담만 주며, 사전에 회로 차단기(circuit breaker) 등으로 요청을 제어해야 효과적임
• Idempotency Key(멱등키) 도입으로 동일 요청 재처리 시 중복 작업 방지가 가능함
• 일부 장애 상황에서 열린 실패(fail open) 또는 닫힌 실패(fail closed) 중 선택이 필요함. 예를 들어, Rate Limiting은 fail open(허용) 쪽이 사용자 영향이 적은 방향임. 반면 인증은 fail closed가 필수임

마무리

• 서비스 분리, 컨테이너, VM 도입, 트레이싱 등 일부 주제는 생략됐으나, 잘 검증된 컴포넌트를 적재적소에 사용하는 것이 장기적으로 가장 안정적인 시스템 구축으로 이어짐
• 기술적으로 특별한 설계는 실제로 매우 드물며, 지루할 정도로 단순한 설계가 오히려 실무에서 가장 자주 쓰임
• 본질적으로 좋은 시스템 설계란 눈에 띄지 않고, 충분히 입증된 방법론을 안전하게 조합하는 과정임

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

팀을 이끄는 역할을 맡으면, 구성원들은 수많은 중요한 결정에서 최종 판단을 기대하게 된다. 사람들은 결단력 있는 리더를 신뢰한다. 하지만 결단력은 쉽게 익힐 수 있는 능력이 아니다. 자신이 내린 결정의 결과를 감당해야 하며, 역사를 돌아보면 무모할 정도로 대담한 결정을 내렸다가 조직을 위기로 몰아넣은 리더들도 많다. 그렇다고 해서 데이터를 더 수집할 때까지 무작정 기다릴 수도 없다. 망설이는 순간, 그 자체가 하나의 결정이 될 수도 있기 때문이다.

클라우드 ERP 솔루션 기업 서티니아(Certinia)의 CPTO 라주 말호트라는 “결단력을 갖는 것은 쉬운 일이 아니다”라며 “불완전한 정보를 바탕으로 매우 빠르게 판단을 내려야 하는 경우가 많다”라고 말했다.

결단력을 키우기 위해 고민해온 기술 리더들에게 이야기를 들어봤다. 이들은 효과적인 전략과 접근 방식을 공유하며, 결단력을 발휘하는 것이 어떻게 리더십 스타일로 자리 잡을 수 있는지를 설명했다.

1. 호기심을 가지기
모든 상황에서 모든 것을 아는 사람처럼 행동하는 것이 결단력 있어 보일 수도 있다. 하지만 말호트라는 “호기심을 갖는 것이 더 중요하다”라고 설명했다.

AI 기반 자동화 및 데이터 분석 솔루션 업체 로보AI(RoboAI)의 CTO인 데이브 커티스는 “물론 ‘나는 세상을 다 이해하고 있고, 모든 답을 알고 있다’라고 말하는 것이 강한 리더처럼 보일 수 있다”라고 말했다. 하지만 실제로는 모든 것을 다 알 수 없다. 특히 기술 분야에선 더더욱 그렇다.

커티스는 “방향성을 제시하고 답을 찾는 과정을 안내하는 것도 똑같이 중요하다”라고 “개인적 경험상 ‘나도 완벽한 답을 가지고 있는 것은 아니다. 가능한 선택지를 탐색해보자’라고 말하니 많은 이의 참여를 이끌 수 있었다”라고 말했다.

리더는 의사결정 과정에 참여시키되, 의사결정의 수준에 대한 틀을 제공해야 한다. 전략적 결정인가? 특정 상황에 국한된 결정인가? 어떤 맥락에서 내려지는가? 같은 부분을 정의해주는 것이다.

커티스는 “나는 마치 사회자처럼 논의를 이끌면서 팀이 자유롭게 의견을 나눌 수 있도록 지원했다”라고 말했다.

이 과정은 다양한 정보 수집뿐만 아니라, 팀원들이 의사결정 역량을 키우는 데도 도움이 된다. 또한 회사의 의사결정 방향을 따르게 하면서, 보다 신속하게 결론에 도달할 수 있도록 한다. 말호트라는 “호기심을 가지는 것은 리더로서 매우 중요한 덕목이다”라고 말했다.

2. 명확성을 제공하고 목표에 집중하기
말호트라는 “많은 이가 리더에게 기대하는 것은 명확성이다”라며 “비전의 명확성, 전략의 명확성, 계획의 명확성, 프로세스의 명확성, 그리고 성공을 측정하는 기준의 명확성이 필요하다”라고 설명했다.

단순히 답을 제시하는 것이 중요한 것이 아니라, 의사결정 과정을 명확하게 정리하는 것이 더 중요하다. 말호트라는 “리더는 조직의 원동력을 증폭시키는 존재다. 이때 그 리더십의 수준은 스칼라가 아닌 벡터의 성질을 가진다. 규모뿐만 아니라 방향이 매우 중요하기 때문에 벡터인 것이다. 따라서 조직의 잠재력을 증폭시키는 촉매가 되려면 달성하고자 하는 최종 목표가 명확해야 한다”라고 설명했다.

리더는 성공이 정확히 무엇을 의미하는지 알려야 한다. 목표를 명확히 하고, 그 목표로 가는 과정에서 선택할 수 있는 경로를 나열해야 한다. 중간 목표를 설정하고, 목표 달성까지의 단계를 설명하며, 성공 여부를 어떻게 측정할 것인지도 명확히 해야 한다.

말호트라는 “이러한 명확성이 리더의 머릿속에만 있는 것이 아니라 팀과 공유될 때, 자연스럽게 결단력이 생긴다”라고 말했다.

3. 의사결정을 복잡성과 영향력에 따라 분류하기
AI옵스 및 IT 운영 자동화 기업 디지테이트(Digitate)의 유럽 시장 CTO 에프레인 루는 “결정을 내릴 때 긴급성과 중요성을 중심으로 생각해야 한다”라고 말했다.

결정이 복잡하고 중요한 사안이라면, 충분한 시간을 들여 최대한 많은 정보를 수집해야 한다. 하지만 쉽게 되돌릴 수 있는 결정이라면, 그는 “너무 깊이 고민하지 않으려 한다”라고 조언했다.

말호트라는 결정의 종류를 ‘단일문(single-door) 결정’과 ‘이중문(double-door) 결정’이 있다고 소개했다. 일단 단일문 결정은 한 번 내리면 되돌릴 수 없는 결정이다. 말호트라는 “단일문 스타일의 결정은 돌이킬 수 없는 만큼, 신중하게 검토하고 회사의 비전과 조율해야 한다”라고 설명했다.

하지만 조직 내 결정 대부분은 이중문 결정이다. 말호트라는 “이중문 스타일의 결정은 실행해보고 뭔가 잘 안 풀리면 다시 돌아올 수 있다”라며 “이 경우, 신속하고 단호한 의사결정이 중요하다”라고 말했다.

즉, 조직의 정책을 바꾸거나 쉽게 철회할 수 없는 인프라를 도입하는 것과 같은 결정이 아니라면, 지나치게 고민할 필요가 없다. 필요한 경우 나중에 조정하면 된다.

4. 결정의 영향력을 예측해보기
리더의 위치에 서면 자연스럽게 전략적인 관점에서 사안을 바라보게 된다. 하지만 최종 결정이 가장 직접적으로 영향을 미치는 것은 현장에서 일하는 사람들이다.

루는 “나는 항상 실제 현장에서 어떤 일이 벌어지는지 놓치지 않으려 한다”라며 “내가 직접 그 상황에 있다고 가정하고, 앞으로 일어날 일을 단기적으로 시뮬레이션한다”라고 설명했다.

의사 결정이 현장에서 어떤 영향을 미칠지 논리적으로 추론해볼 수도 있지만, 해당 상황에 놓여 있는 사람에게 직접 의견을 구하는 것도 좋은 방법이다.

루는 “그들은 나보다 최근의 경험을 가지고 있기 때문에, 내가 생각하지 못한 통찰력을 제공할 수도 있다”라고 말했다.

5. 의사결정의 기준을 정하고 위임하기
조직에서 자신의 역할과 책임을 명확히 이해하는 것은 중요하다. 어떤 결정이 자신의 몫인지, 어떤 결정은 상위 리더에게 넘겨야 하는지, 또 어떤 결정은 팀에 위임해야 하는지를 구분해야 한다. 팀이 리더에게 반드시 상의해야 할 사항을 독단적으로 결정하는 것도 문제지만, 반대로 모든 결정을 리더에게 떠넘기는 것도 바람직하지 않다.

로보AI의 커티스는 “나는 의사결정의 기준을 설정했다”라며 “모든 세부 사항에 직접 관여할 수는 없다. 그래서 정기적인 회의를 통해 결정의 우선순위를 정한다”라고 말했다. 가령 특정 사항과 연관된 팀이 직접 결정할 수 있는 사항 그리고 실무팀이 결정해서는 안 되는 사항을 직원에게 알려줬다고 설명했다.

커티스는 “예를 들어, 개발자가 사용할 생산성 도구와 관련된 것이라면, 그 결정은 개발자에게 맡긴다”라며 “그런 도구가 개발자의 일상 업무에 영향을 주지만, 회사 전체의 전략에 영향을 미치는 것은 아니기 때문이다”라고 설명했다.

반면, 커티스는 막대한 투자가 필요하거나 광범위한 영향을 미칠 수 있는 사안의 경우, 회사의 장기적 목표와 재무를 고려하는 팀이 결정하는 것이 더 낫다고 설명했다.

빠른 결정이 필요할 때도 있지만, 모든 결정을 직접 내리려 하면 결국 과부하에 걸릴 수밖에 없다. 거기다 그런 구조 속에선 팀이 자율성을 갖지 못하고, 성장하지 못한다. 커티스는 “의사결정의 기준과 구조를 명확히 정립하는 것은 리더가 반드시 해야 하는 일이다”라고 말했다.

6. 이해관계자를 파악하기
커티스가 언급한 ‘의사결정의 기준’에서 중요한 요소 중 하나는 조직 내 이해관계자를 파악하는 것이다. 그는 “결단력 있는 리더가 되려면 이해관계자를 잘 이해해야 한다”라고 설명했다.

이해관계자들의 의사결정 방식을 기본적으로만 파악하고 있어도, 그들의 의견을 반영해야 할 사안인지 쉽게 판단할 수 있다.

커티스는 “내 팀원이 내가 어떻게 의사결정을 하는지 이해하길 바란다”며 “마찬가지로 나도 상위 리더의 의사결정 스타일을 파악하려 노력한다. 모든 세부 과정에 직접 관여하는 상사가 있는가 하면, 팀의 자율성을 존중하는 상사도 있기 때문이다”라고 설명했다.

이해관계자를 제대로 파악하지 못하면, 어떤 결정이 자신의 권한 내에 있는지 확신하기 어려워진다. 커티스는 “이런 상황이 지속되면 사람들이 같은 문제를 고민하며 시간을 낭비한다”라며 “의사결정의 기준이 명확하지 않으면, 혼란이 생긴다. 자신의 권한이 어디까지인지 모르면, 결국 결정을 내리지 못하는 경우가 많다”라고 말했다.

7. 완벽한 데이터가 없어도 결정을 내리기
말호트라는 대부분의 결정이 ‘이중문 결정’, 즉 되돌릴 수 있는 결정이라고 했다. 이러한 결정은 완벽한 증거 데이터가 없어도 일단 내려야 한다.

기업용 경비 관리 및 결제 솔루션의 엠버스(Emburse)의 CTO 켄 링달은 “앞서가는 경쟁자를 이기려면 신속하게 움직여야 한다”라며 “현재 상황에 맞춰 대응하는 것이 아니라, 앞으로의 상황 변화를 예측하고 대응해야 한다”라고 설명했다.

그는 경험이 많을수록 이런 결정을 내리기가 더 수월하다고 설명했다. 링달은 “어느 정도 확신을 가지고 결정을 내릴 근거가 필요하다”라고 말했다. 하지만 데이터를 완전히 확보할 때까지 기다리다 보면, 오히려 지나치게 깊이 파고들면서 결정을 내리지 못하는 상황에 빠질 수 있다.

링달은 “너무 오래 고민하면, 점점 한 가지 요소에만 집중하게 된다. 그러다 보면 분석이 과해지고 결정을 내리는 것이 점점 어려워진다”라고 설명했다.

빠른 의사결정의 진정한 핵심은 구체적인 근거나 데이터가 나올 때면 기꺼이 마음을 바꾸겠다는 태도다. 링달은 “결정을 일단 내리자. 단, 구체적 근거나 데이터가 새로 생긴 후에 모순을 인정하거나 결정을 번복하는 것을 두려워하지 말아야 한다”라며 “사람들은 이를 ‘빠른 실패(fail fast)’라고 표현하기도 한다”라고 설명했다.

8. 기본 지식을 쌓아 자신감을 키우기
링달은 “결정을 내리는 것을 주저하는 사람들을 보면, 자신감이 부족한 것이 보인다”라고 “이들은 자신의 경험을 신뢰하지 못하거나, 데이터를 믿지 못하는 경우가 많다. 또는 데이터를 직접 분석해본 적이 없을 수도 있다”라고 설명했다.

새로운 역할을 맡았을 때 특히 이런 현상이 자주 나타난다. 그는 “자신감은 경험에서 나온다”라며 “새로운 역할을 맡았기에 ‘이것이 올바른 방법이다’라고 확신할 만한 경험이 부족한 것이다”라고 설명했다.

망설여질 때는 질문을 하거나, 데이터를 파헤치거나, 비슷한 상황을 찾아봄으로써 상황이나 기술에 대한 기초 지식을 쌓아야 한다. 링달은 “훌륭한 리더는 좋은 질문을 던지는 사람이라고 생각한다”고 말했다. 스스로 결정을 내리지 않더라도, 이 방법은 사람들이 올바른 결정을 내리는 데 도움이 될 수 있다.

링달은 “나는 ‘x, y, z를 생각해 보셨습니까?’, ‘이런 가능성은 어떻게 생각하나요?’같은 유도 질문을 한다”라며 “이렇게 질문하면 팀원이 올바른 방향으로 생각하도록 할 수 있을 뿐 아니라, 필요한 답을 얻을 수 있다”라고 설명했다.

9. AI에 대한 전략적 판단 능력 기르기
데이터 과학 및 머신러닝 플랫폼 업체 도미노 데이터 랩(Domino Data Lab) AI 전략 총괄 켈 칼슨은 “IT 리더들은 AI 전략에 대한 결정을 보다 신속하고 명확하게 내릴 수 있어야 한다”라고 강조했다.

기술 리더들이 AI 관련 결정을 내리는 데 어려움을 겪는 가장 큰 이유는, 링달이 지적한 대로 이 분야에 대한 경험과 자신감이 부족하기 때문이다. 칼슨은 “AI나 머신러닝에 대한 배경 지식이 없는 경우가 많다”라고 설명했다.

그럼에도 불구하고, AI 관련 의사결정은 IT 리더들이 직접 내려야 한다. 칼슨은 “AI와 머신러닝 역량에 대한 투자 방향을 결정하고, 어떤 AI 활용 사례를 우선순위에 둘지 판단하는 것은 IT 리더의 몫이다. 그래야 기업이 AI를 통해 실질적인 변화를 이끌어낼 수 있다”라고 말했다.

다른 의사결정과 마찬가지로, 기본적인 지식을 쌓는 것이 AI 전략을 세우는 데도 도움이 된다. 칼슨은 “AI는 기존의 데이터 중심 기술과 많은 공통점을 가진다”라며 “세부적으로 들여다보면 물론 차이가 있지만, AI 이니셔티브를 실행하기 위해 제기하고 답해야 하는 핵심 질문은 대체로 동일하다. 어떻게 구현할 것인가? 어떤 자원이 필요한가? 어떤 위험이 있는가? 어떻게 관리할 것인가?”라고 설명했다.

이러한 질문에 답하는 것은 조직의 최고 경영진만이 할 수 있는 역할이다. 칼슨은 “이런 질문에 대한 답을 검증하는 것은 리더들의 책임이다”라고 밝혔다

https://www.cio.com/article/3826476/%eb%b6%88%ed%99%95%ec%8b%a4%ed%95%a0-%eb%95%8c%eb%8f%84-%ea%b2%b0%ec%a0%95%ec%9d%80-%ed%95%b4%ec%95%bc-%ed%95%9c%eb%8b%a4%c2%b7%c2%b7%c2%b7-%ea%b2%b0%eb%8b%a8%eb%a0%a5-%ec%9e%88%eb%8a%94-%eb%a6%ac.html

1.용기와 위험 관리 능력
2.데이터 자산의 수익화 이해
3.데이터 거버넌스와 윤리에 집중
4.지성과 감성의 균형 유지

IT 서비스 기업 아바나데(Avanade)가 발표한 ‘생성형 AI 준비도 보고서’에 따르면, 응답자의 90% 이상이 경쟁력 유지를 위해 올해 말까지 AI 중심 운영 모델로 전환해야 한다고 언급했다. 이 조사는 연간 매출 5억 달러 이상인 기업의 비즈니스 및 IT 임원 3,000명을 대상으로 실시됐다.

변화에 대응하기 위해서는 기존의 ‘직무 기술서’에는 없는 새로운 형태의 IT 리더십 기술과 비즈니스 통찰력이 필요하다. 디지털 시스템을 원활하게 운영하면서 경영진과 완벽한 비즈니스 파트너가 되는 것이 오늘날 IT 리더에게 요구되는 역량이다. 다음은 현재 복잡한 비즈니스 환경에서 성공하기 위해 새로운 기준을 구현하고 있는 리더의 주요 특성이다.

## 용기와 위험 관리 능력
과거에는 대담한 기술 아이디어를 구현하려면 상당한 재정적 투자가 필요했다. 오늘날은 생성형 AI 기술 발전으로 이전보다 훨씬 적은 비용으로도 구현이 가능해졌다. 하지만 비용이 감소했음에도 포괄적인 변화 프로그램의 필요성은 여전히 중요하다. 생성형 AI는 단순히 플러그 앤 플레이 솔루션이 아니다. 효과적인 IT 리더십에는 혁신에 대한 용기뿐만 아니라 변화 관리 원칙에 대한 깊은 이해도 필요하다. IT 리더는 기술이 신중하고 효과적으로 통합되도록 전략적 배치에 대한 현명한 조언을 조직에 제공해야 한다. 또한 생성형 AI가 가져오는 새로운 수준의 위험과 규정 준수 문제를 이해하기 위해 법무팀과의 긴밀하게 협력해야 한다.

## 데이터 자산의 수익화 이해
IT 리더는 단순한 기술 전문가가 아니라 데이터에 정통한 ‘데이터 상인’이다. 물리적 상품 대신 가치 있는 데이터, 인사이트, AI/ML 제품을 보유한 상점 주인을 상상해 보라. 이 상점 주인이 성공하려면 고객 니즈를 이해하고, 제품을 최신 상태로 유지하며 고품질로 잘 정리해야 한다. 분석과 컨설팅 같은 부가 가치 서비스를 데이터와 함께 제공하면 더욱 매력적일 수 있다. 이러한 마인드셋과 비즈니스 원칙을 적용함으로써 IT 리더는 새로운 수익원을 창출할 수 있다.

## 데이터 거버넌스와 윤리에 집중
AI가 보편화되면서 윤리적이고 책임감 있는 사용이 중요해졌다. 리더는 잘못된 데이터셋으로 AI 모델이 학습할 때 발생할 수 있는 편향이나 차별의 위험을 완화하기 위해 데이터 거버넌스 정책을 수립해야 한다. AI는 투명성이 핵심이다. 그래야 이해관계자들이 AI가 생성한 인사이트를 이해하고 검증할 수 있다. 기존의 문화, 구조, 거버넌스를 기반으로 프로그램을 구축함으로써 IT 리더는 윤리적 기준을 유지하고 혁신을 촉진하면서 AI의 복잡성을 헤쳐나갈 수 있다.

## 지성과 감성의 균형 유지
AI가 도입된 직장을 관리하려면 IT 리더는 지능 지수(IQ)와 감성 지수(EQ)의 균형을 유지해야 한다. IQ 측면에서는 AI가 중심이 되는 세상에 대한 비전을 갖고 있어야 하며, 직원들이 다른 복잡한 업무에 더 많은 시간을 할애하고 생산성을 높일 수 있도록 AI를 활용할 영역을 파악해야 한다. 더 중요한 것은 EQ다. 긍정적인 영향을 전파하고, 직원들의 참여를 유지하며, 변화하는 인력에 대한 불안감을 해소하고, 새로운 업무 방식과 사고방식에 초점을 맞춘 재교육을 돕기 위해 EQ와 인간 중심 기술이 필수적이다. 실제로 고급 분석으로 인해 이해하기 어려운 수준으로 방대한 양의 데이터가 생성되고 있다. 따라서 깊은 전문 지식이나 순수한 지능보다 부드러운 관리 기술이 더 중요해질 가능성이 높다.

https://www.cio.com/article/3614878/%ea%b8%b0%ea%b3%a0-%eb%b9%a0%eb%a5%b4%ea%b2%8c-%eb%b3%80%ed%99%94%ed%95%98%eb%8a%94-%ec%8b%9c%eb%8c%80%ec%97%90-%eb%8c%80%ec%9d%91%ed%95%98%eb%8a%94-it%eb%a6%ac%eb%8d%94%ec%9d%98-%ed%8a%b9%ec%a7%95.html

https://www.cio.com/article/3613520/%ec%b9%bc%eb%9f%bc-it-%eb%a6%ac%eb%8d%94%ec%9d%98-2025%eb%85%84-%eb%aa%a9%ed%91%9c-it-%ec%9d%b8%ec%8b%9d-%ed%9a%8c%eb%b3%b5%ec%9d%b4-%ec%9a%b0%ec%84%a0%ec%9d%b4%eb%8b%a4.html

디지털 플랫폼의 채용 공고 광고는 비용이 거의 들지 않는다. 동시에 공고를 게시한 회사는 다양한 정보를 얻거나 여타 효과를 거둘 수 있다. 이를 테면 채용 공고만으로도 기업은 잠재적 인재 기반을 구축하거나, 시장 동향을 조사하거나, 성장 중인 기업으로서 관심을 끌 수 있다.

이러한 이유로 ‘유령 일자리’ 현상이 빠르게 증가하고 있다. 유령 일자리는 채용할 의사가 없는 회사에서 게시한 구인 공고를 말한다. 이러한 꼼수는 부정적인 사회적, 경제적 결과를 초래한다. 노동 시장의 효율성에 영향을 미치고, 지원자의 비용을 증가시키며, 연구자와 정책 입안자의 데이터 분석을 복잡하게 만든다.

뉴욕시립대학교의 헌터 응은 최근 ‘왜 지금 일자리를 찾기가 그렇게 어려운가? 유령 일자리(Ghost jobs)를 검색해보라‘라는 연구 논문을 발표했다. 그는 이 현상을 조사하면서 특히 대기업과 정보 기술 등 고도의 기술을 필요로 하는 분야에서 이러한 현상이 점점 더 보편화되고 있다는 사실을 발견했다.

https://www.cio.com/article/3611792/%ec%b1%84%ec%9a%a9-%ea%b3%84%ed%9a%8d-%ec%97%86%eb%8a%94%eb%8d%b0%eb%8f%84-%ec%9d%b8%ec%9e%ac-%eb%aa%a8%ec%8b%ad%eb%8b%88%eb%8b%a4-%c2%b7-%c2%b7-%c2%b7-%ec%9c%a0%eb%a0%b9.html

https://zarar.dev/good-software-development-habits/

• 
  이 글은 조언이 아닌, 저자가 현재 적용하고 있는 개발 습관들에 대해 작성한 내용
• 나쁜 습관을 피하고 좋은 습관을 만들기 위해 노력한 경험을 정리한 글로, 생산성 향상과 품질 유지에 도움이 되었던 10가지 습관을 다룸

1. 작은 커밋 유지

• 커밋을 최대한 작게 유지해야 함. 작은 커밋은 버그 발생 시 특정 커밋만 되돌릴 수 있게 하여, 복잡한 병합 충돌을 피할 수 있음
• "소프트웨어가 컴파일될 때 커밋할 수 있어야 한다"는 것을 규칙으로 삼음

2. 지속적인 리팩토링

• Kent Beck의 조언: "변화를 원할 때, 먼저 변화를 쉽게 만들고, 그런 다음 쉽게 변화를 만드세요."
• 최소 절반의 커밋은 리팩토링이 포함되도록 함. 작은 리팩토링이 큰 요구사항이 들어올 때 큰 도움이 됨
• 큰 리팩토링은 피해야 함. 대신 10분 이내의 작은 개선 작업을 지속적으로 수행

3. 코드 배포의 중요성

• 코드 자체는 잠재적 부채이며, 배포되지 않은 코드는 가장 큰 부채임
• 테스트는 신뢰감을 주지만, 실제 배포는 진정한 승인을 의미함
• 배포 빈도가 높아질수록 호스팅 비용이 증가할 수 있지만, 최신 작업이 실제로 작동함을 확인하는 것은 중요한 이점임

4. 프레임워크의 기능 테스트하지 않기

• 프레임워크의 기능을 테스트하지 않음. 프레임워크는 이미 충분히 검증되어 있음
• 컴포넌트를 작게 유지하면 프레임워크가 대부분의 작업을 처리하게 되어 테스트가 줄어듦
• 큰 컴포넌트는 복잡성을 추가하고, 이에 따라 많은 테스트가 필요해짐

5. 새로운 모듈 생성

• 특정 기능이 기존 모듈에 맞지 않는다면, 새 모듈을 생성하는 것이 좋음
• 기존 모듈에 억지로 기능을 추가하는 것보다 독립적인 모듈로 남겨두는 것이 나음

6. 테스트 주도 개발(TDD)의 유연한 적용

• API 설계가 명확하지 않을 경우 테스트를 먼저 작성하여 "고객"의 입장에서 생각함
• TDD는 종교적인 원칙으로 따르지 않음. 필요한 경우 더 큰 단위로 작업 후 테스트할 수 있음
• 작은 단위의 코드를 실패 상태로 만들지 않아도 되며, 생산성을 저해하는 교조주의에 얽매이지 않음

7. 복붙은 한 번만 허용

• 한 번의 복사는 괜찮지만, 두 번째 복사부터는 중복이 생김
• 이 시점에서 적절한 추상화를 통해 중복을 제거해야 함. 파라미터화가 약간 이상해 보여도, 여러 구현을 합치는 것보다는 나음

8. 디자인의 변화 수용

• 디자인은 시간이 지나면서 낡아짐. 리팩토링을 통해 노화를 늦출 수 있지만 결국에는 바뀔 수밖에 없음
• 이전의 디자인을 너무 집착하지 말고, 변화를 받아들여야 함
• 완벽한 디자인은 없으며, 변화에 잘 대처하는 능력이 소프트웨어 개발의 핵심임

9. 기술 부채의 세 가지 유형

• 기술 부채는 세 가지 유형으로 분류할 수 있음:
  1. 현재 작업을 방해하는 것
  2. 미래 작업을 방해할 가능성이 있는 것
  3. 방해할 가능성이 있을지도 모르는 것
• 첫 번째 유형의 부채는 최소화하고, 두 번째 유형에 집중하며, 세 번째 유형은 무시해야 함

10. 테스트 가능성과 좋은 설계의 관계

• 테스트하기 어렵다면 설계에 문제가 있을 가능성이 높음
• 테스트 설계 또한 개선의 대상이 될 수 있음. 예를 들어, em.getRepository(User).findOneOrFail({id})의 목(Mock) 작성을 어렵게 느낀다면, 별도의 함수로 분리하거나 테스트 유틸리티를 사용하는 것이 좋음
• 테스트가 작성되지 않는 이유는 테스트하기 어렵기 때문이며, 이는 설계의 문제일 수 있음