한국 대기업에서의 라이브옵스(LiveOps)

오토에버에서도 라이브옵스(LiveOps)를 시작할려고 한다. 조직은 이미 봄에 만들었고, 뭘 하기도 전이긴 하지만 이야기 할 사람들과 역할을 가지고 이야기를 해야하기 때문에 작지만 팀을 만들었다. 팀 리드를 세우고 여러 관계자들과 이야기를 하면서 역할의 타당성과 기대 역할에 대한 의견을 모았다. 있어야 할 조직이라는 생각이 들었고, 제대로 일 할 제대로 된 팀을 만들기 위해서 본격적으로 채용을 시작한다.

왜 LiveOps인가?

한국 대기업에서 IT 서비스는 대부분 SI(개발)와 SM(운영)으로 이뤄진다. 직접 경험해보니 대기업이 움직이기 위해 아주 많은게 필요하다. 어느 회사든 마찬가지지만 기업의 필요를 딱 맞추는 상용 제품은 없다. 그러니 자체적으로 만들어야 한다는 빌미를 제공하지만, 적당히 상용 제품을 플러그인 방식의 커스텀 모듈을 만들어 통합해 쓰면 되는 경우도 있다. 이렇든 저렇든 대기업이 돌아가기 위해 필요한 IT 서비스들이 있어야 한다. 모든 대기업도 여느 인터넷, IT 기업과 마찬가지로 대고객 서비스를 제공해야 살아남을 수 있다는 것을 알고 있고, 현대차 그룹 역시 마찬가지다. 현대차 역시 차량 중심의 다양한 서비스들을 7×24로 제공하고 확장하고 있다.

현대오토에버가 제공하는 현대차 그룹의 개발과 운영은 어떠한가? 남들이랑 다를바 없다. 냉정하게 평가하면 타 기업에 비해 수준이 좀… 파트너사(외주사)에 의존해 대부분 개발이 진행되다보니 모든 기업이 고생한다는 기술 부채가 남다르다. 요즘은 외주 개발보다는 내부 인력을 직접 개발하는 비중을 늘려가고 있지만, 누가 개발하던 결국 운영은 모두 오토에버가 감당한다.

현대오토에버의 모든 결과물은 서비스다. 일반적으로 생각하는 서비스와 다름이 있다. 서비스의 처음은 프로젝트를 통해 외주사(혹은 내부 조직)를 통해 만들어지고, 성공적(?)으로 만들어진 결과물이 이제 운영 조직으로 넘어온다. 개발과 운영이 자연스럽게~ 이어져야 하는데, 대부분 예상처럼 안된다. 운영이 잘 될려면, 첫 단추인 개발이 어떻게 된건지를 알아야 한다. 그리고 변경이 발생할 때마다 서비스의 영향이 어느 수준인지 서비스 담당이 예측하고 가늠할 수 있어야 한다. 변화가 직접적이든 간접적이든. 서비스 운영의 핵심은 첫번째 변경부터 EOS까지 변경을 체계적으로 관리할 수 있느냐이다. 오토에버가 운영하는 서비스는 정의 방식에 따라 수백개 혹은 수천개가 된다. 한 해 그룹사 요청으로 진행하는 프로젝트는 수백개 이상이다.

현대오토에버의 라이브옵스 조직은 규모를 감당하기 위한 일하는 체계를 먼저 만들어야 한다. 단순히 라이브옵스 조직만으로 이 규모를 운영하는 것은 일하고 싶은 사람들을 줄세울 수 밖에 없다. 당연히 각 사업부 혹은 센터 단위에서 대행과 위임이 병행 적용되도록 실행을 마찬가지로 체계화한다. 그리고 자연스럽게 아주 자연스럽게 “우리는 이렇게 일해!” 라는 말이 구성원 스스로부터 나올 떄까지 포기하지 않는 것이다.

변경을 잘 관리하면 장애는 없어질까? 설마 그런걸 기대하는 사람은 없겠지. 되려 더 많은 장애를 기대해야 한다. 사람에 의한 모니터링 수준이 SMS, APM에 의해 이뤄지면 더 많은 장애가 발생할 건 불을 보듯 뻔하다. 체계를 적용하는 초반 단계의 양적 증가를 권장하고 권고해야 한다. 그리고 새롭게 확인된 이벤트의 의미를 추정하기 위한 데이터 중심의 사고를 해야 한다. AI가 놀면 안되니 숫자에 압도되 이전에 못하던 분석을 AI를 써서 우리가 해결해야 할 진짜 문제를 찾아야 한다. 단순한 이벤트의 집합이 아닌 상관 관계 파악을 통해 RC에 접근하기 위한 일반적인 방법과 고도화를 위한 시도를 권장해야 한다.

라이브옵스 조직과 체계를 통해 가장 크게 기대하는 바는 장애를 통해 조직이 배우고 성장하는 것이다. 장애 때문에 징계먹고 쫑크먹을까봐 변화/변경을 두려워하며 “우리는 이렇게 일해!” 라는 되도 안는 자위를 하며 당당해하는 어처구니 없는 상황을 종종 마주친다. 다음 번 서비스 배포시에 이런 부분을 주의하고 자동화하는 것이 “장애 부검”을 통해 확인됐다면, 다음 번 변경시에 이를 확인하고 팀이 한단계 성장했다는 것을 확인해주는 것. 변경을 관리하고 장애 상황과 리뷰를 리딩하는 라이브옵스 조직에 대한 기대치다.

글로벌 서비스의 연속성과 안정성

현대오토에버의 대고객 서비스 다수는 한국에서 개발됐지만 글로벌 고객에게 서비스되고 있다. 현대 및 기아차가 전세계에 판매되고 주행한다는 것은 단순한 한국 서비스를 운영한다는 마인드가 아닌 글로벌 서비스 운영 감각을 갖춰야 한다. 서비스가 잘 운영되기 위한 체계를 달성해야 하지만, 서비스를 대하는 사람의 태도가 먼저 글로벌이 되야 한다. 시스템의 일관성을 달성하기 위해 사람의 일관성이 필요한 이유다. 7x24x365는 쉬운 단어가 아니다. 더구나 단일 국가가 아닌 글로벌 주요 권역을 커버해야 한다면 일을 대하는 우리의 자세 먼저 다듬어야 한다.

글로벌 서비스의 연속성과 안정성을 보장하기 위해 명심해야 할 사항은 복잡도다. 복잡도의 증가는 필수적이다. 서비스에 참여하는 주체들이 많아지고 다양해진다면 업무의 복잡도 뿐만 아니라 서비스를 구성하는 시스템의 체계도 단연한 수순으로 복잡해질 수 밖에 없다. 모노리딕에서 벗어나 MSA를 당연한 것이 되고, 그걸 넘어 EDA 체계를 서비스 제공에 도입해야 할 때도 있다. 스케일에 따른 일관성이 관리를 위해 반드시 있어야 한다는 것을 누구나 머리속에서 알 수 있다. 단 이를 행동으로 옮겨 관리하는 것은 누구나 쉽게 하지 못한다. 너무나 어려운 일이라는 걸 마찬가지로 알고 있기 때문에.

라이브옵스를 통해 도달시키고 싶은 것은 “일관성있는 관리 체계 완성”은 아니다. 물론 되면 행복하겠지만, 사람이라는 불확정 요소에 움직이는 세상에서 일관성이 반영된 관리 체계는 심각한 관료주의를 불러들일 수 있다. 이상론이기 보다는 현실론이길 원한다. 복잡성 혹은 복잡도를 라이브옵스 조직이 인지하고 인식하길 원한다. SLA/SLO 기반의 품질 중심의 운영을 위한 시스템간 서비스간 상호 연관 관계를 당사자들이 이야기할 수 있도록 하고, 지식화하기 위한 방안을 주도했으면 한다. 논의와 지식의 데이터화를 통해 짧은 호흡의 신뢰 기반 소통과 서비스 조직이 주도하는 지식의 축적을 리딩했으면 한다.

짧은 기대!

일단 기대만 하는 라이브옵스 조직과 체계가 활성화된다면 담당자가 아니어도 롤백(Rollback)이 이뤄졌으면 한다. 사실 아무리 고도화됐다고 하더라도 대부분 서비스 장애의 대응은 되돌리기다. 멀쩡하게 잘 돌아가는 서비스가 이상 동작을 하는 건 변화가 있었다는 것을 의미하는 것이고, 원래 상태로 되돌리기는 사실 당연한 조치다. 하지만 이 당연한 조치 조차도 담당팀이 아니면, 담당자가 아니면 못하는 것 또한 현실이다. 우선 신뢰와 지식 기반으로 담당자가 아닌 라이브옵스 팀에서 롤백을 실행하길 기대해본다. 물론 나중에는 판단 기준을 갖고 AI가 실행할거라고 생각하지만.

덧) 확실히 채용 지원자가 드물거라고 생각했지만, 생각보다 어렵다. 관심있는 분들의 많은 채용 지원 부탁…

현대오토에버 라이브옵스(LiveOps) 체용 공고

엔지니어가 AI 코딩을 해야 하는 이유

거의 5년만에 코딩을 해봤다. 물론 서비스 시스템을 위한 코드 작성이 아니다. 이 시간 동안 코드에 손대지 않았다면 개발자라고 이야기하는 것도 무색하다. 사실 보기에 갑갑하다고 나서서 코드 작업했다가 문제를 일으키기도 했다. 라이브는 살아있는 것이기 때문에 현직 개발자가 하는게 맞지. 특히나 IntelliJ를 써서 코드를 작성해본 건 꽤 오래된 것 같다. 마지막 코드 작업은 VS Code 가지고 React로 FE App을 개발했었으니 말이다.

라이엇게임즈 마지막 개발 FE App

대학교 특강을 땜빵해달라는 요청이 있었고, 주제가 TDD(Test Driven Development)였다. 현대오토에버 합류 이후 코드 짤 시간도 생각도 없었다. 다른 이유로 오토에버의 개발 환경 개선 작업을 주도하고 있기 때문에 환경이 구축된 이후에 뭘 하더라도 할려고 했다. 덕분에 맥에 아껴두고 깔지 않았던 IntelliJ도 설치했다. 그리고 감동했다. 감동의 이유에 대해서는 조만간 다른 글을 통해 이야기하겠지만… 아는 사람들은 감동할 것이다.

특강을 대신 부탁하신 분이 IDE(IntelliJ)의 Refactoring 기능 활용 방법을 꼭! 잘 전달해달라는 요청이 있었다. 특히 강의를 마우스로 메뉴따라 하면 학생들이 혼돈의 도가니기가 되기 때문에 꼭 단축키를 이용하라는 조언도 해주셨다. 사실 이게 말이 되는게 강의장에서 학생들에게 “어떤 메뉴 > 어디 세부 메뉴 > …” 이렇게 언급을 하면 왜 다시 질문하는 학생들이 그렇게 많은지. 그리고 엉뚱한 질문에 답하고 나면 정말 시간이 빨리 간다. 역시 정답은 단축키! 도움말에 나오는 단축키 목록을 가만히 보고 있자니 대강 생각나는 것 같다. 몸이 기억한다는게 이런 느낌일까?

TDD를 적용할 예시로 계산기를 염두에 두고 있어서, 메이븐 프로젝트부터 셋업해서 차근차근 마음대로 코드를 작성했다.껍데기 코드도 대강 만들고, 깨지는 테스트 케이스도 만들었다. IDE 화면을 왔다갔다하면서 코드를 작성하자니, 예전이라고 하기에도 더 먼 옛날에 코드짜던 추억도 떠오르고… 감회라는게 이럴 때 쓰는 단어라는 생각이 났다.

TDD 특강 이야기를 듣자마자 생각이 들었던 건 이제 단축키가 아니라 AI 코딩이었다. 이제는 단축키로 코드를 효과적으로 짜는게 실력이 아니라 AI Assist 기능을 제대로 활용하는 것이 엔지니어의 능력이라고 생각했고, 학생들에게도 변화된 세상에 맞춰 준비를 해야한다는 이야기를 하고 싶었다. 그리고 쏘카때부터 코파일럿을 사람들에게 쓰라고 했고 50% 이상 생산성 향상이라는 답을 들었다. 그리고 최소 50% 향상이라는 이야기를 깃헙 CTO로부터 듣기도 했다. 듣기만 했지 코드로 직접 해보질 않았기 때문에 이번 기회에 스스로도 써보고 정말 그 정도인지를 확인하고 싶었다.

먼저 테스트 코드를 Parameterized Test를 활용해 Refactoring 해달라고 했다.

Before

@Test
void shouldRunToCalculate() throws UnsupportedCalculationException {
  assertThat(calculator.run(1, Calculator.OPERATOR.PLUS, 1)).isEqualTo(2);
}

@Test
void shouldCalculateMorePlusCases() throws UnsupportedCalculationException {
  assertThat(calculator.run(1, Calculator.OPERATOR.PLUS, 2)).isEqualTo(3);
}

After

@ParameterizedTest
@CsvSource({
"1, PLUS, 1, 2",
"1, PLUS, 2, 3"
})
void shouldCalculateCorrectly(int left, Calculator.OPERATOR operator, int right, int expected) throws UnsupportedCalculationException {
  assertThat(calculator.run(left, operator, right)).isEqualTo(expected);
}

구체적인 지침을 줬기 때문에 기대했던 만큼 결과가 나온다. 우선 테스트 선수라는 이야기는 맞는 것 같다. 빠른 작업을 위해 단축키를 쓸 필요가 없다. 그냥 영역을 선택해서 코파일럿으로 적절한 Directive를 주는 것만으로 결과를 얻었다. 동일한 코드를 4o-mini를 통해 실행했을 때 JUnit4 기준으로 결과를 생성했지만, JUnit5로 테스트 결과를 생성하라고 추가 Directive를 줬더니 유사한 코드를 생성했다.

테스트 코드에 대해서는 기대만큼의 결과를 얻을 수 있다는 것을 확인했으니, 메인 코드 Refactoring을 진행했다. 간단 코드로 사전에 작성한 코드는 아래와 같다.

public int run(int leftValue, OPERATOR operator, int rightValue) throws UnsupportedCalculationException {
  if (operator == OPERATOR.MINUS) {
    return leftValue - rightValue;
  } else if (operator == OPERATOR.PLUS) {
    return leftValue + rightValue;
  } else {
    throw new UnsupportedCalculationException();
  }
}

위 코드에서 Refactoring의 방향에 대해 별다른 지침을 주지 않았지만, “가독성, 확장성, 중복 제거” 관점의 결과라는 이야기와 함께 결과를 만들었다. 그리고 이 결과를 다음의 방안에 착안해서 진행했다고 코멘트를 남겼다.

  • if-else → switch 구문으로 가독성 개선
  • 향후 연산자가 추가될 수 있도록 enum 내에 BiFunction을 활용한 전략 패턴 도입
  • UnsupportedCalculationException을 연산자 자체가 책임지도록 설계
public int run(int leftValue, OPERATOR operator, int rightValue) throws UnsupportedCalculationException {
  if (operator == null) {
    throw new UnsupportedCalculationException("Operator cannot be null");
  }
  return operator.apply(leftValue, rightValue);
}

public enum OPERATOR {
  PLUS((a, b) -> a + b),
  MINUS((a, b) -> a - b);
  // 향후 MULTIPLY 추가 시: MULTIPLY((a, b) -> a * b)

  private final BiFunction <Integer, Integer, Integer> operation;
  OPERATOR(BiFunctioninteger<Integer, Integer, Integer> operation) {
    this.operation = operation;
  }

  public int apply(int a, int b) throws UnsupportedCalculationException {
    if (operation == null) {
      throw new UnsupportedCalculationException("Unsupported operation for operator: " + this.name());
    }
    return operation.apply(a, b);
  }
}

내가 선호하는 스타일 방식으로 거의 완벽하게 Refactoring 결과를 만들었다. 앞서 리팩터링한 테스트를 통해 결과가 수행되는지 확인했다. 완벽하게 동작한다. 여기에 더해 곱하기 부분은 나중에 구현할 것이고, 이를 메인에서 Exception 처리하는 것이 만족스럽지 않기 때문에 이 부분만 코드로 전환할 필요가 있었다. 다음의 Prompt를 추가해줬다.

BiFunction대신 Operation을 써서 추상화해줘.
MULTIPLY를 추가해주고 Not implemented 라는 메시지로 Exception을 발생시키도록 해줘.

그리고 최종적으로 다음의 코드로 Refactoring을 마무리했다.

public enum OPERATOR {
  PLUS((leftValue, rightValue) -> leftValue + rightValue),
  MINUS((leftValue, rightValue) -> leftValue - rightValue),
  MULTIPLY((leftValue, rightValue) -> {
    throw new UnsupportedCalculationException("Not implemented");
  });

  private final Operation operation;
  OPERATOR(Operation operation) {
    this.operation = operation;
  }

  public int apply(int leftValue, int rightValue) throws UnsupportedCalculationException {
    return operation.apply(leftValue, rightValue);
  }
}

@FunctionalInterface
public interface Operation {
  int apply(int leftValue, int rightValue) throws UnsupportedCalculationException;
}

여기까지 과정에서 IntelliJ에서 사용한 단축키는 Cmd + R 혹은 실행 범위를 변경하기 위해 Shift + Cmd + R 단축키만 사용했다. 단축키 빌런은 앞으로 세상에 필요없을 것 같다.

느낌 정리

정말 세상은 너무 빠르게 변하고 있는 것 같다. 특히 개발 분야에서 더욱 그렇다. 쏘카에서 코파일럿을 도입시킨 3년 전에 다른 리더들과 당시의 개발자가 얼마쯤이면 필요없어질 것인가를 가지고 이야기를 나눈 적이 있었다. 나의 예측은 앞으로 5년 후면 신입 개발자에게 요구하는 코딩 수준은 AI가 어느 정도 대체할 것이었다. 이번 결과를 돌려보면서 느낀 점은 나의 예상이 틀렸다는 것이다. 시니어와 페어를 이룬 신입 개발자를 가정한다면 이미 AI는 일반적인 Java 코드 수준에서는 신입 개발자를 앞서고 있다. 적절한 Directive를 줄 수 있는 시니어 개발자라면 코파일럿 혹은 Gen AI 기반의 Assist 기능을 활용해 4~5년차 수준의 개발자를 한 명과 함께 일하는 것과 비슷한 Performance를 얻을 수 있다.

내 경험이 틀린 것인지 한번 더 검증하기 위해 간단한 RESTful endpoint를 가지는 Springboot 기반 어플리케이션을 만들어봤다. 예상 목표 시간은 30분이었는데, 거의 30분만에 Working Code를 완성할 수 있었다. 테스트 코드까지를 포함해 실제 전체 형상을 완성하는데는 1시간 이내가 걸렸다. 아마도 AI Assist의 도움을 받지 않고, 예전 방식대로 자료 찾고, Javadoc 뒤지고, Stackoverflow에서 edge 케이스를 함께 확인하는 시간을 썼더라면 최소 3시간에서 하루 정도는 썼을 것 같은데, 한 시간안에 Local 환경에서 동작하는 WebApp을 만들 수 있다는게 놀랍기만 했다.

시대는 진화하고 있다. 개발자의 역할 역시 바뀌는 시대에 맞춰 재정의가 이뤄져야 한다. AI와 경쟁하는 것이 아닌 AI를 도구로써 효과적으로 다루며 개발이라는 업에서 자신의 가능성을 입증할 수 있는 사람이 되어야 한다.

컨트롤보다 얼라인먼트

팀을 리딩하는 건 언제나 어렵다. 특히 본인에게 직접 보고(Direct Reports)하는 사람이 늘어나는 팀 확장 시기에 어려움이 기하급수적으로 커진다. 늘어난 사람 고민도 있지만, 일의 크기가 커졌기 때문이다. 모든 리더들의 고민 시점이다. 리더 생활을 이제 시작했느냐 오래 했느냐의 차이가 없다. 그냥 어렵다.

어려움은 환경에서 나오고 사람에서 나온다. 늘어난 일이 어제와 다르고, 혹은 내일 분명 달라질 것이다. 사람은 언제나 알았던 것과 다르게 행동한다. 믿을 수 있다고 생각했지만 기어코 못 믿을 짓을 벌인다. 사람들과 함께 일을 해내야 하는 내 몸뚱아리는 하나고, 하던대로 하다보면 지치고 내가 먼저 나가 떨어질 것 같다.

하나부터 열까지를 챙겨볼 수 있다. 컨트롤이다. 혹은 마이크로(Micro-management)라고 한다. 몸이 감당 가능하다면 이것도 방법이다. 환경에 대응할 수 있고, 사람을 제어할 수 있다는 의미다. 하지만 앞서 이야기했지만 내 몸이 하나기 때문에 한계가 있다. 더 하다가는 병난다. 몸이 병나면 쉬고 돌아와 더 할 수 있지만 마음이 병나면 약도 없다. 특히 사람에게서 받은 상처는 더 깊고 아프다. 물론 받기만 할 수 없으니 주기도 한다. 서로 서로 마음이 병난다.

해 본 사람은 병난다는 것을 안다. 그리고 마이크로를 할 수 있다 치더라도 규모의 한계, 기간의 한계를 안다. 이럴 때 조직 피라미드를 생각한다. 내가 관리할 수 있는 한계를 나에게 직접 보고하는 사람 숫자로 제한한다. 그리고 님들 책임이라고 힘 주어 강조한다. 그리고 나에게 보고하는 사람 너머에 있는 사람을 애써 무시한다. 그저 보고하는 사람들을 닥달한다. 뭔가 맘에 안드는 이야기를 들었다면 더욱 닥달한다. 관리 똑바로 하라고. 관리가 위계를 만들고, 명백한 층을 만든다. 그리고 가까이 하기엔 너무 먼 당신이 되어 버린다.

규모의 조직을 잘 관리하는 방법으로 사람들이 이야기하는 것이 위임(Empowerment, Not Delegation)이다. 위임은 “믿고 의지한다.”는 표현이다. 같은 방향, 목표를 보고 있다고 믿는다. 리더인 내가 보는 방향과 나에게 보고하는 사람이 같은 방향을 보고 있다. 각자가 목표로 나가기 위해 필요한 결과를 결정하고 달성하기 위해 노력(실행)하는 것에 리더인 내가 의지한다.

리더인 나의 몫은 방향(혹은 목표)를 잡고, 나와 함께 하는 사람들이 같은 방향을 바라보는지 확인하는 것이다. 같은 방향을 바라본다면 개인의 결과는 관리가 아닌 지원 대상이고, 리더에게 개인은 보고하는게 아니라 공유하면 된다.

같은 방향과 목표를 보고 있다 하더라도 누구나 감당 가능한 일의 크기가 다르다. 같은 산을 바라보고 있다고 하더라도 산에 오르는 방법은 여러 가지다. 무작정 올라가면 되는거 아니냐는 이야기를 곧이 곧대로 “하라고” 내버려두는 건 일종의 방임이자 직무 유기다. 개인이 감당할 규모(혹은 역량)와 결과가 조직 전체에 미치는 영향을 파악하고, 적정선을 맞춰야 한다. 그리고 실패와 실패 영향을 고려해야 한다. 도전적인 과제를 다들 기피하는 이유는 실패 때문이다. 실패를 좋아할 사람없고, 본인 커리어에 좋은 한 줄이 기록되길 원하지 실패 이력은 전통적인 한국 상황에서 해명꺼리가 될 수 밖에 없기 때문이다. 리더 관점에서 위임의 크기를 비유적으로 찾아내는 비유 방법으로 “나무 모델“을 대입해보면 좋다.

나무 모델은 “Dare to Lead“에서 언급된 위임하기 위한 방법이다. 책을 읽어보면 알겠지만 위임의 수준에는 각 위임을 통해 예상해 볼 위험의 크기가 있다는 것이다.

Empowerment Levels

  • 나뭇잎 수준 – 그냥 해보면 된다. 실패하더라도 조직에 영향을 미치지 않기 때문에 개인의 도전 의사가 먼저다. 물론 조직에는 나뭇잎 수준의 영향이겠지만 개인은 다른게 느낄 수 있다는 걸 기억하자.
  • 가지 수준 – 리더의 자율 책임 범위에서 해볼 수 있다. 혹은 리더에게 공유하고 할 수 있는 수준이다. 가지가 잘리더라도 나무에 큰 영향을 미치지 않는다. 큰 줄기라면 영향을 줄 수 있지만 나무의 다른 줄기가 손실을 만회해 줄 수 있기 때문이다.
  • 줄기 수준 – 조직의 미래 성장에 영향을 미친다. 이 수준의 영향이 발생되면 다음 단계의 큰 성장 혹은 도약은 유보되고, 장기간의 재정비를 필요로 한다. 개인이나 리더의 판단보다는 리더십의 판단이 필요하다. 과감한 결단과 도전이 필요하다.
  • 뿌리 수준 – 뿌리가 영향을 받으면 나무가 죽는다. 죽을 수 있다가 아니라 대부분 죽는다. 할 수 있더라도 절대로 개인 판단에 의해 결정하면 안된다. 리더 단독이 아닌 리더십 수준에서 협의와 합의 후 실행되야 한다. 할 수 있기 때문에 했다가 사단이 발생하면 회사를 망하게 만든다. 망했을 때 후 폭퐁은 개인이 감당할 수준을 넘어선다.

반드시 필요한 건 위험의 크기를 알아야 한다는 것이다. 특히 위임이 방임 혹은 방치가 되지 않을려면 리더의 역할이 중요하다. 가장 먼저는 위임받을 사람이 받을 깜(역량)이 되는지를 알아야 한다. 그리고 위임을 통해 주도적으로 혹은 알아서 결정하더라도 미칠 수 있는 영향력의 범위가 어느 수준인지를 가늠해야 한다. 가늠을 통해 간섭이 아닌 주도적으로 결과를 만들어낼 수 있는 기회를 담당자에게 부여할 수 있다. 누구의 일이냐면 리더의 몫이다.

뭘 도와주면 될까? 현재 사장님이 미팅시에 항상 하시는 말씀이다. 어떻게 보면 당연한 말인데, 매우 색다르다. 살아오면서 많이 들어보지 못한 말이니 어색할 수 밖에 없지 않을까? “자주 공유 드리겠다.” 라고 이야기했다. 무엇보다 필요한 것은 공유를 통해 사장님의 방향을 따라 내가 보고 있는지, 내가 만드는 결과가 같은 시선을 따라 이어지는지를 확인해야 한다.

퇴사하는 분에게 보내는 글

스스로 선택지를 찾아 새로운 여정을 떠나시겠다는 분이 있다.

나를 잘 못 만나 혹은 잦은 조직 개편의 여파에 쓸려 제대로 중심을 가눌 수 없는데서 오는 심리적 스트레스가 가장 큰 요인 아닐까 싶다. 최종적으로는 개인의 선택이지만 선택지에 이르는 과정에서 조직이 일을 하기 위한 안정감(Stability, not Safety)을 낮춘 부분은 분명하다. 내가 제시한 팀이 결과를 만드는 부분에 적극 호응해 결과를 만들긴 했지만, 사이에 스스로 타들어가는 걸 막지 못한 건 맞다. 떠나는 결정에 대한 책임은 나에게도 분명 있다.

떠나시는 분께 다음과 같이 메시지를 드렸다.

그동안 몸고생 뿐만 아니라 맘고생으로도 고생 많았어요.

어디서든 이만한 고생이 또 있겠냐 싶지만 리더 혹은 리더십의 역할을 한다는 건 스트레스를 안고 사는 일입니다.

본인이 본인 삶의 여정을 개척하는 과정이라는 것, 남이 나를 위해서 맞춰주지 않는다는 것만 명심해주면 좋겠습니다.

이번 경험이 좋든 나쁘던 다음 여정에 도움이 됐으면 하고, 길지 않은 기간이었지만 정말 수고 많았습니다.

건강하게 성취를 만들어서 크게 성공하는 모습 볼 수 있었으면 합니다.

더욱 더 팍팍해지는 일상이 되가는 건 사실이다.  Gen AI가 나오면서 “혼자 할 수 있겠지…” 라는 착시를 만들고 있지만, 큰 꿈을 실현하기 위해서는 조직이 필요하고 구성원 역할이든 리더 역할이든 이루고 싶다면 조직이라는 틀 안에서 해야 한다.  창업이라는 맞춤 옷을 만들지라도 조직이 형성되면 내 맘대로 되지 않은 일이 백가지 천가지다. 엔트로피는 증가될 수 밖에 없고, 결국 엔트로피를 감당할 수 있는냐 없느냐로 귀결된다.

그래서 사람이 문제라고? 사람의 문제가 아니라 조직 시스템의 문제다. 조직 시스템이 증가하는 엔트로피를 담아내고 관리할 수 있는 상호 작용 능력을 갖추고 있어야 한다. 엔트로피는 결코 낮아지지 않는다. 그리고 시스템이 엔트로피를 담아내지 못하면, Bang! 폭팔한다.

코드에서 사람으로 시스템을 만드는 방식을 변경하면서 항상 고민하는 문제다. 그리고 이 문제에 대한 정답은 오직 신만이 알고 있다. 사람이 정답을 알 수 없지만, 올바름이란 무엇인지는 계속 질문하는게 내가 해야 할 일이 아닐까 싶다.

HMG Global IT Forum 2025

현대오토에버에 합류한 직후부터 해외법인의 기술 현안과 현황 그리고 문제점을 파악하기 위해 다녔었다. 여러 문제점들이 보였지만, 그럼에도 가장 크게 피부에 와닿는 문제는 본사와 해외 법인간의 단절이었다. 정보가 있었지만 정보가 원할히 흐르기 위한 소통과 공감이라는 부분이 부족했다. 물론 이 부분은 고객이라는 높이 차이, 위치 차이가 한 몫을 하긴 했지만 현대차 그룹이라는 한 배를 타고 있는 구성원으로 결과를 만들기에 커다란 벽이었다.

일을 하기 위해 필요한 본사와 혹은 고객사 본사 담당자들과 어떤 이야기들이 있었는지 질문했다. 안타깝지만 업무에 따라 이뤄지는 온라인 미팅 이외에 사람을 알기 위한 자리가 없었다. 사람을 모르는데 어떻게 일이 돌아갈까… 이해하고 왜 이런 질문 혹은 요청을 하는지를 공감할 수 있는 시간이 없었다. 이야기해본 해외 법인 담당자들 모두 만나 이야기하는 자리의 필요를 이야기 했다. 그럼 만들어야지!

출장에서 복귀한 이후로 현대차 그룹에서 진행되는 오프라인 행사들을 찾아봤다. 오토에버 구성원들이 적극적으로 참여할 수 있는 행사도 필요했지만, 기존 행사 가운데 함께 참여했을 때 시너지를 만들 수 있는 행사가 있다면 그것도 좋다고 판단했다. 이런 목적에 부합하는 행사가 “HMG Global IT Forum” 이었다. 행사 목적과 이전 내용을 확인해보니 서로 연결되고, 현재 각자가 가진 업무의 내용을 공유할 수 있는 좋은 자리가 될 것 같았다. 오케이! 함께 해보자.

완성차(현대차+기아차) ICT 본부와 현대오토에버가 공동 주체하기로 결정 후 두달 이상의 시간을 들여 프로그램의 세부 내용과 해외 법인과의 소통 과정을 거쳤다. 준비가 생각만큼 쉽지는 않았고, 행사를 가성비있게 진행하다보니 어려움이 가중되었다. 그럼에도 불구하고 양사가 서로 좋은 행사를 만들자는 취지에서 협조하고 역할을 나눠 연결되고 공감할 수 있는 행사로 프로그램과 Staff 로써 각자 역할을 정했다. 그리고 행사 시작.

4박 5일의 행사라는 긴 행사를 시작했고, 장거리 여행을 무릅쓰고 많은 해외 법인에서 참여해서 서로 많은 이야기를 나눴다. 키노트 연사로 개발이 어떤 방식으로 이뤄져야 할지, 그리고 SDLC(Software Development LifeCycle) 관점에서 현대오토에버가 추구하는 개발과 운영의 추진 방향에 대해서도 많은 분들 앞에서 이야기할 수 있었다.

많은 분들과 문제를 해결하기 위해 어느 부분이 부족한지, 부족함을 메우기 위해 우리가 고민할 사항은 어떤 것들이었는지 나눌 수 있는 소중한 시간이었다.

다 수고해주신 Staff 덕분이다. 특히 엉뚱한 센터장을 만나서 행사를 기획하고, 진행하는데 고생한 개발혁신팀 구성원분들이 큰 수고를 해줬다. 고맙고 감사할 따름이다.

이번 경험을 바탕으로 다음 연결을 준비할 예정이다. 일이 되게 할려면 가장 바탕은 사람이고, 혼자가 아닌 팀으로 일을 하기 위해 필요한 것은 이번 Global IT Forum 주제에서 강조한 소통과 공감이다. 한번에서 그치는 것이 아니라 지속되어 언제든 한 팀으로 움직일 수 있어야 한다고 생각한다.

지난 수고스러움을 뒤로 하고, 앞으로의 성취와 결과를 위해 체계적인 다음 수고스러움을 찾아 떠난다.

혁신이 아니라 정상화

올해(2025년) 1월부터 통합혁신센터(Center of Innovation)이라는 신설 조직을 꾸려 현대오토에버의 기술이 고객과 현장의 구성원에게 효과적으로 닿게 할 것인가를 고민하고, 실행하고 있습니다. 기술은 쓰임의 문제이고, 잘 쓰이도록 만드는 것이 IT 혹은 SW 개발 영역의 변하지 않는 화두입니다. 수십년 업계의 고민이 있었지만, 모두를 만족하는 정답은 없습니다. 고민에 대한 제 답안은 “쓰는 사람과 쓰는 사람을 이해하고 만드는 사람들”이라고 생각합니다. 그리고 업계를 리딩하는 많은 IT 기업들이 이 방식을 이미 실행하고 있습니다.

현대오토에버가 혁신센터를 통해 달성하고자 하는 것은 IT 체계와 SW개발의 정상화입니다. 현대차그룹의 70여개가 넘는 계열사와 고객들의 필요를 Digitalization을 통해 가치로 전달하는 것이 현대오토에버의 책임입니다. 이를 위해 가치 중심의 사고와 유연하고 지속 가능한 체계를 구성해야 합니다.

전통적인 그룹 IT 혹은 제조 IT 틀에서 벗어나야 하기 때문에 혁신이 필요합니다. 디지털 기반의 가치 중심 사고를 통해 SDV를 포함해 미래 모빌리티를 가능하게 하는 바탕 역할을 현대오토에버가 수행할 예정입니다.

통합혁신센터는 지도(Map)를 그리는 조직입니다. 지도를 따라 정상화라는 1차 목적지까지 현대오토에버 구성원들이 잘 도착할 수 있도록 최선을 다하겠습니다.

 

https://v.daum.net/v/20250326113442805

링크드인 포스트

그래서 뭘 하고 싶은데요?!

누가보면 딱 욕먹기 좋은… 하지만 답해야 할 질문이다.

뭘 하고 싶으신가요? 뭘 하기 위해 이 자리에 있으신가요?

답은 본인이 정한 그 안에 이미 있는데, 객관식이 아닌 주관식으로 본인이 적어야 하기 때문에 두려운 건 아닌지.

지우개로 지우고 또 지워서 뭉개진 그 위에서 멍한 모습이 당신 모습 아닌가요?

스스로 당당해야 합니다. 내가 있는 자리와 내가 하는 일에 대해서. 오늘 현재의 그 모습에서.

결국 내가 나를 답합니다.

한계 – 안주할 것인가 확장할 것인가

한계를 어떻게 바라보고 있는지 종종 목격하고 있다. 많은 사람들이 자신의 경험을 바탕으로 “이게 우리의 한계입니다.” 라고 단언한다. 특히 오랜 직장 경험에서 비롯한 연륜의 느낌을 잔뜩 섞어 주니어들에게 세상은 특히 이곳은 이런 곳이라고 진지하게 이야기한다.  이런 분들은 “한계”라는 이름으로 안전 지대를 만들고 있다. 나의 문제, 혹은 노력 부족이 아니라 한계라는 내가 어쩌지 못하는 상황과 조건 때문이라는 변명을 하고 있다. 아주 딴딴한 절대 불변의 변명의 철벽이 “한계”이다.

하지만 한계는 고정된 것이 아니다. 각자 개인 혹은 조직의 심리가 한계를 고착화시키고, 딴딴하게 고정된 존재로 인식하는 것일 뿐이다. 고정되도록 만드는 것은 결국 상황에 있는 사람의 마음이다.

한계를 잘 사용할려면 이를 잣대(Barometer)로 써야 한다. 한계를 파악하는 것은 중요하고 반드시 필요한 일이다. 우리의 상황을 진단했고, 다음을 달성하기 위해 무엇이 필요한지 알고 있다는 것이니까 말이다. 부족한 부분을 보충하거나 확장하기 위해 무엇을 할 것인가? 질문에 답하면 된다. 기존의 사고 틀을 바꾸고 새로운 방식을 시도해야 한다. 과정을 반복하면서 한계를 확장하자. 굳이 모양이 이쁠 필요는 없다. 되려 투박하게 할 수 있는 부분부터 차근차근 넓혀가면 된다. 넓혀가고 있고 포기하지 않는게 중요하다. 인식된 한계를 잣대로 사용해야지, 움직이지 말고 가만히 있으라는 잘못된 편향으로 쓰면 안된다.

이런 관점에서 현대오토에버를 생각해본다. 현대오토에버는 시장에서 그룹사 자체 물량(Captive)으로만 성장한다는 비판을 받는다. 개인적으로 현 상황에 대해 다른 관점을 갖고 있다. 그만큼 현대차 그룹이 “Together for a better future”를 달성하기 위해 많은 것들이 필요하다는 것을 의미한다. 그리고 Digitalizing을 실현해야할 책임을 갖는 현대오토에버는 만들고 누군가에게 책임을 넘기는 SI 방식이면 안된다. 지속성을 담보하기 위한 “서비스(Service)” 중심의 개발과 운영 역량을 콕 찝어 이야기하는 것이다.

현대오토에버의 미션은 현대차 그룹의 Digital Transformation을 Digital 혹은 온라인 서비스 관점에서 실현시키는 것이다. 공공이나 민간 SI를 해서 돈을 벌어오는 것이 오토에버가 당장 감당할 몫일까? 더 나은 미래를 만들어가는 여정에서 자연스럽게 역량을 축적할 것이다. 당당히 현대차그룹내에서 실력을 보여주고 있으면 자연스럽게 만들어달라는 요청이 생가지 않을까? 누구나 인정하는 전문가에게 일을 부탁하지 다른 사람에게 부탁할까?

되돌아가 우리의 한계는 무엇인가? 현재의 한계에 안주한다고 했을 때, 과연 현대차 그룹이 꿈꾸는 동반성장을 통해 만들어갈 더 나은 미래를 디지털이라는 수단으로 완성할 수 있을까? 완성할 수 없다면 우리의 한계를 어디까지 넓혀야 당당하게 “이 책임을 현대오토에버가 담당하고 있습니다.” 라고 이야기할 수 있을까?

부끄럽고 창피하더라도 회피하지 않고, 똑바로 들여다보면서 이것이 우리의 현실이자 한계임을 알아야 한다. 새로운 한계점을 설정하고, 조직의 역량을 통해 새로운 한계에 도달할 수 있도록 제시하고 이끌어야 한다. 리더십의 일원이 내 몫이기도 하다.

책임 어떻게 질 것인가?

리더십에 대한 이야기를 하면서 뻔하게 내가 빼지않고 사용하는 단어가 책임이다.

리더는 단순히 권한을 행사하는 자리가 아니라 책임지는 자리고, 그 책임을 온당하게 지기 위해 권한을 행사하는 자리라고. 근데 뭔 책임인데?

리더가 져야 하는 책임은 조직이 주어진 혹은 선언한 사명(Objectives)을 온전하게 달성하게 하는 것이다. 달성하지 못하면 상응하는 책임을 져야 한다. 어떻게 달성할까?

조직의 목표와 달성했을 때 도출되는 결과는 조직, 즉 구성원들이 만드는 것이다. 리더 한 사람이 만들 수 있는 것이 아니다. 리더는 목표를 설정하고 목표를 달성하기 위한 조직내 합당한 역할을 정의한다. 그리고 위임한다. 앞서 이야기한 것처럼 리더 한 사람이 할 수 없기 때문에 조직의 힘으로 달성할 수 있도록 합당한 역할(사람)이 그 몫을 다할 수 있도록 구조라는 환경을 만들어야 한다. 환경을 만드는 것이 “권한 행사”다.

종종 권한의 종속적 개념으로 책임을 이야기하는 분이 있기도 하다. 완전 잘못된 생각이다. 그 누구의 책임도 아닌 리더의 책임이고, 온전하게 리더가 책임져야 한다. 그리고 조직의 규모에 따라 혼자 모든걸 이룰 수 있다는 생각도 지극히 1차원적이다. 이런게 되면 일론 머스크는 이미 화성에 갔다. 조직이 하는 것이고, 책임을 기반으로 위임해야 한다. 위임을 하기 위해 올바른 권한 행사를 하는 것, 그것이 어찌보면 리더의 역량이자 능력이라고 생각한다.

왜 이렇게 열심히 일하시나요?

함께 일하는 구성원이 퇴근하면서 한 질문이다.

내가 일하는 업무 강도를 보면 임원이라는 건 하면 안되는 포지션이라고, 줘도 안할 것 같다고 이야기하는 구성원이다. 매일 새벽 출근에 못해도 3일은 술먹고, 술을 안먹으면 밤 9시 근방까지 사무실 근방에 있다. 거기다가 하루 종일 떠들기까지. 저녁 무렵에는 목이 잠겨서 말이 나오지 않는 날도 있고. 적고 보니 그닥 좋은 직업은 아닌 것 같긴하네.

구성원 질문에, 글쎄? 흠…

그닥 근사한 답은 아닐지 모르지만 “꿈” 이라고 이야기해줬다.

나이 50 넘어 뭔 뚱딴지 같은 이야기인가 싶기도 하지만, 여전히 이루고 싶은 일이 있다. 특히 이 일은 쉽지 않은 대기업, 그것도 언제라도 짐을 싸야 한다는 이야기를 듣는 자리여야 해볼 수 있는 일이다. 뭐 얼마나 거창한 일이라고 그러는지 모르지만, 된다고 하면 의미있고 재미도 있을 그런 꿈이다.

항상 최선을 다해서 일하는 것에는 변함이 없지만, 언제든 그 일에 의미를 더한다면 더욱 최선을 다하고 싶은게 당연지사 아닐까 싶다.

최선을 대해 이루고자 하는 꿈에 한 발자국 더 다가가고 싶다. 이쯤되니 시간이 중요하고 더 잘 최선을 다해 쓰고 싶은 생각뿐이다.