함께 일한 개발자들
결국 사람이다.
25년 동안 수많은 개발자들과 일했다. 신입부터 특급까지, 말 많은 사람부터 하루 종일 한마디 안 하는 사람까지. 프로젝트는 혼자 하는 게 아니기에, 결국 함께 일한 사람들이 프로젝트를 만든다.
제일 안타까운 건 도움을 청하지 못하는 개발자들이다. 코드가 풀리지 않아 며칠을 끙끙 앓다가 마감 직전에야 말한다. "사실 이 부분이 안 돼서..." 이미 늦었다. 급하게 다른 사람에게 넘기거나, 일정을 지연시킬 수밖에 없다.
왜 못 물어보냐고 하면 대답은 비슷하다. "제가 해결할 수 있을 것 같았어요." "민폐 끼치기 싫었어요." "이것도 못하면 무능해 보일까 봐요."
하지만 반대다. 모르는 걸 며칠씩 붙잡고 있는 게 더 무능해 보인다. 프로젝트 전체를 지연시키는 게 더 민폐다. 경력이 20년이어도 막히는 부분은 분명 존재한다. 다른 개발자들과 같이 고민하면 해결책은 보인다.
한 후배가 있었다. 경력 3년 차였는데 질문을 거의 안 했다. 항상 "네, 알겠습니다" 하고 자리로 돌아갔다. 중간 체크를 해도 "잘 진행되고 있습니다"라고만 했다. 막판에 코드를 확인했더니 엉망이었다. 기본 구조부터 잘못 짜서 전체를 다시 만들어야 했다.
물었다. "왜 안 물어봤어?" 후배가 답했다. "수석님이 바빠 보여서요. 그리고 이 정도는 제가 할 수 있어야 한다고 생각했어요." 바빠도 물어보는 게 맞다. 나중에 다시 만드는 게 더 시간이 오래 걸린다.
그 후로 그 후배에게는 매일 진도를 물었다. 막히는 부분이 있으면 바로 같이 보자고 했다. 처음에는 쑥스러워했지만, 점차 익숙해졌다. 질문하는 걸 배웠다.
반대로 모든 걸 혼자 하려는 개발자들도 있다. 자기 파트만 책임지면 되는데, 다른 파트까지 신경 쓴다. "이 부분은 제가 같이 봐드릴게요." "저기 구조가 이상한데 제가 고칠까요?"
고마운 일이지만 때로는 문제가 된다. 자기 일정을 희생하면서 다른 사람을 돕다가 정작 자기 일을 못 끝낸다. 야근으로 메우려 하지만 체력이 버티지 못한다.
한 개발자가 그랬다. 경력 12년 차였고 파트장이었다. 파트원들이 막힐 때마다 직접 나서서 같이 코드를 봤다. 심지어 다른 파트 후배들까지 도와줬다. 본인 개발은 밤에 했다.
한 달을 그렇게 보내더니 결국 쓰러졌다. 과로였다. 일주일 쉬고 복귀했지만 예전 같지 않았다. 이후로는 도움을 주되, 선을 긋는 법을 배웠다고 했다. "이 부분은 직접 찾아보고, 그래도 안 되면 다시 물어봐" 하고 방향만 알려주는 식으로.
말이 안 통하는 개발자들도 있다. 기술적으로는 뛰어난데 설명을 못한다. "이게 이렇게 되는 거잖아요"라고 하는데, 전혀 이해가 안 된다. 다시 물어보면 똑같은 말을 반복한다.
코드로만 대화하려는 사람도 있다. "여기 보세요, 이렇게 짰잖아요." 코드를 보여주는데 주석도 없고 변수명도 알아보기 힘들다. 왜 이렇게 짰는지 물어보면 "이렇게 하는 거 아닌가요?"라고 한다.
함께 일하기 힘들다. 아무리 실력이 좋아도 협업을 못 하면 프로젝트에서는 독이 된다. 결국 그런 개발자는 혼자 할 수 있는 부분만 맡게 된다. 다른 사람과 연결되는 기능은 주지 않는다.
반대로 기술은 부족해도 소통을 잘하는 개발자는 팀에서 환영받는다. "이 부분 제가 이해한 게 맞나요?" "이렇게 하면 될 것 같은데 확인 좀 부탁드려요." 겸손하게 묻고, 명확하게 확인한다. 실력은 시간이 지나면 늘지만, 소통 방식은 쉽게 안 바뀐다.
실력은 좋은데 관계가 좋지 않은 사람, 실력은 별로인데 관계가 좋은 사람. 둘 중에 선택하라면 관계가 좋은 사람을 선택한다. 실력은 학습이 가능하다. 관계는 학습하기에는 힘들다.
테스트 기간이 되면 모두가 지친다. 매일 쏟아지는 오류 목록, 밤을 새워 고치는 코드, 다음날 또 올라오는 같은 문제. 이 시기를 함께 버티는 경험이 팀을 만든다.
밤 10시, 사무실에 남은 개발자들끼리 치킨을 시킨다. 먹으면서 하루를 정리한다. "오늘 오류 몇 개나 고쳤어?" "열다섯 개." "나는 스무 개." 웃으면서 이야기하지만 모두 지쳐있다.
새벽 2시, 아직도 안 풀리는 코드를 붙잡고 있는 후배에게 선배가 다가간다. "같이 볼까?" 둘이서 모니터를 보며 한 줄 한 줄 따라간다. 새벽 3시에 원인을 찾는다. 하이파이브를 하고 각자 집으로 향한다.
이런 순간들이 쌓인다. 프로젝트가 끝나고 뿔뿔이 흩어져도 그때의 기억은 남는다. 다른 프로젝트에서 다시 만나면 반갑다. "그때 그 프로젝트" 이야기를 한다. 함께 지옥을 버텨낸 사람들은 특별하다.
경력이 쌓이면서 배우는 것보다 가르치는 일이 많아진다. 신입 개발자에게 프로젝트 구조를 설명하고, 코드 리뷰를 해주고, 막힌 부분을 같이 본다.
하지만 배움은 계속된다. 신입 개발자가 새로운 기술을 알려줄 때도 있다. 최근에 나온 프레임워크, 새로운 개발 도구, 효율적인 단축키. "팀장님, 이거 아세요? 이렇게 하면 훨씬 빠른데." 고맙게 배운다.
경력이 적다고 배울 게 없는 게 아니다. 경력이 많다고 다 아는 게 아니다. 서로 주고받는다. 그게 팀이다.
개발자마다 속도가 다르다. 어떤 사람은 빠르게 많은 양을 해낸다. 어떤 사람은 느리지만 꼼꼼하게 한다. 어떤 사람은 처음에는 느린데 나중에 속도가 붙는다.
속도가 빠른 게 무조건 좋은 건 아니다. 빠르게 짜고 오류가 많으면 결국 수정하느라 더 시간이 걸린다. 느려도 처음부터 제대로 짜면 테스트에서 문제가 적다.
중요한 건 자기 속도를 아는 것이다. 그리고 팀 전체의 속도에 맞추는 것이다. 혼자 빨라봤자 다른 사람이 완료해야 다음 단계로 넘어간다. 혼자 느리면 전체가 기다린다.
25년 동안 뛰어난 개발자도 많이 봤고, 실력은 부족하지만 열심히 하는 개발자도 많이 봤다. 소통 잘하는 사람, 묵묵히 일하는 사람, 리더십 있는 사람. 모두 달랐다.
하지만 좋은 프로젝트를 만든 팀의 공통점은 있었다. 서로 돕고, 함께 버티고, 질문하는 걸 두려워하지 않고, 실수를 나무라지 않고, 각자의 속도를 인정하는 팀. 결국 기술보다 사람이다.
AI가 코드를 작성해 주는 바이브 코딩시대에는 사람과의 관계가 더욱 중요하다. 코드 실력이 좋다는 건 옛말이 될 듯하다. 코드는 AI가 만든다. 그것을 컨트롤할 사람은 있어야 한다. 코드를 작성하는 것에서 컨트롤 실력으로 이동하고 있다. - 무엇인가를 컨트롤한다는 것은 그것보다 더 많은 것을 알고 있어야 한다. -
AI가 코드를 대신한다고 해도 좋은 프로젝트는 좋은 팀과 사람이 만드는 것에는 변함이 없다.
