직접 만든 코드와 사랑에 빠진 개발자의 비극
카테고리: IT 심리학 | 작성자: Mind & Tech | 발행일: 2026-07-30
요약: 내가 직접 구축한 시스템일수록 객관적인 버려짐을 거부하는 이케아 효과의 메커니즘과 이를 극복하는 아키텍처 전략.
수년간 여러 IT 스타트업과 성장기 기업의 시스템 아키텍처를 개편하고, 복잡하게 얽힌 레거시 코드를 리팩토링하는 프로젝트를 총괄하며 한 가지 지독한 패턴을 목격해 왔습니다. 시스템이 거대해지고 기술 부채가 한계에 다다르면 항상 특정 지점에서 기이한 병목이 발생하곤 했습니다.
그 병목은 시스템의 성능 한계나 서버의 사양 부족이 아니었습니다. 바로 특정 내부 프레임워크나 커스텀 모듈을 손대려 할 때마다 터져 나오는 베테랑 엔지니어들의 격렬한 저항이었습니다. 분명 시장에는 이미 훨씬 더 안정적이고, 문서화가 잘 되어 있으며, 전 세계 수만 명의 개발자가 검증한 훌륭한 오픈소스 라이브러리가 존재합니다. 그럼에도 수많은 팀들이 자체적으로 만든 비효율적인 유틸리티 코드를 고수하느라 밤을 새우고 있었습니다.
"이건 우리가 우리 비즈니스 레이어에 최적화해서 바닥부터 직접 만든 프레임워크입니다. 오픈소스로 바꾸면 우리 특유의 유연성이 사라집니다."
회의실을 채우던 그 당당하고도 슬픈 목소리들을 잊을 수 없습니다. 정작 그 '유연성' 때문에 신규 입사한 개발자들은 온보딩에 두 달이 걸리고, 일주일에 수십 시간씩 의미 없는 버그를 잡느라 방전되고 있는데 말이죠. 저 역시 한때 내가 밤새워 짜낸 수천 줄의 아키텍처를 지키기 위해 몸부림쳤던 부끄러운 과거가 있습니다.
오늘 글을 한 줄로 요약하면, **내가 직접 땀 흘려 만든 코드일수록 비합리적으로 과도한 가치를 부여하는 '이케아 효과(IKEA Effect)'를 직시하고 자아와 코드를 분리해야만 시스템과 개발자 모두 성장할 수 있다는 이야기입니다.**
---
### 1. 나사가 삐뚤어진 DIY 책상을 버리지 못하는 뇌의 착각
행동경제학자 댄 애리얼리(Dan Ariely) 교수는 실험을 통해 사람들이 스스로 조립한 이케아 가구에 대해, 완제품으로 구매한 더 뛰어난 가구보다 훨씬 더 높은 가치를 매긴다는 사실을 증명했습니다. 이를 심리학에서는 '이케아 효과(IKEA Effect)'라고 부릅니다. 인간의 뇌는 자신이 직접 노동과 시간을 투여하여 무언가를 만들어냈을 때, 노력이 투입된 대상과 '자아 정체성'을 동일시하도록 설계되어 있습니다.
개발자에게 코드란 단순한 업무 결과물이 아닙니다. 밤을 새우며 고민했던 논리적 사고, 수많은 오류와의 사투, 그리고 마침내 컴파일에 성공했을 때 뿜어져 나온 도파민이 결합된 '지적 창작물'입니다. 문제는 이 창작물이 비즈니스 현장에서는 언젠가 폐기되어야 할 수단에 불과하다는 점입니다.
우리가 직접 만든 커스텀 모듈은 비유하자면 '손수 나사를 조여 만든 삐뚤어진 DIY 책상'과 같습니다. 내가 만들었기에 애착이 가고, 어디가 어떻게 부실한지 눈감아주게 되며, 위태롭게 흔들려도 "이 정도면 운치 있고 쓸 만하지"라며 스스로를 속입니다. 반면 최신 오픈소스나 표준 라이브러리는 공장에서 정밀 레이저로 가공된 '최첨단 수술 도구'입니다.
DIY 책상 위에서 정밀한 입술 수술을 할 수는 없는 노릇입니다. 정밀 수술 도구가 필요할 때조차 DIY 책상을 고집하는 순간, 기술 생태계에서의 고립과 생산성 붕괴가 시작됩니다. 실제 제가 거쳤던 한 조직에서는 4년 전 자체 제작한 사내 상태 관리 프레임워크를 버리고 전역 표준 라이브러리로 전면 교체하는 결단을 내린 적이 있습니다. 결과는 놀라웠습니다.
* **주당 유지보수 공수**: 프레임워크 버그 수정 및 예외 처리 시간 월 42시간 절감
* **신규 개발자 온보딩 속도**: 첫 PR 작성까지 걸리는 기간 6주에서 1.2주로 단축
* **시스템 빌드 에러율**: 내부 프레임워크 충돌 건수 73% 감소
숫자는 거짓말을 하지 않았습니다. 감정적인 애착을 걷어내고 냉정하게 수치를 측정했을 때, 우리가 '자체 아키텍처의 자부심'이라 부르던 것은 그저 '비효율적인 기술 부채의 덩어리'였음이 드러났습니다.
---
### 2. 수천 줄의 코드를 지키려다 팀 전체를 수렁에 빠뜨린 잔혹사
3년 전, 저는 대규모 커머스 플랫폼의 코어 아키텍처를 담당하는 리드 엔지니어였습니다. 당시 저희 팀은 외부 ORM(Object-Relational Mapping) 기술의 성능이 마음에 들지 않는다는 이유로, 직접 데이터베이스 쿼리를 최적화하여 처리하는 '자체 엔진'을 바닥부터 구축했습니다. 저를 포함한 핵심 개발자 3명이 두 달간 주말도 반납해가며 만든 작품이었습니다.
초기에는 확실히 빠른 처리 속도를 보여주었고, 우리는 내부 테크 세미나에서 성공 사례로 발표하며 자부심에 취해 있었습니다. 그러나 시간이 흐르며 생태계가 급변했습니다. 데이터베이스 버전이 올라가고, 마이크로서비스 아키텍처가 도입되었으며, 표준 ORM 라이브러리들은 비동기 처리와 자동 캐싱 기능을 무섭게 발전시켰습니다.
하지만 우리의 자체 엔진은 기술 변화를 따라가지 못했습니다. 새로운 데이터 타입이 추가될 때마다 우리가 직접 엔진 내부 파서를 수정해야 했고, 메모리 누수가 발생할 때마다 프로파일링 도구를 붙여 며칠씩 밤을 새워야 했습니다.
어느 날, 팀에 새로 합류한 실력 있는 데브옵스 엔지니어가 차분하게 기술 제안서를 내밀었습니다.
"선배님, 이 자체 엔진을 폐기하고 요즘 글로벌 표준으로 자리 잡은 오픈소스 ORM으로 전환하는 것을 제안합니다. 현재 우리 팀 개발 시간의 30%가 이 엔진의 버그를 고치는 데 쓰이고 있습니다."
그 순간 제 뇌 속에서는 거세한 저항 반응이 일어났습니다. 편도체가 하이재킹된 것처럼 방어적인 태도가 튀어나왔습니다.
"이 엔진이 우리 서비스 특성에 맞게 얼마나 세밀하게 최적화되어 있는지 몰라서 하는 소리입니다. 외부 라이브러리를 쓰면 우리 데이터베이스의 특수 쿼리를 처리할 수 없어요!"
저는 목소리를 높였고, 제안을 가져온 동료를 설득하려 애썼습니다. 하지만 일주일 뒤, 상용 환경에서 자체 엔진의 동시성 처리 오류로 인해 결제 트래픽 일부가 30분간 마비되는 치명적인 장애가 발생했습니다. 장장 8시간의 핫픽스 작업 끝에 버그를 잡았을 때, 모니터 화면에 비친 제 모습은 참담했습니다.
제가 지키려고 했던 것은 '서비스의 안정성'이나 '기술적 탁월함'이 아니었습니다. 그저 "내가 피땀 흘려 만든 작품이 틀리지 않았다"는 개인의 헛된 자존심과, 그동안 쏟아부은 수개월의 시간이 부정당하는 것에 대한 '매몰 비용 편향(Sunk Cost Fallacy)'이었을 뿐입니다.
다음 날 아침, 저는 팀원들을 모아놓고 고개를 숙였습니다. 그리고 사내 엔진의 폐기(Deprecation) 타임라인을 발표했습니다. 한 달에 걸쳐 표준 라이브러리로 마이그레이션을 완료한 날, 모니터에서 수천 줄의 사내 코드가 삭제(-4,820 lines)되는 순간을 보았습니다. 시원섭섭함 뒤에 밀려온 것은 괴로움이 아닌, 비로소 자유로워진 아키텍처의 가벼움이었습니다.
---
### 3. 자아와 코드를 분리하는 3단계 아키텍처 리셋 프레임워크
내가 만든 코드와 사랑에 빠져 눈이 멀어버리는 이케아 효과에서 벗어나려면, 단순한 의지만으로는 부족합니다. 개발자의 뇌가 스스로 감정적 애착을 끊어낼 수 있도록 돕는 객관적이고 연산적인 시스템이 필요합니다. 현장에서 즉시 적용할 수 있는 3단계 프레임워크를 제시합니다.
* **1단계: 기술의 '소유권(Ownership)'을 '관리권(Stewardship)'으로 전환하기**
* 내가 짠 코드는 나의 소유물이 아닙니다. 코드는 유기체처럼 변하고 언제든 더 나은 솔루션으로 대체될 수 있는 임시 수단입니다.
* PR(Pull Request) 리뷰 시 "제 코드의 논리는~" 대신 "현재 시스템의 이 구간은~"이라는 언어적 표현 개편을 적용하세요. 주어를 '나'에서 '시스템'으로 바꿀 때, 코드에 대한 비판을 자신에 대한 공격으로 받아들이는 편향을 차단할 수 있습니다.
* **2단계: 기술 부채의 정량적 평가 지수(KPI) 도입하기**
* 커스텀 모듈이나 사내 프레임워크를 유지할지, 표준 라이브러리로 대체할지 결정할 때 감정을 배제하는 공식을 만드세요.
* **[유지보수 위험도 점수 = (월간 버그 수정 시간 + 신규 입사자 교육 시간) / (최신 외부 도구 교체 시 예상 공수)]**
* 이 위험도 점수가 1.5를 넘어서면, 아무리 애착이 깊은 코드라도 예외 없이 폐기(Deprecation) 백로그에 등록하는 규칙을 팀의 가라운드 룰로 설정해야 합니다.
* **3단계: '코드 삭제(Code Deletion)'를 성과로 축하하는 문화 만들기**
* 이케아 효과는 무언가를 '손실'한다는 공포에서 증폭됩니다. 따라서 코드를 지우는 행위를 손실이 아닌 '복잡성의 감소'라는 이득으로 인식하도록 뇌의 보상 시스템을 재설계해야 합니다.
* 주간 스프린트 회고 시 가장 많은 레거시 커스텀 코드를 삭제하고 표준 도구로 대체한 팀원에게 '오늘의 클리너' 상을여여하거나, 커밋 로그의 삭제 라인 수(- lines)를 정량적 기여도로 인지하는 조직 문화를 구축하세요.
---
### 내일 출근해서 당장 실행할 수 있는 아키텍처 결단
엔지니어로서의 진정한 성숙함은 "내가 얼마나 복잡하고 거대한 시스템을 바닥부터 직접 만들 수 있는가"에서 나오지 않습니다. 오히려 "시스템의 목적을 위해 나의 자아와 애착이 담긴 코드를 얼마나 미련 없이 버릴 수 있는가"에서 증명됩니다.
내일 사무실로 출근하거나 IDE를 열었을 때, 당신이 가장 애지중지하고 자부심을 느끼는 그 커스텀 모듈을 냉정하게 바라보세요. 그것이 과연 현재 팀의 생산성과 서비스의 미래를 위해 최선의 선택입니까, 아니면 단순히 당신의 노력이 투입되었기에 버리지 못하는 DIY 책상입니까?
아래에 제공되는 [실전 체크리스트]와 [AI 프롬프트 템플릿]을 활용해, 당신의 팀이 지닌 인지적 이케아 효과를 지금 즉시 진단하고 냉정한 마이그레이션 계획을 수립해 보시길 바랍니다. 자아를 내려놓는 순간, 당신의 기술 아키텍처는 비로소 비상하기 시작할 것입니다.
```text
====================================================================
[실전 체크리스트: 자체 코드 이케아 효과 진단 및 리팩토링 평가]
====================================================================
다음 항목 중 3개 이상에 해당한다면, 당신과 팀은 '이케아 효과'와 '매몰 비용 편향'에 빠져 기술 부채를 방치하고 있을 가능성이 매우 높습니다.
[ ] 1. 사내 커스텀 모듈/프레임워크의 버그를 고치는 데 주당 5시간 이상을 사용하고 있다.
[ ] 2. 신규 개발자가 들어왔을 때, 표준 문서가 아닌 '특정 제작자의 구두 설명'에 의존해 온보딩을 진행한다.
[ ] 3. 검증된 최신 오픈소스 도입 제안이 나왔을 때 "우리 시스템은 특수해서 안 된다"는 말이 먼저 나온다.
[ ] 4. 코드를 수정하거나 삭제할 때 원래 작성자의 눈치를 보거나 감정적 마찰을 겪은 적이 있다.
[ ] 5. 사내 모듈의 성능이나 안정성을 객관적인 정량 수치(KPI)로 측정해 본 적이 6개월 이상 없다.
[ ] 6. "내가 고생해서 만든 코드"라는 이유로 작동은 하지만 비효율적인 유틸리티를 수개월째 남겨두고 있다.
--------------------------------------------------------------------
[실전 무기: 냉정한 기술 전환 평가를 위한 AI 프롬프트 템플릿]
--------------------------------------------------------------------
아래 프롬프트를 복사하여 Claude, ChatGPT 등 생성형 AI에 입력하세요. 감정을 배제하고 객관적인 아키텍처 교체 타당성을 분석해 줍니다.
[역할 정의]
당신은 최고 수준의 치밀함과 냉철함을 가진 20년 차 수석 IT 아키텍트이자 기술 이사회 고문입니다. 개인의 감정이나 매몰 비용 편향을 완전히 배제하고, 오직 비즈니스 효율성, 유지보수성, 인지적 부하 관점에서 기술 스택 전환을 평가합니다.
[분석 요청 사항]
우리가 자체 제작하여 사용 중인 [자체 제작 모듈/프레임워크 이름 또는 설명]을 최신 오픈소스/표준 라이브러리인 [대체하고자 하는 표준 기술 이름]으로 교체할지 여부를 평가하려 합니다.
다음 정보를 바탕으로 객관적인 보고서를 작성해 주세요.
1. 현재 자체 시스템 현황:
- 개발에 투입된 기간/인력: [예: 3개월 / 엔지니어 2명]
- 주요 기능: [예: 사내 전용 API 인증 및 Caching 처리]
- 현재 발생하는 페인포인트: [예: 신규 입사자 적응 불가, 최신 Async 처리 미지원, 주당 6시간 버그 수정]
2. 평가 및 분석 항목:
A. 이케아 효과 진단: 현재 자체 시스템을 고수하려는 논리 중 편향이나 감정적 애착에 해당하는 요소 도출
B. 정량적 유지보수 비용 비교: 자체 유지보수 vs 표준 기술 도입 시 1년 단위 공수(Man-Hour) 추정 비교
C. 마이그레이션 리스크 및 완화 전략: 교체 시 발생할 리스크 3가지와 단계별 폐기(Deprecation) 로드맵
D. 최종 추천안: [전환 강행 / 부분 유지 / 보존] 중 확실한 결론 제시
[출력 포맷]
- 감정적 수식어를 배제하고, 가차 없고 명확한 데이터 중심 보고서 형식으로 작성할 것.
- 마지막에는 개발팀이 내일 출근해서 실행할 수 있는 '코드 삭제 및 전환 Action Item 3가지'를 요약 제공할 것.
====================================================================
```
IT & Mind Trends
댓글 0