스택오버플로우 없는 개발자는 존재할까
- 01 Dec, 2025
스택오버플로우 없는 개발자는 존재할까
매일 아침 9시에 회사에 도착하면 커피를 한 잔 내려 마신다. 그리고 슬랙을 켠다. 어김없이 누군가는 물어본다. “개발님, 이거 어떻게 하죠?” 나는 그럼 “아 그거요”라고 한다. 그 순간 손가락은 자동으로 움직인다. 구글 탭을 열고, 스택오버플로우에 들어가고, 검색창에 키워드를 친다. 5초, 10초 지나면 누군가는 이미 같은 문제를 겪었고, 2015년에 누군가가 정답을 남겨놨다. 나는 그 링크를 복사해서 슬랙에 붙여넣는다. “여기 봐보세요.”
마치 내가 방금 그 코드를 생각해낸 것처럼.
개발자의 비밀, 스택오버플로우
7년 개발 경력이라고 하면 사람들은 내가 거의 모든 에러를 처리할 수 있다고 생각한다. 솔직히 말하자면, 틀렸다. 나는 거의 모든 에러를 검색할 수 있다. 차이가 크다.
후배가 처음 입사했을 때 보여준 표정을 아직도 기억한다. 내가 NullPointerException으로 한 시간을 고민하다가 결국 스택오버플로우를 켰을 때, 후배가 물었다. “어? 시니어 분도 검색하세요?” 그 순간의 당혹스러운 감정은 이루 말할 수 없었다. 내 신비로움이 한 순간에 무너져 내렸다.
하지만 생각해보니 이건 수치스러운 게 아니었다. 이건 효율이었다.
프로그래밍이 정말로 유명해진 건 스택오버플로우 같은 플랫폼이 생겨난 후부터다. 그 전에는 어떻게 했을까? 동료에게 물었을까? 책을 뒤졌을까? 아니면 그냥 에러를 품고 살았을까? 요점은 이거다. 모든 개발자는 스택오버플로우를 쓴다. 쓰지 않는 개발자는 거짓말쟁이다.
나는 이제 이 사실이 자랑스럽다. 내가 모르는 걸 빠르게 찾을 수 있는 능력, 그게 진짜 시니어의 실력이 아닐까?
‘아 그거요’ 신드롬
회사에서 내 입버릇이 뭐냐고 물으면 ‘아 그거요’라고 답할 것 같다. 진짜 입버릇이 그거다.
기획자가 “김개발님, 이거 간단하게 수정 가능하죠?”라고 물을 때. 나는 “아 그거요”라고 한다. 속으로는 ‘간단한 게 뭔데 아무것도 간단한 게 없는데’라고 생각하면서.
근데 이 ‘아 그거요’라는 말이 나올 때, 사실 나는 이미 구글을 켠 상태다. 손가락은 스택오버플로우 URL을 치고 있다. 그리고 몇 분 뒤, 나는 마치 내가 방금 이 솔루션을 생각해낸 것처럼 설명한다. “네, 이렇게 하면 돼요.”
동료들은 나를 신뢰한다. 나는 빠르기 때문이다. 빠른 것처럼 보이기 때문이다. 사실 나는 빠르게 검색할 뿐이다.
회의 중에 라포톱으로 딴 짓하는 척하면서 코드를 보는 것도 그래서다. 누군가가 기술적인 질문을 던질 때, 나는 회의실에서 나가지 않고도 답할 수 있어야 한다. 그래야 존재감이 있다. 슬랙 알림보다 회의 중 질문이 더 스트레스다. 왜냐하면 구글을 켤 시간이 없기 때문이다.
레거시 코드와 스택오버플로우의 한계
그런데 여기서 흥미로운 지점이 있다. 모든 게 스택오버플로우로 해결되는 건 아니라는 것이다.
작년에 우리 회사 시스템에 심각한 버그가 발생했다. Redis 캐시가 특정 상황에서 스테일(stale) 데이터를 반환하는 문제였다. 처음엔 간단한 TTL 설정 문제인 줄 알았다. 스택오버플로우에서 관련 답변들을 찾았다. 하지만 우리 상황과 맞지 않았다. 우리는 레거시 코드를 건드리고 있었기 때문이다.
그 순간 나는 깨달았다. 스택오버플로우는 일반적인 문제를 푸는 거다. 하지만 개발자가 실제로 맞닥뜨리는 건 특수한 문제다. 우리 회사의 특수한 아키텍처, 우리 팀의 특수한 레거시 코드. 이건 누구도 미리 답해줄 수 없다.
그때서야 내가 진짜로 생각해야 했다. 검색하는 게 아니라, 논리를 조립해야 했다. 에러 로그를 읽고, 데이터 플로우를 추적하고, 테스트를 써야 했다. 그게 7년의 경력이 의미를 갖는 순간이었다.
스택오버플로우 없이도 문제를 풀 수 있다는 걸 증명해야 했다.
팀 채널에 링크 붙여넣는 나
근데 여기서 또 다른 문제가 생겼다. 바로 내가 아는 것처럼 보여야 한다는 압박이다.
“김개발님, 이거 어떻게 하죠?”라는 질문이 나오면, 내가 “음… 잘 모르는데 한번 알아봐야겠네요”라고 답하면 어떨까? 솔직한 답변이지만, 팀의 신뢰도는 하락한다. 그래서 나는 재빨리 스택오버플로우를 켠다. 그리고 링크를 붙여넣는다.
“여기 봐보세요. 이런 식으로 하면 돼요.”
후배들은 고마워한다. 나는 영웅이 된다. 아무도 내가 지금 그 링크를 처음 읽고 있다는 걸 모른다.
이게 나쁜 건 아니다. 오히려 이게 효율적인 개발 문화를 만드는 방법이다. 스택오버플로우라는 거인의 어깨 위에 서서, 우리는 더 높이 본다. 우리는 개별 문제를 푸는 시간을 줄이고, 아키텍처와 설계를 고민할 시간을 얻는다.
하지만 한 가지 확실한 건, 그 링크 뒤의 진짜 지식을 이해해야 한다는 것이다. 링크를 붙여넣는 건 쉽다. 하지만 왜 그 솔루션이 작동하는지 설명할 수 있어야 한다. 그게 바로 시니어와 주니어의 차이다.
스택오버플로우를 넘어서
지난 3년간 나는 사이드 프로젝트를 3번 시작했다. 그리고 3번 모두 접었다. 왜냐하면 사이드 프로젝트에서는 스택오버플로우가 덜 효과적이기 때문이다. 회사 일과 달리, 내가 정말로 무언가를 만들어야 하기 때문이다.
회사에선 기존 구조를 이해하고 거기에 기능을 추가하면 된다. 하지만 새 프로젝트를 시작하면 처음부터 아키텍처를 설계해야 한다. 데이터베이스 스키마를 그려야 한다. API 엔드포인트를 설계해야 한다. 이건 스택오버플로우로 해결되지 않는다.
그래서 나는 프로젝트를 접었다. 불편한 진실을 마주했기 때문이다. 내가 진짜로 무언가를 만들지는 못한다는 것을.
하지만 요즘 생각이 바뀌고 있다. 회사에서 시스템을 유지보수하고 개선하는 것도 충분히 가치 있는 일이라는 걸 깨달았기 때문이다. 누군가는 새로운 기술을 개척해야 하고, 누군가는 기존 시스템을 견고하게 유지해야 한다. 나는 후자를 잘 하는 개발자다. 그리고 그건 나쁜 게 아니다.
스택오버플로우는 내 도구다. 좋은 도구를 쓰는 게 효율적인 거다.
결국, 그래서 뭐어?
어제 기획자가 또 물었다. “이 기능, 어렵죠?” 나는 답했다. “아 그거요, 간단해요.” 내 손가락은 이미 스택오버플로우 URL을 치고 있었다.
5분 뒤, 나는 솔루션을 제시했다. 기획자는 놀랐다. 동료들은 감탄했다. 나는 아무 말도 하지 않았다. 필요 없었다. 그들의 신뢰가 내 상이었다.
근데 오늘따라 한 가지 생각이 떠나지 않는다. 혹시 내가 7년간 같은 걸 반복하고 있는 건 아닐까? 검색 능력만 늘고, 실제 지식은 쌓이지 않고 있는 건 아닐까?
아니다. 그건 아니다. 나는 분명히 성장했다. 스택오버플로우 링크를 붙여넣을 때, 이제는 그게 왜 작동하는지 안다. 처음엔 몰랐지만. 경험이 쌓이면서 링크 뒤의 지식도 깊어졌다.
스택오버플로우는 내가 알고 있는 것들의 색인이 되었다. 나는 더 이상 순수하게 검색만 하지 않는다. 나는 확인한다.
그 차이가 전부다.
스택오버플로우 없는 개발자는 존재할 수 있지만, 그런 개발자는 아마 매우 외로울 것 같다.