개발자라면 한 번쯤 남 탓해 본 대상들 (Every Software Developer Has Blamed…)
Sylwia Laskowska가 개발자라면 누구나 한 번쯤 탓해 본 대상 12가지를 유머러스하게 정리했습니다. 마지막에는 기본적 귀인 오류를 짚으며 동료를 조금 더 너그럽게 보자고 제안합니다.
Every Software Developer Has Blamed…
I got back from FrontKon in Prague today (well, technically yesterday, since I'm publishing this...
개요 #
코드가 엉망이면 일단 누군가를 탓하고 본다. 개발자라면 다들 겪어 봤을 장면입니다. 프런트엔드 개발자 Sylwia Laskowska가 자신의 연재 "You're a Real Software Developer Only If…"의 새 편으로, 개발자가 한 번쯤은 탓해 봤을 대상 12가지를 골라 정리했습니다.
글을 쓴 시점에 저자는 프라하에서 열린 FrontKon 콘퍼런스에서 막 돌아온 참이었습니다. 패널 토론과 발표를 모두 잘 마쳤지만, 그단스크행 비행기가 새벽 6시에 뜨는 바람에 새벽 3시 반에도 아직 프라하에 있었다고 합니다. 평소 쓰던 기술 글은 자료 조사가 더 필요해 다음 주로 미루고, 독자들이 기다리던 가벼운 시리즈를 먼저 내놓았습니다.
개발자가 탓하는 12가지 #
사람과 조직 #
1. 다른 개발자. 코드가 형편없으면 내 잘못일 리 없습니다. 같은 팀 동료든, 옆 팀 사람이든, 이전에 프로젝트를 맡았던 개발자든 누군가 망쳐 놓았을 겁니다. 그런데 막상 확인해 보면 그 "다른 개발자"가 6개월 전의 나인 경우가 꽤 많습니다.
2. 회사. 프로세스는 엉망이고 표준은 없고, 경영진은 뭘 하는지 모릅니다. 불쌍한 개발자는 이 거대한 기계에 던져져 끝없이 싸워야 하죠. 다만 1인 사업자라면 그 회사가 바로 나라서 조금 민망해집니다.
5. 클라이언트. 자꾸 뭘 요구하고 매사에 불평하는 클라이언트만 없으면 일이 훨씬 수월하고 즐거울 텐데 말입니다.
8. 요구사항. 너무 모호하거나, 엉성하게 쓰였거나, 이해관계자가 내놓은 황당한 아이디어에서 출발했거나. 설령 요구사항이 완벽하더라도 문서 어딘가에는 빠진 내용이 있기 마련입니다.
코드와 기술 #
Photo by Nemuel Sereti on Pexels
3. 레거시 코드. 만든 지 6개월밖에 안 된 애플리케이션에도 레거시 코드는 어김없이 있습니다. 그리고 모든 버그와 지연, 놓친 마감은 당연히 그 레거시 코드 탓입니다.
4. 프레임워크. 버그투성이에 예측도 안 되고, 필요한 기능은 절반쯤 빠져 있습니다. 내가 프레임워크를 직접 만들면 정말 대단할 텐데, 아직 안 만든 이유는 간단합니다. 그런 약속을 한 적이 없으니까요.
6. 백엔드. 저자가 문제가 생기면 제일 먼저 의심하는 대상입니다. 뭔가 안 되면 백엔드 짠 사람 잘못일 수밖에 없습니다. 설마 내 코드에 문제가 있다는 건 아니겠죠?
7. 프런트엔드. 버그 리포트가 들어오면 백엔드 개발자도 정확히 똑같이 생각합니다. AI 시대에 원하든 원치 않든 많은 개발자가 풀스택이 됐지만, 마음은 여전히 어느 한쪽 "엔드"에 조금 더 가 있다고 저자는 말합니다.
9. 캐시. "캐시 지워 보세요"라는 말을 한 번도 안 해 봤다면 개발자라고 할 수 있을까요?
10. CORS. 원인 모를 에러가 뜨면 주니어 개발자가 가장 먼저 의심하는 대상입니다. 어제까지 멀쩡히 돌아갔다는 사실은 신경 쓰지 않습니다. 아마 CORS 문제일 겁니다.
11. 브라우저. 너무 뻔하죠. 사람들이 아직도 Safari를 고집하는 게 우리 잘못은 아니잖아요?
그리고 마지막은, 나 자신 #
12번째 항목에서 저자는 잠시 진지해집니다. 불평에는 두 종류가 있다는 겁니다. 하나는 날씨 탓하듯 가볍게 투덜대는 불평입니다. 저자는 폴란드에서는 불평이 거의 스몰토크나 다름없다고 덧붙였습니다.
다른 하나는 좀 더 생각해 볼 만한 불평입니다. 저자는 프로젝트나 함께 일하는 사람이 정말 유해한 경우도 분명히 있고, 그럴 때는 앞으로 어떻게 할지 진지하게 고민해야 한다고 선을 그었습니다. 하지만 그렇지 않은 경우라면, 내가 탓하는 그 모든 대상 사이에서 나는 어디에 서 있는지 잠깐 멈춰서 돌아볼 필요가 있다고 말합니다.
기본적 귀인 오류와 행위자-관찰자 편향 #
저자는 두 가지 심리학 개념을 소개합니다.
- 기본적 귀인 오류(fundamental attribution error): 다른 사람의 행동을 설명할 때 그 사람의 성격이나 기질은 과대평가하고, 처한 상황은 과소평가하는 경향입니다.
- 행위자-관찰자 편향(actor–observer bias): 내 행동은 상황 탓으로 설명하면서, 남의 행동은 그 사람의 성격 탓으로 설명하는 경향입니다.
내가 일을 그르쳤을 때를 떠올려 보면 이해가 쉽습니다. 코드가 썩 훌륭하지 않았거나 마감을 놓쳤을 때, 우리는 대개 그럴듯한 이유를 댈 수 있고 그 이유는 실제로 타당한 경우가 많습니다. 몸이 좀 안 좋아서 집중이 안 됐을 수도 있고, 배관공이 말을 멈추지 않아 오전 절반을 날렸을 수도 있고, 라이브러리 문서가 형편없었을 수도 있습니다.
그런데 다른 개발자가 실수하면 어떨까요. 안타깝게도 "진짜 바보 아냐?"라는 생각부터 드는 경우가 많습니다.
그 개발자에게도 삶이 있습니다. 우는 아이가 있고, 늦게 나타나는 배관공이 있고, 우리가 전혀 모르는 수많은 사정이 있습니다. 우리는 그 사람의 생각이나 상황을 알 수 없으니 뇌가 지름길을 택합니다. "무슨 일이 있었나 보다" 대신 "이 사람은 그냥 무능하다"고 결론 내려 버리는 거죠.
저자의 마무리 #
저자는 거창한 철학적 결론을 붙여 보려 했지만, 떠오르는 문장마다 "Sylwia 코엘료"가 쓴 것처럼 들려서 그만뒀다고 합니다. 대신 짧게 정리했습니다. 서로를 조금만 더 이해해 보자는 겁니다.
그리고 다음에 다른 개발자를 탓하고 싶어질 때 이것만 기억하라고 덧붙입니다. 지금 이 순간에도 어딘가에서 다른 개발자가 나를 탓하고 있을 거라고요.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.