📌 Introduction
디프만 18기 합격 후기를 남긴 게 엊그제 같은데 벌써 이번 주면 최종 발표 세션이다.
이번 기수에서 얻어가고 싶은 것들이 제법 있어 굉장히 열심히 참여를 한 덕분에 18기에서 내 이름을 모르는 사람은 없을 것 같다.
인적 네트워크부터 새롭게 만들어본 나의 페르소나 테스트, 새로운 팀 리딩 방식 시행착오 경험과 업계 정보 수집 등 뽑아먹을 수 있는 경험과 데이터들은 알차게 뽑아먹었다.
시간과 체력이 갈려나간 감이 없진 않지만, 지금은 디프만을 하기로 한 것이 성공적인 투자였다고 확신할 수 있다.
이번 글은 디프만 18기 첫 주차부터 품고 있던 한 가지 개인적인 고민에 대한 기록이다.
디프만 활동의 구체적인 정보를 얻을 목적이라면 이 글은 권하지 않는다.
📌 개발 동아리가 더이상 가치를 지닐 수 있는가?
언젠가부터 나는 어디에 속하든 '내가 만약 이곳을 운영한다면 어떻게 할까'를 상상하는 버릇이 생겼다.
이 버릇은 디프만에서도 발현되어, 첫 주부터 운영진이 동아리를 운영하는 방식을 관찰하게 만들었고, 운영 직책별로 '나라면 어떻게 했을까'를 머릿속으로 굴려보곤 했다.
그런데 활동 중반쯤부터 그 시뮬레이션이 자꾸 막히기 시작하면서, 상상은 나를 꽤 불편한 자리로 데려다 놓았다.
AI가 개발을 한다.
디자인도 하고, 기획의 상당 부분까지도 개입한다.
만드는 일의 대부분을 AI가 가져가는 시대에, 그렇다면 개발 동아리는 도대체 어떠한 가치를 지니는가.
내가 조사한 바로는, 학생들은 포트폴리오에 쓸 소스를 만들고 현직자와 협업해보기 위해, 현직자들은 회사가 아닌 자기만의 제품을 만들고 커뮤니티의 네트워크에 속하기 위해 지원하는 비중이 가장 컸다.
그렇다면 더이상 개발 동아리에 가입하는 메리트가 없다고 봐야하지 않을까?
- 협업 경험을 노린다 해도, 현직 개발자 중 학생과 확연히 차이 날 만큼의 AI 활용 경험을 가진 이가 몇이나 될까. 산업군에 따라 실무에서 AI를 거의 안 쓰는 경우도 있다. 운영진이 방향성을 이쪽으로 잡고 현직자를 선발한들, 합격자 전원이 만족할 수준을 보장하긴 어렵다. 확률적으로는 원하는 경험을 얻지 못할 가능성이 더 크다.
- 있다고 하더라도 대부분은 정보를 취하고 싶어하지, 가진 정보를 나누는 이들은 소수다.
- 기획을 빠르게 결정하고 UT를 통해 짧은 주기로 스프린트를 이어나가려면 팀의 규모는 작은 것이 좋다. 특히나 이런 밑바닥부터 시작해야 하는 사이드 프로젝트일 수록 더더욱. 그러나 지금 팀의 규모가 너무 크다. 인원을 줄이자니 학생의 시험기간, 취준생의 면접, 직장인의 업무와 탈주 같은 예측 불가능한 변수가 팀 밸런스를 무너뜨릴 수 있어 운영진 입장에서는 신중해질 수밖에 없다. AI 시대의 흐름과 가장 크게 불협화음을 내는 지점이라고 본다.
- 제품을 목적으로 온다면 가장 불확실성이 크다. 네트워크는 개인의 노력으로 만들 수 있지만, 제품은 단순한 기술력의 문제가 아니기 때문이다. '운영 경험'이라는 목적 하나로 시간과 열정을 투자하기엔 리스크가 가장 크다.
곰곰이 생각해봐도 그나마 남는 건 친목을 위한 네트워킹 정도다. 그러나 남는 게 네트워킹뿐이라면, 그냥 사교 동아리에 가는 게 더 이득 아닌가.
특히나 요즘처럼 Generalist의 역량이 중요해지는 시대에 비슷한 직군의 사람들끼리 모여서 사고가 갇히는 것보다, 차라리 다양한 도메인에 종사하는 사람들과 이야기해보는 것이 훨씬 생존에 유리한 전략일 수도 있다.
그렇다면 더더욱 '개발' 동아리여야 할 이유는 없지 않을까?
누군가는 이에 대한 혜안을 가지고 있을 수도 있겠으나, 나는 내 질문에 대한 반박이 쉽게 떠오르지 않아서 굉장히 불편했었다.
그리고 이 불편함을 회피하는 대신, 늘 그랬듯 정면으로 끌어안아 보기로 했다.
📌 개발은 단순히 '만드는 일'이 전부인가?
쉽게 답이 나오지 않는 질문에는, 질문 그 자체에 다시 의문을 품어보는 것이 도움이 될 때가 있다.
"정말 이제 개발 동아리에 남은 것은 네트워킹을 통한 친목뿐인가?"를 다시 던져보면, 초기 질문에 아직 검증하지 않은 전제가 하나 깔려 있음을 알 수 있다.
"AI가 '만드는 일'을 가져가면 사람이 할 일도 함께 사라진다"는 전제다.
개발 동아리의 가치가 줄어든다는 결론은, 결국 개발자가 하던 일이 곧 '만드는 일'이고 그게 전부였다는 가정 위에 서 있다.
만약 만들기 말고도 사람이 해야만 하는 무언가가 남아 있다면, 그 전제는 무너지고 의심도 함께 흔들린다.
그러니 지금부터 내가 해야할 일은 검증이었다.
실무에서 배운 깨달음이 개발 동아리에서도 통용되는 가치인지, 개발자의 일에 코드를 생성하는 것 이상의 무언가가 남아 있는지를 직접 확인할 수 있다면, 기존의 전제를 무너뜨릴 수 있게 된다.
📌 AI-Native Development
팀의 서버 파트장을 맡게 되었고, 이번 프로젝트는 AI-Native 방식으로 진행하기로 충분히 합의를 거쳤다.
다만 팀원들은 아직 AI를 본격적으로 활용해 개발해본 경험은 없었다.
그래서 처음부터 정교한 안전장치(Harness)를 갖추고 시작하는 대신, 그 안전장치가 왜 필요한지를 먼저 체감하는 방향으로 프로젝트를 끌고 갔다.
아주 기본적인 규칙 문서와 구조를 잡기 위한 예시 파일만 만들고, 나머지 작업은 모두 AI에게 맡겨버렸다.
리뷰를 통해 "만들기를 전부 AI에게 넘기면 어떻게 되는가"를 직접 확인하고 점진적으로 개선해나갈 생각이었으나, 일정이 예상보다 촉박해지면서 리뷰도 못 한 채 일단 원격 저장소에 전부 올려버리는 대참사가 벌어졌다.
이런, 이건 내 계산 밖의 일이었다.
동아리가 시작하고 한 달쯤 지났을 때, 팀원들에게 중간 감상을 물었다. 돌아온 답은 "색다른 경험이고 좋았다"였다.
예상과 다른 답이었다. 그래서 한 가지를 더 제안했다.
"각자 자신이 맡았던 작업의 주요 기능만이라도 좋으니, 직접 코드 리딩을 하고 리뷰를 해봅시다. 그 후에 다시 한 번 감상을 물어볼게요."
아니나 다를까, 1~2주 뒤 동일한 질문에 대한 답은 완전히 뒤집혀 있었다.
사용하기만 하고 제대로 이해하지 못한 코드가 여기저기 누적되면서 코드베이스는 손대기 어려운 상태가 되었고, 직접 읽기 전까지 마냥 좋다고 느끼던 것들이 실은 엉망이 되어 있었음을 그들 스스로 깨닫게 되었다.
harness가 마련되어 있었다면 이야기는 달랐을 거라고?
글쎄, 난 harness를 silver bullet으로 여기지 않는 사람이라 모르겠다.
📌 AI가 가져가지 못한 것
이 작은 실험은 초기 전제를 정면으로 반박했다.
AI가 만들기를 전부 가져갔음에도, 정작 잘 만들어졌는지를 판단하는 일은 자동으로 따라오지 않았다.
심지어 이 기술 부채가 너무 많이 쌓인 나머지, 최종 런칭 때 사람이 몰려 서버에 장애가 나도 손쓸 수 있는 게 없었다.
장애가 왜 나는지 아무도 이해하지 못했기 때문이다. (사실 이건 내가 모니터링 도구를 너무 대충 붙여놓은 탓도 있다.)
"AI가 작성한 코드를 제가 왜 리뷰하죠?"
이런 물음은 서비스를 운영하며 장애의 책임을 져본 적이 없을 때 나오기 쉽다.
frontier model을 개발하는 회사들조차 100% AI에게 맡기지는 않는다.
"그럼 검증하는 일도 AI에게 맡기면 되잖아요?"
좋은 접근이다. 하지만 이 또한 쉽지 않은 일이라는 것을 알게 될 것이다.
지표를 계산하고 수치를 뽑고 테스트를 돌리는 것처럼 정적인 일들은 충분히 할 수 있으나, 모호한 경계에서 기준을 나누고 무엇을, 누구를 위해 측정을 할 가치가 있는지 판단하는 일은 쉽지 않다.
어떤 질문을 던질지, 무엇을 나아짐의 기준으로 삼을지, 어디까지를 한 번에 검토할 범위로 볼지는 계산이 아니라 판단의 영역이다.
판단을 AI에게 완전히 넘겨본 적이 있는가? 사이드 프로젝트에서 중반쯤부터 공포를 느꼈었다.
AI에게 내 자리를 내어주고 관점을 옮겨야 한다고 주장해왔지만, 이건 능동적으로 관점을 옮긴 것이 아니라 AI에 의해 자리에서 완전히 밀려난 것에 가까웠다. (책임은 여전히 내가 지는데 불구하고!)
어느샌가부터 AI가 내게 설계 방향성을 논의하자고 제의를 해도 아무것도 논의할 수가 없었다. 내가 지금 코드 베이스와 설계를 전혀 모르고 있었기 때문이었다.
검증을 건너뛴 대가는, 그렇게 나에게도 똑같이 돌아왔다.
"만드는 것"의 가치가 0에 수렴하고 있는 작금의 시대에, 검증의 능력은 여전히 엔지니어가 가져야 할 덕목이라고 나는 말하고 싶은 것이다.
만든 것을 스스로 검증하지 않으면, 그 경험은 학습이 아니라 한 번 스쳐간 일화로 휘발될 뿐이다.
일화를 학습으로 바꾸어야 한다.
여기서 초기의 전제는 무너진다.
AI가 만들기를 가져가도, 개발자에게는 검증이라는 일이 남는다.
개발 동아리의 가치 역시 거기서 다시 시작될 수 있다.
📌 혼자서 쌓을 수 있는가
그런데 의심은 마지막 보루를 하나 더 쥐고 있다.
검증이 남은 가치라 치자. 그건 혼자서도 쌓을 수 있지 않은가. 굳이 동아리라는 공동체가 필요한 이유는 무엇인가.
이 물음에 답하지 못하면 결국 "그럼 혼자 공부하면 되지"로 모든 게 무너진다.
혼자 하는 검증은 외롭고, 무엇보다 미루기 쉽다. 더 큰 문제는 나를 들여다보는 눈이 나 하나뿐일 때다. 그러면 기준도 내 안에 갇힌다.
내가 세운 질문이 충분히 날카로운지, 내가 놓친 각도는 없는지를 스스로는 알기 어렵다. 검증은 타인의 시선 앞에 설 때 비로소 날카로워진다.
내 팀에서 평가를 뒤집은 것도 결국 시선이었다. "리뷰해봅시다"라는 말은 자기 코드를 남에게 설명할 수 있는 상태로 만들라는 요구였고, 그 시선을 의식하는 순간 보이지 않던 것이 보이기 시작했다.
여기서 앞서 미뤄둔 Generalist 이야기로 돌아오게 된다.
다양한 도메인의 사람과 섞이는 것이 사고를 넓히는 데 유리하다는 말은 분명 옳다. 그러나 검증이라는 관점에서 보면, 아무나의 시선이 다 같은 무게를 갖는 것은 아니다.
내 가설이 충분히 날카로운지, 내가 택한 기준이 적절한지를 깊이 되짚어줄 수 있는 건 같은 언어를 쓰는 동료다. 막연한 격려가 아니라 "그 측정은 무엇을 놓치고 있다"고 짚어줄 수 있는 시선 말이다.
사고를 넓히는 만남과, 검증을 벼리는 만남은 다르다. 그리고 후자야말로 '개발' 동아리가 사교 모임과 갈라지는 지점이다.
사교 모임은 사람을 만나게 해준다.
그러나 같은 일을 하는 사람들이 서로의 검증을 들여다보는 자리는, 사람을 만나게 하는 동시에 각자를 한 걸음씩 밀어 올린다.
같은 '만남'이라도 그 만남이 무엇을 향하는지가 다른 것이다.
📌 네트워크는 가치를 만들기 위한 수단이어야 한다.
이제 처음의 의심으로 돌아온다.
먼저 그 의심의 정당한 부분을 인정해야 한다.
네트워킹만이 목적이라면, 정말로 사교 동아리가 더 낫다. 개발이라는 고생을 굳이 끼워 넣을 이유가 없으니까. 이 점에서 처음의 의심은 옳았다.
그러나 바로 그렇기 때문에, 네트워크는 목적이어서는 안 된다는 결론에 닿는다.
그동안 네트워크는 종종 그 자체가 목적이자 종착지처럼 다뤄지곤 했다. 연결되는 것, 인맥을 쌓는 것이 활동의 목표가 되는 식으로.
나 역시 그 분위기 속에 있었기에 안다. 그러나 연결만을 향해 달리면, 막상 연결된 다음에 묘한 공허함이 남는다.
연결되었다, 그래서 무엇을 할 것인가?
네트워크의 자리를 종착지가 아닌 출발점으로, 목적이 아닌 수단으로 옮겨야 한다.
네트워크는 그 위에 '서로의 검증을 벼리며 함께 성장하는 일'을 올리기 위한 지반이다.
그 위에 무언가를 올리는 순간, 개발 동아리는 비로소 사교 모임과 갈라진다.
같은 네트워크라도 그것이 무엇을 떠받치느냐에 따라 전혀 다른 것이 된다.
이것이 첫 주부터 나를 불편하게 했던 질문에, 한 기수를 꼬박 보내고 내가 도달한 답이다.
개발 동아리는 여전히 가치를 지닐 수 있다.
단, 네트워크를 목적이 아니라 가치를 만들기 위한 수단으로 다시 세울 때.
📌 그래서, 내가 운영한다면
이 글은 '내가 운영한다면 어떻게 할까'라는 상상에서 시작했으니, 그 상상으로 마무리하는 것이 맞겠다.
아래는 누구에게 권하는 처방이 아니라, 지금 시점에서 내가 그려보는 개인적인 구상일 뿐이다.
내가 운영을 맡는다면, 네트워킹과 검증을 같은 시간 축 위에서 순차적으로 끊어두지 않을 것이다.
"일단 친해지고 나중에 검증 문화를 만들자"는 분리는 작동하지 않으리라 본다.
친목만을 위한 자리에는 사람이 잘 모이지 않고, 미뤄둔 검증은 좀처럼 돌아오지 않기 때문이다.
둘을 시간 위에 끊어 놓으면 십중팔구 둘 다 놓친다.
특히나 요즘처럼 자신에게 명확한 이득이 돌아오지 않는다면 참여를 하지 않는 문화일 수록 더더욱 그렇다.
그래서 나는 둘을 한 그릇에 담아보고 싶다.
함께 검증하는 경험 그 자체를 어울림의 형식으로 만드는 것이다.
"이런 걸 해봤는데, 그게 정말 나아졌는지 이렇게 재봤다"를 서로 내보이고, 자랑하고, 또 그 자리에서 기분 좋게 깨지는 자리.
이런 형식이라면 얻어갈 것이 있어 사람이 모이고, 그 자리에서 자연스럽게 친해지며, 무엇보다 검증이 의무가 아니라 자랑거리가 된다.
내 팀에서 "리뷰해봅시다"라는 한마디가 평가를 통째로 뒤집었듯, 공동체 단위에서도 같은 각성이 일어날 수 있지 않을까.
📌 아직 풀지 못한 것
물론 이 구상에도 내가 아직 답을 정하지 못한 빈칸이 있다.
사람을 움직이는 일을, 자발성에 맡길 것인가 아니면 구조로 떠밀 것인가.
면접 자리에서는 누구나 열심히 하겠다고 말한다.
그러나 막상 그 다짐만큼 움직이지 않는 것이 또한 사람이다.
동경하게 만들면 알아서 나아갈 것이라 믿고 자발성에 맡길 것인가, 아니면 발표 순번이나 기록의 의무 같은 장치를 두어 최소한의 움직임을 끌어낼 것인가.
돌이켜보면 내 팀에서 각성이 일어난 것은, 파트장인 내가 "리뷰해봅시다"라고 떠밀었기 때문이다.
그 강제가 없었다면 "색다른 경험이고 좋았다"에서 멈췄을지도 모른다.
작은 팀에서는 한 사람이 그 역할을 할 수 있다. 그러나 공동체의 규모에서, 그 떠미는 역할은 누가 어떻게 맡아야 하는가.
솔직히 나는 아직 이 질문의 답을 갖고 있지 않다.
다만 이 빈칸을 품은 채로 다음 걸음을 고민하고 있다는 것까지가, 지금 내가 정직하게 말할 수 있는 전부다.