필자인 양준하는 2023년부터 2026년까지 2년 7개월간 하이퍼리즘 CTO/CISO로 재직하였음

• 하이퍼리즘은 60명 규모의 암호화폐 트레이딩 회사고, 그중 10-20명 규모의 개발조직을 운영해왔었음
• 하이퍼리즘에는 퇴사자가 본인의 회사업무를 정리해서 블로그로 쓰고 나가는 문화가 있음
• 웃기게도, 내가 만들자고 해서 생긴 문화인데 벌써 차례가 와버렸음
• 재직 기간에 있었던 CTO로서의 다양한 챌린지들과, 거기서 추출할 수 있었던 인사이트를 솔직하게 소개해보겠음

1. 테크 리딩

기술적 의사결정

• CTO의 삶은 기술 스택, 인터페이스 결정, 아키텍처 설계 등등 정답이 없는 선택들의 연속임
• 이런 기술적인 의사결정은 생각보다 매우 큰 스노우볼이 되곤 함. 조직이 반년 동안 삽질만 하고 코드베이스를 전부 갖다 버리게 될 수도 있음
  • 필자도 암호화폐 거래소와의 네트워크 시스템을 과추상화하는 실수를 하면서 이러한 실패를 경험해봤고, 그 과정에서 증발한 맨먼스는 두 자릿수였음
• 특히 인프라는 비용·보안·락인·생산성 등에 미치는 영향이 매우 큰 영역이라서, 단순히 코드 구조나 라이브러리를 잘못 선택한 것에 비해 타격이 더 크고, 뒤늦게 바꾸는 것은 지옥임
  • AI 시대에는 더더욱 그러함. 코딩 에이전트를 사용하다가 주로 만나는 병목은 구독·배포·인증인가·연결성·관측가능성 등 인프라 관련이었음
  • 입사 초에 인증 레이어와 RPC 프로토콜을 잘못 정한 적이 있었는데, 지금은 아주 고약한 레거시가 되어버렸고, 최근까지도 팀원의 원망(?)을 가끔 듣고 있음
• 자주 만났던 결정장애의 패턴은 1) 오픈소스 사용 2) SaaS 사용 3) 직접 구현 셋 중 하나를 선택해야 하는 상황이었음
  • 필자의 경우 3을 과하게 많이 선택했었음. 당시 필자는 경험이 부족한 CTO였기 때문에 직접 써보지 못한 스택들에 대해 본능적으로 공포감이 들었고, 예측가능하고 컨트롤가능해 보였던 (물론 실제로는 전혀 그렇지 않았다) from-scratch를 선택했던 것 같음

사례기반의 사고법

• 따라서 의사결정들의 80퍼센트 이상은 구체적인 유사사례를 기반으로 해야 함
  • 이런 경험주의적 방식은 혁신을 만들기 어려울 순 있으나, 적어도 크게 망하진 않음
  • 특히 다음과 같은 상황에선 꼭 사례기반 의사결정을 고수해야 함
    1. 일정이나 퀄리티 달성 실패에 대한 리스크가 매우 큰 상황
    2. 기술이 비즈니스의 핵심이 아닌 상황
    3. 테스트나 평가가 안 되는 추상적 가치를 최적화해야 하는 상황 (보안, UX 등)
• "직관의 함정"에 자주 빠졌던 필자는, 회사에서 의견을 말할 때마다 "이를 서포팅하는 과거 사건을 슬랙에서 최소 1개는 찾아오자"라는 나만의 규칙을 시도했음
  • 회사 슬랙 트래픽이 상당히 많았는데, 관련 사례를 단 1개도 인용할 수 없는 아이디어가 유효하긴 어려울 것이기 때문임
  • 이는 간단하지만 효과적인 필터링이었고, 과거 사례로 시장의 행동을 예측하는 것 자체가 업무인 트레이더들에게서 공통적으로 관찰하고 배울 수 있었음
  • 위 사고법을 거치면서 MBTI의 N 수치가 소폭 하향되기도 했음(?)
• 시니어리티라는 것은 결국 문제 상황이 주어졌을 때 적절한 레퍼런스나 과거 유사 케이스를 빠르고 잘 생각해낼 수 있는 능력인 것 같음
  • ChatGPT 딥리서치를 시도해보더라도, 실제 회사들이 내부에서 어떻게 일하는지는 프라이빗한 정보일 때가 많아서 퍼블릭 데이터 크롤링에 기반한 "AI 딸깍"으로 대체하기에는 높은 장벽이 있음
• 이런 수많은 결정들을 본인이 직접 할 수 있으면 제일 좋지만, 유능한 시니어 엔지니어를 두고 "전회사 이야기"를 자주 청취하는 것만으로도 큰 도움이 됨

조직의 성숙도

• 팀원이 납득하지 못하는 기술적 결정은 매우 높은 확률로 틀렸다고 봄. 팀원들이 납득하지 못했다는 것은 1) 본인이 틀린 생각을 하고 있거나 2) 설명을 제대로 못했거나 3) 팀원들의 수준이 낮다는 거임
• 결국 셋 다 본인 문제임. 3)에 대해 더 이야기해보자면...
  • 교육과 성장은 회사 입장에서 ROI가 불명확한 투자임
  • 특히 개발자들을 기술적으로 교육한다는 것은, 그들을 앉혀놓고 강의를 설파하거나 어떤 프로그램을 이수하게 하는 것이 아니라, "적절한 주니어:시니어 비율을 유지"하는 인적 구성으로써 실현될 때가 많음
  • 그래서 시니어를 레퍼런스체크할 때에는 "이 사람이 팀에 교육적인 기여를 어떻게 했나요?"를 꼭 물어봤었음
  • 지극히 Individual Contributor 성향의 엔지니어라도, 교육과 문화에 있어서는 Influential Contributor일 수 있음. 필자는 그런 사람을 좋아했음
    • 팀에 주기적인 회고를 꼭 해야 한다고 주장하여 조직에 정착시킨 엔지니어도 있었고, 회사에 암호학 스터디를 열어 점심시간마다 돌아가면서 논문리딩을 한 엔지니어도 있었음
  • 어쨌든 시니어 엔지니어를 적절히 팀에 혼합하는 건 상당히 비싸고 복잡한 문제이기에, 여기에 필요한 드라이브를 걸 수 있는 사람은 CTO임
• 시니어 채용과 별도의 방법으로, 회사 슬랙에 "개발 잡담 채널"을 만들어서 일종의 사내 개발자 커뮤니티를 조성하고, 한두 달에 한 번씩 모든 엔지니어를 불러놓고 자유로운 주제로 기술세미나를 돌아가면서 하게 해봤음
  • 교육적 효과가 대단했냐? 하면 그건 아니지만, 서로 해커뉴스와 레딧에서 본 재밌는 POV를 공유하는 것만으로도 자극과 관점의 전환에 도움이 됐음
  • 지금도 사내 개발 커뮤니티에 메시지가 매일 몇십-몇백개씩(?) 올라옴. 적어도 새로운 기술적인 주제에 대해 토론하고 탐구하는 분위기는 잘 갖춘 조직을 만들었다고 생각

2. 매니징

팀간 협업

• 엔지니어들은 보통 "잘 정의된 문제"를 해결할 때에 제일 만족스러워하고, 퍼포먼스도 가장 높음
• 문제를 잘 정의하는 걸 어렵게 만드는 제일 흔한 이유는 예측하기 힘든 우선순위의 변화임
• 우선순위는 항상 바뀌는 거지만, 예측 불가능한 변화는 보통 다른 팀에서 유발되는 경우가 많음
  • 팀간 커뮤니케이션을 실무자들끼리 하면 결국 표면적으로만 해결되고 근본적인 비효율은 그대로 남을 때가 많음
  • 제일 많이 본 패턴은 "애드혹한 요청을 하는 타팀"과, "그걸 애드혹하게 해결하는 우리팀"이 만나는 환장의 조합이었음
  • 다른 팀에서 산발적으로 들어오는 요청들은, 모아놓고 보니 "적당히 확장가능한 스키마를 가진 신규 데이터베이스와 CRUD 서비스를 만들어주세요" 정도로 환원가능한 문제였음
    • 그러나 맥락 없이 그때그때 계속 반영해온 우리팀은 결국 정체불명의 누더기 API를 짊어지게 됐음
• 조직장인 CTO는 다른 팀에 대한 이해도를 갖추는 데 투자를 많이 하고, "본인만이 할 수 있는 일", 즉 하이레벨한 팀간 코디네이션을 통해 회사 전체의 생산성을 유지해야 함
• 그 외 디테일한 팀내 데일리 태스크에 대한 매니징을 본인이 직접하는 것은 팀이 6명 이하일 때나 가능할 듯함

치타와 독수리

• 실무 엔지니어와 중간 관리자들은 기본적으로 "치타형 시야" 속에서 몰입하지만, 그동안 CTO는 "독수리형 시야"로 팀원들이 생각하지 못했던 기회를 발굴해내는 게 중요함
  • 중간 관리자가 잘 해낼 수 있는 일은 execution의 퀄리티와 효율을 높이는 것임
  • CTO는 그 execution이 지금 시점에서 과연 가치가 있는지, 가짜노동은 아닌지, 아예 그만두고 다른 걸 해야 하는 건 아닌지 등 메타적인 관점으로 비판적인 사고를 해야 함
• 큼직한 방향성 변화는 큰 매몰비용을 만들어냄. 매몰비용을 가차 없이 감수하고 제일 높은 기댓값을 찾는 드라이브는 CTO가 해야 하는 일임
  • 중간 관리자는 관성과 경로의존성 속에서 성숙도를 만들어내는 사람임. CTO는 "중간 관리자가 할 수 없는 일"에 집중해야 함
  • 하이퍼리즘은 "유기"라는 용어를 밈화하여 사용하곤 했음. 프로젝트를 "유기"하고, 태스크를 "유기"하고, ...
    • 결국은 기댓값 최적화를 위한 "손절"을 일상적이고 필연적인 것으로 받아들이자는 배경에서 나온 용어가 아닐까 함
    • 트레이딩 회사인 만큼, 매몰비용을 감수하는 데에 있어서 냉정할 필요가 있었기도 하고
• 하던 것을 고수하는 게 맞다고 판단했더라도, 그 방향성을 팀원들이 잘 납득하고 있는지 온도체크를 해야 함
  • 필자가 팀 초창기에 1on1 과정에서 제일 많이 들었던 코멘트가 "내가 하고 있는 엔지니어링이 과연 임팩트가 있는지, 어떻게 쓰이는지 잘 와닿았으면 좋겠다"였음
  • 치타는 뒤를 돌아보는 순간 속도가 급격하게 느려짐. CTO는 치타가 뒤돌아보지 않고 몰입할 수 있도록 해줘야 함
  • 간단한 예시로, 다른 팀과의 회의에서 가볍게 나온 칭찬을 기억해놨다가 "오늘 다른팀 XX님이 말하던데, YY님이 만든 그 기능 정말 좋다고 하더라고요"라고 말해주곤 했음
    • 이런 사소한 모티베이션도 실무자들의 몰입에 큰 도움이 됨

위임의 미학

• 수많은 컨텍스트 스위칭의 굴레에서 벗어나기 위해 매번 위임을 하려고 다짐하지만, 자주 만났던 근본적인 보틀넥은 "중간 관리자의 부족"이었음
• 중간 관리자를 건너뛰고 개별 실무자에 직접 위임을 하자니 복잡한 비즈니스 컨텍스트와 배경을 설명하는 것부터가 큰 코스트였고, 실무자가 스스로 "태스크의 완성조건"을 판별할 수 있도록 좋은 기준을 제시해주는 것도 어려웠음
• 따라서 아무리 팀이 커도 유능한 중간 관리자가 없으면 위임을 하고 싶어도 할 수가 없었음
• 신규 채용으로 해결할 수도 있었겠지만, 필자가 이를 해결하기 위해 가장 먼저 했던 일은 팀에 있던 3개의 셀을 합병/분할하여 5개의 셀로 더 잘게 나누는 것이었음
  1. 잘게 쪼개면서 일단 중간 관리자의 슬롯 자체가 늘어나게 됨
  2. 실무자였던 사람이 중간 관리자를 새로 맡게 되면서 장기적으로 육성의 기회를 얻음
• 팀에서 가장 크리티컬한 버스팩터의 라인업을 구성하는 사람들은 대부분 중간 관리자들이었음
  • 채용에만 의지하기에는 리스크가 큼. 모르는 사람의 "관리자 역량"을 평가하는 것은 상당히 까다롭기 때문 (기술력이나 커뮤니케이션 능력 등을 평가하는 것에 비해서)
  • 따라서 CTO는 일부러라도 순환해서 관리자 경험을 시켜보는 장기적인 육성 파이프라인을 운영해야 함

3. 인사 및 채용

팀원들과 소통하기

• 최소 분기에 한 번씩은 주요 팀원들과 1on1을 해야 함
  • "3개월"은 인사에 있어서 마법의 기본 단위와 같은 숫자임
  • 어떤 포지션을 새로 채용하려면, 회사 입장에서는 1개월간 소싱 → 1개월간 평가 및 협상 → 1개월간 인수인계 및 입사 대기까지 총 3달 정도의 시간이 필요하기 때문임
  • 따라서 주요 인력의 퇴사리스크는 적어도 세달 전에는 아는 게 좋고, 그렇기에 세달마다는 1on1을 해봐야 하는 것임
• 경험상 1on1의 제일 큰 효능은 "문제의식"을 끄집어내는 것임
  • 조직에 대한 심각한 회의감, 퇴사에 대한 고민, 지속되는 스트레스 등은 일상적인 상황에선 쉽게 고백하지 않음
  • 신기하게도 많은 문제들은 그 자리에서 즉석으로 해결할 수 있었음
    • "이번 프로젝트가 끝나면 X팀에서 한번 파일럿으로 일해보실래요?", "모르셨겠지만, 사실 옆 팀에서 Y이슈가 크게 터져서 이 태스크를 급하게 부탁드리게 된 거였어요" 등 팀원이 모르거나 생각해보지 못했을 법한 관점과 정보들을 제시하는 것만으로도 꽤 큰 완화를 할 수 있었음
  • "문제"보다 더 나쁜 것은, 문제가 있는지조차 파악하지 못하거나, 문제가 아닌 것을 문제라고 잘못 인식하도록 방치하는 것임
  • 1on1은 CTO나 개발조직을 넘어 회사나 경영진에 대한 피드백을 말할 수 있는 사실상 유일한 기회기도 함
    • 필자는 "당신의 메시지는 (원한다면) 왜곡 없이 경영진에게 바로 전달된다"라는 신뢰를 주기 위해, 1on1 노트를 해당 팀원에게 건네고 자유롭게 첨삭할 기회를 준 이후에 그대로 경영진에게 공유했었음
• 조직원들에게 내년도 기본급을 어떻게 줘야 할지를 매주 고민해보는 것이 좋음
  • 그 결과는 1) 본인의 기대치와 비교했을 때 fair하고 2) 사내에서 비교했을 때 fair하고 3) 시장과 비교해서 fair해야 함. 즉 어려운 고차원 방정식임
  • 결론적으로 모든 사람들이 기본급 통보를 받았을 때 "딱 예상대로"라고 느끼는 게 최적해였던 것 같음
  • 실망하는 사람이 있으면 기대 컨트롤을 잘못한 것임. 저성과자에게는 지속적으로 피드백을 했었어야 하고, 성과와 보상에 대해 합리적인 예측치를 가질 수 있도록 1on1에서 계속 싱크를 해 왔었어야 함
  • 이런 사회적 스트레스와 설득의 코스트를 지속적으로 회피하다가 마지막에 인사팀에게 "통보"를 부탁하게 되면, 갑작스러운 퇴사리스크를 예측하고 관리할 수 있는 제일 쉬운 기회를 버리는 것과 마찬가지임
• 상급자일수록 메타인지 기회가 부족하고, CTO 본인도 피드백을 받아야 함
  • 필자는 모든 1on1에서 "나에 대한 의견"을 의무적으로 청취하고, 그 의견이 뭐가 됐든 위에서 말했듯이 경영진에게 그대로 공유하는 원칙을 지켜왔음
  • "다 좋으신 것 같아요"라고 대답하는 팀원에게는 "그럴 리가 없지 않느냐?" 하면서 집요하게 추궁(?)하기도 했음
  • 한때는 완전한 익명 셋업의 구글폼으로 피드백을 받아본 적도 있는데, 5퍼센트라는 처참한 응답률을 보였지만 그 소수의 응답만으로도 관점의 전환을 할 수 있었음

개발조직 브랜딩

• 말주변이 부족하거나, 네트워킹을 기피하는 사람은 CTO에 적합하지 않을 수도 있음. 인재 소싱에 한계가 있기 때문
  • 간단하게는 링크드인 글 같은 것이라도 잘 써야 함. 짧고 굵고 자극적으로 회사 개발조직에 대한 이미지를 전달할 수 있는 PR 능력이 있어야 함
  • 필자의 경우 질 좋은 개발자들을 만나기 위해 대학교 취업설명회, 코딩대회 후원, 링크드인 콜드메시지, 대학교 동문행사, 업계 컨퍼런스, 오픈소스 프로젝트 등 상당히 다양한 걸 시도해봤음
  • 그곳에서의 내 발언들이 회사의 이미지와 미래 지원 가능성을 결정한다고 생각하면, 즉흥적인 사교/전달능력이 중요할 수밖에 없음
• 이런 활동들의 최종적인 목표는 단순히 아웃바운드 소싱이 아닌 "브랜딩"이라고 보는 게 맞을 것 같음
  • 경험상 훌륭한 채용의 80퍼센트는 인바운드였던 것 같음 (심지어 스팸 메일함에서 운 좋게 발견하여 리드 엔지니어를 채용한 케이스도 있었음)
  • 이건 B2B 영업과 비슷함. 높은 인재밀도를 유지하고 싶으면 종착역은 아웃바운드에 계속 시간을 쓰는 것이 아니라, 브랜딩과 인바운드가 일어나도록 만드는 것임

개발자 채용하기

• 20명 미만의 개발팀이라면, 레퍼런스체크는 무조건 직접해야 함. 한번 채용하면 내보내는 건 꽤나 고통스러운 과정임. 그 책임은 본인이 져야 하고, 그렇기에 본인이 직접 평가해야 함
  • 레퍼리 입장에서도 상대방이 HR팀보단 CTO일 때 더 솔직하고 디테일하게 응답할 확률이 높음
  • 사전에 준비된 레퍼리라고 해도 "A님이 해줬던 제일 인사이트풀한 코드리뷰가 뭐였나요?" 같은 갑작스러운 질문에는 "음..."하고 고민해보다가 머릿속에 생각나는 이야기를 그대로 할 수밖에 없음. 이런 구체적인 에피소드를 즉석에서 지어낼 수는 없기 때문
  • 시니어 엔지니어의 경우 동의하에 6-7명에게 한 명당 30분씩 전화로 레퍼런스체크를 했었음. 경험상 레퍼런스체크는 서류평가, 면접평가, 과제평가를 전부 합친 것과 비슷하거나 조금 더 많은 정보의 가치를 지녔음
• 훌륭한 에이스라면 CTO가 직접 버선발로 나가야 함. 커피챗 단계부터 회사의 비전과 매력을 어필해야 함. 에이스 엔지니어를 채용하는 것은 인사팀도, 대표도, 테크리드도 아닌 CTO가 나서야 제일 효과적임
  • 모르는 회사로부터의 영입제안은 "의사결정권자"이자 "미래의 옆자리 조직장"이 하지 않는 이상 와닿기 힘듦
    • 어디까지 정보와 카드를 오픈할지를 즉석에서 책임지고 결정할 수 있는 사람만이 매력적인 대화를 이끌어나갈 수 있기 때문
  • 필자는 주로 그 자리에서 폰을 꺼내서 회사의 슬랙채널을 보여줬음. 회사의 조직문화와 분위기를 직접 보고 판단하라는 의미에서
  • 회사를 나오기 전 마지막으로 채용한 시니어 엔지니어의 경우 컨택/소개/평가/레퍼런스체크/오퍼/협상의 전 과정이 1년 걸렸고 모두 직접 수행했었음

4. 회사 경영

기술 PR

• 경영진들에게 엔지니어링 조직, 특히 프로덕트랑 떨어져있는 인프라 조직의 퍼포먼스와 기여를 와닿게 납득시키는 것은 쉽지 않음
• 역시 "사례기반"의 커뮤니케이션을 하는 게 중요함. 총론적으로, 탑다운으로 이야기하면 결국 기술이해도가 없는 다른 사람의 입장에서는 1) 너무 피상적이거나 2) 너무 기술적이거나 둘 중 하나일 수밖에 없음
  • 예를 들어 필자의 개발조직은 분기별 타운홀마다 회사 인프라에서 호스팅되고 있는 논리적인 비즈니스 로직 (트레이딩 전략)의 개수나 관리/모니터링되는 지갑의 개수 등을 취합해서 공유하곤 했음
  • 여전히 경영진에게는 추상적인 숫자일수도 있지만, 그 숫자들이 비즈니스적인 개념들과 어떠한 대응관계가 있고, 뭔가 시간에 따라 성장하는 추세를 보이고 있다는 수준만 이해할 수 있어도 "약한 끄덕끄덕" 정도는 이끌어낼 수 있었던 것 같음
  • 다른 예로 보안 인프라의 중요한 변화사항이 생길 때에는, 이게 왜 기술적으로/구조적으로 더 뛰어난지 설명하는 것보단, 그냥 이걸 안 했을 때 당할 수 있는 해킹의 과거 실제 사례를 소개해주는 게 편할 때가 많았음
• 회사 밖의 업계 사람들 혹은 잠재적 투자자/고객들에게 "저 회사는 그래도 기술에 뭔가 있구나"하는 이미지를 만들어주는 것도 꽤나 중요한 업무임
  • 이는 본질적으로 앞서 언급한 브랜딩에 대한 기여임
  • 1년에 한두 번씩은 외부 행사나 컨퍼런스에서 회사가 속한 산업 (블록체인)의 기술적인 트렌드에 대해 종종 발표하곤 했었음
  • 강연의 내용은 회사가 실제로 하는 일이 아닌, 산업 내 특정 주제에 대한 기술적이고 중립적인 내용이었음
    • 어쨌든 사람들은 "저런 재밌고 신기한 내용을 다룰 수 있는 CTO가 있는 곳"으로 기억한다는 것이 중요함
  • 필자는 아직도 "작년에 그 강연 너무 잘 봤었다"는 인사로 나한테 말을 건네오는 사람들을 가끔 만남

기술적 비전

• CTO가 설정하는 "우리 조직의 기술적 비전"은 생각보다 팀원들 사이에서 자주 인용됨
  • 필자의 개발조직 같은 경우에는 회사 특성상 외부에 서비스할 프로덕트를 만드는 게 아니라, 사내 직원들의 트레이딩과 재무를 돕는 거대한 생산성 플랫폼을 만드는 것에 가까웠음
    • 따라서 "우리는 거대한 데브옵스가 되어야 한다"라는 방향성을 자주 말하곤 했음
    • 이는 구체적인 비즈니스 유틸리티보단, 비개발자(트레이더)들이 LLM의 수혜를 입어 "딸깍 코딩"으로 원하는 걸 알아서 할 수 있는 환경 자체를 조성하는 데 집중하자는 의미였음
  • 이런 내러티브는 모티베이션을 위한 구호로도 좋은 거지만, 데일리 의사결정에서도 자주 사용되곤 했음
    • 예를 들어, 실무자들이 인터페이스의 고수준 ↔ 저수준을 고민해야 하는 상황에선 보통 후자를 일관되게 선택했음
    • "우리는 복잡한 비즈니스 로직 핸들러를 만드는 게 아니라, Configurable한 플랫폼을 지향해야 하지 않을까?"와 같은 생각에 기반한 거였음
  • 이런 현상이 반복되다 보면, 결국 타 팀의 입장에서 개발조직이 "예측가능"해진다는 좋은 성질이 생김
    • 새로운 요구사항을 우리 팀에 전달한 후에 "이걸 3주 뒤에 어떻게 완성해올까?"에 대한 합리적인 기대나 예측을 할 수 있게 되면서 커뮤니케이션 코스트를 줄일 수 있음
    • 반대로 개발팀 입장에서도, 까딱 잘못해서 특정 비즈니스 로직에 과최적화된 가젯을 갖고가면 "아니 우리회사 개발조직의 역할은 이게 아닐 텐데요?"라는 피드백이 준비되어있다는 것을 예상할 수 있음
• 치타들은 정답이 없는 고민 상황에서는 결국 CTO가 적어놓은 "우리 개발조직의 목표"의 마지막 버전을 뒤적뒤적 찾아보며 결정의 근거로 사용함
  • CTO가 설정한 비전은 그저 위키 첫페이지에 넣어놓기 위한 추상적인 구호가 아니라, 실무자들의 데일리 의사결정에서 인용되는 임팩트있는 소스가 된다는 점을 알고 있어야 함
  • 필자는 잊을 만하면 중간 리드급들로부터 "조직의 개발 방향성이 슬슬 Outdated된 것 같다"라는 피드백을 들었고, 그걸 중대한 위기감지 지표로 삼았었음

조직적 메타인지

• C레벨 한 명의 스타일이 해당 조직 전체의 분위기나 사고방식을 결정하곤 함
  • 그렇기에 내가 빌딩한 팀이 객관적으로 뛰어난지, 아니면 그냥 내 눈에 보기 좋은 인형들인지 편향 없이 메타인지하는 건 생각보다 트리비얼하지 않음
• 본인의 개발조직을 지금 당장 통째로 포장해서 시장에 내놓으면, 냉정하게 비용대비 매력적인 팀으로 보일까?와 같은 사고실험을 가끔씩 해보는 게 좋음
  • 반대로 우리 개발자들이 어디 밖에 가서 자부심 갖고 "나 여기 개발자야" 할 수 있을지를 생각해보는 것도 필요할 것임
• 모든 회사가 스타개발자들을 데리고 기술기반 경영을 해야 하는 건 아니지만, 적어도 Principle과 체계는 확실하게 갖고 있어야 함
  • 필자는 랜덤한 커피챗에서 만난 매력적인 시니어 개발자가 "여긴 개발팀 분위기나 수준이 어떤지 궁금해요" 하고 물어보더라도, 바로 회사의 위키나 이슈트래커를 꺼내서 우리가 일하는 방식을 보여주는 것에 거리낌이 없었음
  • 의외로 구직자들은 팬시한 개발방법론이나 화려한 인프라스택보다, "조직이 합리적인 의사결정방식을 가지나?", "코드리뷰는 누가 해주나?"와 같은 기본적인 것들에서 먼저 안심을 느끼는 것 같았음
• Principle을 확보했으면, 그 다음은 시대 변화 속에서 우물 안 개구리가 되지 않도록 노력해야 함
  • 타사의 기술 블로그를 읽어보고, 다른 회사 개발자나 CTO와 커피챗을 하는 것은 시간 내어 해야 할 투자이고, 메타인지 타임을 가지기 좋은 기회들임
• 예를 들어 필자는 2024년 10월 경부터 사내에 풀타임 에이전트 개발자를 채용해서 사내지식베이스에 연결되어있는 코딩 에이전트를 만들어야 한다고 주장했음
  • 그 과정에서 POV 구체화에 큰 도움이 된 것은, 우연히 알게 된 AWS 출신의 시니어 엔지니어가 Windsurf를 당장 도입하지 않으면 안 된다면서 몇 시간에 걸쳐 설명을 해준 사건이었음
  • 아직 "바이브코딩"이라는 단어도 생기기 전이었지만 당시 필자는 큰 FOMO에 휩싸여 해외 커뮤니티를 찾아보며 최신 코딩 에이전트들에 대해 공부를 시작했음
  • 밖에서 만나는 개발자들마다 "코딩 에이전트가 뭔지 아냐"고 물어보고, 조직에서 시도하려는 새로운 아이디어들을 설명하며 반응을 테스트해봤었음
  • 또한 사내 지식베이스에 연결되는 RAG 솔루션을 도입하려고, 당시 최신 실리콘밸리 회사들의 세일즈팀에 무턱대고 연락하여 인트로 콜을 해보기도 했음
    • 2025년 초 당시에 RAG 솔루션을 만드는 회사들은 어찌나 그리 바빴는지, 나같이 돈을 내고 쓰겠다는 고객도 지인 레퍼럴을 받기 전까지는 콜은커녕 답장조차 받지 못하는 상태였음
    • FOMO에 빠져있던 필자는, 다른 회사의 AI 도입 현황을 꼭 알아내고 싶었기에 힘들게 뮤추얼을 찾아내어 겨우 콜을 성사시켰음
    • 결국 이런 일들을 했던 이유는 "우리 조직이 혹시 갈라파고스 상태인가?"라는 위기감 때문이었던 것 같음
  • 이러한 외부 탐색에 대한 노력 덕분에, 하이퍼리즘은 국내에서 조직 차원의 바이브코딩을 상당히 빠르게 시도한 얼리어답터 중 하나였고, 현재도 높은 AI 리터러시를 갖추고 있다고 생각함

마치며

다행히 하이퍼리즘을 나오는 과정에서 훌륭한 후임 CTO를 채용할 수 있었음

• 특이하게도 반년 동안 회사에서 후임자와 공존했었는데, 새로운 CTO가 새로운 방식으로 기존 조직을 핸드오버 받는 과정을 직접 오래 관찰할 수 있는 진귀한 기회였음
  • 이 과정은 나 스스로를 성찰하고 객관화하는 밀도 높은 시간이었고, 그래서 이런 글을 쓸 수 있게 된 것이기도 함
• 위에서 설명한 다양한 챌린지들에 대해 후임자와 대화해보니, 역시 공통의 깊은 공감대가 있었음

하이퍼리즘은 워낙 특이한 도메인과 인적구성을 가진 회사라, 여기서의 경험이 다른 데서도 통용될지는 솔직히 잘 모르겠음

• 역설적으로, 글에서 여러 번 강조한 "사례기반"을 실천하기에는 필자는 여전히 경험이 부족한 초짜 CTO이기에 결국 이 글은 한 회사에서의 경험에 기반한 것임
• 거기다가 지금은 대 AI의 시대인 만큼, 근미래에 개발조직의 통상적인 모습과 최적해가 엄청나게 바뀔 거라고 예상함
• 그럼에도 불구하고 적어도 몇 가지 핵심적인 원칙들은 교훈삼아 읽어볼 가치가 있었길 바라겠음