한국에는 PC방이 있었다. 개발자에게는 어떤 환경이 필요할까

유학 시절 스타크래프트에서 한국인이라는 말 한마디가 만들던 기대에서 시작한 질문이다. 실력은 어디에서 만들어지는가. PC방이 보여준 연습과 피드백의 반복을 개발자의 하루로 옮기면, 변경 뒤에 무엇이 일어나는지 보이는 환경이 된다.

백재민
백재민
CollabOps 창업자
한국에는 PC방이 있었다. 개발자에게는 어떤 환경이 필요할까

유학 시절 스타크래프트를 하다가 한국인이라고 말하면 상대가 게임을 나가버리는 일이 있었다. 지금 생각하면 웃긴 장면인데, 그때는 꽤 진지한 질문으로 이어졌다. 사람의 실력은 어디에서 만들어지는 걸까.

내게 PC방은 그 질문을 떠올리게 하는 공간이다. 컴퓨터가 있고, 같이 게임할 사람이 있고, 잘하는 사람의 플레이를 옆자리에서 볼 수 있다. 한 판을 끝내면 결과를 확인하고 바로 다시 시도한다. 연습과 피드백이 누가 시키지 않아도 반복된다.

이 글은 그 비유를 개발자의 하루로 옮겨본 것이다. 지금 나는 한국에서 CollabOps라는 개발·운영 플랫폼을 만들고 있고, 게임을 하며 품었던 관심이 개발자가 일하는 환경을 만드는 일로 이어져 있다.

사람의 실력은 어디에서 만들어질까?

연습과 피드백의 간격이 짧은 환경에서 만들어진다. PC방에는 그 조건이 전부 있었다. 도구가 있고, 함께할 사람이 있고, 잘하는 사람이 보이고, 한 판의 결과가 바로 나온다. 재능 있는 사람이 실력을 키우고 결과를 만들어내는 데 필요한 것은 결국 이 반복이 일상에 얼마나 가까이 있느냐였다.

근데 이건 게임 얘기만은 아니다. 소프트웨어 엔지니어로 일하면서 같은 눈으로 일하는 환경을 보게 됐다. 같은 개발자라도 변경 사항을 검토받는 과정, 테스트를 실행하는 방법, 배포 결과를 확인하는 경로에 따라 하루의 경험이 완전히 달라진다. 코드를 작성한 뒤 무엇이 일어나는지 이해할 수 있으면 다음 행동을 결정하기도 쉬워진다.

개발자의 하루에서 피드백은 어디에서 끊기나?

코드를 고친 뒤와 그 결과를 확인하는 사이에서 끊긴다. 예를 들어 이런 상황을 생각해 보자. 코드를 고치고 나서 어떤 검사를 해야 하는지 찾는다. 누구에게 승인을 받아야 하는지 물어본다. 실제 배포된 버전이 무엇인지 다시 확인한다. 각각은 작은 일이다. 그런데 하루에 몇 번씩 반복되면 개발자가 문제 자체에 집중할 수 있는 시간을 차지한다.

경험 많은 사람이 주변의 질문을 계속 대신 풀어주게 되는 것도 같은 이유다. PC방으로 치면 옆자리의 플레이를 보는 대신, 매 판마다 규칙을 다시 물어봐야 하는 상태다.

좋은 개발 환경은 무엇을 보여줘야 하나?

다음 행동과 그 결과다. 변경을 만들면 필요한 검증이 무엇인지 보이고, 막혔다면 이유와 판단할 사람이 보이고, 배포 이후에는 실제로 무엇이 달라졌는지 돌아볼 수 있어야 한다. 실패한 경험도 다음 사람이 참고할 수 있는 형태로 남아야 한다.

내가 DevOps에 끌린 이유가 여기에 있다. 개발과 운영을 오가며 발생하는 일을 하나의 흐름으로 이해하고 싶었다. 좋은 코드를 만드는 과정만이 아니라, 그 코드가 사용자에게 도달하고 결과를 확인하는 과정까지 한 화면 안에 있어야 한다는 생각이다. 저장소, 변경 요청, 파이프라인, 배포 기록이 처음부터 한 평면에 있으면 "다음에 뭘 해야 하지"라는 질문의 상당수가 사라진다. 소스 관리에서 배포까지에서 그 연결을 어떻게 설계했는지 적었다.

물론 도구가 사람의 실력을 대신해주지는 않는다. 요구사항을 이해하고 설계하고 검토하는 역량은 사람의 몫이다. 환경이 할 일은 그 역량이 매번 같은 준비 작업과 불필요한 추측에 쓰이지 않게 하는 것이다.

인터넷이 막힌 현장에서도 그런 환경이 가능한가?

가능해야 하고, 그래서 좋은 개발 환경은 현장에서 실제로 쓸 수 있는 형태여야 한다. 기업과 공공기관을 만나면서 환경의 조건이 얼마나 다른지 배웠다. 인터넷을 자유롭게 쓸 수 없는 곳이 있고, 기존 시스템을 계속 유지해야 하는 곳이 있고, 도입할 인프라와 인력이 제한된 곳이 있다. 그 조건을 모른 채 익숙한 방식만 설명해서는 실제 일하는 환경을 바꾸기 어렵다.

설치하고, 배우고, 운영하고, 문제가 생겼을 때 복구할 수 있어야 한다. 처음에 멋지게 보이는 것과 계속 일에 쓰이는 것 사이에는 이런 조건들이 있다. CollabOps가 설치형을 기본으로 잡은 이유도 같다. 폐쇄망 안에서도 변경 하나에 검토·검증·배포 기록이 같이 붙어 있어야 PC방의 옆자리가 생긴다.

AI가 코드를 쓰는 시대에 이 질문은 어떻게 달라지나?

시도하는 사람이 늘어날수록, 무엇을 검증하고 누구와 판단해야 하는지 보여주는 환경이 더 중요해진다. AI로 소프트웨어를 만드는 방법이 늘면서 코드를 만들어보는 사람의 범위가 넓어졌다. 한 사람이 빠르게 시도한 결과가 조직이 신뢰할 수 있는 결과로 이어지려면 그 사이에 연결이 필요하다. 시도는 쉬워졌는데 확인은 그대로라면, 피드백의 간격은 오히려 벌어진다. 이 부분은 에이전트와 프로덕션 권한에서 따로 다뤘다.

사람이 가진 능력이 어떤 조건에서 더 잘 발휘되는지는 여전히 궁금한 질문이다. PC방에서는 옆자리의 플레이를 보고 다음 판에 바로 시도해볼 수 있었다. 개발자의 일에서 그 옆자리는 변경 하나를 열면 검토와 검증과 배포 결과가 같이 보이는 화면이다. 시도하고, 확인하고, 배우는 흐름이 자연스러운 환경. 우리가 만드는 제품이 그 환경의 일부가 되는지는 실제로 쓰는 사람들의 하루에서 드러난다.

태그#founder-notes#developer-experience#devops#feedback-loop#platform#culture