직접 조영호 개발자님을 우아한테크코스 캠퍼스에 초청하여 강연을 준비하고, 강연을 들으면서 정리한 내용을 작성합니다.
어느 개발자의 성장 일기: 조영호 개발자님 특강을 듣고
『오브젝트』와 『객체지향의 사실과 오해』의 저자이신 조영호 개발자님(현 Alfred AI Native Engineer)을 초청하여 강연을 들었습니다. 이번 시간은 단순히 최신 기술의 트렌드를 쫓는 이야기가 아니었습니다. 1983년부터 지금까지 굵직한 기술 패러다임의 변화를 온몸으로 겪어온 한 선배 개발자의 생생한 '성장 일기'이자, 후배들을 향한 묵직한 조언이었습니다.
변화의 시기, 열린 마음으로 적응하기
영호님께서는 끊임없이 변화하는 IT 생태계 속에서 '적응'의 중요성을 강조하셨습니다. 특히 지금 우리가 맞이한 변화가 역사상 세 손가락 안에 꼽힐 만큼 거대하다고 말씀하셨는데, 저 역시 현재의 변화가 제 개발 여정에 있어 가장 큰 파도로 다가오고 있다고 생각합니다.
변화의 시기를 맞이하는 자세에 대해 영호님은 "내가 저것까지 알아야 해?"라며 거부하기보다는, 열린 마음으로 받아들여야 한다고 당부하셨습니다. 저 또한 변화를 수용하지 못하면 도태될 수밖에 없다고 굳게 믿고 있기에, 동료들이 '함께 일하고 싶은 오픈 마인드를 가진 개발자'로 성장하기 위해 늘 다짐하고 있습니다.
순수했던 열정, 그리고 첫 발걸음 (1983~1997)
컴퓨터가 귀했던 영호님의 어린 시절, 친구 집에서 처음 접한 게임은 그를 컴퓨터의 세계로 이끌었습니다. 게임을 하기 위해 컴퓨터 학원에 등록하셨다는 이야기를 들으며, 저 역시 초등학교 방과 후 수업 시간에 자격증 공부를 핑계 삼아 게임을 즐겼던 추억이 떠올라 깊이 공감했습니다.
영호님이 학원에서 처음 배운 언어는 'MSX BASIC'이었습니다. 머릿속으로 생각한 명령어가 화면에 직관적으로 구현되는 재미에 푹 빠지셨다는 말씀을 들으며, 저의 첫 프로그래밍 경험을 되돌아보았습니다. 제 첫 언어는 대학교에 입학하며 배운 '자바(Java)'였습니다. 처음엔 낯선 문법들이 어렵게만 느껴져 영호님처럼 즉각적인 재미를 느끼진 못했습니다. 게다가 다른 수업에서 파이썬(Python)을 병행하며 혼란을 겪기도 했습니다. 여러 언어를 접해봤지만, 여전히 저에게는 자바가 가장 익숙하고 편안합니다. 제가 처음으로 프로그래밍의 직관적인 재미를 느꼈던 순간은, 자바를 묵묵히 파고든 끝에 '스프링(Spring)' 프레임워크를 배우면서부터였던 것 같습니다.
이후 국민학교 졸업 선물로 첫 개인 컴퓨터를 갖게 되셨지만, 저장 매체가 없어 주말마다 긴 코드를 처음부터 다시 타이핑해야 했다고 하셨습니다. 애써 작성한 코드가 날아가는 허무함 속에서도 포기하지 않고 끈기 있게 코딩을 이어가신 모습에서 그 시절 개발자들만의 깊은 낭만을 느낄 수 있었습니다.
구조의 한계와 새로운 언어의 탐구
교육용 16bit PC가 보급되고 플로피 디스크를 사용하게 되면서, 드디어 작성한 프로그램을 저장할 수 있게 되셨습니다. 하지만 코드가 길어질수록 구조는 복잡해졌고, 코드 수정은 점점 어려워졌습니다.
이 문제를 해결하기 위해 컴퓨터 잡지를 뒤적이며 GOTO 문 없이 구조적 프로그래밍이 가능한 'Pascal'을 독학하셨지만, 이번엔 언어의 속도가 발목을 잡았습니다. 결국 더 빠른 처리 속도를 위해 저수준 제어가 가능한 C언어를, 그래픽 처리를 위해 하드웨어를 직접 제어하는 어셈블리 언어까지 섭렵하셨다고 합니다.
"취미로 게임을 만들면서 재밌게 놀던 시절이었다. ‘이걸 해야 돼’라는 압박감 없이, 단순히 좋아해서 했던 시대였다."
영호님의 이 회고는 제게 큰 울림을 주었습니다. '개발자라면 반드시 이걸 알아야 한다'는 정해진 커리큘럼에 쫓기는 지금 시대와 달리, 오직 눈앞의 문제를 해결하기 위해 스스로 필요성을 느끼고 기술을 탐구하던 그 순수한 열정이 무척 멋있게 다가왔습니다.
객체지향과의 만남, 그리고 '설계'의 깨달음
영호님이 개발자로서 가장 큰 폭의 성장을 이루었다고 꼽으신 시기는 군 복무 시절이었습니다. 전산실 서버를 지키며 하루 4시간 쪽잠을 자는 열악한 환경 속에서도, 전산 서적을 읽으며 '세포와 세포막'이라는 비유를 통해 처음 객체지향(OOP)을 접하셨다고 합니다. Windows 95 출시와 함께 C++이 부상하던 시기였습니다. (이때, 오늘날 백엔드의 핵심 패러다임으로 여겨지는 객체지향이 본래 프런트엔드(GUI) 환경에 더 적합한 방식에서 출발했다는 사실은 제게 꽤 신선한 충격이었습니다.)
군대 선임과 함께 C++로 게임을 만들면서, 영호님은 큰 깨달음을 얻게 됩니다. 초기에는 Object Pool에 이미지를 넣고 타입별 포인터로 업데이트와 렌더링을 처리하는 방식을 썼는데, 이는 데이터 결합도가 높아 수정이 매우 까다로웠습니다. 그러나 선임이 가져온 다른 게임의 소스 코드를 분석하며, 상속과 다형성을 활용해 내부가 캡슐화된 깔끔한 클래스 구조로 리팩터링하는 과정을 경험하셨습니다.
여기서 얻은 첫 번째 교훈은 "기능이 동작하는 것만큼이나, 이해하고 수정하기 편한 구조를 만드는 것이 중요하다"는 것이었습니다. 상태와 행위는 함께 다녀야 한다는 객체지향의 본질을 게임 프로그래밍을 통해 체득하신 것입니다.
패러다임의 전환: GUI에서 클라우드까지
제대 후 영호님은 터미널 환경에서 GUI(윈도우) 시대로의 급격한 변화를 마주하게 됩니다. "지금까지 배운 것이 모두 무용지물이 되는 건가" 하는 두려움도 있었지만, 막상 Windows 환경에서 프로그래밍을 해보니 하드웨어를 다루는 방식만 달라졌을 뿐 메인 로직을 구현하는 방식은 기존과 유사했습니다. 여기서 "기술이 진화하더라도 문제 해결의 본질적인 방법은 유사하다"는 두 번째 깨달음을 얻으셨습니다.
이후 인터넷의 대중화와 자바(Java)의 부상, 애자일(Agile) 방법론의 도입, 스마트폰의 등장으로 인한 모바일 트래픽의 폭증, 그로 인한 빅데이터와 클라우드 컴퓨팅의 시대까지. 기술은 숨 가쁘게 발전했고 개발자는 끊임없이 변화에 적응해야만 했습니다.
변하지 않는 본질: 유지보수성과 개발자의 책임
과거에는 기술의 변화가 지금보다 훨씬 급격하게 다가왔다고 합니다. 하지만 그 격변의 역사 속에서도 절대 변하지 않는 단 하나의 본질이 있었습니다. 바로 "소프트웨어의 생명주기에서 개발보다 유지보수 기간이 훨씬 길다"는 사실입니다.
시대를 관통하는 궁극적인 목표는 결국 '유지보수성'입니다. 타인이 쉽게 이해할 수 있는 코드를 작성하는 것은 어렵지만, 소프트웨어가 오래 지속되기 위해서는 그 구조적 트레이드오프를 짊어지고 조율하는 것이 바로 개발자의 역할입니다.
최근 AI의 발전으로 '이제 코드를 직접 짜지 않아도 된다'는 생각에 대해, 영호님은 "자신을 갉아먹는 안타까운 생각"이라고 일축하셨습니다. AI는 내 머릿속의 아이디어를 빠르게 코드로 구현하고 피드백을 받는 데 유용한 '도구'일 뿐입니다. 의사결정을 대신해 줄 수는 없으며, 시스템을 유지보수하는 최종 책임은 오롯이 개발자의 몫입니다.
시대가 바뀌어도 우리가 해야 하는 일은 '유지보수하기 쉬운 코드를 작성하기 위해 집요하게 고민하는 것'입니다. 영호님의 마지막 당부처럼, 저 역시 이 험난하지만 매력적인 개발의 여정을 진심으로 즐기며 나아가는 개발자가 되겠습니다.
Q&A 세션 요약
AI 시대, 개발자의 역할과 주니어의 역량
- 신입 개발자에게 필요한 역량은 무엇인가요?
회사마다 기준이 다릅니다. AI 활용 능력을 중시하는 곳도 있고, 전통적인 개발 역량을 중시하는 곳도 있습니다. 하지만 '개발자가 갖춰야 할 기본 역량'은 변하지 않습니다. 당장 회사에서 요구하는 공부와, 자신의 미래를 위한 공부를 병행하는 것이 좋습니다. - AI가 발전하면 자연어로 코딩하는 시대가 올까요?
오지 않을 것이라 생각합니다. 코딩은 그동안 쌓아온 수많은 추상화의 결과물입니다. AI가 이를 이해하려면 맥락 전체를 알아야 하는데, 사람 간의 소통에서도 오해가 발생하듯 비결정적인 AI가 완벽히 이해하기는 어렵습니다. - 생산성(빠른 구현)과 좋은 설계 중 무엇이 우선인가요?
둘 다 중요합니다. 일단 동작하는 코드를 빠르게 만들고, 이후에 좋은 설계로 리팩터링하는 연습을 하는 것이 가장 좋습니다. - 여전히 신입 개발자가 필요한가요?
물론입니다. 고연차 경력직은 이직이 잦은 편입니다. 신입을 뽑지 않는 회사는 발전이 없거나 조직이 정체되어 있을 확률이 높습니다. 신입은 조직에 새로운 자극제가 됩니다. - 함께 일하고 싶은 동료는 어떤 사람인가요?
'오픈 마인드'를 가진 개발자입니다. 해보지도 않고 "저건 아니야"라며 답을 정해놓고 소통하는 팀원과는 일하기 힘듭니다. - 면접 시 반드시 확인하는 질문이 있나요?
필수 질문은 따로 없고, 이력서에 맞춘 꼬리 질문을 합니다. 이력서에 적힌 기술을 정말 깊이 고민하고 사용했는지, 그 과정에서 어떻게 의사소통하고 결정했는지를 집중적으로 확인합니다.
객체지향(OOP)과 좋은 설계의 본질
- AI 시대에도 유지보수하기 좋은 설계가 중요한가요?
물론입니다. 코드를 작성하는 비용 자체는 낮아졌지만, 나쁜 코드의 유지보수 비용은 오히려 더 커졌습니다. AI가 코드를 분석할 때 결합도가 높고 응집도가 떨어지면 유지보수가 매우 힘들어집니다. 비용의 가치를 판단하는 것은 결국 개발자의 몫입니다. - 객체지향 설계에도 정답이 있나요?
설계에 완벽한 정답이나 오답은 없습니다. 설계는 '제약 속에서 최선의 답을 찾는 과정'입니다. 일정, 동료의 수준, 기술적 숙련도를 종합적으로 고려해 일정 내에 마무리할 수 있는 최적의 타협점을 찾는 것이며, 이는 많은 경험을 통해 우선순위를 정하는 감각을 길러야 합니다. - 좋은 코드를 판단하는 기준이 있다면?
단위 테스트(Unit Test)가 깨지지 않고, 유지보수가 가능해야 합니다. 만약 코드에 모킹(Mocking)이 너무 많다면, 이는 단위 테스트가 서로 고립되지 못했다는 뜻이므로 '나쁜 코드'이자 설계적 결함이 있다는 신호입니다. 단위 테스트는 짧은 시간에 독립적으로 돌아가야 합니다. - 프로젝트 시작 시, 객체의 책임을 할당하는 기준은 무엇인가요?
처음부터 기계적인 기준을 적용하지는 않습니다. 초반에는 코드를 읽었을 때 '스토리가 보이는 정도'의 가독성을 중심으로 책임을 할당합니다. 이후 시간이 지나면서 유연성과 재사용성을 갖추도록 리팩터링해 나갑니다. - Syntax Sugar(문법적 설탕)에 대한 생각은 어떠신가요?
코드를 쉽게 작성하게 해주지만, 자칫 가독성을 해칠 수 있습니다. 유지보수성을 최우선으로 생각한다면, 다른 사람이 명확하게 이해할 수 있도록 풀어쓰는 것이 더 낫다고 생각합니다.
TDD, DDD, 그리고 Spring 프레임워크
- DDD(도메인 주도 설계)와 객체지향의 차이는 무엇인가요?
객체지향이 기능 수행을 위해 '코드를 어떻게 배치할 것인가'를 다루는 기술적 매체라면, DDD는 기술적인 것을 넘어 '도메인을 바라보는 관점 그대로 사용자와 커뮤니케이션'하라는 철학적 개념에 가깝습니다. 아키텍처, 커뮤니케이션, 배포 등 전반적인 의사결정을 도메인 중심으로 하는 것이 DDD입니다. - Spring MVC와 객체지향은 다른 정체성을 가지나요?
Controller, Service, Repository 구조는 사실상 절차지향적입니다. Spring 프레임워크 자체가 절차적으로 코드를 짜기 쉽게 만들어져 있습니다. 객체지향이 진정으로 적용되어야 할 곳은 '도메인(Domain) 단'입니다. - TDD(테스트 주도 개발)에 대한 생각은 어떠신가요?
개인적으로 아주 좋아하지는 않습니다. TDD가 객체지향을 연습하기엔 좋지만, 때로는 테스트를 위해 억지로 중복을 만들어야 할 때도 있습니다. 프로덕션 코드에 중복이 전혀 없어야 한다는 것도 일종의 오해입니다. 저는 리팩터링 후에 테스트 코드를 작성하는 것을 더 선호합니다. TDD를 무조건 맹신하기보다는 상황에 맞는 적합한 방법을 쓰는 것이 중요합니다.
저서와 개발자로서의 태도
- 『오브젝트』는 어떻게 읽는 것이 좋나요?
이 책은 객체지향을 설계할 때의 '방향성'을 다룬 책입니다. 개념만으로는 이해가 어려워 코드를 활용해 설명했습니다. 처음엔 내용을 습득하는 것만으로도 벅찰 수 있으니 여러 번 반복해서 읽어보기를 권합니다. - 『오브젝트』 표지의 의미와, 담지 못해 아쉬웠던 점은?
표지는 '원 안의 원'이라는 프랙탈(Fractal) 구조를 나타내는 작품입니다. 객체 안에 객체가 있는, 응집도 높게 캡슐화된 객체지향의 느낌을 잘 보여준다고 생각해 직접 골랐습니다. 아쉬운 점은 이론 중심이다 보니 실무적인 팁을 많이 담지 못한 것입니다. 실무에서는 이론과 반대로 타협해야 하는 경우도 많습니다. - 『오브젝트』 이후 읽기 좋은 책을 추천해 주신다면?
『이펙티브 자바(Effective Java)』, 『클린 코드(Clean Code)』를 추천합니다. 원칙 중심의 책인 오브젝트를 읽은 후, 실제 응용 코드를 다루는 책을 보면 원칙 간의 충돌을 어떻게 해결하는지 배울 수 있습니다. 크레이그 라만의 『Applying UML and Patterns』, 마틴 파울러의 『엔터프라이즈 애플리케이션 아키텍처 패턴(PEAA)』도 제가 주기적으로 다시 읽는 훌륭한 책들입니다. - 『객체지향의 사실과 오해』에서 '이상한 나라의 앨리스'를 인용한 이유는?
초고를 동료들에게 보여주었을 때 용어가 너무 어렵다는 피드백을 받았습니다. 독자들의 이해를 돕기 위해 친숙한 비유를 찾다가 도입하게 되었습니다. - 개발자가 절대 하지 말아야 할 것이 있다면?
'자만심'을 경계해야 합니다. "내가 이것을 잘 안다"라고 확신하는 것은 위험합니다. 학습할 것은 끝없이 많고, 우리가 아는 것은 매우 적기 때문입니다. - 꾸준한 열정의 원동력은 무엇인가요?
결국 '재미'에서 나옵니다. 예전만큼 마냥 재밌지만은 않지만, 스스로 설계의 기준을 정하고 그것을 달성해 나가는 과정에서 저만의 재미를 찾고 있습니다. 정답이 없는 선택의 기로에 섰을 때는 오래 고민하기보다 일단 빠르게 실행해 보고 경험을 통해 배우는 편입니다.