3달 만든 코드를 모두 엎고 배운 것

“뒤집어엎자.”

창업한 다음, 제품을 처음부터 다시 만들기로 결정한 시점은 이미 프로젝트를 시작한 지 두 달이 지난 후였습니다. 당시 저는 Python 기반 FastAPI 웹 프레임워크로 자체 웹 애플리케이션 서버 프레임워크를 만들고 있었습니다. 그러다 문득 ‘내가 만든 프레임워크인데 왜 남이 만든 신생 프레임워크를 쓰는 기분이지?’라는 생각이 들었습니다. 지나치게 일반화했는지 정작 제가 만들 프로젝트에 활용하는 게 불편했기 때문이었죠. 두 달이란 시간을 버리는 건 아까웠지만, 다행히 목표로 정한 출시 시점까지는 한 달 정도 시간이 있었습니다. Django로 개발하면 충분히 일정을 맞출 수 있겠다고 예상했습니다.

처음부터 다시 코딩을 시작한 지 5주가 지나 알파 버전으로 서비스를 개시했습니다. 그리고, 그로부터 두 달 뒤에 고객을 처음 만났습니다. MVP(Minimum Viable Product, 최소 기능 제품)로 고객과 3주 정도 시간을 보내고 난 다음, 저는 한 번 더 탄식할 수밖에 없었습니다.

“고객이 쓰지도 않는 걸 그동안 만들었네. 심지어 만든 지 두 달 지난 내 코드는 다시 사용하기 어려운 레거시(Legacy)가 됐구나. 한 번 더, 뒤집어엎자.”

대체 무슨 일이 있었던 걸까요?

무엇을, 왜 만드는가?

무슨 제품을, 왜 만들게 되었는지, 그 이야기부터 해야겠습니다.

저는 25년 가까이 엔지니어로 일했습니다. 그러다 보니 자연스레 팀 내부 또는 멘토링으로 만난 주니어 엔지니어와 이야기를 나눌 기회가 생겼습니다. 때로는 놀라기도 했습니다. 열심히 자기 계발하는 이들이 많았거든요. 그런데 그와 동시에 이상하다는 생각도 들었습니다. 이런 질문을 받았기 때문입니다.

“한날 님은 어떻게 그걸 아시는 거예요?”

평범한 질문 같지만, 이상하게 여긴 이유가 있습니다. 이렇게 묻는 내용이 그들이 공부하거나 연습하는 주제에 깊이 관련된 것이었거든요. 처음에는 그저 빈말이라 여기고 농담으로 받아쳤죠. 하지만 기억을 더듬으니 비슷한 질문을 받은 빈도가 적지 않습니다. 재차 물어보며 진심을 보이는 이들을 한 명, 두 명, 세 명, 그렇게 거듭 만나자 이상하다는 생각이 들었어요. 그래서 자기 계발이나 성장을 주제로 이야기를 나누는 자리가 마련되면 저는 으레 물어보게 되었습니다.

“OO 님은 어떻게 학습하세요?”

문제 정의

성장은 공통 주제입니다. 그리고 마음처럼, 기대만큼 성장하지 못하는 과정 역시 흔한 현상입니다. 비법이라도 있지 않을까 싶은 주니어의 마음을 모르는 바는 아니지만, 경력이 오래된 제게도 성장은 쉽지 않으며 비법은 없습니다. 사람마다 차이가 있다 해도 성장하기 위해 지난한 과정을 거쳐야 하는 것을 보면 우리는 같은 클래스를 상속받은 게 분명합니다.

어떻게 학습하냐는 제 질문에 나오는 대답은 크게 세 가지로 분류할 수 있습니다.

• 스스로 어떻게 학습하는지 모른 채 열심히 한다.
• 스스로 어떻게 학습하는지 알고 있으며 열심히 한다. 그러나 엉뚱한 방법이라는 건 모른다.
• 스스로 효과와 효율이 좋은 학습 체계로 학습한다.

예상했겠지만, 세 번째 분류에 속하는 이는 극소수입니다. 스스로 학습 체계를 구축한 이는 이 중에서도 소수인데, 대개 좋은 사수나 팀을 만난 덕에 자신도 모르는 새 체계를 구축하게 됩니다. 운이 좋은 경우입니다. 그런 환경과 기회는 흔치 않으니까요.

스스로에게 물어봤습니다. ‘나는 어떻게 학습하더라?’ 여러분에게도 여쭤보죠. “여러분은 어떻게 학습하세요?” 저는 이 질문으로 제가 풀어야 할 문제를 정의했습니다.

고객 정의

문제를 정의한 다음 먼저 제 학습법을 회고했습니다. 곧이어 뇌 과학과 인지 심리학 등으로 학습법을 또 학습했습니다. 학습에 왕도는 없다고 생각했는데, 알아갈수록 방법이 선명해졌죠.

학습 비법은 특별하지 않았습니다. 심지어 대부분 이미 경험했거나 들어봤을 겁니다. 이른바 국영수 중심으로 밥 잘 먹고 잠 잘 자며 틈틈이 운동하는 그런 것들이거든요. 특별한 건 실천입니다. 의지만으로 실천하는 것은 어렵습니다. 그랬다면 선생님도, 코치도, 사수도 필요 없을 거예요. 생각이 여기 미치자 어렴풋한 감정이지만 설레기 시작했습니다. 성장에 목말라하거나 지난한 상태에 빠진 이들이 실천하도록 내가 도울 수 있지 않을까?

다시 한번, 저는 이 질문으로 고객을 정의했습니다.

효과적인 학습 방법

학습을 효과적으로 만드는 실천법

이 글을 찾아온 분들을 위해 학습을 위한 실천법 몇 가지를 소개합니다.

우선 예습은 대부분 효과적이지 않습니다. 오히려 학습을 방해하죠. 예습은 본 학습 과정에서 그 내용을 이미 학습한 느낌이 들게 합니다. ‘학습한 느낌’이요. 실제로 학습이 이뤄지지도 않았는데, 학습한 느낌 때문에 학습을 중단하는 경우가 매우 많습니다. 사람들은 학습한 느낌을 학습이라 속은 채 넘어갑니다.

반면 복습은 효과적입니다. 우리는 학습이 끝나고 10분만 지나도 이를 망각하기 시작해요. 한 시간 후에는 벌써 반이나 망각하고, 그다음 날에는 학습했다는 사실이 흔적처럼 느낌으로 남아있을 겁니다. 복습으로 흐릿해지는 기억을 누적시켜 이를 강화해야 합니다.

이러한 복습은 다소 불편을 느낄 만한 강도로 점진적으로 반복해야 합니다. 안전한 지대를 벗어나야 하죠. 틀렸다는 불쾌감, 실은 제대로 학습하지 않았다는 진실을 마주하는 불편함을 기꺼이 맞이해야 합니다. 학습 내용을 기억에서 인출하려면 부하가 일어납니다. 이때 생기는 과열을 극복해야 하죠. 심지어 이런 과정을 반복해야 합니다. 시스템 1*이 개입하지 않도록 경계하며 시스템 2*를 동원해 불편한 지대를 지나야 학습이 이뤄집니다.

*시스템 1과 시스템 2 : 심리학자 키스 스타노비치(Keith Stanovich)와 리처드 웨스트(Richard West)가 고안한 용어. 시스템 1은 직감적이고 무의식적으로 잠재 기억에 축적된 정보를 활용해 빠르게 반응하는 사고 체계(mode)이며, 시스템2는 의식적이고 논리적이며, 추상적으로 사고하는 체계다. 시스템 1은 착시가 일어나거나 프레이밍에 갇히는 단점이 있고, 시스템2는 용량이 작고 느리며 에너지를 많이 소비한다. (참고 글)

학습 과정에서는 자기 생각, 나만의 언어로 메모하여 정보를 잘 압축(compressing)하고 부호화한(encoding) 다음, 색인(indexing)해야 합니다. 예를 들어 발표 내용을 외워 낯선 곳에 가서 발표해야 한다고 합시다. 이럴 때는 주요 지점마다 기억을 인출해 낼 일종의 ‘열쇠'를 만들면 좋습니다. 잊지 말아야 하는 주제 A가 있다면, 전방 상단에 있는 벽걸이형 스피커를 시각 신호 매체로 대응해 떠올리는 것도 방법입니다. 더 쉽게는 그 공간 자체와 친숙해질 수도 있죠.

또한 학습으로 풀어낼 문제를 정의할 수 있어야 합니다. 여러분이 작성한 코드에 버그가 있는데, 실행할 때마다 결과가 다르다면 문제를 정의할 수 없겠죠. 오류나 동작 결과가 피드백으로써 동작하지 않는 것입니다. 일정한 패턴을 보이는 문제는 힘들고 어렵긴 하지만 고마운 존재입니다. 무작위 과정과 피드백이야말로 사람을 미치게 만드니까요.

마지막, 학습을 할 때는 적시에 피드백을 받아야 합니다. 틀린 학습을 반복하고 있지 않은지 관찰하고 교정해야 하죠. 힘들게 ‘1 + 1’이라는 문제를 풀어 ‘3’이라는 답을 구했다고 합시다. 이 답이 틀렸다는 걸 6개월 뒤에 알게 되면 어떨까요? 이런 상황을 피해야 합니다. 이때 시험(Test)은 아주 좋은 피드백 방법 중 하나입니다.

간단하지만 실천하기 어려운 이유

이러한 실천법은 얼마든지 많이 도출해 낼 수 있습니다. 이를 구성하는 주요 줄기는 크게 달라지지 않거든요. 앞서 제시한 실천법들은 어떤가요? 맥 빠질 만큼 뻔하고, 이미 우리가 알고 있는 데다가, 실천하기도 어렵지 않아 보입니다.

그런데 말이죠. 우리 뇌는 집요하리만큼 에너지 최적화를 지향합니다. 착시를 겪을지언정 에너지를 들이는 상황을 어떻게든 피하려 하죠. 효과적인 학습 원리는 단순하지만, 에너지가 많이 들어갑니다. 이런 뇌의 거부 반응이 실천을 어렵게 만듭니다.

고객을 만나다

오늘도 평화롭고, 아무 일도 일어나지 않습니다

다시 저와 제품이 마주한 문제로 돌아가겠습니다.

학습법에 대한 학습을 마친 다음, 정의한 문제를 해결할 방향을 잡았습니다. 소프트웨어로 학습 효과를 높이는 수단과 환경을 제공하는 거였죠. 그래서 제가 생각한 대로 이런 멋진 기능과 저런 훌륭한 기능을 계획하고 열심히 코딩했습니다. 열심히 만들었더니 기능들이 서로 어우러져 얼추 제품의 모습이 드러났습니다.

고객을 얼른 만나 제품을 개선하자는 야심 찬 마음으로 알파 버전이라 명명하고 서비스를 개시했습니다. 구축해야 할 게 산더미 같았지만, 꼭 필요한 건 준비했다고 여겼거든요. 이렇게 MVP를 만들었습니다.

하지만 제 MVP는 문제를 조금도 해결하지 못했습니다. 여전히 낮은 효율로 열심히 학습하며 미미한 효과를 보는 사람은 많았고, 그들 중 누구도 제가 만든 서비스를 이용하지 않았습니다. 혹시 서비스를 ‘http://localhost:8810’으로 돌리는 건 아닌지 의심되어 일부로 밖에 나가 접속해 보기도 했습니다. 잘 동작하더군요. 그저 이런 생각만 들었습니다. ‘이 페이지엔 캐시를 붙여야겠군. 살짝 느리네.’

분명 검색 크롤링 봇보다 사람이 직접 방문하는 일이 더 많았습니다. 그저 제 제품이 그들에게 전혀 기여하지 못할 뿐이었죠. 제 코드는 왜 작용하지 않았을까요?

3주 파일럿 프로그램

초조한 마음으로 더욱 열심히 코딩했습니다. 콘텐츠도 보강했습니다. 살짝 느린 저 페이지는 캐싱 처리했습니다. 뭔가 하긴 했는데, 효과는 없었습니다. 이유를 몰랐습니다. 아무것도 모르니 무작정 광고를 돌릴 수도 없는 노릇이었죠. 캄캄한 방에서 전등을 켜고 싶은데, 벽을 더듬지도 못하고 허우적대는 느낌이었습니다.

저는 문제에서 도망치고 싶으면 무언가를 배웁니다. 네, 그래서 이때도 1인 창업을 주제로 하는 온라인 워크숍에 참여했죠. 워크숍에서는 소프트웨어 엔지니어링을 할 줄 모르는 이들이 여러 도구와 방법으로 자신의 아이디어를 고객 손에 쥐여 주고 있었습니다. 이들은 고객이 내는 돈으로 피드백을 받고 있었죠.

퍼뜩 정신이 들었습니다. 제가 세운 가정, 즉 “사람들은 학습법을 익히면, 효율적으로 학습할 수 있다"는 가정은 구글 드라이브와 디스코드로도 충분히 검증할 수 있다는 걸 깨달았죠. ‘그동안 뭐 한 거야?’라고 생각했습니다. 이런저런 코드가 잔뜩 붙은 제 망치 같은 제품으로는 못을 발견해도 망치질에 시간이 적잖이 들 것이 분명했죠. 정말 저는 뭘 하고 있던 걸까요? 코딩할 때가 아니라는 걸 자각하고는 곧바로 웹사이트 빌더로 랜딩 페이지를 만들었습니다. 목표한 수만큼 학습 참가자를 모집했고, 3주 단위 파일럿 학습 프로그램을 진행했습니다.

그 결과, 목표보다 높은 수료율을 달성했습니다. 수료한 다음 팬을 자처하는 분도, 제가 설계한 학습 체계와 방법을 지지하는 분도 생겼습니다. 물론 학습 목표를 달성하며 효과를 본 학습자들이었죠. 제 기준에서는 여러모로 이 학습 방법이 작동할 것이라는 가정을 입증한 셈이었습니다. 물론 진솔한 피드백도 여럿 받았습니다. 혼자서는 알다가도 모를 그런 문제를 눈앞에 마주하자, 코딩만 해오던 3개월이 후회가 되었습니다. 문제를 푸는 데 그 시간을 썼다면 더 좋았을 테니까요. 또, 그때 깨달았습니다. 이 코드로는 새로이 정의한 문제를 효율성 있게 해결하기 어렵겠다고 말입니다. 그래서 결정했죠. “뒤집어엎자.”

좋은 코드는 어떤 코드일까?

엔지니어링은 공학, 과학 기술을 응용하고 활용해 문제를 해결하고 과제를 달성하며 운용하는 활동입니다. 해결해야 하는 문제, 달성해야 할 과제는 다르게 표현하면 ‘가치’입니다. 그러므로 문제와 과제의 대상, 즉 고객이 있어야 이를 해결하고 달성하여 가치를 전달할 수 있습니다.

엔지니어링의 수단은 다양합니다. 코드를 작성하는 일은 그 다양한 수단과 방법 중 하나에 불과합니다. 고객에게 전달할 가치를 가장 효과적으로 엔지니어링 하는 방법이 코딩이라는 걸 확인한 다음, 그다음에 코드를 작성해도 전혀 늦지 않습니다. 엔지니어링의 쓸모에 기여하지 않는 코드는 죽은 코드에 그치지 않습니다. 죽은 코드는 오히려 진짜 엔지니어링을 방해하기도 합니다.

정의한 문제에 동의하고, 새로운 문제 해결 방법에 공감하는 고객을 찾는 것이 먼저입니다. 이어 고객과 함께 제품을, 그리고 가치를 만들어야 합니다. 고객과 함께 문제를 엔지니어링 하는 코드를 작성해야 합니다. 이러한 프로젝트를 사명으로 삼는 한, 엔지니어링이 가치를 창출하지 않는다면 저는 나아가지 못할 것입니다. 

마치며

개발을 시작한 지 25년이 지났고, 이번이 무려 세 번째 창업인데, 새삼 제 머리카락도 못 자른다는 걸 이번 일로 알았습니다. 깨달았으니 전문가를 찾아가든, 이를 스스로 해결할 방도를 찾아야 했습니다. 저는 후자를 선택했습니다. 앞으로도 제 머리카락 자르는 이야기를 종종 전하려고 합니다. 눈썹을 밀거나 귀 끝을 자를지도 모릅니다. 뜻하지 않게 삭발을 할지도, 이상한 머리 모양으로 불쑥 나타날 수도 있습니다.

누군가 저처럼 나쁜 코드로, 나쁜 엔지니어링을 하지 않기를 바라는 마음입니다. 좋은 코드 작성하고, 좋은 엔지니어링을 하고, 좋은 제품을 만드세요. 저를 반면교사 삼아서 말이죠. 부끄러움은 오롯이 제 몫으로 지고 가겠습니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.