-
[독후감] 이펙티브 엔지니어 - AI 시대에 효율적인 엔지니어란 뭘까개발/오피니언 2026. 3. 2. 18:19
이펙티브 엔지니어라는 책을 읽게 되었습니다.
이 책의 저자가 전달하고자 하는 메시지는 명료합니다.
내가 하는 일이 높은 레버리지를 가지도록 해라.
시간이라는, 누구에게나 공평하게 주어지는 이 한정된 자원을 가장 효율적으로 사용하라는 메시지입니다.
AI 시대를 살아가는 소프트웨어 엔지니어로서, 우리는 어떻게 일해야 효율적으로 일할 수 있을까요?
이 책에서 소개하는 예시들 중에 제가 중요하다고 생각하는 두 가지를 골라 봤습니다.
- 여러 명에게 영향을 미칠 수 있는 일이 더 큰 레버리지를 가진다.
- 급하지만 중요하지 않은 일을 위임하면, 급하지 않지만 중요한 일에 시간을 더 투자할 수 있다.
이런 명제들은 논리적으로 옳습니다.
그렇기 때문에 시간이 지나도 변하지 않습니다.
세상이 바뀌고 환경이 변화하더라도 바뀌지 않습니다.
마치 1 + 1 은 2라는 사실처럼, 논리적 표현이기 때문입니다. 다시 볼까요?
- 여러 명에게 영향을 미칠 수 있는 일이 더 큰 레버리지를 가진다.
- 나 혼자 10시간을 단축했을 때보다, 100명의 1시간을 단축하는 것이 더 큰 영향력을 갖는다는 사실은 자명합니다.
- 급하지만 중요하지 않은 일을 위임하면, 급하지 않지만 중요한 일에 시간을 더 투자할 수 있다.
- 시간이라는 자원은 예나 지금이나 똑같이 한정된 자원입니다. 일을 위임하면 그만큼의 시간이 생긴다는 사실 역시 자명합니다.
이 두 가지 명제에 따라 실천할 수 있는 행동에는 어떤 것이 있을까요?
정답은 아니지만, 저의 사례를 공유해보려 합니다.
여러 명에게 영향을 미칠 수 있는 일
저는 회사 전체를 상향평준화 시키려는 노력을 했습니다.
얼마 전 사내 AI 세미나에서 발표를 했습니다.
"AI를 가장 잘 쓰는 팀"이 되자는 개발팀 목표 아래, 저의 AI 사용 경험을 공유하고 사람들의 피드백을 받는 자리였습니다.
추상적인 내용이 아닌, 정말 실무를 어떻게 하는지에 대한 구체적인 사례를 공유했어요.
개인의 경험을 공유해서 팀 전체의 경험으로 만들면, 팀 전체를 상향평준화 할 수 있습니다.
Claude Code, 물론 모두들 각자 잘 쓰고 있겠지만, 분명 비효율이 존재합니다.
이런 세미나를 통해 실제로 제가 작업했던 내용, 프롬프트, 사용 사례를 공유하면 배울 점, 지적할 점이 꼭 하나씩은 나옵니다.
그걸 모두가 보는 앞에서 공유하고 대화를 나눕니다.
그러면 모두의 효율이 함께 높아지는 겁니다.
AI와 별 연관은 없지만, 여러 명의 시간을 아낀 경험을 하나 더 소개하겠습니다.
저희 회사는 프로덕션 환경과 테스트 환경, 로컬 환경의 DB가 분리되어 있어요. 로컬에서 개발할 때 최신 데이터를 참조하려면 프로덕션 환경의 데이터를 복제해와야 합니다.
이를 위해서는 특정 테이블(NoSQL의 경우 collection)만 복제해오는 스크립트가 필요합니다. 그런데 이 스크립트를 각자 만들어서 쓰고 있었어요.
기존에 일하시던 개발자 분들은 이미 만든 스크립트를 사용하기 때문에 불편함이 없겠지만, 신규 입사자 분들은 스크립트의 존재도 잘 모릅니다.
그리고 스크립트를 매번 새로 만드는 건 시간이 좀 오래 걸리는, 다소 귀찮은 일입니다.
이런 비효율을 개선하기 위해, 범용적으로 사용할 수 있는 스크립트를 작성하고 사내 레포지토리에 공유했습니다.
이제 신규 입사자는 스크립트를 직접 작성할 필요 없이, 레포지토리를 clone 해오고 실행하면 됩니다.
이것을 잘 다듬어서 온보딩 프로세스에 반영하기로 했습니다.
별 거 아닌 작업이지만, 모두가 공통된 스크립트를 사용하게 되었다는 점이 중요합니다.
이제 스크립트에 문제가 생기거나 새로운 기능이 필요해질 경우, 이 공통 스크립트가 업데이트 될 겁니다.
관리 지점을 단일 지점으로 묶을 수 있는 겁니다.
이러면 개발자들이 같은 문제로 두 번 일하는 일이 없어집니다.
장기적으로도 레버리지가 높은 활동인거죠.
급하지만 중요하지 않은 일을 위임하고, 중요한 일을 위한 시간을 확보하기
중요하지 않은 일을 AI에게 위임했습니다.
어떻게 위임했느냐.
먼저 AI가 잘하는 일과 못하는 일을 구분해야 합니다.
AI는 뻔한 걸 잘합니다. 뻔하지 않을수록 못합니다.
정확히는 AI의 특성은 아니고, LLM의 특성이긴 합니다. 확률에 의해 다음 토큰을 골라 나가는 방식이고, 학습된 데이터가 많을 수록 정답을 고를 확률이 높아지니까요. 아무튼 그렇습니다.
AI에게 개발 작업 전체를 위임할 수 있다면 얼마나 좋을까요?
하지만 안타깝게도, "이거 만들어줘" 같은 간단한 명령으로 개발 전체를 위임할 수는 없습니다.
AI 도구를 사용해 본 분들은 느끼시겠지만, 내가 원하는 좋은 결과물을 얻기 위해서는 프롬프트를 잘 써야 합니다.
개발의 목적, 필요한 요구사항, 제약 조건 등 맥락을 빠짐없이 제공해야 좋은 결과가 나옵니다.
그런데 저는 완벽한 프롬프트를 작성하기 위해 공들이기가 싫었어요.
그럴 바에는 코드를 직접 치고 마는게 빠르겠다는 생각이 자꾸 들었습니다.
하지만 분명 프롬프트를 대충 써도 찰떡같이 알아듣는 몇 가지 케이스가 있습니다.
뻔한 케이스들입니다.
- 프레임워크 문법에 맞는 보일러플레이트 코드 작성
- 핵심 도메인 로직이 없는, Infrastructure 레벨의 코드 작성
- 일반적인(뻔한) 테스트 작성
이런 케이스에서는 제가 대충 명령하더라도 좋은 결과를 만들어냅니다.
그래서 저는 뻔하지 않은 일에 집중하고 있어요.
전체 구조를 설계하고, 인터페이스를 정의하고, 도메인 로직을 짜는 일입니다.
나머지 작업들은 AI에게 대충 명령합니다. 그렇게 해도 좋은 코드가 나옵니다.
그리고 AI에게 더 많은 일을 위임하기 위해, 저는 좋은 코드를 쓰려 노력합니다.
한번 코드를 잘 만들어 놓으면 그 다음부터는 AI에게 굳이 맥락을 입 아프게 설명하지 않아도 기존 구현을 참조시키면 되니까 좋더라구요.
애매하고 복잡한 코드를 작성하면 AI가 헤맵니다.
간결하고 명확한 코드를 작성하면 AI가 방향을 잘 잡습니다.
이 책을 읽고 나서 느낀 점이라면, AI 시대라고 해서 효율적인 엔지니어에 대한 정의가 크게 바뀌지는 않았다는 것입니다.
여전히 시간은 가장 중요하고 한정된 자원입니다.
AI 도구는 시간을 효율적으로 쓸 수 있는 또 다른 방법일 뿐이라고 생각합니다.
역설적이지만 그래서 사실 AI를 잘 쓰는 건 굉장히 중요합니다. 시간을 아껴주는 강력한 도구니까요.
AI는 가속기(accelerator) 역할을 한다는 글을 본 적이 있습니다.
그 말인 즉, 옳은 방향이든 나쁜 방향이든 그 방향으로 빠르게 내달리게 해준다는 뜻입니다.
그래서 저는 옳은 방향 설정에 집중하는 것이 더욱 중요해졌다고 생각해요.
요즘은 AI 도구를 써서 일주일만에, 하루만에, 30분만에 프로젝트를 완성했다는 얘기들이 하루가 다르게 링크드인에 올라와서 판을 뜨겁게 달구고 있습니다.
하지만 AI 도구로 메가히트를 한 사례는 잘 나오지 않고 있어요. AI 시대 이전의 메가히트 비율과 비슷한 것 같습니다.
결국 어떤 문제를 해결하느냐,
그 문제를 정의하는 능력이 더 중요해지지 않았나 싶습니다.