복잡한 기술이 해결책이 아닐 때 - Part 1
기술보다 본질을 이해한 컨설팅
이 일화는 모두 당사자의 허락을 받아 게시되었습니다.
내 주변 사람들은 경력과 상관없이, 내가 개발자라는 이유만으로 기술적인 조언을 부탁하곤 한다.
최근만 해도 업체와 개인을 도와준 일이 각각 있는데, 우선 업체의 사례부터 보겠다.
몇 달 전 무직 상태라 단기 소득이 필요해 소규모 프리랜스 공고에 지원했다가 뜻밖에도 컨설팅을 수행하게 된 일화이다.
디지털 전환이 막막했던 사장님
나 또한 한때는 기술로 모든 문제를 해결할 수 있다고 믿었다.
아마 그 분도 같은 생각이었을 것이다.
이커머스 데이터 분석 자동화를 맡기고 싶어요.
오랜 시간 오프라인 매장을 운영해온 사장님이었다. 최근 시장 변화로 이커머스 진출이 절실해졌지만 첫 시도가 실패했고, 기술적 해결책을 찾고 있었다.
이전 업체들은 "요구사항을 완벽히 기술적으로 적어달라"거나 "다 해드린다"고 했지만 결과는 실망스러웠다고 했다. 의뢰를 위해 GPT로 직접 워크플로우를 작성해봤지만 그것조차 맞는지 확신이 없다고 했다.
10분이 90분이 된 통화
원래는 간단한 프리랜싱 일정 논의가 될 예정이었다. 하지만 내가 비즈니스 관련 경험이 있음을 언급하자 대화가 깊어졌다. 90분 동안 그의 사업 배경, 현재의 어려움, 기술에 대한 기대와 좌절을 들었다.
(나는 대학생활 중 사회적 문제해결 기획으로 예비창업 지원사업 및 피칭에 여러차례 참여했던 경험이 있다)
결론적으로, 나는 완전히 다른 방향을 제시했다.
사실 요구사항대로 이행하는 게 나에겐 더 쉬웠을 것이다. 하지만 효과 없는 작업으로 또다시 좌절감을 안기고 싶지 않았다. 진짜 문제는 다른 곳에 있다는 걸 이미 느끼고 있었기 때문이다.
엘리베이터 문제
이미지 출처 : https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.antler.co%2Facademy%2Fsolving-the-rig나는 유명한 사례를 들었다.
초기 엘리베이터에 대한 "너무 느리다"는 불만을 해결하기 위해 누군가는 더 빠른 엘리베이터를 개발하려 했지만, 다른 누군가는 단순히 거울을 설치했다. 진짜 문제는 '속도'가 아닌 '지루함'이었던 것이다.
그리고 물었다. 당장의 비즈니스 효용이 우선인지, 특정 기술을 써야만 하는 제약이 있는지, 처음 생각한 워크플로우를 꼭 고수해야 하는지.
다행히 그는 열린 마음으로 함께 고민하길 원했다.
진짜 문제 발견
며칠간 고객과 추가 대화를 나누고, 오프라인 매장과 경쟁사 온라인몰을 분석했다. 해당 산업군의 소비 패턴도 연구했다. 발견한 핵심은 이거였다. UX가 불편한 건 맞지만 그게 전부가 아니었다.
오프라인 매장에서 잘 구축된 브랜드 가치와 판매 전략이 온라인에는 전혀 반영되지 않았던 것이다. 고객과 이 문제를 공유하자 그는 크게 공감했다.
제공한 솔루션
결과적으로 네 종류의 문서를 제공했다.
업계 벤치마크 사례와 UX 개선 제안서 (12p)
디지털 마케팅 관련 기술 솔루션 조사 (7p)
외주 의뢰용 명세 가이드라인 (15p)
비개발자용 기술 기획 입문 자료 (3p)
당장의 개선사항뿐 아니라 향후 기술 도입을 위한 간단한 가이드도 포함했다.
사장님이 가장 답답해했던 건 사실 기술 그 자체가 아니라, 기초 지식이 없다 보니 외주 의뢰 등의 커뮤니케이션조차 쉽지 않다는 점이었다. 그래서 자료를 만들면서 IT기획 교육 자료와 로드맵/과제도 곁들였는데, 그가 “요즘 들어 가장 기뻤던 순간이었다”고 말해줬을 때 나 역시 뿌듯했다.
예상치 못한 제안
우리 업체의 기술 자문을 맡아주시겠어요?
감사했지만 정중히 거절할 수 밖에 없었다. 이유는 명확했다:
미들-시니어급 의사결정을 요구하는 자리였다
아직 정규직 경험조차 없는 주니어가 감당하기엔 무거운 책임이었다
프리랜서로만 초기 커리어를 쌓기보다, 제대로 된 팀에서 배우고 싶었다
그 직무는 사업적 결정에 깊이 관여하는 자리였다. 수익모델이나 기밀을 다루는 만큼 장기적인 파트너십이 전제되어야 했고, 그래서 초기 커리어 단계의 나로서는 더더욱 수락하기 어려웠다.
대신 우리는 그 이후로도 비공식 멘토링 관계를 이어가고 있다. 한 달이 지난 지금도 매주 1시간씩 통화하며 서로의 인사이트를 나눈다. 실제로 그 분의 웹사이트는 내가 제안한 UX 개선사항 대부분이 반영되어 매주 눈에 띄게 나아지고 있다.
마무리
문제를 이해하는 것이 해결의 시작이다이번 프로젝트에서 배운 세 가지:
요구사항의 이면을 봐야 한다
듣는 것이 때로는 코딩보다 중요하다
완벽한 기술 솔루션보다 적절한 해결책이 더 가치있다.
주니어인 나에게 이번 경험은 특별했다.
처음엔 기술만 제공하면 된다고 생각했다. 하지만 90분의 대화가 모든 걸 바꿨다. 진짜 문제는 코드가 아닌 다른 곳에 있었다.
그날 밤, 문득 예전의 나를 떠올렸다. 난 여러 활동을 하며 막막할 때가 많았다. 당시에는 나조차도 내가 뭘 원하는지 확신이 없었지만. 그저 누군가 내 이야기를 들어주고 같이 고민해주길 바랐었다.
사장님에게서 그때의 내 모습을 겹쳐 봤던 것 같다.
그렇기에 앞으로도 나는 문제를 ‘해결’하기 이전에, 먼저 ‘이해’하고자 하는 엔지니어가 되고자 한다.
다음 편에서는 친구가 받은 황당한 견적서 이야기를 나누려 한다.