실전 에세이3min read

"우리는 IT 기업이에요" — 개발자가 한 명도 없는데

AI 덕분에 개발자 없이도 결과물이 나옵니다. 그래서 IT 기업을 자처하기가 쉬워졌습니다. 하지만 만드는 것과 지키는 것은 다른 문제입니다.

"우리는 IT 기업이에요" — 개발자가 한 명도 없는데

결과물은 나왔지만 그것을 지킬 사람이 없는 상황을 보여주는 일러스트

"저희는 IT 기업입니다."

이 말을 하는 회사에 개발자가 한 명도 없는 경우를 여러 번 봤습니다. 예전에는 이게 좀 민망한 상황이었습니다. 서비스는 외주로 만들었고, 그 뒤로는 아무도 손을 못 대는 상태였으니까요.

그런데 요즘은 상황이 달라졌습니다. 개발자가 없어도 결과물이 나옵니다. AI에게 시키면 화면이 뜨고 기능이 돕니다. 그래서 이제 이 말은 민망한 게 아니라 꽤 그럴듯하게 들립니다.

문제는, 결과물이 나온다는 것과 그걸 지킬 수 있다는 게 다른 이야기라는 점입니다.

만드는 것과 지키는 것은 다른 일입니다

만드는 건 한 번입니다. 지키는 건 계속입니다.

  • 장애가 났을 때. 새벽에 결제가 안 된다는 연락이 옵니다. 원인을 찾아야 하는데, 그 코드를 이해하는 사람이 회사에 없습니다. AI에게 물어볼 수는 있지만, AI는 "지금 우리 서비스가 실제로 어떤 상태인지"를 모릅니다. 화면 캡처만 보고 원인을 맞히는 건 사람이든 AI든 어렵습니다.
  • 6개월 뒤 고쳐야 할 때. 만들 때는 빨랐는데, 왜 그렇게 만들었는지 아무도 모릅니다. 손대면 다른 데가 깨질 것 같아서 결국 손을 못 댑니다. 그래서 기능 하나 바꾸는 데 처음 만들 때보다 오래 걸립니다.
  • 사고가 났을 때. 회원 정보가 새거나, 결제가 이중으로 되거나. 이건 "고치면 되는" 문제가 아니라 책임의 문제입니다. 무엇이 어디까지 새어나갔는지 판단할 사람이 필요합니다.

이 셋의 공통점이 있습니다. 전부 만든 다음에 벌어지고, 전부 판단이 필요합니다. AI가 코드를 잘 짜주는 것과는 다른 능력입니다.

"만들 수 있다"가 "안다"는 뜻은 아닙니다

AI 시대에 생긴 가장 흔한 착각이 이겁니다. 결과물이 나왔으니 이해한 것 같은 느낌이 듭니다. 하지만 나온 것과 아는 것은 다릅니다.

솔직히 말하면 이건 개발자에게도 해당됩니다. AI가 짜준 코드를 제대로 안 읽고 넘어가면, 저도 6개월 뒤에 똑같이 헤맵니다. 차이는 제가 그걸 읽을 수 있다는 것뿐입니다. 읽을 수 있는 사람이 회사에 아예 없는 것과, 읽을 수 있는데 안 읽는 것은 위험의 크기가 다릅니다.

그래서 "우리는 IT 기업"이라고 말할 때 진짜 기준은 개발자 채용 여부가 아니라 이겁니다. 문제가 생겼을 때 판단할 수 있는 사람이 어딘가에 있는가.

그렇다고 개발자를 뽑으라는 말은 아닙니다

1인 사업자나 직원 몇 명인 회사에 "개발자를 채용하세요"는 현실성이 없습니다. 연봉도 문제지만, 뽑아놓고 시킬 일이 상시로 있지도 않습니다. 그래서 이 조언은 대부분 무시되고, 무시되는 게 합리적입니다.

제가 생각하는 답은 다릅니다. 기술 판단은 살 수 있습니다. 상시 고용이 아니라, 판단이 필요한 지점에서만 제대로 된 사람에게 묻는 겁니다. 실제로 판단이 필요한 순간은 그렇게 많지 않습니다.

  • 만들기 전 — 이 구조로 가면 나중에 뭐가 막히는지
  • 받을 때 — 이게 정말 돌아가는 건지, 데모만 되는 건지
  • 사고 났을 때 — 어디까지 문제인지

이 세 지점만 제대로 통과하면 나머지는 굳이 개발자가 필요 없습니다. 반대로 이 세 지점을 아무도 안 보면, 개발자가 열 명 있어도 같은 사고가 납니다.


개발자가 없는 회사가 IT 기업을 자처하는 게 잘못은 아닙니다. 지금은 정말로 만들 수 있으니까요.

다만 만든 다음이 훨씬 깁니다. 그 긴 구간에 판단할 사람이 아무도 없다면, 그건 IT 기업이 아니라 운이 좋기를 바라는 상태입니다.

혼자 회사를 굴리고 계신다면 mvpit.dev에서 편하게 이야기 나눠보고 싶습니다.

기술 역량AI 코딩1인 사업자회사 운영외주개발

새 글 알림 받기

새로운 블로그 글이 발행되면 이메일로 알려드립니다.