추측하지 말고 이분탐색하라
정상 작동 버전과 고장 난 버전 사이 어딘가에서 버그가 나타났다면, 차이를 눈으로 훑는 대신 이력을 이진 탐색하라—중간 지점을 확인하고 하나의 변경만 남을 때까지 반복하라.
엔지니어가 여덟 시간 내내 타이핑만 한다는 이미지는 대체로 틀렸다. 다른 사람의 코드를 읽고, 원인이 뚜렷하지 않은 장애를 추론하고, 엔지니어가 아닌 사람들에게 기술적 절충을 설명하는 일이 새 코드를 작성하는 일만큼—입사 후 몇 년만 지나면 대개 그보다 더 많이—차지한다.
이 직업 안에서 전수되는 기술은 어떤 언어를 배울지보다 사고 습관에 가깝다. 추측 대신 체계적으로 버그를 추적하는 법, 잘 돌아가는 코드는 언제 그냥 두어야 하는지, 그리고 코드를 삭제하는 것이 그 주에 한 가장 가치 있는 일일 때는 언제인지가 그것이다.
이 일이 요구하는 역량
문제 분해88
디버깅90
시스템 설계74
커뮤니케이션과 협업80
테스트와 코드 품질70
지속적 학습83
문제 분해
모호하고 큰 요청을 작고 독립적으로 만들고 테스트할 수 있는 조각으로 쪼개는 능력—큰 작업에서 막히는 엔지니어와 생산적인 엔지니어를 가장 크게 가르는 기술이다.
디버깅
추측하고 될 때까지 이것저것 바꾸는 대신, 시스템이 어디서 왜 오작동하는지 체계적으로 좁혀 나가는 능력.
시스템 설계
서비스, 데이터, 팀을 어떻게 나눠야 전체가 첫날에만 돌아가는 게 아니라 몇 년간 안전하게 계속 바뀔 수 있는지 결정하는 능력.
커뮤니케이션과 협업
비엔지니어에게 기술적 절충을 설명하고, 리뷰어를 위해 변경 사항을 명확히 정리하고, 범위를 협상하는 능력—전문적으로 쓰인 코드는 작성되는 것보다 훨씬 많이 읽히고 논의된다.
테스트와 코드 품질
사용자가 발견하기 전에 잘못된 변경을 잡아내는 검증을 작성하고, 다음 사람—흔히 몇 달 뒤의 자기 자신—이 안전하게 수정할 수 있도록 코드베이스를 읽기 쉽게 유지하는 능력.
지속적 학습
언어, 프레임워크, 그리고 이제는 AI 도구까지 몇 년마다 뒤바뀐다. 첫 직장이나 부트캠프 이후 의도적으로 배우기를 멈춘 엔지니어는 빠르게 정체된다.
하루의 풍경
- 7–9
메일함, 스탠드업, 트리아지
밤새 온 알림과 메시지를 확인한 뒤, 팀이 무엇을 하고 있고 무엇이 막혀 있는지 나누는 짧은 스탠드업 회의를 한다.
- 9–12
딥워크: 코드 작성
하루 중 가장 잘 보호되는 시간대로, 이상적으로는 알림을 끈 채 지속적인 집중이 필요한 기능이나 수정을 구현한다.
- 12–13
점심
진짜 휴식 시간. 많은 엔지니어가 바쁠 때 가장 먼저 사라지는 것이 이것이고, 잃고 나면 가장 먼저 후회하는 것이라고 말한다.
- 13–16
리뷰, 페어링, 회의
동료의 풀 리퀘스트를 읽고, 어려운 문제를 함께 풀고, 대개 오후에 몰려 있는 설계·계획 회의를 진행한다.
- 16–19
디버깅, 배포, 마무리
그날의 변경을 완료해 출시하고, 안전하게 배포되는지 지켜보며, 내일이나 밤새 온콜을 맡을 사람을 위해 메모를 남긴다.
- 19–7
퇴근 (대체로)
개인 시간과 수면—온콜 주간이 아니라면. 온콜 주간에는 휴대폰 알림이 새벽 3시를 예정에 없던 프로덕션 장애로 바꿔놓을 수 있다.
노하우
현장에서 실제로 전수되는 기술 지식 — 동기부여 문구가 아니다.
코드를 읽기 전에 실패 먼저 읽어라
전체 오류 메시지, 스택 트레이스, 주변 로그 줄에는 이미 답이 담겨 있는 경우가 많다. 곧바로 소스로 뛰어들어 추측하는 것은 컴퓨터가 공짜로 제공한 유일한 증거를 낭비하는 일이다.
변경을 쉽게 만든 다음, 쉬운 변경을 하라
어떤 기능을 추가하기 어렵다면, 대개 코드가 그 기능에 맞지 않는 모양으로 짜여 있다는 신호다. 동작 변화 없이 먼저 리팩터링해 그 기능이 작고 뻔한 diff가 되게 만든 뒤 그 diff를 적용하라.
체스터턴의 울타리
이해되지 않는 코드, 설정값, 검사 로직을 삭제하거나 단순화하기 전에 왜 거기 있는지 먼저 알아내라. 정확히 그 이유 때문에 몇 년째 일어나지 않은 장애를 조용히 막고 있는 것일 수 있다.
코드를 삭제하는 것도 진전이다
더 이상 존재하지 않는 코드는 버그도 없을 수 없고, 다음 독자를 헷갈리게 할 수도 없고, 업데이트가 필요하지도 않다. 죽은 경로와 쓰지 않는 기능을 제거하는 일은 기능을 출시하는 것만큼 축하받아야 한다.
고무 오리 디버깅
도움을 요청하기 전에 동료나 심지어 무생물 앞에서 문제를 소리 내어 한 줄씩 설명하라. 정확하게 표현하는 행위 자체가 누군가 대답하기도 전에 버그를 드러내는 경우가 많다.
일의 도구들
코드 에디터/IDE
비주얼 스튜디오 코드와 젯브레인즈의 IDE들이 시장을 지배하며, 둘 다 이제 AI 기반 자동완성과 채팅을 에디터에 직접 내장한다.
Git
2005년 토르발스가 만든 뒤 업계 거의 전체가 표준으로 채택한 버전 관리 시스템으로, 이것 없이 출시되는 것은 거의 없다.
이슈 트래커
지라, 리니어, 깃허브 이슈는 버그와 기능의 백로그를 팀이 일주일 또는 한 분기 단위로 계획할 수 있는 것으로 바꿔준다.
CI/CD 파이프라인
모든 변경마다 코드를 빌드, 테스트, 배포하는 자동화 시스템으로, 배포를 긴장되는 수동 이벤트에서 일상적인 일로 바꾼다.
AI 코딩 어시스턴트
깃허브 코파일럿 같은 도구는 이제 엔지니어가 받아들이는 코드 줄의 상당 부분을 작성하며, 일상 업무를 타이핑에서 검토와 지시 쪽으로 옮기고 있다.
실패하는 이유
이력서 지향 개발
문제에 맞아서가 아니라 이력서에 잘 보여서 유행하는 언어, 프레임워크, 아키텍처를 고르는 것으로, 다음 팀이 떠안아야 할 복잡성을 남긴다.
오류 메시지를 읽지 않는 것
프로그램이 실제로 보고하는 내용을 읽는 대신 기억나는 해결책에 패턴 매칭하는 것으로, 엉뚱한 원인을 쫓느라 몇 시간을 태울 수 있다.
빅뱅 재작성
작동 중인 시스템을 버리고 '제대로' 처음부터 다시 만드는 것은 악명 높게 위험한 시도다—1990년대 말 넷스케이프가 브라우저를 전면 재작성했던 사례는 그 때문에 시장 선두 자리를 잃은 널리 인용되는 사례다.
계속 탐색하기
공학·기술 분야의 다른 직업
🤖
AI 연구원
기계 지능을 뒷받침하는 알고리즘을 설계하고 검증하는 직업으로, 이제는 자기 자신의 연구 과정 상당 부분을 자동화하려는 경쟁이 벌어지는 분야이기도 하다.
AI 내성 50 🛰️항공우주공학자
지상을 벗어나는 항공기, 로켓, 우주선을 설계하고 분석하고 인증하며, 추측의 여지가 없는 안전 여유를 다루는 직업이다.
AI 내성 74 🌉토목공학자
강과 바위와 중력을 다리, 도로, 맑은 물로 바꾸는 직업 — 임호테프 이래 문명을 떠받쳐온 조용한 하중지지의 업.
AI 내성 72 🔌반도체 엔지니어
컴퓨터, 휴대폰, 무기 등 거의 모든 전자기기 내부의 트랜지스터를 설계하고 제조하며, 지구상 극소수 공장만이 다룰 수 있는 초정밀 장비를 다룬다.
AI 내성 60 🦾로봇공학 엔지니어
물리적 세계를 감지하고 판단하고 행동하는 기계를 설계하는 사람으로, 진짜 난제는 지능이 아니라 언제나 세계 그 자체였다.
AI 내성 65