개발자가 하는 말, 번역해드립니다 - "기술 부채", "리팩토링", "레거시"의 진짜 의미

"대표님, 기술 부채가 심각합니다"

이 말을 들으면 대표님들은 보통 이렇게 생각합니다.

 

"기술 부채? 우리가 개발비를 못 준 건가? 아니면 서버비를 밀린 건가?"

 

아닙니다. 개발자가 말하는 기술 부채는 돈 문제가 아닙니다. 하지만 방치하면 정말로 돈 문제가 될 수 있습니다.

 

작년에 한 대표님께서 급하게 연락하셨습니다. 간단한 기능 하나 추가하는 데 개발자가 2달이 걸린다고 한다는 거였죠. "뭐가 그리 어렵냐"고 물으니 개발자는 "기술 부채 때문"이라고만 답했답니다. 대표님은 화가 나서 개발자를 바꾸려 했고, 개발자는 억울해서 퇴사를 고민했습니다.

 

문제는 둘 다 같은 언어를 쓰고 있지만, 다른 뜻으로 이해하고 있다는 거였습니다.

 

오늘은 개발자들이 자주 쓰는 용어들을 비개발자 대표님들이 이해할 수 있게 번역해드리겠습니다. 이 용어들을 이해하면, 개발팀과의 소통이 훨씬 수월해질 겁니다.

핵심 용어 번역 사전

1. 기술 부채 (Technical Debt)

개발자가 말할 때: "기술 부채가 쌓여서 개발 속도가 느려지고 있습니다."

 

실제 의미: 빨리 만들려고 대충 만든 코드들이 쌓여서, 이제 새로운 기능을 추가하기가 점점 어려워지고 있다는 뜻입니다.

 

비유로 설명하면: 집을 지을 때 기초공사를 대충하고 빨리 올린 건물입니다. 처음에는 빨랐지만, 나중에 2층을 더 올리려니 기초부터 다시 해야 합니다. 기술 부채는 바로 그 "부실한 기초공사"입니다.

 

실제 사례 - 저희 팀: 초기에 MVP를 2달 만에 만들 때, 저는 많은 기술 부채를 만들었습니다. 에러 처리는 대충, 테스트 코드는 없고, 데이터베이스 설계도 임시방편이었죠. 그래도 제품을 빨리 출시했고, 고객 반응을 확인할 수 있었습니다.

 

문제는 1년 후였습니다. 사용자가 100명에서 10,000명으로 늘자 시스템이 터지기 시작했습니다. 간단한 기능 하나 추가하는데도 3주가 걸렸죠. 왜? 코드가 너무 엉켜있어서 어디를 고치면 어디가 망가질지 예측이 안 됐기 때문입니다.

 

결국 3개월을 투자해서 시스템을 다시 정리했습니다. 그제야 개발 속도가 다시 빨라졌죠.

 

대표님이 들었을 때 해야 할 질문:

• "구체적으로 어떤 부분이 문제인가요?"
• "지금 안 고치면 어떤 일이 생기나요?"
• "고치는 데 얼마나 걸리고, 고치면 어떤 게 나아지나요?"
• "새 기능 개발과 병행할 수 있나요, 아니면 따로 시간이 필요한가요?"

주의: 개발자가 "기술 부채"를 핑계로 일을 안 하려는 건지, 정말 심각한 문제인지 구분해야 합니다. 구체적인 설명을 요구하세요.

2. 리팩토링 (Refactoring)

개발자가 말할 때: "이번 스프린트는 리팩토링에 집중하고 싶습니다."

 

실제 의미: 겉으로 보이는 기능은 그대로지만, 코드 내부를 깔끔하게 정리하겠다는 뜻입니다.

 

비유로 설명하면: 옷장 정리입니다. 옷의 종류는 그대로지만, 막 쌓여있던 걸 종류별로 개서 정리하는 겁니다. 당장은 옷이 늘어나지 않지만, 나중에 옷을 찾기가 훨씬 쉬워지죠.

 

왜 필요한가: 리팩토링을 안 하면 코드가 점점 복잡해집니다. 나중에는 버그 하나 고치는 데도 며칠씩 걸리게 됩니다.

 

실제 사례: 한 번은 로그인 기능에 버그가 생겼습니다. 단순한 버그였는데, 코드가 너무 엉켜있어서 고치는 데 2주가 걸렸죠. 리팩토링을 미뤄둔 대가였습니다.

 

그 후로 저는 매 스프린트의 20%를 리팩토링에 할당합니다. 당장 눈에 보이는 결과물은 없지만, 장기적으로 개발 속도를 유지하는 비결입니다.

 

대표님이 들었을 때 해야 할 반응:

• 좋은 반응: "얼마나 시간이 걸리나요? 그리고 이걸 하면 다음 개발이 얼마나 빨라지나요?"
• 나쁜 반응: "기능도 안 늘어나는데 왜 시간을 쓰나요? 그냥 새 기능 만들어주세요."

대표님을 위한 팁: 리팩토링은 투자입니다. 지금 시간을 쓰지만, 나중에 훨씬 빠르게 개발할 수 있게 됩니다. 단, 무한정 리팩토링만 하는 건 안 됩니다. 전체 개발 시간의 15-25% 정도가 적당합니다.

3. 레거시 (Legacy)

개발자가 말할 때: "이건 레거시 코드라서 손대기가 무섭습니다."

 

실제 의미: 오래되고 복잡해서 잘 이해가 안 되지만, 그래도 지금 돌아가고 있는 코드라는 뜻입니다. 고치면 뭐가 망가질지 몰라서 무섭습니다.

 

비유로 설명하면: 할아버지가 만들어둔 복잡한 배관 시스템입니다. 어떻게 돌아가는지는 잘 모르겠는데, 일단 물은 잘 나옵니다. 근데 하나 고쳤다가 집 전체 물이 안 나올까봐 무섭습니다.

 

왜 생기나:

1. 원래 만든 개발자가 퇴사함
2. 문서가 없음
3. 오래 전에 급하게 만들어서 코드가 복잡함
4. 여러 사람이 덧붙이면서 더 복잡해짐

실제 사례: 저희 서비스의 결제 시스템이 레거시였습니다. 3년 전에 퇴사한 개발자가 만들었고, 문서도 없었죠. 그런데 잘 돌아가서 아무도 손대지 않았습니다.

 

문제는 새로운 결제 방식을 추가해야 할 때였습니다. 코드를 열어보니 아무도 이해를 못했습니다. 결국 2주 동안 코드를 분석하고, 테스트를 만들고, 조심조심 수정했죠.

 

대표님이 들었을 때 해야 할 질문:

• "레거시를 그대로 두면 안 되나요?"
• "새로 만드는 것과 고치는 것 중 뭐가 나아요?"
• "레거시를 유지하는 비용은 얼마나 되나요?"

중요: 레거시라고 무조건 나쁜 건 아닙니다. 잘 돌아가고 있다면 굳이 손댈 필요 없습니다. 하지만 계속 수정이 필요하다면, 언젠가는 정리해야 합니다.

4. 스케일 (Scale / 확장성)

개발자가 말할 때: "이 구조는 스케일이 안 됩니다."

 

실제 의미: 지금은 사용자가 적어서 괜찮지만, 사용자가 많아지면 시스템이 감당을 못 한다는 뜻입니다.

 

비유로 설명하면: 엘리베이터 없는 3층 건물입니다. 사람이 적을 때는 괜찮지만, 100명씩 드나들면 계단으로는 감당이 안 됩니다. 엘리베이터(=확장 가능한 시스템)가 필요합니다.

 

실제 사례: 초기에 저는 서버 1대로 시작했습니다. 사용자 100명까지는 문제없었죠. 그런데 갑자기 기사에 나서 하루에 사용자 10,000명이 몰렸습니다. 서버가 죽었습니다.

 

급하게 서버를 늘렸지만, 데이터베이스 구조 자체가 많은 사용자를 감당할 수 없게 설계되어 있었습니다. 결국 3일간 서비스가 불안정했고, 2주 동안 밤샘 작업으로 시스템을 다시 만들었습니다.

 

대표님이 들었을 때 해야 할 질문:

• "우리 목표 사용자 수까지 버틸 수 있나요?"
• "지금 고치지 않으면 언제쯤 문제가 될까요?"
• "미리 대비하는 비용 vs 나중에 고치는 비용이 얼마나 차이나나요?"

대표님을 위한 팁: 초기에는 스케일을 너무 걱정할 필요 없습니다. PMF 찾기 전에 확장성 걱정하는 건 사치입니다. 하지만 트랙션이 생기기 시작하면, 그때는 투자해야 합니다.

5. 디버깅 (Debugging)

개발자가 말할 때: "하루종일 디버깅했는데도 못 찾았습니다."

 

실제 의미: 버그가 어디서 생기는지 찾는 중입니다. 코딩보다 탐정 놀이에 가까운 작업입니다.

 

비유로 설명하면: 물이 새는 집에서 어디서 물이 새는지 찾는 작업입니다. 벽을 뜯어보고, 배관을 확인하고, 하나하나 테스트합니다. 찾는 데 5분 걸릴 수도, 5일 걸릴 수도 있습니다.

 

왜 시간이 오래 걸리나:

1. 버그가 특정 조건에서만 나타남 (재현이 어려움)
2. 코드가 복잡해서 원인을 찾기 어려움
3. 여러 부분이 얽혀있어서 어디가 문제인지 모름

실제 사례: 한번은 "가끔" 로그인이 안 된다는 제보가 들어왔습니다. 저는 테스트해봤는데 잘 됐습니다. 다른 개발자도 잘 됐습니다. 그런데 고객은 계속 안 된다고 했죠.

 

3일을 디버깅했습니다. 알고 보니 특정 브라우저의 특정 버전에서만 발생하는 버그였습니다. 고치는 건 10분 걸렸지만, 찾는 데 3일이 걸렸습니다.

 

대표님이 들었을 때 해야 할 반응:

• 좋은 반응: "많이 답답하겠네요. 추가로 도움이 필요한 게 있나요?"
• 나쁜 반응: "하루종일 뭐 한 거예요? 아직도 못 찾았어요?"

중요: 디버깅은 시간이 예측 불가능합니다. 개발자가 게을러서 안 찾는 게 아니라, 정말 찾기 어려운 겁니다.

6. MVP (Minimum Viable Product)

개발자가 말할 때: "이건 MVP 수준으로만 만들겠습니다."

 

실제 의미: 핵심 기능만 있는 최소한의 제품을 만들겠다는 뜻입니다. 완벽하지 않지만, 고객 반응을 확인할 수 있을 정도는 됩니다.

 

비유로 설명하면: 완성된 자동차 대신 스케이트보드를 먼저 만드는 겁니다. 스케이트보드도 "이동"이라는 핵심 가치는 제공합니다. 고객 반응을 보고 나서 자전거, 오토바이, 자동차 순으로 발전시킵니다.

 

주의할 점: MVP는 "대충 만든 제품"이 아닙니다. 핵심 기능은 제대로 작동해야 합니다.

 

실제 사례: 저희 첫 제품의 MVP는 기능이 3개뿐이었습니다. 회원가입, 로그인, 핵심 기능 하나. 그게 전부였죠.

하지만 그 핵심 기능 하나는 완벽하게 작동했습니다. 고객들이 돈을 낼 만큼 가치있었죠. 그 반응을 확인한 후, 다른 기능들을 하나씩 추가했습니다.

 

대표님이 알아야 할 것: MVP는 시작점입니다. 고객 피드백을 빨리 받기 위한 전략이죠. 하지만 MVP 수준에서 멈춰서는 안 됩니다. 계속 개선해야 합니다.

7. API (Application Programming Interface)

개발자가 말할 때: "외부 서비스 API를 연동해야 합니다."

 

실제 의미: 다른 회사의 서비스를 우리 서비스에 연결하겠다는 뜻입니다.

 

비유로 설명하면: 전기 콘센트입니다. 콘센트 안에 어떤 복잡한 전기 시스템이 있는지 몰라도, 플러그만 꽂으면 전기를 쓸 수 있습니다. API도 마찬가지로, 내부가 어떻게 작동하는지 몰라도 사용할 수 있게 만든 연결 통로입니다.

 

실제 예시:

• 카카오톡 로그인 API: 우리가 직접 로그인 시스템을 만들지 않고 카카오 로그인을 쓸 수 있음
• 결제 API: 토스, 네이버페이 등의 결제를 우리 서비스에 연결
• 지도 API: 구글맵, 네이버맵을 우리 서비스에 표시

대표님이 알아야 할 것: API 연동은 편하지만 비용이 듭니다. 사용량에 따라 돈을 내야 하고, 외부 서비스가 문제 생기면 우리도 영향받습니다.

8. 배포 (Deploy / 배포)

개발자가 말할 때: "오늘 오후에 배포하겠습니다."

 

실제 의미: 개발이 끝난 코드를 실제 서비스에 올려서 고객들이 쓸 수 있게 하겠다는 뜻입니다.

 

비유로 설명하면: 영화를 찍고(개발), 편집하고(테스트), 최종적으로 극장에 거는(배포) 것입니다. 개봉 전까지는 아무도 영화를 볼 수 없죠.

 

왜 조심스러운 작업인가: 배포할 때 뭔가 잘못되면 서비스 전체가 멈출 수 있습니다. 그래서 보통 사용자가 적은 새벽이나 점심시간에 배포합니다.

 

실제 사례: 한번은 금요일 저녁에 급하게 배포했습니다. 대표님이 "주말 전에 고객한테 보여줘야 한다"고 해서요. 배포 직후 버그가 발견됐고, 저는 주말 내내 밤샘으로 고쳤습니다.

그 후로 저는 "금요일 오후 배포 금지" 규칙을 만들었습니다. 아무리 급해도 목요일까지 배포하거나, 월요일로 미룹니다.

 

대표님을 위한 팁:

• 금요일 오후/저녁 배포는 위험합니다
• 중요한 배포 전후로는 개발자들이 긴장합니다. 배려해주세요
• "빨리 배포하라"고 압박하지 마세요. 버그 생기면 더 오래 걸립니다

9. 테스트 코드 (Test Code)

개발자가 말할 때: "테스트 코드를 작성해야 해서 시간이 더 걸립니다."

 

실제 의미: 만든 기능이 제대로 작동하는지 자동으로 확인하는 코드를 만들겠다는 뜻입니다.

 

비유로 설명하면: 자동차 공장의 품질 검사 로봇입니다. 사람이 일일이 확인하는 대신, 로봇이 자동으로 브레이크, 엔진, 조향 등을 테스트합니다. 처음 로봇 만들 때는 시간 걸리지만, 나중에는 계속 재활용할 수 있습니다.

 

왜 필요한가: 코드를 하나 수정하면 다른 부분이 망가질 수 있습니다. 테스트 코드가 있으면 뭐가 망가졌는지 바로 알 수 있습니다.

 

실제 사례: 초기에는 테스트 코드 없이 개발했습니다. 빨랐죠. 그런데 팀이 5명으로 늘자 문제가 생겼습니다. A 개발자가 수정한 게 B 개발자 코드를 망가뜨렸는데, 배포하고 나서야 알았습니다.

테스트 코드를 도입한 후로는 이런 문제가 90% 줄었습니다. 지금은 전체 개발 시간의 30%를 테스트 코드 작성에 씁니다.

 

대표님이 알아야 할 것: 테스트 코드는 보험입니다. 당장은 시간이 걸리지만, 장기적으로 버그를 줄이고 개발 속도를 높입니다.

10. 핫픽스 (Hotfix)

개발자가 말할 때: "긴급 핫픽스 배포합니다."

 

실제 의미: 서비스에 심각한 버그가 생겨서 급하게 고치고 배포하겠다는 뜻입니다. 정상 프로세스를 건너뛰고 빠르게 처리합니다.

 

비유로 설명하면: 응급실입니다. 원래는 진료 예약하고 차례를 기다려야 하지만, 응급 환자는 바로 치료합니다.

 

언제 필요한가:

• 서비스가 완전히 멈춤
• 보안 문제 발견
• 돈과 관련된 중대한 버그
• 많은 사용자가 영향받는 치명적 버그

실제 사례: 한번은 결제 버그가 발견됐습니다. 고객이 돈은 냈는데 제품을 못 받는 상황이었죠. 새벽 2시였지만 바로 핫픽스 했습니다.

정상적이라면 코드 리뷰하고, 테스트하고, 다음날 배포했겠지만, 이건 한시가 급했습니다. 30분 만에 고치고 배포했습니다.

 

대표님이 알아야 할 것: 핫픽스는 예외적인 상황입니다. 자주 일어나면 개발 프로세스에 문제가 있는 겁니다.

대화 예시: 번역 전 vs 번역 후

상황 1: 기능 개발이 늦어질 때

번역 전:

• 개발자: "기술 부채 때문에 2주 더 걸립니다."
• 대표: "무슨 소리예요? 간단한 기능인데?"
• 개발자: "레거시 코드라서 리팩토링이 필요해요."
• 대표: "자꾸 이상한 용어 쓰지 말고 그냥 만들어주세요!"

번역 후:

• 개발자: "기존 코드가 복잡하게 얽혀있어서, 이 기능을 추가하려면 먼저 정리가 필요합니다. 2주 더 걸릴 것 같습니다."
• 대표: "정리 안 하고 그냥 추가하면 안 돼요?"
• 개발자: "가능은 한데, 그러면 나중에 더 큰 문제가 생길 수 있습니다. 지금 2주 투자하면, 앞으로 비슷한 기능은 3일이면 만들 수 있습니다."
• 대표: "알겠습니다. 그럼 정리하면서 만들어주세요. 다만 꼭 필요한 정리만 하고, 일정은 체크하면서 진행합시다."

상황 2: 서버가 느릴 때

번역 전:

• 사용자: "앱이 너무 느려요!"
• 대표: "개발팀, 왜 이렇게 느려요?"
• 개발자: "스케일 이슈입니다. 아키텍처를 바꿔야 해요."
• 대표: "그게 뭔 소리예요? 그냥 서버 좀 늘려요!"
• 개발자: "그렇게 간단한 문제가 아닙니다..."

번역 후:

• 개발자: "사용자가 예상보다 많이 늘어서 현재 시스템이 감당을 못 하고 있습니다. 서버를 늘리는 것만으로는 부족하고, 시스템 구조 자체를 바꿔야 합니다."
• 대표: "구조를 바꾸는 게 얼마나 걸려요? 그 동안 서비스는 어떻게 하고요?"
• 개발자: "2주 정도 걸립니다. 그 동안은 임시로 서버를 늘려서 버티겠습니다. 비용이 평소보다 3배 정도 나갈 것 같습니다."
• 대표: "알겠습니다. 2주 안에 끝낼 수 있을까요? 정기적으로 진행 상황 공유해주세요."

대표님을 위한 실전 팁

Tip 1: 개발자에게 비유를 요청하세요

기술 용어를 이해 못 하겠으면, "비개발자도 알 수 있게 비유해서 설명해줄 수 있나요?"라고 물어보세요. 좋은 개발자는 비유로 설명할 수 있습니다.

Tip 2: "왜"를 세 번 물어보세요

• "왜 리팩토링이 필요한가요?"
• "왜 지금 해야 하나요?"
• "왜 2주나 걸리나요?"

세 번 물으면 진짜 이유가 나옵니다. 개발자도 자신의 생각을 정리할 수 있고요.

Tip 3: 구체적인 숫자를 요구하세요

• "얼마나 걸리나요?" → "2주요" (좋음)
• "많이 걸려요" (나쁨)

개발자가 숫자를 못 대면, 제대로 파악 못 한 겁니다.

Tip 4: 트레이드오프를 이해하세요

개발에는 항상 트레이드오프가 있습니다.

• 빠르게 vs 완벽하게
• 기능 추가 vs 안정성 개선
• 비용 절감 vs 성능 향상

무엇을 우선시할지 명확히 소통하세요.

Tip 5: 정기적인 기술 리뷰 미팅

월 1회 정도 CTO와 기술 현황을 리뷰하는 시간을 가지세요.

• 현재 기술 부채 상태
• 향후 3개월 기술 투자 계획
• 예상되는 기술적 리스크

이 시간에 용어 설명도 함께 받으세요.

개발자분들께

대표님들이 기술 용어를 모르는 건 당연합니다. 우리도 회계 용어, 법률 용어 잘 모르잖아요?

비개발자에게 설명할 때는:

1. 전문 용어 최소화
2. 비유 활용
3. 구체적인 예시
4. 비즈니스 임팩트 설명

"기술 부채가 심각합니다" 대신 "코드가 복잡하게 얽혀있어서, 새 기능 추가할 때마다 예상치 못한 버그가 생깁니다. 이번 주 발견된 버그 5개 중 4개가 이 문제 때문이었습니다. 2주 투자해서 정리하면, 앞으로 버그가 50% 줄고 개발 속도는 30% 빨라질 것 같습니다."

이렇게 말하면 대표님도 이해하고 지원해줍니다.

마치며

개발자와 비개발자가 같은 언어를 쓰는 것 같지만, 실제로는 다른 의미로 이해할 때가 많습니다. 이 간극이 오해를 만들고, 오해가 갈등을 만듭니다.

 

하지만 서로의 언어를 조금씩 배우려는 노력만 있다면, 훨씬 더 건설적인 대화를 할 수 있습니다.

 

대표님들께: 개발자가 이상한 용어 쓴다고 짜증내지 말고, "무슨 뜻인지 쉽게 설명해줄 수 있나요?"라고 물어보세요.

 

개발자들께: 대표님이 기술을 모른다고 답답해하지 말고, 비개발자도 이해할 수 있게 설명하는 연습을 하세요.

 

결국 우리는 같은 배를 탄 사람들입니다. 서로의 언어를 배우는 게 회사를 성공으로 이끄는 첫 걸음입니다.

---

다음 글에서는 "비개발 대표의 첫 개발자 채용 가이드"를 통해 이력서 보는 법부터 면접 질문까지 실전 노하우를 알려드리겠습니다.

---

이 글은 '모두의 CTO' 시리즈의 네 번째 글입니다.

 

관련 글:

• 스타트업에 CTO가 정말 필요한가?
• 좋은 CTO와 나쁜 CTO를 구분하는 법
• CTO 지분은 얼마나 줘야 할까?