내가 지난 7년간 엔지니어로 일하면서 배운 것 (3)
개발자로 일하다 보면 어느 날 문득,
낯선 에러 로그 한 줄이 눈에 꽂힐 때가 있다.
평소처럼 넘어가기엔 묘하게 찜찜하다.
이럴 때 뇌는 ‘지금 파고들어야 해’라는 신호를 쏘고,
우리는 자연스레 디버깅 모드로 진입한다.
반복된 경험이 만든 이 번개 같은 판단 체계가 휴리스틱이다.
이 글은 ‘7년간 엔지니어로 일하며 배운 것’ 시리즈의 마지막 편,
그리고 마지막 키워드인 휴리스틱을 다룬다
어림짐작과 논리적 추정 그 사이
혹시 코딩 테스트에서 A* 알고리즘 문제를 풀어본 적 있는가?
다익스트라 알고리즘의 확장판으로,
각 노드까지의 경로를 ‘추정’해서 효율적인 길을 찾는 방식이다.
이처럼 전통적인 알고리즘은 가능한 모든 경우의 수를 계산하지만,
현실 세계는 그렇지 않다.
변수는 너무 많고, 시간은 항상 부족하다.
그래서 우리는 제한된 정보와 경험을 기반으로 ‘그럴듯한 추정’을 한다.
이 전략이 바로 ‘휴리스틱 알고리즘’이며,
쉽게 말하면 ‘어림짐작’이다.
하지만, 언제나 적절한 해답일까?
현대 사회는 빠른 판단을 요구한다.
이때 휴리스틱은 놀라운 효율을 발휘하지만,
동시에 우리를 편향이라는 함정으로 이끌기도 한다.
예를 들어,
지난 프로젝트에서 MySQL이 잘 통했으니, 이번에도 그게 최선이겠지.
이 판단은 대표성 편향 (Representativeness_heuristic)일 수 있다.
상황은 바뀌었지만, 우리는 과거 경험 몇 개로 전체를 판단해버린다.
또 다른 예를 하나 들어보겠다.
다들 React 쓴다더라.
유명하고 익숙하다는 이유만으로 도입하지만,
막상 프로젝트를 어느정도 진행 후 돌아보면 우리 도메인과는 맞지 않는 경우도 있다.
이 기술이 가진 장단점과 특징을 면밀히 고려하지 않고 귀에 익숙하기 때문에 겪게되는 재앙이다.
이런 판단은 가용성 편향 (Availability heuristic)이다.
잘 알려졌고 자주 접했다는 이유만으로 판단 기준이 왜곡된 것이다는
휴리스틱은 대부분의 경우 유용하지만,
기술 선택처럼 중요한 결정 앞에서는 신중함이 필요하다.
그러면 어떻게 판단해야 할까?
엔지니어링 세계에 은탄환(Silver Bullet)은 없다.
뛰어난 엔지니어는 늘 트레이드오프를 고려하고,
그에 따라 결정을 내린다.
내가 자주 쓰는 방법은 표 만들기다.
A4 한 장에 각 기술의 장단점, 리스크, 상황별 트레이드오프를 적어본다.
요즘은 ChatGPT Deep Research, Perplexity 같은 도구를 활용해 빠르게 정보를 정리할 수도 있다.
무엇보다 중요한 건, 결정 이후에 복기하는 습관이다.
기록의 힘: ADR을 써보자
복기를 하려면 무엇이 필요할까?
중요한 의사결정에는 기록이 필수다.
우리가 왜 이렇게 결정했는지 복기하고 다시 돌아볼 수 있기 때문이다.
프로젝트 시작과 동시에 ADR(Architecture Decision Record)을 작성해보자.
후임자가 나중에 코드를 보며 “도대체 이걸 왜 이렇게 했지?”라고 묻지 않게 만드는 최소한의 예의다.
마지막으로, 비판적 사고 (Critical Thinking)
좋은 엔지니어는 끊임없이 의심하고 질문하며 자신만의 기준을 만든다.
아무리 좋은 책이라도 그 책에서 더 배울 수 있는 방법은 다음 3가지라고 생각한다.
- 책을 읽고 따라 하기
- 의문을 품기
- 반론을 제기하고 나만의 생각 만들기
이 중 세 번째가 엔지니어에게 가장 필요하다.
왜냐하면 우리는 99%의 완성도에 안주하지 않고,
100%를 향해 고도화하는 사람들이기 때문이다.
단순히 받아들이는 것이 아니라,
의문을 품고, 반론을 제기하고, 자신의 생각을 표현하는 훈련이 중요하다.
예전에 교수님께서 논문을 “기존 지식을 의심해 세상의 지평을 한 발짝 넓히는 과정”이라 하셨던 말이 떠오른다.
우리도 문제 해결 과정에서 지금 그 문제 끝에 서 있는 사람들이다.
한 발짝 더 가려면 기존의 솔루션을 Critical하게 바라보고 발전시켜나가야 한다.
정리
- 휴리스틱은 빠른 판단을 가능하게 하지만,
- 대표성 편향과 가용성 편향은 판단력을 흐릴 수 있다.
- 그래서 우리는 비판적 사고, 트레이드오프 분석, **기록 문화(ADR)**를 통해 회고하고 개선하고 더 나은 결정을 해야 한다.
이 글로 지난 7년간의 엔지니어 여정을 정리하는 시리즈를 마무리한다.
3편에 걸쳐 아래 주제를 다뤘다.
- 이진 분류의 핵심 지표: Confusion Matrix, F1 Score
- 데이터 해석의 출발점: 평균값과 통계값, 최빈값 (Mean, Median, Mode)
- 직관의 힘과 그 함정: 휴리스틱과 심리 편향, 그리고 비판적 사고
여러분은 SW 엔지니어로서 어떤 배움을 가장 크게 얻었는가?
기억나는 것이 있다면, 글로 써보는 건 어떨까.