소프트웨어 개발 회사를 대략 10년 정도 다녔다.
현재는 퇴사한 회사에서 프리랜서를 하고 있다. 특별히 프리랜서를 하는 이유가 명확하진 않지만
조직생활의 회의감을 느꼈다고나 할까? 그리고 10년을 다닌 조직에 대한 환멸의 감정도 있었을 것이다.
그럼에도 불구하고 왜 다시 거기서 프리랜서를 하는가?
여러 가지 이유가 있지만 멋있게 포장하자면 실패한 도전에 대한 타협..
적나라하게 얘기하면 갈 곳이 없었다.
암튼 2024년에서 2026년으로 넘어오면서 흔히 바이브 코딩이란 것이 등장하며, 소프트웨어 개발의 판도가 변경되었다. 그냥 요즘 내가 느끼는 몇 가지 이슈를 그냥 얘기해보고 싶었다.
1. 투입인력의 의미
예를 들어, “오프라인으로 사용 동의를 받는 절차를 온라인으로 변경하고 싶어요.”라는 요구사항이 발생했다. 우선 기획자가 필요할 것이다. 해당 프로세스를 이해하고 온라인의 바꿀 경우에 대한 변경범위 그리고 가능여부 등을 따져보고 프로세스를 그려야 할 것이다. 필요에 따라 추가되는 데이터베이스 설계가 있을 것이고 추가로 API도 개발해야 하니 인터페이스에 대한 명세도 필요할 것이다. 그리고 기획안으로 요구사항을 제시한 고객과 협의가 필요할 것이다.
그리고 기획안을 바탕으로 디자인이 필요할 것이다. 적용할 웹화면 디자인 / 모바일 화면 그리고 개발을 위한 퍼블리싱까지 진행해야 한다. 디자인과 퍼블리싱이 완료되면 해당 페이지가 실제 동작 할 수 있도록 개발을 해야 할 것이다. 개발이 완료되면 테스트를 진행하고 실제 환경에서 동작하게 된다.
아주 간단한 프로세스에 대한 진행과정이다. 여기서 몇 명이 필요할 것인가.
우선 기획자는 역할에 따라 디자인과 퍼블리싱을 겸할 수도 있다. 다르게 얘기하면, PL급 개발자가 프로세스에 대한 설계나 DB, 인터페이스를 커버할 수 있다. 다만 고객과의 커뮤니케이션 부분에서는 개발자들은 부족하기보다는 기피하는 케이스가 많으니, 아무리 작게 잡아도, 두 명에서 세명은 해당 업무에 필요하다 볼 수 있다.
물론 3명이 모두 같은 업무 분량에 같은 시간을 들여서 일을 해야 한다는 좀 다른 얘기다. 저런 기능이 아주 많이 그것도 아주 많이 모였을 때 하나의 소규모 프로젝트가 될 텐데 지금 현실에서 위와 같은 기능을 구현하는 데는 한 명이면 충분하다.
물론 그게 개발자일수도 있고, 기획자일수도 있다. 기획자가 고객과 커뮤니케이션을 한 뒤 AI 도움으로 디자인+개발까지 진행한다. 또는 개발자가 AI의 도움으로 기획서를 작성하고, 디자인+퍼블을 진행해 개발까지 다 진행하고 점검 + 반영한다. 누가 해도 이상할 것 없다. 물론 여기서 반전은 고객 즉 요구사항을 느낀 사람이 직접 모두를 다해도 된다. 실제로 그것이 더 깔끔해졌다.
과거 10명이 필요한 프로젝트, 5명이 필요한 프로젝트 이렇게 개발 범위에 따라 필요인력을 나눴다면 이제는 그 부분은 과거 계산식과 맞지 않아 졌다는 것이다.
2. 기간의 의미
1번의 예시처럼 “오프라인 절차를 온라인으로 처리” 하는 부분의 개발 기간을 생각해 보자.
물론 기획하고, 디자인하고 개발한 부분을 요구사항을 제시한 고객과 끊임없이 검토받고, 결정하고 하는 부분에서 가장 많은 시간이 소요될 것이다.
그런데 극단적인 예를 들어보겠다. 디자인과 퍼블리싱이 완료되었는데, 고객이 추가로 화면을 요청하거나 디자인을 통째로 갈아엎도록 요구했다고 보자. 실제 투입된 인력은 최소 다시 작업하는데 1~2일이 필요할 것이다.
보통 일반회사는 9시에서 18시까지 근무한다. 9시에 출근해서, 커피 한잔 타마시고, 정리하고 어제 했던 일도 체크하고 사람들과 인사도 좀 나누고 화장실도 좀 가고,, 요즘 트렌드에 맞게 11시 반에 밥을 먹으러 간다면 오전에 집중해서 일할 수 있는 시간은 정말 고작해야 2시간이 되지 않을 때가 많다.
오후라고 다를까? 13시부터 업무를 시작하면 18시까지 5시간이다. 최대한 집중을 해도 3시간 정도가 평균이라 생각한다. 결국 하루 8시간 일을 한다면 최대 집중해서 업무를 보는 시간은 4~5시간 정도가 아닐까 생각한다. 물론 사람마다 상황마다 다르다 평균 5시간이라고 하면 사장님들이 아마 극대노 하실 것이다.
여기서 내가 하고 싶은 이야기는 사람은 일을 하는데 필요한 소모시간이 있다는 것이다. AI는 그런 시간이 없다. 손도 빠른 녀석이 쉬지도 않는다는 것이다. 하루요, 이틀이요가 이제 5분이요 10분 이요가 되는 것이다.
보통 SI라고 말하는 시스템 통합사업에서 신규 구축이라고 해서, 6개월짜리 프로젝트가 나온다고 보자. 그럼 보통 1~2개월을 분석/설계 그리고 2~3개월을 개발 그리고 남은 1~2개월을 테스트와 안정화로 잡는다.
그런데 지금 같은 수준이면, 개발기간은 2~3주로 잡고, 기획이나 분석설계도 충분히 당길 수 있다는 것이다.
6개월짜리 프로젝트는 3개월 내로 종료될 수 있다. 그럼 뭐가 문제냐? SI 업체는 인건비로 수익이 생긴다.
1명을 한 달 투입하는 것을 1M/M라고 한다. Man-Month 1명이 1개월 동안 투입된다. 0.5M/M 한 명이 반달 즉 2주간 투입된다. 뭐 이런 식인데 이젠 사람이 아니라, 사람 + AI 구독 또는 토근사용량을 계산해서 사업비가 측정될 판국이다.
3. 코드 리뷰? 코드 수정?
심각한 문제라 생각하는데, 우선 시니어 적어도 10년 이상 개발을 하신 분들이라면 그래도 감은 잡을 수 있다. 문제가 생겼다. 그리고 AI가 수정을 했다. 바로 코드를 건드리기 전에 어떤 부분이 수정될지 확인하거나 요구사항을 명확하게 프롬프팅 할 수 있다. 그런데 신입의 경우는 얘기가 다르다. 한 번은 이랬다. 어떤 기능을 추가해서, 수정배포를 했는데 기능이 정상동작하지 않았다. 그래서 해당 코드를 적용한 개발자(신입)에게 원인을 파악시켰다. 그리고 수정을 요청했다. 그 친구의 대답은 ‘AI 가 코딩한 거라서, 어디가 문제인지 정확하게는 자기도 모른다. AI에게 물어봐야 한다.’ 로그를 확인한 내가 ‘이런 부분이 이슈인 것 같다’라고 답을 하자 그래도 ‘AI 가 코딩한 거라서 자기가 건드리기가 어렵다’라는 것이다. AI를 도구로 사용하는 개념이 아니라 그냥 다 맡겨버리는 상황이 발생하는 것이다. 사실문제가 되는 수준을 아닐 것이다. 실제로 문제가 발생하는 횟수보다는 효율성이 훨씬 높기 때문에 그렇다고 사용하지 않을 수가 없다. 다만 과거처럼 코드를 깊이 있게 이해할 수 있을 것인가? 하는 의문은 든다. 또 하지만 한편으로 이제 그런 것이 필요한가?라는 의문도 드는 것이다.
4. Yes!
가장 중요한 부분이다. 토를 달지 않는 “Yes” 만약 협업을 해 본 사람이면, 개발자 벽을 한 번이라도 느껴본 사람이라면, 디자이너의 벽을 한 번이라도 느껴본 사람이라면 공감할 것이다. 수정을 요청할 때의 어려움을.. 편의를 위한 기능을 요청했을 때 설득의 어려움을.. AI는 토를 달지 않는다. 그 기능이 왜 필요한지 묻지 않는다. 그리고 그 부분을 개발하는데 소요되는 시간을 걱정하지 않는다. 기획자 입장에서 더 좋은 서비스를 그리고 더 편리한 기능을 제공하는데 굳이 내 고집을 강요하는 사람이 될 필요가 없다. 필요하면 적용하는 방법을 작성해서 주거나, 직접 적용해도 상관없다. 개발자 역시 AI가 개발을 하고 있기 때문에 자잘한 나의 요구사항을 들어주는데 유(柔)해진 것이다. 커뮤니케이션을 담당하는 사람으로 이 부분은 정말 엄청나게 큰 부분이다.
우선 4가지만 정리해 보겠다. 할 수만 있다면 100가지도 내일모레글피까지도 글을 쓸 수 있다. 물론 그것도 AI한테 시켜서.. 급변하는 업무환경에서 아직은 잘 적응한다 생각하지만, 아직 내 우물은 느리게 가는 편이다. 실제 우물 밖은 어떤 환경이 기다리고 있을지 모른다는 것이다.
지극히 개인적인 그리고 현재 내가 처한 상황에서의 AI에 대한 생각을 적어봤다.
다음엔 이 현실이 나에게 주는 불안감에 대한 이야기를 써보고 싶다.
다음에…