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

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

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

리더십의 동기부여 – T자형 인재

컴퓨터와 인터넷은 급속한 지식 확산의 시대를 만들었다. 더불어 기술의 진보는 앞선 이야기처럼 인력(사람의 물리적 힘)을 넘어선 더 큰 능력을 사람에게 부여하고 있다. 이전에는 상상도 못했던 일들이 사람의 손가락 끝으로 버튼을 누르거나 마우스 클릭만으로 이뤄지고 있다.

지식이 주는 힘은 이제 확실하게 일을 해내는 바탕이 됐다. 산업 혁명을 통해 선진화된 대부분의 국가들이 보편적 교육 체계를 수립하고 공교육을 의무화한 이유는 제대로 아는 노동자가 더 높은 생산성을 발휘할 수 있기 때문이다. 농경 사회에서 기계라는 물건을 쓰는 환경으로 변화되어 작업의 효율은 기계의 복잡성을 이해하는지 여부에 직접적으로 비례하기 때문이다.

보편 교육을 보더라도 생활 지식을 위한 일반 교육과 직업과 관련된 전문성을 쌓기 위한 고등 교육으로 나뉜다. 국내에서 고등학교는 애매한 중간 성격을 갖고 있지만, 대학은 대부분 간다는 인식상 초등학교부터 고등학교까지를 일반 교육 영역으로 본다. 그리고 대학과 대학원이 직업에 필요한 높은 수준(혹은 기본기 수준)의 지식을 가르치는 고등 교육 기관의 역할을 수행한다. 보편 교육 체계는 일상의 상식과 인식에 대한 교육을 위주로 한다. 사회라는 집단에서 일하기 위해 필요한 논리적인 사고 방식과 함께 공동체 일원으로 행동하기 위한 예절 규범도 중요하게 배워야 할 내용이다. 사람에 따라 학습 수준의 차이에 따라 폭과 깊이가 다르지만 모두가 같은 걸 배우는 건 맞다.

고등 교육은 전문 영역에 대한 심화된 내용을 학습한다. 사람을 만날 때 MBTI를 질문하는 이유는 그가 나와 다르기 때문이다. 사람마다 갖는 유전적 특징과 부합하는 “일”이 존재하고, 그 일을 했을 때 최대의 효과성을 발휘할 뿐만 아니라 일하는 사람도 행복하다. 전문화된 기술을 학습하는 다양한 방법이 있겠지만 이미 널리 알려진 분야에는 고대부터 현대까지 많은 전문가들의 업적들이 쌓여있다. 평생 공부해도 다 배울 수 없기 때문에 직업 수행을 위해 필수적인 혹은 체계적으로 분류된 내용을 배운다. 고등 교육 체계는 전문성을 바탕으로 소위 인재를 길러내는 역할을 담당한다. 대학은 전문 지식을 공부하고, 석사는 공부하는 법을 배우고, 박사는 왜 공부하는지를 답할 수 있는 역량을 길러낸다고 생각한다. 각각의 단계를 거치면서 한 분야에 대한 전문성을 뾰족하게 갖춘다.

지난 학생 시절을 돌이켜보고, 현재 아이들의 현재 학교 수업 내용을 봐도, 왜 고등학교에서 미적분과 확률 및 통계를 배우는지 이해할 수 없다. 물론 다른 과목도 이해할 수 없는 교육 내용들이 많다. 일이 아닌 일반 사회 생활에서 미적분을 쓸 일이 몇 번이나 되겠는가? (기억이 가물거리긴 하지만 개인적으로 한번 있었던 것 같다.) 한국 교육 체계에서 고등학교를 보편 교육으로 분류하는 반면 독일의 경우에는 직업을 위한 고등 교육을 고등학교에서 실시하고 있다. 요즘처럼 지식 학습 속도도 빠르고, 체격적으로 준비된 상황에서는 독일의 사례가 더 맞지 않을까 싶다.

또한 대학은 전문성이라는 관점에서 합리적인 역할을 수행하고 있는지 궁금하다. 인재를 길러내야 하지만 양산하고 있는건 아닐지 우려된다. 기울어진 운동장은 자본주의 시장 경제에서 안타깝지만 현실이 되었고, 단지 한국만이 아닌 전세계적인 현상이다. 그냥 직업이 아닌 좋은 직업에 대한 경쟁은 더 치열해지고 있다. 고연봉과 함께 직업 안정성을 보장하는 큰기업과 같이 사람들이 일반적으로 인식하는 좋은 직장에서 일할 수 있는 기회가 많지 않다. 제한된 자리를 놓고 벌이는 경쟁에서 대학은 개인의 경쟁력을 학위로 증명하기 보다, 좋은 직장에 입사하기 위한 “어느 대학”이라는 자격증 역할을 하고 있다. 현재 시점의 현실은 소위 좋은 회사의 신입 사원 채용 대상은 인서울에 집중되어 있다. 서울 소재 대학이어야 신입 사원 관문을 뚫을 수 있는 가능성이 생긴다. 인서울이면 다 같은 “서울대”라는 말이 틀린 말이 아니다. 회사가 문제인가 대학이 문제인가? 어느 한 쪽의 문제라기 보다는 서울에 과밀된 인구가 문제라고 본다. 인구의 집중은 기회의 집중을 의미하고, 거주비를 포함한 높은 경쟁 비용은 기울어진 운동장의 높은 위치에 있는 소수가 더 많은 기회를 가질 수 밖에 없다. 사회가 시스템적으로 대응해야 해결 가능하고 큰 두 주체인 회사와 대학의 노력은 가장 기본이 되어야 한다.

보편 교육과 고등 교육을 염두에 두고 보더라도 사회는 교육 환경을 통해 구성원에게 보편성과 전문성을 갖춘 T 자형(혹은 쐐기형) 인재가 되라고 이야기 하고 있다. 현재 사회 시스템으로 인해 일부 왜곡된 부분이 있긴 하지만 높은 동기를 갖고 있는 사람이라면 당연히 T의 쐐기를 깊게 만들 것이다. 필요한 이유(동기)가 있다면 배울 것이고, 배운 내용이 본인의 지적 자산이 되면 쐐기의 한 계층으로 쌓일 것이다. 높은 동기가 자극제로 동작해 결과로 누적된 것이 역량(지적 능력)이라고 볼 수 있다. 앞서 P=MxA 형태로 성과를 간단한 도식으로 설명했는데, 이 관점에서 보면 P, M, A는 독립 변수라기 보다는 서로가 서로에게 영향을 주고 받는 상호 의존성이 있다는 걸 알 수 있다. 한 시점만 두고보면 각각이 독립적이라고 판단할 수 있지만 시간 흐름에 따른 장기적인 변화를 감안한다면 P, M, A 사이에 일련의 피드백 룹(Feedback Loop)이 존재한다고 볼 수 있다.

리더는 성과를 생각한다면 P(성과), M(동기), A(역량)가 상승 효과를 만들 수 있는 선순환 구조(Positive Feedback Loop)을 구상하고, 설계하고, 실행해야 한다. 이들 각각이 상호간 종속 변수임을 인정하고 의존성이 어느 순간에 발생하는지 조직 시스템을 설계하고, 관찰해야 한다. 특히 관찰은 매우 중요하다. 선순환 구조가 되어야 하지만 의도치 않은 변수에 의해 악순환 구조(Negative Feedback Loop)가 만들어질 수 있기 때문이다. 초기 단계가 아닌 정착 단계에서 지속 가능한 선순환 구조가 정립되면 자연스레 높은 동기를 갖는 구성원들의 노력으로 역량이 결집되고, 높은 혹은 좋은 성과들이 창출되는 구조가 만들어질 수 있다. 물론 순환 구조는 내버려두면 망가지기에 닦고 조이는 지속적인 관리가 필요하다.