현실 AX – Claude Code 그리고 Agentic

Posted by on

매우 도전적인 질문이다. 이런 도전적인 질문은 여지없이 욕을 먹기 마련이다. 뭐라고 남이 하는 걸 가지고 참견이냐라는. 그럼에도 AI, AX의 시대에 동참하고 있는 각자가 대표 도구인 클로드코드(Claude Code)와 그 너머의 AI를 어떤 방식으로 쓰고 있는지 짚어볼 시점이라는 생각이 든다. 정말 현실적인 이유인 토큰비 때문이다.

정말 클로드코드 전성시대다. 세상은 어찌보면 ChatGPT 이후 개발에서 AI를 인정했지만, 생활의 AI를 만든건 클로드코드가 아닐까 싶다. 올 초 앤트로픽의 클로드코드가 나온 이후 “도구로의 AI”에 대한 접근성이 크게 열렸다. 세상의 지식과 채팅하는 것을 넘어 API와 MCP로 주변과 연결된 진짜 도구가 된 것이다. 더불어 개발자의 도구 대표가 IDE에서 CLI로 넘어오며 코딩이 아닌 텍스팅이 새로운 개발 언어로 자리잡았다.

이전에도 CLI 기반의 도구가 있었다. 클로드코드가 대세가 된 건 CLI로써 훌륭해서가 아니라 CLI가 인터페이스로 더 적합한 형태가 될 만큼 앤드로픽의 LLM(Claude Sonnet)이 코드 작성에 뛰어난 성능을 보였기 때문이다. 그리고 Public LLM Vendor들이 코딩 각축전/경쟁전이 벌어지면서 성능(Performance)의 새로운 판이 벌어졌다. 간단한 Prompt만으로도 기대했던 결과를 만들어내는 코드가 만들어진다. 이전 AI는 코드 분석에 도움을 줬다면 이제 만드는 것도 쓸만한 수준이라는 믿음을 줬다. 사람이 작성한 Business Logic을 대상으로 테스트 코드를 작성하거나 코드 리뷰를 방식이었다면, 이제 요구 사항 분석, 테스트 코드, 로직 작성, 리뷰 체계와 같은 전체 개발 Cycle을 AI를 써서 실행할 수 있게 됐다. 어깨너머로 바라본 개발자들의 일하는 모습은 터미널에 3~4개 클로드코드가 분석, 코딩, 테스트 코드, 리뷰를 동시에 진행하는 것이 일상이다. 쿨~ 하다.

그런데… 정말 이게 맞는걸까??

요즘 클로드코드를 개발하는 모습은 TDD(Test Driven Development)와 정말 닮았다. 되짚어 질문해보면 왜 TDD가 나왔을까? 근원적인 이유는 사용자가 원하는 것을 잘 모르기 때문이다. 사용자 스스로도 자신이 원하는 것을 명확하게 모르기 때문에, 변화를 적극적으로 수용할 수 있는 단단한 개발을 하기 위해서다. 이 질문은 쓰는 사람과 만드는 사람이 분리된 상황에서는 언제나 유효하다. 실제 현장의 요구 사항은 여전히 엑셀 파일 하나로 전달되고, 해석된 결과물을 고객에게 전달하면 “이건 제가 원하는게 아닌데요.” 라는 반응이 일반적이다. 자신이 직접 만들어 쓰는게 아닌 이상 다른 사람이 내 마음에 쏙드는 물건을 만들어주는 경우는 없다. 물론 이런 이유로 직접 만드는 바이브코딩이 더 유행인지도 모르겠다.

이런 상황에서 AI 기반의 TDD는 어떤 효과를 만들까? 대강 아래와 같은 상황이 벌어진다.

  1. 요구 사항(개략적인)을 입력으로 테스트 코드 생성
    • 입력 – 요구사항
    • 출력 – 테스트케이스 코드
  2. 기본 팀 개발 Convention 스킬이 적용된 Business Logic 코드 생성
    • 입력 – 요구사항, 테스트케이스 코드
    • 출력 – Business Logic 코드
  3. 테스트를 수행하고, Test Fail된 코드에 대한 수정
    • 입력 – Business Logic 코드, 테스트케이스 코드
    • 출력 – 수정된 Business Logic 코드
  4. 코드 리뷰
    • 입력 – 요구 사항, 테스트케이스, Business Logic 코드
    • 출력 – 코드 수정 사항

1~4 단계의 단일 Iteration 과정을 보더라도 후반부로 갈수록 더 많은 입력이 AI에게 필요하다. 앞단에서 생성한 출력 결과들이 뒷단계의 입력으로 사용되고, 입력의 크기는 상상 이상으로 커진다. 한번의 단일 Iteration으로 완성되지 않기 때문에 많은 Iteration을 반복해야 한다. 만약 세부적인 명세가 없어 Business Logic을 파고들면서 구체화하는 과정이 필요한 상황이라면 정교한 컨텍스트를 위해 더 많은 입력이 필요하다. AI 언덕에서 구르는 Snowball 효과가 여기에서 발생한다. 불명확한 요구사항이나 명세의 부재는 눈덩이가 구르는 언덕의 기울기를 급경사로 만든다. 입력과 출력을 토큰으로 대입해보면 소위 토큰을 태우는 Token Maxing 효과가 나온다. 정교한 개발 전략이 뒷받침되지 않으면 지갑이 남아나지 않는다.

개발 전략: 개인 바이브와 조직 바이브의 차이

개발 전략은 개인이 하는 바이브와 조직의 바이브를 갈리는 지점이다. 개발 전략은 장기적인 조직의 개발 Economy를 결정한다. 전략의 부재는 조직내 개인이 개인 바이브를 통해 성과를 만들고 있다는 것을 의미한다. 각자가 자신의 방식으로 문제를 풀지만, 조직내의 각자가 푸는 문제는 조직의 문제를 해결하는 것이다. 개인 프로젝트를 하는게 아니니까. A와 B가 해결하고 기여해야 하는 도메인이 있고, 각자의 Problem Space가 존재하고 이에 대한 해결책을 A, B 모두 바이브를 통해 정의하고 해결하고 있다. Problem Space의 합집합이 도메인 문제와 해결 방안이지만, 교집합 역시 중요하다. 특히 AI가 빠르게 대량으로 생산하는 코드에서 교집합 부분은 서비스의 연속성에 치명적인 영향을 미칠 수 있다. 성공적인 합집합과 교집합을 유지 관리하는 것이 결국은 개발 조직과 서비스 조직의 연속성을 보장하기 때문에 더욱 더 개발 전략이 중요한 이유다.

개발 전략의 중요성을 우리 업계는 이미 MSA(Microservice Archtiecture)를 조직내에서 도입하면서 경험했다. Architecture 수준의 Governing을 통해 관리되지 않는 마이크로서비스 체계는 빠른 속도를 보장할 수는 있어도, 각자 개발에 따른 파편화를 피할 수 없다. “빠른 배포”라는 이름하에 마이크로서비스를 개발할 수 있지만, 동일한 역할/기능을 하는 마이크로서비스가 남발되기도 하고, 분리된 코드베이스로 인해 “코드 중복”이 걸러지기 어렵게 됐다. 중복과 반복 지점에 대한 변경이 발생하면 고친 문제가 고쳐지지 않는 세상 골치아픈 상황에 처하기도 한다. 어찌보면 AI로 인한 코드 대량 생산 시대가 우리에게 같은 질문을 다시 하고 있는게 아닌가 싶다.

AI 기반의 개발은 사람 중심의 개발과는 다르다. 사람이 개발하던 방식을 AI 방식에 대입하면 결국 같은 문제를 되풀이할 수 밖에 없다. 새술을 새부대에 담아야 하는 것처럼 새로운 관점에서 개발 패러다임을 봐야하고, 이 패러다임은 개발 체계 흐름을 한 요소를 해결하는 방식이면 제한된 결과만을 얻게 된다. 전지적 관점(Holistic View)에서 조망하고, 사람과 AI의 역할 재정립, 그리고 그 사이를 단단하게 잇는 거버닝이 수반되야 한다.

현실 AX – Ax vs. aX

Posted by on

AX = AI eXperience

“AI”와 “경험”이라는 두 단어지만 이걸 받아들이는 사람들의 정의는 각각인 것 같다. 정의 차이는 A와 X 가운데 어느 곳에 힘을 주느냐에서 나온다. A를 강조하는 쪽은 AI를 쓰는 것에 우선하는 반면에 X는 일상의 경험이 바뀌는 것을 우선한다.

AI를 쓰면 일상이 바뀔거라는 생각은 지나친 낙관주의다. 세상의 모든 시선이 AI에 집중되다보니 쓰면 바뀌고 가치가 올라간다는 착시 현상이다. 정작 무엇이 바뀌었는지 냉정히 따져보면 바뀐 건 AI를 쓴다는 것 밖에는 없는 것 같다.

개발 세상에서 AI가 바꾼 걸 가혹하게 말하면 IDE와 단축키를 대체했다는 것 아닐까? 이제는 Claude Code나 Codex가 없으면 개발을 못하는 지경이 됐으니 말이다. 그렇다고 개발 속도가 급속도로 빨라지지도 않았다. 물론 코드가 작성되는 속도는 비약적으로 빨라졌지만 정작 사용자를 위해 제대로, 장애없이 실행되는 지점에 도착하는데 걸리는 시간은 이전 IDE로 코드를 짜던 때와 대비해 극적 향상을 만들지는 못했다.

AI 무용론을 이야기하는 것이 아니다. AI는 분명 혁신적인 물건이다. 다만 혁신은 단순히 쓴다고 해서 만들어지는 것이 아니다. 우리 일상에서 혁신을 어떻게 대입할지를 고민해야 AI가 기여한 일상의 찐 혁신을 이룰 수 있다. 인터넷과 스마트폰이 불러온 혁신을 혁신이라 부르는 이유는 이것들이 없는  일상을 생각할 수 없기 때문이다. 세상을 바꿀 것 같았이 등장했던 세그웨이가 한때의 유명세가 되버린 것과 대비된다. AI를 통해 일상의 변화를 만들기 위해서는 먼저 우리는 어떤 일을 어떻게 하고 있는지를 스스로 관찰해야 한다. 관찰을 통해 AI로 변화할 수 있는 지점, 구간이 어딘지 찾아야 한다. 물론 이걸 위해서는 AI를 경험하고 이해해야 한다. AI Literacy가 필요한 이유다. 기본인  Literacy 이외에 실제 변화를 위해서는 당연히 토큰비를 포함한 투자가 필요하다. 변화의 정당성은 효과가 투자 비용을 상쇄할 때 입증된다.

다시 개발 세상으로 돌아가보자. SDLC(Software Development Life Cycle) 관점을 간단히 요약하면 “요구사항(Requirement) – 개발(Coding) – 검증(Functional Test)- 배포(Deploy) – 운영(Operation)” 이라는 흐름으로 동작한다. 그리고 흐름을 구성하는 개별 요소는 전단계 요소의 결과에 따라 필연적으로 “대기 시간”이 발생한다. 명확하지 않은 요구 사항으로 아키텍처가 뒤바뀐 경험을 한 아키텍트는 온전한 요구 사항이 수립될 때가지 기다린다. 한 줄 요구 사항에 혼쭐난 개발자는 완벽한 명세가 기입된 Jira Ticket이 오기 전까지는 Business Logic을 구현하고 싶지 않다. 결국 이런 대기 시간이 합쳐서 비효율을 만들고, 앞단의 대기 시간은 뒤쪽으로 흐를수록 스노볼 효과를 만들게 마련이다. 개발에 Claude나 Codex를 쓴다고 해서 전체 개발 시간이나 Performance 개선이 이뤄지지 않는 이유가 여기에 있다.

결국에는 흐름(flow)를 혁신해야 찐 AI 효과를 볼 수 있다. 기존 흐름이 만드는 가치를 AI를 이용한 흐름으로 재설계해야 혁신의 결과를 기대할 수 있다. 그리고 재설계의 핵심은 흐름에 필연적으로 존재하는 대기 시간에 있다. 사람 중심 흐름에 존재하는 대기시간을 AI 중심에서 없애거나 최소화되야 한다. 사람이 아닌 기계의 속도는 실행 시간을 극단으로 줄일 수 있다는 것이 오히려 대기 시간으로 역효과를 만들 수 있다. 단순히 사람 중심의 기존 흐름에 AI를 끼워넣으면 대기 시간이 만드는 병목 현상이 흐르는 관을 부풀려 터트릴 수도 있다. 쓸 수 있다고 해서 썼다가는 거덜날 수 있다.

현실 AX – 주간보고

Posted by on

AI를 써야한다고 정말 열심히 이야기한다. 하지만 역설적으로 보고하고 보고받는 미팅으로 대부분의 시간을 보내는 것이 일상이니 정작 내가 직접 AI를 쓸 수 있는 기회는 많지 않다. 그래도 말따로 행동따로면 안되니 해야겠다는 생각 와중에 이건 할 수 있겠는데? 라고 생각한 아이템이 주간보고다.

정말 다행으로 연초부터 컨플런스(Confluence) 기반으로 전사 주간보고 체계가 돌아가고 있다. 컨플런스로 전환하면서 주간 보고 작성 형태도 일원화됐다. 사실 컨플 기반의 전사 주간 보고 틀을 잡을 때, AI 사심을 넣어서 이런 방식이면 AI에게도 좋겠다는 형태로 잡아보자고 했다. 이만큼 해뒀으니 여기에 AI를 써보기로 했다.

해보기로 맘먹은 당시에 6개의 실과 3개의 직할 팀이 있었다. 개별 조직에서 취합한 주간 보고 내용을 조직장들과 검토, 논의하고 그 가운데 전사 공유 내용으로 올릴 내용을 선별해 이를 주간 보고 회의체에 올려야 한다. 주간 보고 논의 내용 취합과 선별된 아이템을 정리해주는 담당자(사람)이 있었다. 하지만 올 초부터 담당자가 원래 해야 할 일에 집중하고, 이 일은 직접 하겠다는 호기를 부렸다. 실제 취합과 선별 내용을 올리는 걸 직접 해보니 생각보다 녹녹치 않았다. 어찌보면 간단하고 쉬울 복붙인데 항목별로 Copy를 하고, 전사 주간 보고 페이지에 Paste하는 일은 곧잘 20~30분을 잡아먹었다. 특히 더 어려운 점은 이 일이 “매우 귀찮은 일” 이라는 것이다. 중요한 일이 맞지만 Copy & Paste를 하고, 틀어지지 않도록 수정하는 작업은 가치를 만드는 일이라기보다 번거로운 반복 작업인 건 틀림없는 사실이었다. 귀찮으니 안하게 되고, 안하니 더욱 “일”이 되버렸다. 그러니 매번 전사 주간 보고 운영 담당자에게 쪼임을 당하기 일쑤였다. 그런데 이걸 왜 내가 하고 있는거지?

AI한테 시키면 되잖아!!

그래서 클로드를 열었다. 먼저 Confluence API를 연결하고, PAT(Personal Access Token)을 발급했다. 그리고 “이 페이지의 선택된 내용들을 옮겨줘!” 라는 사람에게 지시할 법한 Prompt를 넣었다. 샘플 페이지의 내용을 의도한 대로 대상 페이지로 옮겨줬다. 오~ 유레카!!! AI의 힘이구나!!

이제 실전으로 실제 주간 보고 페이지를 지정하고 옮겨달라고 했다. 하지만 예상과 달리 실패해버렸다. 그리고 “컨플런스 페이지를 복붙하시는게 더 빠릅니다. 복붙 방법을 안내해드릴까요?” 라는 친절한 안내를 해줬다. 신박하네! 그래도 내가 개발자 출신인데 자존심이 있지 왜 안되는지 단계를 따져보니 정말 간단한 이유였다. 주간 보고 내용이 API가 허용하는 한계를 넘어버렸다. 왜 그런가 싶긴 했는데 Curl로 컨플런스 API를 호출해보니 이유를 알만 했다. curl이 알려준 사실은 이렇다.

<table> <tr> <td>..</td> <td> .. </td> .. </tr> <tr> .. </table>

내용은 없고, 죄다 마크업 Tag들이 전부다. 본질은 없고 껍데기가 난무하니 눈에 보이는 글씨보다 몇 곱절 데이터의 크기가 부풀려질 수 밖에. 사실 표(테이블)로 정갈하게 맞춰진 보고서는 사람이 읽기에 좋다. 하지만 AI가 맥락을 파악하기 위해 읽는데는 방해물이 될 뿐이다. 결국에 AI가 쓸 수 있는 데이터가 문제였던 것이다.

해결하기 위해서는 AI가 쉽게 읽을 수 있는, 그리고 사람은 무난하게 읽을 수 있는 형태가 필요하다. 먼저는 테이블을 없앴다. 그리고 보고 테마를 구분하기 위해 컨플런스의 제목을 활용했다. 테이블이 사라진 허전함은 블릿을 사용해 사람 가독성을 챙겼다. 그리고 전사 보고가 필요한 내용인지 아닌지를 구분하기 위해 Checkbox 를 사용해 주간 보고 이후에 어떤 항목을 올릴 것인지를 체크할 수 있도록 했다. 이렇게 형태가 갖춰졌다. 이 내용을 스킬로 만들어 작성하도록 할까 생각하다가… 오버엔지니어링이라고 결론냈다. 그냥 템플릿 페이지가 있으면 그걸 복사하면 될 걸. AI를 쓸게 아니라 그냥 API를 쓰면 된다.

좀 내용 많은 주간 보고 하나를 찾아서 이 양식에 맞춰 테스트 데이터를 준비했다. 다시 시도. 하지만 이번에도 안된다. 분량이 많으면 API도 버벅이는구나. 분명 Payload 크기를 조정할 수 있는 API가 있을 것 같았다. 찾아볼까 하다가 다시 든 생각은 6개 실, 4개 팀의 주간 보고 내용을 굳이 한 페이지에 담을 필요가 있을까? 아무리 컨플이 공동 편집이 된다고 하지만 컨플이 구닥(Google Docs)는 아니다. 나 조차도 쫑나는 것 때문에 내용을 다시 입력한 번거로움이 기억났다. 개별 조직 단위별로 세부 페이지를 나누고 내용을 볼 수 있는 Master 페이지를 두고 거기서 한 번에 사람이 볼 수 있도록 했다. 편집할 때 실장님, 팀장님들이 번거로울 일도 없고, 개별 페이지 내용도 한 조직의 내용만 담으면 되니 크기도 작아지고, 사람이 읽기에도 부담이 없다. 1석 3조!

Master와 Sub 페이지 방식으로 구성된 템플릿을 다시 만들어 테스트를 돌렸다. 조정된 스킬이 이제는 완벽하게 각 팀별 페이지를 만들고 조직장님들의 입력을 기다리는 형태가 됐다. 이제 사람들이 일하고 나도 일할 수 있는 상태가 됐다.

HITL – 근데 주간 보고는 어떻게 돌아갈까?

솔직히 이 질문 재미있다. 평소에 생각하지도 않았던, 해보지 못했던 질문이다. 우리는 많은 일을 하지만 세부적인 형태, 방식을 생각하지 않고 그냥 한다. 숙련됐다는 표현이 이걸 나타내는 것이다. 물론 처음에는 구체적이고 순서에 따른 방법을 생각했을지 모르지만, 어느 순간부터는 그냥 하는 거다. 이것이 인간이 수천년을 거치면서 발전시킨 인간의 일하는 방법이다.

원래 질문으로 다시 돌아가 주간 보고가 어떤 방식으로 이뤄지는지 정리해보자.

  1. 조직장들(사람)이 각 조직의 주간 보고 내용을 기입(작성)한다.
  2. 센터 주간 미팅에서 주요 안건을 리뷰(사람)한다.
    • 영향력 위주로 전사주간보고 항목으로 지정하고, 특히 그 가운데 발표 항목을 선정한다.
    • 전사 구성원들이 읽을 내용이기 때문에 부족하거나 과한 내용은 직접 수정하거나 부탁한다.
  3. 수정이 마무리되면, 보고 자료를 전사 공간에 게시한다. (사람의 결정)
  4. 작성을 마친 주간 보고 자료는 별도 공간에 이력을 위해 백업한다 (사람의 결정).

나와 조직장들은 각 단계에서 자신의 역할을 한다. 조직장들의 역할은 작성과 보완이고, 내 역할은 결정과 보완이다. 그리고 역할이 끝나면 이를 모으고 올리는 과정을 통해 AI가 동작하길 나는 희망했다. 그래서 단계 각각을 4개 스킬(Skill)로 나누어 만들었다. 물론 각 스킬이 기대만큼 완벽하게 동작하지 않았다. 제대로 된 형태/방식으로 스킬이 돌려면 일종의 최적화와 맞춤 기간이 필요하고, 무엇보다 가장 중요한 건 써보는 것이다.

내가 쓰는 것도 것도 중요하지만, “전사 주간 보고”는 혼자만의 작업이 아니라 조직장들과 함께 하는 것이다. 쉽게 말하면 때가 되면 새로운 주간 보고 페이지가 나와 있어야 올릴 수 있고, 센터 주간 회의를 마쳤다면 해당 내용이 전사 공간에 올라가야 한다. 그런데 만약 내가 휴가를 가거나 아파서 누워버리면? 이 작업을 누군나 할 수 있어야 하는데???

화룡점정 – 공유하고 누구나 쓰기

AX의 마지막은 내가 할 수 있는 이 작업을 누군가도 할 수 있어야 한다는 점이라고 생각한다. AI를 활용한 작업이 개인화/사유화되면 결국 조직의 역량이 아닌 개인 역량에 머문다. 다행히 스킬을 모으는 Git Repo가 따로 있었고, 해당 레포에 MR을 생성해 Merge까지 완료했다. 공유가 됐으니 “할 일 다 했습니다!” 로 끝나면 곤란하다. 스킬을 공유한다는 건 생각보다 어렵다. 특히 공유가 문제가 아니라 스킬이 작성된 환경 자체가 개인에게 맞춰진 경우가 많기에 실제 스킬이 다른 사람의 환경에서 잘 돌지는 장담할 수 없다. 다른 사람들의 단순 MR/PR 코멘트도 중요하지만 실제 사용 피드백이 더 큰 의미를 갖는다. 다행히 실무 개발에 몸담고 있는 조직장 2분이 잘 쓸 수 있다는 착한 피드백을 줬다. 나처럼 개발을 한참 전에 놓은 다른 실장이 성공적으로 수행하는 것도 추가로 확인했다. 내가 없더라도 AI적인 형태로 주간 보고는 운영이 되겠구나 싶은 생각이 들었다. 물론 AI답게 더 발전시켜줄 사람이 필요하겠지만.

하지만 이게 다일까? 좀 더 들여다보면 우리가 이야기하는 AI, 특히나 비엔지니어링 직군이 보지 못하는 또 다른 면이 요즘 AI에는 있다. 그 이야기는 다음에 좀 더 풀어보자.

접착제같은 AI라고 해야할까?

Posted by on

호랑이 담배피던 시절의 전자정부 프레임워크을 통해 배운 교훈은 프레임웍을 만들려면 잘 유지되야 한다는 것이다. 그래서 프레임워크라는 물건을 만드는 건 매우 어렵다. 전자정부 프레임워크는 당시의 Spring Framework 초기 버전에 공공 프로젝트 진행을 위해 필요한 몇가지 요소를 더한 것이다. 스프링이 시장의 주류로 자리잡는 시기였기에 일관된 형태로 사용하도록 가이드가 어려웠다. 더해서 스프링 프레임워크는 쭉쭉 발전하는데, 전자정부 프레임워크는 스프링의 발전 속도를 따라잡지를 못했다. 결국 한참 벌어진 차이를 극복하지 못했고, 오히려 이걸 쓰는게 보안적인 취약점을 만들기도 했다. 결국 현실의 스프링 대비 한참 낮은 버전이 전자정부 프레임워크의 기반이 되버렸고 개발자들은 왜면했다. 공공 SI를 해야하는 어쩔 수 없는 회사의 개발자들이나 써야하는.

다른 개발 프레임워크은 어떨까? 따지고 보면 예전의 전자정부 프레임워크 접근과 크게 틀리지 않다. 예전에는 그냥 스프링 기반이었다면 이제는 대부분이 스프링부트의 이런 저런 것들이 기반이라는 점 아닐까? 여기에 사내에서 정의된 표준 시스템들인 PaaS 혹은 SaaS를 프레임워크의 요소가 될 것이다. 구성만 보면 전자정부 프레임워크의 구성 요소와 별반 다르지 않은데?

프레이워크를 만든다면 프레임워크 구성 요소들이 동작하도록 엮어야 한다. 상호 동작을 위해 묶으면 일단 강결합이(Tight Coupling) 발생한다. 이런 강결합 상황에서 개별 요소 하나를 바꾸는 건 의존성 문제로 쉽지 않은 일이 되곤한다. 유용함이 커질수록 결합도는 높아지고 변경에 따른 고려 사항들이 많아진다. 결국 바꿀 것들이 많아지거나 아니면 현상을 그대로 유지하는 선택을 강요받는다. 프레임워크의 유지보수 비용이 많이 들어가는 이유이고, 대부분의 프레임워크가 망하는 이유이기도 하다. 그만큼 유연한 구조, Loosely coupled 형태의 프레임워크를 만들기 어렵다.

요즘 만드는 프레임워크는 묶음을 코드가 아닌 AI와 스킬(Skill)을 통해 해결한다. 물론 관련성있는 모듈을 엮기 위한 충분한 메뉴얼이 있어야 한다. 모듈들이 어떤 방식으로 조합되면 좋을지 예시(Example)이 있다면 이를 바탕으로 스킬을 만들 수 있다. 코드가 필요하지만 실제 결합을 위한 코드가 굳이 필요없다. 결합 코드가 물론 좋지만, 코드를 통한 결합은 강결합을 만든다. 이에 반해 AI와 스킬의 조합은 약결합을 통해 기존 강결합된 프레임워크가 보여줄 수 있는 기능을 제공할 수 있다. 프레임워크의 구성 요소의 변경이 필요하더라도 변화 대응에 대한 유연성을 충분히 확보할 수 있다. 다만 언제나 그렇듯 프레임워크 자체에 대한 릴리즈 관리는 변함없이 필요하다.

AI 기반 프레임워크의 주의점은 역시나 할루시네이션이다. 너무 물렁한 요소들이 결합된다면 의도와 다른 방식의 결합물을 쓰는 사람에게 제시할 수 있다. 기능에 대해서는 단단함을 제공해야 하고, 이들이 이어지는 맥락을 약결합되지만 혼선없이 엮일 수 있는 가드레일을 함께 제공해야 한다. 그래야 프레임웍이 제공하는 전체적인 완결성이 지속적으로 제공될 수 있다.

AI 기반 프레임워크가 주는 매력은 굳이 Gradle이나 Maven 같은 툴에 엮을 필요가 없다는 점이다. 프레임워크를 AI Agent화 시키면 언제든 필요할 때 꺼내 쓸 수 있기 때문이다. 그리고 상황에 따라서는 AI가 스스로 이 상황에 가장 맞는 도구로 프레임워크를 꺼내주는게 된다면 “거버닝”을 굳이 강제하지 않아도 자연스러운 조직의 개발 활동으로 이어질 수 있지 않을까 싶다.

꿈꾸는 이야기같지만 실제 이런 것들이 가능한 것이 요즘 아닐까 싶다. 개인이 개발한다면 굳이…라고 이야기할 수도 있겠지만, 조직이 개발을 한다면 이런 프레임워크라는 환경이 조직내에 있어야 한다고 생각한다. 언젠가는 되겠지…

효과적인 AI – 맥락에서 스토리로

Posted by on

AI는 맥락을 기반으로 스토리를 풀어낸다.

적절한 맥락을 줬을 때 AI가 기가막힌 응답을 만들어내는 걸 보고 있다. 거꾸로 짚어보면 좋은 혹은 쓸만한 결과를 만들기 위해서는 맥락이 중요하다는 반증이다. 하지만 기대하는 결과가 커지면 커질수록 부합하는 맥락은 어느 수준일까?

Prompt Engineering이 주류를 이룬다. 좋은 Prompt를 이야기하면서 그 Prompt가 내가 겪고 있는 문제를 한번에 해결해주길 원한다. 사람이 그렇다.

하지만 정작 문제를 잘 들여다보면 한가지 문제가 아니라 여러 문제들이 복합 작용을 일으켜 나를 골치아프게 만드는 그 문제를 만든다. 하지만 우리는 덩어리진 큰 문제를 바라볼 뿐 헤집어 제대로 된 문제들을 보려 하지 않는다. 사람이 그렇다.

사람은 소프트하게 이 문제를 그동안 개발 세상에서 풀어왔다. 그러면서 여러가지 방법들을 엔지니어링이라는 이름으로 발전시켰다. 방법의 하나하나에 아키텍처라는 개념적인 이름을 부여했다. 그렇게 해서 생겨난게 Monolithic 이나 MSA가 아닐까 싶다.

상황에 어떤 아키텍쳐 적합한지 이야기하듯, 어떤 방식 혹은 구조의 Prompt Engineering이 맞는지를 논하는 시점이라고 생각한다. 그리고 이를 구성하는 Reusable Prompting이 뭔지, 그걸 넘어서 다시 물어볼 필요도 없는 것이 뭔지를 제시할 수 있는 사람이 지금 시대의 아키텍트가 되어야 하지 않을까?

그래서 지금 시대의 아키텍트는 스토리를 만드는 작가(스토리 텔러)와 점점 유사해지는 것 같다.

효과적인 AI – 30:70에서 10:90으로

Posted by on

30:70 혹은 20:80은 IT 업계에서 제품/서비스는 만들기보다 운영이 더 어렵다는 것을 의미하는 대표적인 비교 수치다. 제품/서비스의 전체 생애주기에서 만드는 비용보다 쓰이는 과정에서 닦고 조이는 비용이 3배 혹은 4배 이상 들어간다는 것이 업계 정설이다. 특히 생명주기가 긴 제품, 혹은 사용자가 많은 제품일수록 이 비용의 크기는 커진다.

SaaS/PaaS 시대를 거치면서 구성 요소의 일부를 서비스로 대체하면서 운영 노력 일부를 낮추는 효과를 거두기도 했지만, 그렇다고 비용 자체가 낮아진 것은 아니다. S(P)aaS 역시 잘 쓰면 보약이 되지만, 독이 되는 경우도 빈번하다. 자충수를 초래해 비용 대비 이익을 얻지 못하거나 큰 청구서를 받을 수 있고, 락인에 빠져 이도저도 못하는 최악의 상황에 직면할 수 있다.

바이브 코딩을 외치는 AI의 시대에 이 비율은 어떨까? SaaS가 시장 주류로 자리잡기 시작한 시점과 매우 겹치는 멘트들이 많다보니 과연 AI는 제품과 서비스의 생애주기 비용에 어떤 영향을 미칠 것인가? 전문 개발자 뿐만 아니라 바이브로 자신이 원하는 걸 스스로 만들 수 있다는 모두가 개발자인 시대가 정말 도래한 것일까?

10:90

무료 구글 제미나이가 답한 생명주기에서 개발과 운영의 비중이다. 다음 프럼프트를 사용해 얻은 결과다.

개발과 운영의 비용에 대해 업계에서 통상적으로 이야기하는 비율을 알려줘.

AI 시대에 이 비율이 유지되나?

2026년 현재 시점에서 인터넷상에 쏟아진 AI 시대 현재 개발 담론을 종합한 결과일 것이다. 누가 AI를 써서 개발을 했느냐에 따라 달라지는 숫자라 맞다 틀리다 이야기할 수 없지만 쓰는 개발 역량을 갖춘 사람들의 평균을 고려한다면 합리적인 숫자라고 생각한다.

하지만 바이브만으로 만들어진 제품의 생애주기 비용이라면 이야기가 다른다. 10:90이 아니라 5:95 극단적으로 1:99일 수도 있다. 기능적으로 동작할지 모르지만, 개인적으로 살펴본 AI가 만든 코드의 품질이 불량했다. 더구나 추가 필요 사항을 위해 고쳐도 AI라는 확률 머신이 기존 기능을 그대로 유지할지 장담할 수 없다. Harness를 동반한 정교한 Prompting이 아니면 엉뚱한 곳도 함께 바꾸기 일쑤다. 아는 사람이 고칠려고 하더라도 난해한 코드 파악과 사이드이펙트(Side Effect) 수정에 시간/비용이 필연적으로 발생한다.

제품/서비스의 비용은 생애주기 전반 관점으로 살펴야 한다. AI는 당연히 써야 하고, 생애 주기 전체 흐름의 효과를 얻기 위해 전략적으로 대입하는 지혜가 필요하다. 한 구간의 효율은 다른 구간의 병목을 필연적으로 유발한다. 개발과 운영이라는 사이클이 사용자 가치 만족으로 흘러가는 파이프에서 AI라는 도구의 역할을 명확히 정의해야 한다. 그리고 종종 파이프를 통통쳐 막히는 구간이 없는지 들어보고 살펴봐야 한다.

남도 쓸 수 있는 것을 만드는 건 쉽지 않다. 만족이라는 단어는 참 어렵다. 남에게도 좋은 것을 생각하는 순간 이것저것 고민할 것들이 많아진다. 그래서 엔지니어라는 직업이 여전히 유효하고 유망한 직업/직종이라고 믿는다. 다만 정의는 계속 변하겠지만.

바이브는 새로운 세상을 여는 것은 맞다. 스스로 생각했을 때 재미있는 걸 만들었다면 주변에 공유하고 도움주고 생각을 나눌기회가 된다. 그리고 지인 가운데 엔지니어가 있다면, 과연지속 가능할지??? 즐겁게 토론할 수 있는 기회도 제공해줄 수 있을 것이다.

즐 바이브~

효과적인 AI – 토큰값

Posted by on

AI를 잘 쓸려면 알아야 하고, 아는 가장 첫번째 방법은 써보는 것이다. 쓰다보면 유용함을 알게 되고, 유용하면 더 쓰게 마련이다. 특히 아는 사람이 더한다고 엔지니어들은 이제 AI없이는 일할 수 없는 세상이 됐다. 세상이 이렇게 변하다보니 개인이나 회사나 모두 토큰비를 걱정할 수 밖에는 없다. 최근 성능 좋은 AI 공급사들이 쓴만큼 청구하는 방식으로 전환하기에, 더욱 더 고민될 수 밖에 없다. 가랑비에 옷 젖는 것처럼, 무계획이면 지갑 거덜나기 십상이다.

가장 좋은 방법은 한번 토큰을 지불한 일을 되풀이하지 않는 것이다. 토큰비 중복 지불을 최소화 하는 것이다. 이 개념이 반영된 것이 스킬(Skill)이다.  목적을 가지고 만든 Prompt를 매번 다시 할 이유가 없고, 남이 잘 만들어 공유한 Skill을 굳이 쓰지 않을 이유가 없다. 와중에 AI가 맥락을 잘 이해할 수 있는 글쓰기는 어렵다.

엔지니어에게 더 좋은 방법은 라이브러리와 API를 사용하는 것이다. AI를 쓰던 안쓰던 사용자가 쓸 기능의 코드를 만드는 것이 엔지니어의 역할이다. 이미 동작하고 검증된 코드가 있다면 마다할 이유가 굳이 없다. 와중에 복붙이 아닌 관리 가능한 형태로 제공되는 코드라면 더욱 더. 코드 재사용으로 사용자를 위한 기능에 시간과 토큰을 쓰는 것이 사용자 중심 엔지니어링이다.

조직에서 공유와 기여(참여)가 발동되면 우상향된 효과를 볼 수 있다. 개인 차원에서도 물론 효과가 있지만, 조직 구성원들이 좋은 스킬, 라이브러리, API 들을 만들고, 공유하고, 재사용되면 더 큰 가치 창출의 발판이 된다고 믿는다. AI는 이 씬에서 속도와 창의성을 뒷받침하는 아주 좋은 지렛대로 쓰일 수 있다.

제대로 전문가

Posted by on

샘 올트만 한국에 방문해 대통령과 환담하는 영상이 화제다. 두 사람의 대화가 화재가 아니라 샘 올트만의 장시간의 단독 발언 내용을 두 페이지에 걸쳐 메모장을 써서 의미 손상없이 명확하게 짱짱하게 전달하는 통역사가 화제다. 보기에도 정말 프로페셔널하다.

프로페셔널 관점에서 영어를 잘 한다기보다는 집중력이 놀랍다. 특히 올트만이 이야기하는 과정에서 맥락을 잡기 위한 메모에서 맥락을 놓치지 않기 위해 메모지를 넘기는, 튕기는 모습이 더 인상적이다. 대통령이 있는 자리에서 저런 동작과 일종의 소음이 무례가 될 수 있다고 “의전”을 생각하는 사람들은 생각할 수 있다. 그런 부분들은 모두 제끼고 본인이 자리에서 해야할 가장 중요한 일에 몰입해 달성해나는 모습이 너무 대단하다고 생각한다. 극강의 집중력이다.

프로라면 이래야 하지 않을까 싶다. 내가 있는 자리에서 보여줘야 할 플레이가 있다면 온전하게 그것에 집중해서 결과를 만들어내는 모습이어야 한다. 간만에 짜릿한 프로의 모습을 본 것 같아 즐겁다.

변화는 누구의 몫인가?

Posted by on

2027년까지의 변화 전략을 수립하면서 예상한 가장 큰 어려움은 변화 자체를 구성원들이 인식하게 만드는 것이다. 1년여 사이에 수립한 전략을 실행하는 과정에서 느낀 가장 큰 괴리는 임원분들한테 정말 많이 이야기를 했는데, 팀장까지만 내려가도 모른다는 것이다. 어라?

본사 팀실장들을 모아놓고 변화 전략을 이야기한 이유이기도 하다. 그리고 한 발 더 나아가 지방 사업장을 중부와 남부로 나눠 이야기를 떠들었다. 물론 이런 한번의 이야기로 뻔한 이야기가 뇌리에 모두 박힐거라고 생각하지 않는다. 그리고 박히기만 해서도 변화는 이뤄지지 않는다.

변화는 누구나 두렵다. 인간이란 존재가 그런 존재다. 익숙한 것에서 벗어난다는 것에서 “왜 내가 벗어나야 하는거냐?” 라는 항의성 질문은 언제나 존재한다. 그럼에도 실질적인 변화는 그걸 해야한다고 대다수가 받아들일 때 실체화된다. 대다수가 받아들일려면 그들이 믿을 수 있는 일말의 증거가 있어야 한다. 저걸 해야 나에게 이득이 된다는. 인간의 이기적인 유전자는 자신의 이익이 담보되야 행동을 유발한다. 도움된다는 것을 실제로 보여줘야 믿고 그나마 행동한다.

지방 사업장에서 팀원들의 이야기를 조금이라도 들어보니 더욱 그러하다는 것을 다시금 알게된다. 인간은 이기적이다. 그러므로 변화를 이끌려면 멱살을 잡아 밖으로 끄집어내야 한다. 기술 전략이 잡는 멱살은 기술로 된다는 것을 증명해주는 것이라고 생각한다. 그리고 현실의 실체에 적용했을 때 도움이 된다는 것을 말이 아니라 결과로 보여주는 것이다. 제대로 된 멱살이 필요하다.

변화는 통합혁신센터장의 몫이 아니다. 그 몫은 회사 전체 구성원이어야 한다. 구성원을 설득해내는 것이 변화를 이니시한 나의 몫이고 멱살을 잡는 것이 내가 이끄는 조직의 몫이다. 하지만 실제 회사의 변화는 모든 구성원의 몫이다. 모든 구성원이 적어도 듣게는 만들겠다. 듣고 본 좋은 것을 어떻게 다룰지는 구성원 본인들이 판단할 몫이다. 참여할지 아니면 살아왔던 그길을 그냥 가실지.

본인들이 살던 길이 맞다고 생각하시는 분들을 억지로 등떠밀 생각은 추호도 없다. 듣고 보고 확인했음에도 하기 싫다면 그들은 그들의 리그에 있으면 그뿐이다. AI가 왜 도움이 되는지 비기술직군에 있는 나는 이해할 수 없고, 왜 써야하는지도 모르겠다는 분들을 설득할 생각은 없다. 이제부터 이해는 각자의 몫이다. 보여준 걸 믿을지 말지, 행동할지 말지만 스스로 결정하면 그뿐이다.

회사가 감당할 몫은 앞으로 더 커질 것이다. 다만 구성원으로 회사의 역할에 각자가 충실한 AI 시대의 1인분 역할을 해주길 기대한다. 변화는 그 인식에서 시작한다.

오른손은 구성원이고, 나는 왼손으로 거들뿐이다.

감자 농사 리더십

Posted by on

누구나 스트레스를 관리하는 방법이 필요하다. 내 스트레스를 내가 풀지 못하면, 내 주변에 풀게된다. 주변에 준 피해는 도돌이표로 나에게 돌아오게 마련이다. 나 역시 번아웃이라는 시기를 겪었고, 스스로의 해소 방법으로 일로부터 도피처를 찾아 텃밭 농사를 짓기 시작했다.

어느 덧 만 4년이 넘는 기간 동안 하다보니 이 땅과 시간을 어떤 방식으로 해볼까를 생각했다. 상추랑 고추로만 채울 수 있는 땅이 아니라 이런 저런 시도를 해봤는데 강원도 특성상 감자가 초보 농사꾼 입장에서 젤 무난하다. 물론 시골에서 자라 중학교때까지 어머니 도와 농사를 했지만, 안한지 30년이 넘은 사람이 할 줄 안다고 이야기하는 건 어불성설이다. 슬프지만 요즘 코딩 안한지 5년 가까이 되가는 관계로 개발자라고 이야기 안하는 거랑 같다. 코딩할 때가 젤 좋은 것처럼 그래도 호미질하고 삽질할 때, 일 생각을 포함해 모든 잡념을 지워주기 때문에 잘 하지도 못하는 농사를 한다.

농사는 안할 때가 젤 좋긴하다. 물론 잡념이 많아지긴 하지만 새소리, 바람소리 듣는 것만으로 힐링된다. 특히 눈 많은 계절이나 비올 때 지붕에 닿는 그 소리가 너무 좋다. 4년 농사를 지어보니 기후 변화를 체감한다. 원래 못짓는 농사긴 하지만 너무 더워져 첫 해 잘 되던 것들이 안되니 말이다. 나만 안되는게 아니라 옆집 할머니 댁도 안된다. 그래서 올해 농사는 감자만 하는 걸로.  어찌됐던 기름값을 쓸거고, 노동을 할 예정인데 뭐라도 얻으면 보람된다. 제대로 된 보람은 먹을 걸 많이 만들어내는데 있으니 기후라는 상황 변화에 대응해야 한다.

뭐든 성장시킬려면 땅이 중요하다. 땅이 척박하면 뭔 짓을 하더라도 안된다. 키울려고 하는 작물의 특징과도 맞아야 한다. 막연히 기름지다고 해서 뭐든 잘 자라는건 아니다. 풀은 예외다. 어디서든 잘 자라니. 기본적인 환경이 준비되야 뭘 기대해볼 수 있다.

거름을 쳤다고 바로 뭘 심으면 안된다. 닭똥, 돼지똥이 주 원료인데 삭혔다고 하더라도 냄새 장난 아니다. 바로 심으면 뭐든 죽여버릴 기세니 몇 일 비바람에 독한 기를 빼야 한다. 이론적으로 좋다는 건 당연한 사실이지만 현실에서 상호 작용이 이뤄질려면 그만큼 융합의 시간이 필요하다. 그렇다고 너무 긴 시간 여유를 두면 영향분이 대지로 흡수되는게 아니라 배수로 타고 흘러나갈 수 있다. 거름을 쳤다면 텃밭 농사꾼은 꼭 다음 주에 와서 땅을 엎어야 한다.

계획된 노동의 시간이다. 땅을 다 갈아엎고 감자를 심을 고랑을 만들어야 한다. 딱 한번 이걸 삽과 괭이로 갈아엎은 적이 있다. 서울로 돌아와 연차내고 앓아누웠고, 병원 통원 치료했다. 무식하면 용감하다는 말을 실천했다. 다음부터는 주변에 농기계를 가지고 계신 어른께 땅을 갈아달라고 부탁드렸다. 그리고 고랑만 내가 원하는 높이와 깊이가 되도록 만들었다. 그리고 잡초는 정말 징글징글하기 때문에 비닐을 친다.

모든 걸 혼자 할 수 없다. 도구를 당연히 써야하고 직접 도구를 쓸 수 없다면 가진 사람에게 부탁하거나 협업해야 한다. 부탁이 될려면 사람과의 관계가 필수다. 좋은 시골 인심은 외지인인 내가 어떻게 하느냐에 따라 달렸다. 당연히 해주겠지? 어불성설이다. 상황에 맞는 관계를 설정하고, 모두에게 좋은 관계를 만들 수 있다면 좋겠지만, 적어도 일의 결과를 달성하기 위한 필요한 관계를 만들어야 한다.

심었으면 다가 아니다. 특히 씨감자를 심어두고 가만히 놔두면 낭패를 본다. 감자는 상대적으로 손이 덜가는 작물이긴 하지만 일주일에 한번씩 다니는 입장에서 심은 후 그대로 방치하면 농사 망친다. 특히 비닐로 덮어둔 상태에서 방치하면 싹이 나오다가 그대로 죽어버리는 경우가 생긴다. 싹이 열린 구멍으로 나오라는 법이 없다.  앞으로 나오기도 하고 옆으로 나오기도 한다. 싹이 나오는 시점에 구멍이 아닌 다른 쪽으로 볼록하면 그쪽으로 더 구멍을 크게 내줘야 한다. 활로가 생기지 않으면 더워지는 계절의 열기를 그대로 받아 타버린다. 잡초 막을려다 감자 자체를 죽일 수도 있다.

조직에 인재를 영입한 경우에도 마찬가지다. 뛰어난 기량과 역량을 갖췄더라도 아직은 조직 안에서 발현되기 전이다. 조직내에 올바르게 정착됐을 때, 인재가 제대로 인재로써 뭔가를 보여줄 수 있다. “꽂아놨으니 님이 알아서 해야지!” 라는  것은 인재를 대하는 일종의 방임이자 방치다. 조직 시스템에 잘 융화되는지 살펴야하고, 폭넓은 결과를 만들기 위해 필요하다면 체계를 변경할 수 있어야 한다. 기존 틀을 바꾸지 못하면 결과를 만들 인재가 고사하는 경우가 나온다.

어느 정도 감자가 자라기 시작하면 종종 들여다봐야 한다. 감자를 얼마만큼 얻고 싶냐? 라는 생각에 따라 해야 할 일의 양이 달라진다. 작년에 생각보다 적게 나와서 두루 사람들에게 보내줄 양이 적었었는데, 올해는 나누는 기쁨을 좀 더 갖고 싶었다. 그럼 잡초를 뽑아야 한다. 아무로 비닐을 쳤다고 하더라도 고랑 사이로 난 잡초의 성장 속도는 어마무시하다. 이놈들이 햇빛을 가린다. 그리고 비닐 사이로도 잡초가 삐져나온다. 감자가 가져가야 할 영양분을 이놈들이 뺏아간다. 종종 보면서 눈에 거슬리는 놈들을 뽑아줘야 한다.

조직에도 항상 잡초같은 존재들이 있다. 조직이 가지고 있는 자양분이 성과를 위해 쓰이는게 아니라 개인의 이익 혹은 기득권을 지키기 위해 사용한다. 조직이 추구할 결과를 위해 써야 할 거름이 엉뚱한 곳으로 흘러간다.  심지어 도전하는 동료를 얽어매 비틀기도 한다. 관성이라는 가시로 칭칭 동아매 새로움에 대한 도전을 원천 봉쇄하기도 한다. 그리고 썩은 사과가 되어 주변을 오염시킨다.

회사의 방향에 결을 맞춘 리더라면 당연히 이런 잡초들을 식별하기 위해 노력해야 하고, 분리하거나 뽑아내야 한다. 간혹 감자밭에 다른 작물이 섞이는 경우가 있다. 감자를 키울거면 감자를 키워야 한다. 아무리 좋은 인재라고 하더라도 그 인재가 조직이 추구하는 방향과 결과 도출에 맞지 않는다면 다른 곳에서 역량을 발휘할 수 있도록 도와야 한다. 그래야 리더와 조직이 온전히 조직의 목표에 집중할 수 있다.

올해 수확은 겨울과 봄에 기대했던 만큼은 아니지만 오랜 봄가뭄 때문에 완전 망했다 싶은 예측을 뛰어넘는 어닝 서프라이즈다. 텃밭 농사의 가장 큰 기쁨인 가족과 지인들에게 나눌 수 있을 만큼의 수확이고, 남은 찌그러기가 아닌 온전한 감자 몇 알도 챙겨갈 수 있을 양이다. 당분간은 감자 샐러드가 아침이고, 저녁은 삶은 감자이며 주말 특식은 감자전과 닭볶음탕이다. 극강의 더위와 가뭄이라는 어려움이 있었지만, 목표했던 수확을 할 수 있어서 기쁨이 두배되는거 아닌가 싶다.

그냥 사먹는게 훨 싼거 아니냐… 당연히 나올 말이다. 하지만 이건 감자 먹을려고 농사를 짓는것으로 의미를 해석하는 사람이다. 어림잡아 백만원 넘게 투자해서 감자 10박스를 얻었는데…

조직, 그리고 더 큰 조직인 회사는 추구해야 할 목표와 결과가 있다. 내가 속한 조직이 만드는 결과의 의미가 궁극에는 상위 조직, 그리고 더 큰 상위 조직에 목표와 결과에 도움이 되야 한다. 감자 농사, 텃밭 농사로 내가 얻는 것은 아무 생각도 안하는 것이다. 땀 흘리는 그 사이에는 정말 아무 생각도 없다. 생각을 비우면 아예 새로운 생각이 머리 속을 채운다. 아하, 왜 그 생각을 못했을까? 새롭게 채워진 생각을 가지고 다시 도시로, 회사에 돌아온다.

벡만원을 투자한 감자 10박스는 Local Maximum 결과다. 하지만 현재 회사에서 진행하고 있는 기술 전략과 실행은 몇 백억, 몇 천억을 좌지우지한다. 백만원 투자해서 회사가 몇 백억 단위의 결과를 얻을 수 있다면 당연히 해야한다고 생각한다. 이것이 Global Maximum을 추구하는 마땅한 시니어 리더십의 자세라고 믿는다.

항상 고민한다. 내가 추구하는 것이 나 자신만을 위한 Local Maximum인지 조직과 회사, 그리고 사회를 생각하는 Global Maximum일지. 허무맹랑하지만 꿈이 북극성처럼 내가 가야 할 길을 밝히고 있다. 오늘도 이 길을 간다.