안하겠다는거 아니잖아요ㅠㅠ
‘아니 대체 왜 안된다는 거에요... 여기 이 앱 보면 되잖아요?’ 이 말은 개발자들이 가장 듣기 힘들어하는 말 중 하나다. 특히 하기 싫어서가 아니라 우리 회사가 갖고있는 기술적 제약과 한계를 설명했을 때 돌아오는 이 대답은 개발자들의 전문성을 무시하는 것처럼 들린다. 하지만 기획자 입장에서는 다른 서비스의 사례를 들며 가능성을 타진하는 것이 당연한 일이며 벤치마킹 대상을 찾는 이 활동이 오히려 칭찬받아 마땅한 행동이다. 이처럼 서로의 입장 차이로 인해 발생하는 갈등은 대부분 기술적 복잡성에 대한 이해 차이에서 비롯된다. 왜냐하면 비개발자가 이를 이해하기엔 당연한 한계가 있기 때문이다.
겉으로 보이는 것과 실제 구현의 복잡성은 큰 차이가 있다. 사용자 입장에서는 단순해 보이는 기능이 개발 관점에서는 매우 복잡한 경우가 많다. 버튼 하나를 추가하는 것도, 텍스트 하나를 수정하는 것도 개발자에게는 여러 가지 기술적 고려사항이 필요할 때가 있다.
왜 개발자들은 자주 “안된다”고 말할 수밖에 없을까? 이는 단순히 개발자가 귀찮아서가 아니다. 보안, 성능, 확장성 등 눈에 보이지 않는 많은 제약사항들이 존재하기 때문이다. 이러한 제약사항들을 이해받지 못할 때 개발자들은 깊은 좌절감을 느낀다.
이 글에서는 개발자들이 마주하는 기술적 제약과 복잡성이 무엇인지, 그리고 왜 이것을 설명하고 이해받는 것이 어려운지 알아보려 한다.
보이지 않는 기술적 제약
개발자들이 가장 먼저 고려하는 것은 보안과 안정성이다. 특히 개인정보나 결제 관련 기능은 매우 엄격한 기준을 따라야 한다. 간단한 기능 하나를 추가하더라도 회사 내부 보안팀의 평가 기준이나 PCI DSS와 같은 보안 규정을 준수해야 하고, 해킹이나 데이터 유출 위험도 고려해야 한다. 이는 단순히 ‘조심해서 개발하면 되는’ 문제가 아니라, 체계적인 설계와 검증이 필요한 영역이다.
성능과 확장성도 중요한 제약사항이다. “지금은 사용자가 얼마 없으니까 괜찮아요”같은 이야기를 하더라도 나중에 사용자가 많아졌을때 그런 말을 했다는 사실을 보통 기획자는 기억하지 않는다. 트래픽이 갑자기 증가하거나, 데이터가 늘어났을 때도 안정적으로 동작하도록 보장하는 것은 온전히 개발자의 역할이다.
단순해 보이는 요청의 실제
“큰 수정 아니고 이거 조금 바꾸면 되는거 아니에요? 좀 해주세요“라는 요청은 빙산의 일각만 보는 것과 같다. 버튼 하나를 추가하기 위해서는 화면 설계 변경, 이벤트 처리, 예외 상황 대응, 다양한 환경에서의 테스트 등 수많은 작업이 필요하다. 특히 여러 시스템이 연동된 환경에서는 하나의 변경이 연쇄적인 영향을 미칠 수 있다. 개발자들은 그래서 안 하겠다는게 아니다. 다만 그렇게 간단한 일은 아니라는 걸 이해받고 싶어할 뿐이다.
깊이 들어가면 데이터 구조의 변경은 더욱 신중해야 한다. “이 항목 하나만 추가하면 되잖아요?“라고 생각할 수 있지만, 데이터베이스 스키마 변경은 기존 데이터의 마이그레이션, 관련 기능의 수정, 백업 시스템 변경 등 광범위한 작업을 수반한다. 게다가 한번 잘못 설계된 데이터 구조는 나중에 수정하기가 매우 어렵다.
설명해도 이해받지 못할 때
“전에 하시던 A과장님은 금방 할 수 있다던데…“라는 말은 현재 이 일을 맡고있는 개발자의 전문성을 부정하는 것과 같다. 각각의 시스템은 서로 다른 기술 스택, 아키텍처, 제약사항을 가지고 있다. 전임자가 가능하다고 이야기했다고 해서 현재 환경에서도 가능하리라는 보장은 없다. 말로 가능하다고 말하는건 쉽다. 안된다는것을 설명하는것은 부존재를 증명하는 것 만큼 어렵다.
특히 기술 부채를 설명하는 것은 더욱 어렵다. 당장은 동작하지만 미래에 문제가 될 수 있는 코드, 리팩토링이 필요한 부분을 설명하려고 해도 “지금 잘 돌아가는데 뭐가 문제예요?“라는 반응을 마주하게 된다. 이는 마치 눈에 보이지 않는 건물의 균열을 설명하는 것처럼 어려운 일이다.
상호 이해를 위한 제안
기술적 제약과 복잡성을 설명할 때는 비즈니스 관점에서 접근하는 것이 효과적이다. 보안 이슈는 잠재적인 손실로, 성능 문제는 사용자 이탈로, 기술 부채는 미래의 개발 비용 증가로 설명할 수 있다. 또한 문제를 지적하는 것에서 그치지 않고, 실현 가능한 대안을 함께 제시하는 것이 중요하다.
장기적인 관점에서 보면, 당장의 편의보다는 지속 가능한 개발이 더 중요하다. 임시방편적인 해결책은 나중에 더 큰 비용을 초래할 수 있다. 기획자와 개발자가 서로의 입장을 이해하고, 함께 최적의 해결책을 찾아가는 자세가 필요하다. 이는 단순히 현재의 문제를 해결하는 것을 넘어, 더 나은 제품을 만들어가는 기초가 될 것이다.