조금 늦게 AI를 따라가는 회사와 사람들에게

김수보

10분

2025.10.01.

어떻게 일해야 할까?

챗GPT는 “인공지능”이다. “세상의 모든 것”을 아는 “척척박사”다. 생각보다 많은 일을 할 줄 안다. 그리고 잘한다.

하지만, 이런 위대함은 일단 뒤로 미뤄두자. 모든 가능성을 열어두면 현실 프로젝트가 진행되지 않는다. 지금은 일을 해야 할 때다. 중요한 사항 몇 가지를 짚어 보면 이렇다.

(1) 챗GPT은 결정을 하지 않는다.

챗GPT 에게는 의지가 없다. 책임질 처자식이 없으니 호구지책으로 일하지 않는다. 사장님께 잘 보일 필요도 없으니 회사 우선주의로 일하지도 않는다. 그냥 시킨 일을 잘할 뿐이다.

그러니 결정은 의지를 가진 사람의 몫으로 하자. 성능 목표, 설계 방향, 기능 콘셉 등 그런 건 사람이 정해야 한다.

그러면 과거와 똑같은 식으로 프로젝트가 진행되는 거 아닌가?

맞다. 하지만, 일단은 그렇게 시작하자. 너무 멀리 생각하면 아무것도 시작할 수 없다.

일단 옛날처럼 설계하고, 옛날처럼 기능목록을 잡자. 대신 그 일을 잘하기 위해 AI를 쓰자. 별것 아닌 것까지 물어보고 별것 아닌 것까지 설계하자.

결정은 반드시 베테랑 설계자가 하자. 좋은 걸 알아보고 선택하는 건 역시 사람의 몫이다. 경험자가 아니면 뭐가 뭔지 알 수 없기 때문이다.

(2) 챗GPT는 만능 조수다.

“조수, 이렇게 만들어 와!”

“조수, 이렇게 고쳐와!”

이렇게 명령하자.

이 조수는 세상의 모든 것을 알고 있는 “척척박사”다. 똑똑하게 코드를 만들어 오는 훌륭한 개발자이기도 하다. 친절하고 자세하게 지시할수록 일을 잘할 확률이 높다.

대답이 마음에 안 들 때도 있다. 그건 내가 잘못한 거다. AI는 컴퓨터다. 시키는 대로 한다. AI가 잘못했다면 그건 사람이 잘못시킨 거다.

(3) “아키텍처”도 물어보자

챗GPT는 훌륭한 소프트웨어 설계자이기도 하다. “설계”를 아주 잘한다.

무엇보다 쪽팔릴 걱정이 없으니 자세하게 물어보자. 유치하더라도 자세하게 물어보면 좋은 대답을 해준다. 물론 정답을 알아보는 건 자기가 해야 한다.

횡설수설해서 이해가 안 될 때도 있다. 예제 코드를 내놓으라고 하자. 설명해달라고 하자.

잘 모르겠다면 이렇게 이야기하자.

“이렇게 저렇게 자세히 알려줘.” 무엇을 듣고 싶은지 설명해 줘야 그렇게 대답해 준다.

아키텍처가 복잡하다면 작게 나누어서 물어보자. 그 다음 몇개를 묶어서도 물어보자. 그렇게 “아키텍처”를 설계해 보자.

알아야 할 게 있다.

요즘 챗GPT를 두고 많은 사람이 “자비스”*라고 착각한다. 그렇지 않다. 지금의 “인공지능”은 솜씨 좋은 이야기꾼일 뿐이다. “챗GPT”는 정답을 만들어주지 않는다. 정답은 사람이 만들어야 한다.

*자비스 : 영화 “아이언맨”에 등장하는 인공지능 비서.

AI를 잘 사용하는 설계자는, 내가 잘 설계할 수 있도록 AI를 활용하고 이용하는 사람이다.

설계안을 등록한 후 보완할 점을 찾아달라고 해보자. 필요한 부분을 디버깅해달라고 해보자. AI가 보완해야 할 것이라며 내놓은 대답이 쓸모 없거나 잘못된 대답을 한다면, 내 설계안이 완벽했다는 뜻이 된다.

(4) 반드시 검증해야 한다.

“개발 언어”는 논리적이고 규칙적이다. 게다가 lint 같은 탐지 도구도 있다. 그래서 거짓말 탐지가 쉽다. 그렇기에 AI에 모든 상황과 코드를 컨텍스트로 등록할 수 있다면, 매우 높은 완성도의 결과물을 받아 볼 수 있다.

하지만, 토큰* 소모량이 커서 언제나 그렇게 일하긴 어렵다. 필요한 부분만 잘 요약해서 물어봐야 한다. 하지만, 보통 사람들은 잘 요약하는 능력이 부족하다. AI가 알아듣지 못하게 지시했을 확률이 높다.

결과물이 잘못될 확률도 높아진다. 그래서 내가 제대로 물었는지, 챗GPT가 제대로 대답했는지 꼭 확인해야 한다.

*토큰(Token) : LLM에 묻고 들을 때 기본이 되는 입출력 단위. 기술적으로는 다르지만, “낱말” 정도로 이해하자.

어떻게 확인할까?

우선 결과 코드를 찬찬히 읽어보자. 이해하기 어렵다면 이렇게 물어보자. “이건 왜 이렇게 짠 거야?”

AI가 상세하게 설명해 줄 거다. 잘 읽어보고 정말 그런지 검토해 보면 된다. 잘 모르겠다면 구글링을 한다. AI 검색에 의존하지 말고, 원문을 읽어보자.

중요한 건 “내가 읽어보고 이해하는 것”이다.

AI가 만든 코드 중에 내가 모르는 건 없어야 한다. 그래야 전체가 망가지지 않는다. AI는 거짓말을 한다. 교묘하게 섞여 있다. 검증하지 않았다면 항상 거짓말이 있다고 생각하자.

(5) 자질구레한 정리는 직접 해야 한다.

AI에게는 약점이 있다.

톡톡 튀는 감성과 엣지(Edge)가 없다. 그건 내가 만들어야 한다.

까칠한 눈높이와 성깔도 없다. 그것도 까칠한 내가 가지고 있어야 한다.

내 맘에 쏙 드는 디테일이 없다. 역시 꼼꼼한 내가 만들어야 한다.

디자인 레이아웃, 마진(Margin), 라인 색상(Line Color), 폰트(Font) 등은 내가 결정하자. 로그 포맷(Log format) 같은 것도 내가 결정하자. 추천을 몇 개 받은 다음 결정하면 된다.

사람의 마음속으로 들어가는 건 AI가 해주지 않는다. AI는 내가 시킨 걸 한다. 내 느낌을 따라 AI에게 물어보자. 결정은 내가 해야 한다.

무엇이 바뀌었을까?

정리해 보자. 그래서 뭐가 변한 걸까?

첫째, 새로운 영역에 대한 진입이 쉬워졌다.

옛날엔 모르는 분야는 시작할 수조차 없었다. 뭔가를 하려면 제일 먼저 “아는 사람”을 찾아야 했다. 정보를 듣고 도움을 받아야 했다.

이제는 챗GPT가 있다. node.js를 몰라도 node.js로 개발할 수 있다. “python으로 짠 걸 node.js로 바꿔줘.” 차라락 짜준다. 잘 짜려면 시간이 필요하지만, 입문은 비교할 수 없이 빨라졌다.

‘찍먹’을 쉽게 해 볼 수 있게 되었다는 뜻이다. 대신 그 변화를 잘 이해하고 활용할 수 있어야 한다. 그것만으로 많은 변화가 생긴다.

둘째, 업무 사이클이 빨라졌다.

옛날엔 기능 하나 만들려면 일주일이 걸렸다. 지금은 하루 만에 만들 수 있다. 빨라진 건 확실하다. 시간을 벌었다. 이젠 그 시간을 어떻게 사용할지 고민만 하면 된다. 특히, 시간을 번다는 건 기업활동에 있어 굉장히 큰 기회 자산이다. 잘 활용할 수 있어야 한다.

셋째, 제품 개발 속도가 빨라졌다.

옛날엔 개발 기간이 길다 보니 계획 단계에 충분한 시간을 주기 어려웠다. 이젠 충분한 시간을 줄 수 있게 되었다. 개발 속도가 빨라졌기 때문이다. 제품 구상에 더 많은 시간을 쏟을 수 있게 되었다.

그런데 이건 훈련이 필요하다. 개발자들은 대부분 How에 대해선 능숙하다. 반면 What에 대해선 서투르다. 이젠 What을 생각해야 한다. 어떤 제품을 만들지 고민하고 결정해야 한다. “결정”도 해 본 사람이 더 잘한다.

앱도 좋고, 서비스도 좋다. SDK나 라이브러리일 수도 있다. 쓸데없는 상상도 하고 부족하더라도 제품을 만들어 보자. 그래야 훈련이 된다. 만들고 부시기를 반복해 봐야 제작 시간도 빨라지고 완성도도 올라간다.

잊지 말아야 할 게 있다.

챗GPT에 일을 시키는 게 아니다. 챗GPT를 이용해서 나를 강화시키는 거다. 반복된 훈련을 통해, 나와 팀을 업그레이드시키는 거다. 훈련 목표는 AI를 써서 좋은 결과물을 빨리 만들어 내는 것이다.

무엇이 안 바뀌었을까?

제품을 만들어야 돈을 번다는 사실은 안 바뀌었다. 제품이란 효용가치를 제공하는 기능 뭉치를 말한다. 효용가치는 사람인 고객이 느껴야 한다. 그래야 돈을 내기 때문이다.

“사람들은 왜 내 제품을 사는가?”

“그것을 어떻게 만들 것인가?”

이 두 가지 회사의 고민은 영원히 변하지 않는다. AI는 이 일에 도움이 되어야 한다.

업무는 여전히 사람이 해야한다. AI 성능이 모자라서가 아니다. 업무는 “기능”이 아니기 때문이다.

책임은 AI가 아니라 사람이 져야 한다. 그래야 고쳐서 더 좋게 만들 수 있기 때문이다.

AI는 직원을 강화시키는 도구이지, 직원을 대신하는 도구가 아니다.

기업이 직원을 해고하게 만드는 건, AI가 아니라 AI로 강화된 다른 직원들이다.

회사의 변화

물론 어떤 회사는 AI에 잘 대응한다. 하지만, 대부분의 회사는 그렇지 않다. 왜 그럴까?

변화의 기준을 팀과 조직이 아니라 개인으로 바라보기 때문이다.

예를 들어보자.

AI 덕분에 혼자서 많은 일을 할 수 있게 되었다. 그래서 신입사원을 뽑지 않는다. 시니어가 대신 그 일을 한다. 하지만, 신입사원이 해야 할 일이 없어진 건 아니다. 업무량은 그대로다. 그래서 전체 시간은 줄지 않는다.

어떻게 되었을까? 인건비는 줄었다. 하지만, 직원들은 바쁘니까 혁신적인 무언가를 만들어내지 않는다. 혼자 해결할 일이 많아져서 주어진 일만 하기에도 벅차다.

분명 개인의 생산성은 좋아졌다. 하지만, 회사의 생산성은 그대로다. 효율은 올랐지만 효과는 안 오른 거다. AI를 써서 2배로 일하는 개발자를 갖게 되었지만 회사가 좋아진 건 없다.

새로운 제품과 고객이 없다면 성장은 없다. 회사는 이제 이 문제를 고민해야 한다.

높아진 생산 효율을 비용 절감보다 효과 창출에 써야 한다. 회사는 이런 질문을 던져봐야 한다.

“AI를 쓰는 개발팀은 무엇을 할 수 있을까?”

“AI를 쓰면 고객은 무엇이 더 좋아질까?”

SI 현장 이야기

큰 SI 프로젝트들이 애매해졌다. 기술 변화가 빨라서 큰돈 들이기 부담스럽기 때문이다. 대신 레거시 시스템을 고쳐쓰기 좋아졌다. AI가 복잡한 분석을 잘해주기 때문이다.

웹 포털, 은행 상품 추천 등 정보가 공개되어도 괜찮은 곳은 AI를 적극 활용한다. 하지만, 기업 보안이 중요한 곳은 AI를 쓰지 않는다. 따로 구축한 “보안이 좋은 AI”는 대답이 시원찮다. 학습량이 낮기 때문이다. 그래서 기업 침투가 더디다.

그럼 AI 제품을 SI로 만들어보면 어떨까? 그런데 AI는 남의 손을 빌려 만들기 애매한 기능이다. 정제된 학습 데이터가 필요하고, 많이 필요하기 때문이다. “공개 데이터”로 만든 건 경쟁력이 낮다. “비공개 데이터”는 민감하다. 특히 개인정보가 포함되었다면 아웃소싱 업체에 맡기기 어렵다.

그리고 AI 제품은 디테일이 높아야 좋다. 하지만, 아웃소싱 업체는 디테일을 높이기 힘들다. 업무 당사자가 아니어서 불편을 모른다. 고객 데이터를 가지고 놀아볼 수 없다. 뭘 개선해야 할지 뽑아낼 수 없다. 즉, 아웃소싱이 많이 필요한 대형 프로젝트들은 한동안 혼란스러울 것 같다.

반면, 작은 프로젝트들은 많이 생기고 있다. 사이즈가 작아 만들기 쉽고, AI 덕분에 비용이 적어지고 기간이 짧아졌다. “작은 제품 만들기” 시장은 활황이다.

프로젝트 관리는 애매해졌다. AI가 좋은 건 확실한데 세밀한 효용은 예측할 수 없기 때문이다. 예측하기 어렵고 통제 불가능한 리소스는 운영하기는 어렵다.

3개월짜리 일을 “AI 써서 1개월 안에 하겠다”. 이렇게 계약서를 쓸 회사가 있을까? “납기지연”, “지체상금” 등 제약조건이 걸린다면 더 더욱 찾기 힘들다.

그래서 “SI 수행 기간 줄이기”는 한동안 힘들 것 같다.

지금 당장은 LLM을 개발자와 기획자를 도와주는 코파일럿, 딱 그 정도의 역할로만 쓰자. 커서(Cursor), 깃헙 코파일럿(Github Copilot)도 열심히 쓰자. 우선 그렇게 시작하자. 그렇게 시작하면 회사가 어떻게 일해야 할지 보인다. 당사자라서 보일 수밖에 없다. 안 그러면 답답하니까. 그렇게 현장을 진화시키자.

어떤 “갑”은 AI를 적용해서 현장을 바꾸고 있다. 생산 공장에 AI를 넣었다고도 한다. 음, 중견기업들은 부러울 수 있다.

그런데 이걸 중견기업이 아웃소싱으로 구축할 수 있을까? 어렵다. 어떤 곳에 AI를 써야 할지는 외부 업체들이 알 수 없다. 현장을 모르기 때문이다.

유명 업체로부터 AI 구축 컨설팅을 받을 수도 있다. 하지만, 아직 시장 사례가 많지 않다.

지금 현장은 직원들이 직접 AI를 써보고 개선점을 찾아내야 하는 탐색 단계에 있다.

직접 “요구사항”을 만들고, 상세하게 검수할 수 있는 수준이 되면 “AI 프로젝트”도 쉽게 아웃소싱할 수 있다.

어중간하게 써보도록 하지 말고 적극적으로 써보게 하자. “AI를 이용한 프로세스”도 만들고, “AI를 활용한 업무처리 원칙”도 만들게 하자. 업무를 리뷰하고 결과물을 어떻게 관리할지도 방침을 만들자.

예를 들어, AI를 쓰면 업무처리량이 늘어난다. 하지만 늘어난 결과물을 어떻게 관리할지는 노하우가 없다. 개발팀 인원은 줄지만 운영팀 인원이 늘 수도 있다. 회사는 이 변화에 대응할 수 있어야 한다.

직원들이 “챗GPT 를 쓴다는 사실”에 매몰되면 안 된다. 그 변화를 통해 무얼 할 수 있는지를 고민하고 결정해야 한다. 개발 자동화는 아주 작은 변화다. 그건 개발자만 변하면 된다. 개발팀이 변하는 건 큰 변화다. 이건 회사가 변해야 한다.

회사가 집중해야 할 것

회사의 정체성은 “돈을 번다”는 거다. 아마 영원히 바뀌지 않을 거 같다. 효용가치가 필요하다. 이건 제품마다 다르다.

냉장고를 만드는 기업이라면 식품의 보관 원리를 더 잘 이해할 수 있도록 해보자. 냉동실로 가야 할 제품이 냉장실로 왔다면 알람으로 알려주자. 3일 이내에 먹지 않으면 썩는다고 알려주자. 오래된 우유가 있다면 버리라고 해주자.

에어컨을 만드는 기업이라면 집안의 공기질을 관리하게 해보자. 고등어를 굽고 있을 때 주방 환기구를 자동으로 켜게 하자. 가스가 새고 있다면 음성으로 위험을 알려주고 대응 요령까지 말해주자.

제품으로서의 AI는 챗GPT와 같지 않다. 인풋(Input)되는 데이터의 질, 내용, 양에 따라 완전히 다른 제품이 된다. “데이터”는 AI 제품의 원료다. 클린할수록 AI의 질이 올라간다. AI기술을 가진 회사는 이런 데이터를 지속적으로 수집하고 관리할 수 있어야 한다.

SI 기업은 이런 데이터를 지속적으로 수집할 수 있을까? 단순 인력 파견 기업에게는 불가능한 일이다. 특정분야의 전문기업이라면 가능하다. 우리 고객에 맞춰 미리 데이터를 수집, 분석, 가공해볼 수 있다. 이걸 준비하고 훈련해보자. AI 학습을 위한 데이터 삽질 경험이 AI 기술력이다.

요즘 커서(Cursor), 클로드 코드(Claude Code) 같은 코드 개발 도구 시장이 핫하다. 개발자가 필요 없다고도 말한다. 무엇을 의미할까? 그동안 개발이 느리고 비쌌다는 뜻이다. 따라서 인건비 중심의 SI 사업은 이제 먹고 살기 힘들어진다.

AI 가 촉발한 시장은 “퍼스트 무버(First Mover)”들의 시장이다. 앞서가지 않으면 도태된다.

하지만, SI 시장은 “패스트 팔로워(Fast Follower)”들이 찾는 시장이다. 빨라(Fast)지는 것만으로 살아남을 수 있다.

시간이 지나면 아웃소싱 시장도 다시 좋아질거다. 공공 부분은 여전히 “조달”을 할 수 밖에 없기 때문이다. 하지만, 시장 상황은 완전히 바뀔 거다. AI가 고객의 시간과 비용을 줄여주기 때문이다.

좋은 개발팀이 있다면 프로젝트 비용을 낮게 부를 수도 있다. 혹은 더 짧은 기간을 제시할 수도 있다. 반면, 인건비는 높아질거다. AI를 잘 쓰려면 훈련이 필요하고, 훈련된 개발자는 부족하기 때문이다.

개발팀의 퍼포먼스가 좋아지도록 AI 훈련을 잘 시켜 놓자. 프로젝트 기간을 줄이기 위해 풍부한 부품군을 미리 준비하는 것도 좋다. 이게 SI기업들의 경쟁력이 될 거다.

정리해 보면 이렇다.

경쟁구도의 핵심은 “우리 회사” vs “AI”가 아니다. “AI를 쓰는 회사” vs “AI를 쓰지 않는 회사”간의 싸움이다. “AI가 못하는 걸 우리 회사”가 할 수 있다”라는 것에 초점을 맞추면 안된다. AI를 쓰지 않으면, AI를 쓰는 회사에 의해 대체된다. 훨씬 더 빠르고 가볍게 움직이기 때문이다.

아직 시장에선 퍼스트 무버(First Mover)들도 헤매고 있다. 그래서 시간이 조금 더 있다.

새롭게 만들어질 시장을 잘 고민해 보자. 시장을 잘 따라가야 생존할 수 있다.