23년도, 전역을 하고 규호와 함께 DevOps 세미나를 보러 갔다.
어쩌다가 규호도 그 세미나에 같이 가게 되었는지, 정확한 히스토리는 기억나지 않는다. 하지만 그것이 시발점이었다는 건 확실하게 기억한다.
세미나가 끝나고, 규호가 나에게 연락을 했다. 자신의 동아리(지금의 플레이콕 ㅋㅋ) 안에서 사용되는 애플리케이션의 한계를 파악하고, 노코드 개발 툴을 활용해 동아리 내부의 니즈를 직접 해결해보고자 한다는 거였다.
그 모습을 본 순간, 나는 규호에게서 개발자로서 가져야 할 가치관 중 하나를 봤다. 바로 현실 속의 문제를 논리적인 사고방식을 통해 소프트웨어로 자연스럽게 풀어보고자 하는 것. 내가 어릴 때부터 밥 먹듯이 해왔던 그것을, 규호가 하고 있었다.
그 모습을 보고 나는 순간적으로 충동이 들었다. 어떠한 사고의 절차도, 깊은 생각도 없이 바로 말했다.
"규호, 나랑 같이 프로젝트 한번 해볼래?"
그 뒤 규호의 반응이 자세하게 어떤 느낌이었는지는 가물가물하다. 그게 벌써 3년 전이니까.
시작 — 서로의 합을 맞추던 시절
그렇게 처음 시작된 프로젝트가 JEYSport… 라고 생각하겠지만, 사실 그 이전에 서로의 합과 개발 방법론을 체득하기 위해 간단한 샘플 구현, 아이디어 프로토타이핑을 통해 기초적인 과정과 합을 확인하는 시간이 있었다.
초보 개발자들, 정말 코드에 입문하는 사람들이 가장 크게 두려워하고 의문을 갖는 것 중 하나가 이것이다.
"어떻게 프로그램을 개발하기 위해 두 사람이 소스코드를 병행해서 하나의 프로그램을 만들 수 있죠?"
사실 나도 이 부분에 대해 이론적으로만 알고 있었지, 실제로 피부로 느낀 적은 없었다.
(그럼에도 나는 규호에게 아는 척을 굉장히 많이 했다.)
아는 척에 대하여
예전에 규호에게도 말했지만, 내가 말하는 "아는 척"이란 이런 의미다.
나만의 고유한 설명 방법으로 말할 수 있을 정도가 아니라면, 나는 그것을 이해하지 못한 거고, 모르는 거라고 생각한다. 자신의 고유한 설명 방법으로 무언가를 말하려면, 그 개념에 대해 일반적으로 알려진 구체적인 사실과 정보를 알고 있어야 하고, 나아가 추상적으로 설명하기 위해서는 본인만의 지식 베이스를 구축해야 한다.
나는 이 부분에 대해서 나만의 지식 베이스를 구축하지 못한 채, 구체적인 사실과 정보만 알고 있는 경우가 많았다. 그런 상태에서 규호에게 아는 척을 정말 많이 했다. 그걸 구태여 규호에게 말하지도 않았다.
왜냐하면, 우리의 개발을 성공적으로 진행하기 위해서는 같은 방향을 보면서 나아가야 했고, 그 방향성을 정립하고 주도하기 위해서는 흔들림 없는 자신감을 보여줘야 한다고 생각했기 때문이다.
예전에는 늘 그랬다. 처음 보는 동료들과 프로젝트를 하게 되었을 때, 불확실한 영역에 닿게 되었을 때, 나는 항상 그래왔다.
전환점 — RAGIT, 그리고 진짜 협업
하지만 2년째가 되고, 25년도 공개 개발자 대회에서 RAGIT을 할 때는 달랐다.
내가 AI학과인데도 불구하고, 더 많은 것을 알아야 하는 위치에 있었음에도 불구하고 — 아는 척을 아예 하지 않았다.
이미 확실한 신뢰의 관계가 깊게 형성되었기에, 이제는 내가 주도하지 못해도, 약간의 방향성을 잃어도, 규호가 잡아주고 맡아줄 수 있는 사람이 되었다고 판단했기 때문이다.
RAGIT을 하기 전까지는 규호의 작업 영역에서도 내가 굉장히 신경을 많이 쓰고자 했었다. 본인이 그것을 인지하고 있었을지는 잘 모르겠다. 하지만 RAGIT에서는 정말 느낌이 달랐다. RAG의 핵심 코어 부분에 대한 책임과 판단을 아예 규호에게 맡겼다.
완벽한 의미의 협업이 비로소 2년 만에 이루어졌고, 정말 성공적인 프로젝트가 만들어졌다고 생각한다. 거기에 결과물까지 증명되었으니, 이 활동이 가졌던 가치와 의미는 정말 많은 것을 시사한다.
재밌는 비유를 하나 들어보겠다.
동료와 둘이서 수많은 적을 상대하고 있다. 우리는 서로 등을 맞대고 있는 상황이다.
이 상황에서 나는 동료를 믿고, 동료의 상황에 신경을 아예 쓰지 말아야 한다.
그런데 동료를 걱정해서 흠칫 뒤를 돌아봤다고 해보자. 내 눈에 동료가 적에게 공격당하기 직전인 게 보인다. 나는 내 영역을 잠시 버리고 동료의 위험을 막았다.
결과적으로는 동료의 위험을 막았고, 좋은 상황처럼 보일 수 있다. 하지만 그렇지 않다. 그 순간 내가 적에게 공격을 받았다면? 동료를 위해 잠시 지켜준 거 아니냐고? 아니다. 그런 판단을 한 순간 팀의 리소스 손실이 발생한다.
그 판단 자체를 머릿속에서 지워버려야 한다. 동료가 공격을 받았다면 그건 동료의 영역에서 일어난 일이지, 나의 잘못이 아니다.
협업이란 그런 것이다.
그리고 이제는 규호가 충분히 성장했다. 소프트웨어 개발을 제외한 모든 영역에서는 나를 충분히 상회하고도 남는다. 아니, 어쩌면 소프트웨어 개발마저도 상회할지 모른다.
실력을 비교하려는 게 포인트가 아니다. 서로의 등을 맞대고, 서로의 영역을 전혀 신경 쓰지 않아도 그 상황을 완전히 타파할 수 있는 완벽한 동료가 되었다는 것. 그것이 핵심이다.
23년, 24년에는 다양한 상황과 다양한 프로젝트를 통해 우리는 성장과 실패를 반복했다. 구체적인 사례들도 많지만, 그 내용까지 다 담기에는 글이 너무 길어질 것 같아 생략한다.
그 모든 과정을 거쳐, 우리는 25년도에 어떠한 잡음 없이 RAGIT 프로젝트를 성공시켰다. QA도 문제 없었고, 소프트웨어의 품질, 실제 기능의 동작, 프로젝트 일정 관리, 협업 그 자체 — 모든 것이 매끄러웠다.
(뭐… 라이선스 문제라든가, 마지막 발표에 대한 스탠스가 서로 달랐다는 점만 빼면…?)
그리고 개인적으로, 추석에 34일 정도 내 자취방에서 밤을 새워가며 같이 코딩했던 게 참 좋았다.3배는 훨씬 더 즐겁다는 건 사실이다. 혼자보다 무조건 둘이 낫다고 생각한다.
함께 개발한다는 건 혼자 할 때보다 2
페이스메이커
이건 소프트웨어 개발에만 국한된 이야기가 아니다.
23년도부터 규호라는 친구와 함께 페이스메이커로 달릴 수 있었기에, 지금까지 혼자 해왔던 것과는 차원이 다르게 효과적으로 성장할 수 있었다.
효과적으로 성장한 수준이 아니라, 규호라는 친구에게 도움과 영향을 정말 많이 받았다.
첫 2주년 회고록이라 그런지, 프로젝트나 기술, 개발, 업무적인 부분의 회고록을 작성해야 하는데 감성에 빠져서 이런 글을 쓰게 되었다. 다음에는 프로젝트에서 발생한 실무적인 부분에 대해서만 글을 작성할 것이다…!
26년도에 들어와서는 잠시, 서로의 교집합 없이 각자의 영역에서 해야 할 일들이 명확하게 존재하기에 아쉽게도 함께하는 프로젝트는 쉬어가게 되었다.
서로 개인적인 목표와 활동만 공유하면서 나아가는 중이다.
하지만 이건 끝이 아니라 잠시 멈춤이다.