런드리고 4년의 회고

기억이 흐릿해지기 전에 런드리고(의식주컴퍼니)에서 있었던 4년의 회고를 적고자 합니다. 저에게 런드리고는 처음으로 스타트업이라는 곳을 경험하게 해준 곳이고 4년 동안 정말 훌륭한 동료들과 즐겁고 열정적으로 근무한 회사입니다. 저와 함께한 회사의 모든 동료들에게 감사함을 전합니다.

1. 채용

회사에 조인할 당시에 개발자 수는 한자리 숫자였어요. 앱 개발자, FE 개발자, BE 개발자 분포로 기술 스택은 Android Kotlin, iOS Swift, Frontend PHP, Backend Java-Spring, & Golang. 그리고, Kafka, Redis.

스타트업에서 좋은 개발자 채용은 어렵습니다. 이유도 명확합니다. 채용을 열어도 회사가 외부에 알려지지 않아 지원자가 많지 않고, 지원자의 역량(물론, 이력 내용으로만 판단)도 회사의 인지도와 비례하였습니다.

초기 스타트업이 채용에서 많이 사용하는 방식으로 지인 찬스가 있습니다. 물론, 이 방식에 대해서 장단점을 논하는 글을 본 적이 있지만, 지인 찬스 채용의 단점은 극복해야 할 문제이지 이 문제 때문에 사용하지 못할 이유는 없습니다. 저는 이 방식으로 채용했습니다. 운이 좋았습니다. 제가 과거에 같이 근무했던 훌륭한 시니어 개발자분들이 여러 명 조인해주셨어요. 스타트업으로 이직을 결정하는 여러 요소가 있는데, 그중에 하나가 회사가 어떤 사업을 하고 있느냐일 것입니다. 런드리고는 세탁 사업을 하고 있고, 세탁의 수요는 지속적입니다. 이 의미는 세탁 사업을 하는 회사의 전망은 밝을 것이라는 기대입니다. 이런 기대를 기반으로, 세탁은 어떤 문제를 해결해야 하는지, 개발을 통해서 해결할 수 있는지을 도전할 수 있다면 이는 개발자가 그 회사에 조인하게 만드는 중요한 요소입니다. 이제 중요한 요소 하나는 충족되었다고 보겠습니다. 다음은 어떤 사람들과 어떻게 일하느냐가 중요한 요소인데, 이것은 일종의 평판 조회와 유사한 것이고, 과거에 직접적인 동료였으니 이는 매우 정확한 본인만의 평판 조회를 가진 셈이지요. 이 요소도 충족되었다고 판단해주신 저의 지인 개발자들에게 감사함을 전합니다. 또한, 중요한 이직 사유인 처우에 대해서도, 대표님이 많이 도와주신 덕분에 큰 어려움 없이 뛰어난 시니어 개발자를 채용할 수 있었습니다.

시니어 개발자 채용이 되면 주니어 개발자 채용이 가능해집니다. 회사에 개발 멘토를 해주실 분들이 있고, 이를 채용에서 잘 알릴 수 있다면 성장을 원하는 주니어 개발자 채용이 한결 쉬워집니다. 괜찮은 주니어 개발자를 골라 뽑을 수 있는 기회도 생깁니다. 런드리고에서도 실제로 그러했습니다. 우리는 아예 경력 없는 신입 개발자를 채용했습니다. 이 과정에서 많은 도움을 받은 곳이 SSAFY(사피) 입니다. 사피는 대졸자를 대상으로 신입생을 선발하여 개발 교육과 함께 일정 금액의 보수도 지급하는 훌륭한 인재 양성 기관입니다. 이 기관이 민간(?)이라는 것이 놀랍습니다. 대기업이 할 수 있는 일종의 사회 환원 사업처럼 보였으니까요. 사피에 채용 설명회를 할 수 있는 기회를 얻었습니다. 당시에 코로나가 창궐했던 시기로 직접 대면하여 채용 설명회를 할 수는 없었지만, 온라인을 통해서 사피에서 제공해주신 스튜디오에서 실시간으로 채용 설명회를 하고 질답 시간도 가지면서 회사를 홍보하여 신입 개발자 지원을 받았습니다. 여기에서 교육받으신 신입 개발자분들은 훌륭했습니다. 사피에 들어가기 위한 경쟁이 있다 보니 2~3년 차 정도의 주니어 개발자보다 더 잘하시는 분이 많았습니다. 하지만, 당시에 런드리고라는 이름만으로 채용 경쟁력은 없었습니다. 저는 신입 개발자들이 어떤 것을 원하는지 파악하고 있었다고 자부합니다. 채용 공고를 정성스럽게 작성하였습니다. 일반적인 JD는 간략한 회사 소개와 함께 어떤 기술 스택의 경험을 가진 개발자를 원한다고 작성합니다. 하지만, 런드리고의 채용페이지에는 더 많은 내용을 넣었습니다. 회사 설명은 당연하고, 개발 조직이 어떻게 개발하는지 상세하게 기술했습니다. 우리가 개발하는 영역, 각 영역에서 어떠한 기술 스택을 사용하고 어떤 경험을 필요로 하는지, 그리고, 가장 중요한 개발 조직 문화를 이해할 수 있도록 구체적인 업무 방식(코드 리뷰, 개발 업무 할당, 커뮤니케이션 방식 등)을 매우 상세히 기술하였습니다. 또한, 런드리고의 개발 조직에는 어떤 회사의 어떤 경험을 가지신 분들이 있는지 기술하여 이 회사에 조인했을 때, 무엇을 배우고 성장할 수 있는지를 가늠할 수 있도록 했습니다. 개발자의 성장 욕구를 충족시켜줄 수 있는 회사라는 인식을 가지게 하는 것은 개발자가 회사를 선택하는 데 있어 매우 중요한 요소입니다. 이러한 것들을 채용 설명회에서 강조했습니다. 더불어, 더 중요할 수 있는 신입 연봉에 대해서도 파격(?)적인 제안을 했습니다. 신입 개발자 연봉 5천만원. 이는 업계 Top 수준이었습니다. 당시에 개발자 채용에 대한 추세는 개발자 공급보다 수요가 많아 개발자 몸값이 계속 오르던 시기입니다. 당시에 당근에서 신입 개발자 초봉 6천만 원 제안도 본 적이 있습니다. 우리가 제시한 5천만 원은 훌륭한 개발자를 뽑기 위한 의지의 표현이었습니다. 사피 채용 설명회에서는 런드리고보다 훌륭한 회사도 많이 있었습니다. 이들과 경쟁하여 훌륭한 인재를 데려오기 위한 노력에 성과가 있었습니다. 덕분에 6개월 또는 1년 간격으로 1~2명씩 신입 개발자를 채용할 수 있었고, 이후에 이들의 기여는 탁월했습니다. 이분들은 런드리고가 성장하는데 정말 성과를 발휘해 주셨다고 생각합니다.

2. 개발 프로세스, 개발 업무 관리

개발 프로세스는 이미 여러 best practice가 있습니다. 중요한 것은 그것들 중에서 우리에게 맞는 것은 무엇인가를 판단하고 적용하는 것입니다. 관용적인, 표준적인이라고 말할 수 있는 과정은 존재하나, 그중에서 스타트업에 맞으면서 특히 우리의 상황에 맞는 것은 무엇인지 취사선택하여 실행하는 것이 중요하다고 판단했습니다. 스타트업의 개발은 단기간 이터레이션의 반복입니다. Lean(형용사) 개발이 강조되고, 기술 부채가 이미 많고, 시급히 해결해야 할 과제도 많습니다. 하지만, 이 모든 변수들은 회사의 사업에 얼마나 기여하는지, 그래서 어느 시기에 무엇을 해야 하는지 판단하는 것의 중요한 가중치 산정의 기본 요소입니다. 효과가 높으면서 개발 기간이 짧은 것이 최우선으로 진행되어야 하고, 그러기 위해서는 넣고자 하는 기능이 개발에서 얼마나 소요될지 정확하게 산정하는 것이 중요했습니다. 정확한 기간 산정은 과거 경험에 기반합니다. 그래서, 경험 많은 개발자는 큰 도움이 됩니다. 우리는 사업이나 기획이 원하는 요구사항을 말하면 대략적으로 얼마나 소요될지 거의 바로 판단해주었습니다.

런드리고 개발이 개발 업무를 수행하는 방식은 2주 SPRINT 입니다. 2주 동안 해야 할 일을 플래닝하고 전력 질주하여 해내는 것이죠. 과거에 이러한 스프린트 방식으로 프로젝트를 성공적으로 완료한 좋은 경험이 있습니다. 그때의 프로젝트는 과거에 경험해 보지 못한 프로젝트였고, 기획과 개발이 하나씩 맞추어 가고 시행착오를 겪으며 진행했습니다. 2주 만에 동작하는 코드를 만들었지만, 그 동작은 나중에 많은 변화를 요구받았고, 이후 과정에서 많은 변경으로 인해 버려진 코드가 되었습니다. 하지만, 동작하는 코드에 대한 성취감은 그 다음 스프린트를 수행하며 변화에 대응하는 동기를 주었습니다. 마지막 스프린트를 완료하는 날 출시할 수 있었던 좋은 경험으로 런드리고에서도 유사한 방식으로 적용했고 또 하나의 성공이었다고 평가합니다.

스프린트 플래닝이 참 중요합니다. 그래야만 알찬 스프린트 기간를 보낼 수 있으니까요. 스프린트 방식을 처음 시작할 때에는 시행착오도 있었습니다. 스프린트가 끝났지만 계획한 일을 모두 수행하지 못한 것이죠. 하지만, 이러한 시행착오는 그 다음 스프린트를 거치며 점점 없어졌습니다. 개발 멤버들이 이러한 방식에 적응하며 예측 가능하도록 업무를 마무리해주었습니다. 물론, 예측하지 못한 일들이 매번 스프린트마다 발생했습니다. 하지만, 스프린트가 종료되었을 때 계획한 업무를 마무리하고 싶었습니다. 그래야만, 이 업무가 마무리되길 기대하는 다른 부서에서 다음 일을 진행할 수 있기 때문입니다. 예측하지 못한 업무로 인해 계획한 업무를 마치지 못하는 상황을 최소화하고 싶었고, 그러려면 예측 가능한 선에서 버퍼가 필요했습니다. “비정기 업무”를 플래닝에 포함시켰습니다. 계획된 업무를 완료하는 것을 더 중요하게 생각하고, 스프린트 내에 적절한 버퍼를 둔 것입니다. 개발 조직은 다양한 부서에서 개발을 요청받습니다. 정해진 프로젝트, 프로젝트 완료 후 고도화, 정기/비정기 마케팅을 위한 개발 등 다양한 부서에서 다양한 개발 요구 사항을 받습니다. 이들은 자신들이 요청한 것이 언제 완료되는지 가장 궁금해합니다. 개발 리소스는 항상 부족하고 어느 부서의 요청 사항이 언제 완료되는지 미리 알려주는 것은 중요합니다. 그것이 다음 플랜을 세우고 실행하는 데 기본 일정이 되기 때문입니다. 스프린트를 통해 2주 뒤에 완료되는 것이 무엇인지 누구나 알 수 있습니다. 그리고, 완료될 것이라고 기대합니다. 이 기대에 부응하기 위해서 비용(비정기 업무 할당)이 들더라도 계획된 일정을 지키는 것이 더 우선되어야 한다고 판단합니다.

3. 개발의 방향성: 런드리고 앱, 스마트 세탁 팩토리 개발, 데이터, AI

세상에 공짜는 없다! 라는 명언이 있듯이 빠른 개발은 기술 부채를 가져올 가능성을 높입니다. 기술 부채라는 단어 자체가 약간의 부정적 의미를 담지만, 개발에서 기술 부채가 만들어지는 것이 어쩌면 당연할지도 모르겠습니다. 기술 부채를 감당할 수 없을 만큼 키웠다면 문제이지만, 관리 가능한 수준의 기술 부채는 전략적으로 선택할 수도 있으니까요. 개발은 기술 부채(나중에 더 구조적, 깔끔한, 일관성 있는 개발 변경을 필요로 한다는 의미)를 만들면서 개발하기를 원하지 않습니다. 항상 마음 한편에 불편함을 지니고 있으면서 “이거 나중에 고쳐야 하는데…”라는 마음을 가지고 있죠. 나중에 안 고치도록 개발하고 싶지만 개발 일정(아마도 이 이유가 대부분)상의 이유로 현재 개발 요구 사항에만 집중하여 개발하게 됩니다. 나중에 수정 요구 사항이 있을 때, 짧은 시간에 수정되지 않을 가능성이 높은 상태로 릴리즈를 하게 됩니다. 오렐리 출판사에서 출간한 “구글 엔지니어는 이렇게 일한다” 라는 책에서 “지속 가능한 개발”에 대한 내용이 나옵니다. 지속 가능한 개발이란 무엇일까요? 책에서 언급하는 내용은 “변경 가능성에 얼마나 빠른 대응이 가능한가”를 말합니다. 소프트웨어는 한번 릴리즈하고 이후에 변경이 없는 경우는 거의 없습니다. 그 소프트웨어로 사업을 지속하고 있다면 변경 요청은 따라올 수밖에 없습니다. 이러한 변경 요청에 얼마나 빠르고 효율적으로 대응하는가(얼마나 빨리 기능 추가, 수정이 가능한가)를 고려하는 것은 그 사업의 성패가 달려있을 수도 있습니다. 간단한 기능 하나 추가에 4주가 소요된다면 사업을 지속할 수 있을까요? 변화에 빠른 대응이 가능하게 만들어진 소프트웨어를 개발하는 것이 그 사업이 지속되는 데 필수 요소이고 이러한 소프트웨어를 만드는 것이 중요합니다. 이는 곧 기술 부채를 줄이는 개발과 같은 맥락에 있고, 설계의 중요성, 코드 퀄리티 높이기와도 그 결을 같이 합니다.

런드리고 개발도 지속 가능한 개발을 위해서 레거시 요소들을 제거하고, 신규 개발에서도 변경 가능성을 높이기 위해 노력했습니다. PHP로 구현된 Frontend 화면을 react로 변경하는 작업을 지속적으로 했습니다. PHP가 나쁜 것은 아닌데, 구조적인 문제점을 만들면서 개발할 가능성이 높습니다. 가장 어려운 점이 PHP 코드 내에서 sql 쿼리가 존재한다는 것입니다. PHP 언어로 백엔드 기능도 커버하려다 이런 결과물이 나오게 되는 것 같습니다. 데이터 영역과 뷰 영역이 혼재되어 있다 보니, 변경에 대해서 잠재된 오류 가능성이 높습니다. (테이블의 컬럼 변경이 어떤 파급 영향이 있는지 알기 위해 PHP 소스코드를 모두 검사해야 하는 수고를 해야 합니다.)

런드리고에서의 개발 영역은 크게 2가지입니다. 런드리고 사용자 영역에서 앱 개발, 앱을 위한 서버입니다. 그리고, 다른 영역은 세탁 스마트 팩토리의 세탁 공정을 처리하는 시스템, 자동화 설비와 연계되는 시스템, 운송 시스템 등입니다. 팩토리 영역에서의 개발 범위가 더 큽니다. 개발 분야가 다양하고 각 분야가 더 깊이 발전하고 있으니, 모든 개발 분야의 전문가가 되는 것은 불가능합니다. 저의 태생이 백엔드 분야여서 이 분야 외에는 모두 좋은 인재를 영입하여 믿고 맡기고, 그 방향성에 대해서만 논의와 합의하였습니다. 백엔드 분야는 더 자세히 협의하면서 서비스 데이터 구조와 전체 서비스의 일관성을 유지하기 위해 노력하였습니다. 일부는 핸즈온 개발을 통해서 기여하기도 했습니다. 또한, 주요 지표를 산출하기 위해서 snowflake를 도입하였고, 세탁물의 품목을 판단하기 위해서 이미지 기반의 세탁 품목 AI를 개발했습니다.

런드리고에서 도입한 기술 스택들이 있습니다. MSA, aws EKS, Kafka, Redis, 이벤트 처리 outbox pattern 등입니다. 우리의 문제 해결을 위해서 필요한 요소를 도입하고, 개발 멤버들에게 역량 강화의 동기 부여가 될 수 있는 요소들을 찾아 시범적으로 도입하고 더 넓게 확장하는 방식이었습니다. 스타트업 분야가 다양하고 이를 실현하기 위한 노력의 일환으로 개발이 이용된다고 할 수 있는데, 기술은 빠르게 발전하지만 정말 그 기술이 우리 사업을 실현하는 데 필요할까요? 물론, 향후 확장성을 고려한다면 여러 가지 기술적 시도를 통해 미리 준비하는 것은 매우 중요한 활동입니다. 다만, 현재의 문제를 해결하는 데 있어 반드시 새로운 것을 도입해야 하는 것은 아니고, 트렌드 기술을 사용해야 하는 것도 아닙니다. 어쩌면 MSA 구조가 아니어도, Kafka가 없어도 우리의 문제를 해결할 수 있습니다. 고전(?)적인 기술 스택만으로도 대부분의 문제를 해결할 수 있습니다. 하지만, 그렇게 하는 것은 바람직하지 않지요. 이직하려는 마음이 없더라도, 채용을 하지 않더라도, 어떤 기술 스택 경험의 개발자를 채용하려고 하는지 보기 위해서 다른 회사의 채용 페이지를 방문합니다. 그곳에 적힌 기술 용어들이 현재 그 회사가 채용한 기술 스택이고 향후 도입하려는 기술도 일부 나와 있습니다. 여러 회사에서 공통적으로 언급되는 것들이 현재의 트렌드입니다. 저는 런드리고의 개발자들이 사업의 문제 해결을 넘어 트렌드에 뒤쳐지지 않는 개발자로 성장할 수 있는 기회를 주고 싶었습니다. 도입 비용이 크지 않다면 트렌드 기술로 일부 도입하면서 경험하게 하고 그 부분의 전문가가 되기 위한 첫걸음이 되길 원했습니다. 이러한 방향이 어떤 개발자에게는 강력한 동기 부여가 될 수 있습니다. 여기서 주의해야 할 것이 있는데, 바로 오버 엔지니어링입니다. 간단한 문제를 해결하는 데, 다기능 프레임워크를 도입하는 것 같은 것이죠. 이는 곧 높은 비용을 의미합니다. 새로운 것을 도입하는 것 자체가 목적이 아니며, 현재 우리 문제 해결에 도움을 받는 것이 최우선입니다. 가장 중요한 것! 우리를 위한 적절한 기술의 선택, 이 시점의 우리의 현재 시스템을 고려하고, 새롭게 해결하려는 문제를 정확히 파악하고 이를 위한 적절한 기술이 무엇인지 판단하는 것!

4. 종합적 회고

런드리고에서 4년의 시간은 저에게 소중한 경험입니다. 한 회사의 전체 개발을 리드해 볼 수 있는 시간을 가지는 것은 쉽지 않으니까요. 개인적으로 4년 동안 무엇에 집중했나 되돌아보면 크게 2가지입니다. 개발이 런드리고에 기여할 수 있는 것은 무엇인가, 개발 조직을 어떻게 운영할 것인가. 이 주제에 집중하여 시간이 참 빨리도 흘렀습니다.

런드리고는 사용자 앱뿐만 아니라, 세탁 스마트 팩토리 운영이 있습니다. 실제로 스마트 팩토리 개발이 더 많은 비중을 차지합니다. 스마트 팩토리에서의 효율화가 회사의 생존과 직접적으로 연결되어 있습니다. 오피스 조직은 다른 회사와 크게 다르지 않지만, 스마트 팩토리는 달랐습니다. 국내에서 이 정도 규모의 대규모 세탁 팩토리는 없습니다. 런드리고가 최초이고 대량 세탁의 새로운 도전입니다. 스마트 팩토리를 어떻게 운영하는 것이 최적인가에 대한 답을 찾아야 합니다. 아직 완벽한 답을 찾지 못했지만 점점 효율화되고 좋아지고 있습니다. 팩토리의 운영 효율화가 너무나 중요하다고 여겼고, 이를 위해서 여러 자동화 설비를 도입하고 이를 개발과 연계하여 사용자 경험까지 전달하려고 했습니다. 팩토리에서의 효율화를 위해서 시스템의 고도화가 필수라고 생각했습니다. 많은 개발 리소스가 팩토리 효율화 개발에 투입되었습니다. 그 결과 시스템적인 진보는 이루었습니다. 하지만, 이러한 기여 방법이 최선이었나를 되돌아보게 됩니다. 시스템으로 해결할 수 없는 것들이 많습니다. 저처럼 IT 업계에만 오래 있었던 사람에게 실제 팩토리의 상황은 생소한 경험입니다. 세탁 팩토리는 많은 사람을 필요로 합니다만, 같은 인력으로 더 높은 효율을 만드는 것이 목적입니다. 즉, 팩토리의 운영이 중요한데, 얼마나 이 문제에 집중했었나 후회가 남습니다. 개발 코드를 들여다보는 것보다 오히려 스마트 팩토리 현장에서 무엇이 문제이고 개선해야 하는지 찾는 시간이 더 필요했을지도 모릅니다. 이 문제점을 찾고 전달해주는, 저보다 더 전문가들이 있었습니다만, 이 방식이 최선이었나 다시 한번 되돌아보게 됩니다. 안일하게 대처했다는 후회도 남습니다. 문제의 현상을 보며 팩토리 내부에서 해결되기를 기대했었으니까요. 현장에서의 문제 해결의 주체가 되지 못했던 것이 아쉽습니다.

처음으로 스타트업에 조인하여 회사의 성장과 함께 힘들었던 시간, 배움의 시간을 보냈습니다. 그 과정에서 제가 잘할 수 있는 것이 무엇이고 힘들어하는 것이 무엇인지 깨닫는 시간도 있었습니다. 이 모든 것들이 저에게는 소중하게 남아 있습니다. 무엇보다 런드리고에서 많은 사람들을 만나 동고동락하며 지낸 시간이, 저에게는 인생의 찬란했던 순간으로 남습니다.

저와 함께 해준 개발 멤버들에게 특히 감사함을 전합니다. 저의 미숙함으로 인해 상처받은 분들도 계셨을 것 같습니다. 희망하자면, 런드리고의 개발자로서 괜찮은 경험을 했다고 느끼는 분들이 많았으면 좋겠습니다. 시간이 조금 지난 후에, 우리가 다시 뭉쳐서 그때의 즐겁게 개발하던 시간을 다시 가질 수 있기를 희망합니다. 저는 비록 런드리고를 떠났지만, 런드리고 잘 되기를 항상 바라는 마음입니다.

5. 남은 이야기들

회사의 성장, 업의 특성, 조직의 변화, 조직장들과의 관계, CTO와 대표와의 관계 등 더 많은 이야기들이 있지만 굳이 이 지면에 적을 필요는 없을 듯합니다. 저의 가까운 지인들에게만 소회를 남기는 것으로 대신하겠습니다.

6. 부록: AI와 함께하는 개발

이제는 개발할 때 AI를 사용하지 않는 것이 어색한 시대가 되었습니다. AI가 이렇게 코딩을 잘할지 누군가는 알았을까요? 알파고가 바둑을 정복한 것처럼 AI가 모든 개발을 정복할 날이 올까요?

AI와 함께하는 개발에 대해서 두 가지 측면으로 적고자 합니다. 하나는 코딩의 결과물을 바라보는 입장(개발자가 아닌 분들)과 실제로 그 결과물을 만드는 사람들의 입장(개발자들)입니다.

최근에 바이브 코딩을 했습니다. 의식주컴퍼니는 몇 가지 사업 영역이 있는데, 그중 하나가 런드리24라는 무인 빨래방 사업이고, 런드리24 앱을 직접 바이브 코딩으로 개발했습니다. (제가 마무리하지 못하고 퇴사했지만, 그 뒤를 잘 마무리해준 X솔과 HH님에게 감사함을 전합니다.) Flutter로 개발했는데, 과거에 Flutter로 개발한 경험이 없습니다. 그래서, 너무 모르고 개발하는 건 불가능하니 인강을 시청했습니다. 인강의 커리큘럼이 꽤 많았는데, 강의 자체만 시청한 시간이 20시간이 넘습니다. Dart 언어를 배우고 Flutter를 배웠습니다. 직접 코딩을 따라 하면 아… 이렇게 개발하는구나라는 것을 알게 되었습니다. Flutter 위젯의 정확한 사양은 몰라도 무엇을 하려 하는지는 잘 이해하는 수준이 되었습니다. 이후에 바이브 코딩을 시작했습니다.

처음부터 AI에게 맡기는 것은 적당하지 않다고 판단하여, 만들려는 앱과 가장 유사한 예제 코드를 찾았습니다. 이 코드를 기반으로 바이브 코딩을 했습니다. 화면의 특정 UI, 내부 기능 등을 바이브 코딩으로 작성했습니다. 여러 가지 업무를 함께하다 보니 시간이 소요되긴 했지만, 앱을 만들기 위한 바이브 코딩만 2주 정도의 시간을 쓴 것 같습니다. 앱이 100% 완성되진 않았지만, 어느 정도는 동작하는 앱이 완성되었습니다. 이 과정에서 느낀 점이 있습니다. 앞에서 말씀드린 두 가지 측면을 기준으로, 첫 번째 저는 앱 개발자가 아닙니다.(2009년 경에 아이폰 앱을 출시한 적이 있지만.) 인강을 수강한 것이 거의 전부입니다. 그럼에도 바이브 코딩만으로 앱을 개발할 수 있습니다. 앱 개발자가 아니어도 앱을 개발할 수 있습니다. 이 상황 자체가 큰 변화입니다. 회사에서 앱 개발자를 채용하지 않아도 앱을 만들 수 있습니다. 이것이 결과물을 바라보는 사람들에게는 정말 효율적이라고 느낄 것입니다. 앱 개발자 채용 없이 2주 만에 이 정도 앱이 나올 수 있다니! 결과물이 나오는 효율이 정말 좋아진 것입니다. 개발자들에게 AI를 더 장려하고 싶어지는 것은 당연합니다. 여기까지는 좋습니다. 그럼, 결과물을 만드는 개발자 입장을 말해보겠습니다. 바이브 코딩을 했는데, 나에게 남는 것은 무엇인가라는 생각이 먼저 듭니다. 이러한 방식의 결과물을 만드는 것은 약간의 시간을 투자하면 누구나 할 수 있는 작업입니다. 결과물이 나왔다는 것 말고는 다른 의미를 찾기 어렵습니다. 특히, 개발자 중에서 자신의 배움을 중요하게 생각하는 분들이 있고 이분들에게 바이브 코딩은 (조금 과장해서) 시간 낭비입니다. 코딩을 하면서 성장의 느낌을 받을 수 없으니까요.

추가로, 개발자에게 하기 나름의 변수가 있습니다. 제가 바이브 코딩을 하면서 Flutter를 더 깊이 있게 공부하는 기회를 가질 수 있습니다. AI가 만들어주는 코드와 주석을 보면서 또는 특정 코드를 설명해달라고 하는 스크립트를 적으며 Flutter를 더 배우는 시간을 가질 수 있습니다. 이러한 과정의 개발이라면 의미 있는 바이브 코딩이 됩니다. 그렇지만 결과물이 나오기까지 시간이 더 걸릴 것이고, 이 과정의 배움을 실천하기 위해서 바이브 코딩을 줄이고 직접 코딩하는 시간이 늘어날 수 있습니다. 즉, 효율은 다소 떨어지겠지요. 하지만, 이러한 과정으로 바이브 코딩을 한다면 개발자들에게도 매우 의미 있는 바이브 코딩이 될 수 있습니다.

추가로 2, 한 가지 더 있는데… 자기가 잘 아는 분야의 코딩을 AI의 도움을 받는 것입니다. 이 측면 때문에 주니어 개발자보다 시니어 개발자가 유리하다고 말하는 것일 텐데요, 요구 사항을 구현하는 데 있어 요구 사항 자체를 잘 이해하고 있고, 어떤 과정을 거쳐야하며, 무엇을 하면 되는지 잘 알거나 경험이 있는 경우입니다. 이런 경우는 전체 설계를 개발자가 직접 하는 것이고 설계대로 코딩하는 것을 AI 도움을 받고, AI가 만든 코드를 검수하며 손으로 직접 고치면서, 가끔은 AI가 만들어준 코드를 통해서 배우면서 개발하는 것입니다. 이 방법은 효율적이면서 개발자 본인에게도 의미 있는 작업입니다. 이러한 생각의 흐름을 따라가다보면, 그래서 AI 코딩 시대에 개발자들에게 중요한 것은 무엇인가라는 질문을 하게 됩니다. AI를 잘 사용하는 것이 자체가 중요한 것이 아닙니다. AI를 잘 사용하기 위한 개발자 본인의 역량이 다시 한번 강조됩니다. AI에게 무엇을 어떻게 시킬지 잘 알고, 내 말을 무조건 따르는 팀원의 역할로 AI를 활용하는 것입니다. 내가 잘 알아야 잘 시킬 수 있습니다.

혹자는, AI가 더 발달하여 현재 AI가 커버하지 못하는 영역의 개발도 해줄 날이 올 것이라고 합니다. 저도 그날이 올 것이라고 생각합니다. 하지만, 그 시절이 되면 더 높은 난이도의 개발이 필요하고 그 영역은 다시 인간이 원하는, 인간의 경험에 기반하여 AI 도움을 받는 방식의 반복이지 않을까 예상해봅니다.

회사에 따라 개발의 영역과 난이도가 다릅니다. 대부분의 개발이 AI만으로 가능한 회사도 많을 것이라 확신합니다. 그 회사들은 개발 자체가 회사의 성패와는 약간 거리가 있고, 개발 결과물이 하나의 도구로 사용되는 수준의 회사일 가능성이 높습니다. 그 회사들은 AI 도움으로 엄청난 효율성을 볼 수 있다고 생각하고 그렇게 실천하는 것이 바람직하다고 봅니다. 중요한 것은 우리가 바라는 개발의 결과물이 우리 회사에게 어떤 의미냐에 따라 AI의 도움을 어떻게 받을 것인지 판단하면 되는 것입니다.

(본 글은 AI 도움없이 작성되었습니다. 일부 오타 수정만 도움 받았습니다.)