요즘IT » IT서비스 » 피드

누구도 알려주지 않는 AWS 보안의 첫 번째 원칙

이 글은 위시켓과 함께 요즘IT 브랜디드 콘텐츠로 제작했습니다.

흠뻑 젖은 채로 리조트 방 앞에 서서야 깨달았습니다. “아, 방에서 키 안 가지고 나왔다….” 수영장에 다녀오며 카드키를 방에서 안 가지고 나왔던 겁니다. 결국 수영복 차림으로 떨며, 멀리 떨어진 프론트 데스크까지 걸어가서 새 키를 받으러 갔습니다. 지난 겨울 휴가 때 제 이야기입니다.

호텔이나 리조트에 놀러 다니다 보면 쉽게 이런 상황을 마주하기도 합니다. 평소 결제와 신분증 확인을 모두 휴대폰으로 해결하다 보니, 지갑 없이 폰 하나로 다니는 데 익숙하기 때문입니다. 호텔 카드키를 따로 챙기는 일은 꽤 번거롭게 느껴졌고, 때로는 방에 두고 나오거나 심지어 밖에서 잃어버리고 오는 일도 있었습니다.

밖에서 놀다가 호텔 키를 잃어버리면 어떻게 될까요? 카드키를 받을 때는 호텔 측에서 작은 종이 케이스에 방 번호를 적어 주기도 하는데요, 이 경우 누구나 제 호텔 방에 들어올 수 있게 됩니다. 만약 그 열쇠를 잃어버린 사실조차 모른 채 방을 방치해 둔다면 어떨까요? 방에 있던 짐은 그대로 도난당하고, 파손된 가구나 전자제품에 대해 호텔 측에 변상해야 할 수도 있습니다.

<출처: 작가, Gemini로 제작>

그런데 만약 잃어버린 것이 호텔 키가 아니라 개인이나 회사의 클라우드 인프라 열쇠였다면 어떨까요? 마찬가지로 누군가 내 클라우드 계정에 접근해 고객들의 개인정보를 탈취하고, 심지어 서비스까지 중단시킬 수도 있습니다. 실제로 2014년, 한 기업은 클라우드 열쇠를 탈취당해 모든 데이터와 백업이 삭제되었고, 회사는 영구 폐업했다고 합니다.

위시켓 클라우드팀에서 업무상 수많은 AWS 계정을 관리하는 제게, 이러한 사건은 남의 이야기가 아닙니다. 그런 경험을 바탕으로 클라우드 보안에서 가장 흔하면서도 가장 위험한 실수 하나에 관해 설명해 보려고 합니다.

클라우드의 두 가지 자격 증명

요즘 메리어트나 IHG 같은 호텔 체인에서는 모바일 키를 지원합니다. 이런 모바일 키가 있었다면 카드키를 두고 나와도 당황하는 일은 없었을 것입니다. 또, 카드키를 잃어버리더라도 제 얼굴 인증 없이는 모바일 키를 사용할 수 없을 겁니다. (실제로 메리어트 본보이 앱은 모바일 카드키 사용 시 페이스 아이디를 요구합니다.)

클라우드에서도 이처럼 전통적인 키와 모바일 키처럼 두 가지 인증 방식이 존재합니다.

첫 번째 증명: 카드 키 방식

우리는 호텔에 도착하면 보통 프론트 데스크에서 카드키를 받습니다. 서울의 호텔, 도쿄의 호텔, 뉴욕의 호텔 모두 호텔마다 프론트에서 각각 다른 카드키를 받아야 합니다. 만약 잃어버린다면 어떨까요? 누군가 주워 제 방에 들어갈 수도 있습니다.

AWS의 인증 열쇠를 잃어버리면, 호텔 열쇠와는 비교할 수 없을 만큼 심각한 문제가 발생할 수 있습니다. 특히, 호텔의 카드키는 최소한 체크아웃 날짜가 지나면 만료됩니다. (그래서 일부 호텔에서는 카드키를 기념으로 가져가게 해주기도 합니다.) 반면 AWS의 장기 자격 증명인 IAM 접근 키는 마치 쇠로 된 열쇠와 같습니다. 누군가 직접 문에 달린 자물쇠를 바꾸지 않는 한 꾸준히 작동합니다. 게다가 쇠 열쇠보다 복제하기도 쉽습니다. 두 줄의 문자열을 복사해 붙여넣기만 하면 되기 때문입니다.

두 번째 증명: 모바일 키 방식

반면 모바일 키는 조금 다릅니다. 예를 들어 메리어트 호텔의 모바일 키는 본사에서 중앙 관리됩니다. 하나의 메리어트 계정만 있으면 호텔 지점과 관계없이 어디서든 체크인하고 모바일 키로 객실 문을 열 수 있도록요. 심지어 동시에 예약한 호텔이 두 곳이라면, 하나의 휴대폰으로 두 객실을 모두 열 수도 있습니다. 또, 제 휴대폰이기 때문에 얼굴과 같은 생체 정보 없이는 사용할 수 없습니다. 여기에 체크아웃 이후에는 별도의 관리가 필요하지 않습니다.

AWS에서도 마찬가지입니다. 저는 하루에도 여러 번 AWS 계정을 오가며 작업하는데, 로그인할 때마다 각 계정의 아이디와 비밀번호를 모두 알아야 한다면 매우 번거로운 일이 될 것입니다. 그래서 모바일 키 방식을 적극 사용합니다.

장기 기억 증명 vs. 단기 자격 증명

AWS에서는 이 두 가지를 다음과 같이 구분합니다. 카드키, 마치 호텔의 쇠 열쇠 같은 방식은 장기 자격 증명(long-term credential)이라고 부릅니다. 반면 모바일 키와 같은 방식은 단기 자격 증명(short-term credential)이라고 합니다. 한 번 만들어지면 열쇠구멍이 바뀌지 않는 한 쓸 수 있는 쇠 열쇠와 달리, 모바일 키는 사용할 때마다 제 생체 인증이 필요하기 때문입니다.

장기 자격 증명의 대표적인 예는 AWS IAM(Identity and Access Management)의 접근 키(Access Key)입니다. 이 접근 키는 두 줄의 문자열로 이루어져 있습니다. 한 번 생성되면 그 자체로는 만료되지 않는 특징도 가집니다. 또한 문자열 형태이기 때문에 누구에게나 복사해 전달할 수 있습니다. 카카오톡으로 주고받거나, 코드에 들어간 채 클라우드나 깃허브와 같은 원격 저장소에 업로드될 수도 있습니다. 이처럼 발급된 키를 삭제하려면 해당 계정에서 직접 삭제해야 합니다. 호텔마다 프론트 데스크에서 카드키를 따로 발급하듯, 각 AWS 계정에서 개별적으로 생성하고 관리합니다.

반면 단기 자격 증명은 IAM 자격 증명 센터(IAM Identity Center)를 통해 발급됩니다. 호텔 체인 본사가 앱을 통해 키를 관리하듯, AWS 조직(AWS Organization, 여러 계정을 하나로 묶어 관리하는 단위)의 관리 계정에서 중앙으로 관리됩니다. 하나의 사용자로 여러 AWS 계정에 접근할 수 있다는 점도 특징입니다. 로그인할 때는 다단계 인증(Multi-Factor Authentication, MFA)을 거쳐야 하며, 인증이 완료되면 임시 토큰이 발급됩니다. 이 토큰은 사전에 설정된 일정 시간이 지나면 만료되고, 로그인할 때마다 새로 발급됩니다. 만료 이후에는 별도로 신경 쓸 필요가 없습니다. 알아서 사라지니까요.

<출처: 작가, Claude로 제작>

<출처: 작가>

AWS 접근 키를 잃어버리면, 어떤 사고가 날까요?

AWS 접근 키를 잃어버리면 어떻게 될까요?

이 열쇠에는 만료일이 없고, 복제도 매우 쉽습니다. 사실 키 값이 그리 길지도 않아 마음만 먹으면 외울 수도 있는 수준입니다. 누가 복사했는지, 복사본이 몇 개나 존재하는지도 알 수 없습니다. 누군가 자물쇠를 바꾸기 전까지 그 열쇠의 복사본을 가진 누구든 언제든 문을 열 수 있습니다.

키 유출이 악용으로 이어진 시간

이에 대한 실험이 있습니다. 보안 연구팀 Comparitech는 AWS 자격 증명을 공개 깃허브 리포지토리에 일부러 올려두었습니다. 결과는 충격적이었습니다. 첫 번째 악용이 1분 이내에 발생했습니다. 1분입니다. 음료수 한 모금 마시기도 전에, 누군가 그 열쇠로 문을 열고 들어온 셈입니다.

이건 우연이 아닙니다. 팔로알토 네트워크의 Unit 42 팀이 추적한 EleKtra-Leak 캠페인에 따르면, 공격자들은 깃허브에 노출된 AWS 자격 증명을 자동으로 스캔하고 있었습니다. 키가 노출되면 평균 5분 이내에 악용이 시작됐고, 탈취한 키로 수백 대의 EC2 인스턴스를 생성해 암호화폐를 채굴했습니다. 이 캠페인은 2020년부터 최소 3년간 지속되었습니다.

우버 역시 비슷한 사례를 겪었습니다. 2013년에 생성된 다음, 한 번도 교체되지 않은 접근 키가 깃허브 리포지토리에서 발견됐고, 곧바로 5,700만 건의 고객 데이터가 유출되었습니다. 이어 1억 4,800만 달러의 벌금이 부과되었고, 보안 책임자(CISO)는 형사 유죄 판결을 받았습니다.

키 유출을 알아챌 때까지 걸리는 시간

그렇다면 규모는 어느 정도일까요? 깃가디언의 2025년 보고서에 따르면, 2024년 한 해 동안 공개 깃허브에서 유출된 암호 키는 2,380만 개에 달합니다. 이는 전년 대비 25% 증가한 수치입니다. 더 무서운 점은, 2022년에 유출된 키의 70%가 2025년에도 여전히 유효하다는 사실입니다.

<출처: 작가, Claude로 제작>

그러니까 이들은 열쇠가 탈취되었는데도 자물쇠를 바꾸지 않은 것입니다. 무려 3년 동안이나요.

왜 바꾸지 않았을까요? 정확히는, 바꾸지 못했을 겁니다. 유출 사실을 몰라 바꾸지 않았을 수도 있고, 혹은 그 과정에서 기존에 정상적으로 작동하던 서비스에 영향을 줄까 걱정했을 수도 있습니다. 호텔에 비유하면, 객실 문고리를 전부 교체하는 바람에 기존 열쇠를 가진 직원들이 객실 청소를 못하게 되는 상황과 비슷합니다.

그렇다면 모바일 키, 즉 단기 자격 증명이 유출된다면 어떨까요? 애초에 임시 토큰은 복사나 공유를 전제로 만들어진 값이 아닙니다. 또한 다단계 인증을 거쳐 발급되기 때문에 이를 굳이 복사해 전달할 상황 자체가 많지 않습니다. 즉, 유출 경로 자체가 상대적으로 적습니다. 설령 유출되더라도 이 키는 수 시간 내에 자동으로 만료됩니다. 체크아웃 이후의 키카드처럼, 만료된 토큰은 의미 없는 문자열에 불과합니다.

그래도 감시 카메라(CloudTrail)가 있지 않나요?

호텔에 CCTV가 있듯, AWS에는 클라우드트레일(CloudTrail)이라는 서비스가 있습니다. 누가 언제 어떤 작업을 했는지, 모든 API 호출을 기록하는 서비스입니다. 장기 자격 증명이든 단기 자격 증명이든, 예외 없이 모두 기록됩니다.

<출처: 작가>

문제는 기록이 남는 것과 범인을 특정하는 것은 별개의 문제라는 점입니다. 모바일 키 방식, 즉 IAM 자격 증명 센터를 통한 접근은 기록이 비교적 명확합니다. “김승빈이 오후 2시 13분에 서울 호텔 503호에 들어갔다”처럼, 사용자 누구가 무슨 계정에서 어떤 작업을 했는지 신원을 특정할 수 있습니다.

실제 위시켓에서 활용중인 추척 봇 <출처: 작가>

반면 접근 키를 사용하면 기록에는 키 ID만 남습니다. 해당 키를 원래 주인이 사용한 것인지, 복사본을 가진 누군가가 사용한 것인지 구분할 수 없다는 뜻입니다. CCTV에 정문으로 자연스럽게 들어오는 사람이 찍혔지만, 그 사람이 실제 투숙객인지 열쇠를 주운 사람인지 알 수 없는 상황과 같습니다.

즉, 감시 카메라가 존재하더라도 범인이 정당한 열쇠를 들고 정문으로 들어온다면 이를 의심하기는 어렵습니다.

게다가 클라우드트레일에는 또 하나의 치명적인 한계가 있습니다. 기본 설정에서는 녹화 기록이 90일만 보관되며, 기간이 지나면 로그는 자동으로 삭제된다는 겁니다. 더 오래 보관하려면 별도의 저장소를 직접 설정해야 합니다. 클라우드트레일의 존재 자체를 모르는 경우도 적지 않고, 알고 있더라도 사건이 발생한 이후에야 CCTV를 돌려보듯 로그를 확인하는 경우가 비일비재합니다. 심지어 필요한 로그를 제대로 찾지 못하는 상황도 흔하죠.

따라서 실시간으로 이상 징후를 탐지하는 체계가 무엇보다 중요합니다. AWS에는 이러한 감지기 역할을 하는 다양한 서비스가 있기 때문에, 상황에 맞게 활용하면 보다 선제적으로 계정을 보호할 수 있습니다. (더 자세한 내용은, 글이 호응을 얻는다면 후속 편에서 준비해 보겠습니다.)

<출처: 작가, Claude로 제작>

마스터 키인 루트 사용자(Root User) 관리하기

지금까지 이야기한 접근 키는 호텔 객실 하나를 열어주는 열쇠에 비유할 수 있습니다. 그런데 이 호텔에는 마스터 키가 존재한다면 어떨까요?

AWS 계정에는 루트 계정 사용자(Root Account User)라는 특별한 사용자가 있습니다. 계정을 처음 생성할 때 만들어지는 이 사용자는 해당 계정 내 모든 리소스에 접근할 수 있습니다. 서버를 생성하거나 삭제하는 것은 물론이고, 다른 IAM 사용자를 만들고 권한을 변경하거나, 심지어 계정 자체를 폐쇄하는 것까지 합니다. 호텔 체인 전체를 열 수 있는 마스터 키와 같은 존재입니다. 어떤 객실이든, 어떤 금고든 열 수 있는 열쇠입니다.

일반 사용자(IAM User)의 권한을 아무리 잘 설정해두더라도, 루트 계정 사용자가 탈취되면 모든 보안은 무력화됩니다. 공격자가 이 마스터 키를 손에 넣는 순간, 다른 열쇠로는 대응할 방법이 사실상 사라집니다.

Root User의 두 가지 자격 증명

이 루트 계정 사용자 역시 IAM 사용자와 마찬가지로 두 가지 자격 증명을 가집니다. 하나는 이메일 주소와 비밀번호로, AWS 콘솔(웹사이트)에 로그인할 때 사용합니다. 다른 하나는 접근 키로, 앞서 설명한 것과 동일한 두 줄의 문자열입니다.

AWS 공식 문서는 이 두 가지 모두에 대해 강하게 경고합니다. 콘솔 로그인에 대해서는 “루트 계정 사용자가 필요한 작업이 아니면 사용하지 마세요”라고 안내하며, 접근 키에 대해서는 아예 “생성하지 마세요”라고 명시합니다. 그러나 아이러니하게도 접근 키를 생성하는 버튼은 콘솔에 버젓이 존재합니다.

부주의하게 만약 이 마스터 키를 유출했다면 어떻게 될까요? 글의 서두에서 잠깐 언급했던 코드 스페이스 사건이 바로 그 사례입니다. 2014년, 공격자는 루트 계정을 얻어 코드 스페이스의 AWS 콘솔 접근 권한을 탈취했습니다. 회사가 대응을 시도하자 공격자는 서버와 저장소, 백업 등 복구 가능한 모든 리소스를 삭제해버렸습니다. 결국 코드 스페이스는 영구적으로 폐업했습니다.

모바일 키로 바꿔라

지금까지의 이야기를 정리하면 이렇습니다. 쇠 열쇠(IAM 접근 키)는 만료되지 않고, 복제가 쉽고, 누가 사용하는지 구별하기 어렵습니다. 한 번 유출되면 회수도 거의 불가능합니다. 여기에 마스터 키(루트 계정 사용자)까지 유출된다면, 사실상 대응 자체가 불가능해집니다.

물론 열쇠를 잃어버려 나오는 이 머리 아픈 상황에 대한 해법은 이미 정해져 있습니다. 모바일 키로 바꾸는 겁니다.

AWS도 권장하는 해법

IAM 자격 증명 센터는 AWS가 제공하는 모바일 키 시스템입니다. 이 시스템은 AWS 조직 관리 계정에서 모든 멤버 계정의 사용자와 권한을 통합 관리합니다. 로그인할 때마다 MFA를 거쳐야 하고, 인증이 완료되면 임시 토큰이 발급됩니다. 이 토큰은 일정 시간이 지나면 자동으로 만료됩니다. 또, 그렇기에 누가 어떤 계정에서 어떤 작업을 했는지 기록도 명확하게 남습니다.

<출처: 작가>

사실 이 개념은 새로 등장한 규정은 아닙니다. AWS는 2017년 AWS SSO라는 이름으로 이 서비스를 처음 출시했고, 2022년 IAM 자격 증명 센터로 이름을 변경하며 공식 권장 방식으로 자리 잡았습니다. 이어 2025년에는 공식 블로그에서 “장기 IAM 접근 키를 넘어서라”는 제목의 글까지 발행했습니다.

그럼에도 불구하고 많은 개발자가 여러 이유로 IAM 사용자와 접근 키를 씁니다. 아주 큰 글씨로 경고가 적힌 공식 문서를 충분히 읽지 못했을 수도 있고, 코딩 에이전트가 생성한 설정을 의심없이 신뢰했을 수도 있습니다. 또는 문제를 알면서도 관성적으로 기존 방식을 고수했을 지도 모릅니다.

그래서일까요? 접근 키를 코드에 포함한 채 깃허브에 올렸다는 이야기를 개발자라면 한 번쯤은 들어봤을 겁니다. 그렇게 여전히 2024년 한 해에만 2,380만 개의 암호 키가 유출되었습니다.

보안 시스템을 직접 구축하기 어렵다면?

문제는 현실은 녹록지 않다는 겁니다. AWS 조직을 구성하고, IAM 자격 증명 센터를 설정하며, 사용자와 권한을 관리하고, 클라우드트레일 로그를 별도 저장소에 백업하는 일까지, 이 모든 과정을 직접 수행하려면 AWS 보안에 대한 전문 지식이 필요합니다. “개발자라면 이런 것쯤은 다 알지 않을까?”라고 생각할 수도 있습니다. 하지만 병원에서 수술을 받을 때도 외과 의사와 마취과 의사가 각자의 역할을 맡듯, DevSecOps나 클라우드 전문가 없이 이를 구축하는 일은 쉽지 않습니다. 중요한 보안 관련 일을 AI 모두에게 맡기는 것도 찝찝하고요.

특히 직접 개발을 하지 않고 외주 개발사에 맡기는 경우도 마찬가지입니다. 개발 과정에서 외주 개발사가 접근 키를 실수로라도 유출하지 않았다고 확신할 수 있을까요? 임시 자격 증명 운용이 번거롭다는 이유로, 두 줄짜리 문자열을 복사해 여러 곳에서 사용하고 있을 가능성도 있습니다. 또한 AWS에 대한 기초 지식이 부족하다면, 외주 개발이 끝난 다음 불필요한 사용자나 접근 키가 모두 정리되었는지 확인하기도 어렵습니다.

사실 그래서 저는 위시켓에서 이런 일을 대신합니다. 안심 호스팅 서비스라는 것을 운영하며 AWS 계정 생성부터 IAM 자격 증명 센터 사용자 생성, 권한 관리를 고객을 대신해 설정하고 운영합니다. 불필요한 리전에서의 서버 생성을 차단하고, 클라우드트레일 로그를 삭제하는 행위도 막습니다. 또한 보안에 취약한 IAM 사용자나 접근 키 생성 자체를 원천적으로 제한합니다. 정책은 누구든 예외 없이 적용됩니다.

위시켓 안심 호스팅 서비스 <출처: 위시켓>

마치며

물론 서비스 홍보도 홍보지만, 저희한테 맡기지 않더라도 모바일 키로의 전환은 꼭 검토했으면 합니다. 위시켓 클라우드팀에서 근무하다 보니, 탈취된 자격 증명으로 뭄바이나 스톡홀름과 같은 예상치 못한 리전에 서버가 만들어지고, 암호화폐 채굴에 악용되는 사례를 직접 목격한 적도 있습니다. 보안 규칙을 매일 고민하고 다루는 입장에서 가장 쉬운 일을 두고 큰 피해를 입는 고객사를 보며, 그 지식을 전하고 싶었습니다.

그래서 다시 한 번 강조하려고 합니다. 애초에 열쇠를 만들지 않는다면 잃어버릴 열쇠도 존재하지 않습니다. AWS 스스로가 말하듯 쇠 열쇠를 내려놓고, 모바일 키로 바꿔야 합니다.

기회가 된다면, IAM 자격 증명 센터의 기술적인 부분을 더 깊이 다뤄볼 예정입니다. 실제로 모바일 키를 어떻게 설정하고, 어떤 구조로 동작할지, 그 내부 구조를 열어보겠습니다.

]]>

프리랜서 개발자 186명의 2025년 생존 리포트

프리랜서 개발자 186명의 2025년 생존 리포트

프리랜서 시장은 빠르게 성장하고 있지만, 정작 현장의 이야기는 '각자도생'에 가깝습니다. 단가는 어느 정도인지, 일감은 어디서 구하는지, 공백기엔 뭘 하는지, 경험해본 사람만 아는 정보들이죠.

요즘IT와 위시켓이 프리랜서 개발자 186명을 대상으로 설문을 진행했습니다. 응답자의 68%가 경력 7년 이상, 45%가 프리랜서 활동 7년 이상인 베테랑들이에요. 이 리포트는 그들이 말하는 현실과 생존 방식을 데이터로 정리한 결과입니다.

프리랜서를 선택한 이유: 자유보다 수입

'시간과 장소의 자유'가 1위일 것 같지만, 실제로는 '더 많은 수입(43.5%)'이 가장 큰 동기였습니다. 창업이나 비즈니스 확장(29.6%)이 그 뒤를 이었고, 시간·장소의 자유는 23.1%로 3위에 그쳤어요. 낭만보다는 현실적인 계산이 프리랜서 시장 진입의 주된 이유인 셈이죠.

가장 두려운 순간: 공백기

10명 중 6명(61.8%)이 '공백기가 길어지는 것'을 가장 두렵다고 답했습니다. 그 이유를 물었더니 74.7%가 '경제적 수입 감소'를 꼽았어요. 커리어 단절이나 기술 도태 우려보다 당장의 생계 문제가 훨씬 큰 불안 요소로 작용하고 있었습니다.

다음 프로젝트까지 평균 대기 시간은 1~2개월(37.6%)이 가장 많았고, 이 시간을 어떻게 보내느냐는 질문에 59.7%가 '새로운 기술 학습'이라고 답했어요. 단순 휴식보다는 다음을 준비하는 시간으로 활용하는 경향이 뚜렷했습니다.

일감은 어디서? 경력에 따라 다르다

프로젝트 수주 경로는 지인 소개(29.6%), 플랫폼(27.4%), 재계약(26.3%)이 비슷한 비중으로 나타났습니다. 흥미로운 건 경력별 차이예요. 초급 개발자는 플랫폼 의존도가 43.8%로 높은 반면, 고급 개발자는 22%까지 낮아지고 대신 재계약과 지인 소개 비중이 59.8%까지 올라갑니다. 경력이 쌓일수록 관계 기반 수주가 늘어나는 구조죠.

협업에서 가장 힘든 건 '마감'

클라이언트와 협업할 때 가장 힘들었던 경험으로 '비현실적인 일정 강요(34.4%)'가 1위를 차지했습니다. 대금 결제 지연이나 미수금 문제(7.5%)보다 훨씬 높은 수치예요. 업무 범위 불명확(17.7%), 클라이언트의 전문성 부족과 의사결정 지연(15.1%)이 뒤를 이었습니다.

AI 대체? 두렵지만 배우고 있다

'AI가 개발자를 대체할 것'이라는 말에 86.5%가 동의했습니다. 하지만 위축되기보다는 적극적으로 대응하는 모습이에요. 74.7%가 현재 AI 관련 기술을 학습 중이라고 답했습니다.

리포트 마지막에는 100명 이상의 현직자가 직접 작성한 주관식 응답을 정리한 생존 팁이 담겨 있습니다. 멘탈 관리, 네트워킹, 기술 전문성, 재정 관리 네 가지 영역으로 나뉘어 있는데요. "최소 6~12개월 생활비를 확보해두라", "기술보다 신뢰가 재계약을 만든다", "프로젝트 퀄리티보다 마감과 소통이 중요하다"처럼 실전에서 우러나온 조언들입니다.

요즘IT 독자 여러분의 지속 가능한 성장을 위해, 전체 리포트를 공개합니다. 2026년 생존 전략에 도움이 되길 바랍니다. 요즘IT와 위시켓은 2026년에도 프리랜서 개발자 여러분을 응원하겠습니다.

<2025 프리랜서 개발자 생존 리포트>에서는 이런 내용을 알 수 있어요

응답자 186명의 직군·경력·활동기간 상세 분포
공백기에 대한 인식과 활용법
프로젝트 수주 채널과 갈등 해결 방식
AI 대체 가능성 인식과 주요 학습 영역
현직자 100명 이상이 직접 쓴 생존 팁 (멘탈·관계·기술·재정)

]]>

당신 회사가 AI 도입에 늘 실패하는 2가지 이유

Editor's note

AI로 개인의 생산성은 눈에 띄게 높아지고 있지만, 많은 기업이 여전히 ‘우리 조직에는 어디서부터 적용해야 하는가’에서 어려움을 겪고 있습니다. 요즘IT는 위시켓이 운영하는 미디어로, 현장에서 기업들의 AI 도입을 가장 가까이에서 보고 듣는 위치에 있습니다.

이번 글은 위시켓 AIDP 팀이 실제 프로젝트와 상담을 통해 확인한 기업의 AI 도입이 왜 막히는지, 어디서부터 접근해야 하는지에 대한 정리입니다. 우리 회사의 경험을 기반으로 한 내용이지만, 그만큼 지금 시장에서 실제로 일어나고 있는 변화와 문제를 가장 정확하게 전달할 수 있다고 생각해 실었습니다.

글을 읽고 여러분의 조직에서는 AI 도입 과정에서 어떤 고민이 있었는지도 함께 들려주세요.

기업이 정체한 본질적 이유와 실패하지 않는 AX 전략 두 가지

“AI 없이 온전히 보낸 하루”가 기억 나시나요? ChatGPT가 등장한 지 3년 여만에 이미 AI는 우리 삶에 깊이 침투해 많은 것을 바꿨습니다.

저는 위시켓 AIDP(AI Delivery Platform) 사업부 리더 이홍주입니다. AI 도입을 전문적으로 컨설팅하고 구축까지 돕는 일을 하고 있죠. ChatGPT가 등장했을 때부터 AI를 사업과 운영 프로세스에 한발 앞서 적용하며 직접 활용해왔습니다.

그러다 보니 개인적으로는 AI 덕분에 일과 삶 모든 방면에서 생산성이 15~20% 향상됐다고 느낍니다. 저뿐 아니라 요즘엔 비개발자들도 ChatGPT와 같은 대화형 AI를 통해 프로그램을 직접 만들어냅니다. 프로그램만이 아니라 정보 탐색, 아이디어 발굴, 데이터 정리, 논리 구체와 등을 더 빠르게, 더 많이 해내며 생산성을 높이고 있습니다.

개발자들은 더 극적인 변화를 맞이했습니다. 생산성이 최소 3~4배 증가했다고 해도 과언이 아닙니다. 요즘 Copilot, Cursor 등 코딩 에이전트 덕분에 직접 코드를 입력할 일이 크게 줄었으며, 수준 높은 모듈화된 코드의 작성, 활용, 개선이 몇 가지 설정과 프롬프트만으로 가능해졌습니다.

AI가 생산성 3배 높였는데, 왜 연봉은 그대로일까?

하지만 이런 생산성 증가에도 불구하고 연봉은 상승되지 않았습니다. 위시켓에서 관찰한 IT 프리랜서 단가는 오히려 전체적으로 하락하고 있습니다. 개발자 몸값의 부익부 빈익빈 현상도 여전하죠. 생산성이 3~4배 증가했다면 연봉은 최소 2배 올랐어야 하는 것 아닐까요?

이는 AI가 개인에게 가져다준 변화와 충격에 비해 조직의 변화는 미미한 현실을 단적으로 보여주는 사례입니다. 이뿐만 아니라, 아마 생각보다 많은 조직에서 ‘실제로 우리 회사에 충격적인 변화가 없다’고 느낄 것입니다. 개인의 변화에 비하면 그 차이가 크죠. 왜 이런 역설이 발생했을까요?

위시켓은 월 1,000건 이상의 IT 프로젝트 의뢰가 유입되는 플랫폼입니다. 그런 만큼 다양한 회사 대표님들과 담당자들을 현장에서 만나죠. 그 과정에서 이 역설의 근본적인 이유를 찾을 수 있었습니다. 그 결론을 한 마디로 정리하면 다음과 같습니다.

AI는 회사를 바꾸지 않습니다.
AI를 ‘소프트웨어’로 구현하는 회사만이 변화합니다.

이 글은 바로 그 지점에서 시작합니다. 왜 개인과 기업 사이에 이렇게 거대한 격차가 생겼는지 두 가지 핵심 이유를 파헤치고, 기업이 나아가야 할 두 가지 명쾌하고 실질적인 방향을 제시하겠습니다.

AI 도입이 조직 성과로 이어지지 않는 두 가지 이유

1. AI는 '원유'일 뿐, '훌륭한 소프트웨어'가 가치를 만든다

LLM과 ChatGPT의 관계에 대해 생각해봅시다. 우리는 LLM을 ChatGPT라는 소프트웨어를 통해 사용합니다. LLM을 포함한 생성형 AI는 결국 '모델(Model)'일 뿐이며, ChatGPT는 OpenAI의 최신 모델을 활용하면서도, 에이전트 같은 대화형 경험을 제공하기 위해 수많은 로직이 '소프트웨어'로 구현된 사례죠.

즉, AI는 '원유(Crude Oil)'와 같습니다. 원유 자체는 엄청난 잠재력을 가졌지만, 그 자체로는 가치를 만들어내지 못합니다. 이 원유를 LPG, 휘발유, 나프타 등 정제된 제품으로 바꾸어 고객 경험이나 운영 프로세스를 변화시키는 것이 바로 '소프트웨어'의 역할이며, 이곳에서 진정한 가치(Value)가 구현됩니다.

<출처: 위시켓, Gemini로 제작>

이제 앞서 제기한 역설이 명확해집니다. 개발자의 생산성이 3~4배 증가했다는 것은 '원유'가 확보되는 양이 많아졌다는 의미입니다. 그러나 이 원유가 '정제' 과정을 거쳐 실제 가치를 만들어내는 결과물, 즉 훌륭한 소프트웨어로 완성되는 양은 비슷하거나 조금 더 많은 수준에 그칩니다.

왜일까요? 코드를 빨리 생성하는 것과 그것을 고객 가치로 전환하는 것은 전혀 다른 문제이기 때문입니다. 요구사항 정의, 아키텍처 설계, 사용자 경험 최적화, 비즈니스 로직 구현. 이 모든 '정제' 과정의 난이도는 여전히 높습니다. 연봉과 처우는 '투입량'이 아닌 '결과'로 측정됩니다. 따라서 최종 결과물이 크게 증가하지 않는다면 연봉 역시 크게 오르지 않습니다. 오히려 AI를 활용하는 개발자가 많아지면서 경쟁이 치열해지기 때문에, 단가가 낮아지는 추세가 나타나는 것이죠.

핵심을 다시 정리하면 이렇습니다.

AI 자체는 당신의 회사를 변화시키지 않습니다. AI를 통해 구축된 소프트웨어가 회사를 변화시킵니다.

엔비디아 CEO 젠슨 황은 이렇게 말했습니다. "AI는 당신을 대체하지 않는다. AI를 활용하는 다른 사람이 당신을 대체한다."

젠슨황 엔비디아CEO <출처: 엔비디아>

여기서 우리는 논리를 한 단계 더 발전시킬 수 있습니다.

AI를 통해 구축된 '소프트웨어'와 이를 현명하게 활용하는 '사람'이 당신을 대체할 것입니다.

2. SaaS를 쓰는데 왜 변화가 없을까 - 자체 소프트웨어의 필연성

두 번째 이유를 살펴봅시다. 이미 많은 기업이 노션, 슬랙, 더존, SAP 같은 다양한 SaaS(Software as a Service) 솔루션을 활용하고 있습니다. 그런데 왜 변화를 체감하지 못할까요?

연 매출 50억 원 이하, 인원 수 30명 이하 규모의 회사라면, SaaS 솔루션들을 잘 활용하는 것만으로도 충분한 AI 전환 효과를 볼 수 있습니다. AI로 인해 SaaS의 종류가 다양해지고 수준이 빠르게 향상되고 있으니, 선택지도 많아 AI 시대의 수혜를 그대로 체감할 수 있겠죠. 하지만 이 규모를 초과하는 회사라면 상황은 완전히 달라집니다. 일정 규모 이상의 회사는 시장이라는 치열한 경쟁 환경 속에서 고유한 서비스와 프로세스를 통해 경쟁우위를 확보해 왔습니다.

그런데 SaaS 솔루션은 표준화된 기능과 제한적인 커스터마이징만 제공합니다. 이는 인사, 회계 등 경영지원 영역 같은 표준화된 프로세스의 생산성 강화에는 도움이 됩니다. 하지만 우리 회사만의 고유한 경쟁우위를 혁신하는 변화는 만들어낼 수 없습니다. 왜일까요? 경쟁우위는 표준화된 기능이 아닌, 우리 회사만의 고유한 일하는 방식, 즉 서비스와 프로세스의 최적화에서 나오기 때문입니다.

정리하면, 일정 규모 이상 기업이 변화를 체감하지 못하는 이유는 명확합니다. 자체 소프트웨어로 고유한 경쟁우위를 최적화해야 하는데, 표준화된 SaaS에만 의존하고 있기 때문입니다. 결국 일정 규모를 넘어서는 기업이 AI를 제대로 활용하면서 경쟁우위를 혁신하려면, 우리만의 소프트웨어, 즉 자체 소프트웨어를 구축하는 수밖에 없습니다. 개인의 생산성 향상을 조직 전체의 성과로 전환하려면, 우리 회사 고유의 업무 방식을 AI와 결합한 소프트웨어가 필요합니다.

자체 소프트웨어를 구축하지 않으면 AI 전환(AX)은 성공할 수 없습니다. 손을 놓고 있다가는 자체 소프트웨어를 구축하고 AI 전환에 성공한 경쟁사에 압도될 것입니다.

하지만 소프트웨어 구축의 현실: 50%의 실패

'언제든 충분히 검증되었을 때, 나중에 시도하면 되지 않느냐?'라고 생각하실 수 있습니다. 하지만 AI 전환과 우리만의 소프트웨어를 구축하는 프로젝트는 비용만 지불하면 무조건 투자 대비 성과(ROI) 관점에서 성공할 수 있는 종류가 아닙니다. 지금은 최소한, 어떻게 실패하지 않을 수 있는가에 대한 방법을 알고 있어야 합니다.

이러한 프로젝트들은 기술적 난이도뿐만 아니라, 변화에 대한 조직의 거부감, 모호한 요구사항 정의, 데이터 통합의 실패와 같은 다양한 비즈니스/조직적 문제로 인해 ROI(투자 대비 수익) 관점에서 최소 50% 이상의 확률로 실패합니다.

그렇다면 어떻게 해야 할까요?

AX의 시작, 실패하지 않는 소프트웨어 실현 방법

먼저 냉정하게 인정해야 합니다. 자체 소프트웨어 구축은 쉽지 않습니다. 50% 이상이 실패하는 데는 이유가 있습니다.

하지만 포기할 수는 없습니다. 지금은 위기이자 기회입니다. AI 개발 생산성이 3~4배 향상된 지금, 과거에는 불가능했던 속도로 자체 소프트웨어를 구축할 수 있습니다. 이전에 3개월 걸리던 프로젝트가 이제는 1개월 만에 실현됩니다. 경쟁사가 이 기회를 잡아 앞서가는 동안 우리만 손을 놓고 있을 수는 없습니다.

다행히 방법은 있습니다. 실패하지 않는 소프트웨어 구축을 위한 두 가지 핵심 전략을 소개합니다.

1. 5배 이상 높아진 AI 소프트웨어 개발 생산성을 레버리지하라

첫 번째 전략은 '5배 이상 높아진 AI 소프트웨어 개발 생산성을 레버리지하는 것'입니다.

개발 관련 종사자라면 모두 공감하실 겁니다. 22년말 ChatGPT 등장 이후, 개발 생산성이 최소 3~4배 증가했다는 것을요.

2022년 말에 3개월 걸리던 프로젝트가 이제는 1개월 만에 실현될 수 있습니다. 더 중요한 사실은 '높은 소프트웨어 개발 비용' 이라는 진입장벽이 거의 허물어졌다는 점입니다. Cursor, Copilot 등의 코딩 에이전트가 소스코드 개발 전문가를 완전히 대체하면서 아키텍쳐 설계, UI/UX 기능 모듈 구현, CI/CD 역량만 있으면 순식간에 결과물을 내보일 수 있습니다.

따라서, 이제는 계약 및 프로젝트 착수 전에도 ‘맞춤형 소프트웨어’ 프로토타입을 사전에 확인하고 진행할 수 있는, 확인해야 하는 시대입니다. 예전처럼 PI(Process Innovation)이나 BPR(Business Process Reengineering) 프로젝트를 선행하면서 ‘제안서’에 목숨 걸고 공들이던 시기는 끝난 것 같습니다.

즉 AI 소프트웨어 개발 생산성을 레버리지한다는 것은 우리가 기대하는 결과에 대한 프로토타입(MVP) 실현 속도가 기존 수 개월(Month)에서 수 일(Day) 혹은 수 주(Week)로 단축되었으니, 빠르게 만들어보고, 테스트하고, 수정하는 방식으로 전환하라는 것입니다. 실현 가능성이 불분명한 컨설팅 보고서를 기다리기보다, 실제 작동하는 소프트웨어를 먼저 만들어 검증하는 것이 이제는 더 빠르고 효과적입니다.

실제로 위 화면처럼 아키텍처와 기능 기획만 제대로 나오면 아래와 같은 소프트웨어를 3일~7일 안에 만들 수 있습니다.

하지만, ‘프로토타입 실현이 극단적으로 빨라졌다’라는 사실만으로 자체 소프트웨어 구축을 무조건 성공할 수 있을까요? 그렇지 않습니다. 아무리 빨라져봐야 실제 업무에 활용되지 않으면, 즉 현업에 배포(deployment)되지 않으면 그저 허울좋은 전시품일 뿐입니다.

2. Garbage In - Garbage Out을 경계하라

두 번째 전략은 'Garbage In - Garbage Out을 경계하는 것'입니다. "쓰레기를 넣으면 쓰레기가 나온다." 전통적인 이 원칙이 AI 시대에 더욱 중요해졌습니다.

AI 개발 생산성이 높아졌다고 해서 소프트웨어 실현 비용이 엄청 낮아지는 것은 아닙니다. 바로 Garbage In - Garbage Out 때문입니다. Cursor, Copilot 등 코딩 에이전트는 매우 빠르게 코딩합니다. 그런데 명확한 기대 결과를 설정하고 방향과 단계를 잡아주지 않으면, 있어 보이지만 아무 쓸모없는 소프트웨어가 나옵니다. 개발자의 시간과 LLM 토큰을 아무리 투입해도, 사용하지 않는 기능이 많고, UI/UX는 최악은 아닌데 이해되지 않고, 막상 핵심 기능의 품질은 기대에 부합하지 않는 결과물이 나오는 것이죠.

요즘 소프트웨어 구축 프로젝트를 진행하다 보면, 개발 생산성이 높아졌다는 게 체감됩니다. 고객이 잘못됐다고 피드백하면, 프로토타입뿐 아니라 전체 산출물을 말 그대로 처음부터 끝까지 2~3번 뒤엎는 경우도 종종 봅니다.

그런데 이게 옳은 현상일까요? 생산성이 올라가서 금액 부담이 적어졌더니, 결국 걸리는 시간은 동일하고 고객사 입장에서는 커뮤니케이션만 더 답답합니다. 채용한 개발자든 외주 의뢰한 개발사든 마찬가지입니다.

지금이 '자체 소프트웨어'를 최적의 ROI로 실현할 수 있는 이상적인 타이밍입니다. 지금 실현된다면 복리적 효과도 크게 기대됩니다. 하지만 여전히 많은 분들이 채용이나 외주 과정에서 Garbage In - Garbage Out을 반복하고 있습니다.

어떻게 피할 수 있을까요? 핵심은 올바른 파트너 선택입니다. 두 가지 기준을 소개합니다.

AI 도입 시 Garbage In - Garbage Out을 막기 위한 방법

(1) 엔드투엔드 기획 역량이 있는 파트너를 선택하라

채용을 하든 외주를 하든, 엔드투엔드 기획 역량이 있는 파트너와 함께하십시오.

대부분의 개발자나 개발사(90% 이상)는 채용을 하든 외주를 하든 기획한 대로, 설계한 대로만 소프트웨어를 구현합니다. 엔드투엔드 컨설팅 회사가 아닌, 개발사기 때문에 어떻게 보면 당연한 것이겠지요. 그래서, 개발자나 개발사는 우리가 원하는 요구사항을 구체화하고, 최적의 솔루션을 제안하고, 전체 프로젝트 일정과 작업 범위를 구성하고, 적절한 단계 및 마일스톤을 설정하는 것에는 익숙하지 않습니다. 특별히 잘 못한다기 보다는 그저 다른 프로젝트를 했던 것처럼 하는 것입니다.

위에서 언급드렸던 것처럼, 명확한 기대 결과를 설정하고 방향과 단계를 잡아주지 않으면, 좋은 소프트웨어는 구현될 수 없습니다. 많은 기업들이 AI 도입과 전환에 실패하는 이유는, 엔드투엔드가 아니라 단순 외주 용역을 맡기려고 하기 때문입니다.

그렇다면 엔드투엔드 기획 역량이 있는 파트너를 어떻게 판단할 수 있을까요? 임직원, 그 중에서도 오퍼레이션 팀 리더를 채용하는 것처럼 판단하시라고 조언드리고 싶습니다. 아래와 같은 질문에 부합하는 파트너들이죠.

우리 회사의 비즈니스를 이해하고 있으며, 커뮤니케이션이 수월한가?
시키는 일만 하는 게 아니라, 우리의 문제 자체를 해결하려고 하는가?
일회적 용역 관계가 아닌, 회사와 함께 성장할 수 있나?

(2) 문제 해결 역량이 있는 파트너를 선택하라

AX(AI Transformation)를 실현하려면 회계, 인사 등 비핵심 공통 기능이 아니라, 제품개발/마케팅, 영업/물류/채권, 구매/조달/재고/채무, 생산/제조/원가, 데이터 분석/비즈니스 인텔리전스와 같은 회사의 핵심 밸류체인(Value Chain) 중심으로 자체 소프트웨어를 구축해야 합니다.

특히 매출액 50억 이상이거나 인원 규모 30명 이상인 경우, 대부분 고유한 서비스와 비즈니스 프로세스 특성을 가지고 있습니다. 생존과 이익 창출을 위한 경쟁우위를 구성하는 기반이지요.

일반적인 SaaS나, B2C 소프트웨어 경험만 있는 파트너는 이런 고유한 경쟁우위를 소프트웨어로 실현하기 어렵습니다. 이 실현 과정이 하나의 ‘거대한 문제’ 이며, 이 문제를 해결해본 경험과 역량이 있어야 AX 성공 확률이 높아집니다. (다시 한 번 상기시켜 드리면, ROI 관점에서 성공 확률은 50% 미만입니다.)

그렇다면 문제 해결 역량이 있는 파트너인지 아닌지는 어떻게 판단할 수 있을까요?

이커머스, 단순 정산 어드민, 웹사이트 제작 등 누구나 상상할 수 있는 문제를 해결해본 게 아닌, 기업의 독특하고 고유한, 어려운 문제를 해결해본 파트너를 채용하거나 외주 의뢰하십시오.

이런 높은 기준을 적용하지 않는다면, 우리 회사의 핵심 서비스와 업무 프로세스 변화는 실패할 가능성이 매우 높습니다.

마치며

최근 위시켓은 AI 전담 조직 AIDP를 신설하고, 전문가 매칭을 넘어 컨설팅·개발·운영까지 직접 지원하기 시작했습니다. 13년간 2만 건 이상의 IT 프로젝트를 수행하며 쌓은 경험과, AI 시대에 들어 확보한 500억 원 규모의 프로젝트 매니지먼트 자산 덕분에, 자연스럽게 ‘기업들이 어디에서 가장 많이 막히는가’를 깊이 관찰할 수 있었습니다. 그 과정에서 실제로 많은 실패 사례를 가까이서 보며, 이 문제를 전담으로 다룰 조직의 필요성을 느끼게 됐습니다.

기획 역량과 문제 해결 역량을 모두 갖춘 파트너를 직접 찾고 관리하는 일이 쉽지 않다면, 위시켓 같은 플랫폼을 활용하는 것도 하나의 선택입니다. 하지만 이 글의 목적은 특정 서비스를 권하는 데 있지 않습니다. 어떤 방식을 선택하시든, 불필요한 시행착오와 실패를 줄이길 바라는 마음에서 현장 경험을 공유드리는 것입니다. 수 억 원을 들여놓고도 실패하는 안타까운 사례를 정말 많이 봤고, 그런 일이 없으면 좋겠습니다.

➡️ 위시켓 AIDP 살펴보기

글을 끝까지 읽으셨다면, AI의 파급력을 체감하면서도 기업의 변화는 만들어내지 못해 답답해하시는 분들이거나 변화를 만들기 위해 고심하고 계신 분들일 거라 생각합니다. 그런 분들께 이 글이 작게나마 도움이 되기를 바랍니다.

핵심을 다시 정리하면

개인의 생산성은 폭증했지만 기업은 변하지 않는 이유는 명확합니다. ‘AI’가 아니라 ‘소프트웨어’가 핵심입니다.
AI는 원유일 뿐이며, 소프트웨어로 정제해야 가치가 됩니다.
일정 규모 이상 기업은 자체 소프트웨어 구축이 필수입니다. 하지만 소프트웨어 구축은 성공이 쉽지 않습니다.
성공하려면: (1) AI 개발 생산성을 레버리지하고 (2) 올바른 파트너를 선택해야 합니다.
지금 시작하지 않으면 경쟁사와의 격차가 기하급수적으로 벌어집니다.

AI 시대의 승자는 AI를 가진 자가 아니라, AI로 만든 훌륭한 소프트웨어를 가진 자입니다. 그것이 AI 시대 우리 회사가 변화하지 못하는 이유이자, 우리가 나아가야 할 방향입니다.

당신의 목소리를 들려주세요

12월에 발행될 'AI 도입 리포트'에 여러분의 경험과 고민을 담고자 합니다. AI가 만들어내는 급격한 변화에 압박을 느끼는 분들이 많을 것입니다.

AI 전환을 시도하면서 겪은 어려움
자체 소프트웨어 구축 과정의 실제 경험
지금 가장 고민하고 있는 지점

여러분의 솔직한 이야기를 들려주세요. 현장의 생생한 목소리가 더 나은 인사이트를 만듭니다.

➡️의견 남기기

]]>

프리랜서 하시게요? 그럼 기획을 잘 하셔야겠네요?

이 글은 ‘리오랩(매니패스트)’이 제작하고, 요즘IT가 기업 제휴 콘텐츠로 소개합니다.

혹시 프리랜서 개발자로 일하고 계신가요? 혹은, SI를 운영하고 계신가요? 그렇다면 혹시, 이번 달 돈을 받지 못한 공짜 노동은 몇 시간 정도 하셨는지 계산해 보셨나요?

저는 가끔 프리랜서 일을 하는 부업으로 친구들을 만나는데, 친구들이 이런 말을 할 때가 있습니다. “저번 주말에 한 5시간 투자해서 거의 오십만 원 받았잖아. 요즘 외주 일 꽤 쏠쏠해.” 프리랜서로 부수적인 수입을 얻는다는 것은 직장인들에게는 아주 멋진 일입니다. 단 몇십, 몇백만 원에 불과하더라도 그런 부수입은 우리들을 아주 행복하게 만들죠. 하지만 본격적으로 외주 일을 하든, 부업으로 외주 일을 하든 외주 업무의 현실은 비청구시간 (Non-Billable Hours)과의 끝없는 싸움입니다.

나도 모르게 하고 있는 공짜 노동들

외주 업무를 할 때 가장 고통스러운 시나리오를 복기해 봅시다. 열심히 클라이언트를 찾아다니고, 운 좋게 구한 예비 클라이언트와의 미팅이 성사됩니다! 두 시간 동안 열정적으로 미팅하며 클라이언트의 요구사항을 듣습니다. 집에 돌아와 세 시간을 들여 미팅 내용을 정리하고, 클라이언트의 요구사항을 분석하여 제품의 핵심 기능을 도출합니다. 이 기능은 어떻게 구현하고, 저 기능은 어떤 리스크가 있는지 혼자만의 회의를 거칩니다. 다시 한 시간을 들여 꼼꼼하게 견적서를 작성해 발송합니다. 이 정도면 클라이언트가 받아들일까? 이 정도면 내가 (혹은 우리 팀원들이) 일했을 때 손해는 아닐까? 여기까지 총 6시간. 나의 시급을 5만 원으로만 계산해도 30만 원어치의 노동입니다.

그리고 며칠 뒤, "검토 후 연락드리겠습니다."라는 정중한 메일을 받습니다. 그리고 그 클라이언트는 다시는 연락이 오지 않습니다.

결국 이 6시간의 노동은 비청구시간, 즉 순손실로 잡힙니다. 혹시 클라이언트와 계약하게 되더라도, 5시간 만에 번 줄 알았던 내 수입은 사실 11시간이 투입된 수입이었습니다. 우리가 아무리 최신 기술 스택을 마스터하고 AI로 코딩 시간을 50% 단축해도, 그것만으로는 영업 단계의 이 비청구시간을 줄이는 데는 큰 도움이 되지 않습니다.

실제로 해외 프리랜서 전문 매체 프리랜서 인포머(Freelance Informer)의 분석에 따르면, 많은 프리랜서가 업무 시간의 약 30%를 고객 확보, 행정, 제안서 작성 등 청구 불가능한 활동에 쏟고 있습니다. 이는 프리랜서가 실제로 생각하는 것보다 약 30%가량 적은 수입을 얻고 있을 수 있음을 시사합니다.

프리랜서들은 아마 그들이 생각하는 것보다 30%는 더 적게 벌고 있을 수도 있다. <출처: 프리랜서 인포머>

이 글에서는 이 고질적인 공짜 노동 시간을 유료 계약으로 바꾸는 가장 현실적이고 강력한 무기, 바로 명료한 기획력에 대해 이야기해보고자 합니다. 만일 외주 업무를 하시는 분이라면, 혹은 부업으로 외주 업무를 시도하려고 생각하셨던 분에게 좋은 아이디어가 되기를 바랍니다.

수주의 근본적인 실패 원인: 고객의 불안감

우리는 왜 수주에 실패할까요? 수많은 클라이언트 미팅이 왜 계약으로 이어지는 데 실패하는 걸까요? 우리는 클라이언트의 마음속으로 들어가 볼 필요가 있습니다.

많은 클라이언트는 IT 전문가가 아닙니다. 그들은 보통 특정 제품에 대한 아이디어와, 그 제품이 어떤 방식으로 기능할 것이라는 느낌만 가지고 있습니다. 그리고 동시에, "이 개발자가 제대로 만들어오지 않으면 어쩌지?", "내가 생각한 것과 완전히 다른 결과물이 나오면 어쩌지?" 하는 거대한 불안감을 안고 있습니다.

이 불안감을 해소하지 못하면 계약은 성사되지 않습니다. 저희는 SI를 운영하고 많은 프리랜서들을 고용하기도 하면서, 클라이언트와 미팅하는 개발자/PM들에게서 세 가지 유형을 관찰했습니다.

클라이언트의 거친 생각과 불안한 눈빛을 마주한다면… <출처: 작가, ChatGPT 생성>

유형 1: 코더(The Coder)

클라이언트: "인스타그램 같은 앱을 만들고 싶어요. 그런데 이제 특정 직업인들만 쓰는 거죠."
개발자: "아, 네. 가능합니다. 프론트엔드는 React Native로 하고, 백엔드는 Node.js와 Express, DB는 MySQL 할거구요... 예상 비용은..." (기술 설명)
클라이언트 속마음: "무슨 말이지? 이게 내가 원하는 결과를 만드는 가장 효율적인 방법이 맞긴 맞나? 이렇게 하면 내가 원하는 결과가 나오기는 하나?" (불안감 상승) → 계약 포기.

코더 유형은 기술로만 소통합니다. 고객이 원하는 것은 기술이 아니라 결과인데도 말입니다.

유형 2: 영업사원(The Salesman)

클라이언트: "인스타그램 같은 앱을 만들고 싶어요. 그런데 이제 특정 직업인들만 쓰는 거죠."
PM: "물론 가능합니다! 릴스 기능은 기본으로 넣을 수 있고, DM 기능에 AI 챗봇까지 넣을 수 있습니다. 과업 기간은 이 정도로 산정할 거구요." (과잉 약속)
클라이언트 속마음: "말은 청산유수인데... 저걸 다 하는데 이 견적이 맞나?" (의심 상승) → 계약 포기.

영업사원 유형은 언제나 예스를 남발합니다. 하지만 구체적인 실현 방안이 빠져있는 예스는 오히려 고객의 의심만 살 뿐입니다.

유형 3: 파트너(The Partner)

클라이언트: "인스타그램 같은 앱을 만들고 싶어요. 그런데 이제 특정 직업인들만 쓰는 거죠."
개발자/PM: "네, 알겠습니다. 인스타그램은 기능이 정말 많은데요. 혹시 대표님이 가장 구현하고 싶은 핵심 기능, 딱 하나만 꼽자면 무엇일까요? 1) 사진 공유 피드, 2) 릴스 같은 숏폼, 3) DM 기능 중 어떤 것인가요?" (기획 질문)
클라이언트 속마음: "아, 이 사람은 내 아이디어를 구체화하려고 노력하네." (1차 신뢰)
개발자/PM: "만약 사진 공유 피드가 핵심이라면, 유저는 가입하자마자 어떤 화면을 보게 될까요? 다른 사람의 사진일까요, 아니면 사진을 올리는 버튼일까요? 혹시 생각해 두신 게 없다면, 제 생각에는 다른 사람의 사진부터 올리고 그 다음 화면을 업로드 버튼으로 만드는 게 좋을 것 같습니다. 왜냐하면~" (심층 질문 및 전문적 견해 피력)
클라이언트 속마음: "아, 내 아이디어가 아직 모호했었구나. 이런 게 다 필요한 거였네. 이 사람이랑 일하면 되겠다." (신뢰감 상승) → 계약.

고객은 기술을 사는 것이 아니라 내 문제의 해결책을 삽니다. 그리고 그 해결책을 함께 만들어갈 신뢰할 수 있는 파트너를 삽니다. 기획 역량은 이 단계에서 고객의 불안감을 해소하고 신뢰를 심어주는 가장 강력한 영업 역량입니다.

클라이언트와의 계약 수주를 성공시키기 위하여 우리는 어떻게 해야 할까? <출처: 작가, ChatGPT 생성>

공짜 노동을 유료 계약으로 바꾸는 간단한 기획서

저희가 제안하는, 파트너형 개발자가 되어 고객 수주율을 높일 수 있는 핵심 도구는 바로 간단한 기획서입니다. 상담 단계는 개발 단계가 아니라 영업 단계입니다. 이 단계에서 고객의 불안감을 해소하고 신뢰를 주기 위해서는, 견적서 외에도 추가적인 분명한 결과물을 제시해야 합니다. 저희는 이 결과물을 보통 간단한 기획서를 클라이언트에게 제공하고 있습니다.

여기서 말하는 간단한 기획서란, 당연히 모든 화면을 정의하고 상세 정책을 설명하는 80페이지짜리 두꺼운 기획서가 아닙니다. 미팅 내용을 바탕으로 개발자가 클라이언트의 아이디어를 어떻게 이해하고 구체화했는지 보여주는 핵심 요약본입니다. 이 문서는 빠르면 미팅 후 24시간 이내, 늦어도 48시간 이내에 보내는 것이 좋습니다.

간단한 기획서의 4가지 핵심 구성

말씀드렸듯이, 간단한 기획서에는 진짜 기획서처럼 모든 내용이 다 들어갈 필요는 없습니다. 저희는 계약 성사 전에 제출하는 기획서에는 다음과 같은 핵심 내용만을 포함하여 작성합니다.

1. 프로젝트 정의 (PRD): 우리가 만들 것은 무엇인가?

이것은 프로젝트의 북극성입니다. "인스타그램 같은 앱"이 아니라, "모바일 환경에 익숙한 20대에서 40대 부동산 중개인들을 타겟으로, 사진을 바탕으로 동네 소식을 공유하고 소통하는 커뮤니티"처럼 명확하게 하는 거죠. 클라이언트의 요구사항을 이렇게 명확하게 정리함으로써 클라이언트의 신뢰를 얻을 수 있습니다.

2. 핵심 기능 명세서 (MVP): 무엇이 들어가야 하는가?

최종 제품에 포함될 모든 기능을 나열하는 것이 아닙니다. 최소한 고객과의 미팅에서 고객이 언급한 핵심 기능들과, 그리고 몇 가지 제안들을 포함하면 좋습니다. 저희는 보통 이 단계에서 MoSCoW 기법을 참고합니다.

Must-Have(필수): (예: 소셜 로그인, 사진 피드, 댓글/좋아요) - 이것 없이는 서비스가 성립하지 않음.
Should-Have(권장): (예: 마이페이지, 해시태그 검색) - 중요하지만, 1차 오픈에서 빠져도 됨.
Could-Have(고려): (예: DM 기능, 릴스) - 2차 고도화 대상.

이 분류만으로도 고객은 자신의 아이디어가 정리되는 느낌을 받습니다.

3. 정보 구조도 (IA): 어떻게 작동하는가?

메뉴들의 구조를 한눈에 보이도록 표현한 정보 구조도 <출처: 작가, 매니패스트로 제작>

Figma나 Sketch로 거창한 와이어 프레임을 그릴 필요 없습니다. 고객은 그 화면이 예쁜지 아닌지에만 집중하게 되어 본질을 놓칠 수 있습니다. 대신, 간단한 텍스트를 이용해 메뉴 구조와 사용자의 핵심 동선을 보여줍니다.

1. 홈 (피드 목록)

1-1. 피드 상세 (댓글)

2. 업로드

3. 검색(해시태그)

4. 마이페이지

4-1. 내가 쓴 글

4-2. 설정

이것만으로도 클라이언트는 자신이 의뢰한 프로젝트가 성공했을 때 받게 될 결과를 훨씬 구체적으로 상상할 수 있게 되었습니다. 고객이 그 결과를 상상하게 했다면, 계약은 한 걸음 더 다가왔습니다.

4. 기능 기반 개략 견적(The How Much): 그래서 얼마인가?

이것이 핵심입니다. "총 2,000만 원"이라는 총액 견적(Lump Sum)은 고객에게 블랙박스처럼 느껴집니다. 대신, 2번에서 정의한 핵심 기능을 기반으로 견적을 제시합니다.

소셜 로그인: 100만 원
사진 피드 (읽기/쓰기): 300만 원
댓글/좋아요: 200만 원
마이페이지: 100만 원

총계: 700만 원

이 1페이지 기획서를 견적서와 함께 보내야 합니다. 이 문서는 클라이언트에게 "나는 당신의 아이디어를 이만큼 구체화했다"는 강력한 증거이자, 당신이 코더가 아닌 파트너라는 증명입니다. 이 문서를 얼마나 빠르고 정확하게 만들 수 있는지가, 프리랜서 개발자의 비청구시간을 줄이고 수주율을 높이는 핵심 역량입니다.

명료한 기획력이 가져오는 3가지 금전적 이득

이렇게 명료한 기획서를 빠르게 작성할 수 있는 기획력은 단지 수주율만 높이는 데 그치지 않습니다. 실제 프로젝트가 시작된 후에도 개발자의 수익성을 극대화하는 3가지 강력한 이득을 가져다줍니다.

이득 1: 가격 흥정이 기능 협상이 됩니다(수주율 증가)

Before(기획서 없음): "총 2,000만 원입니다." → (클라이언트) "너무 비싸네요. 1,800에 맞춰주세요." → "아... 그러면 이번에는 1,800으로 맞춰드릴게요." (출혈 경쟁 시작)
After(기획서 있음): "총 2,000만 원입니다. 세부 사항은 기획서를 참고해 주세요." → (클라이언트) "너무 비싼데, 1,800은 안되나요?” -> “아, 그러면 댓글/좋아요 기능 구현이 200만 원인데, 일단 이걸 빼고 1차 오픈하고 반응을 보고 추가하면 어떨까요?" (구체적이고 건강한 협상 시작)

기획서는 견적의 근거가 되어 신뢰를 줍니다. 클라이언트는 더 이상 뜬구름 잡는 비용이 아니라, 기능 단위로 명확하게 예산을 조율할 수 있게 됩니다. 이는 개발자의 전문성을 높이고 불필요한 가격 할인을 막아줍니다.

이득 2: 재작업이 추가 계약이 됩니다(수익률 증가)

프로젝트 관리의 가장 큰 재앙은 스코프 크립(Scope Creep), 즉 정해진 범위를 넘어서는 추가 요구사항입니다. 프로젝트 관리 협회(PMI)의 2021년 보고서(Pulse of the Profession)에 따르면, 프로젝트의 34%가 스코프 크립을 경험했다고 합니다. SI에서 일해보시거나 프리랜서로 일해보신 분이라면 다들 경험해 보셨을 겁니다. 물론 어느 정도는 당연히 감수해야 할 부분이지만, 마주할 때마다 스트레스를 만드는 일이죠.

프로젝트의 34%는 스코프 크립을 겪는다. <출처: PMI 보고서>

가장 간단한 예시로, 이런 상황을 생각해 볼 수 있습니다. 프로젝트가 한창 진행 중일 때, 클라이언트의 슬랙이 오는 거죠. "아, K님. 저희 내부에서 논의하다가 결정된 건데, 제품 마케팅 방안으로 추천인 제도가 결정됐거든요. 혹시 회원가입할 때 추천인 코드도 입력하게 해주실 수 있나요? 간단한 수정 같은데."

Before (기획서 없음): "아... 네. 그런데 그 기능까지 구현하려면 일정이 조금 밀릴 수 있는데요..." (간단하지 않은 공짜 재작업 시작, 수익률 하락, 스트레스 증가)
After (기획서 있음): "네, 좋은 기능이네요. 다만 미팅 때 합의했던 기획서를 기준으로 보면, 추천인 코드는 견적 외 추가 작업 항목입니다. 해당 기능이 들어가려면 개발 공수 3일, 추가 견적 200만 원이 발생합니다. 계약서 추가로 진행해 드릴까요?" (유료 추가 계약, 수익률 방어)

이렇듯 업무의 시작부터 명료하게 작성한 기획서는 프로젝트의 범위를 지키는 명확한 스코프 쉴드(Scope Shield)이자 프로젝트의 기준이 됩니다. 감정적인 거절이 아닌, 객관적인 자료에 기반한 비즈니스 협의가 가능해집니다.

이득 3: 고객이 팬이 됩니다(LTV 증가)

명료한 기획으로 소통하고 약속한 범위 내에서 퀄리티를 지키는 개발자는 단순 용역이 아니라 신뢰할 수 있는 파트너로 격상됩니다. 클라이언트는 "이 사람과는 말이 통한다", "이 사람은 내 비즈니스를 함께 고민해 준다"고 느끼게 됩니다.

이런 개발자는 자연스럽게 이 고객으로부터 다음 프로젝트를 맡게 되거나, 유지보수 및 추가 작업 계약을 통해 안정적인 고정 수익을 확보하게 됩니다. 이는 프리랜서의 가장 큰 고민인 수입의 불안정성을 해소하는 핵심 열쇠입니다. 고객 한 명의 생애 가치(LTV)가 극대화되는 것입니다.

수익률 증가, 모든 SI와 프리랜서의 꿈이자 목표이다. <출처: 작가, ChatGPT 생성>

결론: 코딩 속도가 아닌 기획력이 몸값을 결정한다

GitHub Copilot, Claude 같은 AI 코딩 툴이 코딩 자체의 장벽을 크게 낮추었다는 것은 이제 주지의 사실입니다.McKinsey의 2024년 연구에 따르면, 생성형 AI는 소프트웨어 엔지니어링의 생산성을 과거의 어떤 발전보다 크게 향상시켜, 개발자 생산성을 35%에서 45%까지 높일 수 있다고 추정합니다. 이는 코딩 속도만으로는 더 이상 차별화하기 어려운 시대가 오고 있음을 의미합니다. AI는 매우 빠르고 유능하지만, 무엇을 만들어야 하는지는 스스로 결정하지 못하는 유능한 인턴과 같습니다.

미래의 프리랜서 개발자, 혹은 외주사의 몸값(시급)은 얼마나 빨리 만드느냐가 아니라, "얼마나 정확하게 문제를 정의하고 기획하느냐"가 결정하게 될 것입니다. 당신의 기획력이 AI에게 줄 수 있는 프롬프트의 질을 결정하기 때문입니다.

당신의 7시간짜리 공짜 노동을 700만 원짜리 유료 계약으로 바꾸는 힘은, 화려한 코딩 스킬이 아닌 명료한 기획서를 작성할 수 있는 능력에서 나옵니다. 프리랜서로 일하고 계시거나 SI를 운영하고 계시다면, 혹은 부업으로 외주 일을 맡아볼까 생각하고 계시다면, 어떻게 나의 기획 역량을 끌어올릴 수 있을지 생각해 보시는 건 어떨까요?

<참고>

manyfast.io/blog

]]>

60대까지 현역, 40년간 개발자로 살아남은 비결

프리랜서 개발자 인터뷰 ① 60대까지 현역, 40년간 개발자로 살아남은 비결

1980년 세운상가에서 애플2를 보고 급여를 털어 컴퓨터를 샀던 20대 청년이 60대가 된 지금까지 개발자로 살아남았습니다. 30년 개발자 생활 동안 대기업 부장에서 사업가를 거쳤고, 현재는 10년째 프리랜서 활동을 하고 있는 40년 경력의 개발자 진광헌 님인데요. 빠르게 변하는 IT 업계에서 40년간 어떻게 생존해왔을까요?

CAD부터 웹개발, 임베디드, AI까지 폭넓은 기술 스택을 보유하고, "남들이 잘 안 하는 것, 어려워하는 것, 금액이 높은 것"을 골라서 프로젝트를 수행하는 진광헌님. 60대가 된 지금은 해류 발전기로 에너지 문제를 해결하고, AI와 휴머노이드를 결합한 농업 자동화를 꿈꾸며 여전히 지치지 않고 사회에 기여할 방법을 고민하고 있습니다.

60대까지 개발자로 살아남은 그의 생존 전략을 들어봤습니다.

진광헌 개발자

40년간 빠르게 변하는 기술 트렌드, 어떻게 따라 잡았나

Q. 간단한 자기소개와 함께 어떤 개발자 인생을 걸어오셨는지 들려주세요.

진광헌이라고 합니다. 40년간 개발자로 활동해왔어요. 대기업인 대림그룹에서 부장까지 올라갔고, Microsoft와 공동 비즈니스로 매출에 기여해서 MS에서 해외여행을 보내주기도 했죠. 퇴사 후에는 국내 최초 안정기 없는 LED조명등을 개발해서 개인 사업을 했지만 실패했고, 그 후 약 10년간 프리랜서로 활동하고 있습니다. 현재는 기본소득당에서 기본소득 재원을 마련하는 것과 관련한 활동을 하고 있어요.

Q. 40년간 개발 트렌드가 엄청 빠르게 변했는데, CAD, 웹, 임베디드, AI 등 정말 다양한 기술을 습득하셨어요. 어떻게 계속 따라 잡으셨나요?

궁금함이 병인 것 같아요. 호기심을 충족하기 위해서 프로젝트를 수행할 때마다 지속적으로 공부하고 학습하다 보니 어느덧 여러 가지를 하게 되었어요.

임베디드는 AI + 휴머노이드의 시대가 될 것으로 판단되어서 MCU부터 다양한 주변장치들을 연계 연동하다 보니 익히게 됐어요. 캐드는 2D 사내 강사부터 시작해서 취미로 3D와 로봇 관절에 사용되는 기어 등을 공부하고 설계하고 제작까지 하다 보니 자연스럽게 습득하게 되죠.

최근엔 LLM의 트랜스포머 구조, 인코더·디코더 파라미터 조정까지 직접 학습해봤습니다. 장비 한계 때문에 깊게는 못 갔지만, 필요한 만큼은 익혔습니다. 필요하거나 흥미 있는 기술을 공부하다 보니 어느새 폭넓게 다루게 됐습니다.

Q. 개발은 어떻게 시작하게 되셨나요?

A. 1980년쯤 세운상가를 구경하다가 애플 II를 처음 봤습니다. 화면에 글자가 뜨고 사람이 키보드로 입력하면 기계가 대답하는 게 너무 신기했죠. “저게 세상을 바꾸겠다”는 생각이 들어서 급여를 털어 애플 II와 확장 카드를 구입했습니다. 그때부터 BASIC 언어로 프로그램을 짜기 시작했고, 이 호기심이 결국 지금까지 이어지고 있습니다.

이후 숭실대학교에 다니며 본격적으로 컴퓨터 구조와 원리를 공부했고, 관련 자격증도 취득했습니다. 당시에는 컴퓨터를 다룰 줄 아는 사람이 드물어서, 회사에서도 “컴퓨터 좀 안다”는 이유만으로 기획실이나 3D CAD 실로 불려가 일을 맡게 됐습니다. 그렇게 실무에서 CAD와 플랜트 설계를 다루면서 자연스럽게 개발자의 길을 걷게 됐습니다.

처음 구입했던 apple II 컴퓨터

다양한 기술 스펙트럼, 쓸 수 있는 ‘칼’이 많다

프리랜서로 전향한 뒤, 진광헌 님은 뚜렷한 원칙을 세웠습니다. 바로 “남들이 기피하는 프로젝트를 고른다”는 것입니다. 그는 “어렵고 단가가 높은 일일수록 경쟁자가 적다”며, 오히려 그런 프로젝트가 자신을 성장시키는 기회가 됐다고 말합니다. 또 그는 ‘전문성’을 기준으로 프로젝트를 고르지 않습니다. 다양한 기술을 다룰 수 있는 만큼 다양한 프로젝트에 도전하고 있죠.

Q. 프리랜서는 어떻게 시작하게 되셨나요?

LED 조명 사업이 실패한 뒤에 프리랜서로 전환하게 됐습니다. 그 LED조명 사업이 실패한 이유가 좀 재밌어요. 당시 형광등 안정기 제조사가 250개사 정도 되는데, 수명이 길고 전력 소모가 적고 가격이 저렴한 제품이 시장에 나오면 250개 사가 문을 닫아야 되는 상황 이었거든요. 그래서 안전 인증을 내주지 않았죠. 시장 진입 시기를 놓쳐서 실패한 거예요.

회사도 30년 다녔고, 돈도 벌면서 이전에 쌓아온 능력을 활용하려고 프리랜서로 활동하고 있습니다.

Q. 많은 개발자들이 프리랜서로서 특정 기술을 깊게 파야 할지, 여러 기술을 폭넓게 배워야 할지 고민이 많습니다. 프리랜서로는 10년 정도 되셨는데, 그런 고민은 없으셨나요?

저는 여러 가지를 할 수 있다 보니까 선택할 수 있는 폭이 넓어요. 요리사로 따지면 여러 개의 칼 중에 어떤 칼을 쓸지 선택하는 것이죠.

웹과 캐드는 본질적으로 다르지 않다고 생각해요. 웹은 서버 한대 놓고 백엔드로 다른 서버들 엮어 가지고 화면에 보이도록 하는 게 웹이잖아요. 캐드는 2차원이든 3차원이든 설계를 해서 컴퓨터로 설계를 한 거를 직접 만든다든지 그런데 사용하는 거고요. 결국은 임베디드 같은 것도 MCU* 안에 프로그램을 집어넣지만 결국 그것도 그냥 프로그램이잖아요.

저는 그저 그때그때 필요하거나 궁금한 걸 배우고 적용했습니다.

*MCU(Microcontroller Unit): 로봇·IoT 기기에 쓰이는 소형 제어용 칩

Q. 주로 어떤 프로젝트를 하시나요? 프로젝트 선택하실 때 기준이 있으시다면요?

"남들이 잘 안 하는 거, 어려워하는 거, 금액이 높은 거"를 선택해요. 선택에 있어서 이기적인 선택보다, 이타적인 선택을 우선하기로 스스로에게 맹세한 이후 이런 기준을 갖게 되었어요.

구체적으로는, 프로젝트의 내용을 보면 여러 가지 기술을 써야 하는 케이스들이 있어요. 한두 가지 기술이 아니고 굉장히 혼자서 여러 가지 기술을 많이 해야 되는 케이스들 말이죠. 내용을 딱 읽어 보면 "아 이게 이 기간 안에 끝날 수 있을까?" 도저히 불가능할 것 같은 느낌이 드는 것들이에요. 개발자의 느낌이나 직감에 따라 구별하고, 공고 내용이 간결하거나 정리된 공고 내용에 따라 판단해요.

남들이 다 하는 거 보면 재미가 좀 없잖아요? 남들이 못하는 걸 하면 뭔가 뿌듯하기도 하고요.

Q. 그렇게 다양한 기술을 하시면 포트폴리오는 어떻게 관리하세요?

A4 30장 분량 되는 문서에 다 기록하고 있어요. 프로젝트뿐만 아니라 본인이 취미로 만들거나 개발한 것이 있으면 화면과 코드 설명 등을 시기와 순서별로 작성해서 디스크와 클라우드에 같이 보관 관리해요. 나중에 고객들이 보시고 "이거 할 줄 아냐?"하고 물어보시면 "할 줄 안다"라고 얘기하고, 그러면 "이럴 때 어떻게 하냐?"하면서 물어보면 답변도 해주기도 하죠. 여러 가지를 할 수 있다 보니까 여러 개의 칼 중에 어떤 칼을 쓸지 선택하는 거라고 생각해요.

Q. 문제 해결 방식에서 "계속 고민하고 생각하는 것이 제일 중요하다"고 하셨는데, 구체적으로 어떤 방식인가요?

문제 해결을 위해서 "이것이 가장 좋은 방법인가"를 계속 고민하다 보면 짧으면 2~3일 내에 좋은 해결책이 떠올라요. 주로 출퇴근 또는 점심시간에 떠오르는 경우가 많아요.

계속 생각하고 고민하는 것이 제일 중요해요. 그 문제를 위해서 계속 생각하고 고민하면 그러다 보면 좋은 아이디어도 떠오르게 되고, 그냥 어디 책에서 찾고 이런 것도 되게 좋은 방법이긴 한데 책에서뿐만이 아니고 계속 고민하다 보면 더 좋은 아이디어나 코드들이 나오게 되죠.

AI 시대 적응 전략과 미래 대비

Q. 커서(Cursor) 같은 AI 도구를 적극 활용하고 계신다고 들었어요. 프리랜서 개발자는 AI 시대를 어떻게 살아가야 할까요?

커서뿐 아니라 제미나이를 비롯해서 2~3개를 사용해요. 지금은 AI가 일정 부분 코드도 많이 만들어주고 제가 생각하는 것 이상으로도 할 때도 있고 전혀 못 할 때도 있거든요.

그래서 지금은 코드도, 프로젝트도 1인 다역해서 가능한 시대가 왔구나 하는 느낌이에요. 내가 그 분야에 대해서 깊이 잘 모르더라도 AI하고 같이 하면서 전체 프로젝트를 네다섯 명 걸려서 만들 걸 한 사람이 다 만들 수 있는 세상이 왔어요.

향후에는 AI가 거의 모든 부분들을 대체할 걸로 예상이 되거든요. 코딩도 마찬가지 입니다, 하지만 제일 중요한 건, 해외에 있는 것만 쫓아서 하다 보면 나중에 진짜 뭔가 더 좋은 걸 못 만들어낸다는 점이에요.

Q. AI가 거의 모든 부분을 대체할 거라고 하시면서도, 새로운 기술을 맹목적으로 따라가지 말라고 조언하셨는데요. 이 두 관점을 어떻게 조화 시키시나요?

새로운 기술이 나왔을 때 그 기술에 대해서만 맹목적으로 쫓아가지 말고 그것보다 더 좋은 것을 만들 수 있는지, 어떻게 하면 그것보다 더 좋게 만들 수 있을 것을 고민을 항상 했으면 좋겠어요.고민하다 보면 더욱 상세히 배우고 학습과 응용이 가능할 수 있도록 깊게 공부하게 되거든요.

AI를 적극 활용하면 키보드 앞에서 바로 답을 얻을 수 있는 시대니까, 이걸 잘 활용하는 것도 중요해요. 하지만 근본적인 사고와 고민은 여전히 사람이 해야 한다고 생각해요.

후배 개발자들에게 전하는 생존 조언

Q. 요즘엔 어떤 도전을 하고 계시나요?

A. 지금은 해류 발전기를 직접 설계·제작하고 있습니다. 공업계 고등학생 때부터의 평생 꿈이었어요. 다음 세대가 화석연료 없이 무한히 쓸 수 있는 에너지원을 만들고 싶었습니다. 해류 발전기는 풍력보다 830배 에너지를 더 생산할 수 있고, 저속의 해류 흐름에서도 발전이 가능합니다. 태양광·풍력보다 발전 시간이 길고 안정적으로 전기를 생산할 수 있어 가성비가 뛰어나다고 생각합니다. 성능 평가 후 에너지기술평가원에 기술 심사를 의뢰할 예정입니다.

또 하나는 농업 자동화 프로젝트입니다. 앞으로 10년이면 70~80대 어르신 농가가 80% 은퇴하고, 나머지 20% 농가가 4천800만 인구를 먹여 살려야 합니다. 그래서 ROS, LLM, 휴머노이드를 결합해 농사에 활용하고 학습시켜 투입하려 합니다. 내년에는 OpenCV로 yolo 등을 사용 동영상에서 여러 프레임 내부의 객체를 추적·추출해 데이터를 MariaDB의 Vector TABLE 기능(최근 지원 됨)으로 DB화하고, 이를 학습 데이터로 활용할 계획입니다.

Q. 지금 20-40대가 60대까지 개발자로 살려면 어떤 준비가 필요할까요?

노동 소멸과 수명 연장 시대에는 다양한 경험을 해보는 것이 중요하다고 생각합합니다. 현재의 AI는 전기 잡아먹은 하마예요. 하지만 인간은 밥 세 끼면 창조적 활동과 움직임과 개발 등이 모두 가능한 극강의 효율적인 지능을 가진 개발자죠.

AI + 휴머노이드 분야의 경우 아직 미개척 분야고, 초보적인 수준의 휴머노이드가 시장에 진입된 상태입니다. 현재 AI + 휴머노이드가 미숙하게 노동을 대체하며 앞으로 20~30년 동안은 성숙기에 접어들 것입니다.

지금 20~40대라면, LLM의 트랜스포머 알고리즘과 ROS*, 펌웨어(F/W)를 활용해 MCU로 로봇의 움직임을 제어하는 방법, 그리고 백엔드를 통해 로봇이 주변 환경을 인지하고 다음 행동을 결정하도록 하는 과정에서 OpenCV를 이용해 객체를 추출·추적하는 기계학습 지식 정도는 갖출 필요가 있다고 생각합니다.

*ROS(Robot Operating System): 로봇 제어용 오픈소스 프레임워크

Q. 언제까지 일할 계획이세요? 은퇴에 대한 생각은 어떤가요?

2~3년 이후 완전 은퇴 하고, 직장 생활 하느라 못해본 것들 하며 살 생각입니다. 은퇴 이후에도 경제적 수입에 상관 없이 많은 사람에게 도움이 되는 생산적인 활동은 계속 할 생각입니다.

Q. 마지막으로 후배 프리랜서 개발자들에게 조언을 해주신다면요?

이기적인 선택보다 이타적인 선택을 우선하라고 말하고 싶어요. 노동 소멸 시대와 수명 연장 시대를 살아가야 하는데, 그런 시대에는 이기심 보다 이타심이 중요하다고 생각하거든요. 저도 늘 돈보다 가장 좋은 선택, 즉 이타적인 선택을 할 수 있으면 좋겠어요.

그리고 끈기가 정말 중요해요. 프로젝트를 할 때도 끈기와 독기가 없이 중간에 포기하거나 단념하는 경우를 많이 봐요. 조금만 더 인내하면 좋은 결과가 눈앞에 보이는데 그걸 못 참는 경우가 많아 안타깝죠. 저는 어려운 프로젝트에서 포기하고 싶을 때 잠시 숨 돌리고 맛있는 음식을 보충하거나 음악 들으면서 쉬고 난 뒤 재도전해요. 숨 좀 돌리고 어려운 걸 버텨내는 끈기를 가져보면 좋겠어요. 프리랜서로서 살아남기 위해 가장 중요한 건 노력과 솔직함 그리고 헌신이거든요.

프리랜서 개발자로서 자신만의 노하우를 들려주실 분은 아래 그림을 눌러 신청해주세요!

]]>

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

SI 산업 가이드북 ⑯

우리는 AI를 어떻게 쓸 것인가?

이건 조금 늦게 따라가는 회사와 사람들을 위한 글이다.

사실 결론은 나왔다.

“인간 vs 인공지능”, 이렇게 생각하면 옛날 사람이다. 요즘은 다 이렇게 생각한다.

“인공지능을 쓰는 나 vs 인공지능을 쓰지 않는 나”

그리고, 당연히 “인공지능을 쓰는 나”가 더 우수하다.

다만 주제를 회사로 옮기면 조금 복잡해진다.

건설로 치면 부품 규격과 공법이 아예 바뀌어버렸기 때문이다.

그런데 이 모든 것을 이끌어야 할 사장님조차 모르는 것 투성이다. 원가 계산도 안 되고 기간 예측도 안 된다. 어디에 얼마나 투자해야할지도 모르겠다. 낭패다.

개발자들도 난처하다. 좋은 건 알겠다. 하지만 그래서 어떻게 해야하지? 모르겠다. 정말 모르겠다.

그래서 오늘은 이 변화를 이해하고 적응하기 위한 이야기를 해보고자 한다.

어떻게 일해야 할까?

챗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)들도 헤매고 있다. 그래서 시간이 조금 더 있다.

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

]]>

국내 ERP는 왜 SAP 아니면 더존일까?

ERP 시리즈

① 그래서 정말로 “ERP”란 뭔가요?
② 국내 ERP는 왜 SAP 아니면 더존일까?

ERP(Enterprise Resource Planning).

저는 10년 넘게 ERP를 써왔습니다. 컨설턴트로, 때로는 경영 분석가로 일하면서 ERP에 대한 이해도가 상당히 높은 편이라고 자부합니다. 그렇게 10년 동안 사용자로 쌓아온 ERP의 개념과 소프트웨어에 대한 이해를 바탕으로 관련 주제들을 자세히 다뤄보고 있습니다.

앞선 글에서는 흔히들 헷갈리는 ERP의 개념과 발전을 쉽게 살펴보았는데요. 이번에는 조금 더 구체적으로 들어가 ERP라는 시장에서 활동하는 주요 벤더(공급업체)와 국내 시장의 이야기를 해보려고 합니다.

미리보기

뻔한 개념 정의 말고, 그래서 정말로 ‘ERP’는 뭡니까?
‘ERP를 사용한다는 것’은 어떤 모습일까?
우리나라에서 ERP는 어떻게 발전해 왔나?
ERP 벤더별 시장 점유율과 반응은? SAP vs. 오라클 vs. 더존
비싸거나 폐쇄적이거나. 국내 ERP에는 대안이 없을까?

ERP 벤더별 시장 점유율과 반응은? SAP vs. 오라클 vs. 더존

앞선 글의 역사 챕터에서 언급했던, 자재 관리 중심의 MRP(Material Resource Planning). 이를 넘어 회사의 각 기능이 협업하는 ‘규칙’이라는 관점에서 ERP 벤더들은 시장에서 어떻게 활동하고 있을까요?

최신의 정확한 시장 점유율 데이터를 얻는 것이 쉽지 않아, 2022년 한국 IDC 자료를 기준으로 살펴보겠습니다. IDC에 따르면 SAP가 21%로 1위, 그다음으로 더존비즈온(16.8%), 영림원소프트랩(6.1%), 오라클(4%) 순입니다. 물론 현재 시점에서도 시장점유율이 큰 폭으로 바뀌거나, 순위가 뒤집히지는 않은 듯합니다.

이번 글에서는 ERP의 특성을 아는 것이 중요한 만큼 시장점유율이 큰 SAP와 오라클, 더존을 중심으로 살펴보고자 합니다. 후반부에는 오픈소스 기반의 개방형 생태계를 갖춘 Odoo(오두)에 대해서도 이야기 해볼 예정이고요. 또한, 가격, 기능, 기술, 혁신성처럼 보다 세부적인 벤더 평가(Vendor Scoring)를 하면 규모가 너무 커져 정성적으로 다루겠습니다.

이제부터 알아볼 것은 ERP를 더욱 쉽고 친숙하게 인식하도록 만들 목적은 아닙니다. 지금의 ERP 소프트웨어들은 너무 비쌉니다. 전자결재, 프로젝트 및 작업 관리, BI/DW 등 기능까지 ERP 범위가 확장되어 있고, 실제로 우리 회사에서는 사용하지 않는 기능과 모듈이 너무 많습니다. 만약 진정한 ‘Pay-as-you-go’ 모델로 간다면 ERP는 더 이상 비싸지 않아도 될 것입니다. (물론 모든 기능을 사용하는 회사에게는 규모의 경제가 동작하는 지금이 더 경제적이겠지만요.)

SAP

SAP는 2015년 Fiori라는 웹과 앱 디자인 시스템을 출시하기 전까지는, 아래처럼 ‘뿌연’ UI를 제공했습니다.

<출처: SAP Community>

그러나 당시에도 SAP의 국내 시장점유율은 20%를 넘었습니다. SAP를 쓰는 이유가 이런 회색조의 칙칙한 화면 때문이 아니란 뜻이죠.

이는 결국 독일 박사급 인재 200명이 들어가 R&D를 했다는 말이 떠돌 만큼, 철저한 구조적 완성도를 자랑했기 때문입니다. SAP에는 모든 트랜잭션(거래) 데이터와 마스터 데이터가 체계적으로 구성되며, 정보가 집계되는 최상위 기능인 경영관리/관리회계(Controlling) 오브젝트로 취합되게끔 모듈 간의 실시간 통합이 완결성 높게 구현되어 있죠.

또한 MRP로 시작한 만큼, 영업, 물류, 생산, 재고 등의 SCM(Supply Chain Management) 영역이 재무 및 경영관리 영역과 완벽히 통합되는 구조 역시 근본적인 강점입니다. 여기에 비즈니스 앱에 최적화된 개발 플랫폼, CTS/TMS 형상관리 시스템, 높은 수준의 정의(Configuration)가 가능한 기본 앱의 수준, 기존 소스코드를 강화할 수 있는 USER-EXIT 등 프레임워크까지 제공합니다. (심지어 소스코드 수정(Modification)도 지원은 합니다만, 여기까지 갔다면 뭔가 기획이나 설계가 잘못된 거겠죠)

화면은 말 그대로 구리지만, 소프트웨어의 철학과 완성도가 많이 앞서 있는 것입니다.

오라클(Oracle)

한편 글로벌 벤더 가운데 국내 점유율 2위였던 오라클은 어떨까요?

오라클하면 전통적으로 DBMS(Database Management System)를 취급하며, 미국을 중심으로 금융/재무(Finance) 영역의 강자입니다. 다만, MRP가 중심이 아니라 재무 관점의 통합을 우선하다 보니 모듈 간 실시간, 즉, 강력한 통합을 제공하는 SAP와 접근 자체가 달랐죠. 그 대신 느슨(Loosely Coupled)하면서 유연한 통합을 지향합니다.

그러다 보니 산업 불문하고 유연하게 이것저것 다 붙이고 통합할 수는 있었는데요, 우리나라에서는 이런 지향이 큰 약점이었다고 봅니다. 삼성전자와 삼성그룹을 필두로 SAP는 전문 개발사와 프리랜서의 생태계가 자연스럽게 조성되었습니다. 반면 오라클은 여전히 ERP를 구축하거나 유지보수 할 파트너의 풀이 확연하게 적습니다. 그래서, 이런 유연함을 보완해 줘야 하는 통합 구축(Integration) 리소스의 질과 양이 부족한 국내 시장에서는 점차 도태되고 있죠.

참고로, ERP를 도입할 때 벤더가 직접 구축에 참여하는 경우는 아주 드뭅니다. 특히 글로벌 ERP 벤더의 국내 지사들은 거의 영업과 GTM(Go-to-Market) 중심으로, 기술지원 관련 역량은 일부만 보유하고 있습니다. 그래서 제안서나 제안 PT는 벤더사가 주도하되, 구축에는 개발사가 함께 참여하는 게 일반적인 모습입니다.

더존비즈온

이제 더존으로 넘어가볼까요? 국산 ERP 벤더 중 1위인 더존은 특히 중소 및 중견기업 중심으로 압도적인 고객 수를 확보하고 있습니다. 매출 5천억 원 이상이거나 제조업 중심인 중견기업 이상이 아니라면 SAP를 사용하기에는 부담스러우니까요. (물론 SAP도 ByDesign이나 Business One 제품군이 있지만요.)

더존과 SAP의 가장 큰 차이는 뭘까요? 더존은 2024년 매출액 4,023억 원, SAP는 약 49.6조 원 정도로 매출 규모가 123배 차이 난다는 점일까요? 이는 결과이자 현상일 뿐입니다.

SAP는 각 모듈을 실시간으로 연결하고 통합하는 아키텍처를 기획하고 설계하는 데에 천문학적인 투자를 했죠. 이 구조는 20년 가까이 지난 현재에도 변함없이 활용할 수 있습니다. MRP의 진화 과정에서 국내 대기업과 혁신을 함께하기도 했습니다.

반면, 더존의 ERP에는 ‘변하지 않는 진리’ 같은 설계 철학이 녹아있지는 않습니다. 어떤 부분은 고객사의 요청에 따라, 어떤 부분은 SAP 등 레퍼런스를 참고하면서 개선해 왔죠. 그래서 SAP와 비교했을 때, 더존은 구조적으로 어렵다고 표현하는 경우가 종종 있습니다. 어떻게든 되기는 되는데, 구조적으로 준비가 안 되어 있으니까 결국 커스터마이징(맞춤형 개발, Customizing)과 후속 유지보수, 고도화에 돈이 더 들어간다는 거죠.

즉, 두 기업은 투자한 금액의 규모와 깊이가 다릅니다. 예상컨대 SAP가 R&D에 수십조 원을 투자했다면, 더존은 수천억 원 정도를 투자했을 겁니다. 매출 규모만큼, 그러니까 123배 정도 차이가 날 수 있겠죠. 이 100배 넘는 투자 규모 차이를 뒤집어 결과를 내는 건 정말 어려웠겠고요.

정리하면, 더존은 SAP와 비교해 상대적으로 고객의 요청과 벤치마크를 통해 점진적으로 개선해 온 솔루션입니다. 따라서 상대적으로 구조적 완성도가 낮습니다. 대신 그만큼 SAP는 비쌉니다.

비싸거나 폐쇄적이거나. 국내 ERP, 정말 대안이 없을까?

연 매출액이 5천억 원 미만이며 제조업이 아닌 국내 기업 고객들 대상으로는 이런 말을 합니다. “국내에서 대안이 있나요? 더존 쓰셔야죠.” PI 프로젝트로 베스트 프랙티스(Best Practice)를 벤치마크하고, 최대한 정교하게 설계해 구축 프로젝트를 관리하고 안정화 잘하면 그것만큼 안전하게 투자 대비 효익을 거두는 게 없으니까요.

더존과 폐쇄성

물론 더존도 파트너사를 통해 구축하는 경우가 적지 않지만, SAP나 오라클 같은 글로벌 벤더 보다 직접 개발하는 경우가 많습니다. 다만 그 역시 생각보다 많이 비싸고, 오래 걸립니다. 파트너사와 개발하는 것과 금액 측면에서도 아주 큰 차이는 아니고요.

그래도 국내 고객사 숫자가 압도적으로 많으니, 구축이나 커스터마이징을 위한 파트너 생태계가 잘 갖춰져 있지 않을까? 생각할 수도 있습니다. 아쉽지만 그렇지 않아요. 공인 파트너사 수도 많지 않고, SAP처럼 프리랜서 생태계가 조성되어 있지도 않습니다. 아마 라이센스 보호를 위한 폐쇄성이 그 원인은 아닐까 싶고요.

SAP는 프리랜서가 투입되면, 개발 경험은 거의 표준화되어 있습니다. 워크벤치(개발 도구 모음, Workbench)에서 투박하게 화면을 그리고, 로직을 짜고, T-Code라는 접속 경로를 만들어주면 끝입니다. 서버, 네트워크, DB를 복잡하게 고려할 필요가 없죠. 그리고 필요하면, SAP의 표준 어플리케이션 소스코드를 확인하고 디버깅하면서 최적의 커스터마이징을 할 수 있고 CTS(Change and Transport System)로 안전하게 형상을 변경하고 관리할 수 있습니다.

반면 더존은 어떨까요? 앞서 말한 모든 것에 제약이 있다고 보면 됩니다. SAP와 비교해 핵심 구조와 로직의 완성도가 떨어지는데, 그에 대한 접근성은 낮습니다. 자연스럽게 열린 생태계가 쉽게 조성되지 않아 구축과 유지관리에 필요한 비용도 떨어지지 않는 거죠.

그렇다면 모든 고객의 요청에 대한 솔루션을 더존이 합리적인 가격과 일정 아래 제시하고 있느냐? 그렇지 않다고 봅니다. 저를 포함해 많은 고객이 아쉬워하고, 개선되었으면 좋겠다고 생각하는 영역이죠. Amaranth 10, Omniesol 등 새로운 제품군으로 넘어오면서 가능성은 열리고 있지만, 아직 기존의 아쉬움을 완전히 해소하기에는 증명할 부분이 많아 보여요.

대안은 없을까?

SAP와 더존, 두 가지 ERP 벤더를 살펴보며 숨이 턱 막혔나요? 하나는 완성도 높지만 과한 기능으로 비용이 너무 많이 들고, 하나는 그보다는 저렴하지만 상대적으로 완성도가 낮으며 다소 폐쇄적인 생태계로 구축, 유지보수와 고도화에 어려움을 겪습니다. 그렇다면 정말 국내에는 다른 대안이 없을까요?

현실적으로, 대안이 나오기 쉽지 않습니다. ERP는 회사 내 기능 간의 규칙인데, 이 가운데 핵심 규칙은 영업/물류(SCM), 재무(Finance) 및 관리(Controlling)입니다. 이 영역을 연결하고 통합하는 흐름을 설계하고 구현하는 일은 진입장벽이 너무 높습니다. 게다가 기능별 전문 비즈니스 로직을 처리할 다른 어플리케이션과 서비스를 연동할 기술/사업 생태계도 필요하죠. 새로운 경쟁사가 나타나기 어려운 환경입니다.

이처럼 거대한 진입장벽이 있지만, 그만큼 ERP는 국내 대다수 기업의 생산성을 혁신할 중추 역할을 하고 있습니다. 기업의 인원수가 50명, 100명을 초과하고, 매출액이 50억 원을 넘어 100억, 500억 원을 돌파하며 기업의 조직과 의사결정 구조가 망가지는 것을 수없이 봤습니다.

커뮤니케이션 비용은 인원에 따라 지수적으로 늘어나고, 데이터 기반 의사결정이 아닌 개인의 감과 영향력으로 기업이 운영되기도 합니다. 결국 폭발적인 성장 가능성은 묻히고 정체되어, 그냥 기업 혹은 괜찮은 기업에 머무르고 맙니다. 위대한 기업이 될 수 있는 잠재력이 있는데도 불구하고요.

그래서 오랫동안 이런 제약을 넘어설 대안 ERP를 찾아왔습니다. 조건은 다음과 같습니다:

회사 내 기능이 협업하는 ‘규칙’이라는 최소 관점에서 과적합을 줄이고 가격 경쟁력을 확보
이미 주요 ‘규칙’에 해당하는 핵심 모듈(물류, 재무, 관리 등)이 구축되어 있음
기술, 사업적으로 개방되어 있어 다양한 전문 앱/서비스와 통합할 수 있으며 생태계 조성이 용이

Odoo(오두)

그런 고민 끝에 발견한 후보가 있습니다. 혹시 Odoo(오두)라고 들어보셨나요?

Odoo는 벨기에에 본사를 둔 오픈소스 ERP 벤더로, 기본 모듈을 확보하면서도 가격 경쟁력과 유연성을 갖춘 제품을 제공합니다. 2002년부에 창립해 전체 직원 수 6,000명, 파트너사는 16,000개 이상, 총사용자 수는 1,500만 명 수준입니다. 매출액은 2024년 기준 6억 5천 달러(약 8,450억원)로 더존 매출의 2배 정도입니다. 글로벌에서는 어느 정도 검증된 플레이어라는 뜻입니다. 더 주목할 점은 성장 속도입니다. 2024년 기준으로, 불과 6년 만에 매출이 15배 성장하며 글로벌 ERP의 주요 강자로 자리 잡은 거죠.

<출처: 작가>

이런 빠른 성장은 Odoo의 ERP가 제가 제시한 3가지 조건을 충족하기 때문이라고 봅니다.

Odoo의 제품은 라이센스당 20.4달러, 약 2.5만 원 정도로 고가의 SAP보다 훨씬 저렴합니다. 더존의 Amaranth10이나 Omniesol 제품군 보다도 경쟁력 있죠. 또한, 모듈별 추가 비용을 내는 구조가 아닌 하나의 요금제로 모든 모듈을 사용할 수 있는 점도 큰 강점입니다.

여기에 더해 회계, 영업, 제조, 재고, 인사 등 70개 이상의 공식 비즈니스 앱과 57,000개 이상의 서드파티 앱을 포함하고 있죠. 각 모듈의 기능 점수도 낮지 않습니다. 핵심은 단단하게 잡혀 있어 제조, 유통, 서비스업까지 범산업적으로 맞춤형 솔루션을 제공할 기초(Foundation)가 마련되어 있다는 뜻입니다.

마지막으로 기술, 사업 생태계도 좋습니다. 모든 소스코드가 열려 있고 필요하면 수정도 할 수 있습니다. 또한, 파이썬 기반의 개방된 구조로 외부와의 연동이나 추가 개발이 매우 원활합니다. 파트너 생태계도 인센티브나 역량 확보 측면에서 잘 설계되어 있고요.

<출처: Odoo, https://www.odoo.com/ko_KR/pricing>

즉, Odoo는 비싼 비용과 폐쇄성에 지친 한국 기업에 맞춤형으로 가성비도 괜찮고 기술적으로도 뛰어난 대안을 제시합니다.다만, 여전히 국내 ERP 시장에서의 존재감은 충분히 드러나지 않았습니다. 마스터카드(Mastercard), KPMG, 메가커피 등 다양한 산업군의 좋은 고객 사례를 보유하고 있음에도 불구하고 말이죠.

국내 ERP 시장에 몇 가지 진입장벽이 있기 때문이라고 생각하는데요. 첫 번째로 우리나라의 회계, 세무 관련 규제는 특수성이 있어서, 이에 대한 맞춤 대응은 아직 보완이 필요해 보입니다. Odoo는 국가별로 강력한 파트너 생태계를 조성하면서 극복해온 부분이라 충분히 새로운 가능성을 보여줄 수 있을 것 같아요.

(농담 섞인 개인적인 생각이지만) 두 번째 장벽은 ‘한국인이 일을 잘하는 편’이라는 데 있습니다. 기업이 일정 이상으로 커지면 작동하지 않는다 해도, 일정 수준의 기업에서 한국인은 엑셀로 모든 문제를 해결하고 카카오톡으로 깔끔하게 일을 처리합니다.

웬만하면 엑셀이 익숙하고 모든 일을 처리할 수 있으니까, “ERP는 필요 없다. 엑셀로 내려달라, 엑셀에서 하겠다”라는 주장이 나오는 거죠. 그 때문에 더존도 SAP도 프로그램이 죄다 테이블/그리드 형식인 경우가 많아요. 하지만 요즘 같은 AI 시대에, 이런 개인의 엑셀 활용 능력은 산업 경쟁력 측면에서는 오히려 독이 되기도 합니다. ERP를 비롯해 다른 소프트웨어까지 잘 활용해야 AI 시대를 이끌어 나가는 산업 경쟁력, 나아가 국가 경쟁력까지도도 확보할 수 있겠죠.

이처럼 신규 ERP가 주목받기 어려운 환경에도 불구하고, 숨막히게 ‘비싸거나 혹은 폐쇄적이거나’라는 제한된 옵션 밖에 없는 상황에서 이런 새로운, 잠재적 대안을 소개하며 가능성을 여는 것이 ERP 시장과 산업에 조금이라도 도움이 되기를 기대해 봅니다.

마치며

ERP라는 개념을 안다는 건, 우리 회사의 전결 규정을 안다는 것과 같다고 생각해요. 우리가 협업하는 대상과 규칙이 어떻게 구성되어 있는지, 혹은 전부가 아니라도 어떤 형태로 잡혀 있는지 많이 알수록 커뮤니케이션은 쉬워질 겁니다. 규칙을 통해 확보한 고품질 데이터로 소프트웨어를 도입하거나 AI를 접목시켜 업무 프로세스도 민첩하게 개선해 성과를 올릴 수 있겠죠.

이 글이 최소한 “ERP가 뭐예요?”라는 질문에 답을 줄 글이었으면 좋겠습니다. 그렇게 각자 회사에서 ERP를 포함한 소프트웨어를 잘 활용해 혁신적인 성과를 만드는 데에 조금이라도 기여가 되었으면 합니다. 긴 글 읽어주셔서 감사합니다.

]]>

그래서 정말로 “ERP”란 뭔가요?

ERP(Enterprise Resource Planning).

저는 10년 넘게 ERP를 써왔습니다. 컨설턴트로, 때로는 경영 분석가로 일하면서 ERP에 대한 이해도가 상당히 높은 편이라고 자부합니다. 그럼에도 가끔씩 누군가로부터 “그래서 ERP가 뭐예요?”라는 질문을 받으면 멈칫하고는 합니다.

누군가는 ERP를 두고 거창하게 “기업 경영의 중추(Backbone)입니다”라고 표현하기도 합니다. 다른 이는 회계 시스템, 영업/물류 관리 시스템, MRP(Material Requirements Planning), 혹은 그룹웨어 시스템으로 설명하기도 합니다.

다가온 AI 시대에도 정제된 데이터를 체계적으로 축적하고 관리하는 ERP의 중요성은 줄어들지 않을 것으로 보입니다. 그러나 ERP라는 키워드를 검색하면 나오는 거대한 정의, 그리고 ERP 벤더(공급업체)와 파트너사들이 제공하는 광고와 복잡한 설명은 진입장벽을 높이는 것만 같습니다.

그래서 10년 동안 사용자로 쌓아온 ERP의 개념과 소프트웨어에 대한 이해를 바탕으로 관련 주제들을 자세히 다뤄보려고 합니다. 기업 규모와 산업을 불문하고 ERP의 개념을 알아두는 것은 중요합니다. 일반 사용자를 비롯해 경영 컨설턴트나 분석가, 나아가 민감한 의사결정이 필요한 경영진 모두 유용한 정보를 얻어가면 좋겠습니다.

<출처: 프리픽>

미리보기

뻔한 개념 정의 말고, 그래서 정말로 ‘ERP’는 뭡니까?
‘ERP를 사용한다는 것’은 어떤 모습일까?
우리나라에서 ERP는 어떻게 발전해 왔나?
ERP 벤더별 시장 점유율과 반응은? SAP vs. 오라클 vs. 더존
비싸거나 폐쇄적이거나. 국내 ERP에는 대안이 없을까?

뻔한 개념 정의 말고, 그래서 정말로 ‘ERP’는 뭡니까?

재미없다고 느끼겠지만, 대표적인 ERP의 정의를 먼저 살펴봅시다.

“ERP는 전사적 자원 관리(Enterprise Resource Planning)의 약자로, 기업 내 다양한 부서의 업무 프로세스를 통합 관리하는 시스템을 의미합니다. ERP 시스템은 재무, 회계, 인사, 생산, 물류 등 기업의 전반적인 활동을 하나의 시스템에서 관리하여 효율성을 높이고 데이터의 일관성을 유지하는 데 도움을 줍니다.”

이 지루한 문장을 단순하면서도 간단한 문장으로, 다시 정의해보겠습니다.

“ERP는 우리 회사의 각 기능(영업, 물류, 생산, 관리, 재무 등)이 협업하는 ‘규칙’입니다.”

협업하는 규칙. 마치 노션(Notion)이나 슬랙(Slack) 같은 협업툴이 떠오르기에 친숙하고 직관적이지 않나요? 이처럼 ERP의 본질은 강력한 자동화, 계획, 통제 및 시뮬레이션 기능이 아닙니다. 오히려 ‘이런 일을 할 수 있게 규칙에 따라 제대로 데이터를 모으자!’라는 선언에 가깝죠.

수많은 예시가 있는데요, 아마 가장 많은 분이 사용해 보았을 ‘E-Accounting’을 예시로 설명해 보겠습니다.

회사에서 업무를 하다 보면 반드시 지출이 수반됩니다. 그렇다고 임의로 회삿돈을 쓸 수는 없으니 결정권자의 승인을 받아야 합니다. 또, 계획 없는 지출은 승인해달라고 할 수도 없죠. 예산이 편성된 항목을 특정하고, 근거도 첨부해야 합니다. 이런 과정을 온라인 또는 전자적으로 처리하는 시스템을 ‘E-Accounting’ 시스템이라고 하고요.

이 시스템은 ERP일까요? 네, ERP입니다. 비용을 사용하는 부서(기능)와 이를 검토하고 집행하는 회계/관리 부서 간의 ‘규칙’이니까요.

‘ERP를 사용한다는 것’은 어떤 모습일까?

ERP를 사용하는 모습을 보기에 앞서, 새롭게 정의한 ERP에서 제외되는 이해관계자를 알아야 합니다. 바로 결재권자, 같은 팀(기능 조직)의 동료, 그리고 경영 분석가입니다. 예시로 알아보겠습니다.

우리가 휴대폰 통신사 고객센터의 고객 서비스(C/S)를 담당하고 있는 직원이라고 가정해 봅시다. 고객이 일정 문제로 이번 달 요금을 면제해달라고 컴플레인을 걸었네요. 우리는 팀장님에게 면제 승인을 요청하고, 빌링팀에 요금 면제 내역을 전달합니다. 여기서 크게 두 번의 정보 흐름이 발생합니다. ‘요금 면제 승인 요청’과 ‘요금 면제 적용 요청’이죠. 하지만, 이 예시에서 ‘요금 면제’를 승인하는 결재권자는 ERP 이해관계자에서 제외합니다. ‘전자결재 및 승인’ 기능 영역까지 포함한 모든 소프트웨어가 ERP로 인식되는 것을 막기 위함입니다.

다음 예시는 ‘같은 팀 동료’에 대한 것입니다. 우리는 C/S 업무 5건을 처리하기로 예정되어 있었습니다. 그런데 급하게 연차를 사용할 일이 생겨 같은 팀 동료가 이 업무를 대신 처리했다고 합니다. 이때 일을 처리해 준 동료 또한 ERP의 이해관계자로 보지 않습니다. ‘프로젝트와 작업(Task) 관리’ 영역도 모든 소프트웨어를 ERP와 분류하는 주요 기능이기 때문입니다.

마지막은 ‘경영 분석가’ 및 ‘정보 소비자’입니다. 경영관리팀이나 데이터 분석팀, 경영진과 리더들이 주로 이에 해당합니다. 이들은 요약된 텍스트와 시각적 자료를 활용해 보고서를 작성하거나 봅니다. 이들 역시 ERP의 범위와 이해관계자에서 제외하겠습니다. ‘BI/DW(Business Intelligence & Data Warehouse)’ 영역까지 포함하면 대부분의 소프트웨어가 ERP로 간주될 수 있기 때문입니다.

이렇게 제외하면 무엇이 남느냐고요? 결재 라인, 작업 및 문서 관리, BI/DW를 제외하고 남는 것은 순수한 기능과 조직 간의 업무 프로세스입니다. 따라서 ERP를 사용하는 모습은 굉장히 단순합니다. 정보를 입력하는 화면, 그리고 유효성을 점검(Validation)하는 규칙이 핵심이죠.

모든 프로세스를 나열하기보다는, 대표적인 기업 프로세스 흐름인 O2C(주문부터 결제까지, Order to Cash)만 구체적인 예시로 살펴보겠습니다.

O2C 주요 프로세스 흐름: 쿠팡 이커머스 예시

시작: 고객이 앱에서 상품을 선택하고 주문합니다.
흐름 1: 고객이 상품, 혜택, 배송, 결제 정보를 입력하면 주문이 요청됩니다.
흐름 2: 시스템에 의해 주문 요청 즉시 출하 지시가 떨어지고 최적의 물류센터가 결정됩니다.
흐름 3: 물류 센터에서 재고를 가져오고(Picking), 포장하고(Packing), 적재 및 운송합니다.
흐름 4: 결제는 미리 이루어졌고, 배송 완료 이후 구매 확정 혹은 반품이 진행됩니다.
흐름 5: 구매가 확정된 상품은 매출과 원가로 집계되고 회계 결산 및 조정을 거칩니다.

쿠팡의 ERP, 즉, 각 기능이 협업하는 규칙이 보이시나요?

사실 눈에는 잘 안 보일 겁니다. 모든 프로세스는 시스템을 통해 이루어져서, 사용자는 단순히 상품을 분류하고 바코드를 찍는 행위만 상상할 수 있습니다. 그래서 ERP가 잘 구현되었다는 것은 ‘규칙’이 명확하고 시스템에 잘 녹아있다는 뜻입니다. 담당자는 바코드만 찍고 있다고 생각하지만, 사실은 ERP에 정보를 입력하고 업데이트하는 행위를 맡습니다.

반면, ERP가 제대로 구현되지 않은 회사는 어떨까요?

똑같이 주문을 받아도 영업관리팀에서 실제 재고가 있는지 수기로 확인하고, 물류팀에서 어느 창고의 상품을 출하시킬지 하나씩 판단해 배차 대상을 지정합니다. 곧이어 배송이 끝나면 하나씩 출하 기록을 업데이트하고요.

혹시 이런 생각이 들지 않나요? ‘아, ERP라는 게 생각보다 별 게 아니구나. 사실 우리는 이미 비슷하게 일을 처리하고 있고, 100% 자동화 안 해도 사람이 다 할 수 있는데? 꼭 도입할 필요는 없겠네.’ 네, 맞습니다. 사실 엑셀 같은 스프레드시트도 입력과 규칙이 표준화되어 있으면 ERP라고 볼 수 있죠. 굳이 거창하게 생각할 필요는 없습니다.

그렇다면, 사실상 회사의 모든 사람이 ERP 사용자이고, 거의 모든 소프트웨어가 ERP 같은데, 왜 정작 떠오르는 건 SAP, 더존, 오라클, Odoo와 같은 특정 소프트웨어일까요? 왜 대기업이나 중견기업의 미궁 같고 칙칙한 SAP, 오라클 화면이 떠오르고, 중소기업 회계팀과 인사팀에서만 쓰는 더존 같은 프로그램이야말로 ERP라는 생각이 들까요?

그 이유는 대부분의 ERP 프로그램이 ‘각 기능이 협업하는 규칙’이라는 범위를 넘어, 확보된 데이터를 기초로 업무를 자동화하는 기능까지 포함하고 있기 때문입니다. ERP에는 수 천, 수 만가지 자동화 기능이 포함되어 있는데요, 대부분의 회사는 이 중 10% 이상을 사용하지 못합니다. 그런데, 패키지 소프트웨어니까 이 기능에 대한 비용도 전부 부담해야 합니다. 그래서 라이센스 비용이 비싸죠.

왜 ERP 프로그램에 ‘협업하는 규칙’이라는 가볍고 직관적인 범위를 넘어 미처 사용하지도 못할 많은 기능이 포함될 수밖에 없었을까요? 현재의 ERP에 대한 모습과 인식이 왜 이렇게 자리 잡았는지 설명하려면, 우리나라 ERP의 주요 역사를 살펴봐야 합니다.

우리나라에서 ERP는 어떻게 발전해 왔나?

ERP 태동기: 세계

먼저 ERP라는 용어의 시작점은 어디인지 쫓아가 봅시다. 많은 분이 ERP라는 용어가 글로벌 톱 리서치/컨설팅펌인 가트너(Gartner)가 1990년대에 정의하면서 시작되었다고 알고 있을 텐데요, 사실 그 진짜 시작을 알기 위해 조금 더 시간을 거슬러 올라가려고 합니다. 우리는 1940년대로 갑니다.

1945년, 독일의 항복에 이은 히로시마 원자폭탄 투하와 일본의 무조건 항복으로, 제2차 세계대전은 연합국의 승리로 종결되었습니다. 이 역사의 한 장면은 여러 측면에서 의미가 있지만, 경제적 관점에서 보면 이후 미국이 전 세계 패권을 주도하게 된 시작이기도 합니다.

강력한 미군의 군수와 운영관리(Operation Management) 역량은 민간 분야로 급속히 퍼졌고, 그에 따라 대량생산, 표준화, 물류(Logistics), Push 기반 생산방식이라는 새로운 패러다임이 등장했습니다.

그렇게 1956년 컨테이너 해운 운항 시작과 1959년 메인프레임 컴퓨터의 상용화 같은 주요 사건을 거쳐 통칭 ‘MRP I’(Material Requirements Planning), 즉 자재 소요량 계획을 효율적으로 자동화하는 소프트웨어가 등장합니다.

1970년대에서 1980년대로 넘어오면서는 IBM의 작고 저렴한 하드웨어, 오라클의 상용 관계형(Relational) DBMS, 그리고 이더넷(Ethernet)과 PC가 나타났습니다. 이제 자재뿐 아니라 설비, 인력, 재무를 통합적으로 관리하는 ‘MRP II(Manufacturing Resource Planning)’로의 발전은 자연스러운 흐름이 되었습니다.

따라서 ERP라는 용어는 가트너에 의해 정의되었다기보다, 제2차 세계대전 이후 제조업이 중요해지고 메인프레임이 확산되면서 부각된 MRP, 그리고 하드웨어와 소프트웨어, 네트워크의 발전이 맞물려 확장된 개념으로 보는 것이 알맞습니다. 여기까지 정리하면 굵직한 글로벌 수준의 이벤트는 짚어본 겁니다.

ERP 태동기: 국내

자, 그럼 우리나라의 ERP 역사로 돌아와 볼까요? 우리나라는 1945년 해방 이후, 1960년대부터 이른바 ‘한강의 기적’을 이루며 급격한 성장을 이루었습니다. 이에 맞춰 정부와 대기업 전산실에 IBM 메인프레임이 도입되며 전산화가 시작됐고, 1970년대에는 수출 100억 달러 돌파와 중화학공업(HCI) 육성 정책 실행으로 삼성과 현대 공장에 MRP I이 시험적으로 운영되었습니다. 세계 흐름에 맞춰 1980년대에는 오라클 RDB를 활용한 MRP II 프로젝트가 활성화되었습니다.

우리나라 ERP 시장의 본격적인 변곡점은 1990년대에 발생합니다. (1994년 국내 최초의 PC방 등장 같은 이벤트와 함께) 1995년, 삼성그룹이 삼성전자부터 시작해 ‘SAP R/3 시스템을 도입하겠다’라는 중요한 결정을 내린 것입니다. 국내에서 ERP라는 용어가 대중화되기 시작한 것은 이때라고 봐야겠죠.

삼성전자는 한때 KOSPI에서 차지하는 비중이 27.8%에 달했던 기업입니다. 국내 1위 SAP의 시장점유율은 20% 수준으로 현재 시점 삼성전자의 KOSPI 비중과 유사해 보이기도 합니다. 여기서 ERP에 대한 잘못된 인식 중 하나의 출처가 드러납니다. ‘대기업 ERP는 SAP 아닌가?’라는 인식은 삼성전자가 SAP를 사용하기에 생겼다고 봐도 좋다는 것입니다. (벤더에 대한 인식과 특성은 다음 글에서 더 자세히 다뤄보겠습니다)

1990년대 후반은 국산 ERP의 태동기입니다. 영림원소프트랩이 1997년 국산 ERP ‘K-System’을 발표하며 포문을 열었고, 1999년에 이카운트 ERP, 2000년에 더존비즈온의 ERP M이 출시됩니다. 특히 1997년의 외환위기(IMF)가 불러온 기업 투명성 제고와 시장 개방을 포함한 구조조정 등으로 ERP 수요는 더욱 커져만 갔습니다.

이렇게 2000년대(Y2K)에 도달한 우리나라는 수많은 전산화가 이뤄진 듯 느껴질 수도 있겠지만, 실제로는 그렇지 않았습니다. 그 당시에도 삼성그룹을 제외한 대부분의 기업들은 이제 막 걸음을 뗄까 말까 고민하는 단계에 머물고 있었습니다.

ERP 확산기: 혁신적인 변화의 실종

지금까지, ERP의 역사는 기술 동향과 경영 환경 변화와 밀접하게 이어진다는 점이 눈에 띄셨을 겁니다. 다만 이런 태동기를 지나 2000년부터 2019년 Covid-19 팬데믹 전까지는 눈에 띄는 큰 변화가 없었던 것처럼 보이기도 합니다.

그러나 이 시기에도 중요한 사건들이 있었습니다. 2002년 미국 엔론(Enron)과 월드컴(WorldCom)의 초대형 회계 부정 사건을 계기로 SoX(Sarbanes-Oxley Act)라는 강력한 규제가 제정되었고, 2007년 아이폰(iPhone)의 등장으로 스마트폰 생태계가 열렸으며, 2008년 글로벌 금융위기가 발발했습니다. 국내에서는 2015년 대우조선해양 분식회계 사건에 따른 신(新)외부감사법 제정도 있었죠.

기술과 소프트웨어 측면에서는 HR 중심의 ERP 워크데이(Workday)가 2012년 IPO(기업공개)를 했고, 2014년에는 오픈소스 ERP Odoo(오두)가 리브랜딩하며 주목받기 시작했습니다. 100% 오픈소스와 파이썬 기반 구조 등 비싼 라이선스 비용과 특정 벤더 종속 문제를 해결하는 방식이었고요. 또한, 2016년 오라클(Oracle)은 넷스위트(NetSuite)를 인수하며 SMB 시장을 공략했고, 마이크로소프트(Microsoft) 역시 같은 해 ‘다이나믹 365’를 출시했습니다. 인포(Infor) ERP는 2014년부터 AWS 기반 클라우드스위트(CloudSuite) 제품을 발표하기도 했습니다.

이 시기의 ERP는 점진적으로 발전했습니다. 다만 다품종 소량생산의 시대로 넘어가면서 이전과 같은 혁신적 매출 성장이나 생산성 향상은 기대하기 어려웠습니다. 따라서 ERP 프로젝트는 점점 TCO(총소유비용, Total Cost of Ownership)와 ROI(투자 대비 수익률, Return on Investment)를 면밀히 검증하는 것이 중요해졌고, 컨설팅펌과 SI 기업들이 BPR(원점에서의 프로세스 구축, Business Process Reengineering), ISP(정보화 전략, Information Strategy Planning), PI(프로세스 혁신, Process Innovation) 등 프로젝트를 표준화하며 ERP 시장의 지속 성장에 기여했습니다.

느슨해진 ERP 시장에 긴장감을 준 Covid-19와 클라우드 경제

사실 클라우드 열풍은 Covid-19 전부터 이미 시작됐습니다. 물론 구글과 MS를 빼놓을 수는 없겠지만, 클라우드 시대의 주인공은 역시 AWS(Amazon Web Services)로 봐야겠죠. AWS를 필두로 2010년 초에 시장은 클라우드 경제를 충분히 증명했고, 2017년 즈음부터 SAP, 오라클 등 ERP 벤더도 제품을 상용 클라우드에 올려 판매하는 데에 집중하기 시작했습니다.

그런데 잠깐, 왜 ERP 얘기를 하다가 클라우드로 주제가 넘어갈까요? 간단하게 말하자면, 클라우드가 ‘비싼데 + 종속되는’ 기존 ERP 도입 방식을 크게 바꾸고 있기 때문입니다.

전통 ERP 도입 방식의 한계

전통적인 ERP 도입 방식은 서버를 준비하고 모듈과 사용자별로 라이센스를 구매하는 방식이었습니다. 라이센스 비용의 15~20% 정도는 매년 유지보수와 기술 지원 비용으로 납부합니다.조금 구체적인 숫자로 예를 들어볼까요? 매출액 5천억 원~1조 원, 직원 수 500~1천 명인 중견 제조 기업을 기준으로 본다면, 일회성 비용으로 40~50억 원, 연간 유지보수 비용으로 5~8억 원을 책정하면 적절합니다.

다만 ERP 벤더사에 따라 TCO(총 소유 비용)는 70% 이상 줄일 수도 있는데요, 어떤 벤더사든 시장에서 빈번하게 수주를 이뤄내는 것을 보면 성과와 비용 사이에 팽팽한 상충 관계(Trade-off)가 있다고 보입니다. 금액의 이점으로 특정 벤더사를 선정했다가 몇 년 후에 재구축하는 경우도 있고, 실제 활용 기능 대비 너무 과한 기능을 제공할 벤더사를 선정하는 경우도 있습니다.

클라우드가 가져온 혁신

하여튼 ERP는 초기 도입 비용도 높고, 한 번 도입하면 종속성도 큽니다. 따라서 고객 입장에서는 진입장벽이 높았죠. 그리고 이런 상황에서 ‘클라우드 경제’가 활성화되었습니다.

AWS는 물리적인 인프라 설치 없이 온라인으로 합리적인 가격에 하드웨어 인프라를 제공하며 혁신을 이뤘습니다. 물리적 소유 대신, 마치 구독형 서비스처럼 ‘사용한 만큼 지불하는(Pay-as-you-go)’ 방식이 가능해진 것이죠.

이는 자연스럽게 소프트웨어를 구독형 서비스(SaaS, Software-as-a-Service) 형태로 제공하는 트렌드로 이어졌습니다. 그러나 초기 클라우드 확산 시기에 ERP 벤더들이 받은 영향은 크지 않았다고 봐요. 고객의 진입장벽을 낮추기 위해 물리적 인프라 대신 온라인에서 클라우드로 ERP 인프라를 관리할 수 있다고 소구하는 수준이 아니었나 싶습니다.

Covid-19 팬데믹과 디지털 전환 붐

2020년, Covid-19 팬데믹이 본격화됩니다. 물론 경제와 민생에도 큰 충격이었지만, 이 사건 이후 전 세계에 ‘디지털 전환’이라는 새로운 붐이 찾아왔습니다. 정부는 경색된 시장을 활성화하기 위해 유동성 정책을 시행했고, 비대면의 제약을 해소하고자 IT 기술의 중요성이 부각되었습니다.

ERP 시장은 어땠을까요? 비싸고 종속적인 구조를 가진 특징으로 위기감을 느꼈을 겁니다. 일종의 대장주인 ERP 벤더 SAP의 매출은 2019년 308억 달러에서 2020년 317억 달러(전년 대비 +3.0%), 2021년 323억 달러(+1.9%)를 기록한 다음, 2022년에 314억 달러(-2.8%)로 역성장했습니다. 금융위기 시기를 제외하고 SAP의 첫 역성장이었죠.

그렇다면 이런 팬데믹 환경이 모든 소프트웨어 시장이 부정적이었을까요? CRM(Customer Relationship Managment) 소프트웨어 시장을 대표하는 Salesforce(세일즈포스)의 매출은 2019년 133억 달러에서 2020년 171억 달러(+28.6%), 2021년 212억 달러(+24.0%), 2022년은 265억 달러(+25.0%)로 폭풍 성장했습니다.

<출처: 작가>

소프트웨어의 특성이 달라 이런 결과가 나왔을까요? 물론 표준화 대량생산에서 맞춤형 개인화로 산업이 넘어가며, CRM 소프트웨어가 부상한 영향도 있을 것입니다. 하지만, 그보다 중요한 차이는 세일즈포스가 1999년 창립부터 철저히 ‘클라우드 Only’ 전략을 유지해 온 기업이라는 점입니다.

ERP가 높은 초기 비용과 긴 계약 기간으로 종속성을 가졌다면, 세일즈포스는 초기 비용이 낮습니다. 게다가 데모와 무료 체험 기간, 혹은 1년 약정 기간이 지나기 전이라도 계약을 해지하고 다른 소프트웨어를 도입할 수 있습니다. 이에 SAP 역시 클라우드 중심 전략으로 전환했고, 2023년과 2024년 다시 각각 7.8%, 8.5%의 성장률을 기록하며 회복세를 보이고 있습니다. (물론 생성형 AI의 영향도 클 것입니다.)

무겁고 거대한 소프트웨어의 굴레를 벗어난 ERP

Covid-19로 대변되는 2020년부터 2023년까지, 디지털 전환과 클라우드 경제 확산 시대를 지난 ERP 시장의 가장 큰 변화는 무엇일까요? 대형 벤더들이 클라우드에 최적화하고 초기 비용을 낮췄다는 점? 접근성을 큰 폭으로 높였지만, 혁신이라고는 보기 어렵습니다.

저는 이 시기를 “ERP가 드디어 무겁고 거대한 소프트웨어의 굴레를 벗어난 시기”라는 정의하고 싶습니다. 이제 우리 회사의 ERP는 SAP다, 혹은 더존이다처럼 특정 벤더로만 묶어둘 필요가 없어졌습니다. 모두 사용한 만큼 지불하는 작은 단위의 클라우드 서비스로 쪼개졌기에, 더는 하나의 거대한 소프트웨어에 종속될 필요가 없어진 것이죠.

그렇게 “ERP는 뭐 쓰세요?”라는 질문에 “SAP나 더존을 씁니다”가 아닌 “재무 모듈은 ‘SAP Finance’를 사용하고, 세무 신고는 ‘더존’, 인사 및 급여관리는 ‘Flex’를 씁니다”라고 대답하는 시대가 온 것입니다.

물론 기업이 다양한 SaaS를 동시에 사용하면서, 통합 관리가 어려워지고 기능을 제대로 활용되지 못하는 사례도 증가하고 있습니다. 이 때문에 일부러 하나의 큰 소프트웨어에 종속되기를 선택하는 경우도 있습니다.

하지만 이런 문제가 대형 소프트웨어 벤더에게 높은 비용을 지불한다고 반드시 해결되는 것은 아닙니다. 통합 관리라는 명분 아래, 더 전문적이고 유연하며 가격 경쟁력까지 있는 다른 대안을 마련할 수 없고, 우리만 쓰려고 자체 구축한 기능과 서비스가 점차 낙후되어 실행력이 떨어지기도 합니다.

결국 지금처럼 ERP의 개념적 범위가 확장되며 업무 프로세스를 표준화하고 효율화할 수 있다는 점은 미래를 기대하게 합니다. 실제 업무 방식, 속도, 품질에 큰 변화가 생기니까요.

마치며

슬슬 변곡점이 오고 있습니다. (이미 온 것 같기도 합니다.)

ERP를 포함해서 프로세스를 통합하고 자동화하는 소프트웨어의 비용이 너무 낮아진 것입니다. 필요한 소프트웨어를 조합해서 잘 쓰는 것만으로도, ROI(Return on Investment)가 즉각적으로 보입니다. 다른 회사는 다 개인용 PC로 일하고 있는데, 우리만 종이문서와 결재판으로 일하고 있다? 생산성의 차이가 어마어마하겠죠. 하물며 소프트웨어 비용이 낮아짐과 더불어, 2023년부터는 생성형 AI까지 본격화 되었습니다. 어쩌면 개인용 PC와 종이 문서만큼, 혹은 그 이상의 차이가 생기고 있는 것 같아요.

이런 이해를 바탕으로 다음 글에서는 주요 ERP 벤더의 특성과 국내 시장에서 이들이 쓰이는 모습을 짚어보겠습니다.

ERP 시리즈

① 그래서 정말로 “ERP”란 뭔가요?
② 국내 ERP는 왜 SAP 아니면 더존일까?

]]>

구글 클라우드 기반 기업용 AI 구축하기(feat. CEN AI)

이 글은 아이티센클로잇과 함께 요즘IT 브랜디드 콘텐츠로 제작했습니다.

요즘 ‘AI 시대’는 그야말로 속도전입니다. 아침에 일어나면 또 새로운 AI 기술이 나왔다는 소식이 들려옵니다. 이메일이나 기획서를 쓸 때 AI의 도움을 받는 것도 흔한 일이 됐고, 오히려 AI 없이 일하는 게 어색하게 느껴질 정도죠. 이제 기업에서도 업무 생산성과 효율성을 높이기 위해 더 이상 AI를 외면할 수 없는 현실입니다.

하지만 막상 AI를 도입하려고 하면 고민도 많습니다. 회사의 민감한 데이터를 외부 AI 서비스에 넘기는 것이 안전할지, 우리 회사 업무 환경에 제대로 맞출 수 있을지 걱정이 되죠. 이럴 때 복잡한 구축 과정 없이, 이미 사용 중인 구글 클라우드(Google Cloud) 같은 플랫폼 기반으로 우리 회사만의 생성형 AI 챗봇을 구축할 수 있다면 어떨까요? 업무 생산성은 또 얼마나 달라질까요?

오늘은 이러한 고민을 현실적으로 해결하기 위해 AI 에이전트 기술을 활용해, 기업 맞춤형 AI 챗봇 서비스 ‘CEN AI’를 개발한 아이티센클로잇 관계자들을 만나봤습니다.

이번 인터뷰에서는 기업 내부 데이터를 활용하는 생성형 AI 챗봇이 실제 업무 환경에서 어떻게 쓰일 수 있는지, 그리고 클라우드 환경에서 생성형 AI 챗봇을 구축하는 전략과 앞으로의 AI 기술 발전 방향에 대해 자세한 이야기를 들어봤습니다.

아이티센클로잇은 멀티 클라우드 환경에서 Cloud Native 애플리케이션 개발과 DevOps 플랫폼 구축 등 전문 기술 역량을 갖춘 기업입니다. 특히 클라우드 기반 AI 기술과 데이터 분석 역량을 바탕으로 다양한 산업 분야의 디지털 혁신을 기술적으로 지원하고 있습니다. 클라우드 전환, 구축과 운영, 컨설팅, 솔루션 제공까지 다양한 영역에서 활동 중입니다.

아이티센클로잇 회사 소개서 &기업용 AI 솔루션 CEN AI 소개서 받아 보기

우리 회사에 맞는 생성형 AI 챗봇, 왜 필요할까?

#AI챗봇 #데이터보안 #생산성 #LLM

왼쪽부터 아이티센클로잇 ‘CEN AI’ 개발 담당 윤상배 이사, 클라우드솔루션센터 정승모 상무 <출처: 요즘IT>

Q. 우리 회사만의 ‘생성형 AI 챗봇’이 필요한 이유는 무엇인가요? 챗GPT나 제미나이와 같은 범용 AI 서비스를 써도 되지 않나요?

정승모 상무: 챗GPT나 제미나이 같은 범용 AI 모델은 기본적으로 개인을 위한 서비스입니다. 그러다 보니 회사의 기밀문서, 고객 정보, 영업 비밀 등 민감한 데이터를 외부에 노출시킬 위험이 매우 큽니다. 실제로 보안 사고가 번번이 발생하고 있어서, 외부 서버로 데이터를 전송하는 일 자체가 엄격히 제한된 회사도 많습니다. 기업의 내부 데이터를 안전하게 활용하고 싶다면, 처음부터 우리 회사에 맞게 설계된 생성형 AI 챗봇을 선택하는 것이 좋습니다.

윤상배 이사: 데이터 면에서도 범용 LLM(대규모 언어 모델)은 일반적인 데이터를 학습한 것이지, 회사의 구체적인 내부 데이터는 학습하지 못합니다. 기업의 업무는 재무, 고객 관리, 문서 관리 등 내부 시스템과 복잡하게 얽혀 있는데요. 범용 AI 모델은 이러한 내부 시스템과 직접 연동되도록 설계되어 있지 않습니다. 결국 직원들이 생산성 향상을 위해 내부 데이터를 활용하려면, 기업의 정보와 데이터 환경에 맞게 커스터마이징된 챗봇 솔루션이 필요합니다.

Q. 기업 단위로 생성형 AI 챗봇을 도입해야 하는 가장 큰 이유는 무엇일까요?

정승모 상무: 대부분의 기업에서 공통적으로 겪는 어려움이 바로 데이터와 관련된 문제일 텐데요. 기업 내부의 정보가 여기저기 분산되어 있고, 또 그 형식도 다양해서 막상 업무에 필요한 데이터를 찾고 취합하는 게 상당히 까다롭습니다. 이런 환경에서는 정확한 데이터 기반의 의사결정을 내리기 어렵죠.

실제로 지식 노동자들은 하루 8시간 중 생산적인 시간은 2시간 정도고, 나머지 6시간은 정보 검색 등 준비 작업에 소비한다고 합니다. CEN AI는 AI를 이용해 이러한 비효율 문제를 해결하는 데 집중했습니다. 기업 내부에 흩어져 있는 데이터를 효과적으로 통합하고, 실시간으로 최신 정보를 기반으로 답변을 생성해 주는 것이죠.

윤상배 이사: 특히 RAG(Retrieval-Augmented Generation, 검색증강생성)라는 기술을 쓰면, 기업 내부에서 생산된 최신 데이터를 정확히 활용할 수 있습니다. AI가 흔히 일으킬 수 있는 할루시네이션(환각) 같은 현상을 크게 줄이고, 답변의 출처까지 명확히 제공해서 신뢰도를 높이죠. 결과적으로 기업들이 자주 직면하는 데이터 접근성의 문제나, 민감한 정보의 보안 문제, 그리고 복잡한 업무 환경 속에서도 빠르고 정확하게 의사결정을 내릴 수 있도록 돕습니다.

Q. 생성형 AI 챗봇을 도입하려면 회사 내부 데이터는 어느 정도로 준비되어 있어야 하나요?

윤상배 이사: 생성형 AI 챗봇의 성능은 결국 데이터의 품질과 양에 따라 결정됩니다. 하지만 많은 기업들이 이미 갖추고 있는 데이터들이 잘 정리되어 있지 않거나, 상당히 파편화되어 있는 경우가 많죠. 그래서 도입 초기부터 모든 데이터를 완벽하게 준비하려고 하기보다는, 일단 명확한 평가가 가능한 특정 시나리오와 관련된 데이터를 우선적으로 준비하고, 간단한 수준에서부터 시작하는 것이 좋습니다.

예를 들어, 제품의 스펙이나 고장 수리와 관련된 데이터가 충분히 확보된 상황이라면, 해당 데이터를 먼저 챗봇에 학습시켜 QA 담당자나 고객지원(CS) 업무에서 빠르게 효율성을 높일 수 있습니다. 그리고 이렇게 초기의 명확한 사례를 만들어 성공 경험을 쌓은 후, 점차 내부나 외부로 확산시키는 것이 가장 효과적인 방법입니다.

Q. 생성형 AI 챗봇 도입 후, 기업에서 기대할 수 있는 주요 성과나 효과는 무엇일까요?

정승모 상무: 가장 먼저 눈에 띄는 성과는 업무의 정확성과 효율성 향상입니다. 기존에 직원들이 많은 시간을 소비했던 기획서 작성이나, 계약서 검토 같은 업무를 생성형 AI 챗봇이 빠르게 처리해 줌으로써 직원들이 핵심 업무에 더 집중할 수 있죠.

윤상배 이사: 무엇보다 중요한 건 기업 내부 데이터를 안전하게 활용하면서도 높은 정확도로 정보를 제공한다는 점입니다. 실제로 범용 AI 모델을 쓰면 정보의 정확도가 80% 정도지만, 기업 전용 챗봇을 활용하면 정확도가 95% 이상으로 올라갑니다. 기업 입장에서는 정보 신뢰도가 높아지고, 의사결정의 속도와 질이 크게 개선되는 효과를 볼 수 있는 것이죠.

또한 기업의 업무 프로세스를 효율적으로 관리할 수 있게 됩니다. 생성형 AI 챗봇은 기업 내부의 복잡하고 다양한 데이터를 통합해, 직원들이 필요로 하는 정보를 즉시 찾아주고 제공합니다. 결과적으로 생성형 AI 챗봇을 도입하면 반복 업무의 부담은 줄고, 의사결정은 빠르고 정확해지며, 직원들이 생산적인 업무에 더 몰입할 수 있는 환경을 마련할 수 있습니다.

CEN AI 기능 예시 <출처: 아이티센클로잇>

기존 클라우드 환경에서 손쉽게 구축하는 생성형 AI 챗봇

#Google Cloud #손쉬운구축 #비용 #클라우드

Q. 클라우드 환경을 기반으로 생성형 AI 챗봇을 구현하면 어떤 이점을 얻을 수 있나요?

윤상배 이사: 구글 클라우드(Google Cloud) 같은 클라우드 벤더를 활용해, 생성형 AI 챗봇을 구현하면 크게 세 가지 정도의 중요한 이점을 얻을 수 있습니다. 가장 먼저, 빠르게 서비스를 출시할 수 있다는 점입니다. 클라우드 벤더들이 이미 준비해놓은 최신 기술과 다양한 서비스를 활용하면, 처음부터 기술을 구축하고 준비할 필요가 없어, 빠르게 시장에 대응할 수 있다는 점이 큰 장점이죠.

두 번째는 비용 관리 측면에서 효율적입니다. 클라우드 환경에서는 별도의 초기 투자가 적고, 사용량에 따라서 유연하게 비용을 조절할 수 있죠. 특히 생성형 AI의 경우 토큰 단위로 비용이 청구되는데, 이 방식을 잘 활용하면 기업 내에서 사용량을 효율적으로 관리할 수 있습니다.

마지막으로 데이터 관리와 보안이 쉽고 안정적입니다. 클라우드 플랫폼에서 데이터를 통합 관리하다 보니, 보안 정책이나 데이터 접근 권한을 일관되게 적용할 수 있는데요. 덕분에 민감한 데이터도 보다 안전하게 관리할 수 있게 됩니다.

Q. 반대로 우려되는 점은 없을까요?

윤상배 이사: 물론 클라우드 벤더 종속에 대한 우려가 있을 수 있습니다. 하지만 앞서 언급한 빠른 구축과 높은 효율성 같은 장점을 생각하면 충분히 감수할 만한 부분이죠.

또 요즘 표준인 하이브리드 클라우드나 멀티 클라우드 방식을 고려한다면 주요 기능은 특정 벤더나 자체 기술을 활용하고, 필요한 특화 기능만 외부 모델을 연동하는 형태로도 유연하게 구성할 수 있어요.

Q. 클라우드 환경에서 생성형 AI 챗봇을 도입할 때, 복잡한 설정이나 별도의 추가 장비 없이도 쉽게 구축할 수 있나요?

정승모 상무: 클라우드 환경의 가장 큰 장점 중 하나는 ‘관리형 서비스(Managed Service)’가 많다는 점인데요. 이는 기업이 최신 기술의 인프라나 서비스 구축과 설정, 심지어 관리조차 직접 하지 않아도 된다는 의미입니다.

특히 클라우드 벤더들은 다양한 관리형 AI 및 머신러닝(ML) 서비스를 제공하고 있습니다. 예를 들어, 대규모 언어 모델(LLM), 임베딩 모델, 벡터 데이터베이스 등 복잡한 서비스를 바로 활용할 수 있도록 지원하죠.

CEN AI도 최신 기술 기반의 클라우드 서비스를 최대한 이용해 개발한 솔루션으로, 인프라 구축에 드는 노력 대신 솔루션 기능과 품질 향상에 집중했습니다. CEN AI를 고객사 환경에 적용할 때도 클라우드 환경을 활용하기 때문에, 온프레미스 기반의 솔루션보다 훨씬 빠르고 간편하게 구축할 수 있는 것이죠.

Q. 생성형 AI 챗봇을 구축할 수 있는 기반 클라우드 서비스로, 구글 클라우드(Google Cloud)가 선택된 이유는 무엇인가요?

정승모 상무: 저희가 구글 클라우드를 선택한 가장 큰 이유는 구글이 가지고 있는 다양한 형태의 데이터와 이를 잘 처리할 수 있는 제미나이 모델의 장점 때문입니다. 구글은 오랜 기간 유튜브나 구글 포토, 구글 맵처럼 이미지나 영상을 많이 다루는 서비스를 운영해 오면서, 정말 방대한 양의 데이터를 쌓아왔어요. 이런 멀티모달 데이터들이 생성형 AI가 학습하고 발전하는 데 아주 좋은 기반이 되는 거죠.

윤상배 이사: 특히 저희가 주목했던 부분은 제미나이 모델이 다양한 형태의 데이터를 굉장히 잘 다룬다는 점이었습니다. 이미지나 영상과 같은 데이터를 실제로 처리할 때 다른 AI 모델에 비해 더 우수한 결과를 보여줬고요. 무엇보다 최근 들어 제미나이의 품질 개선 속도가 정말 빨라서, 저희도 놀랄 정도였죠. 이런 장점 덕분에 생성형 AI 챗봇 구축의 기반으로, 구글 클라우드를 선택하게 됐습니다.

Q. 처음 설정이나 유지보수 시 주로 신경 써야 할 부분은 어떤 것들이 있을까요?

윤상배 이사: 많은 기업들이 처음 AI 챗봇을 도입할 때 가장 먼저 고민하는 부분은 “어떤 LLM 모델을 선택할까?”입니다. 하지만 실제 운영 과정에서 가장 중요한 건 ‘데이터 라이프 사이클 관리’와 ‘챗봇의 응답 품질 관리’입니다. 특히 데이터는 지속적으로 변화하기 때문에 주기적으로 품질을 점검하고 관리하는 게 매우 중요한데요. 기업 환경에서 정확한 정보를 제공하는 건 핵심이기 때문에, 사용자 피드백을 적극적으로 수집하고, 로그 분석 및 품질 프레임워크를 도입하여 철저히 관리하는 게 필요합니다.

또 한 가지 강조하고 싶은 점은 비용 최적화입니다. 클라우드 환경은 간편한 만큼 자원 낭비가 쉽게 발생할 수 있습니다. AI 챗봇 역시 예산 책정부터 지속적인 비용 모니터링, API 호출 최적화까지 체계적으로 관리해야 비용을 효과적으로 통제할 수 있고요.

정승모 상무: 각 회사에 맞는 보안과 규정 준수도 중요합니다. 클라우드 환경의 편리성 덕분에 정보 접근이 매우 빠르지만, 그만큼 보안 리스크가 높아질 수 있는데요. 따라서 데이터 암호화는 기본이고, 주요 민감 데이터에 대한 접근 권한 관리와 로깅 시스템, 감사 시스템 구축까지 세부적으로 준비해야 합니다. CEN AI에서는 이러한 리스크를 줄이기 위해, 데이터 암호화 및 마스킹, 입력이나 출력 단계의 가드레일, 역할 기반 접근 제어(RBAC) 등 다양한 보안 장치들을 추가해 나갈 예정입니다.

또 한 가지 말씀드리면, AI 기술은 최근 매우 빠르게 진화하고 있습니다. 거의 매월 새로운 모델이 나오기 때문에 최신 모델과 기술 동향을 꾸준히 모니터링하고, 주기적으로 테스트하면서 적절한 시기에 모델을 업데이트하는 전략을 반드시 갖추어야 해요. 이렇게 해야만 생성형 AI 챗봇의 성능을 지속적으로 높이고, 새로운 기술의 혜택을 놓치지 않고 활용할 수 있습니다.

Q. 일반적인 챗GPT 같은 서비스와 비교했을 때, ‘가격’의 차이도 있을까요?

정승모 상무: CEN AI의 가격은 크게 구독형과 설치형 두 가지로 나눌 수 있습니다. 구독형의 경우에는 클라우드 방식으로 제공돼서 사용자가 많아질수록 한 사람당 내는 비용이 저렴해지는 구조예요. 예를 들어, 챗GPT 같은 서비스가 한 달에 약 29,000원 정도 한다면, CEN AI는 사용자 한 명당 월 몇천 원 수준으로 이용하실 수 있어요. 다만 구독형 서비스라 하더라도 초기 설정 비용이나 클라우드 인프라 사용료가 따로 발생할 수는 있습니다.

특히 설치형의 경우, 기업 내부 환경에 맞게 시스템을 구축하기 때문에 처음에 별도의 구축 비용이 들어갑니다. 그러나 사용한 토큰 양을 기반으로 비용이 청구되는 방식이라, 실제 사용량이 많아지더라도 평균적으로 사용자의 비용 부담을 낮출 수 있다는 장점이 있죠.

일반적인 챗GPT 같은 서비스를 기업 단위로 사용하게 되면, 토큰 사용량이 누적되어 월 수천만 원 규모까지 비용이 발생할 수 있는데요. CEN AI는 같은 규모로 운영하더라도 사용량 기반의 과금 구조 덕분에 비용 부담을 줄일 수 있어요.

CEN AI 활용 시나리오 <출처: 아이티센클로잇>

더 똑똑한 생성형 AI 챗봇이 되는 방법

#RAG #기술 #에이전트 #효율성

Q. 앞서 ‘RAG’라는 용어가 자주 언급됐는데요. RAG 기술이 정확히 무엇이고, 왜 중요한가요?

윤상배 이사: RAG(Retrieval-Augmented Generation) 기술은 기본적으로 공개된 정보만 학습된 일반적인 대규모 언어모델(LLM)을 기업 내부의 데이터까지 활용할 수 있도록 확장하는 기술입니다. 간단히 비유하자면, 일반 LLM은 상식이 풍부하지만 기업 내부 데이터는 알지 못하는 “비숙련 전문가”와 같습니다. RAG는 바로 이 비숙련 전문가에게 기업의 구체적인 정보를 검색하여 제공함으로써 “숙련된 전문가”로 만드는 것이죠.

다시 말해, 사용자의 질문을 정확히 분석한 뒤, 관련된 기업 내부 문서를 검색하고, 이를 종합적으로 분석·요약해 최적의 결과를 제공하는 기술이라고 할 수 있습니다. 최근에는 단순히 정보를 제공하는 것을 넘어 실질적인 업무와 연계된 액션(AI 에이전트)까지 수행할 수 있도록 발전하고 있습니다.

Q. 그렇다면 클라우드 기반의 ‘CEN AI’는 RAG 기술을 활용해 기업 내부 시스템 및 데이터와 어떻게 연동하고, 기존 챗봇과 비교해 어떤 강점을 가지나요?

윤상배 이사: CEN AI는 기업이 내부에 가지고 있는 데이터를 잘 찾아서 쓸 수 있도록 RAG 기술을 기반으로 만들었어요. 덕분에 ERP나 CRM 같은 기존 시스템들이랑도 쉽게 연결할 수 있고, 각 회사 상황에 따라 필요한 시스템을 맞춤형으로 붙이기도 굉장히 편해졌죠.

특히 자체적으로 만든 도큐먼트 파서 같은 기술을 이용해서, 단순히 키워드만 뽑는 게 아니라 문서의 맥락이나 의도까지 이해하도록 했어요. 이렇게 하면 정확도나 신뢰도가 훨씬 올라가거든요. 또 데이터를 업무나 특성에 맞춰 각각의 AI 에이전트로 만들고, 이 에이전트들을 하나의 슈퍼 에이전트가 다시 통합해서 관리하기 때문에, 여러 시스템과 데이터를 더 자연스럽고 효과적으로 연결할 수 있어요.

정승모 상무: 비즈니스 관점에서 보면 CEN AI는 일반 생성형 AI 챗봇과 차별화된 노선을 지향합니다. 단순히 정보만 주는 게 아니라, 실제 기업 고객의 업무 상황과 맥락을 이해하고, 업무를 직접 도와주는 역할까지 확장하려고 합니다. 회사 내부 시스템과 쉽게 연동해서 업무를 자동화하거나 최적화할 수 있고요. 불특정 다수의 사용자를 대상으로 한 일반 생성형 AI 챗봇과는 달리 CEN AI는 기업마다 서로 다른 요구에 맞춰 유연하게 쓸 수 있어, 기업 사용자의 실제 업무 효율을 높이는 AI 에이전트라고 할 수 있습니다.

RAG 기술을 활용한 ‘CEN AI’ <출처: 아이티센클로잇>

Q. 생성형 AI 챗봇이 기업의 업무를 제대로 지원하기 위해 어떤 조건을 충족해야 할까요?

윤상배 이사: 생성형 AI 챗봇이 현장에서 제대로 쓰이려면 네 가지가 중요합니다. 첫째는 정확성과 신뢰성으로, 항상 최신 정보와 기업 내부 정책이나 법률을 정확히 반영해야 합니다. 둘째는 사실 기반의 답변인데요, 잘못된 정보가 전달되지 않도록 내부 데이터와 연동하고 출처를 명확히 밝혀야 합니다. 셋째는 일관성입니다. 같은 질문에는 일관된 정보를 제공해 사용자 신뢰를 유지해야 하죠. 마지막으로 규정과 정책 준수입니다. 챗봇이 기업의 보안 정책이나 개인정보 보호 기준을 철저히 따르도록 설계되어야 하죠.

생성형 AI 챗봇이 바꿀 비즈니스의 미래

#기업사례 #에이전트 #생산성 #미래전략

Q. 생성형 AI 챗봇을 실제로 도입했을 때 직원들의 업무 방식이나 효율성은 어떻게 달라질까요? 실제 사례가 있다면 소개해 주세요.

정승모 상무: 실제 사례에서 제약업체의 경우, 의약품 규제나 최신 정책 관련 정보를 빠르고 정확하게 얻을 수 있어서 업무 정확도가 높아졌고, 가전업체에선 제품 수리나 고객 응대 정보를 즉시 제공받아 업무 대응력이 크게 개선됐다고 합니다. 건설업계 역시 최신 건축 규제나 프로젝트 관련 정보를 챗봇을 통해 실시간으로 확인해, 업무 처리가 빨라졌다고 하고요. 전반적으로 생성형 AI 챗봇을 도입한 기업에서는 직원들의 만족도와 업무 속도가 눈에 띄게 좋아졌습니다.

Q. 앞으로 ‘CEN AI’가 발전하는 과정에서 주목할 만한 새로운 기술이나 기능은 어떤 것이 있을까요?

윤상배 이사: CEN AI는 앞으로 단순한 정보 검색과 제공 수준을 넘어서, 직접적인 업무 수행과 의사 결정까지 보조할 수 있는 AI 에이전트로 발전해 나갈 예정입니다. 특히 MCP(Model Context Protocol), A2A(Application-to-Application), ADK(Application Development Kit) 같은 아키텍처를 통해 기업이 원하는 방향으로 보다 쉽게 확장하고, 커스터마이징할 수 있도록 지원할 계획입니다.

왼쪽부터 아이티센클로잇 ‘CEN AI’ 개발 담당 윤상배 이사, 클라우드솔루션센터 정승모 상무 <출처: 요즘IT>

Q. 마지막으로 장기적인 관점에서 생성형 AI 챗봇이 기업에 꼭 필요한 이유를 정리해 주신다면요?

정승모 상무: 장기적으로 보면 생성형 AI 챗봇은 기업들이 경쟁력을 지키고 높이기 위해 반드시 필요한 기술입니다. 앞으로 AI를 도입한 기업과 그렇지 않은 기업 사이의 격차는 크게 벌어질 거예요. 특히 데이터를 기반으로 더 정확한 의사결정을 하고, 업무 효율성을 높이며, 고객 경험을 개선하는 데 있어서 우리 기업에 꼭 맞는 생성형 AI를 적극적으로 고민해 보셨으면 좋겠습니다.

윤상배 이사: 생성형 AI 챗봇은 우리 기업이 가진 내부 데이터를 더 잘 활용할 수 있게 하고, 여러 시스템이나 최신 기술과도 자연스럽게 연결해 줍니다. 그래서 앞으로 AI로 생길 변화에 있어, 기업이 더 빠르고 유연하게 대응할 수 있는 환경을 만드는 데 큰 도움이 될 겁니다.

이번 인터뷰를 통해 생성형 AI 챗봇이 단순히 기술적 트렌드가 아니라, 기업의 업무 방식을 바꾸고 경쟁력을 키우는 핵심 전략이 될 수 있다는 점을 확인할 수 있었는데요. AI 기술이 빠르게 발전하고 있는 지금, 잠깐의 변화를 두려워하기보다, 한발 앞서 준비하는 기업이야말로 지속 가능한 성장을 이룰 수 있지 않을까요?

[CEN AI / 구글 클라우드 트라이얼 이용해 보기]

링크에서 우리 기업만을 위한 생성형 AI 챗봇 ‘CEN AI’와 구글 클라우드 도입 상담을 받아 보세요.

김소희 에디터 sohee@wishket.com

]]>

휴머노이드 로봇은 왜, 그리고 어떻게 만드는 걸까?

테크콘 2025 로봇 콘퍼런스 리포트

테크콘 2025 <출처: 작가>

지난 6월 11일, ‘테크콘2025’에서 진행하는 로봇 콘퍼런스에 다녀왔습니다. <지능형 로봇과 인간 공존의 새로운 패러다임>이라는 주제로, 로봇의 미래를 더욱 기대하게 만드는 자리였는데요.

그날 콘퍼런스에서 참가자들이 가장 많이 언급한 키워드는 바로 ‘피지컬 AI(Physical AI)’였습니다. 현장에서는 특히 사람의 모습을 닮은 휴머노이드(humanoid) 로봇이 우리 삶에 얼마나 빠르게 다가오고 있는지 피부로 느낄 수 있었습니다.

테크콘2025, 한재권 교수 세션 <출처: 작가>

가장 흥미로웠던 세션은 한국 로봇공학 연구를 이끌고 있는 한양대 로봇공학과 한재권 교수의 발표였습니다. 휴머노이드 로봇 개발 기업인 ‘에이로봇’을 창업하며 이론뿐만 아니라 실무 경험까지 두루 갖춘 로봇 분야 전문가입니다.

이날 진행한 세션 <Physical AI와 Humanoid Robot의 최신 동향과 산업화>에서 그는 휴머노이드 로봇이 2030년 전에 상용화될 거라고 예상했습니다. 발표의 내용을 따라가며 여러 궁금증이 생겼습니다. 과연 우리는 왜 사람을 닮은 로봇을 만드는 걸까요? 휴머노이드를 개발하기 위해서는 어떤 기술이 필요할까요? 또 요즘 주목받고 있는 엔비디아의 ‘코스모스(Cosmos)’는 로봇 개발에 어떤 역할을 할까요? 발표 내용에 새로 조사한 내용을 더해 지금부터 함께 알아보겠습니다.

세계는 지금 ‘휴머노이드 로봇’

지난 4월 19일, 베이징에서 세계 최초로 휴머노이드(인간형) 로봇 마라톤이 열렸습니다. 그뿐만 아니라 테슬라(Tesla)는 올해 초, 휴머노이드 로봇 ‘옵티머스(Optimus)’ 제작 목표를 최대 10,000대로 잡고 있다고 밝혔습니다. 또한 BMW에 휴머노이드 로봇을 공급하기로 한 스타트업 피규어AI(Figure AI)는 연간 최대 12,000대를 생산할 수 있는 제조 시설을 구축했지요.

본격적인 휴머노이드 로봇 경쟁이 이미 시작된 것입니다.

베이징휴머노이드로봇혁신센터와 유비테크의 '톈궁 울트라'가 1위로 들어오는 모습 <출처: 로이터>

그런데 우리는 왜 굳이 ‘휴머노이드’ 로봇을 만들려고 하는 걸까요? 왜 로봇은 꼭 사람과 닮아야 할까요?

한재권 교수는 “휴머노이드 로봇의 본질은 사람과 닮은 외형 자체가 아니라, 그 형태 덕분에 얻을 수 있는 ‘범용성’”이라고 이야기했습니다. 다시 말해, 로봇도 인간과 비슷한 모습이어야 이미 사람에게 맞춰진 환경에 별도 변화 없이 적용할 수 있다는 것입니다. 예를 들어, 바퀴 달린 로봇은 오르기 힘든 계단이나 좁은 공간도 두 발로 걷는 휴머노이드라면 수월하게 다닐 수 있습니다.

우리나라는 출산율이 낮아지면서 노동력 역시 감소 중인데요. 이런 특성으로 휴머노이드 로봇은 집안일을 돕는 것부터 공장의 조립 작업, 혹은 위험한 산업 현장의 업무까지 다양한 분야에서 멀티플레이어급 활약을 기대할 수 있습니다.

특히 생성형 AI는 휴머노이드 로봇의 가치와 발전 속도를 더욱 앞당기고 있습니다. GPT 같은 거대 언어 모델(LLM)의 등장은 로봇의 ‘뇌’에 해당하는 소프트웨어의 지능을 완전히 다른 수준으로 발전시켰습니다. 이를테면 예전에는 상황에 따라 일일이 세세하게 로봇의 움직임을 프로그래밍해야만 했습니다. 하지만 지금은 LLM 기반의 AI가 방대한 지식을 바탕으로 스스로 맥락을 이해하고 판단할 수 있게 되었지요. 사람과 비슷하게 생긴 로봇에, 사람처럼 언어를 이해하고 문제를 해결하는 AI가 결합된다면 어떨까요? 간단한 지시나 질문만으로도 다양한 업무를 수행할 수 있게 될 것입니다.

즉, 우리가 휴머노이드를 만드는 진짜 이유는 단지 ‘인간을 닮은 존재를 만들기 위해서’가 아니라, ‘인간을 가장 잘 도와줄 수 있는 존재’를 만들기 위해서라고 볼 수 있습니다.

왜 바로 투입하지 않을까?

현재 공개된 휴머노이드 로봇, 테슬라의 ‘옵티머스’나 피규어AI의 ‘피규어02’의 시뮬레이션을 보면, 이들은 이미 여러 업무를 꽤 능숙하게 해내는 것처럼 보입니다.

소포 방향을 정렬하는 피규어AI의 휴머노이드, 피규어02. <출처: 피규어AI>

하지만 로봇이 실제 현장에 바로 투입되는 경우는 드뭅니다. 휴머노이드 로봇을 이렇게 잘 만들어 놓고도 바로 쓸 수 없는 이유는 무엇일까요? 상용화를 위해 남은 과제들을 하나씩 살펴보겠습니다.

배터리

휴머노이드 로봇은 균형을 맞추어 걷거나 팔을 움직이는 등 다양한 동작을 하는데요. 이런 동작은 에너지 소모가 큰 편입니다. 그래서 로봇의 체력이라 볼 수 있는 배터리가 든든하게 뒷받침되어야 합니다. 하지만 아직은 배터리의 에너지 밀도, 즉, 무게 대비 에너지 용량이 충분하지 않습니다. 결국 로봇의 활동 시간이 제한될 수밖에 없지요. 현재 대부분의 휴머노이드 로봇은 완전충전 후 평균 1~2시간 정도밖에 작동하지 못한다고 합니다. (물론 이 문제를 해결하기 위한 연구가 꾸준히 진행되고 있고, 실제로 최근 리튬이온 배터리의 에너지 밀도는 매년 약 5~8%씩 꾸준히 높아지는 추세입니다.)

고성능/저전력 AI 칩

휴머노이드 로봇이 정말 ‘똑똑한 로봇’으로 활약하려면, 눈으로 사물을 인지하고 언어를 이해하며 자율적으로 움직이는 작업들을 빠르게 처리할 강력한 두뇌 역할의 칩셋이 필요합니다.

액추에이터(actuator)

로봇이 사람처럼 자연스럽게 움직이려면 관절과 같은 기능을 하는 액추에이터 기술이 아주 중요합니다. 마치 사람의 근육처럼 강력하면서도 미세하게 움직임을 조절할 수 있는 모터와 감속기 기술이 필요한 것이죠. 또 로봇이 너무 무거우면 움직이기 어렵기 때문에, 가벼우면서도 힘이 좋은 액추에이터는 로봇의 성능을 좌우합니다.

상용화를 위한 핵심 기술 <내용: 한재권. 사진 출처: 작가>

그럼에도 한재권 교수는 이런 제약들이 굉장히 빠르게 해결되고 있는 만큼, 실제 현장에 투입되는 휴머노이드 로봇을 2020년대 안에 볼 수 있을 것으로 전망했습니다. 오픈AI의 샘 올트먼과 엔비디아의 젠슨 황이 “2027년에는 휴머노이드 로봇의 상용화가 가능할 것”으로 예측한 것과 유사합니다.

로봇을 학습시키는 법: 따라 하고, 상상하라!

휴머노이드 같은 범용 로봇이 실제로 우리에게 도움을 주려면, 튼튼한 몸과 뛰어난 두뇌 칩만큼 중요한 것이 또 있습니다. 바로 ‘학습’입니다. 아무리 근사한 로봇이 있어도 정작 할 줄 아는 게 없다면 고철 덩어리에 불과하겠죠.

기존의 산업용 로봇은 미리 정해진 똑같은 작업만 반복하도록 프로그래밍 되어 왔습니다. 그러나 휴머노이드와 같은 범용 로봇은 새로운 상황에도 스스로 적응할 수 있어야 합니다. 그래서 현재 로봇 연구자들은 ‘모방 학습(imitation learning)’이나 ‘강화 학습(reinforcement learning)’ 같은 AI 학습 기법을 적극 활용하고 있습니다.

그중에서도 ‘모방 학습’이란, 단어 그대로 사람의 시범을 모방하며 배우는 방식인데요. 예를 들어, 사람이 어떤 물체를 집어 옮기는 모습을 여러 번 보여주면 로봇은 그 데이터를 보고 행동을 학습하는 것입니다. 이런 시범 데이터는 사람의 움직임을 캡처하거나, VR 기기를 사용해 로봇을 조종한 데이터를 모으는 등 여러 방법으로 구축할 수 있습니다. 이렇게 배우면 비슷한 상황을 만났을 때 로봇은 마치 사람처럼 자연스럽게 행동할 수 있습니다. 마치 아기 사자가 어미를 보며 사냥하는 법을 배우듯 로봇도 사람의 모습을 보고 따라 하면서 지식을 습득하는 것이죠.

인간이 원격 제어로 로봇에게 행동을 학습시키는 모습 <출처: 논문 <RoboCopilot: Human-in-the-loop Interactive Imitation Learning for Robot Manipulation>>

다만 이 방법에도 한계는 있습니다. 사람이 모든 행동을 일일이 보여주기에는 시간이 오래 걸리고 그 범위도 제한된다는 것입니다. 모든 동작에 대해 시범을 보이기란 사실 불가능에 가깝습니다.

로봇 시뮬레이터, 아이작심(Isaac Sim)이란 무엇일까?

이 문제를 해결할 수 있는 핵심 비결은 ‘시뮬레이션’입니다. 특히 ‘아이작심(Isaac Sim)’ 같은 로봇 시뮬레이터를 이용하면, 가상환경에서 거의 무제한에 가까운 행동 데이터를 만들어낼 수 있습니다.

아이작심(Isaac Sim)은 엔비디아가 개발한 로봇 시뮬레이션 플랫폼입니다. 물리 기반의 3D 가상 환경에서 다양한 로봇을 시뮬레이션하고 학습시킬 수 있는 도구인데요. 시각적으로 정교할 뿐 아니라, 매우 현실적인 물리 환경에서 다양한 시뮬레이션을 수행할 수 있습니다.

아이작심 사용자 화면. 물건을 인지하고 집는 시뮬레이션 중이다. <출처: 엔비디아>

사용자는 이 가상 환경 안에서 로봇 모델과 센서, 작업 환경 등을 설정할 수 있습니다. 그런 다음 로봇의 행동을 수천~수만 번 반복하며 강화 학습이나 모방 학습에 필요한 데이터를 빠르게 축적할 수 있습니다. 물리 엔진과 3D 그래픽으로 현실과 유사한 가상 세계를 만들어 놓고, 그 속에서 로봇 수천 대를 동시에 돌리며 훈련시키는 방식입니다. 대량의 합성 데이터를 로봇의 머리에 채워 넣는다고 볼 수 있죠.

이렇게 하면 실제 로봇을 사용하지 않고도 다양한 환경과 작업 조건으로 로봇을 교육할 수 있습니다. 실제 로봇 한 대로는 하루 종일 움직여도 겨우 몇 시간 분량의 데이터밖에 못 모으지만, 아이작심의 가상 세계에서는 시간과 로봇 숫자를 수백~수만 배로 늘릴 수 있습니다. 엔비디아 연구원 짐 팬(Jim Fan)에 의하면, 휴머노이드 로봇은 아이작심으로 1년 치 움직임 학습을 1시간 만에 완료한 사례도 있다고 합니다. 마치 영화 속 닥터 스트레인지처럼 시간을 조절하면서 로봇에게 막대한 양의 훈련을 시킬 수 있는 것입니다.

시뮬레이션의 또 다른 장점은 안전과 경제성에 있습니다. 실제 로봇으로 학습하면 시행착오 과정에서 부딪히고 넘어지면서 망가질 위험이 큽니다. 하지만 가상 환경에서는 아무리 부서져도 리셋하면 그만입니다. 게다가 현실에서는 재현하기가 위험하고 어려운 화재 현장 또는 우주와 같은 환경도 디지털 세계에서는 무한히 생성하며 로봇을 단련시킬 수 있습니다.

아이작심 사용자 화면. 철로에 떨어진 물건을 인지하는 시뮬레이션 중이다. <출처: 엔비디아>

이렇게 시뮬레이터에서 훈련된 정책 모델을 실제 로봇에 이식하면 어떨까요? 처음 접한 현실에도 당황하지 않고 침착하게 대응할 수 있을 것입니다. (물론 가상 환경과 현실 사이 차이(sim-to-real gap)를 극복하기 위한 기술이 필요합니다.)

코스모스: 세계 모델(World Model)의 등장

아이작심(Isaac Sim)이 로봇이 다양한 상황에 잘 대처할 수 있도록 가상 데이터를 만들어내는 시뮬레이션 플랫폼이라면, 이렇게 만들어진 데이터를 학습해 로봇이 실제 세상을 이해하고 미래를 예측할 수 있게 도와주는 AI도 필요합니다. 최근 주목 받는 AI는 역시 엔비디아가 만든 ‘코스모스(Cosmos)’입니다. 엔비디아 CEO 젠슨 황이 로봇 상용화에 유독 자신감을 보이는 이유가 여기 있죠.

코스모스는 시각 정보와 언어, 그리고 로봇의 동작을 모두 입력받아 앞으로 일어날 상황을 예측한 영상을 생성하는 멀티모달 AI 모델입니다. 카메라에 비친 현재 장면과 텍스트 형태의 지시를 함께 입력하면, 로봇이 그 지시에 따라 행동할 때 어떤 일이 벌어질지를 시뮬레이션 영상으로 미리 생성해 주는 것입니다.

코스모스 시뮬레이션에서 로봇이 인식하는 세계의 모습 <출처: 엔비디아>

엔비디아는 코스모스를 ‘월드 파운데이션 모델(World Foundation Model)’이라고 부르며, AI가 현실 세계를 이해하도록 돕는 가상 물리 세계 엔진으로 설명합니다.

이 모델은 무려 2,000만 시간 분량의 비디오 데이터로 학습했다고 합니다. 하루 24시간 내내 쉬지 않고 본다고 해도 2,283년이 걸릴 정도의 데이터죠. 코스모스는 이 데이터에서 물체의 움직임과 상호작용, 그에 따른 결과로부터 중력, 마찰, 충돌 같은 물리 법칙들을 내재화했습니다. 예를 들어, 공이 굴러가는 영상을 수백만 시간 보면서 중력과 마찰의 효과를 익히고, 자동차가 달리는 영상을 수천만 시간 보면서 교통 상황의 패턴을 파악하는 방식입니다.

그렇게 코스모스는 단순히 픽셀을 흉내 내는 것이 아니라 현실의 규칙을 이해하고 표현하는 수준까지 도달했습니다. 실제 코스모스로 만든 영상은 물체의 무게나 움직임, 충돌 후의 상황까지도 실제 물리 법칙에 부합하도록 표현할 수 있습니다. 즉, 사람이 시나리오를 일일이 설계할 필요 없이 AI가 학습 시나리오를 만들고 로봇이 그것을 보면서 배우는 시대가 열린 셈입니다.

마치며

국제로봇연맹(IFR)에 따르면, 우리나라는 제조업 분야에서 노동자 1만 명당 산업용 로봇 1,012대를 사용하는 나라로 이 분야 세계 1위를 기록했습니다. 2위인 싱가포르(730대)와도 꽤 큰 격차입니다. (2022년 기준)

제조업 로봇 사용량 순위 <출처: IFR(International Federation of Robotics)>

이처럼 전자, 자동차, 조선 등 다양한 분야에서 쌓은 정밀한 생산라인과 자동화 기술에 바탕해 우리나라는 로봇을 활용하는 데 이미 익숙한 나라입니다. 특히 이번 ‘테크콘2025’에서는 대한민국의 로봇 기반 물류, 제조, 자율주행, 그리고 휴머노이드 기술들을 접할 수 있었는데요. 수많은 연구자가 보이지 않는 곳에서 얼마나 치열하게 기술 개발에 몰두하는지 새삼 느낄 수 있었습니다.

물론 지금 당장은 엔비디아를 비롯해 미국과 중국이 조금 더 앞서 있다고 할 수 있겠지만, 사실 로봇 산업은 이제 막 출발선을 지났다고 봐도 좋습니다. 무엇보다 로봇 산업의 최종 승자는 단순히 더 많은 로봇을 보유한 것이 아닌, 누가 더 빨리 로봇에게 똑똑한 두뇌를 장착하느냐에 따라 결정될 것입니다. 국내 로봇 산업의 발전을 응원하며 지켜보겠습니다.

]]>

F1은 왜 클라우드 위에서 달리게 되었나

넷플릭스에서 방영 중인 F1 다큐멘터리 ‘F1, 본능의 질주’ <출처: 넷플릭스>

넷플릭스(Netflix)의 다큐멘터리 ‘F1, 본능의 질주’가 인기를 얻으며 F1에 관심을 가지는 사람들이 점점 많아지고 있다. 물론 국내에서 F1은 상대적으로 비인기 종목이지만, F1의 2024년 연간 매출은 36억 5천만 달러에 달하며 시청자 수는 7억 명을 돌파했다. 전 세계에서 가장 인기 있는 스포츠 중 하나로 확고히 자리 잡은 것이다.

그에 비해 F1이 IT 클라우드 산업과 가장 밀접한 스포츠 산업이라는 사실은 비교적 덜 알려져 있다. 레이싱 전략 수립부터 실시간 중계 서비스에 이르기까지, F1은 모든 과정에서 클라우드를 매우 적극적으로 활용하고 있다. ‘클라우드 위에서 달린다’고 표현해도 과언이 아닐 정도다.

주말마다 쏟아지는 1.5TB 규모 데이터

레이싱카 한 대에는 약 300개 내외의 센서가 부착되어 있으며, 이 센서들은 초당 약 110만 개에 달하는 데이터 포인트를 생성한다. 레이싱카의 속도, 타이어의 수명과 온도, 중력가속도, 드라이버의 주행 패턴, 날씨 등 매우 다양한 데이터가 실시간으로 쏟아지는 것이다. 또한 드라이버들이 착용하는 장갑에도 센서가 내장되어 있어, 사고 발생 시 피해를 최소화하고 신속한 구조를 지원하도록 생체 신호 데이터를 모니터링한다.

이렇게 수집된 데이터는 다양한 곳으로 전송된다.

현장의 피트 월*과 엔지니어: 레이싱 전략 운영, 모니터링, 드라이버 피드백 등
공장: 경주 후 분석, 시뮬레이션 설계 개선 등
국제자동차연맹(FIA, F1 주관 기관): 규정 준수 모니터링, 실시간 중계, 사고 상황 분석 등

* 피트 월(Pit Wall): 팀 관계자들이 레이스 모니터링, 전략 운영, 드라이버 커뮤니케이션 등을 진행하는 공간

F1 레이싱카에는 300개 내외의 센서가 부착된다 <출처: Mercedes-AMG Petronas Formula One Team 유튜브>

맥라렌(McLaren)에 따르면, 레이스가 열리는 주말마다 수집되는 데이터의 용량은 약 1.5TB에 달한다고 한다. 이처럼 방대한 데이터를 빠르게 전송하고 분석, 저장 및 활용하려면 고성능 인프라가 필수적이다.

이는 팀과 드라이버만의 문제가 아니라, 실시간 중계 환경에서도 동일하게 적용된다. 예를 들어 서버리스 컴퓨팅, GraphQL API, 메시징 대기열 등 서비스를 연결해 경기 중 측정된 데이터를 유의미하고 순차적인 정보로 변환하며, 이렇게 처리된 데이터는 스토리지와 콘텐츠 전송 네트워크(CDN)를 거쳐 실시간 중계에 활용된다.

AWS의 클라우드프론트(CloudFront)를 사용하는 F1 생중계는 최고 트래픽 기준 초당 6Tbps 속도로 스트리밍된다고 알려져 있다.

경기당 60억 회의 시뮬레이션

F1 레이스에는 10개 팀 소속의 드라이버 20명이 참가하며, 때로는 아주 근소한 차이가 순위를 결정짓는다. 2024년 열린 벨기에 그랑프리에서는 불과 0.647초 차이로 1위와 2위가 갈렸다. 이런 경쟁 속에서 상대를 제치고 승리에 다가가려면, 레이싱카의 속도나 타이어 성능은 물론 다른 드라이버의 행동, 트래픽 상황, 피트 스탑*, 세이프티 카** 투입 여부, 날씨 등 다양한 변수를 예측하고 반영한 전략적 의사결정이 필요하다.

*피트 스탑(Pit stop): 타이어 교체, 연료 보급, 차량 수리 등을 위해 피트 레인(Pit lane)에 정차하는 것. F1 드라이버는 레이스당 평균 2회의 피트 스탑을 실시한다.

**세이프티 카(Safety car): 레이스 중 충돌이나 사고 등으로 위험 상황이 발생했을 때 투입되어 레이싱카들의 감속을 유도하는 차량. 세이프티 카가 출동하면 자연스럽게 차량 간 간격이 줄어들어, 시간 측면에서 피트 스탑을 진행하기 유리하기 때문에 레이싱 전략에서 주요 변수로 작용한다.

이때는 무작위 샘플링을 기반으로 반복 실험을 수행하여 확률 분포를 근사하는 ‘몬테카를로 시뮬레이션’을 활용해 예측 정확도를 높인다. 예를 들어 피트 스탑 타이밍에 따라 레이스 결과가 어떻게 달라지는지를 수천 번 반복해 분석하거나, 다른 레이싱카를 뒤따라 주행할 때 공기역학적 측면에서 어떤 차이가 생기는지 미리 살펴볼 수 있다.

F1에서는 몬테카를로 시뮬레이션을 통해 예측 정확도를 높인다. <출처: Formula 1 Dictionary>

실제로, 레드불 레이싱은 한 시즌 기준으로 레이스마다 약 60억 회의 시뮬레이션을 수행한다. 누적 기준으로는 무려 1,500억 회 이상 진행하는 것이다. 주어진 시간 내에 충분한 시뮬레이션을 실행해 불확실성을 낮추려면, 역시나 인프라가 뒷받침되어야 한다. IT 인프라 경쟁력이 곧 의사결정의 핵심이며, 레이싱 팀의 경쟁력으로 이어지는 것이다.

레이싱카 한 대의 제작비는 평균 1,600만 달러

모든 자동차 제조업체가 고성능 컴퓨팅 환경을 필요로 한다. 그러나 일반 자동차 제조업체와 F1 대상 제조업체가 명확히 구분되는 점은, 개별 레이스마다 해당 서킷의 특성에 따라 레이싱카를 매번 세팅하고 조정해야 한다는 것이다.

F1 팀은 레이스가 펼쳐지는 지역과 서킷의 특성에 맞는 전략을 수립한다 <출처: F1>

F1은 세계 각국을 돌며 레이스를 펼친다. 올해만 하더라도 3월부터 12월까지 아시아, 중동, 미국, 유럽 등 24개 도시에서 경주가 펼쳐지고 있다. 서킷마다 코스 형태와 추월 난이도가 달라짐은 물론 지역의 특성이나 계절에 따른 기후까지 신경써야 한다. 그러므로 레이싱카의 최적화는 필수적인 과정이다.

예를 들면, 레이스 현지 기후에 따라 타이어 마모 속도나 엔진과 브레이크의 성능이 달라진다. 겉모습은 비슷해 보일지라도, 평균 기온이 27°C였던 2024 마이애미 그랑프리와 14°C였던 라스베이거스 그랑프리에 투입된 레이싱카 사이에는 큰 차이가 있을 것이다.

디지털 트윈을 적극적으로 활용하는 F1 <출처: 오토데스크>

게다가 국제자동차연맹(FIA)은 매년 ‘비용 상한제’(Cost cap)를 통해 각 팀의 연간 지출 비용 상한선을 설정한다. 또한 레이스 전에 차량을 실제 주행 환경에서 테스트할 시간 역시 제한적이다.

F1 레이싱카 한 대를 제작하는 데 약 1,600만 달러가 든다는 점까지 감안하면, 비용과 시간의 제약 속에서 최적의 성능을 내는 차량을 만들어내기는 쉬운 일이 아니다. 따라서 이를 위해 실시간 데이터 반영, 설계안 도출, 시뮬레이션 실행 등이 가능한 ‘디지털 트윈’(Digital Twin) 환경 구축이 필요하다.

빠르게 확대되는 클라우드의 역할

2022년, 클라우드 기업 오라클(Oracle)과 파트너십을 체결한 레드불 레이싱은 클라우드 활용 영역을 꾸준히 넓혀가고 있다. 특히 2025 시즌 개막과 함께, 파워트레인 개발과 인프라 표준화, 팬 대상 캠페인 활성화 등 분야에도 클라우드를 더욱 적극적으로 활용할 것을 밝혔다.

오라클의 생성형 AI 솔루션을 이의 제기에 활용하기로 한 점도 주목할 만하다. F1 레이스에서는 경기가 끝난 후, 경기 중 발생한 오류나 불공정성, 규정 위반 등에 대해 이의를 제기할 수 있다. 1년간 단 24번의 레이스만이 진행된다는 점을 고려하면, 드라이버와 팀의 순위를 뒤바꿀 수도 있는 이의 제기는 무척 중요하다.

그러나 이의를 제기할 수 있는 시간은 경기 종료 후 30분에 불과하다. 수천 페이지에 달하는 규정을 검토하고 이의 제기에 적합한 사유를 찾기에는 결코 충분하지 않은 시간이다. 레드불 레이싱은 여기에 RAG(검색증강생성)과 LLM(거대언어모델)을 결합한 오라클의 생성형 AI 솔루션을 활용하고 있다. 규정을 실시간으로 조회하고, 응답을 생성할 수 있게 된 것이다. 차량 개발이나 전략 수립 분야를 넘어 다른 영역에서도 클라우드와 AI 기술이 중요한 역할을 맡은 것이다.

F1과 AWS의 긴밀한 협업

개별 팀뿐 아니라 F1 차원에서도 클라우드를 무척 적극적으로 활용하고 있다. F1은 지난 2018년 AWS를 공식 클라우드 및 머신러닝 파트너로 지정한 이후, 65년 치 레이스 데이터의 마이그레이션, 데이터 분석 환경 구축, 생성형 AI 기반의 ‘Statbot’ 개발, 트로피 디자인 등 다양한 영역에서 협업을 이어오고 있다.

F1과 AWS 협업으로 탄생한 솔루션 ‘Track Pulse’의 인터페이스 <출처: AWS 블로그>

F1이 데이터 기반의 스포츠로 거듭나며 클라우드와 AI, 머신러닝, 디지털 트윈 등의 중요성은 더욱 높아지고 있다. 그런 만큼 앞으로 F1과 AWS 간의 협력 범위는 더욱 확대될 것으로 보인다.

개발자라면 F1 자체는 낯설지라도, F1 소속 엔지니어가 수행하는 업무는 오히려 익숙하게 느껴질 수 있다. F1의 시니어 클라우드 엔지니어 채용 공고를 살펴보면, AWS 관련 역량이 명시되어 있다.

F1의 시니어 클라우드 엔지니어 채용 공고 <출처: Formular 1 링크드인>

공고를 보면 7년 이상의 IT 분야 경험, 4년 이상의 AWS 사용 경험(VPC’s, EKS, EC2, IAM, Route53, S3), AWS 클라우드 네트워킹 경험(Direct Connect, VPC’s, Transit Gateways)과 광범위한 쿠버네티스 실무 경험 등이 요구된다. 이 직무가 고성능 클라우드 및 쿠버네티스 환경에서의 인프라 설계와 운영을 담당하는 역할이라는 점을 어느 정도 추측해 볼 수 있다.

마치며

그동안 F1은 ‘자본의 스포츠’라는 인식이 강했으나, 비용 상한제 도입 등을 통해 보다 공정하고 가치 있는 스포츠로 변화하기 위한 노력을 이어가고 있다. 이 과정에서 데이터 기반 전략 수립을 위한 클라우드의 활용 범위와 기술 수준은 각 팀의 경쟁력과 직결되고 있다. 이로써 F1은 더욱 본격적인 ‘데이터 중심 스포츠’로 진화할 것으로 기대된다.

나아가 F1의 클라우드 활용 방식과 비중, 범위 등을 살펴보면, 다른 스포츠 산업의 미래를 가늠할 흥미로운 인사이트를 찾을 수 있을 것이다.

<참고 자료>

How Does F1 Make Money? Inside F1’s Billion-Dollar Business Model/ F1 History
Formula 1 Now Sees 750 Million Fans Due To Growth With Women And Middle East/ Forbes
F1® on AWS/ AWS
Everything you need to know about F1 safety gear - including key safety features/ Autosport
How Formula 1 Car Sensors Create Data at Every Turn/ Purestorage
Feature: Data and Electronics in F1, Explained!/ Mercedes-AMG PETRONAS F1 Team
How Formula One works with AWS to drive data insights/ Tech Target
Race Strategy/ Formula 1 Dictionary
Oracle Red Bull Racing/ Oracle
Formula 1 is Leading the Digital Twin Technology/ London Digital Twin Research Centre

]]>

SI 현장에서 바라본 ‘소프트웨어 개발의 역사’

SI 산업 가이드북 ⑮

부트캠프를 수강하는 학생들이 제게 묻고는 합니다.

학생: 멘토님. 상속은 왜 받는 거예요? 이렇게 실행해도 되는데 꼭 그렇게 해야 하나요?

나: 음, 그렇긴 하지만 이건 이렇고 저건 저렇고….

상속, 의존성, 단일 책임. 코딩을 배우러 온 학생들에게, 소프트웨어 개발의 영역은 모르는 용어 천지입니다. 왜 하는지도 모르겠습니다. 프론트엔드, 백엔드, 풀스택. 뭘 배워야 할지, 어떻게 해야 할지도 모르겠습니다.

이런 학생들에게 저는 소프트웨어 개발의 변천사를 이야기해줍니다. 큰 맥락을 알면 조금은 눈에 보이니까요. 나머지는 구글이나 챗GPT에 물어보면 됩니다.

그렇게 들려주던 이야기를 정리해 봅니다. 천공카드에 펀칭으로 코딩하던 시절은 건너뜁니다.

한국 소프트웨어 개발 현장의 변화

1980년대: 상업용 코딩의 시작

1980년대 은행의 Host-Terminal 구조 <출처: 작가>

1980년대. 은행으로 가보겠습니다. 직원들 앞에는 모니터와 키보드만 있었습니다. 컴퓨터 본체가 없었죠.

본체는 같은 건물 전산실에 있었습니다. 선을 길게 끌어와서 은행 창구에 모니터를 설치했죠.

컴퓨터가 비싸니 본체 한 대에 여러 대의 모니터, 키보드를 달아서 나눠 쓰는 방식이었습니다.

그 컴퓨터를 영어로는 메인 프레임(main frame), 한글로는 주전산기라 불렀습니다.

은행 프로그램은 메인 컴퓨터에서 실행되었습니다. 이를 “호스트(Host, 주인)”라 불렀습니다. 서버라고 부르지 않았습니다.

모니터, 키보드는 연결선 끝에 있으니 “단말(端末)”이라고 불렀습니다. 영어로는 “터미널(Terminal)”이었죠.

그래서 이 구조를 호스트-터미널(Host-Terminal)이라고 불렀습니다.

물리적으로 연결할 수 있는 케이블 수에는 제한이 있었습니다. 최대 12~32개 정도? 연결 단자 수가 그것밖에 안 되었습니다. 이 숫자가 “동시접속자 수”입니다. 공유기를 달아 이 숫자를 늘렸습니다.

지금이야 랜 케이블 하나로 여러 대의 접속 요청을 처리하지만 이 때엔 그런 기술이 없었습니다. 공유기를 설치하는 것도 나름 어려운 기술이었죠.

호스트 내부의 소프트웨어 하나가 여러 터미널에서 오는 INPUT을 처리했습니다. 개발자는 1인용으로만 코드를 만들었죠. 각 터미널에 맞게 대응해 주는 건 CPU와 실행 프로그램의 몫이었습니다. 멀티태스킹의 초기 형태인데 “시분할 방식”이라고 불렀죠.

예금조회화면 Cobol 예제 <출처: 작가, 챗GPT로 제작>

상업용 언어로는 Cobol을 썼습니다. 순차형 언어다 보니 화면과 로직을 나눌 수 없었죠. 그 때문에 그냥 print 문으로 화면을 그렸습니다. 그래서 화면 하나에 업무 한 개, 로직 한 개를 연결할 수밖에 없었습니다.

자연스레 개발량을 화면 개수로 측정했습니다. 단위를 “본(本)”이라고 불렀는데, 이건 “페이지”의 일본식 한자 표현입니다. 초창기에는 메인 프레임을 일본에서 수입했거든요.

네트워크가 느렸습니다. 전화선을 이용했죠. 낮이면 전화선이 붐벼서 전송 속도가 느려졌습니다.

오후 6시. 명동지점에서 일 결산이 끝나면 중앙 센터로 데이터를 전송해야 했습니다. 그래야 전체은행의 일 결산이 끝나니까요. 하루치 데이터를 묶은 다음 압축해서 전송했습니다. 이런 묶음처리를 “배치(Batch) 작업”이라고 불렀죠.

“본”, “배치 처리” 같은 용어가 이때 자리를 잡았는데, 아직도 쓰이고 있습니다.

즉, “화면 개수 + 배치 프로그램 수 = 개발량”이었습니다. 거의 정확했죠.

DB는 만들어서 썼습니다. 파일로 저장하는 방식인데 이걸 ISAM DB라고 불렀습니다. Linked List 같은 알고리즘을 원시적으로 구현해야만 했죠. 삼성과 LG 등 회사마다 개발한 게 달랐습니다.

동시 처리를 하다 보니 데이터 중복이 발생하는 경우도 많았죠. 알고리즘을 잘 설계해야 했습니다.

이때는 “소프트웨어를 설치한다”는 개념이 없었습니다. 메인 프레임이 움직이도록 하드웨어를 “프로그래밍” 한다는 개념이었죠. 그래서 개발자라기 보다는 “프로그래머”라고 불렀습니다.

삼성전자 같은 기업이 “메인 프레임”을 고객 요구에 맞춰 프로그래밍한 후 납품을 했습니다. 개발 가격은 장비 가격에 합산해서 청구했죠. 제법 큰 돈이 되었습니다. 1990년대 후반까지도 이랬습니다.

1990년대: PC 프로그래밍의 시대

1990년대 클라이언트, 서버 구조 <출처: 작가, Time traveler 유튜브 참조>

초기 버전 컴퓨터인 XT, AT는 건너뜁시다. 1990년대 후반, 80386 PC와 함께 윈도우가 보급됩니다.

PC 성능도 좋았고, 멀티태스킹도 가능했죠. 기업들은 성능이 좋아진 PC를 업무 처리에 쓰고 싶어 합니다. 서버 비용을 줄이고 싶어서죠. 당시 서버용은 하드디스크, CPU, 메모리까지 모두 비쌌습니다.

기술 구조가 변합니다. PC에서 중앙센터의 데이터를 불러와 처리한 후 다시 중앙센터에 저장하는 방식으로 말이죠. “클라이언트-서버” 구조라고 합니다.

중앙센터가 데이터를 나누어 주므로 “서버”, PC 는 데이터를 받아 가므로 “클라이언트”라고 불렀습니다.

처음에는 SI 회사들이 서버, PC, 프로그램을 함께 묶어 납품했습니다. 통합 견적이었죠.

하지만 국산 PC가 등장하며 가격이 저렴해지자 상황이 달라집니다. 기업들이 PC를 따로 샀거든요. 옛날 PC를 그대로 쓰기도 하죠. SI 회사들은 PC를 빼고 납품하기 시작합니다.

그래서 개발 비용을 장비 가격에 포함시킬 수 없게 됩니다. 개발비를 따로 청구해야 했죠. 그런데 계산 기준이 SI 회사마다 케바케입니다. 갑자기 정부가 난감해집니다. 통일된 기준과 근거가 있어야 하거든요. 1997년 “소프트웨어 대가기준”을 만들게 됩니다. 귀찮으니 일반 기업도 따라하게 되죠.

이 기준에 따라 만든 소프트웨어는 삼성, LG, 삼보 등 다양한 PC에서 똑같이 실행되어야 하니 호환성이 중요해집니다. 서버에서 개발할 것도 많아집니다. 버전 관리, 데이터 관리, 백업 관리 등이 추가되자 ‘단순 화면 수’ 말고도 개발량 산정 기준이 필요해지죠.

당시 현장 관리자가 대충 묻습니다. “얼마나 걸릴 것 같아요?”

개발자들이 어림잡아 대답합니다. “3개월이면….”

“넵, 3개월.” 이렇게 개발 기간 산정 방식이 굳어집니다.

이때는 대부분의 기능을 PC에서 처리하면 Fat(Thick) Client, 서버가 처리하면 Thin Client라 불렀습니다. PC, 서버가 기능을 나누어서 담당하는 구조도 있었죠. 상황은 케바케였습니다.

프로그램이 PC와 서버로 나뉘어지니 프로젝트 관리도 복잡해집니다. 이제는 메인 프로그램 하나만 관리하면 안 되었거든요. PC, 서버를 따로 개발한 후 합쳐야 했습니다. “통합 테스트”가 등장하죠.

간혹 옛날 방식으로 프로젝트를 관리하기도 했습니다. 그러면 일정 관리와 테스트가 다 달라져서 문제가 되었습니다. 선 반영 후 수습으로 진행했죠.

2000년대: 웹 개발의 등장

2000년대 웹 개발의 시대 <출처: 작가>

클라이언트 프로그램은 단점이 있습니다. PC가 버벅대면 데이터 전송도 늦어진다는 겁니다. “윈도우 프로그램”이었거든요.

경마장에선 큰 일이었습니다. 경기 시작 전마다 마권 창구가 미어 터졌거든요. PC가 버벅댄다고 늦어지기라도 하면 난리가 났습니다. 돈이 걸린 일이니까요. 그래서 “미들웨어”가 등장합니다. PC는 가볍게 화면만 보여주고, 무거운 업무 기능은 “서버”가 담당했죠. 이를 연결하는 걸 “미들웨어”라 불렀습니다.

시간이 지나면서 미들웨어가 웹페이지를 지원합니다. Weblogic 같은 프로그램이 나옵니다. 이런 프로그램들을 “웹 어플리케이션 서버”*라 부르게 되죠.

*웹 어플리케이션 서버(WAS, Web Application Server): 서버용 코드를 실행시키는 프로그램인데, 웹 전용으로 쓰이면서 붙여진 말입니다. 일반 프로그램은 Application Server라고 부릅니다.

최초의 웹페이지는 “워드 문서”를 대체하기 위해 나왔습니다. 그래서 저장된 페이지만 보여줄 수 있었죠. 동적 표현은 불가능했습니다. 하지만 JavaScript가 나오면서 간단한 동적 표현이 가능해졌고, 웹 서버가 나오면서 커다란 데이터를 출력할 수 있게 되었습니다.

초기에는 웹 화면이 간단하다 보니 로직 속에 뭉쳐서 한 개발자가 만들었습니다. 그래서 그냥 “웹 개발자”라고 불렀습니다. 하지만 단점이 있었죠. 메인 로직과 화면을 잘 분리해서 만들어야 했다는 겁니다.

화면이 100개를 넘어가면 서버 기능은 300~400개를 넘어갑니다. 양이 너무 많아 관리가 안 되었죠. 또, 함께 일하는 개발자마다 코딩 스타일도 달랐습니다. 소스코드가 중구난방이었죠.

MVC 패턴이 생기고 Java Spring이 등장합니다. HTML, CSS가 진화합니다. 그에 맞춰 웹 브라우저가 발전합니다. jQuery가 나타납니다. Ajax가 등장하고, Node.js가 발표됩니다.

이제 웹 화면은 완전히 동적으로 예쁘게 만들 수 있게 됩니다. 마치 윈도우 프로그램처럼요.

코딩이 아주 복잡해집니다. “프론트엔드”라는 분야가 등장하죠.

메인 로직 개발은 “백엔드”로 불리게 됩니다. 처음에는 “백엔드 개발자”가 로직 개발만 했지만, 지금은 DB 관리를 하기도 합니다.

테스트, 코드 관리 체계도 복잡해집니다. 공용 라이브러리도 중구난방이 되죠. 수십 명의 코드를 모아 하나의 바이너리로 만드는 것 자체가 복잡해지죠.

Gradle의 조상 격인 Ant가 등장합니다. 덕분에 IDE도 복잡해집니다. Eclipse(Java IDE)가 메모리를 1GB씩 먹었죠. 컴파일을 돌리는 데만 1시간이 넘게 걸렸습니다. 테스트 한 번 하는 게 일이었죠.

“프로젝트 관리”는 산으로 갑니다. 일정 관리를 너머 소스 관리, 통합빌드 관리까지 해야 했죠. 옛날 기술들과 달라서 위험 관리, 일정 관리, 이슈 관리 방법도 달라져야 했습니다. 하지만, 어떻게 해야 할지 몰랐죠.

한편 작업량과 일정 예측도 시급했습니다. 그래야 예산을 잡고 프로젝트를 시작할 수 있으니까요.

미들웨어 등장 후 화면 수 산정 방식은 버려졌습니다. 기능 점수(Function Point) 방식이 등장하죠. 우당탕탕 잘 되진 않았습니다. 이것도 딱 나누기 어려운 게 많았거든요.

프론트엔드, 백엔드로 나눠지면서 개발량 산정은 저세상 복잡도가 됩니다. 계산 방식도 어려울뿐더러 산정했다 하더라도 실제와 전혀 맞지 않았죠. 대부분 다시 M/M(맨먼스)* 산정방식으로 돌아옵니다.

*M/M(맨먼스): Man per Month의 약자로, 한 달에 몇 명의 개발자가 투입되어 일해야 하는가를 기준으로 비용을 산정하는 방식입니다. 개발자 한 명의 하루 작업량을 예측해서 데이터를 뽑습니다.

2010년대: 네트워크의 시대

2010년대 인터넷의 시대 <출처: 작가>

PC, 유선 인터넷의 보급과 함께 무선 통신이 발전합니다. 그리고 2010년, 한국에도 아이폰이 출시됩니다.

새로운 아이디어, 새로운 비즈니스가 우후죽순 쏟아집니다. Node.js 같은 경량 플랫폼이 등장하죠. 화면 개발에 빠르게 대응할 수 있게 됩니다.

스마트폰 화면은 작습니다. 웹처럼 넓게 펼쳐놓을 수 없죠. 기능을 보여줬다 감췄다 해야 합니다. UX가 중요해졌죠.

화면 조작이 복잡해지자 코드도 복잡해집니다 프론트엔드가 급격하게 발전하죠. React, TypeScript 같은 프론트엔드 툴들이 쏟아집니다. BootStrap, 머티리얼 등 디자인 툴까지 나오죠. 개발은 어려워진 듯 쉬워집니다.

반면 기술 구조는 복잡해서 개발 관리, 일정 관리 난이도가 하늘 높은 줄 모르고 치솟습니다. 특히 UX 설계는 종료 기한을 만들기 어렵습니다. 이건 유저 반응을 보면서 수정해야 완성도가 높아지거든요. 아웃소싱으로는 한계가 있습니다.

인터넷이 보급되면서 API를 이용한 매쉬업*도 활발해집니다. 이젠 다른 회사 기능을 섞어 내 제품을 만들 수도 있게 되죠. 그러다보니 프론트엔드, 백엔드로만 영역을 나눌 수 없어집니다. 비즈니스 특성에 따라 서버 종류와 구현 방식이 천차만별로 달라지거든요. 그래서 이런 리스크 관리를 하려면 다양한 개발 경험이 반드시 필요했습니다.

*매쉬업(Mash up): 하나 이상의 외부 컨텐츠를 모아 만든 사이트입니다. 예를 들어 기상청 API와 네이버 지도 API를 이용하면 “지도로 보는 기상예보”사이트를 만들 수 있습니다.

과학과 공학, 아키텍처와 속도

더 깊은 이해를 위해 ‘컴퓨터 과학’과 ‘컴퓨터 공학’, 그리고 ‘아키텍처’의 관점에서 발전 역사를 다시 짚어보겠습니다. 생각해 볼 시사점도 함께 정리합니다.

OS의 진화와 Java의 등장

Unix의 역사 <출처: 위키피디아>

초기 컴퓨터는 OS와 프로그래밍 언어가 일체형이었습니다. 전원을 켜면 까만 화면에 커서만 깜빡였죠. 여기다 한 줄 한 줄 코딩을 했습니다. 프로그래밍 언어가 “Fortran”이면 공학용, “Cobol”이면 상업용 컴퓨터라고 불렀습니다.

이때는 컴퓨터를 만드는 게 “과학”이었습니다. 약간 가내 수공업 느낌이었죠. 주문 요구사항에 따라 컴퓨터도 조금씩 달랐습니다. 그러다 보니 컴퓨터 구조도 폐쇄적이었죠. 자체 규격을 쓰다 보니 프린터 등이 호환되지 않았습니다.

Unix가 나오면서 OS와 프로그래밍 언어가 분리됩니다. 이제 컴퓨터를 켜면 파일 복사, 삭제는 할 수 있었지만, 코딩할 수는 없었죠. C/C++, Fortran 등을 따로 설치해야 했습니다. 그걸 실행해야 코딩할 수 있었죠. 보통 텍스트 파일로 길게 만든 후 기계어로 컨버팅을 했는데, 이 과정을 “컴파일”이라고 불렀습니다.

Unix가 “메인 프레임”을 대체하게 된 이유는 Multi User, Multi Processing이 가능했기 때문입니다.

여러 대의 PC가 동시에 접속해도 동시 처리가 가능했었죠. 다른 기종의 접속도 허용하다 보니 설계나 규격이 오픈됩니다. “개방형 시스템”이라고 불렀죠.

DBMS도 설치할 수 있게 됩니다. 춘추전국시대가 열리죠. 여러 대의 PC 요청을 처리하다 보니, 무결성, 일관성, 정규화 등이 중요해집니다. 설계 원칙과 기법들이 정리되죠. 이때 접속 요청을 구분하는 용어가 필요해집니다. “트랜잭션”이라는 용어가 널리 퍼집니다.

“컴퓨터 공학”의 시대였습니다. 표준화, 규격화, 호환성 등이 중요했거든요.

HP, 후지쯔, SUN 등이 성능 경쟁을 합니다. 기업들은 다시 자사 규격을 쓰면서 Unix 커널까지 바꿉니다. 같은 C 프로그램이라고 하더라도 호환되지 않을 정도였죠.

2,000년대 초, 이 문제가 심각해집니다. 10억 들여 만들어 놓은 프로그램이 서버 기종을 바꾸면 동작하지 않았거든요. 특정 하드웨어 회사에 종속성이 생겨 버린 거죠.

이 문제를 해결한 게 Java였습니다. 일종의 소프트웨어 머신을 만들어 버린 겁니다. 기종마다 달라지는 건 Java 팀이 해결하고, 일반 개발자는 Java에만 맞추어 코드를 만들었습니다. 그러면 하드웨어가 달라져도 잘 작동할 수 있었죠.

동시에 Unix를 작게 만들고자 하는 움직임도 있었습니다. 오랜 경쟁 끝에 Linux가 시장을 제패합니다. 클라우드 덕분이었죠. AWS가 Linux를 하나의 애플리케이션으로 만들어 버립니다. 이를 “인스턴스”라고 불렀죠. 일종의 소프트웨어 OS가 되어버린 겁니다.

JavaScript(Node.js), Go, Python 등 언어가 경량화되기 시작합니다. Java처럼 다양한 머신을 지원할 필요가 없었거든요. 지금은 Linux에서만 잘 돌아도 충분하니까요.

메인 프레임(폐쇄형) → Unix(개방형) → 소프트웨어 머신(Java VM) → 소프트웨어 OS(인스턴스, Linux) → 여러 개의 OS(쿠버네티스, Docker, Linux)

하드웨어는 이렇게 소프트웨어로 변해버립니다. 그에 따라 기업용 애플리케이션을 만드는 방식도 크게 달라지죠.

아키텍처의 중요성이 높아지다

2000년대 이전

이때는 “시스템 아키텍처”라는 개념이 없었습니다. 그 정도로 시스템 구성이 복잡하지 않았기 때문입니다. “컴퓨터 설계도”나 “하드웨어 설계도” 정도의 개념밖에 없었죠. 실행프로그램이 한 대의 호스트에서만 돌아가면 되었으니까요.

클라이언트, 서버라고 해봐야 구성품은 “PC 프로그램, DB” 두 개가 전부였습니다. 이때는 “빠른 개발”, “코드 재활용” 등이 중요했습니다. RAD*, CBD** 같은 용어가 뜹니다.

*RAD: Rapid Application Development. 여러 도구를 이용해 코딩 속도를 높이는 방법입니다. 주로 코딩 편의를 높이는 도구들이 IDE에 포함되어 보급됩니다.

**CBD: Component Based Development. 기능을 컴포넌트(모듈)화 시키고, 필요에 따라 조립해서 소프트웨어를 개발하는 방식입니다.

2000년대, 웹 개발의 시대

웹 서버가 등장하자 비즈니스가 폭발적으로 성장합니다. 많은 회사가 웹으로 뭔가를 해보고자 했죠. 비즈니스 복잡도가 높아지며 생기는 문제는 “미들웨어”에서 해결하고자 합니다.* 복잡한 설계철학과 추상화가 중요해집니다. “미들웨어” 자체의 기능도 커지고 무거워집니다.

*Java 플랫폼도 미들웨어에 해당합니다. Java Spring은 웹, J2EE는 서버 개발에 특화된 제품입니다.

기능을 어떻게 그룹화하고 어떻게 배치할 것인가 하는 문제가 중요해집니다. 잘 정리해 놓아야 기능을 추가, 삭제하기 쉽거든요. SOA* 같은 개념이 나옵니다. 메시지 규격도 XML로 구조화시키죠.

*SOA: Service Oriented Architecture. 단순한 라이브러리 개념을 하던 기능 모듈이 호출 가능한 서비스가 됩니다. 서비스를 호출하기 위한 인터페이스를 분리함으로써, 변화하는 비즈니스 요구에 쉽게 대응하려는 설계 패턴입니다.

2,000년대 은행의 SOA 설계도 <출처: IJETAE>

Java는 많은 변화를 겪습니다. 온갖 걸 다 지원하려고 하거든요. Java Spring(웹 개발), J2EE(서버 애플리케이션), Java ME 등으로 분화됩니다. 그러다 어느 순간부터 복잡한 예약어와 규칙들로 감당 불가능한 언어가 됩니다. 배우기 쉽게 시작된 언어가 오히려 배우기 어려워지게 되었죠.

2010년대, 네트워크의 시대

여러 대의 서버가 거대한 하나의 시스템을 구성하게 됩니다. 서버가 많아지고 소프트웨어 구성도까지 복잡해지죠. “미들웨어 고도화”로는 한계에 부닥칩니다. MSA* 같은 개념이 등장하죠.

일(=단위 시스템, 서비스 등)을 잘게 쪼개어 개발 및 관리의 편의성을 높이자고 합니다. 좀 더 큰 조립식 개발 구조를 만들죠.

*MSA : Micro Service Architecture. 서비스를 작게 쪼갠 다음 독립된 도메인으로 만들어서 큰 서비스를 만들자는 방식입니다.

Java가 무겁고 복잡해지자 실리콘밸리에서부터 Node.js 같은 경량 플랫폼으로 갈아탑니다. 복잡성을 미들웨어에서 해결하지 않고, “아키텍처”를 통해 해결하고자 하죠.

단위 기능은 CRUD 같은 단순 처리에 집중합니다. 연결은 API를 활용하고 통신 메시지도 단순화시키죠. REST API와 JSON이 거의 제패합니다.

이 흐름을 부채질한 건 AWS였습니다. 클릭 한 번으로 Linux 서버를 만들 수 있게 되었거든요. 이제는 서비스 단위가 아니라 시스템 단위로 부수고 만들 수 있게 됩니다. EC2, S3, Auto Scaleout 같은 기능들이 추가되자 “복잡한 아키텍처” 만들기도 쉬워집니다. 물론 옛날과 비교해서 말이죠.

서버, 클라이언트 관점의 다양한 스택들 <출처: biosistemika>

플랫폼이 경량화되고 클라우드가 일반화되자 개발자들은 소프트웨어 구성품을 묶어서 다루기 시작합니다. “스택”이라고 불렀죠.

“LAMP 스택”이 특히 인기를 끕니다.

Linux + Apache + MySQL/MongoDB + PHP/Python/Perl의 줄임말로, OS, 웹 서버, DB, 프로그래밍 언어를 함께 패키징한 겁니다.

개념이 생긴 지는 조금 되었는데, 인기를 끌게 된 건 클라우드 때문입니다. AWS에서 인스턴스를 만들면 기본으로 설치되어 있었거든요. CentOS가 “패키지 관리”를 온라인으로 하면서 금방 사라지긴 했지만요.

“기술 스택”이라는 개념이 보편화됩니다. “풀스택 개발자”라는 호칭도 등장하죠.

“스택”을 쓰면 장단점이 있습니다. 조금만 공부해도 적절한 완성도를 만들어낼 수 있죠. 대신 고급 아키텍처를 만들긴 어렵습니다. 어차피 다 분해해야 하거든요.

SI 현장은 어려워집니다.

기업에는 여러 가지 아키텍처가 섞여 있으니까요. 분해해서 써야 하는 경우가 많습니다. 그런데 그런 “아키텍트”를 구하기 어렵습니다. 새로운 걸 가르치는 곳조차 없으니 알아서 익혀야 하죠.

“프로젝트 관리”는 점점 더 미궁 속으로 빠져듭니다. 옛날 방식은 안 통하고 새로운 방식을 배울 곳도 없습니다. 그냥 요령껏 알아서 잘하는 회사만 살아남습니다.

기술 변화 속도는 더 빨라질까

신기술이 빠르게 탄생해도 산업 보급 속도는 느립니다.

클라이언트-서버 환경이 웹 개발로 넘어오는 데 10년 걸렸죠. 웹 개발에서 네트워크의 시대로 넘어가는 데도 10년 걸렸습니다. 대중화 끝물 시점 기준입니다.

기술은 끊임없이 변하는데, 산업 변화는 왜 이렇게 느릴까요?

산업 변화의 주도 세력은 크게 두 부류로 구분됩니다. 일반기업과 스타트업이죠.

일반 기업은 전통적인 방식으로 기술을 받아들입니다. 매출을 높일 수 있거나 비용을 줄일 수 있어야 하죠. 두 가지 중 하나가 보장되어야 기술에 투자를 합니다.

스타트업은 가볍고 빠르게 기술을 받아들입니다. 괜찮겠다 싶으면 만들어 보죠. 투자도 가능성에 합니다. 맨땅이기 때문에 신경 써야할 옛날 시스템도 없습니다. 새로 시작할 수 있죠.

이처럼 신기술은 스타트업이 효과를 입증하면 일반 기업이 사서 씁니다. 사회적 변화 과정이 오래 걸리죠.

그래서 큰 기업들은 가능하면 프로젝트 규모를 키웁니다. 한 번 만들기 어려우니, 만들 때 크게 만드는 거죠. 복잡도는 높고, 요구사항은 많고, 오래 써야 하니, 프로젝트 난이도는 올라갑니다. 관리 위험성도 커지죠. 100% 한 군데 이상 펑크가 납니다.

기술은 이런 위험을 해결하고자 진화합니다. 복잡도가 높아질수록 변화의 속도는 더 빨라지죠. 빨리 해결할수록 돈을 더 많이 벌 수 있으니까요.

기술은 얼마나 더 복잡해질까?

R&D는 논외로 하고 상용 기술에 한해 이야기해 봅니다.

“기술이 얼마나 더 복잡해질까요?”

인스타그램처럼 B2C 분야에서 기술 진화는 “사람 수준”까지 이어져야 합니다. 그래야 돈을 벌 수 있거든요. 사람들이 자연스럽게 지갑을 꺼내는 수준까지 진화하게 됩니다.

웹 개발에서 네트워크로, 서버 한 대가 여러 대로, 구조가 끊임없이 복잡해진 것도 사람처럼 보이기 위해서입니다. 인터넷 쇼핑몰의 복잡한 추천기능은 사실 판매원을 대신하는 겁니다. 더 자연스럽고 취향에 맞게 보여줘 신용카드를 꺼내게 만드는 거죠.

앞으로 이런 기술들은 얼마나 복잡해질까요? 아마 한참 더 복잡해질 겁니다.

“은행” 같은 B2B 분야에선 어떨까요?

B2B 분야의 기술 진화는 “비즈니스 가치사슬을 잘 유지하는 수준”까지 일어납니다.

말이 좀 어렵죠? 쉽게 말하면, 그 기업이 그 산업 속에서 담당하는 역할까지만 진화합니다.

B2B 분야, 특히 사회 인프라는 부품처럼 맞물려 있습니다. 크게 한 번 투자해서 가늘고 오래 사업을 지속하는 구조죠. 서로 구역을 침범하지 않는 묵시적 룰이 있습니다. 이걸 어기면 전쟁이죠.

예를 들어 국민은행과 기업은행은 주력 포인트가 다릅니다. 기업은행은 중소기업 지원을 위해 설립된 은행이라 기업 대출을 잘 해줘야 하거든요. 반면 국민은행은 전세 대금 같은 걸 잘해줘야 합니다.

그리고 은행 앱에는 네이버처럼 배너 광고를 붙이진 않습니다. 은행 사업의 본질이 아니거든요.

일반인용 AI 는 기업에선 큰 도움이 되지 않습니다. 기업 간 특수관계를 학습시키기 곤란하거든요. 색다른 고민이 필요하게 되죠.

B2B 분야에선 비즈니스 흐름이 길어지거나 복잡해지기 어렵습니다. 복잡성이 높아질수록 비용이 커지는데, 인프라형 사업에선 소비자 가격을 높이기 힘들잖아요.

그래서 복잡해지다 임계점을 넘어서면 다시 단순해지는 현상을 반복합니다. 고급 기능을 저렴하게 제공해야 하는 비즈니스 환경인 거죠.

이런 현상은 기술 발전과 아키텍처의 적절성을 이해하는 중요한 시사점을 줍니다. 산업 분야마다 비즈니스 환경이 다르다는 뜻이죠.

더욱 중요해지는 프로젝트 관리

SI 현장은 여전히 복잡합니다. 기술 이슈는 그나마 쉬운 주제이죠. AI의 활용성이 많이 좋아졌거든요.

문제는 프로젝트 관리입니다. “프로젝트 관리”란 기술적, 비기술적 위험 요소를 식별해 내고, 위험 요소를 적절하게 제거해서, 원하는 기간 내에 목표 결과물을 얻어내는 방법론을 말합니다.

프로젝트를 하다 보면 사람마다 이해 수준이 다르고 처리 역량도 달라 반드시 갈등이 생기거든요.

이걸 해소하려면 사람, 서버, 기술 자원 등을 잘 통제해야 합니다. 오케스트라의 지휘자와 같죠. 어렵습니다.

“프로젝트 관리” 기술은 “프로젝트 성공률”로 입증됩니다. SI 기업을 찾은 고객이 일을 맡길 수 있는 지표가 되죠.

그런데 이토록 중요한 프로젝트 관리 노하우는 성장하지 못했습니다. 옛날 것이 잘 작동하지 않고, 새로운 기술은 잘 모르니까요. 가르치기도 배우기도 어려운 상황이죠. 애자일이 잘 나갔지만, 그게 전부는 아닙니다.

앞으론 프로젝트 성공률이 높고 고객평이 좋은 회사가 더욱 돋보일 겁니다. 프로젝트 관리 노하우는 그 회사를 차별화시키는 중요한 요소가 될 거고요. SI 기업이 그러려니 하고 넘길 수 있는 건 아니죠.

그래서 다음엔 SI 기업의 생존과 이어질 중요한 포인트인 “리스크 관리”와 “자원 관리”에 대해 좀 더 자세히 알아보겠습니다.

]]>

SI 프로젝트의 문서는 왜 만들까?

SI 산업 가이드북 ⑭

AI의 시대, 하지만 SI는 갈 길이 멉니다. 옛날에 비해 많이 변하긴 했지만 그래도 여전히 그대로죠.

특히 산출물만큼은 옛스러움을 답습하고 있습니다. 다른 사람에게 일을 맡긴다는 특성상 어쩔 수 없기도 하지만, 산출물 받는 사람들이 개발할 사람이 아니기 때문에 개선할 필요성을 못 느끼거든요. 공공사업 쪽은 규제처럼 정해져 있어 안 만들 수도 없습니다.

그러다 보니 프로젝트에 투입된 초보 개발자는 정말 영문도 모른 채 산출물을 만듭니다. 왜 필요한지, 언제 필요한지도 모르죠. 그래서 진짜 필요한 내용이 안 담깁니다. 최근 어떤 프로젝트에 들어갔더니, 문서는 많은데 볼만한 게 하나도 없더라고요.

그래서 ‘SI 프로젝트 산출물’에 관한 내용을 정리해 보았습니다.

문서화

소프트웨어 문서화에 대한 이해 <출처: CERN>

문서는 왜 만들까요?

좀 오래되긴 했지만, 지난 1998년 스위스의 한 기관이 연구를 했습니다.

“프로젝트팀의 업무 시간은 어떻게 쓰일까?” 이런 주제였죠.

결과가 이렇게 나옵니다.

“프로젝트팀은 전체 시간의 27%를 업무 파악에 쓰고, 고객 요구사항 분석에 24%, 설계에 18%, 구현 18%, 테스트에 13%를 쓴다. 전체 업무의 33%는 재작업에 쓴다.”

재작업이란 소위 삽질을 말합니다.

이 중에서 구현, 테스트는 AI의 도움을 받기에 딱 좋습니다. 하지만, 업무 파악과 요구사항 분석, 설계는 그렇지 못하죠. 기업 업무는 케바케가 엄청 많거든요. AI가 돕긴 하지만, 일일이 확인을 해야 합니다.

즉, 1998년부터 이어져 온 주요 업무의 약 69%는 여전히 사람이 해야 하는 일입니다. 이걸 잘못하면 재작업 33%는 사라지지 않죠.

시스템 구축이란, 세상에 없던 걸 새로 만드는 작업입니다. 그러다 보니 사실 고객도 모릅니다. 뭘 만들어달라고 해야 할지 말이죠. 요구사항을 정리할 수 없으니, 개발할 수도 없죠.

더군다나 개발 과정은 눈에 보이지 않습니다. 문제가 있다면, 뭔가를 볼 수 있을 때쯤 이게 아니라는 걸 깨닫게 되죠. 시간이 한참 흐른 후입니다. IT 프로젝트의 오랜 숙명이죠.

한편 문서는 눈에 보이지 않는 모든 것들을 보이게 만들기 위한 수단입니다. 보면서 오류를 바로잡자는 거죠. 살필 시간이 없다면 문서의 가치는 사라집니다.

그런데 대부분의 SI에는 문서 살필 시간이 없죠. 문서를 보는 것보다 그냥 담당자에게 물어보는 게 제일 정확하고 빠르니까요.

그렇다면 문서는 왜 필요할까요?

첫째, 개발하면서 계속 봐야 하는 문서들이 있습니다. 코드로는 표현 못 하는 전체 그림이죠. 이런 문서는 설계도라고 합니다. 코드를 읽어서 클래스(Class) 간 관계를 확인하는 것보다, 그냥 화살표로 그려진 그림을 보는 게 빠릅니다. 좀 더 한눈에 들어오기 때문이죠.

화살표가 복잡할수록 더욱 그렇습니다. 퐁당퐁당 건너뛰는 트랜잭션이라면 꼭 그림이 있어야 하죠.

둘째, 물어볼 사람이 없는 경우입니다. 개발이 끝나고 운영이 시작되었을 때 이야기죠. 개발한 사람은 없고 복잡한 구조를 설명해 줄 사람도 없습니다. 문서가 유일하게 기댈만한 곳이죠.

그래서 개발 단계에선 “과정 문서”가 많이 필요합니다. 소통에 필요한 내용을 그림으로 표현해 놓은 거죠.

반면 운영 단계에선 “과정 문서”가 필요 없습니다. 나 혼자 일을 하고, 고칠 부분도 많지 않고, 소통할 사람도 적으니까요. 대신 전체 그림이 필요합니다. 그것도 최신판으로요. 내가 딱 고칠 부분만 알아내면 되거든요.

스타트업은 운영 중에 신규 기능을 개발합니다. 그래서 SI 운영보다는 문서가 복잡합니다. 데이터와 기능이 자꾸 변하다 보니 최종 버전 관리가 잘 안되죠. 그냥 적절히 관리합니다.

아무튼 이렇게 문서도 필요에 따라 달라집니다. 필수 문서가 있을까요?

SI 할 때 반드시 작성되는 문서들이 있습니다. 초보자들은 잘 모릅니다. 정리해 봅니다.

업무 구성도

은행 수신 업무 구성도 <출처: 작가>

업무 구성도는 업무를 정리한 그림입니다. 전체 업무와 하위 업무를 상세하게 그려줍니다.

그림 속의 업무는 은행 수신 업무의 구성도입니다. 은행 창구 직원들이 쓰는 프로그램의 메뉴이기도 합니다.

이런 걸 표현할 때는 전문용어를 해석하지 않습니다. 그냥 그대로 정리합니다. 직원들이 쓰는 용어이기 때문입니다.

은행에선 “돈”을 “신용”이라고 부릅니다. 그래서 예금업무를 “수신”(신용을 받는다)이라고 합니다. “유동성신규”는 입출금이 자유로운 자유 예금, “정규성신규”는 일정 기간 비치해 놓는 정기 예금, “적립성신규”는 적금 예금을 말합니다.

시스템에서는 일반적으로 메뉴 하나에 메인 화면 하나를 매칭합니다.

‘신규계좌조회, 해지계좌조회? 이건 하나로 만들면 더 좋지 않을까, 왜 두 개를 만들었을까?’ 은행 구성도를 볼 때는 이런 생각을 하면 안 됩니다. 은행업무 시스템의 사용자는 일반인들이 아니거든요. 창구 직원들이 사용자입니다.

해지계좌는 손님들이 문제를 제기할 때 들여다봅니다. 상담이 발생할 때죠. 해지 사유, 지급 이자, 해지 처리 담당자, 정확한 해지 일시 등의 정보들이 상세하게 기술되어 있어야 합니다.

화면이 필요한 상황은 일반인이 겪는 상황이 아닙니다. 그래서 창의적으로 생각하면 안 되고, 개선이 필요하면 직접 당사자에게 물어봐야 합니다.

즉, 업무 구성도는 고객의 언어로 만들어진 개발 목표이자 프로젝트의 범위입니다.

개발 요구사항을 정리해 놓은 뼈대이기도 하고요. 그렇기에 프로젝트를 시작하면 가장 먼저 만들어야 할 문서입니다.

다만 빠지는 것들이 있습니다. 고객도 모르는 것들이죠. 보안관리, ID 인증, 통계 업무 같은 것들입니다. 이런 업무는 창구 직원이 아니라 전산실 직원이 하는 일이니까요. 그래서 업무 구성도를 정리할 땐, 관계된 사람들을 모두 고객이라고 생각하고 만나야 합니다.

시스템 구성도

우체국 차세대 금융시스템 구성도 <출처: 디지털데일리>

시스템 구성도를 보겠습니다.

여기서 시스템이란 한 대의 서버를 말합니다. 옛날에는 시스템 = 서버 한 대 = 업무 하나였거든요. 그래서 시스템 구성도가 업무 구성을 담고 있습니다.

요즘에는 그렇지 않습니다. 단순히 업무에 따라 서버를 나누지 않고 기능별로 분리하기도 합니다. 지금의 시스템 구성도는 소프트웨어 구성도와 비슷해져 버렸죠. 그래서 요즘에는 “시스템 개요도”, “업무 시스템 개념도” 등으로 부릅니다.

자세히 보면 업무들이 계층적으로 정리되어 있습니다. 그래서 각 업무의 종속관계, 연관관계 등을 이해할 수 있습니다. 시스템의 업무 범위도 알 수 있죠.

이를테면, 이미지 가운데 영역의 “계정계”란 “계정”을 중심으로 이루어지는 업무들입니다. 우체국에서는 예금 업무도 하지만, 보험 업무도 합니다. 이 그림을 보면 알 수 있죠.

“정보분석/활용”이 이러한 “계정계”와 같은 레벨에서 다루어집니다. 중요도가 높겠군요. 독립 시스템으로 운영되는 걸 보니 담당 부서도 다르겠네요.

이미지 왼쪽 “채널 서비스”란 소통 채널을 말합니다. 방송 채널을 생각하면 쉽죠.

데이터는 “계정계”에서 가져오고, 인터넷, 스마트폰, 폰뱅킹 등을 통해 고객과 소통합니다.

둘을 함께 그려놓은 건 DB가 같거나 역할이 유사하기 때문입니다. 보안 정책 관리 등이 유리하죠.

시스템 구성도를 통해 이런 것을 읽습니다. 코드를 만들고 유지 보수하기 위한 중요 자료들이죠.

물리적 시스템 구성도

전통적 물리적 시스템 구성도 <출처: 작가>

옛날 그림을 가져왔습니다. 요즘도 클라우드가 아닌 전통적인 서버를 구성할 땐 이렇게 구성합니다. 클라우드 시스템도 구성 원리가 비슷하니 참고할 수 있습니다.

물리적 시스템이란, 손으로 만질 수 있는 “하드웨어 서버”를 말합니다. 요즘에는 서버 한 대에 700만 원 정도 합니다. 옛날에는 한 대에 4~5억 원씩 했습니다. 성능과 스펙에 따라 돈이 많이 들어갑니다. 그래서 어떤 걸 사고 어떻게 준비해야 할지 미리 정해야 합니다. CPU, 메모리, 스토리지 등등을 말이죠.

그런데 그걸 정리하려면 어떤 소프트웨어를 쓸지, 속도는 얼마나 빨라야 할지도 알아야 합니다. 그러려면 아직 만들어지지 않은 소프트웨어의 성능을 대충 예측할 수 있어야 하죠.

예를 들어 거래 로그가 하루에 천만 개씩 쌓이고 3개월을 보관해야 한다면, 약 9억 개의 로그 저장공간이 필요합니다. 로그 파일 하나에 1Kb를 차지한다면, 약 900GB의 스토리지가 필요하겠네요. 프로그램 공간까지 고려한다면 약 1.5 TB짜리 스토리지를 사야 합니다.

다만 로그 데이터라면 굳이 좋은 곳에 담아둘 필요가 없습니다. 읽지 않고 보관만 하다가 사고 발생 시에 열어보면 되니까요. 읽기 쓰기가 느려도 저렴하면 좋습니다.

이렇게 파일별로 보관 정책도 분리할 수 있죠.

물리적 시스템 구성도는 이런 일을 구분하기 위해 그립니다. 그리고 이 결정은 하드웨어 구매 예산에 그대로 반영되죠.

AWS의 물리적 시스템 구성도 <출처: AWS>

AWS 구성도도 사실 같은 목적으로 그립니다. 전산실 운영자 입장에선 거의 1대1로 매칭되죠. 서버를 실 구매할 필요가 없을 뿐, 해야 하는 일은 거의 똑같습니다.

클라우드를 도입할 때 비용 예측을 안 하는 경우도 꽤 많습니다. 요즘에는 전산실 업무를 잘 아는 개발자가 많지 않거든요. 그래도 중대형 SI는 대부분 전산실이 있다 보니, 이런 걸 해달라고 합니다. 운영할 때 서버 비용은 중요하니까요.

간혹 서비스가 이제 시작해서 가입자가 1천 명이 안 되는데, AWS 서버 비용만 매월 천만 원씩 나오는 경우도 생깁니다. 기업형 SI에선 있을 수 없는 일이죠. 할 이야기가 많은데, 다음 기회에 다뤄보겠습니다.

시스템 소프트웨어 구성도

전통적 시스템 소프트웨어 구성도 <출처: 작가>

레거시가 많은 시스템을 연동해야 할 땐, 이런 그림들을 보게 됩니다. 마찬가지로 옛날 그림이죠.

요즘은 대부분 리눅스(Linux)를 쓰다 보니 이렇게까지 복잡하진 않습니다. 소프트웨어 스택이 일반화되었죠. 그래서 노션(Notion) 같은 문서 프로그램에 “표”로 정리합니다. 그림이 보기 좋긴 하지만, 표가 더 간단하죠.

시스템 소프트웨어란, OS 위에 설치해야 하는 기본 프로그램들을 말합니다. 옛날 서버들은 OS가 달라서 저런 걸 정리해야 했습니다. 실제 운영이 이뤄지는 환경이다 보니 “운영 환경”이라고 부릅니다.

보통 “개발 환경”에서 디버깅을 뺀 구성이라고 생각하면 됩니다.

메모리, 연결선 등도 중요한데, 특히 “버전”을 눈여겨봅니다. 옛날 버전을 쓰는 경우도 많거든요.

JDK를 요즘 버전으로 개발했다가 이 서버에 올리면 안 돌아가는 경우도 많습니다.

그래서 가능하면 서버별로 자세하게 그려줍니다. IP, 프로토콜(protocol), 네트워크 포트(network port) 같은 것도 기록하죠. 시스템 운영에 필요한 거라면 모든 정보를 한데 모아서 기록합니다.

개념적 시스템 소프트웨어 구성도 <출처: 작가>

소프트웨어 구성도를 그릴 때 엄격한 기준이 있는 건 아닙니다. 필요한 게 있다면 자유롭게 그립니다. 목표는 소통과 이해를 돕는 것입니다. 장애가 났을 때 이 그림을 딱 펴면 어디서 문제가 났는지 알 수 있어야 합니다.

그래서 이 그림은 운영팀에게 매우 중요합니다. 이게 없다면 “상용 서버” 관리자가 없다는 겁니다. 큰 회사라면 보통 담당자가 있지만, 작은 기업이라면 없는 경우도 많습니다. 그래서 프로젝트가 끝나도 이런 그림이 안 생기는 경우가 많습니다.

문서가 없는 시스템에 신규 기능을 만들러 새로운 개발자가 들어오면 이 그림부터 파악하느라 시간이 한참 걸립니다. 엔지니어링에 서툰 초보 개발자라면 이런 관계를 몰라서 코딩을 시작하지도 못합니다.

그런 사람이 많냐고요? 많습니다. 특히 신입사원들은 이런 걸 배울 기회가 더욱 없으니 말이죠.

애플리케이션 구성도

클래스 다이어그램 <출처: 작가>

애플리케이션 구성도. 애플리케이션이란 개발팀이 만드는 프로그램을 말합니다. 실제로 동작해야 하는 프로그램들이죠.

게시판 만드는 거라면 굳이 이런 게 필요가 없습니다. 클래스(Class) 몇 개로도 끝나거든요. 그런데 은행 업무 같은 건 그려야 합니다. 클래스 몇천 개가 복잡하게 얽혀 있거든요.

이거 꼭 필요할까요? 사실 코드란 건 이렇게 짜도 돌고, 저렇게 짜도 돕니다. 그래서 개발자들이 자기 스타일대로 만들죠. 하지만, 은행같이 복잡하게 얽혀 있는 업무라면, 업무 간 연관관계를 고려해야 합니다. 예금 잔액을 조회한 후에야 ATM기 출금을 허락할 수 있잖아요.

특히 SI는 복잡한 기능을 한 번에 ‘짠’ 하고 만들어야 하기 때문에 이렇게 설계도를 그려놓고 개발을 시작합니다. 이런 설계도에 클래스 다이어그램(Class Diagram), API 정의서, 화면 설계서 등등이 들어가죠.

실제로 많이 보냐고요? 봅니다. 그리고 봐야 합니다.

산출물로 만들어야 하는 워드나 엑셀문서는 아닐 수 있지만, 우리는 UML 툴을 이용해서 ERD나 클래스 다이어그램을 그립니다. 그렇게 만드는 것들로 화면설계서, API 정의서 등이 있습니다.

이런 문서들은 개발자와 개발자, 설계자와 개발자, 디자이너와 개발자, 기획자와 디자이너 등이 함께 봅니다. 업무 내용을 식별하거나 작업 지시를 하기 위해서죠.

보통 “개발문서”라고 부르는 이런 산출물은 초보개발자들도 많이 보는 편입니다. 그런데 공공 SI프로젝트에선 엑셀, 파워포인트, 한글 문서로 옮겨 적기도 합니다. 사실 좀 불편하죠. 개발자들은 이미 UML 툴이나 피그마(Figma) 등으로 충분하거든요.

요즘에는 이런 작업을 지원하는 도구가 많아지면서 SI 프로젝트에도 변화가 많이 생겼습니다. 다만 대부분 웹 기반 도구라 계정이 있어야 볼 수 있습니다. SI 프로젝트는 이동 인력이 많은 만큼 관리가 불편하긴 하죠. 그래서 최종본을 파일로 출력해서 하나를 관리하기도 합니다.

개발문서는 소통에 반드시 필요한 문서입니다. SI 프로젝트라면 이런 게 안 만들어질 수가 없죠.

이런 문서가 전혀 관리되지 않는 곳도 있습니다. 일이 제대로 진행되지 않고 있다는 겁니다. 그런 곳에 들어가면 챙길 곳을 몰라 한참 헤매기도 합니다. 일정이 촉박하면 아주 난감하죠.

데이터 구성도

ERD, 테이블 구조도 <출처: 작가>

모든 기업 시스템은 고객 데이터가 바로 돈입니다. 데이터 구성도는 그러한 비즈니스 가치사슬, 고객 정보를 모두 담은 그림입니다. 일반적으로 기업 비즈니스에서 애플리케이션은 데이터를 만드는 도구일 뿐 핵심이 아닙니다. 데이터가 바로 사업의 정체성이죠.

그래서 데이터 구성도는 모든 기업에서 중요합니다. ERD는 이 구조를 정의한 틀이죠.

어쨌든 반드시 잘 관리되고 있어야 합니다. 정상적인 기업이라면 잘 관리될 수밖에 없습니다.

API를 만들 때도 필요하고, 회계 결산할 때도 필요하고, 서비스 기능을 만들 때도 필요하니까요.

그런데 이런 게 없는 곳도 있습니다. “진짜 없다고?” 물을 수도 있겠네요. 네, 있습니다. 회사가 작아서 개발팀이 없거나 필요할 때만 외주를 주는 회사도 많거든요. 아예 개발 담당자가 없죠.

이런 프로젝트에 들어갔다면, 데이터 구조를 알기 위해 ERD를 새로 그려봐야 합니다. 역공학(Reverse Engineering) 도구들이 있으니 그걸 이용해 봅니다. NoSQL 계열이라면 다른 방법을 써봅니다.

프로젝트 관리문서들

지금까지 본 문서들은 실제로 만들어질 시스템에 대한 것들입니다. 프로젝트 문서(개발문서)들이죠.

목표를 뚜렷이 하고 과정을 드러냄으로써 최종 결과물을 제대로 만들고자 하는 수단들입니다.

SI 프로젝트가 아니라도 쉽게 볼 수 있죠.

그런데 SI 프로젝트에선 “일하는 과정”을 관리하는 문서도 있습니다. 요구사항 변경, 업무량 증가 등 일정과 예산에 영향을 주는 모든 것들을 기록하고 관리하죠. 이런 걸 “프로젝트 관리문서”라고 합니다.

SI는 결국 남의 일을 하는 것이고, 이해관계자 여러 명이 얽혀 있기 때문에 100점으로 끝나는 경우가 절대 없습니다. 책임소재와 갈등, 합의 내역 등을 잘 관리해서 분쟁, 갈등 상황에 대비해야 하죠.

그러다 보니, “관리문서”는 골칫덩어리로 보이기도 합니다. 1억 원짜리면 1억 원어치, 10억 원짜리면 10억 원어치 문서들이 생깁니다. “프로젝트 관리자”인 PM 조직이 살뜰히 문서를 챙기는 이유죠. 개발자 입장에선 고통스러운 일입니다. 일이 잘 끝난다면 쓸데없는 문서가 되니까요.

개발자가 만들긴 해야 하지만, 문서 수요자가 개발자가 아닌 경우도 있습니다. 복잡한 주간 보고 케이스죠. 투입시간으로 관리하다 보니 증명을 위한 문서도 만들게 됩니다.

이번 글의 목표는 시시비비를 가리고자 함이 아니니 여기선 넘어가겠습니다. 다만, ‘프로젝트 관리문서를 어떻게 할 것인가’에 대해선 많은 연구가 필요합니다.

큰 규모든 작은 규모든 SI가 겪고 있는 가장 큰 문제의 집약체이기 때문입니다.

초보 개발자들은 프로젝트 관리문서를 볼 기회가 거의 없습니다. 그냥 문서 담당자에게 물어보는 게 가장 빠르죠.

마치며

정리합니다. 프로젝트 산출물은 크게 “소통”을 위한 문서, “결과”를 보관하는 문서, “과정”을 관리하는 문서, 이렇게 크게 세 종류로 나뉩니다.

“소통”을 위한 문서, “과정”을 관리하는 문서는 프로젝트가 끝나면 보관 효력이 사라지죠. 반면 “결과”를 보관하는 문서는 운영 중에도 지속적으로 읽히며 업데이트됩니다.

문서를 죄악시하는 개발자들이 있습니다. 그건 너무 많이 나가지 않았나 싶습니다.

모든 문서는 필요에 의해 생겼고 그 필요가 여전히 존재하니까요. 외부 개발자가 API를 써야 하는데, 내부 개발자가 API 스펙 문서 하나 못 만들어 주면 부끄러운 겁니다. 텍스트만 적은 워드나 엑셀 문서라도 없는 것보다는 훨씬 낫죠.

다만, 이런 산출물을 어떻게 관리할 것인가에 대한 연구는 거의 멈추었습니다.

요구사항 정의서를 꼭 엑셀로 정의해야 하는가?

요구사항 식별자를 붙여서 이리저리 문서로 관리를 해야 하는가?

그게 과연 프로젝트를 잘 끝내는 데 중요한 것인가?

그래서 그걸 좀 쉽게 할 수 있는 방법이 없는가?

이런 질문들이 사라졌죠. 그냥 관행처럼 움직입니다. 이런 관행들은 규제나 정책 하나로 바뀌지 않습니다. 사람과 습관의 문제니까요.

문제를 가장 잘 아는 사람은 문서 템플릿 관리자가 아니라, SI 프로젝트의 구성원들입니다. PPT 문서가 노션과 피그마로 바뀐 것처럼, 프로젝트 팀 내에서 필요성에 대한 질문을 던져보고 개선하려는 노력들이 이어지면 좋겠습니다.

]]>

인하우스 개발, 몇 명이나 필요하고 얼마나 들까?

SI 산업 가이드북 ⑬

이번 편은 “인하우스 전략”입니다. 내부 개발팀 구축을 고려하는 전통 산업 리더들이 청중입니다.

요즘 자동차는 자율 주행이 필요해졌고, 금융은 AI가 필요해졌고, 의료계는 원격 진료가 필요해졌습니다.

대기업들은 “OO 시스템즈” 같은 IT 계열사를 통해 문제를 해결하고 있지만, 내부 개발팀을 만드는 것도 고민하고 있습니다. 어떤 차이가 있을지 정리를 해봅니다.

인하우스란

당근의 주요 변화 <출처: 작가 제작, 혁신의숲, 한국경제, 당근 참조>

2023년 말, 당근이 흑자전환을 했습니다. 창업한 지 8년 만이었죠. 회사는 직원 수 3명으로 시작했습니다. 지금은 400명이 조금 넘죠. 긴 세월 동안 SI 등으로 사업 전환을 하지는 않았습니다. 그리고 대부분 아웃소싱 없이 직접 개발했죠. 인건비가 많이 필요했습니다. 이를 위해 2,000억 원이 넘는 돈을 투자받았죠.

현재 당근 전체 인력의 70%가 개발 인력입니다. 지금도 무언가를 계속 만들고 있는 거죠.

이렇게 제품 개발을 모두 내부 개발자가 하는 걸 “인하우스 개발”이라고 합니다. 프리랜서를 고용하기도 하지만, 정말 일부 역할에 한해 한시적으로 쓰죠.

인하우스 개발의 장단점 <출처: Wishdesk>

인하우스 개발에는 단점이 있습니다.

먼저 고정비가 높습니다. 비싼 직원을 여러 명 데리고 있어야 하니까요. 그리고 계속 데리고 있어야 합니다. 회사의 개발 노하우가 직원에게 쌓이니까요.

부대 비용도 높아집니다. 채용과 교육 훈련, 관리 비용까지 생각해야 하죠. 시간 비용도 많이 들어갑니다. 업무 역량을 끌어내기까지 기다려야 하죠.

즉, 한 번 개발하고 말 거라면 인하우스 개발이 불리합니다. 아웃소싱을 하는 게 낫죠.

그렇다면 왜 인하우스 개발이 필요할까요?

첫째, 소프트웨어가 제품인 경우입니다. “직방” 같은 인터넷 서비스도 해당됩니다. 소프트웨어가 기업이 돈을 벌어들이게 해주는 직접 재화인 거죠. 100%가 아니라 50%만 해당하여도 됩니다. “테슬라”에서 자율주행은 빼놓을 수 없는 기능이죠. 제품을 만드는 강력한 구성 요소입니다. 인하우스 개발팀이 꼭 있어야 하는 이유죠.

둘째, 시장 변화에 맞춰 제품을 빠르게 바꿔야 하기 때문입니다. 빠르게 움직이려면 “우리 직원”이라는 운명 공동체 의식이 필요하죠. 느리게 대응해도 좋다면 아웃소싱으로도 충분합니다.

셋째, 노하우가 중요한 경우입니다. 노하우는 제품을 개량하기 위한 강력한 수단이죠. 시행착오를 통해서만 축적됩니다. 그리고 그 분량만큼 후발주자와의 거리도 멀어지죠.

아웃소싱을 하면 노하우는 외부 업체에 축적됩니다. 우리가 우리 제품을 더 좋게 만들기 어렵죠.

넷째, 보안 때문입니다. 아웃소싱을 하면 어쨌든 정보는 유출됩니다. 100%가 아니라 일부라고 해도요. 자투리를 모아 전체를 유추할 수 있습니다. 정보 유출이 사업에 큰 영향을 미친다면 인하우스 개발이 필수입니다.

돈이 얼마나 들까?

당신은 스타트업 창업자입니다. 인스타그램 같은 작은 앱을 만들려고 합니다.

몇 명이 필요하고, 얼마나 많은 돈이 필요할까요?

인스타그램 같은 앱을 만들려면 앱 개발 1명, 웹 개발 1명, 서버 및 DB 개발 1명, 이렇게 최소 3명의 개발자가 필요합니다. 기획자 1명, 디자인 1명까지 붙이면, 최소 5명이 되죠.

돈은 얼마나 들까요?

연봉, 퇴직금, 사무실비 등등을 다 더하면, 어느 정도 경력 있는 개발자라 했을 때, 1인당 평균 1억 원 정도 추산합니다. 개발팀 구성에 연간 5억 원 정도의 고정 비용이 필요한 거죠. 기타 비용을 생각하면 창업 비용으로 연간 7~8억 원을 준비해야 합니다.

이것도 1년 만에 제품이 나와서 그다음 해에 매출을 만드는 경우입니다. 아니라면 2년 차에 또 그만큼 돈을 구해야 하죠. 보통 첫해에 제품을 만들고, 둘째 해에 고객을 만들고, 셋째 해에 매출을 만듭니다. 그다음에 손익분기점(BEP)을 넘기도록 계획을 잡죠. 창업자는 이 기간을 버틸 수 있도록 돈을 구해와야 합니다. 단순 계산으로도 3년에 20억 원 정도 조달해야 하죠. 빌리거나 투자를 받아야 합니다.

사업마다 상황은 많이 다르겠습니다만, 어쨌든 창업할 때는 이런 식으로 꼼꼼히 따져봐야 합니다.

좋은 개발자를 만나고 기업 문화를 만들고 하는 건 그다음 이야기입니다. 인하우스 개발도 아웃소싱 못지 않게 어렵습니다.

개발팀의 변화

인하우스 개발팀은 아웃소싱 팀처럼 변하려는 경향이 있습니다. 분업화, 프로세스화 될수록 말이죠.

수익화 방식이 정해지고 사업 환경이 안정되면, 기술 환경도 안정됩니다. 그러면 기업은 낭비를 줄여 이윤을 높이려는 시도를 하죠. 이른바 효율화입니다.

가장 좋은 효율화 방식은 “분업, 프로세스, 반복”입니다.

“분업”은 업무 간 결합도를 낮춰 책임이 넘어가는 걸 막아줍니다. 남의 일은 생각할 필요가 없는 거죠.

“프로세스”는 생산 과정을 안정화 시킵니다. 프로세스가 시킨 대로만 해도 결과물이 나오는 거죠.

“반복”은 숙달을 통해 생산성을 높여줍니다. 좀 더 짧은 시간에 완성도가 올라가게 되죠.

이 모습은 어느 정도 “SI”와 닮아 있습니다. SI가 제조업의 효율화 방식을 벤치마킹했으니까요.

인하우스 개발팀은 아웃소싱에 필요한 업무 난이도를 낮추고, 비효율을 제거하는 “R&D” 역할을 하게 됩니다. 이 과정에서 인하우스 개발팀은 자연스럽게 프로세스 중심의 경직된 일 문화를 갖죠.

외부 환경의 변화가 적다면 좋은 선택이 될 수도 있습니다. 그게 아니라면 바람직하지 않죠.

개발팀의 경직성이 사업을 방해하게 됩니다. 개발자 문제라기보다 이렇게 만든 조직의 문제입니다.

우아한 말로는 “기술 변화에 대한 적응 실패”라고 하죠. 구글보다 컸던 Yahoo! 가 몰락하게 된 이유입니다.

※ 참고 글: What happen to yahoo?

개발팀과 운영팀

오류를 줄일 땐 프로세스화가 좋습니다.

옆에서 누가 체크해 주는 게 훨씬 더 가볍고 빠르니까요. 프로세스는 “불신”을 바탕으로 설계합니다. 이전에 체크하지 않은 것은 다 오류일 수 있다고 보는 거죠. 대신 느립니다. 점검하지 않은 건 모른다고 가정하니까요.

“운영팀”은 이렇게 프로세스 기반으로 구성합니다. 안정성, 항상성, 지속성이 중요하거든요. 그런데 이렇게 하다 보면 자꾸 중복이 생깁니다. 낭비죠. 관리자가 개입해서 자꾸 없애줘야 합니다. 낭비 제거, 다른 말로 효율화라고 하죠. 운영할 땐 이런 걸 중요하게 봅니다.

그러나, 새로운 걸 개발하려면 자유로운 게 좋습니다. 잘 모르면 일단 만들어봐야죠. 프로젝트팀 내에서 상의하고 결정하게 합니다. “스케치해 보고 개발”, 이 과정을 반복하는 거죠. 관리 문서가 아니라 결과물과 개발 코드를 보면서 진도를 뺍니다.

이렇게 일하는 방식을 오래된 관습, “문화”라고 하죠. 참고로 문화는 효율을 위해 움직이지 않습니다. “효과”라는 결과를 향해 움직이죠. “개발팀”은 이렇게 구성합니다. 목표, 결과, 성과, 이런 것들이 중요하니까요.

한편 “은행권 차세대 프로젝트” 같은 대형 프로젝트는 좀 다릅니다. 핵심은 창의적 연구 개발이라기보다, 알려진 기술로 비즈니스 시스템을 조립하는 겁니다. 시스템이 크고, 복잡성을 통제해야 하니, 설계도, 조립도 같은 게 중요합니다. 그래서 관리팀을 섬세하게 구성하죠.

즉, IT 운영팀, 개발팀, SI 프로젝트의 개발팀은 같아 보이지만 모두 다른 조직입니다. 조직 목적이 다르기 때문에 조직도 달라지는 거죠.

개발 문화

“개발 문화”라고 하니까 기획자, 디자이너가 이런 말들을 많이 합니다.

“개발자 편의만 너무 봐주는 거 아니냐?”

“개발 문화”를 “개발자 문화”로 오해하는 겁니다.

“개발 문화”가 화제가 된 건 2004년의 구글 때문입니다. “20% 프로젝트”*로 지메일과 구글 나우가 나왔거든요. 이 문화가 Google Developer Day, Google I/O 등으로 이어집니다. 이때까지만 해도 “개발 문화”는 개발자들만의 그 무엇이었죠.

*20% 프로젝트: 모든 직원이 자신이 원하는 창의적인 프로젝트에 업무 시간의 20%를 사용하도록 한 구글의 문화

일반인에게 널리 알려지게 된 건 2012년 페이스북 때문이었습니다. IPO를 하면서 투자자 공개서한에 “해커 문화”를 강력하게 내세웠거든요. 주식 투자자들에게 그걸 믿고 우리 회사에 투자하라 한 겁니다. 사람들은 궁금해지기 시작합니다. “도대체 그게 뭔데?”

구글과 페이스북으로 대표되는 이런 일 문화가 “개발 문화”라고 불리게 된 건, 회사 제품이 “인터넷 서비스”였기 때문입니다. 제품의 제작, 생산, 심지어 판매까지 모두 소프트웨어로 만드니까요. 즉, 개발 문화가 없으면 기업이 존립할 수 없는 겁니다. 제조업이었다면, R&D 문화, 생산 프로세스 등이 해당하겠죠.

즉, IT 회사에서 “개발”이란 제품을 만드는 전체 과정을 일컫는 말입니다. 코딩 스타일만 말하지는 않죠. 굳이 일반화시켜 보자면 “기업문화” 정도가 될 겁니다.

어쨌든 이때가 되어서야 사람들은, “인터넷 서비스나 패키지 소프트웨어를 잘 만들려면, 프로세스뿐 아니라 개발 문화가 있어야 하는 구나”라는 걸 알게 됩니다.

개발 문화 만들기

그런데 개발 문화는 어떻게 만들까요?

자연스러운 게 제일 좋겠지만, 누구나 사업 현장을 그렇게 만들 수는 없습니다. 마냥 기다릴 수도 없으니까요.

“문화”를 만드는 인위적인 수단은 “제도”와 “분위기”입니다. 회사니까 이 정도로도 충분합니다.

“구글의 20% 프로젝트”, 이건 “제도”입니다. 그런데 처음 해보면 100% 헤매게 되죠. 보고 따라 하는 게 가장 빠릅니다. “따라 해 봤더니 목표한 결과에 쉽게 이르게 되더라.” 이런 성공 경험이 “습관”을 만들어 냅니다. 이게 오래되고 여러 사람이 함께하면 “관습”이 되죠. 그다음에야 문화가 됩니다.

즉, 문화는 제도 → 분위기 → 습관 → 관습을 거쳐 만들어집니다. 시간이 꽤 걸릴 것 같지만, 생각보다 빠르게 바뀝니다. 보고 따라 하는 게 “행동”, “생각”을 변화시키는 가장 빠른 방법이니까요.

다만, 코드의 양, 일의 범위, 기존 프로세스와 충돌 등이 변화의 속도를 느리게 만듭니다.

대기업은 개발 문화 만들기가 생각보다 어렵습니다. 이미 형성된 다른 문화가 있으니까요. 점진적이면서 느린 변화를 선택할 수밖에 없죠. 스타트업은 자유롭습니다. “새 문화의 축적”에만 신경 쓰면 되니까요.

그래서 큰 기업들은 CIC(Company In Company) 형태로 작은 스타트업을 만들거나 작은 스타트업을 인수하기도 합니다. 개발 문화를 바꾸기 위한 불씨로 쓰죠.

사람이 중요해요

일을 하다 보면 반드시 사고가 일어납니다.

분업화, 프로세스화는 사람의 책임을 덜어줍니다. 매뉴얼, 표준화를 통해 문제를 해결하니까요.

시킨 대로 한 사람은 잘못이 없습니다. 단계가 길고 복잡한 업무를 반복해야 할 경우 좋은 선택이죠.

어떤 일이 벌어질까요?

기업은 평이한 개발자를 뽑습니다. 설계는 비싸게 합니다. 복잡한 문제는 구조를 통해 해결하고, 업무 완성도는 반복 숙달을 통해 높입니다.

단점으로는 프로세스가 계속 늘어납니다. 사람도 계속 늘어납니다. 프로세스가 길어지면 시장 변화에 쉽게 대응하기 힘듭니다.

반면 개발 문화로 일할 땐 만든 사람이 책임을 지게 합니다. 개인 역량을 통해 문제 해결을 합니다. 일이 구분되지 않고 복잡하게 섞여 있는 경우 할만한 선택이죠. 대신 한 사람이 짊어져야 할 책임이 큽니다. 스트레스 수치가 높은 환경이죠.

고수 개발자를 뽑아야 합니다. 이것저것 다 해본 사람이니 일하기 편리하고, 결과 빨리 나오고, 소통도 잘 됩니다. 교육 훈련도 필요 없죠. 다만 연봉이 비쌉니다.

단점은 대량으로 반복하기 힘든 겁니다. 오래 지속하기도 어렵죠. 사람 구하기 매우 어렵습니다.

두 가지 사례는 극단적인 비교입니다. 대부분의 회사는 중간 어디쯤 있죠.

결국 둘 다 사람이 중요합니다. 요즘엔 사람 구하기 너무 힘들거든요.

2000년대 초엔 개발자 뽑기가 쉬웠습니다. 베이비붐 세대가 IT 현장에 들어와 있었거든요. 요즘은 아닙니다. 개발자 구하기 정말 어렵습니다. 훈련된 개발자는 더더욱 어렵죠.

기업 교육의 중요성이 점점 높아지고 있습니다. 새로 구하기보다 기존 직원을 훈련해서 쓰고 싶은 거죠.

좋은 채용 전략

어떤 사람을 뽑아야 할까요? 어떻게 뽑고, 어떻게 관리해야 할까요?

어렵습니다. 모든 IT 회사의 숙제죠.

인사가 만사라고 개발팀 채용, 관리도 사실 전통적인 HR의 연장선상에 있습니다. 다만 IT라는 산업 특성이 더 강할 뿐입니다.

상황은 조직마다 회사마다 다릅니다. 그래서 콕 찝어서 이야기할 만한 정답은 없죠.

다만 IT 분야에 새로 진입하는 채용 담당자들이 꼭 알고 있어야 할 내용이 있습니다. Rober Half Technology라는 큰 회사의 분석 리포트입니다. 2020년 미국 상황을 정리한 내용인데, 국내 사정도 비슷합니다. 핵심만 요약해 봅니다.

우리 고객의 67%가 IT 팀을 확장할 계획을 갖고 있다.
그러나, 90%의 회사가 적임자를 못 찾고 있다.
개발자의 86%는 현재 취업 상태로 이직 의사가 별로 없다.
개발자 채용에는 최소 며칠 ~ 최대 4개월이 걸린다.
채용 담당자의 75%는 입사 제안을 거절당해 본 적이 있다.
거절한 개발자의 53%는 다른 곳에서 더 좋은 제안을 받았다고 한다.

한국도 흐름은 비슷합니다. 기존 산업과 IT 기술의 융합도가 높아지며, 인하우스 개발팀의 필요성도 따라 높아지는데, 개발자를 구할 수는 없으니까요.

좋은 개발자는 어떻게 구할까요?

검색해 보면 여러 가지 팁들이 많지만, 그중에서 중요하다고 생각하는 세 가지만 추려 보겠습니다.

첫째, 좋은 개발자는 찾아다녀야 합니다.

어떤 분야든 마찬가지겠지만, 우리 회사에 맞는 개발자를 우연히 만날 가능성은 거의 없습니다. 그 사람을 채용하게 될 확률도 거의 없고요.

비슷한 사람을 꾸준히 수소문해서 찾아다녀야 하고, 만나더라도 오랜 시간 이야기를 나눠야 비로소 공감할 수 있습니다. 뜻이 맞아야 시너지가 나는 거죠.

둘째, 채용 공고는 긴 호흡으로 냅니다.

기업은 채용 공고를 한 달 정도 기한으로 냅니다. 급하니까요. 그런데 한 달이라는 시간은, 우리가 찾는 사람이 있을 확률 x 그가 우리 채용 공고를 볼 확률 x 입사를 결심할 확률 x 원서를 잘 낼 확률이 꼭 맞아떨어져야 적당한 시간입니다. 너무도 낮은 확률이죠.

게다가 대부분은 우리 회사가 통제할 수 없는 항목들입니다. 오직 하나, 우리 채용 공고를 볼 확률을 높일 수 있죠. 그래서 채용 공고는 최소 2~3달이어야 합니다. 길수록 좋죠.

신입사원 채용은 대부분 신규 채용입니다. 졸업 시기에 맞춰 공고를 내면 지원서를 많이 받을 수 있죠.

반면 경력사원 채용은 대부분 이직입니다. 현재 업무가 바빠서 못 볼 수도 있죠. 그래서 경력 채용 공고일수록 여러 곳에 길게 냅니다. 또는 찾고 있는 개발자가 많이 오는 곳을 선택합니다. 돈이 좀 들어가죠.

셋째, 우리가 하는 일을 잘 알려야 합니다.

아무렇게나 공고를 낸다? 아무런 공고여도 괜찮은 사람이 옵니다. 정성 들여 공고를 낸다? 가물에 콩 나듯이 괜찮은 사람이 옵니다만, 그래도 정성 들여 공고를 내야 합니다. 우리가 무슨 일을 하는지 알아야 그에 맞는 사람이 찾아오니까요.

이를 도울 방법도 있습니다. 개발자 세계는 넓습니다. 별거 아닌 것처럼 보여도 우리 일을 좋아하는 사람이 있습니다. 기술 블로그나 SNS 등 우리가 하고 있는 일을 널리 알립니다. 돈이 되진 않습니다. 그래도 많이 알릴수록 핏이 맞는 사람을 만나게 될 확률이 큽니다.

즉, 좋은 채용 전략은 좋은 인력풀과 오랫동안 스킨십을 맺는 겁니다.

좋은 인재는 절대 한 번에 들어오지 않습니다. 한 명씩 한 명씩 채워 좋은 개발팀이 되는 겁니다.

다음에는 해외 기업들은 어떻게 아웃소싱을 하고 있는지 알아보겠습니다.

]]>

‘서툰 갑’을 위한 IT 아웃소싱 성공 전략

“이런 것까지 아웃소싱하나?”

‘아웃소싱’ 시장을 보면 상상하지 못한 것도 많습니다. 예를 들어 ‘콜센터’. 우리가 전화한 고객센터 상담원이 외주회사 직원이라는 걸 아는 사람들은 많지 않습니다. 아는 사람은 다 알고 있지만요.

그런데 이런 주제까지 다루면 아웃소싱의 범위가 너무 넓습니다. 여기선 ‘IT 시스템 구축’ 분야로 시야를 좁혀 봅니다.

이번 편은 아웃소싱이 서툰 갑들이 청중입니다. 이제 막 시작한 의류 스타트업일수도 있고, 오래전 창업한 제조회사일 수도 있습니다. IT 시스템을 아웃소싱해야 하는데, 어떻게 접근할지 막막한 사람들 대상입니다.

어떤 회사가 아웃소싱을 할까?

IT 아웃소싱을 왜 할까요?

일이 일회성이기 때문입니다. 그래서 내부에 개발 인력이 없죠. 그렇다고 정직원을 채용할 만큼 일이 많지 않습니다. 비싼 인력을 뽑을 상황은 더욱 아닙니다. 개발팀 유지가 사업 경쟁력도 아닙니다. 즉, IT 서비스가 주력이 아닌 기업들이란 뜻이죠. 대표적인 곳이 제조, 유통 쪽입니다.

또 있을까요?

프로젝트가 크고 복잡해서 특급 설계자, 고급 개발자 등 많은 전문가가 필요합니다. 그런데 그런 인력을 모두 고용∙유지할 여력은 안 됩니다. 은행권 차세대 프로젝트가 대표적인 예죠.

또는 로봇 코딩을 해야 하는데, 그 회사 독점 설비 제품이라 다른 개발자를 구할 수도 없을 때가 있습니다. 공장생산라인 쪽 상황입니다.

이처럼 “아웃소싱”을 할 수밖에 없는 상황은 꽤 많습니다. “인하우스 개발”은 아예 선택지에도 없죠. 대부분의 전통 산업은 이렇습니다. 그렇다면 IT 기업들은 어떨까요?

구글이나 페이스북도 아웃소싱을 합니다. 물론 우리나라 SI처럼 시스템 구축 자체를 아웃소싱하지는 않습니다. 전문가를 일시적으로 고용하거나, 시간을 줄이기 위해 활용하죠. 또는 마케팅 등 주력 분야가 아닌 것들은 아웃소싱을 합니다.

*참고 글: 구글이 아웃소싱을 하는 이유

아웃소싱의 역사

아웃소싱의 역사 <출처: terralogic>

언제부터, 왜 아웃소싱을 했을까요? 비교적 최근 시절부터 살펴보겠습니다.

1980년대, 미국에서는 아웃소싱이 대세였습니다. 제조업의 발달로 부품이 복잡해졌거든요.

모든 부품을 혼자서 만들 수가 없었습니다. 모든 걸 혼자 다 연구할 수도 없었고요. 당연히 분업화, 전문화가 됩니다.

1990년대, “아웃소싱”이 MBA 과정을 통해 깊게 연구되고 알려지기 시작합니다. 그와 함께 중국이 개혁개방을 합니다. 부품 생산을 위탁한 후 수입∙조립하는 게 훨씬 더 싸집니다. 아웃소싱이 글로벌하게 대중화되죠.

2000년대, 토요타의 성공 전략이 널리 퍼집니다. 전 세계가 아웃소싱에 열광하게 되죠.

그들의 핵심 시스템인 Just In Time(JIT), Kanban(간판 또는 칸반)이 주목을 받습니다. 재고를 쌓지 않고 필요한 때에 필요한 만큼만 주문한다, 전체 현황을 파악할 수 있는 현황판을 만들어 매일 관리한다, 이런 방법들이 널리 전파됩니다.

자동차 한 대를 만들려면 부품이 2만 개 정도 들어갑니다. 200개 정도의 협력 업체를 데리고 있어야 하죠. 2, 3차 하청업체를 포함하면 1만 개가 넘습니다. 비용과 일정을 제대로 관리하지 않으면 자동차 제작이 아예 안 되는 상황이죠.

자동차 품질이 좋아지려면 2만 개나 되는 부품도 같이 좋아져야 합니다. 작은 부품 하나도 연구개발이 필요하죠.

아웃소싱을 하면 하청업체들이 연구개발을 합니다. 토요타는 가격에 반영해 주면 되고요.

이 과정을 극한으로 관리해서 최대 효율을 뽑아냅니다. 가격협상을 유리하게 하기 위해 부품을 직접 만들어 보기도 합니다. 비용 구조를 파악하죠. 이런 식으로 전체 부품의 70%까지 외주로 조달합니다.

이런 아웃소싱 전략이 MBA를 타고 1990년대, 2000년대를 지나 IT 산업으로도 들어옵니다.

마침 IT 붐이 시작되던 시기라, 산업계에는 아웃소싱이 금방 정착되죠.

아웃소싱이 어려운 이유

IT 아웃소싱을 맡기는 회사는 이렇게 생각합니다.

우리 회사처럼 움직이는 SI 회사가 있으면 좋겠습니다. 우리 사업, 우리 시스템을 잘 이해하고 있고요.

필요할 때만 딱 계약을 할 수 있으면 좋겠습니다. 큰 프로젝트 할 땐 친구들을 잘 모아오기도 하고요.

저런 회사가 있을까요? 아니요, 절대 없습니다. 저런 일을 해야 하는 건 내부 직원들입니다. 외부 회사에 기대할 수 없죠. 그런데 아닌 걸 알면서도 저런 생각을 하는 분들이 있습니다.

운이 좋게 저런 SI 회사들을 만날 수는 있습니다. 하지만 눈에 보이지 않는, 그 SI 회사의 희생이 있죠. 알게 모르게 우리 프로젝트 때문에 적자를 보고 있습니다. 하지만 적자를 오래 버티진 못하죠.

남의 일일까요? 아닙니다. 아웃소싱하던 회사가 망하면 우리 사업에도 영향을 받습니다. 오래된 제조회사들은 절대 아웃소싱을 쉽게 생각하지 않습니다. 핏이 맞는 하청업체를 찾기 위해 시간과 공을 들이고, 한 번 맺어진 신뢰 관계에 손상이 갈 행동은 쉽게 하지 않죠. 운명이 함께 얽혀 있으니까요.

IT 프로젝트도 마찬가지입니다. 아웃소싱은 우리 회사의 시간을 줄여주고, 경쟁력을 높이기 위한 투자입니다. 당연히 갑의 일이죠. 목표한 결과가 나오기 위해 가장 노력해야 하고, 책임져야 하는 사람이 바로 “갑”이란 뜻입니다.

‘SI 업체에 맡겨 놓으면 그냥 만들어 주는 거 아냐?’ 이렇게 생각하는 분들 있습니다.

굉장히 큰 착각입니다.

아웃소싱은, 원래 내가 해야 할 일을 남에게 시키는 겁니다. 내가 하는 것처럼 결과가 나와야 하죠.

또, 내가 못 하는 것을 남에게 시키는 겁니다. 나에게 부족한 것까지 채워서 결과가 나와야 하죠.

내가 챙기지 않는다면 기대와 같이 나올 리 없습니다.

내가 해야 할 일을, 남을 통해 이루는 것. 그게 아웃소싱이니 어려울 수밖에 없습니다.

IT 아웃소싱의 위험 요소

8가지 아웃소싱 리스크와 관리 방안 <출처: diceus>

내가 해야 할 일을 남에게 시킨다. 그래서 훌륭한 결과물을 만들어낸다.

매우 어려운 일이죠. 어떤 일들이 일어날까요? 아웃소싱의 위험 요소를 정리해 봅니다.

어려운 말로는 비용 리스크, 통제 리스크 등등이라고도 하는데 그냥 쉽게 풀어 써봅니다.

첫째, 무얼 원하는지 정리하기 어렵다

프로젝트는 항상 새 것입니다. 우리 회사에는 없는 걸 만드니까요. 그래서 어떻게 만들어야 할지 모릅니다. 대부분의 조직이 그렇죠.

그런데 SI 업체는 “어떻게 만들어달라”라고 구체적으로 요구해야만 움직입니다.

“요구사항 명세서”라는 걸 정리해서 줘야 하죠. 이거 정리하는 게 일입니다. 기술도 알아야 하고, 구축 과정도 알아야 합니다. 모르면 절대 정리할 수 없죠.

요구사항 명세서가 없으면 아예 일을 시작할 수도 없습니다. 그래서 이런 정리를 전문으로 해주는 업체에 위탁을 하기도 합니다. ISP 사업 등이 여기에 해당합니다. 하지만, 결국 갑인 내가 알아야 합니다. 내가 모르면 중요한 부분이 빠질 수도 있죠. 내가 모르는 것까지 SI 업체가 알아서 만들어 올 리 없거든요.

이런 요구명세를 정리하기 힘든 사업일 땐, 아웃소싱이 아니라 내부 개발팀으로 시작하는 겁니다. 아웃소싱은 뭘 원하는지 정리할 수 있을 때, 비로소 시작할 수 있죠.

그러려면 공부를 해야 합니다. 시간이 걸립니다.

둘째, 적정 업체를 찾기 어렵다

프로젝트에는 많은 돈이 들어갑니다. 그래서 모두 프로젝트가 100% 성공하길 바라죠.

하지만 시장에 정말 많은 SI 업체가 있어도, 마음에 드는 업체 찾기란 사막에서 바늘 찾기 같습니다. 다들 가진 기술과 경험들이 다르니까요. 이것저것 따지다 보면 다 조금씩 부족합니다. 우리 사업을 위해 준비된 곳은 없으니까요.

‘유사 사업 경험이 많고 우리 사업도 잘할 수 있는 업체?’ 그런 기업이 존재할 확률은 생각보다 적지 않습니다.

하지만 ‘그 업체를 내가 필요한 시점에 만나게 된다?’ 그런 확률은 거의 없습니다.

제조업체는 아웃소싱을 해야 할 땐 적정 업체를 찾아 수개월씩 시장을 돌아다닙니다. 1년 이상 걸리기도 하죠. IT도 마찬가지입니다. 발품을 팔아야 나한테 맞는 업체를 구할 수 있죠.

금액이 작아 그렇게 찾아다닐 정도는 아니다, 그럴 땐 적정 업체가 많이 모여있을 만한 플랫폼을 찾아다녀 봅니다. 물론 역시 많은 업체를 만나서 이야기를 나눠봐야 합니다.

셋째, 결과를 보장하지 않는다

프로젝트 발주를 잘했다고 프로젝트가 잘 끝나는 건 아닙니다.

SI 기업이 백번쯤 반복해온 일이라면 성공 확률이 100%죠. 아니라면 결과를 보장할 수 없습니다. 일이 제때 끝나지 않을 수 있고 80%만 개발될 수도 있습니다. 만들고 나니 다른 제품일 수도 있죠.

SI 업체 때문이 아닙니다. IT 프로젝트의 특성 때문입니다. IT 프로젝트는 설계도만 가지고 찍어내는 제품이 아닙니다. R&D에 가깝죠. 만들어보고 수정하고 다시 만들고를 반복해야 합니다.

프로젝트 중간중간 SI 업체 단독으로 결정할 수 없는 많은 갈림길도 등장하죠. 갑이 참여하지 않으면 프로젝트는 표류합니다.

갑의 간섭 없이 잘 끝났다고 해도 문제입니다. 기술 주도권이 SI 업체에 있거든요. 일이 질질 끌리거나, 추가 개발 사항이 생기기도 합니다. 돈을 아껴볼까 하고 시작한 것이 돈 먹는 하마로 변하게 되죠.

갑은 프로젝트 진행 중에 이런 문제를 발견하고 제거해 나가야 합니다.

넷째, 시장에 유연하게 대처할 수 없다

SI 기업은 내 맘같이 안 움직입니다. 당연하죠. 우리 회사가 아니니까요.

모든 건 계약에 묶여 있습니다. 정해 놓은 선을 넘는 일이 생기면 계약 관계를 먼저 정리해야 합니다. 새로운 요구사항을 다시 정리하고 반영해야 일이 됩니다. 생각보다 행정 프로세스가 길고 많습니다.

경계선상에 걸친 일도 있습니다. 그냥 해달라고 하기 애매하죠. 반면 어떤 일은 그냥 해주기도 합니다. 경중의 기준을 쉽게 판단할 수 없죠.

당연히 시장 변화에 빠르고 유연하게 대처할 수 없습니다. 이렇게 대처해야 하는 사업이라면 아웃소싱은 처음부터 피해야 합니다.

다섯째, 보안 사고 발생 가능성이 높다

운영 중인 시스템이라면 고객 데이터가 잔뜩 쌓여 있습니다. 새 프로젝트를 시작하려면, 이제 새 데이터를 쌓아야 하죠. 당연히 SI 업체에 데이터 권한을 줄 수밖에 없습니다.

하지만 SI 업체는 보안을 대하는 마인드가 다릅니다. 남의 회사라 빈구석이 생기기 마련이죠.

아웃소싱을 하면 보안 위협이 커집니다. 그래서 대기업은 아예 개발 시스템을 따로 운영합니다. SI 업체는 가짜 데이터를 가지고 개발을 합니다. 오픈 시기에야 엄격한 보안 통제 속에서 실제 데이터를 볼 수 있게 만들죠.

큰 프로젝트에선 시작할 때 필요한 “테스트 데이터 세트”를 별도로 만듭니다. 꼭 해야 할 일이죠.

이때 쓸 데이터 관리는 갑의 역할입니다. 코드값부터 고객데이터까지 사업 현장의 데이터가 필요하니까요. SI 업체가 알 리 없죠.

IT 아웃소싱 전략

즉, 아웃소싱은 돈만 주면 다 알아서 해주는 그런 일이 아닙니다. 가만두면 가만둘수록 상황은 계속 나빠지죠. 이런 위협을 피해 아웃소싱에 성공하려면 어떻게 해야 할까요?

시장에 공개된 여러 노하우 가운데, 꼭 알아야 할 것 다섯 가지를 정리해 보았습니다.

아웃소싱 기술 중 하나. 벤더 선택 및 전문가 관리하기 <출처: FastCapital>

핵심 역량은 아웃소싱하지 않는다

인스타그램 같은 SNS를 만들고 싶은 스타트업이 있습니다. 창업자는 기술을 모릅니다. 회사를 시작하며 자기는 기획서만 만들고 개발은 전부 외주 주려고 합니다.

이게 성공할까요? 아니요, 실패합니다. 대부분 계약 분쟁으로 이어지고, 창업주들은 흑화됩니다.

왜 그럴까요? 이건 IT 프로젝트를 모르는 걸 넘어 사업 세계에 대한 이해가 부족한 겁니다. 사업 세계는 돈이 된다면 남의 것도 베끼는 치열한 현장입니다. 그래서 그 어떤 업체도 핵심 역량을 아웃소싱하지 않습니다. 베껴지는 순간 사업 경쟁력을 상실하니까요.

인스타그램 같은 “아이디어”는 쉽게 베낄 수 있는 겁니다. 핵심 역량이 될 수 없죠. 반면 사용자 피드백에 빠르게 반응하고 시장에 맞춰주는 “제작 능력”은 쉽게 베낄 수 없습니다. 이건 회사의 경쟁력을 만들어 냅니다. 좋은 개발자와 좋은 기업 문화가 있어야 하니까요. 핵심 역량이 될 수 있죠.

사업 경쟁력과 핵심 역량은 보편적 원리에 기반하지 않습니다. “아이디어 도둑질”로 고소해서 이길 순 있어도, 그게 사업의 성공을 보장하진 않습니다. 단순한 아이디어만으로는 끊임없이 베껴질 위협에 시달리게 되니까요.

아웃소싱은 핵심 역량이 아닌 걸 조달하기 위한 전략입니다. 이걸 헷갈리면 안 됩니다.

목적을 뚜렷이 한다

핵심 역량이 아닌 걸 확인했다면, 우선 프로젝트의 성격부터 정합니다. 투자인지 비용인지부터 정해야 하죠.

투자형이라면, CJ대한통운이 추진했던 대형 물류 시스템 구축 같은 예를 들 수 있습니다. 돈을 벌기 위한 인프라 시스템이죠. 창고 관리, 택배 관리 등이 있습니다. 시스템의 복잡도가 높고, 쉴 새 없이 돌아가야 하니 목표 수준도 높죠.

불확실성을 줄이고 성공 확률을 높여야 합니다. 비싸더라도 크고 경험이 많은 기업을 데려와야 하죠. 예산을 충분히 확보해야 합니다.

비용형이라면, IT 시스템 운영 아웃소싱 같은 겁니다. 효율화가 중요하죠. 무엇을 절감할지, 어떻게 절감할지 정해야 합니다. 돈은 적게 쓸수록 좋죠. 하지만 망가지면 안 되니, 규모에 맞는 적당한 업체를 소싱합니다. 훌륭한 사람을 기대하면 안 됩니다. 부족한 건 시스템으로 메꿔야 하죠.

즉, 투자형이냐 비용형이냐에 따라 아웃소싱의 기준이 달라집니다. 내가 준비해야 할 사항이 달라지는 거죠.

공부해야 한다

프로젝트 발주자가 아무것도 모른다? 망한 프로젝트입니다.

기술도 알아야 하고, 사업, 관리도 알아야 하죠. 어려운 일입니다.

IT 아웃소싱은 사업에 필요한 시스템을 만드는 과정입니다. 결국 이 시스템으로 돈을 벌어야 하죠.

그런데 아직 어떻게 돈을 벌어야 할지 모른다? 만들어야 할 기능을 정의할 수 없다는 겁니다.

메일로 마케팅을 하려는 데, 누구에게 보내야 할지, 어떤 메시지를 담아야 할지, 어떤 식으로 보내야 할지 모르는 겁니다. 도달률, 오픈율을 어떻게 체크해야 할지도 모르는 겁니다.

“SI 업체가 알아서 해주겠지.” 이렇게 생각하면 오산입니다. IT 프로젝트에선 수많은 갈림길을 만나고 그때마다 선택지를 고민해야 합니다. 선택∙관리 방법과 노하우는 엄연히 교육을 통해 배우고 익혀야 하는 전문 스킬이죠.

예를 들면, 프로젝트 요구사항 정리, 목표 전달 능력, 이해관계자들과 소통 능력, 예산 편성 및 관리 능력, 협상 능력, 조달 및 계약 관리 능력, 리더십, 업무 및 기술 지식 등등이 필요합니다.

특히 리스크 관리 능력은 매우 중요합니다. SI 기업들은 아무래도 자기가 불리한 상황은 잘 이야기하지 않거든요. 갑이 미리 위험 상황을 포착하고 긴장도를 낮춰줘야 합니다.

기업 풀을 미리 관리한다

우리랑 핏이 맞는 업체가 알아서 찾아오진 않습니다. 운이 좋다면 그럴 수도 있겠지만, 거의 없다고 보는 게 맞습니다. 우리가 무언가를 만들려고 한다는 사실이 널리 알려지지 않았다면 더욱 그렇죠.

그래서 미리 기업 풀을 관리해야 합니다. 프로젝트의 규모가 클수록, 시스템이 복잡할수록, 요구사항이 까다로울수록, 도움받을 수 있는 기업들을 더 많이 알고 있어야 합니다.

가격협상력을 높이려면 2개 이상의 기업을 알고 있어야 합니다. 전화번호만 알고 있으면 안 되고, 평판도 알고 핵심 개발자들도 알고 있으면 좋습니다.

SI 기업들 역시 돈을 많이 준다고 해서 금방 관심을 보이진 않습니다. 자기들이 할 수 있는 일인지 미리 가늠하죠. 계약 불이행 등의 복잡한 상황에 휘말리면 안되니까요.

기업들을 미리 만나보고 우리가 만들고 싶은 걸 함께 상의해야 합니다. 어떻게 만들 건지 들어보고 실력도 가늠해 봐야 합니다. 복잡한 요구사항일수록 미리 이야기해 둬야 그들도 시간을 두고 방법을 찾습니다. 기업풀 관리는 꽤 많은 시간과 발품이 필요한 일입니다.

이제 막 시작한 스타트업이라면 기업 풀이 없습니다. 이럴 땐 발이 넓은 SI 기업이나 위시켓 같은 플랫폼을 활용합니다. 단, 인터뷰 등은 직접 해야 합니다.

을과 파트너쉽을 가진다

시스템 초기 구축은 대량의 자금을 투자해서 사업 인프라를 구축하는 행위입니다. 사업의 성패를 가늠할 정도로 중요한 일이죠. 당연히 우수한 사람들이 많이 투입됩니다.

기존 시스템 업그레이드는 대량의 자금을 투자해서 사업 인프라를 확장하는 행위입니다.

사업의 도약을 위해 아주 중요한 일이죠. 역시 우수한 사람들이 많이 투입됩니다.

이럴 때 갑은 을에게 새로운 파트너를 소개받기도 합니다. 새로운 아이디어와 기술력도 얻고, 골치 아픈 문제를 쉽게 해결하기도 하죠. 그렇게 만든 네트워크를 통해 새로운 시장에 진입하기도 합니다. 생각보다 흔하게 일어나는 일입니다.

한편 을은 갑을 통해 새로운 사업 기회를 만듭니다. 새로운 문제를 해결하며 전문 지식을 늘리죠. 함께 참여한 기업들과 사업적, 기술적 네트워크를 확장하기도 합니다. 사업 경쟁력이 늘죠.

2019년 삼성SDS는 CMC 글로벌이라는 베트남의 SI 회사에 투자를 합니다. 지분을 30% 수준까지 인수하죠. 처음에는 인력 공급을 받았습니다. 이젠 이 회사를 통해 베트남에 진출까지 했죠.

2020년에는 베트남의 빈커머스와 손을 잡고 스마트 물류 시스템을 구축합니다. 2023년엔 이 물류플랫폼을 “첼로 스퀘어”라는 이름으로 출시까지 하죠.

작은 프로젝트의 경우 규모가 작지만 현상이 크게 다르진 않습니다. 하지만 이런 일은 계약 관계를 넘어선 동반자 의식이 생겨야만 가능합니다. 서로 고민하고 연구해야 하니까요.

파트너쉽은 사업에서 유의미한 변곡점을 제공하기도 합니다. 그래서 갑에게도 중요한 일입니다.

마치며

“우리 일을 남에게 시킨다”, “외주업체 도와주는 거다”, “돈 주니까 대우받아야 한다”

이런 생각을 하고 있다면 매우 잘못된 겁니다. 아웃소싱에 대한 이해가 전혀 안 되어 있습니다. 교육으로 개선할 필요가 있죠.

아웃소싱은 갑이 구사하는 엄연한 “사업 전략” 중의 하나입니다. 핵심 역량에 집중하고, 전문성을 강화하는 중요한 경영 수단이기도 하죠. 경영학 수업에서 배우는 겁니다. 쉽게 생각할 건 아닙니다.

IT 프로젝트는 많은 사람이 만나 복잡한 이해관계가 얽히는 화학적 결합의 현장입니다. 작으면 작은 대로, 크면 큰 대로 새로운 변화들이 생기죠.

갑이 올바른 인식을 가진 경우와 그렇지 않은 경우는 프로젝트 결과에서 두드러진 차이가 나타납니다.

하지만, 안타깝게도 IT 아웃소싱 운영 노하우는 거의 공유되지 않죠. 엉겁결에 프로젝트를 맡아 우당탕탕하는 갑들이 대부분입니다. 그래서 실패하기도 하고요.

아웃소싱을 자주 하는 큰 기업이라면 관련 교육을 정기적으로 해야 합니다.

아웃소싱을 처음 하는 기업이라면 시간을 가지고 준비할 필요가 있습니다.

여기까지 갑의 아웃소싱 전략을 살폈습니다. 다음 편에는 “인하우스 전략”에 대해서도 이야기를 해보겠습니다.

]]>

지원하기 싫어지는 IT 채용 공고의 7가지 문제점

성의 없는 채용 공고 <출처: 작가> ※모든 예시는 실제 공고를 각색하였음

중소 IT 채용 시장에는 적합한 사람을 구하기 어렵다는 한탄이 많다. 그런데 간혹 그 어려움의 이유가 보이는 채용 공고를 만나기도 한다.

심지어 최근 본 어떤 공고는 담당 업무 항목을 채우지 않아, “상세내용을 입력하세요” 문구가 그대로 노출되고 있었다. 담당 업무 항목은 구직자의 지원 여부를 결정할 매우 중요한 정보다. 이런 성의 없는 채용 공고는 적합한 인재를 만날 가능성을 떨어뜨릴뿐더러 회사에 대한 인상까지 나쁘게 만든다.

이번 기회에 중소 IT 기업 채용 공고의 나쁜 사례들을 살펴보고 그에 대한 처리 방식을 제안하려고 한다. 중소 IT 기업에서 인사를 담당하거나 관련 있는 분들이 주목하면 좋겠다. 아울러 IT 직군 구직자들도 질 낮은 채용 공고가 만들어지는 이유와 그 사례를 숙지하며, 원하는 일자리를 얻는 데 도움을 얻길 바란다.

시작하기에 앞서: 성의 없는 채용 공고가 회사에 미칠 손실

일반적으로 성의 없는 채용 공고는 기업이 원하는 유형의 지원자를 이탈시키며 원하지 않는 지원자를 유인한다. 이는 제외 작업, 즉 필터링에 들어갈 비용을 증대시킨다. 채용 과정의 효율은 떨어져 공고만 잘 써도 쉽게 피했을 추가 업무를 만들고 만다. 대강 쓴 공고가 회사에 어떤 손실을 끼치는지 먼저 환기해 보자.

‘한 단어’만 추가해도 받지 않았을 이력서

성의 없는 채용 공고는 역시 성의 없는 지원자를 유인한다. 물론 채용 공고를 성의 있게 작성한다고 해서 이런 지원자가 없어지지는 않는다. 하지만 “성의 있게 쓴 조건에‘만’ 안 맞는 지원자”들도 있다.

예를 들어, 자바(Java) 개발자를 뽑기 위한 공고의 제목이 “개발자를 모십니다”라고 하자. 그러면 자바스크립트(JavaScript), C#, C/C++ 등 온갖 스택을 가진 개발자들이 지원할 것이다. “자바(Java)”, 한 단어만 추가해도 받지 않았을 이력서를 제외하는 작업이 추가로 생긴다.

필터링보다 채용 공고에 노력을 집중하는 편이 낫다

더 큰 문제는, 중소 IT에서 채용을 맡은 사람은 대부분 채용이 본 업무가 아니란 사실이다. 채용에 들어간 무의미한 작업 시간은 그의 본업까지 영향을 미친다. 당연히 회사 전체에 부정적인 영향이 갈 수밖에 없다. 바쁘고 시간이 없을수록 선택과 집중이 따라야 한다.

이쯤에서 중소 IT 기업의 채용 프로세스를 짚어보자. 보통은 ①채용공고 → ②서류전형 → ③면접전형 → ④최종결정 순으로 이뤄진다. 이 가운데 면접은 커뮤니케이션으로 사람을 판단해야 하는 고차원의 작업이다. 숙련이 많이 필요하고 변수도 많다. 그런 만큼 집중해 개선할 때 빠르게 효과를 볼 확률이 높은 프로세스는 채용 공고 단계다. 노력한 대로 성과가 나타날 가능성이 높은 데다가, 다음 프로세스인 서류 검토 업무의 부담도 크게 줄일 수 있다.

따라서 본업에 더해 채용까지 해야 하는 바쁜 담당자라면, 채용 공고 작성에 공을 들이는 편이 훨씬 큰 효과를 얻을 수 있다.

구직자가 지원하기 싫어지는 채용 공고 유형 7가지

채용 공고를 신경 써야 한다는 사실에 충분히 공감했다면, 이제 어떻게 채용 공고를 쓸지가 문제다. 글에서는 나쁜 사례를 먼저 살펴본 다음, 이를 피하거나 처리하는 전략을 쓰려고 한다. 지금부터 우리가 반드시 피해야 할 7가지 사례들을 확인해 보자.

1. “필수: 경력 1년↑, 우대: 근무 경험”: 필수와 우대 사항 명확하게 쓰기

채용 공고에는 구인할 사람의 자격을 표기한다. 크게 필수 사항과 우대 사항 두 가지를 내세운다.

필수 사항은 말 그대로 지원자의 자격 요건이다. 이를 충족하지 않으면 전형에서 탈락할 가능성이 높다. 이와 달리 우대 사항은 충족되지 않더라도 가능성이 있지만, 충족한다면 전형 과정에서 ‘어드밴티지’를 줄 요건이다. 하지만 이때, 조건을 잘못 설정하면 어드밴티지의 의미가 희석되고 만다.

혼란스러운 자격 요건과 우대 사항 <출처: 작가>

위 공고에는 필수 사항이 경력 1년인데, 우대 사항은 근무 경험이다. 당연히 경력이 1년 이상인 사람들만 지원할 것이기에 모두가 어드밴티지를 받는 상황이 벌어진다. 결국 아무런 변별력이 없는 우대 사항이다.

이 예시는 모 방송국의 공고를 참고했다. 우대 사항의 근무 경험 역시 방송국 경험을 염두에 뒀는데, 이를 실수로 명시하지 못한 것은 아닐까? 이처럼 우대 사항을 선택할 때는 필수 사항과 함께 점검하며 정말 효율적인지 검토해야 한다.

2. “C++, JSP 필수”: OR/AND 분명하게 설정하기

명확하지 않은 필수 사항 <출처: 작가>

이 채용 공고에서 이상한 점을 이해했는가? 이를 이해하려면 업계 배경지식이 필요하다.

일반적으로 C++과 JSP는 쓰이는 영역이 다르다. 따라서 두 가지 모두 다루는 사람은 드물다. 즉, 이 채용 담당자는 둘 중 하나만 다룰 수 있어도 상관없다고 생각했을 가능성이 높다. 하지만 둘 중 하나만 할 줄 아는 대부분의 구직자는 저 필수 사항을 보고 이력서조차 내지 않을 것이다.

필수 사항 안에도 조건부 수용이 있다. 공고를 “C++, JSP 중 1개 가능” 같은 식으로 고친다면, 하나만 할 줄 알지만 다른 조건에 부합하는 사람들의 지원을 받기 수월해진다.

만약 둘 중 하나, 이를테면 C++의 업무 비중이 높은 편이라면 어떻게 해야 할까? 그렇다면 필수 사항을 C++ 하나만 쓰고 우대 사항에 “JSP 가능(또는 경험)”으로 작성하는 것도 방법이다. 이것만으로도 적합한 인재를 구할 가능성을 높여줄 것이다.

3. “경력 무관”: 경력/연차 범위 설정하기

채용 공고의 경력 무관 <출처: 작가>

신입/경력 상관없이 채용할 계획의 회사는 “경력 무관”이라는 문구를 쓰는 경우가 많다.

다만 지원 의사를 가진 경력 5년 차가 이런 공고를 보고 찾아올 가능성이 높을까? 정답은 ‘아니’다. 경력 무관이란 표현은 신입 혹은 경력 1년 차를 뽑겠다는 시그널을 보낸다.

이런 공고를 낸 회사의 상황을 생각해 보라. 대표이사 등 경영진은 피고용자가 늘면 영업 손실이 있을지 점검하고 공고를 내라고 한다. 단적인 예를 들어 보자. 상사가 점심을 한턱 쏘겠다며 “짜장면도 괜찮고, 짬뽕밥도 상관없다”고 말했다. 부하 직원인 당신은 당당히 짜장면과 짬뽕밥을 건너뛰고 “삼선짬뽕”을 주문할 자신이 있는가? 더 쉬운 말로 하면, 경영진이 “연봉 3천에서 1억쯤?” 하며 공고를 냈을 리가 없다. “3천에서 4천쯤?” 정도 좁은 폭을 예상하고 경력 무관이란 조건을 주었다는 뜻이다.

따라서 경력 무관 채용 공고를 냈더라도 실제로는 경력이 유관할 가능성이 매우 높다. 이는 “1년 차 이하인들 어떠하리, 신입인들 어떠하리”란 의미로 통한다. 즉, 기업도 높은 확률로 경력 많은 지원자를 서류 전형에서 탈락시킬 것이다.

이런 의도에 공감한다면 경력 무관이라고 하기보다는 “신입을 포함하며 경력일 경우 최소 1년 이하, 또는 3년 이하”라고 범위를 설정할 것을 권장한다. 제한을 걸지 않을수록 채용 담당자와 지원자 모두의 필터링 작업이 늘어난다. 굳이 안 해도 될 일을 벌리지 말자.

만약 정말로 신입과 경력 둘 다 뽑고 있다면 어떻게 해야 할까? 이럴 경우 공고를 별개로 작성하는 것이 좋다.

4. “1차 면접, 2차 면접” : 이직 희망자를 배려하기

1차/2차 면접 <출처: 작가>

신입은 보통 현재는 백수인 경우가 많아 시간이 넉넉한 사람들이다. 이와 달리 경력직은 회사를 다니고 있는 이직 희망자가 대부분이다.

일반적으로 면접은 실무진의 판단과 임원의 판단으로 나뉜다. 중소기업의 경우에는 면접 한 번에 이들 모두가 참석해 처리하는 편이다.

그런 관점에서 회사에 다니고 있는 이직 희망자에게 2차 면접은 큰 부담이다. 만약 면접 한 번에 처리하는 경우가 일반적인데, 혹시 모를 가능성에 2차 면접이라 작성했다면 수정하자.

또한 팬데믹 이후에는 화상 면접도 흔해졌다. 화상 면접도 가능하다는 언급을 공고에 명시하면, 이직 희망자가 조금 더 부담 없이 지원할 것이다.

5. “근무 조건/복리 후생 정보 없음”: 문제가 될 정보는 미리 알리기

근무 조건(출퇴근 시간, 주 5일제 여부, 근무 지역 등)과 복리 후생은 매우 중요한 정보이다. 특히, 이직 희망자들은 현 직장과 옮겨갈 직장의 근무 조건, 복리 후생 등 차이를 정말 중요하게 생각한다.

만약 이런 내용을 공고에 미리 언급하지 않으면 어떨까? 면접 때 나와 맞지 않는 조건을 듣는다면 실망감이 더 크게 다가온다. 곧 면접자와 면접관 모두 헛된 시간을 보낼 것이다.

이직 희망자에게는 면접 시간을 내는 데 많은 어려움이 따른다. 실무에 바로 투입할 경력직을 채용하고 있다면, 이직 희망자들을 충분히 배려해야 한다. 되도록 근무 조건과 복리 후생은 채용 공고에 명시하는 것이 바람직하다.

6. “원활한 커뮤니케이션 능력” : 기준이 부정확한 스킬 제외하기

기준이 부정확한 스킬 <출처: 작가>

우대 사항이란 ‘어드밴티지’라고 한 바 있다. 하지만 공고를 내며 이런 사항이 어느 정도 가중치를 가지는지 정했을 가능성은 높지 않다. 또한 언급한 항목에 대해 어느 정도 수준을 기대하는지 알기 어려운 경우도 많다.

예를 들어, ‘원활한 커뮤니케이션 능력’이란 표현을 보자. 면접에서 한 두 번의 질문으로 커뮤니케이션 능력을 모두 파악할 수 있을까?

산업인력공단의 NCS 표준에 의하면 커뮤니케이션 능력은 “상대방과 대화를 나누거나 문서를 통해 의견을 교환할 때, 상호 간에 전달하고자 하는 의미를 정확하게 전달할 수 있는 능력을 의미”한다. 즉, 커뮤니케이션이란 말뿐만 아니라 글과 문서 작성을 포함한 능력이다. 그렇다면 두루뭉술한 표현보다 직접 작성한 문서를 포트폴리오로 제출하라고 제시하는 것이 좋다. 노션, 슬랙, 지라 등 도구 활용 능력을 우대 사항으로 두는 것도 원하는 인재의 지원을 받을 방법이다.

7. “연봉은 회사 내규에 따름. 희망 연봉 기재는 필수”: 예상하는 연봉 범위 먼저 제시하기

희망 연봉 기재 요망 <출처: 작가>

급여 기준은 “회사 내규에 따름”이면서 지원자에게는 희망 연봉을 기재하라는 경우가 있다. 회사의 내규가 이미 있는 상황이라면서 왜 희망 연봉을 기재하라는 것일까? 일관성 없는 채용 공고이다. 회사가 연봉을 공개하는 걸 꺼리는 것까지는 이해할 수 있다. 그런데 굳이 희망 연봉을 지원자에게 받으려면 그 범위를 명시하는 편이 차라리 낫다.

여기서 연봉 공개에 대한 시사적인 의견을 피력하고자 한다. 최근 국내 채용 공고를 보면 신입은 연봉 범위를 공개하는 경우가 많아졌다. 그러나 아직 멀었다. 미국 채용 사이트 인디드만 가더라도 웬만하면 연봉 범위에 대한 정보가 신입/경력 따지지 않고 쓰여 있다. 직장인이 일하는 가장 큰 이유는 결국 돈인데, 왜 가격표가 없는 걸까? 아주 극단적인 예시지만, 19세기 미국 노예 매매 시장에서도 수요와 공급 모두 가격표가 있었다. 노예제는 철폐되었지만, 한국의 채용 시장은 그보다 못한지 가격표가 존재하지 않는다. 구직자에게 그보다 중요한 정보가 없는데 말이다.

이런 이유로 지난 2023년, 대통령실에서 채용 공고에 연봉 범위를 명시할 법적 근거를 마련하겠다고 한 바 있다. (참고 기사) 연봉을 공개하는 추세로 돌아선 채용 시장 분위기에 따라, 특히 신입을 채용한다면, 연봉 범위를 명시할 것을 권하고 싶다.

마치며

지금까지 나쁜 채용 공고 사례를 바탕으로 그에 대한 적절한 처리 방식과 고민을 피력해 보았다. 이런 사례를 피할 수 있다면, 그것만으로도 이미 좋은 채용 공고를 쓸 준비가 된 것이다.

좋은 채용 공고란 구직자와 구인자 모두에게 효율을 가져다주어야 한다고 생각한다. 이번 글이 기업이 원하는 인재를 얻는 데 조금이라도 도움이 되었기를 바란다. 또, 건전하고 투명한 IT 채용 시장이 만들어 지는데 약간이라도 보탬이 되기를 희망한다.

]]>

집으로 찾아온 챗GPT, 이런 것까지 된다고?

지난 6월, 네덜란드의 스마트홈 플랫폼 홈 어시스턴트(Home Assistant, 이하 HA)에서 챗GPT 플러그인을 공개했습니다. 여기서 스마트홈 플랫폼이란, 가전제품이나 조명 등 집 안의 스마트 기기를 연결해 원격으로 제어하거나 자동화할 수 있는 서비스 플랫폼을 말합니다.

최근에 삼성이나 LG 가전을 구매할 일이 있었다면 판매 직원이 스마트폰으로 기기를 켜고 끌 수 있는 모바일 앱을 보여준 기억이 있을 겁니다. 아니면 안드로이드 폰이나 아이폰을 구매했을 때 기본으로 설치되어 있던 ‘Home’ 앱을 떠올릴 수도 있죠. 이 친숙한 앱이 모두 스마트홈 플랫폼입니다.

반면 HA는 우리에게 친숙한 플랫폼은 아닙니다. 삼성전자의 스마트홈 플랫폼인 ‘SmartThings’의 회원 수가 약 3억 5천만 명이라는 것을 고려할 때, 약 100만 명의 사용자를 보유한 HA는 비교적 작은 플랫폼입니다.

하지만 HA는 빅테크 기업인 구글과 애플, 제조 기업인 삼성과 LG가 아직 하지 못한 생성형 AI의 도입과 상용화를 누구보다 빠르게 해냈습니다. 플랫폼에 통합 모듈(integration)을 연결하는 것만으로 가전 시장에서도 자연어의 맥락과 멀티 턴을 인식하는 ‘진짜 사람’ 같은 어시스턴트를 사용하게 만든 것이죠. 과연 HA는 어떻게 이러한 성과를 만들어 낼 수 있었을까요? HA의 AI는 무엇까지 할 수 있을까요?

고급 사용자를 위한 스마트홈 플랫폼, HA

HA는 창립자인 파울루스 슈우젠(Paulus Schoutsen)이 2013년 처음 출시한 스마트홈 플랫폼입니다. 대중적인 플랫폼과 다른 두 가지 특징이 있는데요, 하나는 로컬 기반이라는 것이고, 다른 하나는 오픈 소스 플랫폼이라는 것입니다.

<출처: 작가, Napkin.ai로 생성>

첫 번째 특징, 로컬

보통 우리가 스마트홈 플랫폼에 기기를 연결한다고 하면 떠올리는 방법은 다음과 같습니다.

기기를 페어링 모드로 만든다.
스마트홈 앱에서 기기를 페어링한다.
연결 완료!

기기 연결이 이렇게 간단한 이유는 대부분의 스마트홈 플랫폼이 클라우드 기반이기 때문입니다. 플랫폼이 보유한 클라우드 서버에서 모든 처리 과정을 대신해 주므로 사용자는 다른 것을 신경 쓰지 않고, 그저 앱에서 버튼만 누르면 됩니다. 사용자가 버튼을 누르는 순간 플랫폼의 클라우드 서버에 버튼을 눌렀다는 신호가 전달됩니다. 곧 클라우드에서 그 신호를 처리하며 기기가 동작하는 것입니다. 혹자는 이 과정이 사람이 생각하는 것과 유사하다고 하여 클라우드 서버가 ‘두뇌’의 역할을 한다고 말하기도 합니다. 스마트홈 밖에 위치한 ‘두뇌’로 신호가 왔다 갔다 하는 것입니다.

반면 HA는 두뇌(서버)를 집 안(로컬)에 두는 방식입니다. 사용자가 앱에서 버튼을 누르면 집 안에 물리적으로 설치된 서버에서 신호를 처리합니다. 그런데 이 방식에는 큰 단점이 있습니다. 연결이 그리 간단하지 않다는 것이죠. 노트북 컴퓨터와 같은 ‘두뇌’ 역할을 하는 별도의 장치가 필요하기 때문입니다. 이런 장치를 구매하기 위해 하드웨어에 대한 지식이 있어야 할 뿐만 아니라 네트워크 설정을 직접 하는 등 별도 구축 과정을 거쳐야 한다는 어려움이 있습니다.

클라우드 방식과 로컬 방식의 차이는 간단합니다. 인터넷이 끊겼을 때 기기 제어도 함께 끊기면 클라우드 방식, 인터넷이 끊겨도 기기 제어가 가능하다면 로컬 방식입니다.

이 외에도 두 가지 방식에는 주요한 차이가 있습니다. 클라우드 방식은 서버를 업데이트하는 것만으로 오류를 수정하거나 새로운 기능을 추가할 수 있어 유지 보수가 쉽지만, 안정성과 속도 측면에서는 아쉬운 점이 많습니다. 흔히 말하듯 서버가 터지거나 갑자기 인터넷이 끊기면 작동이 멈출 수 있고, 매번 인터넷을 거쳐야 하므로 비교적 속도가 느리기도 합니다.

한편 로컬 방식은 일단 구축하기만 하면 외부 서버에 의존할 필요가 없어 안정적이고, 속도가 빠릅니다. 하지만 유지 보수 역시 전적으로 개인의 몫이 되죠.

<출처: 작가, Napkin.ai로 생성>

구글 Home과 삼성 SmartThings 같이 대중적인 플랫폼은 클라우드 방식을 채택해 입문 사용자까지 포용하는 플랫폼으로 성장했습니다. 반면 HA는 스마트홈에 관심이 많은 일부 고급 사용자들 사이에서 핵심 플랫폼으로 자리 잡았습니다. 물론 주요 작동 방식이 무엇인지와는 무관하게 SmartThings도 일부 로컬 기기 제어를 제공하고 HA도 클라우드 방식의 기기 연결을 제공하고 있습니다. 실제로는 두 방식이 상호보완적으로 사용되는 것입니다.

두 번째 특징, 오픈 소스 플랫폼

HA의 두 번째 특징은 바로 ‘오픈 소스 플랫폼’이라는 점입니다. HA 홈페이지에서는 현재 3,000개가량의 통합 모듈을 지원하며, 각 모듈에는 모두 소유자(Integration Owner)가 따로 있습니다. 마치 깃허브(GitHub)처럼 필요한 기능을 만들고 공유할 수 있도록 만들어졌기 때문입니다.

HA 사용자는 이 통합 모듈을 활용해 앞서 언급한 구글 Home이나 SmartThings를 HA에 연결하는 것은 물론, 전 세계 다양한 사업자의 기기와 플랫폼을 연동할 수 있습니다. 기본적인 소프트웨어 지식이 있어야 한다는 진입장벽이 있지만, 일단 사용법만 깨우친다면 어떤 플랫폼보다 강력한 커스터마이징이 가능합니다. HA가 고급 사용자에게 사랑받는 또 다른 이유입니다.

Home Assistant Integrations <출처: Home Assistant 홈페이지>

물론 삼성 SmartThings도 삼성 기기 외 다른 제품군을 연결할 수 있는 오픈 플랫폼입니다. 앱만으로 구현할 수 없는 고도화된 자동화를 플랫폼에서 직접 만들 수도 있죠. 하지만 HA처럼 오픈 소스 자체가 그 정체성이라기보다는 부가적으로 제공하는 기능에 가깝습니다. 깃허브 레포지토리까지 따로 보유한 HA보다는 사용자 커뮤니티가 활성화되어 있지 않고, 기능도 제한적입니다. 폐쇄형 플랫폼으로 출발한 애플 Home과 구글 Home, LG ThinQ도 현재는 타사 기기의 연결을 지원하고 있지만 역시 제한적이죠.

<출처: Samsung Automation Studio>

대기업이나 빅테크에서 오픈 소스를 적극 도입하지 않는 것은 사용자에게 어렵다는 이유도 있겠지만 안정성을 확보하기 위함이 아닐까 싶습니다. 처음 통합 모듈을 배포한 소유자가 지속적으로 업데이트를 해줄지 알 수 없는 데다, 많은 사람이 플랫폼에 오픈 소스로 접근하다 보면 고객 관리 및 응대의 책임 소재도 불분명해질 수밖에 없기 때문입니다.

HA가 생성형 AI를 빨리 도입할 수 있었던 이유

대기업과 빅테크가 이런 한계로 주춤거리는 사이, HA에서는 통합 모듈 OpenAI Conversation을 공개했습니다. 소유자는 파울루스 슈우젠, HA의 창립자입니다.

이 모듈로 사용자는 오픈AI의 API 키를 HA에 연동할 수 있습니다. 기본적으로는 GPT-3.5로 연동이 가능하고, 만약 사용자가 구독하고 있는 모델이 있다면 해당 모델을 불러와 사용할 수도 있습니다. 답변의 길이를 결정하는 최대 토큰 수(Maximum Tokens to Return in Response)와 응답의 창의성과 자유도를 결정하는 온도(Temperature) 역시 사용 옵션으로 선택할 수 있습니다. 또, API를 가져다 쓰는 것인 만큼 GPT의 성능이 높아지면 연동한 HA 내의 성능도 좋아집니다. 모두 HA가 오픈 소스 플랫폼이기 때문에 가능한 일입니다.

그뿐만 아니라 HA가 로컬 기반 플랫폼이라는 점도 AI 도입에 한몫했습니다. 로컬 플랫폼이 상대적으로 보안에 강하기 때문이죠. 보안 문제는 스마트 스피커를 포함한 스마트홈 분야에서 생성형 AI가 활발히 쓰이지 못하는 가장 큰 이유 중 하나입니다.

처음 생성형 AI가 나왔을 때, 많은 사람이 영화 ‘그녀(Her)’의 사만다나 ‘아이언맨’의 자비스처럼 대화를 주고받을 수 있는 진짜 비서를 기대했습니다. 그러나 이런 꿈은 지금까지 실현되지 못했죠. 여러 가지 이유가 있겠지만, 분명한 점은 성능만의 문제는 아니라는 것입니다. 그중 보안 문제가 아주 큰 비중을 차지하고 있고요. 생성형 AI는 사람들과 상호작용하고, 그 데이터를 다시 학습해 다른 정보를 제공합니다. 만약 비서 역할을 맡기기 위해 사용자가 모든 개인 정보와 민감 정보를 넘겨주면, 그 정보가 다시 학습 데이터로 쓰이며 다른 사람들에게 유출될지 모릅니다.

그래서 최근에는 서버나 인터넷 연결 없이도 기기 내에서 자체적으로 분석할 수 있는 온디바이스 AI 개념이 급부상하고 있습니다. 이를 스마트홈에 적용할 때 로컬 환경, 즉, 인터넷 연결 없이도 작동하도록 구축할 수밖에 없는 HA는 온디바이스 AI를 구현하기 가장 좋은 환경에 있다고 볼 수 있습니다.

HA와 로컬 LLM

HA도 이 기회를 놓치지 않고 로컬 LLM에 심혈을 기울이고 있습니다. 앞서 소개한 오픈AI 통합 모듈은 API 방식으로 아무리 HA에 기기를 로컬로 연결했더라도 외부와 데이터를 주고받게 됩니다. 결국 개인정보에 대한 우려가 발생할 수밖에 없습니다.

이런 단점을 막기 위해 HA는 엔비디아의 젯슨 AI 리서치 그룹(Jetson AI Lab Research Group)과 협력해 모델을 고도화하고 있습니다. 당장 성능은 조금 부족하더라도 장기적으로는 더 효율적이고 보안상 문제가 없는 로컬 AI를 제공하기 위함입니다. 그 결과, 아직 실험적인 단계라고는 하지만 현재도 로컬 LLM인 Ollama 통합 모듈을 제공하고 있습니다. 최근에는 로컬 Llama 3 모델로 기기를 제어하는 프로토타입을 공개하며 진전을 보이고 있습니다.

이처럼 앞으로의 스마트홈은 보안과 안정성을 위해 로컬 환경에서 기기를 제어하며, 생성형 AI까지 활용할 수 있는 플랫폼으로 전환되어야 할 것입니다. 클라우드 기반의 플랫폼은 로컬 AI를 도입하려면 로컬 프로세싱이 구동될 수 있는 기기부터 배포해야 하기에 현실적으로 빠르게 도입하기는 쉽지 않습니다. 하지만 이미 로컬 서버를 보유한 HA 사용자의 경우, HA에서 로컬 기반의 LLM 모델을 공개하면 대부분의 사용자가 곧바로 써볼 수 있습니다. 진입장벽이 높은 대신 모든 사용자가 로컬 서버를 가지고 있는 HA가 AI 시대의 스마트홈 플랫폼으로서는 유리한 고지를 점하고 있는 셈이죠. 또, 이것이 HA가 로컬 AI에 집중할 수 있는 이유입니다.

정리해 보겠습니다. HA는 로컬 서버라는 안정적인 시스템 기반 위에 다양한 오픈 소스 커스터마이징을 지원합니다. 그 덕분에 AI 기능을 빠르게 서빙할 수 있었고, 자체적으로 로컬 AI 기술을 개발하여 향후 스마트홈 시장의 생성형 AI를 선점하고 있습니다. 다만, 높은 진입장벽을 어떻게 허물 수 있을지는 여전한 HA의 과제입니다.

스마트홈에 들어간 챗GPT는 무엇을 할 수 있을까?

현재 HA에서 통합할 수 있는 API 기반의 LLM 모듈은 오픈AI와 구글의 AI입니다. 처음 LLM 모듈이 공개되었을 때는 HA의 챗봇 어시스턴트인 ‘Assist’에 적용하여 대화하는 정도만 가능했으며, 대화로 집에 있는 기기를 직접 제어하지는 못했습니다. 그러나 올해 6월, 릴리즈 파티에서 기기 제어까지 가능한 LLM 데모가 공개되며 사용자들의 큰 호응을 얻었습니다.

데모를 리뷰하며 발견한 세 가지 특징을 정리했습니다. 그와 함께 스마트홈 어시스턴트로서의 챗GPT가 어떤 모습일지, 그 가능성에 대해 이야기 해보겠습니다.

1. 대화를 기억하는 멀티 턴 제어

데모 시연에는 OpenAI Conversation이 적용된 HA Assist가 활용되었습니다. 우선 세션 진행자는 챗봇에 불을 켜달라고 요청합니다. 곧이어 다시 꺼달라고도 요청합니다. 이때, 처음에는 ‘거실 불(living room lights)’을 켜달라고 목적어를 정확히 지칭하지만, 그다음에는 ‘그것들(them)’을 꺼달라고 대명사로 요청합니다.

Home Assistant 2024.6 Release Party <출처: HA 유튜브>

그럼에도 챗봇은 헷갈리지 않고 바로 거실 불을 꺼 줍니다. LLM 하면 가장 먼저 떠오르는 기능인 ‘멀티 턴 대화’가 스마트홈 제어에서도 가능한 것입니다. 당연하고도 간단한 상호작용이지만, 그동안 스마트홈 스피커와 대화할 때 느꼈던 답답함을 해소할 밑바탕이 될 중요한 변화라고 할 수 있습니다.

2. 맥락을 파악하는 솔루션 제안

이번에는 진행자가 단순히 ‘조명을 켜줘’, ‘꺼줘’와 같은 직접적인 표현 대신 상황 설명만 써 간접적으로 표현해 봅니다. “내가 스트리밍을 하고 있는데, 사람들이 내 얼굴이 잘 안 보인다고 하네. 네가 뭔가를 좀 해줘 봐." 이렇게 말이죠.

그 말을 들은 Assist는 즉시 웹캠 조명을 켜 주었습니다. 기존의 스마트홈에서는 없었던 경험입니다.

Home Assistant 2024.6 Release Party <출처: HA 유튜브>

물론 이 영상은 데모이기 때문에 가장 잘 적용되는 케이스를 예로 든 것입니다. 이렇게 작동되려면 몇 가지 조건이 갖추어져야 합니다.

우선, 기기의 이름을 예측할 수 있게 설정해야 합니다. 이를테면 영상에서는 조명의 이름이 ‘Webcam’이라고 되어 있었습니다. 만약 조명의 이름이 기기의 모델명으로 되어 있었다면, 아마 예시와 같은 추론은 불가능했을 것입니다.

또한 기기의 위치도 정확하게 할당해 두어야 합니다. 보통 스마트홈 플랫폼에서는 기기를 등록할 때, 기기의 이름뿐만 아니라 그 기기가 어떤 방에 위치해 있는지를 설정하게 합니다. 위치를 설정하지 않고 모호하게 둔다면 전혀 다른 공간에 있는 기기가 작동할 수도 있기 때문입니다.

마지막으로, 사용자가 집 안 어디에 있는지 파악할 수 있어야 합니다. 영상 속 예시에서 만약 ‘Webcam’이라는 이름의 조명과 스트리밍을 할 수 있는 컴퓨터가 여러 대 있었다면, 어떤 기기를 켜야 할지 Assist가 파악할 수 없었을 것입니다. 이를 파악하려면 컴퓨터와 연결해 사용자가 어떤 기기로 스트리밍을 하는지 알 수 있거나, 재실 센서 등으로 사람이 어떤 방에 있는지 감지할 수 있어야 합니다.

이런 조건이 필요한 것은 사람이 눈으로 보는 것처럼 직접 현재 상황을 파악하는 것이 아닌, 들어온 데이터를 기준으로 상호작용을 하기 때문입니다. 이런 한계에도 가능한 많은 기기를 연결하며 초기 설정을 잘해 둔다면, 충분히 일상에서도 활용할 수 있어 보였습니다.

3. 주어진 조건을 분석하는 정보 제공

마지막으로, 일상적인 질문에 답하기 위해 주어진 조건을 스스로 분석하는 모습도 볼 수 있었습니다. 예시로 사용된 질문은 “내 자동차로 얼마나 멀리 갈 수 있지?”, “낭트(Nantes)까지 갈 수 있나?”였습니다. 곧 Assist는 연결된 테슬라의 충전 정보를 기반으로 정보를 제공했습니다. 충전 차량의 주행 가능 거리와 함께 현재 위치에서부터 해당 지역까지의 거리를 검색해 가능 여부를 알려주는 데는 몇 초도 걸리지 않았습니다.

Home Assistant 2024.6 Release Party <출처: HA 유튜브>

다른 예시로 나온 “엠파이어 스테이트 빌딩이 50m보다 높으면 불을 켜줘"라는 요청에도 “엠파이어 스테이트 빌딩은 381m로 50m보다 높기 때문에 불을 켤게요"라는 답변을 주며 불을 켜주기도 했습니다. 자동차 충전 상태처럼 기기의 정보를 기반으로 답변을 제공하는 것은 물론, 주어진 조건에 대한 외부 정보를 검색하는 것도 가능한 것입니다.

영화 속 진정한 비서의 꿈, 스마트홈

HA의 데모 영상에서 세션 진행자는 자신의 Assist 챗봇을 ‘JarvisGPT’라고 칭했습니다. 영화 ‘아이언맨’ 속 토니 스타크의 음성 비서 ‘자비스’에서 따온 이름이자, 생성형 AI를 통해 모두가 꾸는 꿈이기도 하죠.

그러나 지금처럼 AI가 생산성 도구로써 웹 서비스 안에만 존재한다면, 진정한 의미의 자비스는 실현되기 어려울 것입니다. 결국 이들 AI가 개인의 모든 정보와 맥락을 파악하며 일상과 밀접한 곳에 존재해야만 하겠죠. 그 중심에는 스마트폰과 스마트홈이 있을 것이며, 온디바이스와 로컬 AI 기반의 보안이 더욱 중요해질 것입니다. 최근 애플이 애플 인텔리전스를 발표하면서 보안을 강조한 것도 같은 맥락입니다.

다만 현실에서는 시간이 필요해 보입니다. 지난 8월, 구글 홈이 제미나이(Gemini)를 적용해 홈캠에 찍힌 영상을 요약해 주고, 홈 자동화 생성 기능을 제공하겠다는 계획을 밝힌 바 있습니다. 그러나 이는 생성형 AI가 직접 기기를 제어하거나 자비스처럼 도움을 주는 개념은 아니었습니다. 집 안의 기기까지 AI로 제어하기에는 아직 기능적으로나 보안적으로나 플랫폼에서 가져야 할 책임감이 막중하다는 판단이 아닐까 싶습니다.

그런 관점에서 HA를 주목할 수 있습니다. HA는 오픈 소스 기반의 커스터마이징 방식으로 AI를 제공하기 때문에 플랫폼에서 하나의 기능을 탑재해 제공하는 방식보다는 책임 소재를 피할 수 있습니다. 그뿐만 아니라 로컬 기반이라는 장점 덕분에 장기적으로는 보안에 대한 우려도 해결할 수 있습니다. 그런 만큼 빠르게 생성형 AI 기반의 어시스턴트를 도입할 수 있었습니다.

물론 구글 Home이나 애플 Home, 삼성 SmartThings 같은 클라우드 기반의 플랫폼 역시 AI를 그대로 두지 않을 겁니다. 이들이 어떻게 생성형 AI를 도입해 나갈지도 주목해야 할 관전 포인트입니다. 이 글을 읽는 독자분들도 스마트홈이라는 새로운 관점에서 흥미롭게 생성형 AI의 변화를 지켜볼 수 있기를 바랍니다.

[위시켓 AI 컨설팅 무료 이벤트]

요즘IT 독자들을 위해 준비했어요. 챗봇/데이터 자동화/업무 효율화 등 AI 도입을 고민하고 있다면 위시켓의 AI 컨설팅을 무료로 신청해 보세요. 문제 상황 정의부터 성과 추적, 솔루션 구축까지 한 번에 제안 드립니다.

]]>

스마트팩토리 개발자는 어떻게 리팩토링할까?

2000년도 중후반, .NET Windows Form(이하 WinForm)이 공장자동화 계열에서 MFC, VB와 같은 윈도우 프로그램을 대체하기 시작했다. 어느덧 시간이 흘러, 이제 WinForm을 다루는 개발자들은 무언가 새로운 것을 개발하는 업무는 거의 없는 상황에 놓였다. 그보다 묵을 대로 묵은 옛 선배들의 레거시 코드를 리팩토링하거나 이를 참고해 기능을 확장하는 경우가 많다.

일반적으로 개발 분야에서 리팩토링이란 “결과의 변경 없이 코드의 구조를 재조정함”을 의미한다. WinForm에는 GUI 디자이너, Win32 컨트롤, Form 등 독자적인 클래스 라이브러리가 있으므로 이와 같은 환경에 적용할 리팩토링 방법을 이해해야 한다.

이 글은 스마트팩토리 분야에서 가장 많이 쓰이는 .NET WinForm의 리팩토링 방법을 다룰 예정이다. 예제와 함께 필자가 스마트팩토리 분야에서 직접 WinForm 개발을 해오면서 중요하다고 생각한 몇 가지 전략을 소개하고자 한다.

리팩토링 예제: 입고 검사 프로그램

입고 검사 프로그램의 모습 <출처: 작가>

리팩토링 예제는 입고 검사 프로그램으로, 자재가 입고되면 측정한 중량이 바코드에 표시된 중량에서 벗어나는지 판정하는 역할이다. 바코드 스캐너와 중량계는 직렬로 수신받고 실적은 HTTP로 전송한다. 오래된 프로그램 기준에 맞추면서도 비교적 상위 버전인 닷넷프레임워크 4.7로 개발했다.

이 프로그램의 원본 코드는 깃허브에 올려두었다. 10년 전, 스마트팩토리 분야 1년 차 개발자가 작성했을 법한 스타일로 코딩하려 노력했다. 물론 프로그램은 매우 잘 작동한다. 하지만 코드는 정리되지 않은 엉망진창 코드다.

엉망진창 코드가 오랫동안 보존되는 이유

왜 이토록 엉망진창인 코드가 오래 보존될까? 스마트팩토리 분야에서는 흔한 상황이다. 이 업계에서는 디바이스 연동도, 단위 프로그램의 수도 많아 저관리 프로그램이 자주 발생한다. 이 프로그램들은 가치가 낮으므로 리팩토링 비용이 비쌀 수밖에 없다. 따라서 상황이 나아지지 않고 오래 유지된다.

문제는 이런 저관리 프로그램을 주로 주니어 개발자가 맡는다는 점이다. 좋은 프로그램이 나올 리 없고 좋은 개발자가 나올 리 없다. 게다가 너무 오래도록 리팩토링하지 않은 프로그램이 있다면, 회사의 품질 관리 문제가 생길 수 있다.

그렇다면 프로젝트에서 리팩토링은 어떤 시기에 필요할까? 앞서 말했듯 스마트팩토리 분야는 디바이스 연동이 많다. 그래서 개발과 단위 테스트를 잘하고 가더라도 결국 실제 통신 시에 코드를 고칠 일이 자주 발생한다. 스마트팩토리에서 통합 테스트 기간은 비교적 넉넉하게 잡기 때문에, 급히 문제를 해결하지 않도록 그 기간에 리팩토링은 진행하는 것을 권장한다.

리팩토링 시작하기

먼저 예제 코드에 대한 안내를 하고자 한다. 예제 항목들은 아래 세 가지 목적을 가지고 있다.

단일책임으로 할당하기
사용자 정의 컨트롤 만들기
if-else 지옥 벗어나기

각 항목 모두 기존 코드에서 출발해 Git 브랜치를 새로 만들어 리팩토링을 진행했다. 따라서 순서에 상관이 없이 읽을 수 있다. 이에 맞춰 깃허브에 올려둔 소스들도 여러 브랜치로 커밋했다. 직접 리팩토링 연습을 하고 싶다면 master 브랜치를 포크 받으면 된다.

깃허브에 올라간 브랜치 구조 <출처: 작가>

단일책임으로 할당하기

1. 문제와 해결 방안

입고 검사 프로그램의 기존 코드에서는 ReceiveInspection 클래스가 바코드 스캐너, 중량계, REST API 연결에 대한 설정과 전송 및 수신 처리를 모두 수행한다. 클래스 하나가 여러 책임을 지는 데다 서로 의존성이 큰 탓에 변경이 일어날 때 관련 없는 곳까지 영향이 갈 수 있어 관리가 어렵다. 이런 문제의 해결 방안은 모듈화로, 책임을 각 모듈에 할당하는 것이다.

2. 코드 분석 및 모듈 간단 설계

리팩토링 시에는 우선 코드를 분석하고 이해하는 것이 먼저다. 기존 코드의 기능들을 적당히 배치해 보면 1) 바코드 스캐너, 2) 중량계, 3) 작업 실적 세 가지로 나눌 수 있다. 물론 단일책임으로 분리하는 공사는 품이 많이 들기 때문에 신중하게 결정하고 진행해야 한다.

3. 리팩토링

모듈화는 코드의 구조적 변경이 필요한 경우가 많다. Git이나 SVN을 쓴다면, 브랜치를 하나 만들어 작업하는 걸 권장한다. 나는 Git에서 refactorer_1 브랜치를 만들었다.

또한 모듈을 새로 만들어야 한다면 테스트 주도 개발(TDD)로 시작할 것을 권하고 싶다. 다만 디바이스 연동과 의존하는 모듈이라면, 테스트를 만들 때 모킹(모의 객체)하느라 시간이 더 걸리므로 정말 효율적인지 판단하고 결정할 필요가 있다.

글에서는 바코드 스캐너 기능의 모듈화 과정만을 설명하고자 한다. 다음과 같이 스캐너 연결을 시작하고 연결이 OK가 되는 테스트 코드를 작성했다. (프로젝트는 MSTest이고 모킹 라이브러리는 Moq를 사용했다)

현재는 모듈을 작성한 것이 없기 때문에 컴파일 에러가 난다. 다음의 코드를 작업해 주자.

코드를 간단히 설명하자면, XerialPort는 직렬 통신을 위한 SerialPort 라이브러리에 의존성을 주입하고자 만들었다. 이제 BarcodeScanner 클래스는 생성 시점부터 XerialPort 객체를 파라미터로 참조한다. 스캐너의 연결 상태는 열거자 BarcodeScannerStatus로 알 수 있게 했다. 이 정도만 해도 테스트를 통과할 수 있다.

다음 단계는 스캐너 가동 기능을 테스트하는 것이다. ConnectStart 메소드를 호출하고 시작된 상태인지 체크한다.

컴파일 에러가 안 나도록 ConnectStart 메소드를 BarcodeScanner 클래스에 추가한다. 이 메소드가 호출되면 다른 스레드에서 매 5초마다 확인해서 연결시킨다. 기존 코드를 확인해 보자.

이 코드를 긁어서 BarcodeScanner 클래스에 방금 추가한 ConnectStart 메소드에 붙여 넣었다.

물론 컴파일 에러가 난다. serialPort1, StatusMessageShow 등이 기존 클래스의 자원들이기 때문이다. 이를 해결하려면 serialPort1은 BarcodeScanner의 멤버인 _port로 변경해줄 수 있다. StatusMessageShow 메소드는 창 하단에 메시지를 출력하는 기능인데, 귀찮지만 대리자를 거쳐 외부에서 해당 Form의 UI 자원에 전달할 수 있도록 처리하면 된다.

먼저 Program.cs로 가서 다음과 같이 대리자를 추가해 주고 해당 Form의 메소드를 참조할 수 있다. 이 코드로 Program.statusMessageShow는 f.StatusMessageShow의 함수 포인터로 동작한다.

다시 옮겨온 코드는 다음과 같이 대리자를 호출하도록 바뀐다.

마지막 작업이다. 기존 코드로 가서 바코드 스캐너 객체를 생성하고 ConnectStart 메소드를 호출하도록 변경한다.

이렇게 단일 책임을 위한 리팩토링 일부가 끝났다. 핵심은 꾸준히 테스트를 만들면서 기존 코드를 모듈화하는 작업 방식이다. 모듈화는 코드 구조를 변경하는 작업인 만큼 돌다리도 두드리며 건넌다는 생각으로 임하는 게 좋다. 테스트가 쌓일수록 튼튼한 코드가 나온다.

사용자 정의 컨트롤 만들기

1. 문제와 해결 방안

판정 시 OK와 NG 여부를 화면에 출력하는 방식이 있다. 이 코드를 확인해 보니 조건에 따라 해당 레이블의 색깔을 직접 설정하는 방식임을 알 수 있다.

그러나 주석 없이 색상 변경 코드만 보면 이게 무슨 기능인지 의미를 파악하기 어렵다. 이를 사용자 정의 컨트롤을 통해 아래처럼 코드 한 줄로 만들면, 간단하고 의미도 명확한 방식이 될 것이다.

2. 리팩토링

기존 코드에서 refactor_2usc 브랜치를 만들고 작업을 진행했다. 우선 사용자 정의 컨트롤을 만들기 전에 기존의 컨트롤들이 어찌 배치되었는지 분석해 봐야 한다.

판정을 출력하는 컨트롤 그룹 <출처: 작가>

OK와 NG를 출력하는 영역은 Label 컨트롤 두 개로 기능한다. 이제 사용자 정의 컨트롤을 추가해 두 레이블을 긁어다 붙여 놓으려고 한다. 이 사용자 정의 컨트롤의 이름은 코파일럿이 추천한 ResultHighlighter로 정했다. 이처럼 리팩토링 단계에서 네이밍이 고민이면 지체 말고 인공지능에 물어보는 것이 좋다. 매우 빠르게 적절한 이름을 알려준다.

ResultHighlighter 클래스의 코드와 디자이너 모드의 구현 모습 <출처: 작가>

이처럼 사용자 정의 컨트롤을 만들고 빌드하면 디자이너 모드의 ‘도구 상자’에서 ResultHighlighter 컨트롤이 나타난다.

정의한 컨트롤이 도구 상자에 나타난 모습 <출처: 작가>

기존 화면에서 OK와 NG 컨트롤을 지우고 새로 만든 컨트롤로 바꿨다. 곧이어 다시 ResultHighlighter 클래스로 가서 다음과 같이 Result 프로퍼티를 만들어 기능까지 코딩해 줬다.

이제 기존 코드인 ReceiveInspection 클래스에서 이를 수정하면 이번 작업은 끝이 난다.

if - else 지옥에서 벗어나기

1. 문제 확인

if-else는 매우 활용도가 높은 조건문이지만, else if가 지나치게 반복되거나 조건식이 길고 복잡하면, 분석하는 사람을 지치게 한다. 그런 만큼 if-else는 잘못 쓰면 가독성을 해치기 쉽다.

아래 invoke 구문을 보자. WinForm 개발을 하다 보면 다른 스레드에서 메인 스레드의 자원인 UI 컨트롤에 접근할 일이 무척 많다. 스레드 접근 시 컨트롤의 InvokeRequired가 true가 되기 때문에, 메인 스레드가 동기적으로 처리할 수 있도록 invoke에 대리자 메소드를 넘겨주는 식이다.

문제는 코드에서 나는 악취다. 단순히 컨트롤의 Text 멤버에 문자값을 설정하는 것일 뿐인데 이런 조건문이 자주 등장하여 읽기 어렵다. 낮은 가독성 탓에 자칫하면 근처에 있을지도 모를 중요한 코드가 묻힐 가능성도 높다.

2. 리팩토링

모든 UI 컨트롤이 닷넷의 System.Windows.Forms.Control을 상속한다는 점에 착안해 해결 방법을 찾았다. 이 항목은 refactor_3ifelse 브랜치로 커밋했다.

먼저 대리자 TextSetThreadSafe로 스레드 안전한 기능을 만들어 보겠다.

앞서 InvokeRequired 조건문의 반복으로 악취가 났던 코드로 돌아가, 대리자를 추가했다.

전반적으로 바코드 스캐너 수신 이벤트의 전체 기능이 한눈에 잘 들어오는 모습이다. 그와 함께 TextSetThreadSafe 라는 메소드 이름만으로도 이것이 스레드 안전한 방식의 설정임을 알 수 있게 했다.

이 과정으로 알 수 있는 사실이 있다. 반복되는 조건문이나 복잡한 조건식 탓에 악취가 나는 코드는 메소드로 대체하는 정도만으로 깔끔해지는 경우가 많다는 점이다.

또 다른 예시로 표준중량과 측정중량을 가지고 판별하는 조건식을 가져왔다. 조금 얕지만, 마찬가지로 냄새가 나는 코드다.

허용 오차가 바뀌면 두 개의 하드코딩 값을 변경해 줘야 하는 귀찮은 코드다. 이 코드가 무슨 일을 하는지 역시 신경 써서 봐야 파악할 수 있다. 보기 쉽게 바꾸려면 이를 메소드로 대체하는 것으로 충분하다. 아래 메소드를 만들었다.

허용 오차 범위인지 아닌지 결과를 반환하는 메소드가 나왔다. 앞서 본 조건문을 이 메소드로 대체하고 하드코딩된 값도 상수로 관리하게 되었다. 곧 아래와 같이 의미가 명확한 조건문을 만들 수 있었다.

마치며

모든 예제 브랜치를 병합하고 정리한 코드는 refct_close 브랜치에 올려 두었다. 물론 필자의 작업이 마음에 안 들 수 있으며 그 외에도 리팩토링이 필요한 거리를 발견할 수도 있다. 이는 독자들의 몫으로 남기겠다.

만약 오래도록 리팩토링을 무시하면 어떤 일이 벌어질까? 우리가 본 엉망진창 코드가 레거시 코드가 되어 버리면 결국 리팩토링 부채에 빠지고 만다. 리팩토링 비용이 시간이 지날수록 비싸진다는 의미다. 먼 미래에는 차라리 새로운 코드를 만드는 게 나은 상황이 생긴다. 물론 언젠가는 이런 시기가 반드시 온다는 걸 부정하기 어렵다. 하지만 리팩토링은 이러한 시기를 늦출 수 있다.

이 글이 적어도 개발사에 있어 리팩토링을 장려할 기회가 되었길 바란다.

]]>

SI가 첫 회사인 개발자들에게

이번 편은 “SI 회사”에 취업하는 사회 초년생들을 위한 글입니다.

어떻게 일하고 어떻게 성장할 것이냐, 라는 고민에 도움이 되면 좋겠습니다.

<출처: 프리픽>

SI의 역할

개발자라면 누구나 당연히 SI 개발자로 시작했던 시절이 있었습니다. 1990년대 후반이었죠.

인터넷이 없고 전화선으로 통신을 하던 시절, IT 기반 서비스의 구매자는 “기업” 밖에 없었습니다. 접속 시간 자체가 다 비용이었거든요. 개발자 수가 적었기 때문에 대부분의 기업들은 아웃소싱할 수밖에 없었습니다.

시간이 흘러 인터넷 보급과 함께 컴퓨터가 빨라지면서 비즈니스도 빨라집니다. 기술환경이 복잡해지면서 전문 분야도 IT 컨설팅, IT 구축, IT 운영 등으로 나누어집니다. 고객 범위가 넓어지고 시스템이 커지면서 협업 환경도 복잡해지죠.

우당탕탕할 수밖에 없으니, 제일 먼저 나빠진 게 “프로젝트 현장”이었습니다. 당장 내일까지 맡은 일을 끝내야 하니 밤을 새울 수밖에 없었습니다. 반면, 희생과 노력은 보상받지 못했죠. 발주회사의 직원이 아니니까요.

SI 현장의 근로환경이 나빠지자 개발자들이 안 들어오기 시작했습니다. 반면 포털, 게임 등 B2C 시장이 성장하니 신입 개발자들이 모두 그쪽으로 취업을 했죠. 개발자들이 안 들어오자 2,000년대 들어 SI 현장은 악순환이 이어졌습니다.

2010년대, 노동근로 관점에서 여러 가지 문제들이 터지기 시작합니다. 정부가 나서면서 규제가 만들어지죠. 덕분에 노동환경이 많이 개선됩니다.

하지만, 프로젝트 진행 방식이나 내용이 달라지지는 않습니다. B2B 시장은 복잡한 기업들의 관계 속에서 돈을 벌고 있거든요. 프로세스가 깨지면 사업이 망합니다. 새로운 기술을 받아들이는 데는 시간이 걸립니다. 사업적 필요성을 인식하고 계획과 예산을 수립해야 하니까요.

2010년 아이폰이 출시되었을 때, 웹페이지는 전부 PC용이었습니다. 뉴스 기사를 확대해서 읽어야 했죠. 기업용 “모바일 페이지”는 2년 정도 지나서야 만들어지기 시작했습니다. 그 사이 기업들은 방향과 구현 수준을 정하기 위해 우왕좌왕했습니다. 웹과 앱, 두 세트로 관리하는 것도 부담이었거든요.

체감될 정도로 보급률이 확 바뀐 건 “반응형” 웹 기술이 퍼지면서부터였습니다. 2017년 이후였죠.

즉, 새로운 기술이 뜨더라도 이를 받아들여 보급하는 데 거의 7~8년이 걸린 겁니다. 점진적이고 느리죠. 일일이 필요한 곳을 찾아야 하니까요. 이때 기업 현장에 기술을 보급하는 역할은 누가 할까요? SI 입니다.

스타트업 개발자와 다른 점은?

자동차에 비유해 봅니다.

신모델 개발은 “R&D” 부서에서 합니다. 시장을 연구하고 새로운 기술을 개발하죠. 특허도 내고요.

자동차 생산은 “제작・생산” 부서에서 합니다. 원가, 프로세스, 공장설비 등을 생각하죠.

R&D가 핵심일 것 같죠? 그렇지만 제작・생산의 중요성도 절대 낮지 않습니다. 제품 원가의 중심이니까요. 사업이 잘되려면 모든 게 균형이 맞아야 합니다.

IT 업계에서는 어떨까요? 스타트업이 R&D라면, SI는 제작・생산의 역할을 맡고 있습니다. 설명을 위해 좀 더 또렷하게 대비해 봅니다.

뭔가 반대되는 느낌이 있습니다. 실제로도 그럴까요? 네, 그렇습니다.

보통 IT 개발의 시작은 “요구사항”입니다. 개발 계획과 항목을 확정 짓는 일이죠.

스타트업 개발자들은 이 “요구사항”을 스스로 만들어 냅니다. 우리 사업이니까요. 아이디어에서 개발 항목으로 이어지는 과정에 적극적으로 참여하죠. 알아서 하는 게 미덕입니다.

하지만, SI에선 알아서 일하면 사고입니다. 예를 들어, 금융 기업 프로젝트에 참여한 SI 개발자가 ATM 기능을 알아서 수정한다면 어떨까요? 해킹 시도로 오해받습니다. 작은 수정으로 큰 장애가 발생할 수도 있죠. 피해보상 범위가 엄청 넓을 수도 있습니다.

그래서 SI 개발자들은 “요구사항”이 없으면 일하지 않습니다. 요구사항은 책임자인 “업무 담당자”들이 만들죠. 책임과 권한의 경계선에서 분업을 하는 겁니다.

하지만, 스타트업에선 분업을 하면 망합니다. 아직 돈 버는 프로세스가 없으니까요. 일이 안 나눠지죠. 적당한 선에서 협업하며 우당탕탕해야 합니다.

SI 개발자와 스타트업 개발자가 다른 이유는 직업 환경 때문입니다. 익혀야 하는 경험과 노하우가 다르고 직장인으로서의 가치관도 다르죠. 성장 과정과 목표가 아예 다른 겁니다.

SI 개발자의 만렙은?

SI 만렙 개발자는 어떤 사람일까요?

돈은 많이 벌까요? 당연히 많이 법니다. 하지만 스타트업 같은 파격적인 대우는 없습니다. 아웃소싱 시장이 파격적이지 않거든요. 한 번 투자로 10배, 100배 버는 시장이 아닙니다. 파격적인 보상을 해줄 수가 없죠. 그냥 조금 더 높은 인건비를 주는 수준입니다.

누구나 아는 유명한 개발자가 있을까요?

글쎄요. SI 시장에선 유명세가 크게 도움이 되지 않습니다. 유명세는 미래에 대한 기대감을 높이기 위한 수단인데, 아웃소싱은 기대감보다 문제 해결에 대한 보상을 받는 분야니까요.

이건 아웃소싱이 일어나는 영역의 대부분이 “인프라”이기 때문입니다. 직접 돈 버는 부분들이 아니라 아웃소싱하는 거죠. 그래서 비용이 낮을수록 좋습니다.

SI에선 두루두루 하는 것보다, 한 분야의 전문가들이 대우를 받습니다. 깊이가 깊죠.

기업 인프라에는 복잡한 내용들이 오랜 시간 켜켜이 쌓여 있습니다. 벤더사조차 겪어보지 못한 문제들이 많죠.

TCP/IP 규격의 허점 때문에 오류가 일어날 수도 있습니다. 웹 개발 회사에선 겪어볼 일이 없는 오류죠. 그런 걸 건드려야 하는 인프라 시스템이니까 알게 되는 겁니다.

SI 만렙 개발자는 이런 문제를 해결해 주는 사람입니다. 인스타그램 같은 서비스 개발자와는 관점이 많이 다르죠.

즉, “만렙”이라는 정의도 직업 환경을 따라갑니다.

SI 개발자도 고수가 되면 돈을 많이 법니다. 불러주는 곳도 많고 일도 끊이지 않죠. 비교적 만렙이 되기 쉬운 환경입니다. 필요한 프로젝트를 따라 움직이면 되니까요.

예를 들어 주니어 개발자가 거대한 데이터를 보려면 대기업의 데이터팀 정도는 들어가야 합니다. 진입 문턱이 높죠. 반면 SI 라면 그런 프로젝트를 찾아가면 됩니다. 입사가 아니니 진입 문턱이 낮죠.

SI 만렙들은 부족한 기술 역량을 새로운 프로젝트를 찾아다니며 채웁니다. 한 프로젝트에서 모든 기술 역량을 다 채우기는 힘들거든요.

스킬업을 하지 않고 같은 일만 반복하는 개발자들도 있습니다. 성장보다는 생계 목적이죠. 그런 분들은 다른 곳에서 성장의 가치를 찾습니다. 모두 다 케바케입니다.

SI 개발자로 시작하기

SI 회사에 취업을 합니다. 뭐가 좋을까요? (비교적 나쁜 회사는 아니라고 가정합시다.)

# 상황 1

진입 문턱이 비교적 낮습니다. 시니어들이 어려운 일을 맡기 때문에 채용이 덜 까다롭습니다.

복잡한 실무코드를 볼 기회가 빨리 생깁니다. 당장 옛날 코드를 유지 보수해야 하니까요.

고수의 코드를 들여다볼 기회도 생깁니다. 노하우나 알고리즘은 변하지 않으니까요. 의외로 경외로운 코드가 많습니다. 생각보다 배우는 게 많습니다.

‘아, 저건 저렇게 처리하는구나.’

‘아, TCP/IP 통신을 이렇게 처리한 거구나.’

‘아, 저 로직은 네트워크 장비 문제의 방어 로직이구나’

등등을 말이죠. 다만 옛날 언어라 신규 개발에 참고할 만한 사례가 많지 않습니다.

좋은 코드를 본 적이 없다면 좋은 코드를 짜고 싶은 욕심이 안 생깁니다.

그런데 스타트업에선 훌륭한 선임이 없다면, 훌륭한 코드를 볼 일이 없죠. 시작 단계라 복잡성도 높지 않으니까요. 맨땅에서 헤매다 보면 별일 없이 1년이 후딱 가버립니다. 환상을 가지고 스타트업에 들어갔다 실망하는 초보자들이 많죠.

SI 현장에선 초보자도 좋은 코드 볼 기회가 비교적 쉽게 생깁니다. 계속해서 새로운 프로젝트를 하게 되고, 그만큼 많은 사람들을 만나게 되니까요.

물론 새로운 기능을 계속 덧바르거나, 사람이 바뀌면서 땜질하는 프로젝트라면 코드는 헬입니다.

같은 패키지를 오랫동안 계속 유지 보수하는 경우여야 코드 정리가 깔끔하게 잘 되어 있죠.

# 상황 2

SI는 주로 기업시장에서 일어납니다. 오래된 전통산업이니 비교적 잘 정리된 프로세스를 가지고 있죠. 그래서 비즈니스 이해, 업무 구조화 등이 선행됩니다. 우당탕탕 일하는 것보다는 짜임새가 있죠.

그러니 정리된 환경에서 일하는 걸 좋아한다면 SI도 나쁘지 않습니다. 어떤 분은 스타트업하다가 SI 현장에 오셨는데, 이렇게 이야기하더군요. “참, 세상 편해서 좋다”. 진짜로 편해서가 아니라, 업무 특성이 그만큼 다르다는 겁니다.

다만, 도전적인 기술 과제들이 없습니다. 프로젝트 기한이 있어서 어려운 건 솔루션으로 해결하죠. 연구개발이 좋고, 기술 성장 욕구가 높다면 SI 쪽이 맞지 않을 수도 있습니다.

그런데 요즘 대부분의 SI 회사는 자체 개발한 솔루션이나 패키지를 가지고 있습니다. 단순히 인력 파견만 하는 회사가 아니라면 괜찮을 수도 있죠.

SI 개발자로 성장하기

현장 프로젝트를 하면 다양한 기술적 호기심은 채울 수 있습니다. 별의별 문제가 다 생기거든요. 하지만, 기술 탐구 등 깊이 있는 호기심은 채울 수 없습니다. 탐구와 연구는 도전, 실패를 반복해야 하니까요. 아웃소싱 프로젝트는 대부분 “구축”이기 때문에 실패를 가정할 수 없죠.

그래서 프로젝트를 하다 보면 정체된 느낌이 납니다. 비슷비슷하니까요. 안주해 버리는 사람도 있는데 그러면 안 됩니다. SI 시장도 느리지만 변하거든요. 이에 맞춰 레벨업을 해줘야 합니다.

레벨업 한다는 건, 더 좋은 직장을 구하거나 더 높은 연봉을 받을 기회를 만드는 겁니다. 초보자에게는 꽤 중요한 과제이죠.

현장은 많은 경험치를 주기 때문에 중요한 레벨업 장소이긴 합니다. 하지만, 연구자로서의 경험치는 채울 수 없죠. 이걸 얻으려면 R&D 업무를 해야 합니다.

SI 회사에서도 연구개발을 합니다. 반복 업무는 솔루션이나 패키지로 만들죠. 로그 처리, 메시징 처리, 데이터 수집 처리 등등입니다. 그런 일을 해 보는 것도 좋습니다.

솔루션 기업이나 기술 스타트업으로 이직할 수도 있습니다. 블록체인, 암호화, 보안 솔루션 등 재미있는 분야들이 많습니다. 다만 초보자라면 선배가 있는 곳이 좋습니다. 길잡이가 있으면 언제나 좋으니까요.

“SI 개발자로만 성장하겠어.” 사실 이런 경우는 없습니다. 많은 개발자가 SI와 스타트업을 왔다 갔다 합니다. 그렇게 사는 게 좋다기보다 삶이 그렇게 풀리는 겁니다.

스타트업의 생존율도 30%(5년 차) 정도밖에 안 됩니다. SI 프로젝트 기간은 대부분 6~12개월이죠. 하나만 하고 살 수는 없습니다. 어떤 때는 프리랜서도 하고, 어떤 때는 스타트업에도 들어가게 되죠.

다만, 성장은 내적 동기가 없으면 일어나지 않습니다.

대부분의 회사는 정체되어 있거든요. 수익화 프로세스를 만들어 그걸 안정화시키죠. 그리고 프로세스를 잘 안 바꿉니다. 그래서 적응하고 나면 정체된 느낌이 들고 안주하게 됩니다. 내적 동기가 없으면 그냥 그렇게 흘러가며 살게 되죠.

그렇다고 조급해 하지는 않았으면 좋겠습니다. 성장하는 것도 그럴 기회를 만나야 하거든요. 물론 그런 기회가 항상 있지 않죠. 방향성이 중요합니다. 나의 성장 방향을 잡고, 관심 분야를 좁히고, 좋은 기회를 찾도록 노력하는 거죠.

크게 보면 “SI 개발자”라는 것도 고정관념입니다. 업무 환경에 따라 달라지는 것뿐이죠.

하지만, 스타트업에서 SI 개발자처럼 일하면 안 됩니다. 업무 환경이 다른데 옛날 방식으로 일하면 회사 일도 망하고, 자기도 도태되죠.

어떤 개발자가 되어야 하나?

내가 천재여서 슈퍼개발자가 될 수 있다? 그러면 좋겠지만, 대부분은 그렇지 못하죠.

기본이 중요합니다. 평생 개발자로서 일해야 하니 직업인으로서의 기본은 갖춰야 하죠. 마지노선이 있을까요? 네, 있습니다.

1. 개발을 할 수 있어야 한다

개발자의 기본은 소프트웨어를 만드는 능력입니다. 직업능력의 기본이죠.

코딩 실력만 말하지 않습니다. 컴퓨터의 동작 방식을 이해하고, 통제할 수 있는 능력을 말합니다.

‘개발’이란 어떤 동작을 하는 거대한 컴퓨터 시스템을 만들어내는 일입니다.

프로그래밍 언어는 도구일 뿐이죠. 그래서 컴퓨팅 환경에 따라 달라집니다.

예를 들어 로봇 개발과 인터넷 포털은 프로그래밍 언어가 다릅니다. 개발 방식도 다르죠.

로봇 분야에선 “지멘스(Siemens)”가 유명합니다. “S7-SCL”이라는 언어를 사용해서 구조화된 프로그래밍을 하죠. 오작동하면 생산라인이 중단될 수 있기 때문에 최대한 보수적으로 개발합니다.

미사일 및 항공우주 분야에서는 “ADA(에이다)”라는 언어를 사용합니다. 기계에 내장되기 때문에 메모리 점유율이 낮아야 합니다. 최적화가 아주 중요하죠. 그런 개발 문화를 가집니다.

반면, 인터넷 분야에선 메모리 점유율이나 성능은 거의 신경 쓰지 않습니다. 그냥 비싼 하드웨어를 사죠. 여러 작업을 동시에 진행하기 위한 협업 문화가 중요합니다.

일을 하다 보면, 산업 장벽을 넘어가거나 회색지대에서 일하는 경우가 생깁니다. 클라우드 같은 인프라 기술은 여기저기 걸쳐 있거든요. 개발자가 된다는 건 이런 환경에서도 일할 수 있다는 뜻입니다.

학위가 없더라도 기본 지식은 모자라진 않아야 하죠. 꾸준히 필요한 걸 찾아서 익혀야 합니다.

2. 엔지니어링도 익히세요

“개발”이 소프트웨어 제작을 말한다면, “엔지니어링”은 시스템 구축을 말합니다.

소프트웨어는 노트북에서만 동작하지 않죠. 클라우드뿐 아니라 스마트폰, 냉장고, 자동차에서도 동작해야 합니다. 수천 명이 동시 접속할 때는 여러 대의 컴퓨터가 한 대처럼 움직여야 하죠.

계획한 기능이 제대로 작동할 수 있도록 전체 그림을 그리고 구성하는 일이 필요합니다.

이런 일을 “엔지니어링”이라고 합니다. 소프트웨어뿐 아니라 하드웨어까지 알아야 하죠.

이건 학교에선 익히기 힘듭니다. 데이터를 포함해서 실습환경을 꾸미기 어렵거든요.

하지만, 엔지니어링을 할 수 있어야 개발 업무가 완성됩니다. 내 노트북에만 존재하는 소프트웨어로는 돈을 벌 수 없거든요. 이 기술은 현장을 가야만 익힐 수 있습니다. 소비자가 사용하는 그 환경은 그 프로젝트에서만 만날 수 있으니까요. 부지런히 현장을 찾아다녀야 성장하는 이유이기도 합니다.

대기업 갈 수 있을까?

그렇다면, SI 하다가 네이버 갈 수 있을까요? 갈 수 있습니다. 그렇게 가신 분들이 꽤 있습니다.

수능처럼 1년을 재수하면 될까요? 안 됩니다. 그렇게 뽑는 회사가 아니거든요.

하지만, SI가 아닌 스타트업에는 들어갈 수 있습니다. 이런 경우는 비교적 흔합니다. 진입 문턱이 높지 않으니까요. 그런 곳에서 내공을 쌓다가 네이버를 갑니다. 비교적 흔한 시나리오죠.

SI만 하다가 바로 네이버로 들어간 케이스는 거의 없습니다. 실력 문제라기보다 개발 문화 때문이죠. 위에서 말한 것처럼 대형 인터넷 회사들은 SI처럼 일하지 않거든요.

반면, 실력이 있음에도 안 가는 분들 역시 있습니다. 경력을 인정 안 해줄 때죠. 10년 차인데 7년 차 취급을 해주는 겁니다. 이럴 땐 가고 싶은 마음이 눈 녹듯이 사라지죠.

기업 입사는 대학교 입시가 아닙니다. 수능 점수처럼 동작하지 않죠. 경기가 어려울 땐 채용이 동결됩니다. 좋을 땐 쉽게 채용되기도 하죠. 회사의 목적은 “영리 추구”입니다. 이익이 되면 뽑고, 아니면 안 뽑죠. 상황은 때에 따라 바뀝니다.

다만, 개발자로선 항상 자기 몸값만큼 일할 수 있어야 합니다. 결국 실력이 된다는 전제하에서 주어지는 기회들이니까요.

써놓고 보니 그냥 평범하고 일반적인 이야기들처럼 되어버렸습니다.

하지만, SI 회사라고 첫발 내디디는 걸 막연히 두려워하지 않으면 좋겠습니다.

물론 피해야 할 SI 회사들도 있는데요. 이건 나중에 따로 한 번 정리하겠습니다.

]]>

스마트팩토리는 제조 현장을 어떻게 관리할까? (feat. POP)

“POP에서 문제가 생겨 라인이 멈췄는데….”

제조 현장에서 일하는 사람이라면 이런 말을 많이 들어봤을 것이다. 여기서 말하는 POP란 보통 “제조 현장을 관리하는 IT 시스템”을 의미한다.

그런 만큼 제조 현장의 IT 환경을 이해하려면 POP를 반드시 알아야 한다고 해도 과언이 아니다. 이번 글에서는 POP란 대체 무엇인지, 그리고 어떤 방식으로 제조 현장을 관리하는지 살펴보겠다.

<출처: 프리픽>

POP: ‘작업 행위’들을 관리하는 IT 시스템

POP란 생산포인트(Point of Production)에서 나온 말로, 풀어서 “생산시점관리”라고 말할 수도 있다. 일반적으로 단일한 시스템을 의미하기보다 다양한 시스템을 결합해 새로 구축한 시스템을 의미한다.

이때 “생산포인트”란 무엇일까? 지금부터 독자들의 이해를 돕기 위해 핸드폰 케이스 공장에 POP를 도입하려는 가상의 상황을 기준으로 설명해 보겠다.

공장 담당자, 즉 고객은 POP 도입의 첫 단계로, 스마트팩토리 개발 업체의 프로젝트 매니저(이하 PM)와 시스템 구축을 위한 회의를 진행한다. 그는 논의를 시작하기 위해 우선 핸드폰 케이스의 생산 공정을 PM에게 설명해 주었다.

핸드폰 케이스 생산 공정 예시 <출처: 작가>

공정을 파악한 PM은 이보다 더 자세한 관리포인트를 얻고 싶어 할 것이다. 이미지에 나열된 것은 공정의 개념일 뿐 구체적으로 파악할 수 없어 관리포인트를 얻기 어렵다. 실제 상황을 구체적으로 들여다보면 각 공정은 ‘작업 행위’들의 집합으로 이루어져 있을 것이다. 따라서 공정의 개념보다 실제 작업 행위를 가지고 논의를 시작해야 관리포인트를 얻기 수월해진다.

바로 그 구체적인 작업 행위들에 대응하는 개념이 ‘생산포인트’라 할 수 있다. PM은 생산포인트를 얻고자 좀 더 구체적인 작업 행위를 나열해 달라고 고객에게 요청한다. 이를 이해한 고객이 나열해 준 작업 행위는 아래와 같다.

행위 1: 작업자가 제품 모델을 선택
행위 2: 작업자가 모델에 맞는 금형 틀을 선택
행위 3: 작업자가 사출된 제품을 재단
행위 4: 작업자 또는 생산 설비가 프린트할 자료를 설비에서 선택
행위 5: 검사자가 검사
행위 6: 제품 포장

이처럼 작업 행위를 구체적으로 살피면 관리포인트를 추출할 수 있다. 곧 어떤 정보를 디지털화해 수집하는지, 그리고 상황별로 어떤 작업 주체(작업자 혹은 생산설비 등)를 제어할 것인지를 정할 수 있다. 이제 이런 결정은 IT 시스템으로 작업 행위를 관리하는 방법이 된다. POP는 바로 이 과정을 실현해 만든 체계다.

관리 포인트를 정의하는 방법

이제 이들 작업 행위에서 어떻게 관리포인트를 찾아내고, 그 방법을 IT 시스템에서 실현하는지 과정을 보도록 하자. 여기서도 핸드폰 케이스 공장의 예시를 기준으로 설명하려고 한다.

앞서 정리한 작업 행위를 화이트보드에 나열하고, 고객과 PM 두 사람은 관리포인트를 찾아내는 데 힘을 기울인다. 이때 우리는 소프트웨어 개발방법론의 도움을 얻어 이 과정을 헤쳐 나갈 수 있다. 고객의 요구사항을 정의하고 이를 유스케이스(Use case)로 정리해 보는 것이다.

1. 요구사항 정의

PM은 먼저 금형 사출 공정에 속하는 작업 행위를 기준으로 요구사항을 파악하기로 한다. 두 사람은 관련자들과 두루 논의하여 아래와 같이 요구사항들을 나열할 수 있었다.

작업자는 작업에 들어가기 전, 제품 모델을 선택해야 한다.
금형 틀이 설치되지 않으면 금형사출기는 가동할 수 없어야 한다.
설치한 금형 틀은 선택된 제품 모델(아이폰15프로, 갤럭시 S24 등)과 일치해야 한다.
투입하는 자재(실리콘, 폴리카보네이트 등)가 제품 모델에 대응하는 재질이어야 한다.
압착 작업 가동 전, 작업자가 안전하지 않은 위치에 있으면 설비는 가동을 중단해야 한다.
사출기의 제어시스템과 POP의 통신이 불가능한 상태가 되면, 작업자에게 상황을 인지시켜야 한다.

이 요구사항에는 전산만으로 해결하기 어려운 설비 기능 관련 내용도 포함되어 있다. 이런 경우에는 관련 업체를 회의에 참석시켜 협의를 진행하면 된다. 개발업체 입장에서 계약 이행 의무가 없는 요구사항이더라도, 그에 의존하는 기능이 많을 때는 유스케이스에 포함해 같이 얘기하는 편이 실무적으로 편리하다.

2. 작업에 대한 유스케이스

유스케이스는 다양한 작업 주체들의 행위가 어떻게 상호작용을 하는지에 대한 정의다. 이를 활용하면 고객의 요구사항이 시스템을 통해 어떻게 충족되는지를 직관적으로 보여줄 수 있다.

금형사출 공정의 유스케이스 예시 <출처: 작가>

POP는 외부시스템 인터페이스에 의존하는 경우가 많다. 또한 각 행위자의 관계와 절차를 명확하게 보여줘야 한다. 이런 특징 때문에 프로세스를 중심으로 풀어내는 것이 좋다. 이때는 IT를 모르는 고객과 현장 사람들, 설비와 인프라 담당자 모두가 설계 과정에 참여할 수 있도록 쉽게 표현해야 한다.

작업 행위를 관리하는 방법의 결정

유스케이스가 대략 결정되었다면, 이제 각 작업 행위를 관리할 디바이스를 결정해야 한다.

PM은 ‘제품 모델은 태블릿을 통해 프로그램상에서 선택한다’, ‘금형 틀 선택은 IT 시스템에서 관리하지 않는다’ 등 방식을 관련자들과 하나하나 협의해 간다. 이때, 앞서 만든 유스케이스처럼 도식화해 만들면 무슨 작업 행위가 어떤 디바이스에서 통합되는지 파악하기 쉽다.

어떤 디바이스로 무슨 행위를 관리할지 보여주는 이미지 예시 <출처: 작가>

디바이스와 방식까지 확정했다면, 구매가 필요한 하드웨어 목록을 고객에게 전달한다. 나아가 프로그램의 구체적인 화면 설계를 함께 확정하면 시스템 도입을 위한 설계 단계가 끝난다.

지금까지 우리가 만들어온 체계는 모두 작업 행위를 관리하는 데 그 목적이 있다. 제조 현장의 작업 행위들을 관리하는 이들 체계를 실제 동작하게 만든 IT 시스템, 이를 “POP”라고 할 수 있다.

POP 서버는 어디에 둘까?

이제 POP의 개념을 이해했다면, 몇 가지 주요 특징을 살펴보고자 한다. POP는 다양한 디바이스로 작업 행위들을 관리한다. 그렇다면 이런 디바이스를 중앙 서버에 연결할 것인지, 아니면 현장에 별도 POP 서버를 구축하고 연결할 것인지 검토해야 한다.

보통 공장 내 중앙 서버에는 비즈니스 시스템인 ERP(전사적자원관리), MES(제조실행관리) 등의 데이터베이스가 자리 잡고 있다. 이들 모두 공장 경영에 매우 중요한 가치가 있는 영역이다. 그 때문에 제조 현장에 맞게 여러 협력사가 가져온 디바이스를 이곳에 모두 연결하는 것은 권장하지 않는다. 서버의 스케일 업 부담이 높아지며 보안상 리스크도 증가할 것이다.

따라서 제조 현장에 별도 POP 서버를 따로 두어 디바이스를 연결하고 처리하는 형태가 주를 이룬다. 이 POP 서버만을 중앙 서버에 연결하는 것이다.

제조 현장의 네트워크 예시 <출처: 작가>

POP 서버는 중앙 서버보다 낮은 스펙으로 선택한다. 웹 서비스, 생산 설비를 인터페이스 하는 미들웨어, 디바이스용 프로그램 배포 서비스, 전광판 프로그램 등 제조 현장 운영에 필요한 IT 리소스들이 작동하는 데 무리가 없는 수준에서 서버 스펙이 결정된다. 이렇게 POP 서버를 따로 두는 편이 기업 입장에서는 훨씬 저렴해 경제적이다.

POP는 왜 온프레미스 환경이 대부분일까?

이처럼 POP는 대부분 현장에 서버를 두는 온프레미스 환경으로 구축한다. 클라우드 서비스가 보편화된 현재 IT 산업에도 불구하고 제조 현장의 IT 환경은 여전히 이를 유지하고 있다. 성능과 보안에서 단연코 효율적인 방안이기 때문이다. 이에 대해 알아보자.

1. 더 나은 성능

POP 서버는 디바이스에서 올라오는 데이터를 처리하는 다양한 서비스를 담고 있다. 제조 현장, 클라우드 환경에서 작동하는 서버를 서로 비교하며, 성능 문제에 대한 이해를 높여 보겠다.

첫 번째 차이는 데이터 이동 거리에서 생긴다. 내부 네트워크에서 데이터가 이동하는 것과 인터넷을 통해 바깥의 여러 라우트를 거쳐 데이터가 이동하는 것 중 무엇이 빠르겠는가? 내부 네트워크에서 처리하는 것이 훨씬 빠르다. 짧은 거리는 당연히 통신 성능에 영향을 미친다. (CDN, 즉 콘텐츠전송네트워크가 바로 그런 배경에서 등장했다.)

둘째는 평균 응답 대기 시간의 차이다. TCP 통신의 경우 인터넷에서 패킷이 유실될 가능성이 높아진다. 그와 동시에 패킷 유실로 인한 응답 대기 시간도 길어진다. 이는 곧 평균 응답 대기 시간을 높이는 결과로 이어질 것이다.

마지막은 비용 차이다. 제조 현장의 다비이스는 비교적 가치가 떨어지는 데이터, 상태 관리를 위한 통신 비트 등을 수시로 전송한다. 클라우드 서비스에서는 데이터 처리 용량이 곧 비용이다. 비교적 가치가 낮은 데이터의 비중이 높은 POP의 특성에 따라 이는 경제성이 무척 떨어지는 방식이 된다.

2. 보안을 위한 선택

POP에는 비즈니스 가치를 갖는 중요 정보(품질데이터, 자재소요정보 등)가 있다. 이 데이터가 인터넷 세상에 나가면 상당히 민감한 문제가 생긴다. 물론 클라우드 서비스도 HTTPS 암호화 프로토콜을 사용할 수 있지만, 그 암호화 자체가 성능 부담을 높이기 때문에 주의가 필요하다.

또한 인터넷에 제조 현장의 디바이스들이 연결된다는 건 그 자체로 치명적인 피해를 볼 가능성을 훨씬 높인다. 제조 현장의 디바이스에는 PDA, PC뿐 아니라 생산 설비 제어 장치들도 포함된다. 즉, 악의적인 공격자들에게 매우 효율 좋은 먹잇감이 된다는 뜻이다. 극단적으로, 당신이 공장장이라면 화학류 제어 장치를 인터넷에 연결할 수 있겠는가?

이런 문제의 근원은 퍼블릭 네트워크와 공장의 사설 네트워크가 연결되었기 때문이다. 기본적으로 내부 네트워크에서 처리하게 만들고 외부와의 연결을 통제하는 것이 값싸고 효율적인 방식이다. 물론 온프레미스 환경이 운영 관리에 대한 부담을 높이는 것은 사실이다. 하지만 보안 공격을 한 번이라도 당해본 공장이라면, 제조 현장 네트워크를 인터넷에 오픈하는 일을 결코 하지 않을 것이다. 운영 관리에 대한 부담을 운명으로 받아들이면서 말이다. 인터넷 세상은 참으로 무서운 곳이다.

마치며

POP를 구축하고 운영하는 일은 힘들다. POP는 다양한 시스템이 결합했으므로 복잡할 수밖에 없다. 그래서 이를 운영하고 유지보수하는 업무의 강도와 부담이 높은 편이다. 수많은 제조 현장의 소프트웨어가 레거시 시스템이라는 점도 문제다. 이런 점 때문에 커리어 관리에 신경 쓰는 개발자는 POP를 꺼리기도 한다.

하지만 이런 환경에 적응해 경험을 쌓은 운영 담당자, 그리고 개발자는 대부분 대체 불가능한 인력이 된다. 그렇기에 이런 인력을 구하려는 개발업체들의 경쟁도 상당히 심한 편이다. 무엇보다 일은 고되고 힘들지만 보람도 크다. 시스템이 10년이고 20년이고 문제없이 잘 돌아가는 걸 목격하다 보면 큰 보람을 얻을 수 있다.

이번 글이 제조 현장의 POP를 이해하고 그들의 중요성을 공감하는 데 도움이 되었기를 바란다.

]]>

수행업체는 우리 스타트업의 생존에 관심 없다

지난 글 “IT 아웃소싱을 잘 관리하는 3가지 방법”에서는 제법 큰 프로젝트들 이야기를 했습니다.

작은 프로젝트 이야기를 안 할 수 없습니다. 이번 글은 작은 “갑”들을 위한 조언입니다. 스타트업을 준비하는 사람들이죠.

스타트업 대표님은 어떻게 외주 개발을 시작할까?

미용실에 가면 쿠폰에 도장을 찍어줍니다. 10개 모으면 1번 공짜.

대부분의 미용실은 그렇게 하고 있습니다.

예비 창업자 A 씨는 이 도장 시스템을 스마트폰 앱으로 만들고 싶습니다.

아마 가게 사장님도 편하고, 손님도 편해질 겁니다.

도장을 찍다 보면 예약도 붙일 수 있고요. 결제를 붙이면 수수료도 얻을 수 있겠죠.

인기 있는 미용실을 추천하고 광고를 붙일 수도 있습니다.

미용실 이용 후기를 붙여 경쟁이 되게끔 해야겠네요.

얼마나 벌까요?

전국에 미용실만 11만 5천 개가 있습니다. 월 1,000원씩만 벌 수 있어도, 월 1.15억 원, 연 11.5억 원의 수익을 올릴 수 있죠.

시스템만 갖추면 미용실뿐 아니라 동네 커피숍에도 진출할 수 있겠네요.

동네 카페는 7.5만 개가 조금 넘는다고 합니다. 월 7,500만 원의 수익을 올릴 수 있겠군요.

이리저리 노력하면 연 매출 20억 원을 찍을 수 있을 것 같습니다.

이 정도면 시작해볼 수 있겠군요.

A 씨는 강한 믿음이 생겼습니다. 그리곤 스타트업을 시작합니다.

하지만 A 씨는 미용사 자격증을 준비했을 뿐, 개발 관련 지식이나 경험은 전혀 없습니다.

아직 젊다 보니 초기 투자금도 없습니다. 겨우 정책자금을 지원받아 개발은 외주에 맡기기로 합니다.

미용실 쿠폰 앱 예시 이미지 <출처: 프리픽>

약간 부자연스러운 부분이 있지만, 꽤 흔하게 볼 수 있는 창업스토리입니다. 아직 돈이 없으니 개발자 채용을 할 수는 없는 거죠.

스타트업이 외주 개발하다 만나는 흔한 상황

A 씨는 여러 개의 외주플랫폼을 통해 프로젝트 공고를 올립니다. 개발기간은 3개월.

여러 기업이 입찰에 참가합니다. 직접 참가 업체를 만나보기도 합니다. 적절한 업체를 선정합니다.

자, 이제 프로젝트를 시작합니다. 그리곤 여러 가지 문제들에 부닥치죠.

가장 먼저 부닥치는 문제.

A 씨는 외주사 PM이 무슨 말을 하는지 모르겠습니다.

알아듣지 못할 기술 용어를 막 늘어놓고는 결정해달라고 합니다.

무슨 말인지 잘 모르겠지만 그래도 대표니까 설명을 잘 듣고 “저렇게 하자”를 결정해 줍니다.

그런데 얼마 지나지 않아 다시 찾아옵니다. 이번엔 다른 안건입니다.

또 막 알아듣지 못할 기술 용어를 막 늘어놓습니다. 그리곤 결정해달라고 합니다. 이번에는 “이렇게 하자”를 결정해 줍니다.

끝났을까요? 아닙니다. 또 얼마 지나니 않아 찾아옵니다.

자꾸 찾아와서 뭔가를 묻고 결정해달라고 합니다. 이런 상황이 몇 번 더 반복됩니다.

그렇게 프로젝트 기간이 두 달이 지나고 세 달째.

프로젝트가 어떻게 진행되어 가는지 아직 아무런 이야기가 없습니다. 전화를 받지도 않습니다. 어찌 통화가 되어서 “얼마나 되었냐?”고 물어보면, “다 끝나가는데 이것저것 조금 남았다”라고 이야기합니다. 믿고 조금 더 기다려 봅니다.

세 달이 넘어가고 네 달이 넘어가고, 다섯 달이 다 되어갑니다. 전화로 다 끝났다는 게 벌써 두 달째입니다. 통화도 안 되길래 돈을 못 주겠다고 문자를 보내 버렸습니다. 수행업체가 화를 냅니다. 늦어진 이유가 A 대표 때문이라고 이야기를 합니다. 그러곤 우르르쾅쾅 복잡한 일들이 일어납니다.

생각보다 이런 사례를 자주 봅니다. 그런데 이 정도까지 왔다면 수습이 거의 불가능합니다. 감정의 골이 깊어져서 이성적인 대화가 안 됩니다. 수습하려고 동분서주 하다 보면 일이 더 꼬여버립니다.

무엇이 문제일까?

수행업체는 우리 사업에 대해 관심이 없다

창업가 A 씨는 정말 오랜 시간 이 사업에 대해 정말 많은 생각을 했습니다.

생길 수 있는 모든 가능성을 고민하고 나름대로 대책을 세웠습니다. 성공에 꽤 절박한 상태이기도 합니다. 그래서 이 사업에 대한 이해도와 정보가 만렙입니다.

하지만, 수행업체는 이 사업에 대한 정보가 하나도 없습니다. 관심도 없습니다. 미래에 어떻게 될지 아예 생각하지 않습니다. A 씨와 사업을 같이 하는 게 아니니까요.

그런데 프로젝트를 하면 갈림길이 너무 많습니다. 어떤 선택을 하냐에 따라 결과가 천양지차로 달라지죠. SI 업체는 “선택”을 할 수 없습니다. 사업자가 아니니까요.

광고 기능을 예로 들어 봅시다.

연간 미용실 창업률은 8.2%입니다. 2019년 상반기에만 6,000여 개의 점포가 문을 열었습니다. 당연히 신규 미용실 사장님들은 우리 앱에 광고 기능이 있는지 알리 없습니다. 반면 연간 폐업률*은 6.2% 정도 됩니다. 연간 5,000개 이상의 점포가 문을 닫는다는 뜻입니다. 우리 앱을 잘 쓰시던 사장님이 저기 어딘가로 사라지는 겁니다.

※ 창, 폐업률은 2019년 기준으로 매년 등락이 달라질 수 있습니다.

가만히 있으면 광고주가 점점 줄어드는 구조입니다. 막 창업한 미용사들이 우리 앱을 알 리 없습니다. 다양한 광고・홍보 기능을 구현해야 하죠. 그런데 수행업체가 이런 걸 알 리 없습니다. 당연히 알아서 개발해 줄 수도 없습니다.

즉, 창업자 A 씨는 수행업체가 알아서 개발해 주기를 바라면 안 됩니다.

SI 업체는 사업 주체가 아닙니다. 비슷한 시스템을 구축해 본 기술, 경험이 있어도, “결정”을 할 수 없습니다. 알아서 개발할 확률은 제로입니다. A 씨의 기대와는 뭐가 달라도 다르고, 뭐가 모자라도 모자랍니다.

기술언어와 사업가의 언어가 다르다.

사업언어는 기술언어와 다릅니다. 그런데 SI 업체는 기술언어로 묻습니다. 반면 A 씨는 사업언어로 답을 합니다. 반대의 경우도 같습니다. A 씨는 사업언어로 묻습니다. SI 업체는 기술언어로 답합니다. 프로젝트가 잘 될 리 없습니다.

수행업체의 PM이 사업언어에 대한 이해가 많다면 비교적 낫습니다. 하지만, 대부분의 경우는 그렇지 않습니다.

창업자 A 씨 “우리 가게 오는 손님들을 회원으로 관리하고 싶어요.”
수행업체 “그럼 회원가입 기능을 넣어드릴게요.”

결과물:

주민번호입력 실명인증 해야 함. 전화번호 인증이나 이메일 인증을 해야 함.
회원 ID를 생성해야 함. 중복ID 체크하고, 암호까지 입력해야 함. 특수문자 체크도 함.
주소지 입력도 해야 함.

손님들 “귀찮아서 안 할래요.”
창업자 A 씨 “아, 회원 관리 하지 말자. 그러면 포인트 적립이 안 되네? 에이, 포인트 적립도 하지 말자.”

⇒ 결국 다시 종이에 도장 찍는 걸로 회귀

불과 5~6년 전, 아주 흔하게 보는 상황이었습니다. 결국 A 씨의 앱을 쓰는 미용실이 점점 줄어들고, 사업은 오리무중이 됩니다.

그런데, 이런 구현은 기술적으로는 정말 맞는 방법입니다. 2006년 인터넷 실명제 이후, 회원 관리에 실명인증을 넣는 건 당연시되었습니다. 이걸 안 하면 신고당하기도 했죠.

그리고 결국 마케팅 때문에 고객 주소, 직업 정보를 수집하게 됩니다. 기술적으로 입력 정보 두어 개 더 넣어주는 게 어렵진 않습니다. SI 기업은 정말 잘해주려고 이런 걸 개발해서 넣은 거죠.

하지만, 사업적으로는 틀린 방법입니다.

고객들이 귀찮아할 걸 예상했어야 합니다. 인터넷 서비스를 하는 기업들은 고객들이 귀찮아하지 않도록 회원가입 시 입력 정보를 최대한 줄여줍니다. 가입 절차도 한 번의 클릭으로 끝나도록 하죠.

이런 걸 사업에 관심이 없는 SI 업체가 알 리 없습니다.

결국 잘해준다고 한 일이 사업을 망하게 하는 지름길로 이끈 거죠.

참고로, 위 상황 때문에 간편가입이라는 게 생깁니다.

창업자 A 씨 “우리 가게 오는 손님들을 회원으로 관리하고 싶어요.”
수행업체 “그럼 회원가입 기능을 넣어드릴게요.”

결과물 :

카카오톡 간편가입을 넣음. 또는 전화번호만 입력하면 됨
처음이면 자동으로 가입되고, 1회 이상이면 적립되도록 함. 고객이 신경 쓸 건 없음.

손님들 “별로 수고도 안 드는데 적립하고 가자.”

물론 간편가입이 만능열쇠는 아닙니다. 입력되는 정보는 카카오톡 가상 ID밖에 없습니다. 개인정보는 아무것도 가지고 있지 않죠.

그래서 카카오채널로만 메시지를 보낼 수 있습니다. 다른 마케팅 활동을 하기 힘들죠.

회원가입은 쉬워진 만큼 마케팅 수단이 제약을 받은 겁니다.

요즘 간편가입이 붙는 사이트들이 부쩍 늘었습니다.

기술적으로 “소셜 로그인”이 진화했기 때문입니다. 기술적 언어와 사업적 언어가 가까워진 결과죠. 하지만, 옛날에는 위쪽 케이스가 흔했습니다.

즉, 프로젝트가 잘 되려면 기술언어와 사업언어를 아는 사람이 중간에 있어야 합니다.

꼭 베테랑일 필요는 없습니다. 하지만 소통에 열린 사람이어야 하죠. 모르는 말이라고 해서 필요 없는 말은 아니니까요. 돈이 아쉬운 스타트업이라면 “창업자”가 이 역할을 해야 합니다.

생각보다 단순한 이 사실을 몰라서 많은 프로젝트가 망가집니다. 왜냐하면 “아웃소싱을 하기 위해 무엇을 어떻게 준비해야 하는지”에 대해서는 아무도 알려주지 않기 때문입니다.

어떻게 해야 할까?

그러면, 이런 문제는 어떻게 해결해야 할까요?

가장 일반적인 방법이 프로젝트 산출물을 챙기는 겁니다.

참고 글: 아웃소싱 전문가가 밝히는 요구사항 정의서 작성법

그런데 산출물이 생각과는 꽤 다릅니다. 진행 과정에서 산출물은 그냥 문서일 뿐이니까요. 목표 결과물과 계약사항을 정하기 위해 필요하긴 하지만, 제대로 진행되고 있는지는 알 길이 없습니다. 현실적으로 별다른 준비 없이 아웃소싱을 해버리면 거의 필패라고 봐야 합니다. 그래서 어떻게 준비해야 할지, 알아두면 좋을 4가지를 정리해 보았습니다.

<출처: 프리픽>

무슨 일이 일어나는지 알자

아웃소싱 발주 전 가장 먼저 해야 할 일이 있습니다.

“아웃소싱을 하면 어떤 일이 일어나는지” 정보를 찾아서 듣는 겁니다.

유튜브도 좋고, 정부 강의도 좋고, 일반 강의도 좋습니다. 돈만 준다고 일이 알아서 되진 않습니다.

엄청나게 많은 돈을 준다면 몰라도 말이죠. A 씨는 모든 것이 부족합니다. 이럴 땐 몸으로 직접 뛰어야 합니다.

중요한 건 “이론”을 아는 게 아닙니다. “경험과 사례”를 들어야 합니다. 자격증 따려는 게 아니니까요. 가능하면 나와 비슷한 상황을 찾아서 듣습니다. 그리고 그 강사를 조언자로 활용합니다.

프로젝트에서 상황은 복합적으로 일어납니다. 사람과의 갈등, 외부 환경 등도 등장합니다. 이론만 알아서는 대응할 수 없죠.

보는 것이 믿는 것

Seeing is Believing.

이것 하나만 기억합니다. 볼 수 없다면 아직 아무것도 안 된 겁니다.

디자인이 끝났다면 디자인을 볼 수 있어야 하고, 코딩이 끝났다면 코드를 볼 수 있어야 합니다. 개발이 끝났다면 동작하는 무언가를 볼 수 있어야 합니다.

수행업체를 못 믿어서가 아닙니다. 나(창업자 A)를 못 믿어서 그런 겁니다.

결과물은 보여줘야 하고 볼 수 있어야 합니다. 문서만 가지고 파악하면 안 됩니다. 화면이나 코드를 보여 달라고 하세요. 눈으로 확인할 수 있는 게 없다면, 끝났을 때 결과물이 다를 확률이 매우 높습니다.

결과물을 제때 확인하려면 프로젝트 초기, 일정 계획 세울 때 수행업체랑 같이 세우세요.

이때 뭔가를 볼 수 있도록 마일스톤을 잡아달라고 하세요. 작동하든 하지 않든, 반만 만들었든 아니든 보여달라고 하세요. 일정은 지연되거나 뒤바뀔 수 있습니다. 하지만, 만들어진 게 없으면 아무것도 진행되지 않은 겁니다.

예를 들어, 미용실 쿠폰 앱이라면 이런 것들을 중간에 체크해야 합니다.

(1) 앱 디자인

(2) 화면 작동 여부

(3) 데이터 연동 여부

(4) 가입부터 사용까지 시나리오별 작동 여부

(5) 관리자 페이지 사용 요령

인터넷 서비스란 기술적으로는 “기능을 통해서 데이터를 화면에 뿌려주는” 겁니다.

기능을 통해서 규칙과 통제를 만들어 내고, 화면을 통해서 사람이랑 대화하죠.

그래서 가장 먼저 앱 디자인부터 볼 수 있어야 합니다. 만일 앱 디자인이 없다면 화면 코딩을 할 수 없죠. 화면 코딩을 할 수 없다면, 서버 기능도 미완성인 상태고요. 데이터 흐름까지 완성할 수 없습니다. 데이터 흐름이 곧 비즈니스인데 말이죠.

그런데 앱 디자인을 볼 수 없다는 건, 아직 서비스 시나리오가 결정되지 않았다는 뜻이기도 합니다.

기획자가 다음 페이지에 이게 올지, 저게 올지를 결정하지 못한 거죠. 이건 수행업체의 문제가 아닙니다. A 씨가 아직 마음의 결정을 못한 거죠. 이해는 됩니다. 처음 하는 사업이니까요.

하지만, 프로젝트 기간의 30%나 지나가는데 이런 상황이라면 아주 심각한 겁니다.

수행업체의 목소리만 들어서는 모릅니다. 업체가 핑계 대는 것처럼 들리니까요.

직접 겪어야 비로소 알게 됩니다. 저거 안 챙기면 망하겠다는 생각이 들죠.

예를 들어 “직권 취소”라는 기능도 있습니다. 고객 대응 프로세스가 엉킬 때 강제로 풀어주는 기능이죠. 이런 건 사업 흐름에 맞춰 전체 기능을 체크하다 보면 비로소 알게 됩니다. 실제로 그런 일이 생기니까요.

화면을 보다 보면 초기 데이터가 부족하다는 것도 알게 됩니다.

다 창업자 A 씨가 준비해야 할 것들입니다.

프로젝트가 막히는 가장 흔한 이유이자, 제일 먼저 풀어야 할 숙제는 “창업자 A 씨”가 해야 할 일을 빠뜨리지 않는 겁니다.

처음 하는 사업이고, 어떤 일이 벌어질지는 나도 모르고 수행업체도 모릅니다.

당연히 빠뜨리는 게 있을 수밖에 없습니다. 그러니 자꾸 보면서 해야 할 일들을 체크해야 합니다.

“보는 것이 믿는 것”

이 말은 수행업체뿐만 아니라 나 자신부터 믿지 말라는 뜻입니다.

납기일은 생명

간혹 발주자들이 “납기일”(프로젝트 종료일)을 중요하게 생각하지 않을 때가 있습니다.

일정에 여유가 있다고 생각하거나 잔금을 치를 때까진 괜찮다고 생각하는 거죠.

반면, 모든 SI 업체는 “납기일은 생명”으로 생각합니다.

아웃소싱 사업은 시간을 파는 사업이니까요. 이상적으로는 개발자 B 씨가 “A1” 프로젝트를 8월 30일에 끝내고, “A2” 프로젝트를 9월 1일부터 하는 게 이들이 바라는 상황입니다.

즉, SI 업체들은 “납기일” 전에 모든 일을 끝내고 싶어 합니다. “갑”을 들들 볶을 수밖에 없죠.

발주자 A 씨: “잔금”을 치르는 게 프로젝트 끝. 일 끝내는 건 내 책임 아님.
SI 수행업체: “납기일” 내 일을 끝내는 게 프로젝트 끝. 물론 돈을 받아야 함.

이 두 가지 생각 차이가 분쟁을 만들어 냅니다. 아주 흔하고 오래된 전통적인 갈등입니다.

잘 끝나는 케이스가 있습니다. A 씨가 이렇게 생각하는 겁니다.

발주자 A 씨: 일정 내에 일을 끝내야 함. 그래야 그다음 일을 착수할 수가 있음.

이러면 거의 높은 확률로 일이 잘 끝납니다. 일정 내에 끝내려는 노력이 생각보다 중요합니다.

수행업체의 문제

“발주자가 다 챙겼는데도 수행업체 쪽에서 진전이 없다.”

당연히 이런 경우도 있습니다. 수행업체 쪽에 문제가 생긴 겁니다. 일을 여러 개 하고 있는데 우리 일의 우선순위가 밀렸던지, 함께 하던 개발자가 퇴사를 한 겁니다. 당연히 일의 공백이 생깁니다.

발주자가 어떻게 할 수 없는 부분입니다. 하지만 제때 상황을 공유받아야 합니다. 그래야 “갑”도 대응책을 준비할 수 있으니까요. 수습이 잘 되면 좋겠지만 아닐 수도 있습니다.

공식적으로는 PM에게 해결을 요청해야 합니다. 프로젝트 진행을 정상화시켜 달라고 말해야 합니다. 안 챙기면 유야무야 넘어가기도 합니다.

생각보다 이런 상황이 자주 일어납니다. 좋은 SI 업체도 많지만 그렇지 않은 경우도 많기 때문입니다. 이런 경우가 생기면 대부분 납기일 이후에나 분쟁을 다툴 수 있습니다. “갑”에게도 엄청난 손해입니다. 돈보다 중요한 “일정”을 손해 보게 되니까요. 법적 분쟁은 규모가 작은 “갑”에게도 매우 어려운 시련입니다.

하지만, 현재로선 중간에 조치할 수 있는 방법이 거의 없습니다. 계약을 파기한다 하더라도 명분이 없거나, 그동안 잘못한 걸 서로 물고 뜯기로 한다면, 시스템 구축은 저 멀리 사라지고 법적 분쟁만 남기 때문입니다.

그래서 입찰 단계에서 신중을 기해 업체를 선정해야 합니다.

마치며

이미 수작업으로 돌아가는 사업기능 일부를 외주로 자동화하는 건 성공 확률이 매우 높습니다.

만들어야 할 목표 결과물이 뚜렷하니까요. 불확정성이 낮으니 프로젝트 난이도도 낮습니다.

아직 검증되지 않은 신사업 아이디어를 외주로 만드는 건 매우 어렵죠. 발주자조차도 모르는 일들이 대부분이니까요. 그게 목표 결과물이라면 시작부터 불가능한 겁니다. 모르는 걸 만들어야 한다니.

그런데 생각보다 후자 케이스가 SI 프로젝트로 많이 나옵니다. 그래서 무시할 수도 없죠.

다만 이 경우는 SI 업체에게 모든 걸 일임하는 식으로 만들면 안 됩니다. 100% 실패합니다.

이런 아웃소싱만 잘 해주는 “전문 외주 스타트업”이 있다면 고맙겠지만, 현재 시장에선 거의 보기 힘듭니다.

어떤 경우이는 “갑”이 챙기는 만큼 프로젝트가 간다는 걸 기억하면 좋겠습니다.

]]>

왜 제조업의 데이터 분석은 어려울까?

최근 제조업에서는 전산 시스템 수가 늘어나며 데이터 역시 복잡해지고 있다. 그에 맞춰 제조업 분야 고객의 데이터 분석 의뢰도 그만큼 많아졌다. 이런 관점에서 IT 제조실행시스템인 MES(Manufacturing Execution System)와 데이터에 대한 최적화된 설명이 필요하다는 생각이 들었다. 따라서 이 글에서는 MES의 기본 설명과 함께 데이터 분석 관점에서 주의할 사항에 대한 설명을 다룰 예정이다.

MES의 4가지 핵심 기능

우선 MES의 일반적인 주요 기능을 알아보겠다. 미국 제조업 시스템 단체 MESA(Manufacturing Enterprise Solutions Association International)에서는 MES의 11가지 기능을 제시한다. 이 대표 설명 중 몇 가지 핵심 기능을 간추리면, 크게 작업 스케줄링, 제품 추적성, 품질 관리, 공정 라우팅 4가지를 꼽을 수 있을 것이다. 이제 각 기능을 간략하게 설명해 보려고 한다.

작업 스케줄링

작업 스케줄링이란 생산을 위해 필요한 자원을 어떻게 투입할지 스케줄링하는 것이다. 육하원칙에 기반해 생산에 투입되는 모든 자원의 스케줄을 관리한다고 볼 수 있다. 대표적인 예시는 아래와 같다.

누가? 생산반 A팀이
언제? 주간 근무에 투입되어
어디서? B 생산라인에서
무엇을? C 제품 100개를
어떻게? 작업표준서에 맞게 작업하여 생산한다
왜? 고객의 주문에 맞추기 위하여

설명은 간단해 보이지만 관련한 마스터 정보의 종류가 다양하고 수도 많다. 생산반, 근무조, 근무시간, 생산라인, 작업표준, 생산계획, 비가동계획, 휴무일관리 등 다양한 마스터 정보들이 갖춰져야 이들 정보를 결합하여 생산 지시를 만들 수 있다. 그런 만큼 사실상 작업 스케줄링은 MES의 코어이자 전부라고 해도 과언이 아니다.

제품 추적성

생산 과정을 거쳐 완제품이 만들어지는 과정은 어떨까? 제품의 생산 과정 내내 다양한 자원들이 투입되어 이들이 결국 완제품으로 탈바꿈한다. 이러한 과정을 추적할 수 있다면, 즉 제품 추적성을 구현하면 완제품에서부터 역으로 과정을 추적하거나 반대로 자재에서 완제품으로 전개할 수 있다. 어디서 문제가 생겼고 어떻게 작업한 것인지 추적할 수 있다는 뜻이다.

또한 회계적 관점에서 보면 제품 추적성은 원가 계산을 할 수 있는 충분조건이기도 하다. 다시 말해 완제품 제작에 투입한 모든 요소, 혹은 생산 과정에서 손실되는 요소를 추적할 수 있다면, 이 요소들의 가격을 기반으로 원가를 계산할 수 있다.

완제품을 만들기 위해 투입되거나 손실되는 자원들의 예시 <출처: 작가>

MES는 완제품 하나하나에 들어간 자원 정보들을 모두 추적한다. 그 때문에 ERP와 같은 자원 관리 시스템이 이 정보를 참고하게 된다. 물론 MES는 제조실행 관리 시스템으로 회계 시스템과 상관이 없으므로 회계 관련 마스터 정보도 가지고 있지 않다. 따라서 일반적으로 완제품이 만들어지면 자재 소요량이나 완제품 재고량을 ERP에 보고하는 식으로 해당 시스템이 정보를 참고할 수 있게 해준다.

품질 관리

MES에서 품질 관리란 크게 품질검사항목마스터, 품질검사이력으로 나뉜다. 마스터는 합격기준값인 최소값과 최대값을 공정별, 품목별로 관리하는 것이다. 품질검사이력은 품질검사작업을 실시한 이력이라고 보면 된다.

MES의 하위 시스템으로 볼 수 있는 SPC(통계적 공정 관리, Statistical Process Control)는 품질 관리에 맞게 전문화된 시스템이다. 이때는 품질에 대한 간접 요인들인 공정 효율성, 수율, 공정능력 등을 평가하고 관리한다고 생각해도 좋다. 다만 SPC의 계산값들은 미리 저장된 것이 아니라 조회가 일어날 때마다 생산이력 데이터에 접근하여 그때그때 계산한 것이 보통이다. 그러니 데이터를 얻으려면 직접 시스템에 들어가 취하는 편이 낫다.

공정 라우팅

제조업 공장에 존재하는 생산라인들은 대체로 모듈화를 지향한다. 그 때문에 A 라인에 있던 설비를 B 라인으로 옮기는 것도 가능하다. 이럴 경우 현업에서는 MES 상에서 공정 라우팅 마스터를 조정해 주는 액션으로도 가동할 수 있는 상태가 된다.

품목별 공정 흐름 정의 <출처: 작가>

또한 라우팅은 공장 자동화의 필수적인 마스터 정보이다. 어떤 분기하는 포인트 x가 있다고 가정해 보겠다. 이 포인트의 분기는 a 제품을 생산하는 A 생산라인과 b 제품을 생산하는 B 생산라인 모두와 연결되어 있다. 만약 a 제품이 x 포인트에 도착하여 고정식 바코드 스캐너에 인식되면, 시스템은 이 제품을 어디로 보낼 것인지 판단하여 설비에 알려준다. 공정 라우팅 기능의 대표적인 활용 예다. 다시 말해 이 기능은 공정과 공정의 네트워크를 품목별로 관리할 수 있게 만들어준다.

가장 많이 의뢰하는 분석 데이터, 품질 데이터

제조업 분야에서 들어오는 데이터 분석 의뢰의 대부분은 품질 데이터 분석이다. 이 데이터를 분석하려다 보면 고객의 MES 내부를 들여다보며 품질 데이터 구조를 익혀야 하는 일이 발생한다. 이를 위해 MES에서 품질 정보를 어떻게 디지털로 구조화하는지, 품질 데이터의 특징과 함께 살펴볼까 한다.

검사항목마스터

검사의 종류를 관리하는 마스터 정보이다. 비전 검사, 저항값 측정, 절연 검사, 전압 검사 등의 검사 마스터를 관리한다. 여기서 눈여겨봐야 할 것은 검사 항목과 연관된 설비 혹은 공정들이 무엇인지에 대한 정보다. 대부분 검사 항목이란 설비 혹은 공정의 속성으로 관리된다. 그러니 설비 혹은 공정 마스터 테이블과 조인하면 관계를 파악하기에 어렵지 않을 것이다.

설비정보마스터

앞서 제조업의 공정은 모듈화 되어있다고 언급한 바 있다. 여기서 일부 독자는 ‘공정’이라는 개념과 ‘설비’라는 개념이 각각 독립적이라는 것을 눈치챘을 수도 있다. 공정은 개념의 문제일 뿐이다. 복잡해 봐야 바닥에 테이핑하고 줄을 쳐놓은 것에 불과하다. 하지만 설비는 실제 하드웨어다.

a 설비는 A 라인에서 B 라인으로 이동하거나 다른 지역 공장으로 이설될 수도 있다. 하지만 이설이 되더라도 그 설비는 여전히 a 설비여야 한다. a 설비의 보전 정보(내구재 부품 교체일 등) 역시 유지되는 구조다.

그 외로 최근에는 검사 설비가 최종 공정뿐만 아니라 공정 중간에 배치되는 경우도 흔하다. 예컨대 도금 공정이 끝난 다음 비전 검사 설비가 배치되거나 PCB 제작 후 온도 검사가 배치되는 식이다. 따라서 모든 검사 데이터가 마지막 제품 포장 전에 이루어질 것이라 단순하게 생각하면 안 된다. 공정 라우팅 정보를 참고하여 미리 구조를 파악해 두는 것이 좋다.

검사결과이력

검사결과이력은 결국 품질의 관점에서 분석할 대상이 된다. 그 때문에 마스터 정보와 조인하여 이 검사 이력이 기준 요건을 충족하는지, 혹은 어떤 공정에서 처리된 것인지 파악할 수 있다.

품질 검사란 품질 관련 조직의 공정 단위인 ‘로트’ 하나가 완공되었을 때, 무작위 샘플링으로 이 제품이 품질 요건을 충족하는지 통계적으로 조사하는 것만을 의미하지 않는다.

최근 품질의 중요성이 부각되면서 품질 검사를 하나의 공정으로 두고 모든 제품이 이를 통과하며 전수조사하는 방식도 많아졌다. 이런 환경 변화로 품질 관련 데이터가 방대해졌고, 그에 따라 분석 의뢰가 자주 발생하게 되었다. 따라서 보통 의뢰된 품질 데이터는 샘플링된 데이터가 아니라 전수 조사된 데이터일 확률이 높다.

분석 모델링을 방해하는 MES의 3가지 특성

이러한 품질 데이터는 분석 모델링 과정을 거쳐 분석한다. 분석 모델링이란 데이터에 분석 기법을 적용해 패턴을 파악하고 인사이트를 얻는 방법을 말한다.

하지만 MES의 몇 가지 특성은 이러한 분석 과정을 방해해 결과의 신뢰성을 떨어뜨리는 요인이 된다. 제조업 데이터 분석 모델링에서 특히 주의할 사항을 정리해 보았다.

데이터는 가공될 수 있다

MES는 생산 공정을 디지털로 추상화한 것으로 온전히 실세계를 재현해 낸 건 아니다. 그 때문에 데이터를 그대로 처리하지 않고 가공하는 일이 벌어지기도 한다. 적절한 처리 방법에 따라 관리하는 프로세스로 이를 처리하는 것이 바람직하지만 시스템이 소화하지 못하는 경우도 존재한다. 이때 문제가 벌어진다. 데이터를 가공하는 경우를 알아본 다음 문제 케이스를 다루겠다.

관리 중인 데이터의 가공

라인을 구축한 지 얼마 안 되었다면, 합불 판정의 기준값을 자주 수정하기도 한다. 최적화 때문일 수도 있고 품질 강화 목적일 수도 있다. 이런 이유로 MES는 판정이 내려진 시점의 기준값을 이력에 함께 저장한다. 수정이나 점검이 필요할 때는 이를 참고하여 변경 값을 추적할 수 있다. 마스터에 있는 기준값은 “현재 기준”의 기준값이라는 점에 주의할 필요가 있다.

문제 케이스: 관리되지 못한 데이터의 가공

개발 업체는 안정화 단계에서 발견된 예외 처리를 시스템에 녹여내도록 최선을 다한다. 하지만 때로는 감당하기 어려운 비용이 드는 예외도 발생한다. 이런 경우 개발 업체는 고객에게 2가지 대안, 돈이 드는 방법과 들지 않는 방법을 제시하고 선택하도록 한다. 대개 고객은 안정화 단계에서 한 번 큰돈을 지불한 상황이어서 추가 비용 지출을 꺼린다. 그래서 보통 이런 문제가 생기면 케이스 코드나 하드 코딩으로 대응한다. 시간과 돈은 유한하니 고객이 돈을 지불하지 않는다면 개발 업체도 품이 덜 드는 쪽을 택하는 것이다.

이때 문제가 되는 가공이란 품질값 등을 일반적인 수정이 아닌 특정한 규칙으로 재수정하는 경우를 말한다. 이는 사람이 할 수도 있고 설비나 시스템이 할 수도 있다.

예컨대 어떤 설비에서 점검용 표준 품의 무게가 미달해 NG(No Good)를 내야 하는 상황이 발생했다고 하자. 그러나 물리적인 변경에 예산이 많이 드는 상황이라면 일단 데이터를 수정하는 방법을 생각해 볼 수 있다. 이런 오류는 보통 사람의 실수에 조직적 실수 등이 결합해 나타난다. 소프트웨어의 변경은 물리적인 변경보다 값이 싸 공짜나 마찬가지이므로 이런 수정이 자주 일어난다. 작업한 사람들은 이를 모두 인지하고 있어 괜찮을지 모르지만 문제는 시스템이다. 시스템은 이러한 사정을 알지 못하기 때문에 데이터가 오염되고 만다.

이런 상황은 데이터 분석 기법을 적용할 때 치명적인 문제를 야기한다. Y=a+bX라는 모델의 추정을 위해 준비된 데이터 Y와 X가 있다고 하자. 이때 하필 Y가 가공함수 g(X)가 포함된 오염 데이터라면 어떨까? 그렇다면 실제로는 Y=a+bX+g(X)로 계산한 값이 나온다. 따라서 파라미터 a, b의 추정이 잘못될 가능성이 높다.

어느 정도 잘못된 추정이 나올지 통계 프로그램 R을 활용해 확인해 보았다. 먼저 Y=a+bX+e인 회귀식을 정의하고(e는 오차항이다), 결과 데이터 Y와 입력 데이터 X만으로 파라미터의 추정치 a*, b*를 얻도록 코딩했다.

결과는 a*=10.080271, b*=0.839159로 실제 a(=10), b(=0.84)에 가깝게 추정되었다.

이제 여기 일부 데이터가 오염된 상황을 가정해 X가 2 이하일 때만 2를 더해주는 가공함수 g(X)를 추가해 보았다.

결과는 a*=10.310130, b*=0.835730으로 실제와 더 멀어졌다. 두 파라미터의 표준오차 역시 기존 결과보다 증가했다. 데이터가 상당히 많았는데도 소량의 잘못된 데이터가 결과를 오염시켰다.

이는 마치 인공지능 학습에서 수가 적더라도 “깨끗한 데이터”를 사용하는 것과 같은 맥락이다. 예컨대 메타(Meta)는 LLaMA 학습에 위키 백과와 대중 서적들을 사용했지만, 더욱 방대한 페이스북 데이터는 사용하지 않았다. 이는 한국에서 개발된 AI 챗봇 ‘이루다’의 실패 요인과 비교해 볼 수도 있다. 초기 이루다는 오염된 카카오톡 데이터를 학습해 문제가 발생했고, 이에 개인정보와 필터링에 큰 비용을 치러야 했다. 이처럼 최근 들어 엔지니어들은 깨끗한 데이터로 잘 훈련된 인공지능을 목적에 맞게 파인튜닝하는 편이 훨씬 비용이 적게 든다는 걸 깨우치고 있다.

제조업 데이터 분석에서도 상황은 같다. 분석 모델링의 목적은 데이터에서 인사이트를 얻어내는 것이다. 만약 추정의 오류로 잘못된 비즈니스 결정을 내린다면, 이는 상당히 곤란한 문제를 야기할 것이다. 따라서 분석 결과의 표준 오차가 너무 크게 나온다면 가공 케이스가 있는지 담당자를 통해 조사해야 한다. 곧 이 조사 결과를 반영해 데이터를 적절하게 전처리하는 것이 현명하다.

자동화 설비 데이터의 “저장 시간”은 어디서 오는가?

MES 사용자들은 설비에서 올라온 데이터의 “저장 일시”를 그 액션이 일어난 시간이라고 생각하는 경향이 있다. 하지만 실제 이는 ‘데이터가 데이터베이스에 저장된 일시’인 경우가 대부분이다. 미들웨어와 통합된 MES를 사용한다면 적어도 “데이터수집일시”에 대한 정보는 보여줄 때가 있다. 이 차이는 데이터가 어떤 과정을 거쳐 MES의 데이터베이스에 저장되는지 보면 더 명확해진다.

설비 데이터가 MES 데이터베이스에 저장되는 과정 <출처: 작가>

MES를 다른 시스템과 구별해 주는 특성은 바로 미들웨어와 현장 단말기가 통합된 환경이라는 데 있다. 그런 만큼 MES 데이터를 다룰 때 항상 이 점을 주의해야 한다.

물론 데이터가 각 시스템을 거치며 발생하는 시간 차이는 미세한 편이다. 분 단위, 시간 단위로 데이터를 전처리한다면 매우 사소한 문제가 될 것이다. 하지만 분석 단위가 섬세해야 하는 경우도 있다. 예컨대 초 혹은 밀리초 단위로 설비의 특정 동작 a와 특정 동작 b의 로그를 분석해야 하는 경우라면 얘기가 달라진다. MES는 보통 설비에서 전달받거나 미들웨어 단계에서 수집한 시간을 보존해 데이터베이스에 전달한다. 이런 세밀한 시간 정보에 관심을 가져야 한다면, 실질적인 수집일시 정보를 MES가 관리하고 있는지 운영자나 개발 업체에 문의해야 한다.

간과하지 말아야 할 설비 간 ‘시간 동기화’

저장 시간 관련 우리가 간과할 수 있는 문제가 하나 더 있다. 바로 각 설비와 서비스들 사이 시간이 동기화되어 있다는 전제 아래에서만 이 데이터가 의미 있다는 사실이다.

다양한 설비와 장비 그리고 서버들의 시간을 동기화해주는 환경이 구축되어 있지 않다면 올려 받은 일시 정보는 가치 없는 데이터가 된다. 이런 상황을 대비해 각 설비 업체와 시간 동기화를 위한 서버를 하나 정하기도 한다. 매일, 매시간 시점을 정해 신호를 주면 다 같이 동기화를 하자고 프로토콜을 정하는 것이다.

따라서 일시 정보를 얻기 위해 데이터를 조인해야 할 때는 이를 주의해야 한다. 동기화가 이루어지지 않은 상태라면 초 단위 이하 섬세한 분석은 가치 없는 분석이 될 것이다.

마치며

지금까지 데이터 분석 업무 관점에 최적화해 MES의 특징을 살펴보았다. 분석 업무 시에 무엇을 주의해야 하는지 역시 설명했다. 앞으로 제조업 분야의 데이터를 다뤄 더 좋은 품질의 분석 결과를 만들어야 할 때, 이 글이 약간이라도 도움이 되었기를 바란다.

]]>

쇼핑몰도 ‘맞춤 개발’ 하는 이유

온라인 쇼핑몰 플랫폼 “고도몰” 영업, 개발, 파트너 담당자 인터뷰

여러분은 물건을 어디에서 사시나요? 특별한 경우가 아니라면 가장 먼저 찾는 곳은 바로 인터넷일 겁니다. 지난해 온라인 쇼핑몰에서는 210조 원어치 물건이 팔렸습니다. 물건을 사는 사람도 파는 사람도, 누구나 온라인을 찾는다는 이야기입니다.

그런 만큼 인터넷에는 아주 다양한 쇼핑몰이 존재합니다. 이런 쇼핑몰은 누가, 어떻게 만들까요? 세 가지 방법이 일반적입니다. 직접 사내 개발팀을 두고 만들거나, SI 기업에 큰돈을 주고 맡기거나, 온라인 쇼핑몰 구축 플랫폼을 찾거나. 그중 온라인 쇼핑몰 구축 플랫폼은 우리 입맛대로 커스텀한 쇼핑몰을 만들고 싶지만 개발팀을 꾸리거나 SI 기업에 맡기기 어려운 고객에게 최고의 선택지입니다. 특히, 개발자가 따로 없어 구축과 유지보수에 부담을 느끼는 중소기업들이 플랫폼을 찾습니다. 편리한 기능을 제공하며 리소스를 관리해 주는데 비용은 크지 않거든요.

다만 이토록 치열한 시장에서 살아남으려면 커스터마이징은 선택이 아닌 필수입니다. 우리 브랜드에 딱 맞는 특별한 기능을 개발해야 하죠. 그러다 보니 플랫폼 솔루션을 기반으로 고객이 요구하는 기능을 구축해 주는 또 다른 개발 생태계가 꾸려졌습니다. 이 생태계는 온라인 쇼핑몰의 성장과 함께 몸집을 불리고 있죠.

이 시장에서는 어떤 일이 벌어지고 있을까요? 입맛대로 쇼핑몰을 만들려는 고객을 위해 프론트뿐만 아니라 DB와 백엔드 커스터마이징을 지원하는 플랫폼, “고도몰” 생태계의 사람들을 만나 보았습니다. 요즘 개발 트렌드부터 새로운 구현 방법까지, 온라인 쇼핑몰 개발 시장의 이야기를 들어보겠습니다.

요즘 온라인 쇼핑몰 트렌드: “쇼핑몰 자체 구축 왜 하나요?”

NHN 커머스 EC영업팀 엔터프라이즈파트 윤성준 파트장

윤성준 파트장이 이끄는 엔터프라이즈 파트는 규모가 큰 기업의 자사몰 구축 프로젝트를 담당합니다. 프로젝트 컨설팅부터 에이전시 협업과 오픈까지 모든 과정을 지원하죠. 온라인 쇼핑몰 구축의 A to Z를 모두 아는 그에게 요즘 온라인 쇼핑몰 개발 시장의 트렌드와 이슈를 들어봤습니다.

NHN 커머스 EC영업팀 엔터프라이즈파트 윤성준 파트장

Q. 요즘 이커머스 시장에서는 자체 쇼핑몰 구축, 즉 자사몰 개발이 많아지고 있어요. 그 이유는 뭘까요?

쇼핑몰을 운영하는 분들, 즉 고객이 똑똑해졌기 때문입니다. 이들 모두 처음에는 쿠팡, 스마트 스토어 등 오픈 마켓에 입점해요. 빠르게 물건을 팔 수 있으니까요. 하지만 규모가 커지면 상황이 달라집니다. 그 브랜드가 “회원”을 가지고 있느냐, 없느냐가 중요해집니다. 자사몰은 내 회원을 가질 수 있는 도구이고요. 이제는 온라인 쇼핑몰을 운영하는 고객 모두 회원 확보가 핵심이라는 것을 깨달았어요. 그래서 똑똑해졌다고 표현했죠.

물론 단순히 자사몰을 회원 확보 목적으로만 구축하는 것은 아니에요. 오픈 마켓에서 상품을 구매하는 소비자는 이 물건이 어떤 브랜드인지 중요하지 않아요. 그러다 보니 쉽게 대체할 수 있는 상품이 나오며 가격 경쟁을 피할 수 없죠. 장기적으로 브랜드를 운영하기 위해서는 우리 브랜드만의 공간인 자사몰이 필수예요. 또 플랫폼에 입점하게 되면 입점 수수료, 판매 수수료 등이 발생해요. 매출이 늘어날수록 수수료 부담은 커지죠. 최근 '티메프 사건' 역시 자사몰 전환을 가속하는 계기가 될 겁니다. 정산은 생존의 문제니까요. 자사몰을 이용하면 PG사로부터 직접 정산을 받기 때문에 기다릴 필요가 없어요.

Q. 자사몰을 개발하는 방법은 여럿 있는데요. 그중 쇼핑몰 개발 플랫폼을 사용하면 무엇이 좋을까요?

요즘 고객 미팅에 나가면 저는 이렇게 말해요. “언제까지 SI 하실 거냐?” 라고요. 사람들은 플랫폼에서 쇼핑몰을 구축하면 기능 제약이 많을 거라고 생각해요. 그래서 SI 기업과 함께 자체 개발을 시도하죠. 그 과정에서 고객들 대부분이 어려움을 겪어요. 개발 과정도 힘들지만, 유지보수는 더 어렵거든요. 운영하며 데이터가 쌓이면 서버가 느려지니 확장해야 해요. 개인 정보를 지키기 위한 보안 업데이트도 주기적으로 필요하죠. 빠르게 바뀌는 쇼핑몰 트렌드에 맞추려면 신규 기능도 개발해야 합니다.

하지만 쇼핑몰 구축 플랫폼에서는 이런 문제를 해결할 수 있어요. 특히 고도몰은 백엔드와 DB까지 “커스터마이징”할 수 있는 것이 특징인데요. 이미 제공 중인 서비스를 연동하거나 새로운 기능을 직접 개발해 관리자 페이지에 붙이는 것이 모두 가능해요. 서버와 같은 리소스도 원하면 쉽게 추가하고요. 자체 구축 대비 저렴하고 빠르게, 브랜드에서 원하는 기능을 맞춤형으로 개발할 수 있다는 뜻이죠.

Q. 요즘 이커머스에서 튜닝이 중요한 이유는 무엇인가요?

쇼핑몰마다 원하는 것이 다 다르기 때문이에요. 예를 들어 볼까요? 상품을 등록할 때, 첨부 파일을 함께 올리고 싶은 고객이 있다고 할게요. 이 기능은 원래 자주 쓰지 않는 기능이 맞아요. 플랫폼에서 이미 상품 상세 페이지를 워낙 잘 구축해 두었기 때문이죠. 다만 이 고객이 다루는 상품은 아주 특수해서 품질 인증 관련 파일을 함께 등록해 신뢰도를 올리고 싶을 수 있어요. 그러면 새로운 기능을 추가하는 것이 맞습니다. 다만 이는 드러난 프론트엔드 부분이 아닌 백엔드의 구조를 건드려야 풀 수 있는 문제예요. 그래서 고도몰처럼 백엔드 구조 자체를 맞춤형으로 세팅해야만 해결할 수 있죠. 정해진 구조 안에서만 동작하는 다른 플랫폼은 구현이 힘들어요. 그렇다고 플랫폼을 쓰지 않고 처음부터 만들자니 비용이 큰 데다 앞서 얘기한 문제가 끊이지 않고요.

고도몰과 함께하는 다양한 브랜드 <출처: NHN 커머스>

Q. 요즘 쇼핑몰을 운영하는 고객이 자주 찾는 기능은 무엇일까요? 쇼핑몰 개발의 트렌드가 있을까요?

구독 서비스 요청이 정말 많이 들어온다고 느껴요. 그런데 사실 이 구독이 아예 새로운 기능은 아니에요. 정기 결제 시스템이랑 다를 바 없죠. 정기적으로 고객이 돈을 낼 때마다 물건을 배송해 드리면 구독 서비스라고 합니다. 이렇게 정기 결제 시스템처럼 자주 찾는 네이버페이, 간편로그인, 채널톡 연동 같은 기능은 개발 없이도 “스토어”에서 쉽게 추가할 수 있어요. 휴대폰에서 어플을 설치하듯 원하는 기능을 쇼핑몰 관리자 페이지에 쉽게 설치하는 거죠.

대신 요즘에는 특별한 구독, 프리미엄 구독 서비스에 대한 요구가 많아요. 이는 정기 결제 시스템과 회원 등급 제도를 결합해 풀 수 있어요. 비싼 돈을 주고 새로 개발할 기능은 아니죠. 플랫폼에서 원래 제공하는 정기 결제 시스템에 회원 데이터베이스를 튜닝해 붙이면 해결할 수 있어요.

Q. 그렇다면 쇼핑몰 개발 플랫폼을 찾아온 사람은 어떤 여정으로 자사몰을 얻게 될까요?

고도몰을 찾아온 고객을 기준으로 설명할게요. 가장 먼저 하는 건 고객의 이야기를 듣는 일이에요. 어떤 것을 원하고 무엇이 필요한지 확인하죠. 다음으로는 원하는 방식을 구현할 우리 플랫폼의 특정 기능이나 커스터마이징 범위를 안내해요. 이후에는 고객사에게 적합한 에이전시를 선정하기 위해 리스트를 전달해요. 레퍼런스와 구축 기간, 비용 등을 고려해 함께할 개발사를 결정하면, 프로젝트가 착수됩니다. 프로젝트를 시작하면 기획, 디자인, 개발, 배포를 순서대로 진행하죠.

프로젝트의 시작부터 끝까지, 쉽게 말해 고객이 자사몰을 만들어 운영할 준비가 될 때까지 회사에서 따라가요. 이를 ‘해드림 서비스’라고 이름 붙여 운영하고 있어요. 해드림 서비스를 이용하면 고객사는 개발자 없이도 쇼핑몰을 구축할 수 있는 거죠. 개발에는 고도몰에서 인증한 에이전시가 참여합니다. 고도몰에서는 에이전시를 꼼꼼하게 관리하며 더 높은 품질을 얻도록 지원하고 있어요.

NHN 커머스 해드림 서비스 <출처: NHN 커머스>

Q. 실제 고객과 만나 개발하는 웹 에이전시를 위해 NHN 커머스에서는 무엇을 지원하고 있나요?

저희는 ‘온보딩’ 전략을 운영하고 있는데요. 쉽게 말하면 파트너로 함께하고자 하는 에이전시의 기술 레벨을 측정하고 이를 연결에 활용하는 겁니다. 파트너가 개발을 잘하는지, 디자인을 잘하는지, 튜닝을 잘하는지, 내부에서 파악한 내용에 따라 적합한 고객과 연결하고 있죠. 이때 에이전시의 기술 레벨이 높다면 수수료 혜택을 드리고요.

소통 과정에서 문제가 생기면 NHN 커머스 측에서 중재에 나서기도 합니다. 그뿐만 아니라 저희 튜닝 센터를 활용하면 에이전시가 튜닝한 기능들을 아예 패키지로 묶어 판매할 수도 있어요. 추가 개발 없이 소득을 얻을 방법이죠. 자격 제한은 없습니다. 개발자라면 누구나 고도몰의 파트너가 될 수 있어요.

▶ 해드림 파트너 지원하기

영업부터 유지보수까지: 플랫폼과 에이전시는 어떻게 공존할까?

고도몰 파트너사 카이먼 노은영 실장

플랫폼의 솔루션이 실제 쇼핑몰로 바뀌려면 에이전시 생태계가 필수입니다. 이들 개발사는 현장에서 고객과 소통하며 결과물을 만들어 내고 있죠. 고도몰 파트너사 카이먼의 노은영 실장으로부터 생생한 현장의 이야기를 들어보았습니다.

고도몰 파트너사 카이먼 노은영 실장

Q. 쇼핑몰 구축 플랫폼은 생각보다 다양하게 존재하는데요. 카이먼처럼 한 가지 플랫폼을 전문으로 취급하면 어떤 장점이 있나요?

물론 저희도 고객 요구에 따라 다른 플랫폼을 쓰기도 해요. 어디서는 되는 것이 어디서는 안 되기도 하니까요. 그렇지만 한 가지 플랫폼을 전문으로 다루면 따라오는 혜택들이 있어요.

예를 들어 고도몰의 경우에는 NHN커머스에서 일정 부분 영업을 지원해줘요. 해드림 서비스 과정에서 자연스레 고객과 연결해 주죠. 모니터링과 함께 고객사 측 컨택 포인트를 직접 연결해 주니 소통이 정말 원활해요.

또 영업 팀이 아닌 유지보수 담당자와 직접 컨택할 수 있는 것도 정말 큰 장점이에요. 대형 쇼핑몰은 사이트에 오류가 나면 매출 타격이 굉장히 큰데요. 대부분 플랫폼은 문제가 생겼을 때, 일반 문의만 넣을 수 있어요. 그러면 얼마나 기다려야 할지 모르거든요. 만약 2~3시간 지나 응답이 오면 피해 규모가 얼마나 커질지 알 수도 없고요. 응급 대응이 필요한 상황에 곧바로 담당자와 연결할 수 있으니 좋아요.

Q. 고도몰을 전문으로 다루며 느낀 이 플랫폼의 장점은 무엇일까요?

가장 큰 장점은 튜닝이죠. 다른 곳에서는 따라잡기 힘들어요. 직접 DB를 열고 볼 수 있다는 것은 정말 큰 부분이죠. 단순 기능 개발뿐만 아니라 고객사에서 마케팅 목적으로 주문 통계 같은 정보를 봐야 할 때가 있거든요. 이를테면 가입한 지 3일 내에 첫 구매를 한 유형의 고객들이 자주 사는 품목이 궁금할 수 있잖아요? 이런 건 DB를 열어야 볼 수 있어요. 다른 플랫폼에서는 API를 연동해 받아올 수 있다고 하지만, 실제 데이터를 추출할 때 고객이 원하는 조건으로 추출하기 어려운 경우가 많거든요.

또한, 고도몰의 정기적인 보안 패치 역시 장점이에요. 자사몰은 회원의 개인정보를 보관하기 때문에 유사시에 해킹 등 공격이 들어올 수 있어요. 잦은 패치로 고객이 따로 서버 보안을 신경 쓰지 않도록 관리해 주니 편하죠.

Q. 요즘 이커머스 고객은 어떤 기능을 추가하려고 하나요? 개발 사례가 궁금해요.

브랜드마다 요구하는 기능들이 달라서 딱 한 가지를 뽑기는 어려울 것 같아요. 다만 업종별로 자주 찾는 기능들을 몇 가지 소개해 볼게요.

패션/잡화 브랜드의 경우에는 옵션 커스터마이징을 세세하게 하는 편이에요. 쇼핑몰에서 보여지는 이미지가 중요하기 때문에, 컬러나 사이즈를 직관적으로 보여 주는 것이 중요하죠. 예를 들어 검은색을 누르면 검은색 상품, 흰색을 누르면 흰색 상품 이미지가 썸네일에 노출되는 거예요.

식품의 경우에는 배송 기능을 많이 활용하는데요. 배송 일정이나 시간을 지정하거나 가까운 매장에서 바로 배송할 수 있게 만든 기능이에요. 이런 경우에는 프론트뿐만 아니라 배송 쪽 백엔드도 함께 개발해야 해요.

Q. 백엔드 커스터마이징, 그러니까 튜닝으로 맞춤형 기능을 개발한 사례도 있나요?

카이먼에서 대상의 ‘정원e샵’ 브랜드 통합몰을 구축했는데요. 임직원 기능을 구현하기 위해 그룹웨어의 로그인 세션과 쇼핑몰의 로그인 세션을 물려서 연결해야 했어요. 그룹웨어에 로그인한 상태에서 사이트 이동을 클릭하면 로그인 상태 그대로 이동할 수 있도록요. SSO 통신 프로토콜을 이용해 해결했죠. 여기에 임직원 포인트를 쓸 수 있게 튜닝을 한다거나, 상품권을 사서 포인트로 바꿔 쓴다거나 하는 기능도 구현했습니다.

BYC몰의 경우에는 개인 맞춤형 추천 기능을 만들었어요. 비마이핏이라는 기능이었는데요, 고객이 선택한 결과에 따라 본인에게 맞는 상품을 보여주는 거죠. 성별, 사이즈, 선호 유형 등에 따라 상품을 바로 추천해요. 또 내부 ERP 시스템과 연동해 현재 재고의 품목, 규격 등을 확인해서 보여주기도 하고요. 이런 로직을 짜고 구현하려면 백엔드를 건드리지 않고는 어려워요.

BYC 쇼핑몰의 비마이핏 기능 <출처: BYC 쇼핑몰>

Q. 에이전시에게 맞춤 제작이 중요한 이유는 무엇일까요?

고객은 정말 다 다르니까요. 저희는 맞춤형 제작 업체여서 고객들이 필요하다 하는 기능을 웬만하면 다 만들거든요. 식품, 패션 등 각각 분야에 따라 새로운 기능을 만들고 있죠. 아무래도 고도몰 전문 업체인 만큼, 원하는 데이터를 열어보고 반영하면서도 보안 취약점으로부터 안전하게 구현할 수 있도록 신경 쓰고 있어요.

쇼핑몰 구축 플랫폼의 3가지 키워드: 확장성과 유연성, 안정성

NHN 커머스 고도몰개발/공통플랫폼개발팀 이한진 팀장

이한진 팀장이 이끄는 고도몰개발/공통플랫폼개발팀은 온라인 쇼핑몰을 만들고 운영하기 위해 필요한 모든 환경을 만들어 냅니다. 고도몰은 “튜닝”을 강조하는 만큼 신경 써 개발할 부분이 많다고 하는데요. 그에게서 쇼핑몰 플랫폼의 개발 환경과 다가올 변화에 대한 이야기를 들어봤습니다.

NHN 커머스 고도몰개발/공통플랫폼개발팀 이한진 팀장

Q. 쇼핑몰 구축 플랫폼에 문제가 발생하면 모든 고객사에 손해가 발생해요. 이를 어떻게 대비하고 있나요?

우선 클라우드 기반 인프라로 서버 자원을 탄력적으로 확장할 수 있게 운영하고 있습니다. 트래픽이 급증하는 상황에서도 시스템을 안정적으로 운영하도록 아키텍처를 설계했어요. 데이터 백업과 복구 계획, 최신 보안 위협에 대한 정기 업데이트도 신경 쓰고요. 무엇보다 관련 지표를 실시간으로 모니터링하며 잠재적인 문제를 조기에 발견할 수 있는 내부 시스템을 가동하고 있어요. 문제가 생기면 곧바로 개발팀에 알림이 가죠. 장애를 사전에 탐지하고 즉각 대응하기 위한 지원이에요.

그럼에도 늘 아찔한 상황은 있습니다. 여러 경우의 수를 생각하여 테스트 케이스를 만들어 대응하려고 하지만, 미처 발견하지 못한 에러 제보가 나오면 등에 식은땀이 흘러요. 그래서 더 현장에 밀접한 에이전시 분들과 소통하는 자리를 자주 마련하려 하고 있어요. 고객이 실제로 시스템을 사용하며 겪는 문제를 많이 듣기 위해서죠. 고객에게 문제가 생기면 이에 빠르게 대응하는 것을 언제나 높은 우선순위로 가져갑니다.

Q. 자유로운 튜닝 환경을 보장하기 위해 다양한 변수를 고려한 폭 넓고 섬세한 설계가 필요해 보이는데요. 어떤 가치를 중심으로 개발하고 있나요?

시작 단계부터 확장성을 깊이 고민합니다. 설계를 할 때면 사람들이 가장 흔하게 쓰는 디자인 패턴이 무엇인지 고려해요. 최대한 많이 쓰는 디자인 패턴이나 아키텍처 패턴을 활용하려고 하죠. 복잡한 최신 패턴의 구현은 자제하고 있습니다. 특히 고도몰은 MVC 패턴* 설계를 고수해요. 튜닝을 하려면 코드를 봐야 하는데요, 이를 더 쉽게 이해하고 수정할 수 있어야 하니까요.

한편으로는 모든 사용자와 개발자의 경험을 쉽게 만들려고 합니다. 기획 단계에서는 화면 구성을 확장성 있게, 디자인에서는 편안한 UX를 만들려고 신경 쓰죠.

*MVC 패턴: 가장 널리 쓰이는 디자인 패턴의 하나로, 애플리케이션의 각 요소를 모델(Model)-뷰(View)-컨트롤러(Controller) 역할에 맞게 구분하여 개발하는 형태입니다. 유지보수의 편의성과 확장성을 높이는 데 유리합니다.

Q. 최근 고도몰을 완전한 SaaS형 플랫폼으로 바꾸는 등 큰 업데이트가 있었어요. 어떤 변화가 있었나요?

이번 대규모 업데이트에서 가장 도전적인 과제는 PHP 최신 버전 업그레이드였습니다. 최신 버전은 이전 버전보다 더 빠르고 효율적이에요. 낮은 버전의 PHP를 사용하면 보안 취약점이나 성능 저하 같은 문제가 발생하기 일쑤죠. 장기적으로는 EOL(End of Life, 제품의 라이프사이클 종료) 문제도 있었고요. 이에 미리 대비하고자 대규모 업데이트를 진행했습니다. 데이터베이스나 메시지 큐(MQ) 같은 미들웨어 오픈소스도 EOL 이슈에 대응하기 위해 가능한 최신버전을 제공하기 위해 많은 준비를 했어요.

기존의 고도몰5는 APM(Apache + PHP + MySQL) 구조로 심플하게 구성되어 있었다고 한다면, 최근 고도몰 아키텍처는 상당히 많은 부분이 개선되거나 발전했어요. 대규모 환경에서 안정적이고 빠른 서비스를 제공하기 위해 여러 도구와 오픈 소스를 많이 도입했죠. 예를 들어, 기존 고도몰은 캐싱을 위해 레디스(Redis)를 간소하게 쓰고 있었어요. 하지만 이를 확대해 레디스 기반 글로벌 캐싱을 크게 늘리고, 더 많은 트래픽을 수용하기 위해 멤캐시드(Memcached)를 이용한 로컬 캐시도 도입했습니다. 또 CI/CD, 모니터링, 로깅, 워크플로우 시스템 등 부분에서 많은 개선을 진행했어요. 차차 고도몰 고객과 에이전시 파트너 여러분에게 이런 개선이 어떤 영향을 미치는지 자세하게 설명하는 콘텐츠를 많이 제공해 드리려고 합니다.

고도몰 시스템 아키텍처 <출처: NHN 커머스>

Q. 확장성 있는 플랫폼을 유지하려면 클라우드 환경이 중요할 텐데요. 현재 무슨 클라우드 환경을 활용하며 어떤 수준의 리소스를 제공하나요?

기존 고도몰은 온프레미스(On-Premises) 환경에서 서비스를 제공하고 있었는데요, 재작년부터 클라우드로 인프라를 모두 옮기기 시작했어요. 이제는 모든 인프라를 클라우드 환경에서 사용하고 있습니다. 클라우드로는 NHN 클라우드를 이용하고 있어요. 아무래도 같은 그룹사인 만큼 서포팅 지원이 좋아요. 또 고객사가 대부분 국내 타깃인 만큼 안정적인 국내 클라우드만의 장점을 취할 수도 있고요.

이런 환경 아래 제공하는 CPU, 메모리, 스토리지, 네트워크 대역폭 등의 성능이 뛰어난 편입니다. 비즈니스 플랜을 적용하면 스토리지 300GB, 트래픽 1,200GB를 제공하는데요. 스토리지의 경우 50만 개 이상의 상품 데이터와 300만 명 이상의 회원 정보를 저장할 수 있는 수준이에요. 실제로 저희 플랫폼을 이용해 300만 회원을 관리하는 고객도 존재합니다. 또 트래픽의 경우, 대규모 이벤트에 맞춰 클라우드 인프라를 증설하면 시간당 100만 명까지 수용할 수 있습니다.

Q. 다음으로 고도몰이 해결해야 할 기술 과제는 무엇인가요? 그다음 스텝이 궁금해요.

중요한 과제를 3개 정도로 보고 있습니다. 첫 번째는 PHP 최신 버전의 장점을 쓸 수 있는 JIT(Just-In-Time) 컴파일러를 적용하는 거예요. 코드 실행 속도를 크게 올려 대규모 데이터 처리나 복잡한 로직의 적용을 쉽게 만들려는 목적이죠. 갈수록 늘어나는 트래픽이나 튜닝에 대응하기 위함이에요.

두 번째도 고도몰의 강점인 튜닝 기능을 제대로 활용하기 위한 과제로, API와 웹훅의 추가 개발입니다. 최근 시장에 나오는 다양한 SaaS와 연동하려면 강력한 API가 필수니까요. 다른 시스템과 쉽게 통합하고 연동할 수 있는 API를 많이 만들려고 해요.

마지막은 보안 강화입니다. 저희는 내부에서 보안 패치, 암호화 기술 강화, 실시간 모니터링 개선 등을 진행하고 있어요. 이를 위해 팀 내 보안 전문 인력을 3배로 늘렸죠. 자사몰 운영 과정에서 보안 사고가 터지는 건 치명적이니까요.

Q. 에이전시 개발자가 쇼핑몰 구축 솔루션을 최대치로 활용하려면 무엇이 중요할까요?

튜닝 가이드를 잘 지키는 것이 가장 좋습니다. 저희 생태계에서는 정말 다양한 튜닝이 일어나고 있어요. 그런 만큼 플랫폼도 꾸준히 진화하는 중이고요. 만약 튜닝 가이드를 큰 폭으로 벗어난다면 저희 측에서 정기적으로 진행하는 기능이나 보안 업데이트를 했을 때 오류가 발생할 가능성이 있죠. 저희 팀에서도 “어떤 기능을 만들 때 무슨 방법을 활용하면 좋다”를 알려주는 콘텐츠를 많이 만들고 배포하려고 준비하고 있어요.

활발한 에이전시 생태계를 만들기 위해 회사 차원에서 관심도 기울이고 있어요. 이런 콘텐츠뿐만 아니라 튜닝 센터를 통한 새로운 매출원 확보도 제공하려고 하고요. 업데이트가 있을 때마다 대화도 많이 할 예정입니다. 에이전시, 프리랜서 개발자와 함께 다양한 시도를 하고자 하니 많은 관심 주시면 좋겠습니다.

[고도몰 해드림 서비스 무료 이벤트]

요즘IT 독자를 위한 혜택을 준비했어요. 고도몰의 1:1 쇼핑몰 제작 서비스 ‘해드림’을 무료로 이용해 보세요.

아래 배너를 클릭하여 내용란에 “요즘IT”를 작성해 주세요.

이 글은 NHN 커머스와 함께 요즘IT 브랜디드 콘텐츠로 제작했습니다.

]]>

IT 아웃소싱을 잘 관리하는 3가지 방법

지난 편에 “갑은 SI 프로젝트를 어떻게 만들까?”에 대해서 정리를 했습니다.

이 글은 “을”(SI 기업)이 “갑”을 이해하기 위한 배경지식이었습니다.

이번에는 “갑”이 “갑”을 이해하기 위한 내용을 정리해 봅니다. 대상은 초보자 “갑”입니다.

SI 프로젝트의 갑은 큰 기업에도 있지만, 작은 기업에도 있습니다. 막 창업한 사장님은 무섭습니다. 여기저기에서 무작정 외주업체에 일을 맡기면 안 된다고 하니까요.

하지만 어찌해야 할지 모르겠습니다. 갑은 노하우를 서로 공유하지 않으니까요. 회사도 다르고 상황도 다르고 예산 규모, 시점 모두 달라서 정리된 이론이나 체계가 없습니다. 당연히 배울 수 없죠.

그러나 갑이 잘해야 프로젝트가 잘 끝납니다. 돈을 투자하고 끝까지 책임지는 주인이니까요. 주인이 잘해야 일꾼도 잘하는 법입니다.

베테랑 갑들은 너무나도 잘 아는 내용입니다. 하지만 전통산업에는 이를 모르는 분도 많아 이 글을 썼습니다. 도움이 되면 좋겠습니다.

※ 전통산업(Traditional Industry)이란, 오랜 역사를 가지고 우리 사회를 지탱하는 제조업 및 기간산업 등을 지칭하는 의미로 쓰였습니다.

IT 아웃소싱은 누가 할까?

“스타일난다”를 아시나요?

IT 업계 사람들은 잘 모를 수 있지만, 패션 업계의 네이버 정도로 취급됩니다. 젊은 여성들을 위한 패션 상품과 악세사리를 파는 곳입니다. 지금은 모두에게 익숙한 개념이지만 회사가 문을 연 2004년 당시로선 신선했습니다.

22살 여대생이 2004년에 시작한 회사는 2018년 로레알에 6천억 원을 받고 매각됩니다. 대표는 완전히 돈방석 위에 올라앉았죠. 당시 스타일난다의 매출은 2,000억 원, 영업이익은 400억 원(영업이익률 20%)이었습니다. 어마어마하죠.

스타일난다 홈페이지 메인 <출처: 스타일난다>

비슷한 사례로 무신사가 있습니다. 2001년 프리챌 커뮤니티에서 시작했죠. 신발 사진을 무진장 많이 찍어 올리던 게 계기가 되었습니다. 2023년 매출이 8,829억 원, 영업이익 370억 원이었습니다.

무신사는 개발팀을 100명 이상 데리고 있습니다. 반면 스타일난다는 개발팀을 운영하지 않았죠. 어느 게 더 좋다고 말할 순 없습니다. 각자 일장일단이 있죠. 여기에선 “스타일난다”를 예로 들어봅니다.

이 사업에는 IT가 반드시 필요합니다. 인터넷 쇼핑몰이니까요. 하지만 이 회사가 IT 사업을 하고 싶은 건 아닙니다. 좋은 물건 많이 팔아서 이익을 남기는 걸 하고 싶었죠.

패션이니만큼 유행 상품이 주력입니다. 재고를 많이 확보할 이유가 없죠. 다품종 판매 전략으로 인기 상품은 후딱 팔고 비인기 상품은 떨이를 합니다.

독립 쇼핑몰이 있어야 하고 기술 변화도 적절히 따라가야 합니다. IT의 역할이 작지는 않았죠.

반면 제품 회전이 빠르니 복잡한 개인화, 재고관리 등은 필요 없습니다. 이런 측면에서는 IT의 중요성이 떨어집니다.

그래서 “스타일난다”는 풀 아웃소싱 전략을 취합니다. 개발팀을 운영하지 않고 카페24에 모든 걸 맡겨 버리죠. 2010년 중국 시장을 공략할 때도 카페24를 활용합니다. 그러다 보니 위챗페이, 알리페이 등을 쉽게 붙일 수 있게 됩니다. 다음 해 매출이 677억 원에서 1,151억 원으로 늘어나죠. 큰 노력 없이 2배 성장해 버리죠.

굳이 개발팀을 운영하지 않고도 돈을 번 겁니다. 효과적인 아웃소싱 전략을 선택한 거죠.

IT 아웃소싱을 왜 할까?

왜 기업들은 직접 개발팀을 만들지 않고 SI를 발주할까요?

개발자들은 잘 이해하지 못합니다. 자기 걸 자기가 개발하는 게 너무 당연하거든요.

하지만 현실은 그렇지 않습니다. 국내 GDP를 보면 소프트웨어 세상은 전체 세상의 3.3% 정도밖에 안 되죠. 2021년 기준 “전체 산업 : 소프트웨어 산업 = 2,080조 원 : 68조 원”이었으니까요.

※ 2021년, 미국은 5.8% 정도 ($22조 9,395억 : $13,345억), 유럽은 4% 정도였습니다. ($21조 5,183억 : $8,868억)

GDP는 우리가 쓴 금액을 기준으로 합니다. 누군가 썼다는 건 누군가 벌었다는 뜻이니까요. 소프트웨어 산업의 총생산액이라는 건, 누군가 소프트웨어 구매나 아웃소싱에 쓴 금액을 의미합니다.

참고로 은행이 IT를 이용해 돈을 번 건 소프트웨어 산업이 아닙니다. 금융 산업이죠.

IT가 본업이 아닌 경우

즉, 96.7%의 세상은 IT와 관계없거나 IT를 이용하는 산업활동이라는 뜻입니다. 물론 유통, 제조, 금융, 국방 등 전통산업도 이제는 IT가 없으면 안 됩니다. 하지만, 소프트웨어 개발이 본업은 아니죠.

예를 들어 현대자동차가 소나타 생산라인 시스템을 매달 뜯어고친다면 소비자는 납득할 수 없습니다. 다음 달 바뀔 것을 이번 달에 사지는 않을 테니까요.

결과의 동일성과 프로세스의 항상성이 중요하다면, 자꾸 뭔가 고치는 것보다 한 번 구매해서 오래 쓰는 게 중요합니다. 개발팀을 만들어 빠르게 대응할 필요가 없죠. 전산실 같은 관리팀이 더 중요해집니다.

대기업만 그런 것은 아닙니다. 스타트업도 마찬가지입니다. “빠른 개발”과 “웹 서비스의 빠른 변화” 등이 경쟁력이 아니라면 처음부터 개발팀을 꾸리지는 않습니다.

전문성이 없는 경우

IT 회사라도 전문성이 없는 분야에선 아웃소싱을 합니다.

“케이뱅크”는 2017년 KT가 오픈한 인터넷은행입니다. 새로 시작한 은행이니 맨땅에서 출발해 다른 은행 수준까지 모든 걸 구현해야 했죠. 인가에서 인증까지 1년, 시간이 짧았습니다.

그래서 코어뱅킹은 국내 회사 솔루션을 구매하고, 정보계 등 단위시스템은 아웃소싱을 했죠. 그 비용으로만 첫해에 900억 원을 씁니다.

KT에는 KTDS라는 커다란 SI 회사가 있습니다. 하지만 금융 쪽 경험이 전혀 없었죠. 그래서 중요한 일임에도 불구하고 외부에 아웃소싱을 맡깁니다.

기업시장에서 전문성이란 일반적으로 “비즈니스 전문성”을 말합니다. 기업시장은 “기술”을 사는 게 아니라, “비즈니스가 포함된 기술”을 사는 거거든요. 연구개발 시간을 줄이고, 검증된 제품을 통해 성공 가능성을 높이는 겁니다. 솔루션을 개발하는 게 아니라 사업을 하는 게 목표니까요.

이 외에도 아웃소싱을 하는 다양한 이유가 있습니다. “비용 절감, 출시 기간 단축, 넓은 전문가 풀, 용이한 인력 조정” 등. 다 맞는 말인데, 아웃소싱을 할 수밖에 없는 가장 큰 이유를 보여주는 것이 위 두 가지, 스타일난다와 케이뱅크의 사례입니다.

전통산업이 존재하는 한 IT 아웃소싱, SI는 사라질 수 없습니다. 앞으로도 사라질 수 없죠. 소비자의 성향이 다양한 만큼 비즈니스의 세계도 다양하니까요.

IT 아웃소싱, 어떻게 해야 할까?

그러면 아웃소싱을 어떻게 해야 할까요?

“갑은 요구사항만 말하면 끝 아닌가요? 일은 수행사가 다 해줄 텐데요.”

갑 역할을 이렇게 아는 사람들이 많습니다. IT 아웃소싱에 대한 이해 부족 때문입니다. SI 산업이 급성장했던 2000년대에는 이런 일이 어느 정도 가능했습니다. 양질의 개발자들이 넘쳤거든요. 갑이 부족해도 개발자들이 몸을 갈아넣어서 그걸 메꾸었죠. 지금은 아닙니다.

지금은 상황도 복잡해지고 기술도 복잡해졌습니다. “갑”이 잘해야 합니다. 아주 잘해야 합니다. 하지만 이런 인식을 바로 잡을 기회가 없습니다. “갑 개발방법론” 같은 게 없으니까요. 그냥 잘못된 채로 흘러가는 겁니다.

아래는 IT 아웃소싱 모델의 여러 유형을 나타낸 표입니다.

표1. IT 아웃소싱의 모델 유형 <출처: Appsdevpro, 2023.10>

“전담팀 보강형”은 추가설명이 필요합니다. “전담팀 보강형”은 전산실 담당자가 유지 보수할 때 많이 쓰입니다. 하는 일이 뻔한데 구체적인 요구사항을 확정 지을 수는 없을 때죠. 요구사항이 아니라 업무 범위로 기준을 정하고, “기간 x 투입 인력수 x 등급별 대가”로 계약합니다.

ISP(전략계획) 같은 고급 프로젝트에도 많이 쓰입니다. 역시 요구사항을 확정 지을 수 없거든요. 다만 기본 단가를 높게 쳐줍니다.

이처럼 “관계 기반” 모델은 기본적으로 오너십이 “갑”에게 있습니다. “갑”이 해야 할 일을 외부 전문가를 활용해 업그레이드하는 거죠. “갑”이 아무것도 모르거나 바쁘지 않으면 아무런 성과도 얻지 못합니다. 사이즈가 작아 대부분 “갑”도 1인이 관리하죠.

잘하는 갑에게 붙여주면 아주 효과적입니다. “갑”의 능력을 증강시켜 주니까요. 반면, 못하는 갑에게 붙여주면 아주 망하는 겁니다. 역시 “갑”의 능력을 증강시켜 주니까요. 잘하는 노하우 같은 건 없습니다. 그냥 담당자 개인 성향과 자질에 의존하죠.

“프로젝트 기반형”은 목표가 명확하고 어떻게 해야 할 지 잘 알 때 씁니다. 한시적으로 많은 전문가가 필요하기 때문이죠. 기간, 예산이 정해져 있기 때문에 요구사항이 명확합니다.

장기간 프로젝트에는 유리하지 않습니다. 2~3년 이상이면 주변 상황이 변해버리거든요. 보통 3개월, 6개월, 1년짜리를 많이 합니다.

다만 큰 회사의 경우 업무 조율 때문에 일이 단방향으로 흘러갑니다. 여러 부서가 합의한 상황을 뒤집기 어려우니까요. 책임질 사람이 모호하거나 사라져 버린 경우도 있습니다.

“과업 기반 모델”도 잘 살펴보면 결국 “갑”이 일을 다 해야 합니다. 시스템 구현과 개발을 외주로 돌릴 뿐, 과업을 계획하고 진행시키고 책임지는 일까지 모두 “갑”이 해야 합니다.

여기서 일을 진행시킨다는 건 전체 관점의 일을 말합니다. 요즘은 레거시 없는 곳이 없어서 새 시스템이 만들어지고 있는 동안에도 레거시를 계속 건드려줘야 하거든요. 내부 레거시는 “갑”의 일이죠.

이해를 돕기 위해 꽤 잘 알려져 있으면서 복잡했던 사례를 분석해 봅니다.

신한은행 차세대 프로젝트

그림 1. 2021년 신한은행의 미래 전략 목표 <출처: 신한은행>

2021년 신한은행이 1,800억 원짜리 프로젝트를 런칭합니다. 코어뱅킹을 유닉스에서 리눅스 운영체제로 바꾸는 차세대 프로젝트였죠. 큰 결정인데 목표가 있었습니다.

영업을 좀 더 강화하고 싶었던 것입니다. 대면, 비대면 업무를 통합하고, 고객이 지점 아무 데나 가도 진행하던 대출을 이어서 할 수 있게 했습니다. 그렇게 은행원들이 지점 밖에서도 영업할 수 있게 했죠. 전반적으로 금융 업무에 대한 고객경험(CX)을 개선하고 싶었던 겁니다. 그래서 시작한 디지털 전환 사업이었죠.

계획을 세우는 데만 5개월에 9억 원을 씁니다. ISP 사업은 “EY한영”이 수행했죠. EY한영은 회계법인이지만, IT 컨설팅부터 프로젝트 관리까지 다 합니다.

※ ISP : Information Strategy Planning, 정보전략계획. 기업이 사업을 위해 IT 관련 중장기 미래 전략을 세우는 것을 말한다.

결과물로 42개월에 걸쳐 3,000억 원을 투자하자는 계획이 나옵니다. 변경 범위가 넓으니 단위 프로젝트를 단계적으로 오픈할 계획을 세우죠. 기술적으로는 LG CNS의 도움을 많이 얻습니다.

최종적으로 다음 내용이 제안요청서에 담겼습니다.

▲비대면 전용 코어뱅킹 시스템 구축

▲디지털 중심 코어뱅킹 시스템 전환 재 구축(Layered Architecture, 팩토리 고도화 등)

▲상담중심 단말 환경 재구축 및 CX 고도화

▲디지털 뱅킹 시스템 구조 현대화

▲디지털 라이프 시스템 분리 재 구축

▲데이터 거버넌스 체계 정비 및 관리 시스템 구축

▲넥스트 시스템 아키텍처 설계 및 SI 구축(단말 UI플랫폼, 통합 채널, 대외계, 프레임워크, U2L 등)

표2. 신한은행 “더 넥스트” 제안요청서 주요 과업 <출처: 신한은행>

꽤 구체적이지 않나요?

또한 제안 평가를 할 때 가격 점수보다 “정성 평가”를 높입니다. 가격 경쟁이 아니라 실력 수주를 할 수 있게 만들었죠.

“제안요청서”도 일부 기업에만 배포합니다. 기업비밀이 노출될 수 있거든요. 대기업들은 이렇게 많이 합니다.

제안 업체 선정 과정이 섬세하죠? 절대 허투루 준비하지 않았습니다. 목표와 과정을 정교하게 계획하고 역량 있는 SI 기업들과 의논을 했죠.

누가 했을까요? “갑”이 다 했습니다. 아무도 가르쳐주지 않았겠지만, 저걸 다 챙겨서 했습니다.

혼자 했을까요? 아닙니다. 이 사업의 시작은 진옥동 당시 신한은행장이었습니다. 이 업적을 인정받아 지금은 신한금융지주 회장이 되었죠. 회사 전체가 나서서 했던 겁니다.

구축 프로젝트는 LG CNS가 수주합니다. PMO는 여전히 EY한영이 맡았죠. 계획을 함께했던 기업들이 선정된 겁니다. 그림 그린 기업이 끝까지 책임 지게 만들었죠.

이후 “갑”은 놀았을까요? 아닙니다. 신한은행 내부에서 일어나는 일은 전부 “갑”의 일이거든요.

레거시와 통합하거나 데이터를 이전시켰습니다. 갑의 직원들이 해야 하는 일이죠.

업무 역할 정리와 조직 분리도 합니다. “디지털혁신단”을 신설해 AI 전략을 추진하게 만들었죠. CEO가 결정해야 하는 일입니다.

이런 프로젝트에서 “갑”이 안 바쁘면 이상한 겁니다. IT 프로젝트의 주인은 “갑”입니다. 수행사의 역할은 손과 두뇌를 빌려주는 거죠. 갑은 시스템이 완성되기 전에 사업운영 준비를 마쳐야 합니다.

준비 과정에서 갑이 안 바쁘다면 시스템이 완성되어도 사업을 시작할 수 없죠.

프로젝트 운영 단계

운영 단계로 넘어가면 “갑”의 역할이 더 중요해집니다. 이제 내부 요청에 직접 답을 해야 하니까요. 질문을 넘길 SI 팀이 없죠.

게다가 이제부턴 새로운 시스템이 돌아가는 겁니다. 아무도 모르는 일이 태반이죠.

이제부터 일어나는 모든 일은 세상에서 처음 일어나는 일입니다. 물어볼 사람도 없죠.

오직 “갑”이 능동적, 창의적으로 문제를 풀어가야 합니다.

시스템이 만들어졌다고 사업이 저절로 이루어지는 건 아닙니다. 사업 성과를 만들어 내려면 회사도 부담 백배죠.

IT 아웃소싱을 잘하는 방법

초보 “갑”들은 이런 질문을 합니다.

“어떻게 하면 프로젝트를 잘 끝낼 수 있을까요?”

“어떻게 하면 사업을 잘 지원할 수 있을까요?”

“도대체 무엇을 챙겨야 할까요?”

“저희가 알아서 다 해줍니다. OO님은 그냥 앉아서 쉬세요.”

이건 SI 영업맨들이 옛날에 했던 말입니다. PM들은 이런 말 안 합니다. “갑”의 역할이 얼마나 중요한지 아니까요. 요즘은 “영업맨”도 이렇게 말하지 않습니다. 시절이 많이 변했죠.

좋은 파트너

프로젝트 진행 과정은 눈에 보이지 않습니다. 아무리 보고를 잘 받아도 정말 제대로 진행되는지는 알 길이 없죠. 결국 수행사에 의지할 수밖에 없습니다.

성공적인 아웃소싱의 핵심은 좋은 수행사를 만나는 겁니다. 좀 허무한 결론이지만 그게 전부입니다. 그게 안 되면 아무리 좋은 이론도 말짱 꽝이죠.

그런데 대기업이면 다 좋은 수행사일까요? 프로젝트 금액이 크면 좋은 기업들이 올까요?

아닙니다. 좋은 파트너란 이 일에 맞는 경험과 실력을 가진 사람을 보유한 기업입니다. 결국 사람이 전부인 거죠.

어떻게 해야 그런 기업을 만날 수 있을까요? 말이 아니라 결과를 만들어내는 기업 말이죠. 역시 허무한 결론이지만, 평소에 부지런히 실력 있는 SI 기업들을 만나고 일을 해보는 수밖에 없습니다.

시간과 노력이 걸리는 일입니다. 그래서 큰 프로젝트를 하려면 평소에 차근차근히 준비해야 하죠.

좋은 파트너를 만난 다음은 어떻게 해야 할까요? 가만히 있으면 될까요? 아닙니다.

프로젝트에는 항상 새로운 문제들이 등장합니다. 시간만 충분하다면 대부분 해결할 수 있는 일들이죠. 하지만 항상 시간이 부족해서 사고가 납니다. “을”이 미리 알고 나서도 제때 보고하지 못한 거죠. “갑”과의 관계가 불편하거나 공격받을 가능성이 있기 때문에 보고를 안 한 겁니다.

그래서 프로젝트의 시작은 편하게 대화할 수 있는 관계를 만드는 겁니다. 그게 문제에 대처할 시간을 미리 확보하기 위한 핵심 요령이죠.

이 모든 것 이전에 가장 중요한 게 있습니다.

바로 “갑”이 자기 역할과 책임을 올바로 인식하는 겁니다.

간혹 상황이 어려워지면 책임을 피해 도망 다니는 “갑”이 있습니다. 책임질 사람이 없으니 일 마무리가 되지 않죠. 상황은 더욱 악화됩니다.

갑질하는 “갑”도 있습니다. “을”을 윽박지르는 걸로 문제를 해결하려 하죠. 하지만, 문제는 해결되지 않습니다. 윽박지르지 않았던 게 문제의 원인은 아니니까요.

책임질 일은 빨리 책임지고 다음 단계로 넘어갑니다. 윽박지르지 않고 문제 원인을 찾아 제거하고, 재발하지 않도록 조치합니다. 그게 갑이 해야 할 일입니다.

시간과 노력을 들여 좋은 수행사를 찾습니다. 그다음 좋은 파트너가 되어 줍니다. 아주 평범한 이야기입니다만, 그게 “갑”이 프로젝트를 준비하는 과정입니다. 시간과 노력이 꽤 들어갑니다.

기대치 관리

“갑”은 회사 내부의 “기대치” 관리를 잘해야 합니다. 나의 기대치 아닙니다. CEO, 임원 등 의사결정권자들의 기대치입니다.

돈을 쓰는 데는 다 이유가 있습니다. 1억 원에는 1억 원, 10억 원에는 10억 원만큼의 효과를 기대합니다.

하지만 일은 항상 계획대로 되지 않습니다. 그래서 돈 쓰는 사람들의 기대치를 잘 관리해야 합니다.

“기대치”는 “목표”와 다릅니다. 기대치는 목표보다 앞에 있습니다.

“비대면 거래관리를 위해 코어뱅킹을 업그레이드하는 것”, 이건 목표입니다.

“영업점이 비대면 업무처리를 가능하게 하는 것”, 이게 기대치입니다.

기대치는 제품이 아니라 회사 내부의 변화입니다. 의사결정권자가 그 수준을 정합니다. 그런데 회사에는 의사결정권자가 한 명이 아닙니다. 여러 부서에 걸쳐 있습니다. 쉽게 정리되지 않습니다. 그래서 기대치는 시간을 두고 조율해야 합니다. 프로젝트 시작 전에 말이죠.

수준과 내용 조절은 비교적 가능합니다. 하지만 숙제가 생기면 까다로워집니다. 부서끼리 양보할 수 없는 한계선이 생깁니다. “기대치 관리”는 이런 걸 확인하는 과정입니다.

조율에는 시간이 오래 걸립니다. 새로운 업무 지침을 만들거나 규정도 개정해야 합니다.

비대면 계좌 개설을 한다고 합시다. 개인정보 확인은 휴대폰 인증만 할지, 은행 계좌 인증은 안 할지, 신용불량자에게도 개설을 허용할지, 대포통장은 어떻게 확인하고 막을지 등등을 살펴봐야 합니다.

코드를 어떻게 부여해야 할지는 개발회사의 몫이지만, 정책 결정은 “갑”의 몫입니다. 정책 결정을 하지 못하면 개발이 진행되지 않습니다. 그런데 정책 결정에는 후속 업무가 발생합니다. 비대면 계좌 개설 관련 새로운 정책이 나오면 후속 업무는 프로젝트 담당자가 아니라, 계좌 담당 부서에서 정리해야 합니다. 시간이 걸리겠죠.

프로젝트를 하다 보면 이런 일들이 엄청 많습니다. 즉 “기대치 관리”란 단순한 의견 조율이 아니라, 예산, 기간, 목표 수준, 업무 변화 등을 결정하는 예측 작업입니다.

1,000억 원짜리 프로젝트에만 해당하지 않습니다. 1천만 원짜리 프로젝트에도 이런 일이 있습니다.

“소프트웨어 개발”을 아웃소싱할 수 있지만, “사업 준비”는 아웃소싱할 수 없습니다.

결과물 관리

DB 설계서, API 정의서, 소스코드 등 산출물은 중요합니다. 진행 여부를 확인할 수 있는 양적 결과물이기 때문입니다. 그런데, 산출물을 챙긴다는 건 단순히 “문서” 파일을 받는다는 게 아닙니다.

산출물은 문제 풀이 과정의 결과물입니다. 산출물을 만들라는 건 그 “문제 풀이 과정”을 하라는 뜻입니다. DB 설계서가 나오려면 DB 설계라는 과정이 있어야 합니다.

코드 데이터는 어떻게 만들지, 회원 정보는 어디서 가져올지, 신용정보는 어디서 연동할지 등을 먼저 협의해야 합니다.

그러려면 담당 부서와 회의를 해야 합니다. 이 회의를 주최해야 할 사람이 “갑”입니다.

그런데, “갑”이 정직원이라 해도 그런 복잡한 데이터가 어디에 있는지 모를 수 있습니다. 새로 만들어야 할지 기존 데이터를 재활용할지도 결정하지 못합니다. 삭제 시점이나 폐기에 관한 룰도 정해야 합니다.

당연히 1시간 만에 결정되지 않습니다. 이런 조율 시간을 고려해서 프로젝트 일정에 반영해야 합니다.

ERD, 프로세스 정의서, 클래스 다이어그램? 문서 양식의 이름은 중요하지 않습니다. 산출물을 만들기 위해 “필요한 행동을 제대로 했냐?”가 중요합니다.

제 경험에서 나온 예시입니다. 꽤 큰 유통회사였습니다. A 시스템을 업그레이드할 생각이었습니다. DBA가 기초데이터를 B 시스템에서 추려 넣어줘야 했습니다. SI 개발자는 보안 이슈로 필요한 기능만 개발하면 되었습니다.

그런데 DBA가 테이블 정의서도 데이터 구조도 주지 않았습니다. 그래서 말했습니다.

“제가 할게요. API만 열어주세요.” API도 없습니다.

“아, 그럼 특정 계정에 View Table만 열어주세요. 제가 할게요”. 이제 DBA가 휴가 가고 없습니다.

정리된 엑셀 파일도 없고, 위키도 없습니다.

당연히 이 프로젝트는 우여곡절을 많이 겪었습니다. 당시 꽤 주목을 받는 이름있는 기업이었습니다.

‘큰 기업은 잘하고 있겠지?’ 그렇지 않습니다. 산출물을 관리한다는 건 할 일을 점검하고 준비한다는 뜻입니다. “개발”은 아웃소싱할 수 있습니다. 하지만, “내부업무”는 아웃소싱할 수 없습니다. 대부분의 프로젝트는 “개발”이 50, “사업관리”가 50입니다.

마치며

회사마다 프로젝트마다 상황이 다릅니다. “갑”이 해야 할 일도 다릅니다. 그래서 위에 설명한 상황이 얼마나 도움이 될지 확신은 못 하겠습니다.

‘큰 프로젝트는 저렇게 하는구나.’

‘저런 일들이 일어나는구나.’

이 정도로만 이해해 주시면 좋겠습니다. 막연하게 프로젝트에 들어가기보다 어느 정도 감 잡을 수 있는 정도로만 이해되기를 바랍니다.

1천만 원짜리 프로젝트도 비슷합니다. 이슈의 크기에 차이가 있을 뿐, 저런 일들이 일어나야 합니다.

아웃소싱은 사라지지 않을 겁니다. 기업시장, 공공시장 등 비 IT 산업은 아웃소싱을 할 수 밖에 없습니다.

그런데 아웃소싱의 “갑”을 위한 이론, 업무 체계는 없습니다. 회사마다 상황이 달라서 앞으로도 없을 것 같습니다. 하지만 요점은 있습니다. 잊지 말았으면 합니다.

아웃소싱은 “갑”이 하는 거대한 프로젝트의 일부분일 뿐입니다. 부족한 IT 역량을 전문가의 손에서 빌리는 겁니다. 끊임없이 소통하고 점검해야 일이 제대로 끝납니다.

]]>

프리랜서는 어디에서 일을 구할까?

최근 업의 형태가 다양해지며 프리랜서, 프리워커, 디지털 노마드로 일하는 N잡러들이 늘어났습니다. 그에 따라 여러 근무 형태가 생겨나고 있죠. 그러나 처음 프리랜서로 일을 시작할 때는 클라이언트를 어떻게 구해야 할지 막막할 수 있습니다.

저 역시 작년부터 1년간 프리랜서로 살아오고 있는데요. 클라이언트를 새로 구하기 위해 가장 자주 활용한 것은 프리랜서 관련 플랫폼입니다. 플랫폼의 인재 풀에 등록해 두거나 원하는 공고가 올라오면 지원했습니다. 이런 과정에서 조금씩 경험도 쌓였습니다.

이번 글에서는 제 경험을 바탕으로 국내외에서 활용할 수 있는 프리랜서 플랫폼을 비교해 보려고 합니다. 내게 적합한 플랫폼을 찾는 방법을 소개하겠습니다.

프리랜서는 돈을 어떻게 벌까?

<출처: freepik>

프리랜서 일을 구하는 3가지 방법

프리랜서는 비즈니스 모델이 다양합니다. 대표적으로 파트타임 업무, 컨설팅 및 자문, 강의 등 다양한 방식의 업무 형태를 선택할 수 있습니다. 이때는 보통 플랫폼, 직접 제안, 지인 소개 등으로 클라이언트와 연결됩니다.

1. 플랫폼을 통한 연결
프리랜서와 클라이언트를 연결하는 플랫폼; 크몽, 위시켓, 커리어데이, 업워크, 파이버 등 온라인 중개 플랫폼

2. 클라이언트의 제안
SNS(링크드인, 블로그 등), 개인 포트폴리오 웹사이트를 통해 클라이언트가 먼저 제안

3. 지인 소개
입소문이나 네트워킹(콘퍼런스, 커뮤니티 등), 지인의 소개로 들어오는 일거리

이 3가지 방법은 서로 보완적입니다. 또한 프리랜서의 경력 단계나 전문 분야에 따라 각 방법의 효과성이 달라질 수 있습니다. 저 역시 이를 적절히 섞어 활용하며 프리랜서 활동을 이어갈 수 있었습니다.

플랫폼을 이용할 때 프리랜서의 수익 구조

특히 플랫폼을 통해 클라이언트와 매칭이 되었을 때는 수수료가 발생합니다. 플랫폼이 중간에서 클라이언트와 연결해 주고 수수료를 떼어가는 구조로 진행됩니다.

예를 들어, 1시간 컨설팅 비용으로 50만 원을 받았다고 가정하겠습니다. 여기에 플랫폼 수수료 10%, 세금 3.3%를 제외하면 프리랜서는 최종적으로 435,150원을 받습니다. 이런 계산을 미리 해야 실제 프리랜서의 순수익을 예측하는 데 도움이 됩니다. 따라서 처음부터 수수료와 세금을 고려해 서비스의 적정 가격을 책정하는 것이 중요합니다.

플랫폼을 이용하면 대부분 5~20% 정도 수수료를 내야 합니다. 하지만 그만큼 안전하게 정산을 받을 수 있으며 다양한 클라이언트를 만날 수 있다는 장점이 있습니다. 플랫폼을 활용하지 않고 직접 클라이언트를 찾아 일하면 수수료가 없어 단가가 높아지지만, 커뮤니케이션, 계약, 정산 등을 직접 해야 하므로 번거로울 수 있습니다.

어떤 프리랜서 플랫폼이 있을까?

국내외에는 프리랜서와 클라이언트를 매칭해 주는 다양한 플랫폼이 있습니다. 이 중에서 대표적으로 많이 쓰이며, 프로젝트 건수가 많은 플랫폼 가운데 개인적으로 사용해 본 경험이 있는 프리랜서 플랫폼을 추려보았습니다.

<출처: freepik>

크몽

<출처: 크몽, 작가 캡처>

크몽은 국내 최대 규모 온라인 프리랜서 플랫폼입니다. 개발, 디자인, 마케팅 등 다양한 분야의 전문가들이 서비스를 제공하며 구매자는 필요한 서비스를 쉽게 찾아 구매할 수 있습니다. 2012년 설립 이후 꾸준히 성장했고, 현재는 수많은 프리랜서와 1인 사업가들이 활발하게 이용하는 대표 플랫폼으로 자리 잡았습니다.

위시켓

<출처: 위시켓, 작가 캡처>

위시켓에서는 다른 플랫폼과 비교해 대기업 혹은 큰 규모 기업의 프로젝트 외주를 할 수 있다는 특징이 있습니다. 주로 개발 프로젝트가 많은데요. 소규모 프로젝트부터 회사의 핵심 시스템을 개발하는 대형 프로젝트까지 다양한 규모의 일거리가 있습니다. 또한 프로젝트당 비용을 홈페이지에서 확인할 수 있어서 참고하기 좋습니다.

커리어데이

<출처: 커리어데이, 작가 캡처>

커리어데이에는 멘토링, 강연, 자문 등 주로 단기간 진행하는 프로젝트 공고가 많이 올라옵니다. 그렇기에 다양한 형태의 프로젝트에 참여하면서 폭넓은 경험을 쌓을 수 있습니다. 저도 커리어데이를 통해 자문, 특강 형식의 강의, 멘토링과 같은 단기 프로젝트를 종종 진행했습니다. 특히 클라이언트의 리뷰와 별점이 쌓이면 더 많은 제안이 들어오기도 했습니다.

디오(DIO)

<출처: 디오, 작가 캡처>

디오(DIO)에서는 주로 개발, 데이터, 마케팅 등 다양한 포지션의 스타트업 파트타임 업무를 구할 수 있습니다. 지원자가 주당 일할 수 있는 시간 정보를 설정하면, 플랫폼에서 이를 검토하고 적합한 대상을 매칭해 줍니다. 이 방법으로 클라이언트와 이어질 수 있습니다.

그 외에도 번지, 이랜서, 원포인트(ONE POINT) 등이 프리랜서가 일을 구할 수 있는 국내 플랫폼입니다.

업워크(Upwork)

해외는 국내보다 더욱 프리랜서 시장이 발달해 있습니다. 그만큼 플랫폼 역시 고도화되어 있습니다. 만약 외국어로 커뮤니케이션할 수 있다면 이 공간에서 세계 각국의 다양한 프로젝트와 클라이언트를 만날 수 있습니다.

<출처: 업워크, 작가 캡처>

업워크(Upwork)는 전 세계에서 가장 유명한 프리랜서 플랫폼 중 하나로, 모든 나라의 클라이언트와 프리랜서를 연결합니다. 글로벌 환경에서 일하고 싶거나, 다양한 프로젝트를 경험하고 싶은 프리랜서에게 좋은 선택이 될 수 있습니다. 특히 시간제 계약을 맺을 때 시스템으로 정확하게 정산할 수 있다는 것이 장점입니다.

그 외에도 파이버(Fiverr), 프리랜서닷컴(Freelancer.com) 등 다양한 해외 프리랜서 매칭 플랫폼이 있습니다.

어떤 플랫폼을 선택해야 할까?

지난 1년간 프리랜서로 생활하며 플랫폼의 다양성과 활용법을 배웠습니다. 플랫폼마다 특징과 장단점이 다른 만큼, 그에 맞는 접근 방법이 필요했습니다. 플랫폼에 특화된 공고가 많이 올라오기 때문에 매칭되는 프로젝트의 종류도 달랐습니다. 국내 4개 플랫폼의 특징을 아래와 같이 표로 정리해 보았습니다.

크몽은 프리랜서가 프로필을 등록하면 클라이언트가 이를 보고 직접 프리랜서를 선택하는 방식을 채택합니다. 반면 위시켓은 클라이언트가 프로젝트를 등록하면 프리랜서가 이에 지원하고 클라이언트가 지원자를 선택하는 방식입니다. 따라서 프리랜서가 적극적으로 프로젝트를 찾아야 합니다. 이처럼 적극성 측면이 다르니 플랫폼에 맞는 방식을 취해야 합니다.

플랫폼별 주요 작업 형태를 중심으로 선정하면, 다양한 분야의 클라이언트를 확보할 수도 있습니다. 커리어데이 플랫폼에서는 주로 데이터 분석 관련 특강을 맡았습니다. 한번은 취업 준비생을 대상으로 ‘'취업 동기부여 특강”이라는 주제로 6시간 강연을 하기도 했습니다. 매우 보람차면서도 새로운 경험이었는데요, 이처럼 플랫폼을 잘 활용해 프리랜서 업무를 확장할 수도 있었습니다.

마치며

처음 프리랜서에 도전하거나 N잡을 시도할 때, 가장 어려운 것은 클라이언트를 구하는 일입니다. 그렇기에 국내외 다양한 프리랜서 플랫폼과 링크드인 등 SNS에 포트폴리오를 노출하고 기회를 만드는 것이 중요합니다.

무엇보다 자신에게 적합한 플랫폼을 찾아 활용할 때 더 많은 클라이언트를 만날 수 있습니다. 그만큼 각 플랫폼의 특성을 잘 파악하고 그에 맞는 전략을 세우는 것이 중요합니다. 시간이 흐름에 따라 플랫폼에서 만난 클라이언트들과 스스로 네트워크를 구축하며 장기적인 관계를 형성하는 것도 성장에 큰 도움이 될 것입니다.

이 글을 바탕으로 적절하게 플랫폼을 활용하며 클라이언트와 협업 기회를 확보해 보시기 바랍니다.

]]>

SI 기업이 인구 절벽에 대비하는 4가지 방법

인구 절벽 시대를 맞아 부정적인 전망이 나오는 요즘이다. 우리 정부는 이를 해결하고자 오랫동안 많은 정책과 공적 자금을 쏟아부었지만, 효과는 미미했다. 이것이 과연 해결할 수 있는 문제가 맞는지 회의적인 목소리도 나오고 있다.

그에 맞춰 지금도 인력 부족에 시달리고 있는 SI 기업이 이에 더 빠르게 휘말릴 것이라는 의견이 커지고 있다. 이러한 위험에 대비해야 한다는 데 공감한다면, 이 문제가 SI 기업에 미칠 부정적인 영향들을 예상하고 미리 대응책을 마련할 필요가 있을 것이다.

IT 인력 수급은 왜 점점 어려워질까?

인구 구조적 영향

정부의 한 보고서는 저출생 문제의 심각성을 다음과 같이 전하고 있다.

“2022년의 합계출산율은 0.78을 기록했으며, 최근 발표된 2023년 2분기 합계출산율이 0.7까지 떨어지는 등 한국의 출산율은 세계적으로 유례를 찾기 어려울 정도로 낮은 수준이다.” [1]

이처럼 최근 들어 우리나라에서 급격하게 문제가 가속화된 것과는 별개로, 대부분 선진국의 인구가 감소하는 경향이 있다는 사실은 매우 잘 알려진 현상이다. 한국 역시 선진국 반열에 오르며 이런 현상이 나타나기 시작했으며, 그와 함께 고령 인구 비중도 높아졌다.

국내 인구 피라미드의 연도별 비교 <출처: SGIS>

1960년과 지금의 인구 피라미드를 비교해 보면 역삼각형으로 가는 변화가 뚜렷하게 나타난다. 다시 말해 나라가 늙어간다는 거다. 행안부에서 발표한 2023년 12월 주민등록 통계를 살펴본 기사에 따르면, 우리나라는 이미 70대 이상 인구가 20대 인구를 앞질렀다. 이는 곧 경제활동인구보다 비경제활동인구가 더 많아질 것이라는 전망을 하게 만든다. 현업 인력의 평균 연령이 높아질 것이라는 예상 역시 어렵지 않다.

일자리의 감소

한 보고서에 따르면 최근 2021~2023년간 소프트웨어 인력은 계속 증가하는 추세다.[2] 아래 그래프는 그러한 추이를 반영한다.

2018~2022년 SW전문인력 추이 <출처: SWSTAT>

하지만 이런 추세는 최근 미국 IT 기업들이 인력 감축을 단행하는 현상을 함께 고려하며 평가해야 한다. 글로벌이코노믹의 기사처럼 팬데믹 특수가 끝난 IT 기업은 인력 감축을 벌이고 있다. 앞으로 IT 일자리 추이가 어찌 될지 지켜봐야 할 문제라는 뜻이다.

SI 기피 현상

IT 서비스업, 특히 SI의 경우는 과도한 노동 강도나 잦은 출장 등을 이유로 소위 MZ 세대의 기피 대상이 되었다. 그들뿐만이 아니다. 피로도가 누적된 경력직들이 이탈하는 경우 역시 발생했다. 과기부의 중소기업실태조사에 따르면, 최근 중소 IT 서비스업은 심각한 인력 부족 현상을 겪고 있다.

2019~2022년 중소기업실태조사: IT서비스업 인력 부족 합계 추이 <출처: ITSTAT>

이처럼 안 그래도 엔지니어 수급이 어려운 상황에서, 저출생 등 다른 외부 요인은 이러한 현상을 더욱 가속하기에 좋다.

인력 수급의 어려움을 극복할 현실적인 방안

IT 서비스업의 경쟁력은 노동력에서 나온다고 해도 과언이 아니다. 자본 설비가 중요한 제조업의 경우, 한 사람을 추가로 고용해 발생하는 한계 이익은 적다. 반면 IT 서비스업의 한계 이익은 클 수밖에 없다. 서비스업이라는 그 특성상, 개발자의 직접 서비스가 곧 매출과 영업 이익으로 이어지기 때문이다. 그러므로 인력 수급의 문제는 곧 IT 기업에 생존의 문제가 된다. 인구 절벽이라는 환경적 요인을 직접 해결하기 어렵다면 IT 서비스 기업은 어떻게 해야 할까?

1. 문제 정의: 인력 부족=서비스 품질 저하

인력 감소로 가장 크게 걱정해야 하는 것은 서비스 품질이 낮아지는 경우다. 정보 시스템은 만들고 유지하는데 사람이 필수적이다. 이를 개발하고 유지 보수하는 인력이 줄어들면 서비스 품질은 당연히 떨어질 것이다.

서비스업 특성상 고객은 서비스의 품질 저하를 빠르게 체감한다. 이 점을 잊어서는 안 된다. 담당자가 자주 바뀌거나 대응이 빠르지 못하면, 고객은 상당한 피로감을 느낀다. 이처럼 문제에 대응하려면 우선 인력 부족이 가져오는 문제를 제대로 이해해야 한다.

2. 지금 할 수 있는 것: 인력 이탈 속도 늦추기

문제를 정의했는가? 그렇다면 지금 당장 할 수 있으며 어느 정도 빠르게 효과를 볼 수 있는 플랜을 가장 먼저 고려할 것이다. 이에 해당하는 해결책은 인력이 부족해지는 속도를 늦추는 방향이다. 다시 말해, 직원 이탈을 관리하는 방안이다.

현재 기업에서 일하고 있는 직원은 회사의 교육과 시스템에 적응한 사람이다. 이들의 이직은 서비스 품질에 즉각 타격을 준다. 만약 새로운 직원을 뽑으면 그에 대한 교육 비용이 추가로 든다. 그러니 직원 이탈을 방지하여 품질이 떨어질 가능성을 차단하는 것이 단기적인 문제 해결 방안의 핵심이다.

직원이 교육을 받을 동기 만들기

서비스의 품질을 관리하는 가장 대표적인 방법은 바로 직원 교육이다. 하지만 이러한 목적은 전적으로 회사의 사정일 뿐이다. 효과적인 교육을 위해서는 직원이 교육을 받아야 할 개인적인 동기와 회사의 사정을 일치시킬 필요가 있다. 예를 들어 회사가 제조 분야를 강화하는 교육을 해야 한다고 하자. 만약 물류에 관심이 많은 직원이 있다면 되도록 그에게 관련이 깊은 자재, 출하 분야를 관련지어 교육할 수 있다. 이처럼 개인의 동기에 교육을 맞출 필요가 있는 것이다.

또는 직원에게 교육을 받아야 할 이유를 충분히 설명하며 개인의 의사와 의견을 적극 반영해야 한다. 이런 사전 작업이 제대로 이뤄지지 않으면 결국 교육의 효과는 떨어질 것이다.

넉넉한 인센티브

고용자 입장에서 임금을 높이는 것은 상당히 부담스러운 일이다. 이럴 경우 인센티브는 쉬운 해결책이 된다. 여기서 말하는 인센티브란 성과급과는 다르다. 인센티브란 어떤 행동을 제도적으로 유인해 이를 보상하는 것을 뜻하기 때문이다. 예를 들어 기존 직원이 아는 개발자를 소개하고 채용이 완료되면 보상을 주는 경우가 SI의 대표적인 인센티브 제도라 할 수 있다. 그 외 정부 과제를 따올 때 보상을 해주는 등 경영의 목적을 실현하기 위해 시행하는 것이 인센티브 제도라 할 수 있다.

모두가 같은 노동 강도로 일을 하지 않기 때문에 인센티브 제도는 중요하다. 이런 인센티브가 없는 상황에서 연봉으로 모든 경우를 고려하려면, 수많은 정치적인 이유가 이를 방해해 보상이 잘 안되는 경우가 태반이다. 하지만 인센티브 제도의 경우, 정치적인 사정이 개입하기 어려워 올바르게 보상할 수 있다.

또 다른 인센티브의 장점은 축소와 완화가 쉽다는 점이다. 임금은 깎으면 큰일이 나지만, 인센티브는 여러 사정에 의해 고치는 것이 편리하다. 중소기업에서는 성과급 이야기로 직원들의 사기를 높이는 일에 거의 실패한다는 것을 유념해야 한다. 인센티브는 이보다 가능성이 높으므로 행동을 유인하기도 비교적 쉽다.

복지 제도 차별화

복지 제도는 인센티브와 달리 직원들의 근무 환경과 관련된 사항이다. 인센티브가 특정한 행동에 보상을 줘서 경영상 목적을 이루는 것과 달리, 복지 제도는 전체 직원을 대상으로 무차별하게 혜택을 주는 것이다. 따라서 이를 축소하는 경우 직원들 사기에 부정적인 영향을 미친다. 그러니 도입하는 제도가 지속적으로 유지할 수 있는 성격인지 잘 고려해야 한다.

그럼에도 복지 제도는 인력 유치에 있어 다른 경쟁사와 차별화를 줄 수 있다는 강점이 있다. 이는 기존 직원 이탈의 장애물이 되기도 한다. 예를 들어 주 4일제를 하는 회사는 매우 희소하기 때문에 그곳에 다니는 직원은 높은 연봉을 준다는 헤드헌터의 설득에도 이직을 꺼릴 수 있다.

3. 지금 할 수 있지만 관리 역량이 필요한 것: 외주화

이러한 솔루션을 사용해도 인력을 유지하기 어려운 지경이 되었다면 어떻게 해야 할까? 물론 이런 지경까지 왔다면 정말로 경영을 유지할 수 있을지 회의가 들 만도 하다. 이럴 때는 신뢰할 수 있는 파트너와 함께 프로젝트를 정례화하는 것도 방법이 된다. 기업의 경우, 위시켓처럼 어느 정도 신뢰할 수 있는 시스템을 갖춘 아웃소싱 플랫폼 서비스를 통해 프리랜서와 거래할 수 있다.

최근 SW 프리랜서를 없어서 못 쓴다는 말이 많다. 전자신문 기사에 따르면 SW 프리랜서의 96.7%가 프로젝트 투입 중이라고 한다. 그만큼 기업이 정규직보다 외주에 의존하는 경우가 많아지고 있다는 소리이다. 외주의 장점은 고용에 대한 부담 없이 필요할 때마다 인력을 유연하게 사용할 수 있다는 점이다.

물론 양면성이 있기 마련이다. 외주화의 어려움은 발주처의 매니지먼트 역량이 그 변수가 된다는 데에 있다. 일반적으로 SI 기업은 ‘을’이라는 입장에서 프로젝트에 참여해 왔기 때문에 매니지먼트 역량이 약하다. 그러므로 이런 역량을 강화하는 시도와 경험은 분명 장기적으로 가치 있는 일이다.

4. 시간이 걸리지만 가치 있는 것: 기술 연구&프로세스 뜯어고치기

지금까지 말한 솔루션들은 품질 저하를 관리하고 인력 이탈을 방지하는 등 “관리”에 중점을 두었다. 하지만 장기적으로는 앞에서 설명한 대로 인구 절벽에 대한 대비가 필요하다.

뻔한 방안이지만, 첫 번째는 제품 혹은 패키지 매출 비중을 늘려 SI 의존을 낮추는 것이다. 최근 들어 SI의 맨먼스 단가는 높아지고 있으나, 영업이익률은 악화되는 경향이 나타나고 있다. 이를 보면 SI 사업에 대한 의존성을 낮춰야 한다는 데 다들 동의할 수 있을 것이다.

물론 그렇다고 모든 IT 제품이 성공하는 것은 아니다. (심지어 몇 년 동안 매출이 없을 수도 있다) 이처럼 어느 정도 도박과 같다는 점이 이 방안의 불안전성이다. 그러나 최근 제품에 인공지능과 클라우드 기술 접목이 많아지며 전반적인 IT 서비스업의 기술 수준이 발전하고 있다는 것을 많이 느낀다. 개별 제품의 성공 여부와 상관없이 제품을 만드는 시도와 그에 따르는 연구는 분명 기업에 가치 있는 일임에 틀림없다.

다른 방안은 SI의 비용을 낮춰 효율화를 꾀하는 것이다. 인공지능의 활용, 그리고 이에 기반한 프로세스 뜯어고치기를 시도할 필요가 있다.

물론 SI는 근원적으로 사람이 하는 서비스다. 따라서 프로젝트를 관리하는 리더, 고객과 커뮤니케이션하는 매니저는 필수적이다. 그러나 SW를 개발하는 인력이 지금과 같이 계속 필수적일지는 장담하기 어려워 보인다. 깃허브 코파일럿과 함께 IDE에서 자연어로 개발하는 경험을 해본 개발자라면, 곧 개발자 없는 소프트웨어 개발의 시대를 예상해 봤을 수 있다. 이런 기술의 발전을 지켜보며 개발 프로세스를 재배치할 준비를 하는 일 역시 좋은 방안이 될 것이다.

개발자 개인은 무엇을 할 수 있을까?

그렇다면 개발자 개인은 인구 절벽에 앞서 무엇을 준비해야 할까? 특히 인구 절벽 문제가 커질 10~20년 뒤에도 일을 하고 있을 주니어 개발자에게 이는 가장 중요한 문제일 것이다.

이 문제 역시 위에서 언급한 기업의 대응을 짚어보면 충분히 대안을 예상해 볼 수 있다. 바로 지금 선배들에게 배우고 있는 업무 프로세스가 앞으로는 분명 달라질 것이라는 점이다. 이때, 달라지는 프로세스를 만들 주역은 지금의 주니어 개발자다. 그러므로 현재 업무 프로세스를 이해하고 익힌 다음 문제를 찾아 새로운 기술로 이를 개선하는 훈련과 경험을 쌓아야 한다. 이 역량이 앞으로 무엇보다 더 중요해질 것이라 예상한다.

마치며

지금까지 인력 수급의 어려움에 대한 경향, 그리고 그 대안에 대해 알아보았다. 물론 여기서 언급한 방안들은 뻔한 이야기로 들릴 수 있다. 그럼에도 꾸준히 이런 대책이 나오는 것은 그만큼 행동이 쉽지 않은 일들이기 때문이다.

최근 업계에서 인력 부족에 대한 한탄이 많이 들린다. 인구 절벽 문제와 인력 수급 문제가 상관관계가 높은 문제이며, 이 문제를 피하기 어렵다는 공감대가 형성되었기 때문일까? 그렇다면 문제가 더 커지기 전에 먼저 다양한 방법으로 충분히 대비할 필요가 있다.

<참고 글>

[1] 이철희, 김정호, 이소영, 민규량. (2023). 저출산 정책 평가 및 핵심과제 선정 연구. 저출산고령사회위원회 발간보고서. 2023년 9월. 링크

[2] 소프트웨어정책연구소. 「2023년 SW산업실태조사 보고서」 p27.

]]>

SI 기업의 AI 생존 전략

올해 생각보다 기업시장이 어렵습니다. 여러 가지 이유가 있겠지만, AI 기술의 변화에 주목해 봅니다. 변화가 너무 빨라 기업들은 AI의 활용성을 시험하고 있을 뿐, 충분히 대응하지 못하고 있습니다.

주변 분들과 수다 떨면서 든 생각들을 정리해 보았습니다. 좁은 식견에 부족한 생각일 수 있습니다. 그냥 가볍게 읽어주셨으면 좋겠습니다.

AI란 무엇일까?

<출처: Sentinum, AI: 머신러닝과 언어모델의 차이>

머신러닝, 딥러닝 등 학술적이고 복잡한 설명은 많으니까, 학술적이지 않은 방식으로 핵심만 설명해 봅니다.

지금의 AI는 크게 언어학습을 한 경우와 안 한 경우로 나뉩니다.

언어학습을 안 한 AI가 가장 널리 쓰이는 분야는“자동차 자율주행”입니다. 말만 안 할 뿐 판단을 자기가 다 합니다. 산업현장에서 쓰인지 좀 되었습니다. 테슬라가 나왔으니까요.

기업용으로 제어와 통제를 할 수 있습니다. 그래서 쓰일 일이 많습니다. 냉장고에도 들어가고, 세탁기에도 들어갑니다.

언어학습을 한 경우는 사람과 대화하는 데 쓰입니다. 최근 열풍의 주역입니다.

말을 하니까 사람처럼 생각도 하는 듯 보입니다. 컴퓨터다 보니 아는 게 많습니다. 인터넷의 정보로 학습했으니 먼 나라 지식도, 아주 옛날 지식도 잘 알고 있습니다.

컴퓨터다 보니까 코딩을 시켜봅니다. 엇? 잘합니다. 갑자기 IT 산업이 활발해집니다.

컴퓨터다 보니 지치지 않습니다. 1년 365일 똑같은 열정으로 일할 수 있습니다.

사람 대신 써볼까? 이런 생각이 듭니다.

여기까지가 지난해 많은 기업에게 일어난 변화입니다. 그런데 문제가 있습니다.

“우리 회사 데이터를 ChatGPT에 줄 수 있나?”

당연히 안 됩니다. 삼성전자의 반도체 정보, 서울병원 환자 진료기록 이런 걸 미국으로 보낼 수 없습니다.

군사시설 같은 국가 보안 정보는 더욱 그렇습니다. 이런 정보는 엄격하게 통제된 환경에서 필요한 사람에게만 딱 노출되어야 합니다.

결국 자사 내에 설치가능한 제품을 찾게 됩니다.

이게 ChatGPT만큼 유능하기를 바랍니다. 그러면서 기업이 잘 통제할 수 있기를 바랍니다.

그런데 이게 진짜 될까요? 어떻게 해야 할까요?

이런 변화가 작년과 올해 상반기에 일어났던 변화였습니다.

작년에는 구글과 페이스북이 ChatGPT를 바짝 추격하는 모습이었습니다. 기업들은 관망하는 분위기였죠. 하지만 윈도우에 “코파일럿(Copilot)”이 붙자 분위기가 달라집니다. 써보니까 좋거든요.

설치형 버전? 랭체인(Langchain), 올라마(Ollama)를 이용해 구현할 수 있음을 알게 되자, 개발자 시장이 먼저 반응합니다. 아웃소싱 시장도 이 변화를 벗어날 수 없죠.

AI는 무엇을 대체하고 있나?

AI는 “사람”을 대체하기 위해 만들어졌습니다. 사람이 있어야 하는데 있을 수 없는 상황에서 말이죠. 대표적인 사례가 전쟁과 우주산업입니다. 제2차 세계대전이 기폭제가 되었죠.

처음에 AI는 공장 로봇으로 단순 반복 작업을 했습니다. 사람의 “노동력”을 대체했죠.

사람은 작업을 장시간 반복하면 집중력이 떨어져서 오류가 높아집니다. 로봇은 그렇지 않죠. 매우 복잡한 일까지 정확하게 해냅니다.

이제 AI는 자율주행을 합니다. “지적 능력을 바탕으로 한 노동활동”이죠. 트럭 기사, 택시 기사를 대체하려고 합니다. 꽤 높은 수준까지 올라왔죠.

최근의 ChatGPT는 사람 흉내를 냅니다. “창의력”까지 말이죠. 단순히 베끼는 것이 아니라 재창작을 합니다. 빠른 처리 속도와 방대한 데이터를 가지고 말이죠. 무서운 건 망가질지언정 지치지 않는다는 점입니다. 사람보다 월등히 나은 부분이죠.

그동안 “지능”은 사람의 전유물이었습니다. 하지만, 이젠 아닙니다.

ChatGPT 같은 초대규모언어모델(이하 LLM) 은 사람의 “지적 능력”을 꽤 많이 대체합니다.

완벽한 대체가 가능할까요? 지금은 아닙니다. 기술을 넘어 풀어야 할 숙제가 많죠.

지금은 대체자보다는 강력한 보조자 역할을 합니다. 코파일럿과 함께 코딩을 해보면 “척척박사” 한 명을 옆에 두고 일하는 느낌입니다. 아는 것도 많고 정확하기도 하죠. 물론 확인과 결정은 내가 해야 합니다.

“기업”은 어떤 선택을 하고 있나?

기업은 딱 두 가지 상황에 관심이 있습니다. 매출을 올리거나, 비용을 줄이거나!

AI에 “로봇”을 붙이면 “지적 노동력”이 완성됩니다. 이런 특징을 갖게 되죠.

(1) 특정 수준의 지적 능력으로 노동을 한다.
(2) 사람이라고 해도 믿을 만큼 지적 능력이 높다.
(3) 감정 기복이 없고 지치지도 않는다.
(4) 통제가 가능하며 비용을 예측할 수 있다.

사람들은 (1),(2)번에 주목했습니다. 하지만 기업들은 (3),(4)번에 주목했습니다. “설비”처럼 투자할 수 있으니까요. AI로 사람을 대체하는 건 이릅니다. 쉽게 결정할 수 없죠.

단기적으로는 직원들의 업무능력 향상에 집중합니다. 조금 더 빠르게, 조금 더 많이, 조금 더 창의적인 결과를 만들 수 있게 해주죠.

그런데 이건 SI 프로젝트에 적용될 만한 건 아닙니다. 업무의 양과 내용이 계약으로 정해져 있기 때문에 을이 굳이 더 창의적일 이유는 없죠.

대기업들은 발 빠르게 움직이고 있습니다. DevOps를 개량하거나, 사내 코파일럿을 만들고 있죠.

하지만, 대부분의 기업은 아직 공부하고 있습니다. 어떻게 움직여야 할지 말이죠.

새로운 제품을 만드는 건 어떨까요?

그런데 이런 건 아웃소싱할 것들이 아닙니다. 그 기업이 독창적으로 만들어야 하죠.

초기라서 자체 개발 역량을 보유한 기업들이 먼저 움직입니다. 그 사례가 후발 기업에 전파되고, 그 다음에 “아웃소싱” 시장이 따라가겠죠.

다만 기업시장은 규제가 지뢰밭이어서 생각보다 시간이 걸릴 듯 싶습니다.

SI 시장의 무엇이 대체될까?

갑이 아웃소싱을 하는 이유는 뭘까요? 전문 역량을 조달하는 겁니다. 자기 회사에 없는 전문 지식과 경험을 사 오는 거죠. 솔루션을 갑에게 맞게 조정하는 건 필수입니다. 운영 가능한 상태까지 만들어서 납품받는 게 기본이죠.

그래서 SI 기업의 핵심 자산은 “전문 역량”입니다. (1) 시스템을 만드는 것과 (2) 맞추어 주는 능력이죠. 그러려면 레거시를 알아야 합니다. 새로운 시스템에 대해서도 잘 알아야 하고요.

새로운 시스템이 옛날 시스템과 공존하려면 꽤 많은 숙제가 생깁니다. 그 숙제를 정리한 게 “요구사항”이죠. 프로젝트는 그걸 소프트웨어로 변환하는 과정입니다. 언어적으로 보면 시스템을 만든다는 건, 커다란 변환・번역 과정이기도 합니다.

그런데 이런 변환・번역 업무는 LLM이 가장 잘할 수 있는 일입니다. AI가 코딩에서 두각을 나타내는 이유이기도 하죠.

하지만 의지를 가지는 것, 방향을 정하는 것은 사람이 해야 합니다. 책임과 권한의 문제거든요. AI가 좋은 답을 해줘도 선택하지 않을 수 있습니다.

단기적으로는 이런 상황이 예상됩니다.

AI가 도입된다고 해서 목표 시스템의 규모가 줄진 않습니다. 코파일럿 때문에 개발 속도가 빨라질 뿐이죠. 초급 개발자 없이 시니어 개발자 몇 명이 뚝딱하고 만들 수 있습니다. 프로젝트 기간이 줄어들겠죠.

짧은 기간에 적은 사람이 들어와서 일을 하니, 갑은 전체 프로젝트 비용을 낮출 수도 있습니다.

하지만 요구사항이 줄어든 건 아닙니다. 한 명이 책임져야 할 코드양은 늘어나죠. 100개 개발하던 걸 300, 400개 개발해야 하니까요. 결국 필요한 기능이 다 만들어져 짜임새 있게 돌아가야 프로젝트가 종료됩니다.

짧은 기간에 적은 사람이 투입되면서, 더 많은 책임량을 지는데 보상은 낮아진다면, SI를 하려는 기업들이 있을까요? 아마 차츰 사라져 버릴 겁니다.

코파일럿을 도입한 혜택을 SI 기업이 공유받을 수 없다면 아웃소싱 시장은 깨어집니다. 혜택을 공유받을 수 있도록 계약이 바뀌어야겠죠. 일반 기업은 비교적 유연하게 대응할 수 있습니다. 반면 공공분야는 그렇지 않죠. 규정이나 규제를 고쳐야 해서 시간이 많이 걸릴 겁니다.

운영 업무에서는 어떨까요?

장애를 감시하는데 AI는 탁월한 역할을 합니다. 하지만, 운영 업무의 병목은 개발이 아닙니다. 회의와 소통, 의사결정 과정이죠. 그러니 변화가 급진적이기보다는 단계적으로 발생할 겁니다.

개발 속도는 빨라지고 개발 생산성도 높아질 겁니다. 하지만, 이 질문에 쉽게 대답할 수 없습니다.

“그래서 SI 프로젝트의 프로세스는 어떻게 바뀌어야 하죠?”

AI 도구를 프로젝트 현장에서 사용하려면 갑과 을의 적절한 합의가 필요합니다. 특히 보안 데이터를 학습시켜야 하는 민감한 프로젝트 환경이라면 말이죠.

“AI 기반 개발방법론” 같은 게 나와야 합니다. 시간이 적지 않게 걸리겠죠.

단기적으로 산업적 특수성과 책임 소재 때문에, IT 아웃소싱 시장의 틀이 크게 바뀌진 않을 겁니다.

다만 AI 도구들을 활발하게 이용함으로써 프로젝트 현장이 좀 더 역동적이고 빨라지겠죠.

기업의 아웃소싱 전략은 어떻게 변할까?

<출처: DXC, 아웃소싱 2.0을 위한 조직구조>

단순 반복 작업은 AI 자동화를 시키고, 비 중심 업무는 아웃소싱을 한다. “단순 고반복 업무”, “기술부채” 같은 것들이 대상이 된다.
“복잡한 데이터”, “부서 간 정보 장벽” 같은 것들은 AI를 이용해 통합하고, 데이터를 기반으로 의사결정을 한다. 우리 기업의 차별화와 사업 방향성에 대해서 더 많이 집중한다.

“AI가 아웃소싱을 책임진다. - 당신의 차세대 파트너인 AI를 위한 전략적 프레임워크 그리기” 이 글은 갑이 AI를 어떻게 활용해야 할지, 조직이 어떻게 변해야 하는지를 그렸습니다.

DXC Technology의 전략담당이사인 Carl Kinson이 올린 글입니다.

DXC는 컨설팅, 시스템 구축, IT 아웃소싱까지 모두 제공하는 글로벌 IT 서비스 회사입니다.

2017년 HP의 기업사업 부문이 분리되면서 만들어졌고, 첫해 매출이 33조 원, 현재 직원 수가 13만 명 정도 되는 큰 기업입니다.

이런 기업의 전략담당이사가 “청사진”을 그려주는 건 자기네 회사로부터 풀 서비스를 받으라고 설득하기 위해서입니다. 고수준의 기술영업인 셈이죠. 2024년 2월 올린 글이기 때문에, 글로벌 기업들의 AI 진도를 짐작할 수 있습니다.

전체 그림은 AI 프론티어들이 말하는 것과 비슷합니다. AI를 이용해 기업 내 비효율적인 부분을 제거하고, 조직을 좀 더 작고 가볍게 줄여 핵심 업무에만 집중하라는 겁니다.

달콤한 말입니다. 저도 큰 방향에는 동의합니다. 하지만, 현실적으로 얼마나 오래 걸릴지, 돈을 얼마나 투자해야 할지는 모르겠네요. “금융권 차세대 프로젝트” 같은 붐이 또 한 번 올 것만 같습니다.

작은 기업은 나름대로 변화할 겁니다. 아웃소싱 스타일도 많이 바뀔 듯합니다.

하지만 역시 아직은 시작입니다. 대기업들은 자사 직원을 교육시키는데 시간을 쓰고 있습니다. 우선 내부에 리더그룹을 만들어야 하니까요.

해외의 아웃소싱 시장은 어떨까?

조금 작게 바라봅니다. 해외의 아웃소싱 시장은 어떻게 변하고 있을까요?

기사들을 찾아보니 국내와 크게 다르지 않습니다. 비교적 잘 정리된 글을 요약해 봅니다.

2023년 9월. 포브스지에 실린 글, AI는 IT 아웃소싱에 어떤 영향을 미치고 있는가?(2023.9.7, 포브스, 플라멘 체코프)입니다.

아웃소싱 시장의 변화

1. 노동시장의 변화

ChatGPT 등으로 코딩은 훨씬 더 구조화되고 편리해졌다. “AI를 사용할까 말까?” 이미 이런 고민은 하지 않는다. “어떻게 전체 프로세스에 AI를 적용할까?” 이런 고민을 하고 있다.

2. 사람에 대한 의존성 제거

회사 내의 지식(기술문서, 프로세스 등)이 사람들에게만 쌓이지 않는다. 이젠 시스템에도 쌓인다. 아웃소싱 기업들이 “지식 보유자”로서의 위치를 잃게 된다. 반면 기회도 있다. 적재적소에 지식을 잘 활용할 수 있다면 오히려 더 큰 생산성을 얻을 수 있다. 특정 분야를 전문화하는 게 도움이 된다.

3. 고객의 높아진 기대치

기업 고객의 64%가 이런 기대를 한다. “앞으로는 생산성과 품질이 높아지고 속도까지 빨라질 거다.” 이제 아웃소싱 회사도 AI를 활용하지 못한다면 고객의 기대를 채울 수 없다.

4. 예산 재배치

기업들은 점점 더 단순 작업을 발주하지 않는다. AI를 도입해서 자동화하는 데 투자할 거다. 2030년까지 이 시장의 성장률은 연간 37%로 예상된다.

5. 업무의 재구성

2022년 일반 기업의 39%가 소프트웨어 개발자를, 35%가 데이터 엔지니어를 고용했다. 채용 시장이 AI 직무를 중심으로 움직였다. 모든 업무에 AI를 활용하는 방향으로 바뀌고 있다.

SI 기업들을 위한 조언

1. 비즈니스를 다시 상상한다

회사의 납품 프로세스에 AI를 적용해 본다. AI는 복잡한 의사결정에 통찰력을 제공한다. 회사를 지탱하는 중간관리자들이 통찰력을 가질 수 있게 해준다. 서비스, 고객에만 관심을 가지지 말고, 회사 내 프로세스를 바꾸어 본다.

2. AI 로드맵을 그린다

회사 업무 전체에 AI를 도입하고 변화를 그려본다. AI로 무엇을 할 것인가?

3. 더 높은 부가가치에 집중한다

아키텍처 분야는 여전히 인간 중심적이다. 컨설팅은 AI로 대체될 가능성이 없다.

제품관리자, 비즈니스 분석가, 컨설턴트 등은 비즈니스에 더 큰 가치를 만들어준다.

AI는 “도메인 특성”을 거의 이해하지 못한다. 고객 사업을 이해하는 데 집중하고, 고객과의 커뮤니케이션에 더 많은 시간을 쓰라.

4. 인재 가치를 극대화하고, 인재 전략을 혁신한다

AI로 대체되기 힘든 분야의 사람들을 기른다. 아웃소싱은 생각보다 전문적이고 복잡한 일이다.

시장의 요구도 점점 더 전문화될 것이다. 이젠 제너럴리스트보다 스페셜리스트가 유리하다.

여러 명의 주니어 개발자보다 숙련된 시니어를 쓰는 게 더 높은 품질과 차별화된 서비스를 제공하는 데 유리하다. 특정 분야의 숙련 인력이 필요할 땐 그런 인력을 잠시라도 고용하라.

요약하자면

결국, AI가 할 수 없는 일을 해야 한다. 도메인 지식을 잘 활용하고, 고객의 문제에 집중해라. 이런 이야기들입니다. 특별히 대단한 이야기는 없는 것 같지만, 분명히 곱씹어 봐야 할 이야기입니다.

SI 기업은 어떻게 해야 할까?

기업에는 오래된 규제와 고유한 문화가 섞여 있습니다. 이것들이 기업마다 달라서 시장이 넓고 다양합니다.

AI가 아무리 좋다고 해도 갑자기 레거시 전부를 한 번에 바꿀 순 없습니다. 부담이 적은 외곽지역부터 바뀌겠죠. AI가 침투하는 데는 시간이 걸릴 겁니다.

하지만, 장기적으로는 많이 바뀔 겁니다. AI를 쓸만한 곳이 너무 많거든요. 코드를 잘 짜주기도 하고, 에러도 너무 잘 잡아줍니다. 아무거나 물어봐도 척척 답변을 해줘 결정장애를 벗어나는 데 도움이 됩니다.

이런 때 SI 기업들은 어떤 준비를 해야 할까요? 역시 흔한 이야기이겠지만 정리해 보았습니다.

AI를 인정하고 받아들이자

간혹 아직도 AI를 외면하는 분들이 있습니다. ChatGPT 나 코파일럿을 제대로 겪어보지 못한 거죠.

하지만, AI 시대는 무시해도 옵니다. 나보다 똑똑한 사람, 나보다 잘난 사람들이 AI를 써서 앞서 나갈 거거든요. 우리나라에서 못하면 다른 나라에선 할 겁니다. 외면하고 무시할수록 점점 더 경쟁에서 멀어지게 됩니다.

코딩할 때 “혹시…?” 하는 부분까지 물어보고 써보세요. 당분간은 ChatGPT나 코파일럿을 잘 쓰는 것만으로도 경쟁력이 생길 겁니다.

참고로, 작은 회사라면 ChatGPT 엔진 자체를 만들지는 않습니다. 그건 이미 OpenAI가 했습니다. SI 기업은 AI를 이용해 고객의 문제를 풀어주는 겁니다.

프로젝트 과정을 자산화하자

분석 - 설계 - 개발 - 테스트까지의 전 과정에 AI를 이용하고, 그 프로세스를 자산화합니다. ChatGPT를 어떻게 활용할지, 검증하고 체크할 때 AI를 어떻게 활용할지 등등을 적어서 정리합니다. SQL injection, 방화벽 정보, 해킹 취약점 등도 물어봅니다.

이렇게 하나씩 프로젝트 수행 과정 전체를 “with AI”로 바꿉니다. 효율적으로 일할 수 있게끔 말이죠.

이 과정은 고객도 궁금해합니다. 나중에는 누구나 다 아는 평범한 정보가 될 수 있습니다.

하지만, 지금은 아닙니다. 발 빠르게 움직이는 게 도움이 될 겁니다.

우리 회사만의 데이터를 쌓자

기업용 AI는 ChatGPT처럼 방대한 양의 학습이 필요 없을 수 있습니다. “신한은행 챗봇”이 국방정보를 잘 알고 있을 이유는 없습니다.

AI는 학습 데이터에 따라 다른 제품이 됩니다. 그래서 특정 분야를 학습한 AI가 회사의 자산이 될 수 있습니다.

물론 고객사 데이터를 쓸 수는 없습니다. 공개된 데이터를 모읍니다. 부동산 정보랑 법률 정보 같은 겁니다. 과학계에 나온 논문 정보도 좋습니다. 이런 정보만으로도 AI 역량을 충분히 연습해 보고 드러낼 수 있습니다.

SI 기업들도 이제는 “데이터”를 욕심내야 합니다.

AI를 제품으로 패키징하자

특정분야를 학습한 AI는 독립된 상품 가치를 가집니다. 세계 최고 수준의 1등짜리는 아니더라도, 중소기업에 필요한 5등짜리는 될 수 있습니다.

기업시장은 1등 제품만 팔리는 곳이 아닙니다. 우리 회사에 맞는 제품이 팔리는 시장입니다.

패키징하고 팸플릿을 만드세요. 홈페이지에 올리고 발표를 합니다. 고객이 왜 우리 회사를 찾아와야 하는지를 충분히 알게 합니다.

도메인 전문가

“은행 시스템에 대해 이야기 해줘”

AI가 학습된 데이터를 가지고 “블라블라" 대답을 해줍니다.

그런데 내가 모르겠습니다. “코어뱅킹”이 뭔지 “지급결제”가 뭔지 잘 모르겠습니다.

아니, 알긴 알겠는데 모르겠습니다. 그러니까 “지급결제”에서 어떤 일들이 내부적으로 일어나는지 모르겠다는 뜻입니다.

이건 도메인 지식이 부족한 겁니다. IT 서비스란 기업 고객의 문제를 풀어주는 사업입니다.

AI가 쉽게 설명을 해줘도 내가 알아들을 수 없다면, AI가 아무리 좋아도 있으나 마나입니다.

그 산업만의 특수성을 모른다면 고객의 고민을 공감할 수 없습니다. 공감할 수 없다면 문제를 인식할 수도 없죠. AI와 대화할 정도로 도메인 전문성이 없다면 모든 게 진행되지 않습니다. 결정할 수 없으니까요.

도메인 전문가는 AI에 대체되는 사람이 아닙니다. AI를 다루는 사람이죠.

특정 도메인에 진입하고자 한다면, 도메인 전문가를 모으고 길러야 합니다.

마치며

장기적으로 아웃소싱 시장이 많이 바뀔 겁니다. 고객사들이 AI와 관련된 “제안요청서”를 많이 띄울 거거든요.

새로운 제품을 만들 때, 특정 업무를 자동화할 때, AI를 사용할 수밖에 없도록 아웃소싱할 겁니다. SI 시장이 엄청 커질 수도 있습니다.

혹은 반대일 수도 있습니다. 인하우스 개발로 인해 SI 시장은 작아지고 솔루션 분야가 커질 수도 있습니다.

미래는 알 수 없습니다. 다만 눈에 보이는 변화들에 발맞춰 갈 뿐이죠.

SI 기업들도 이제 능동적으로 AI의 변화를 읽고 움직일 때입니다. 돈이 될 수 있는지 이런저런 시도를 해보아야죠. 작은 기업들을 응원합니다.

※ Langchain, Ollama, BERT 등의 키워드를 검색해보세요. 많은 걸 찾을 수 있을 겁니다.

]]>

4년 차 개발자의 SI 대기업 이직기 ② 면접과 연봉 협상, 그리고 최종 합격

이전 글 4년 차 개발자의 SI 대기업 이직기 ① 이직 결심부터 코딩테스트까지에서는 이직 결심을 시작으로 자기소개서와 코딩테스트를 준비하는 과정을 다루었습니다. 이번 글에서는 서류에 합격한 다음 과정, 면접과 연봉 협상을 공유해 보겠습니다. 나아가 경력직으로 입사해 느낀 장단점 역시 함께 얘기해 보고자 합니다. 시리즈로 이루어진 글이라 첫 번째 글을 보고 오시면 흐름을 이해하기에 더 좋습니다.

<출처: 프리픽>

면접 준비하기

서류와 코딩테스트를 모두 통과하면 남은 관문은 면접입니다. 경력직 면접에서는 주로 어떤 프로젝트에 참여해서 무슨 업무를 진행했는지, 이를 중점적으로 확인하는 편입니다. 이전 회사에서 해온 업무를 보며 앞으로 입사해 투입될 프로젝트에서 필요한 작업을 할 수 있는지도 검증합니다. 또한, 일에 대해 성실한 태도를 가졌는지, 커뮤니케이션이 원활한 사람인지 역시 확인합니다.

경력직의 경우에는 면접 방식이 회사마다 다릅니다. 따라서 구글링 등으로 해당 회사의 경력 면접에서 어떤 질문이 나오는지 미리 확인하는 것이 큰 도움이 됩니다. 기술 면접을 위해서는 이전에 알고리즘 강의를 들으며 정리한 내용, 신입 공채 때 정리해 두었던 자료를 참고했습니다. 제가 몇 차례 이직 면접에 참여했을 때, 모든 회사에서 똑같이 받은 네 가지 질문 유형과 답변 팁을 정리해 보았습니다.

자주 나오는 질문 4가지와 답변 팁

1. 1분 자기소개

면접의 단골 질문인 1분 자기소개는 경력직 면접에서도 그대로 나왔습니다. 제 경우, 신입 면접을 볼 때는 1분 자기소개에 인성과 기술력을 반씩 담아 어필했는데요. 이번 경력직 면접에서는 경험만을 담았습니다. 다음과 같이 가장 말하고 싶은 두 가지 경험을 골라 소개했습니다.

“안녕하십니까? ㅇㅇ회사 ㅇㅇ직무에 지원한 지원자 ㅇㅇㅇ입니다. 저는 백앤드 개발 경험과 물류에 대한 도메인 지식을 가지고 있습니다. A 프로젝트에서는 JAVA를 사용한 백앤드 개발을 맡아 C 모듈의 개발을 진행했습니다. B 프로젝트에서는 SM 업무를 진행하며 물류 도메인 지식을 쌓았습니다.”

이처럼 처음에 두괄식으로 각 프로젝트를 요약해 설명하고, 곧이어 프로젝트에서 맡은 역할과 성과를 상세하게 풀어내는 식으로 진행했습니다. 특히 1분 자기소개를 진행할 때는 대부분 면접관이 눈으로는 자기소개서를 읽으며 귀로만 소개를 듣습니다. 따라서 자신감 있는 어조와 당당한 태도로 말하는 것이 좋습니다.

2. 이직 사유

경력직 면접에서 면접관이 가장 먼저 궁금해하는 부분은 이직을 준비한 이유입니다. 합격한 다음에도 같은 이유로 이직을 알아볼 사람, 즉 얼마 다니지 않을 사람을 뽑으면 회사와 프로젝트에 큰 손해가 생기기 때문이죠.

이 질문에 답할 때는 이전 회사에 대한 험담보다는 무난한 대답을 추천합니다. 저는 규모가 더 큰 기업 중심으로 경력 면접을 본 만큼 직무 경험의 확대를 이유로 들었습니다. 더 큰 시스템에서 다양한 프로젝트를 경험하고 싶으며 이를 통해 성장하고 싶다는 점을 강조했습니다.

3. 지원 동기

앞서 질문에서 이직을 준비한 이유를 설명했다면, 지원 동기는 ‘이직할 회사가 왜 이곳이어야 하는지’ 면접관을 설득하는 단계입니다.

따라서 뉴스와 기업 정보 등 회사에 대한 조사가 필요합니다. 먼저 기업에 대한 이해도를 높인 다음에는 지원 동기와 채용 공고에 적힌 프로젝트를 연관 지어 대답하면 좋습니다. 이런 방식으로 저 역시 참여할 프로젝트에 관심이 많다는 것을 보여주는 동시에 지원한 회사를 많이 알고 있다는 점을 어필할 수 있었습니다.

4. 경력 사항

마지막은 경력 사항에 대한 질문입니다. 이에 대한 준비는 각 프로젝트에서 맡았던 역할을 정리하는 것으로 시작합니다. 기본 정리가 끝난 후에는 여러 프로젝트 가운데 ‘가장 큰 성과를 낸 사례’와 ‘어려움을 극복한 사례’를 정리해야 합니다. 이 두 가지는 참여한 프로젝트에 대한 이야기가 나오면 항상 꼬리표처럼 따라오는 내용입니다.

성과를 낸 사례를 말할 때는 단순히 결과만 얘기하기보다 그 결과를 이루기까지 기여한 과정을 중점으로 얘기하는 것이 좋습니다. 면접관들은 지원자가 우리 회사에 들어와서도 똑같이 기여하며 성과를 낼지 궁금해하기 때문입니다.

어려움을 극복한 사례는 ‘실패했던 경험’이나 ‘어려웠던 경험’을 말해달라는 질문과 같은 질문입니다. 이 질문 역시 실패한 경험 그 자체보다는 이를 극복해 나가는 과정에 초점을 맞추어야 합니다. 어려움을 통해 성장하고 느낀 바를 말하며, 다가올 고난도 충분히 극복할 수 있는 역량을 갖춘 사람이라는 점을 보여주어야 합니다.

더 나은 조건으로 연봉 협상하기

이제 기나긴 경력 채용 프로세스의 마지막 단계, 연봉 협상이 남았습니다. 1, 2차 면접에서 합격하면 최종 합격 안내와 함께 연봉 협상이 시작됩니다. 먼저 인사팀에서 현재 연봉을 증빙할 여러 서류를 보내달라고 요청할 겁니다. 일반적으로 현재 연봉을 바탕으로 제안 연봉이 정해지는데, 10~20% 정도 인상이 평균이었습니다.

연봉을 제안받았다면 그 연봉이 적정한 금액인지 생각해 보아야 합니다. 간혹 높은 연봉을 불러 입사가 취소되지는 않을지 걱정하며 기대보다 낮은 연봉을 수락하는 분들이 있습니다. 저는 회신 기한을 늘려서라도, 다양한 요인을 고려하며 여유롭게 생각해 볼 것을 추천합니다.

우선 해야 할 일은 제안받은 연봉이 이직할 회사에 다니는 비슷한 연차의 평균 연봉과 비슷한 수준인지 체크하는 것입니다. 이직할 회사에 아는 사람이 있다면 조언을 구해도 좋고 블라인드 등을 이용해 정보를 얻을 수도 있습니다. 인사팀이 제안한 연봉이 적정 수준보다 낮다고 판단한 경우에는 납득할 만한 근거를 들어 연봉 인상을 제안할 수 있습니다. 연봉 협상을 위한 메일의 예시를 준비해 봤습니다.

안녕하세요 인사팀 담당자님,

보내주신 오퍼레터 잘 받았습니다.

다만 제안해 주신 연봉이 생각한 것과 달라 제가 희망하는 연봉과 근거를 정리하였습니다.

희망 연봉은 다음과 같습니다.

기본급 xxxx 만 원

샤이닝보너스 xxx 만 원

복지성 포인트 xxx 만 원

: 희망 연봉 xxxx 만 원

근거는 다음과 같습니다.

작년도 평가에서 가장 높은 A등급을 받아 인센티브 xxxx 만 원을 받았습니다.
현 회사는 스톡옵션을 제공하여 xxxx 주를 받았습니다
얼마 전 최종 합격한 B 사에서 제안받은 연봉은 기본급 xxxx 만 원입니다. (증빙 가능)

대내외로 관심이 높은 A 프로젝트에서 앞으로의 과제가 많을 것으로 생각됩니다. 그동안의 프로젝트 경험으로 이 과제들을 해결해 나갈 것이며 연봉의 가치보다 더 많은 기여를 할 준비가 되어있음을 말씀드립니다. 노고에 감사드리며 긍정적인 검토와 회신을 기다리겠습니다.

만약 인사팀에서 제안을 받아들이면 새로운 오퍼레터가 옵니다. 반면 제안을 받아들이지 않는 경우에는 연봉 산정의 근거를 정리한 메일이 옵니다. 돈 이야기를 메일로 주고받는 것이 반가운 일은 아니지만, 그렇다고 아쉬운 연봉을 수락하면 이직 후에도 동기 부여가 떨어질 수 있습니다. 무엇보다 한 번 정해진 연봉을 베이스로 인상이 이뤄질 테니, 합의할 수 있는 부분까지 올려 입사하길 바랍니다.

입사 날짜 협의하기

연봉 협상이 끝나고 최종 입사가 확정되면 현재 다니는 회사에 퇴사를 알려야 합니다. 퇴사 면담을 진행하고, 퇴사 일자를 협의합니다. 인수인계 일정은 대강 3주 정도로 잡고 일자를 정하는 것이 좋습니다. 인수인계를 일정보다 빨리 끝낼 수 있다면 남은 연차를 모두 소진하며 휴식 기간을 더 확보할 수도 있습니다.

퇴사 일자를 정한 다음에는 입사 일을 협의해야 합니다. 이때는 어느 정도 휴식 기간을 가지고 입사할 수 있는 날짜를 정할 것을 추천하고 싶습니다. 이직을 준비하는 과정은 많이 지칩니다. 또 새로운 회사에 입사하면 모든 환경이 바뀌어 적응하는 데 힘들 것입니다. 물론 새로운 팀에서는 하루라도 빨리 오는 것을 원하겠지만, 인수인계나 프로젝트 마무리를 이유로 들어 잠깐의 휴식기를 가지는 것이 좋습니다. 잘 쉬어야 새로운 회사에 입사해서도 몰입해 일할 수 있기 때문이죠.

이직하면 생각만큼 좋을까?

여기까지 직접 겪으며 배운 경력직 이직 과정을 정리했습니다. 그렇다면 이처럼 힘들게 합격한 새로운 회사가 정말로 생각한 만큼 좋을까요? 이직을 고민하는 분들에게 도움이 될 수 있도록, 경력 사원으로 입사하고 업무를 진행하며 느낀 장단점을 정리해 보았습니다.

장점 1. 전 회사의 아쉬운 부분을 보완한 회사에 다닐 수 있다.

신입 사원 때는 회사의 어떤 점이 내게 중요한지 정확히 인지하기 어렵습니다. 그러나 회사 생활을 하다 보면 내가 무엇을 중요하게 생각하고, 무엇이 스트레스 요인이 되는지 직접 체감할 수 있습니다. 이렇게 정리한 우선순위를 기반으로 선택한 회사는 확실히 이전 회사보다 더 나은 환경일 확률이 높습니다.

스트레스를 받는 환경에서 벗어나는 일은 당장 업무에도 큰 도움을 주었습니다. 이직한 다음에는 ‘퇴근길을 또 어떻게 버티지…’ 같은 잡생각과 걱정이 없어졌습니다. 낮은 연봉으로 동기 부여를 주지 않는 환경에서도 벗어났습니다. 이는 곧 업무에 대한 몰입으로 이어졌습니다.

장점 2. 내가 원했던 프로젝트에 참여할 수 있다.

신입 공개 채용은 한 가지 직무에 여러 명을 뽑는 방식으로 진행됩니다. 곧 신입사원 교육 과정을 거쳐 팀이나 프로젝트가 정해지죠. 반면 경력직의 경우에는 채용 공고부터 프로젝트의 정보와 맡게 될 업무를 자세하게 알려줍니다. 따라서 단순히 주어진 업무를 하기보다 자기가 관심 있는 분야의 프로젝트나 업무를 할 수 있습니다.

단점 1. 실전으로 바로 투입한다.

신입에게는 소프트 랜딩을 위한 온보딩 기간이 주어집니다. 하지만 경력직의 경우에는 애초에 공고부터 당장 급한 프로젝트를 해결하기 위한 것이 대부분입니다. 그 때문에 친절하고 여유로운 교육을 기대하기 어렵습니다.

저 역시 입사한 다음, 필수 교육에 참여한다고 자리를 비웠을 때 “당장 해야 할 일이 많은데 자리를 비운 거냐?”라는 고객 문의를 받았습니다. 또 급하게 투입된 업무에, 사수도 없이 개발과 배포를 반복하며 하드랜딩을 경험했죠. 냉정한 사회의 쓴맛을 느낀 시간이었습니다.

단점 2. 공채 입사자의 특권

저처럼 신입사원 공채로 입사했다가 다른 회사의 경력직으로 입사하면 공채에 주어진 특권이 많다는 것을 느낄 수 있습니다. 공채 동기, 선후배로부터 얻는 소속감이 큰 데다 서로 끌어주고 밀어주는 경우도 다반사기 때문입니다.

공채의 경우, 비슷한 연차의 동료에게 모르는 것을 부담 없이 물어볼 수 있다는 것이 위안이 됩니다. 만약 연차가 쌓여 협업을 해야할 때는 안면이 없는 사람보다 더 많은 도움을 받을 수 있습니다. 같은 연차의 승진 대상자이더라도 경력직보다 공채 입사자가 먼저 승진하는 경우 역시 빈번하며, 공채 입사자보다 경력직의 연봉이 더 낮은 경우도 많았습니다. 경력 이직한 다른 친구는 회사에서 공채 사원들끼리만 친하게 지내고 경력직과 은근하게 편을 가른다며 어려움을 토로하기도 했습니다.

마치며

SI 기업의 경력 이직 과정은 보통 서류(포트폴리오, 경력 기술서, 자기소개서) - 코딩테스트(알고리즘) - 면접 - 연봉 협상 - 최종 합격 순으로 이어집니다. 프로세스가 긴 만큼 준비할 것도 많습니다. 물론 퇴근하고 모든 일을 준비하는 것이 힘들기는 하지만, 그렇다고 아예 못할 일은 아니라고 생각합니다. 처음에는 힘들어도 적응하면 요령이 생깁니다.

제가 이직 준비를 시작한 건 입사한 지 만 2년이 지났을 때였습니다. 그때는 어떤 회사에 지원해도 서류에서부터 불합격의 고배를 마셨습니다. 만 3년 차부터는 가끔 서류 합격 메일을 받기 시작했습니다. 이어 만 4년 차에 접어들며 현재 다니는 회사로부터 서류 합격 연락을 받았습니다. 비슷한 시기에 다른 SI 기업한테도 서류 합격 연락을 받았고 코딩테스트와 면접을 진행했습니다. 당시 지금 다니는 기업의 채용 프로세스가 조금 더 빨랐고, 이에 먼저 최종 합격 연락을 받았습니다. 다른 회사는 최종 면접만 남겨두고 있었죠. 그러나 경력 이직 준비 기간이 길었던 만큼 많이 지친 상태였습니다. 더는 이직을 준비하고 싶지 않다는 생각에 두 번째 회사는 면접에 불참하는 것으로 마무리했습니다.

이처럼 힘든 이직 준비 과정과 수많은 탈락의 고배에도 불구하고 이직은 메리트가 있습니다. 이전 직장을 다닐 때 저는 스트레스를 많이 받았습니다. 만약 스트레스의 요인이 회사를 바꿔 해결할 수 있는 문제라면 이직에 도전하는 것이 좋습니다. 변화를 겁내기보다는요. 이직 준비와 연봉 협상까지 쉬운 과정이 없었지만, 제 경험이 작은 도움이 되었으면 합니다. 이직을 결심한 이직러들 모두 꼭 원하는 회사에 들어가길 바라겠습니다.

]]>

[요즘IT 2024] 상반기 ‘개발’, ‘IT서비스’ 인기글 TOP 7

어느덧 2024년의 상반기가 훌쩍 지나갔습니다. 요즘IT는 “완전 럭키비키잖아!”를 외치며, 꽤 긍정적인 하루하루를 보낸 것 같은데요. 요즘IT 독자분들은 어떻게 보내셨나요?

IT업계는 작년에 이어 올해도 역시 ‘AI’로 핫합니다. ChatGPT와 제미나이의 경쟁 구도도 점점 심화되고 있고요. 누가 더 멀티모달을 잘 사용하는지, 누가 더 인간과 자연스럽게 소통할 수 있는지 열띤 기술 경쟁이 벌어지고 있습니다. 그 가운데 요즘IT는 올해도 IT 실무자들의 곁에서 함께 ‘성장’할 수 있는 이야기들을 다루고 있는데요. 이번에 준비한 시리즈에서는 2024년 1월부터 6월까지 카테고리별로 조회수가 가장 높았던 ‘인기 콘텐츠 TOP 7’을 살펴보고자 합니다.

올 상반기 ‘개발’, ‘IT서비스’ 카테고리에서는 어떤 글들이 사랑받았는지 다시 한번 돌아보면서, 남은 하반기도 힘차게 준비해 보아요!

*개발, IT서비스 글을 별도 구분하지 않고, 조회수에 따라 순위를 매겼습니다. 참고해 주세요!

요고의 한마디: 요즘 날씨 너무너무 더우니까 선크림 필수! 양산 필수! 손풍기 필수!

1. SI 기업 TOP 20를 알아보자

조회수: 57.4K / 좋아요: 39 / 스크랩: 49

SI, 이제는 IT 서비스 기업이라고 정의하는 게 자연스러운 시기인 듯합니다. 삼성SDS, LG CNS, SK C&C 그리고 네카라쿠배. 개발 관련 전공이거나 관련 커리어를 영위하고 있다면 일반적으로 생각하는 최고의 IT 서비스, 혹은 IT 회사라고 한 번씩 떠올려봤을 것입니다.

가장 매력적인 IT 서비스 회사는 어느 곳일까요? IT서비스 회사 순위는 블라인드나 기타 커뮤니티에서 자주 오르락내리락하는 주제입니다. 주로 매출액이나 영업이익 순으로들 이야기하는데, 저는 이번 글에서 조금 다른 관점으로 살펴보려고 합니다. 컨설팅, SI 및 현업 커리어를 두루 거치며 스스로 적용하고 있는 '매력적인 회사'를 선택하는 기준을 공유해보려는 것입니다. 이를 통해 SI로 취업, 이직을 고민하거나 재무지표만으로 순위가 언급되는 게 만족스럽지 않았던 IT서비스업계 관계자분들께 참고가 되었으면 좋겠습니다.

- 본문 내용 중 -

2. [SI산업 가이드북①] SI 회사는 가면 안되나요?

조회수: 43.0K / 좋아요: 91 / 스크랩: 63

SI 회사. 업계 사람들에겐 익숙하지만, 바깥세상의 사람들에겐 참 어렵습니다. 옛날과 지형이 꽤 달라졌는데, 누구 하나 이야기해 주는 사람이 없습니다. “블로그를 또 한 번 정리해야 하나?” 이런 고민을 하던 차에 “요즘IT”에 글을 올려 볼 기회가 되었습니다. 그래서 앞으로 SI 시장을 둘러싼 이야기를 해볼까 합니다.

먼저 이번 1회에서는 “SI회사는 가면 안 되나요?”라는 물음에 답해보려 합니다. 이에 답하기 위해 SI의 개념부터 한국의 IT 산업 지형을 개괄적으로 살펴보고, 네이버와 삼성SDS의 사례를 통해 SI와 비SI 시장의 업무 형태, 규모, 인력 규모의 차이 등을 이야기하려 합니다. 시장이 다르다 보니 직업적 가치관, 일하는 방식이 다릅니다. 하지만, 개발자의 일터라는 사실은 변하지 않죠. 저 또한 SI 시장에서 이룬 성장이 작지 않았다고 생각합니다.

제 이야기가 업계 전체를 대표하지는 않습니다. 산업현장에는 규칙이 없기 때문입니다. 다만 제가 알고 있는 현장의 모습을 이야기할 예정입니다. 동료, 후배들의 경험까지 빌릴 계획입니다.

- 본문 내용 중 -

3. 개발자 생산성 높여주는 무료 맥 앱 7가지

조회수: 41.2K / 좋아요: 42 / 스크랩: 82

맥(Mac)을 사용하다 보면 유용한 앱이 정말 많다는 걸 느낍니다. 유료로 구매해야 하는 앱도 있지만, 무료로 받을 수 있는 앱도 생각보다 많은데요. 그래서 종종 동료 개발자들과 요즘 잘 쓰고 있는 맥 앱을 공유하기도 합니다. 이번 글에서는 여러 개발자들에게 추천 받아 잘 사용하고 있는 앱, 개발자의 생산성을 높여준 맥 앱(Mac App) 7가지를 추천해 보려 합니다. 미리 알아두신 후 언제든 필요할 때 사용해 보세요.

- 본문 내용 중 -

4. 챗GPT-4o, 완전 럭키비키잖아

조회수: 37.8K / 좋아요: 27 / 스크랩: 24

OpenAI가 5월 13일(현지시간)에 발표한 챗GPT의 신규 버전이 업데이트되었는데, 현재 이에 대한 반응이 전 세계적으로 상당히 뜨겁습니다. 기존에도 생성형 AI 기술이 글, 이미지 창작이나 SORA 플랫폼을 이용한 비디오 생성에 사용되어 왔지만, 신규 버전은 보다 실시간으로 일반 사람과의 대화를 모방하는 듯한 환경을 반영하여 더욱 주목받고 있습니다. 특히, 이번 버전은 마블의 인기 캐릭터인 아이언맨이 인공지능 비서인 자비스와 대화하는 모습과 아주 유사한 환경까지 제공한다는 점에서 주목받고 있습니다. 이번 업데이트 세션에서 소개된 다양한 챗GPT-4o 활용 방안에 대해 함께 알아보겠습니다.

- 본문 내용 중 -

5. 개발조직은 왜 ‘돈 먹는 하마’로 보일까?

조회수: 26.2K / 좋아요: 18 / 스크랩: 25

"IT회사 CEO들 사이에는 “개발조직은 돈 먹는 하마”라는 이야기가 돌고 있어요. 도대체 개발팀들은 맨날 바쁘다, 밤샌다고 하는데 시스템 완성은 매번 늦어져요. 이유가 뭔지 모른 채 엄청난 개발조직 인건비를 지불하고 있어요."

소위 개발조직이 ‘돈 먹는 하마’로 보이는 현상이 과거 이들이 ‘전산실’이라 불리던 시절부터, 웹과 클라우드의 발전 그리고 AI 혁신이 세상을 시끄럽게 하는 요즘까지도 별 차이가 없다는 이야기입니다. 깊이 공감하는 문제이고, 이 글을 쓰게 된 계기이자 곧 주제이기도 합니다.

- 본문 내용 중 -

6. AI시대에 필요한 개발자, Product Engineer

조회수: 25.4K / 좋아요: 76 / 스크랩: 96

생성형 AI의 등장은 기존 개발 업무를 빠른 속도로 변화시키고 있습니다. 어느새 코파일럿(copilot)과 함께 코드를 짜고, 문제가 발생하면 스택오버플로(stack overflow)가 아닌 chatGPT에게 물어봅니다. 편하긴 하지만 쓸 때마다 위기감을 느끼곤 합니다. 원하는 것만 정확히 얘기해주면 맥락을 파악해서 정확한 비즈니스 로직을 몇 분 만에 만들어 냅니다. 이렇게 AI가 버그도 잡아주고 코드도 대신 짜주는 세상에서 우리 개발자들은 어떻게 살아남을 수 있을까요?

저는 프로덕트 중심으로 사고하고 개발하는 개발자가 끝까지 살아남을 수 있다고 생각합니다. 이번 글에서는 프로덕트 엔지니어가 무엇인지, 왜 프로덕트 엔지니어가 살아남는지 그 이유에 대해 한번 알아보겠습니다.

- 본문 내용 중 -

7. 개발자의 고민: 올해는 무엇을 만들어야 좋을까?

조회수: 23.4K / 좋아요: 55 / 스크랩: 101

2024년 새해가 밝았습니다. 저를 포함하여 많은 개발자 분들은 새해의 목표를 세우고 계실 것입니다. 특히 올해에는 ‘어떤 것’을 개발해볼까? 어떤 개발적인 ‘도전 과제’가 있을까?를 생각하시는 분들도 많을 것이라고 생각합니다. 이번 글에서는 ‘무엇’을 ‘어떤’ 기준으로 만들면 좋을지에 관해 힌트가 될 만한 요인을 소프트웨어 품질 표준에 따라 한번 살펴보고자 합니다.

- 본문 내용 중 -

*각 글의 조회수, 좋아요, 스크랩수는 본문 작성일자를 기준으로 측정했습니다.

[위시켓 AI 컨설팅 무료 이벤트]

]]>

1000억 ‘대형 프로젝트’의 진행 방정식

[IT 입문자를 위한 SI 산업 가이드북①] SI 회사는 가면 안되나요?

[IT 입문자를 위한 SI산업 가이드북②] 스타트업, SI를 해도 되나요?

[IT 입문자를 위한 SI 산업 가이드북③] 갑은 SI 프로젝트를 어떻게 만들까?

[IT 입문자를 위한 SI산업 가이드북④] SI에서 발전된 폭포수, 애자일 바로 알기

[IT 입문자를 위한 SI산업 가이드북⑤] SI 초보라면 이 8가지는 알고 하자

[IT 입문자를 위한 SI산업 가이드북⑥] 1억 넘는 ‘진짜 프로젝트’는 어떻게 할까?

[IT 입문자를 위한 SI 산업 가이드북⑦] ‘대형 프로젝트’는 어떻게 할까?

큰 프로젝트는 어떻게 진행되는지 살펴보겠습니다. 이 글에서 설명하고 싶은 건 “프로젝트 규모에 따른 진행방식의 차이”입니다. 작은 정보지만 SI 초보자나 기업들에 도움이 되면 좋겠습니다.

“대형 프로젝트”라면 10억 원, 100억 원, 1000억 원짜리 프로젝트를 말합니다. 역시 규모에 따라 진행 방식에 차이가 큽니다. 자세하게 말하면 복잡해지니까 요령껏 설명해 보겠습니다. 베테랑들은 이미 알고 있는 흔한 내용입니다. 다만 ‘경험 사다리’가 끊어져 초보자들은 잘 모르는 내용입니다.

큰 프로젝트는 큰 규모만큼 책임도 큽니다. 시스템이 크니까 이해관계자도 많습니다. 일하는 방식도 까다롭습니다. ‘규칙’을 지키면서도 ‘유연’해야 합니다. 뭔가 모순인 것 같죠?

그래서 큰 프로젝트는 작은 회사에 맡기지 않습니다. 개발자 100명짜리와 5명짜리 회사가 같을 수는 없으니까요. 100억짜리 프로젝트를 5명짜리 회사에 맡길 고객은 없습니다.

결과적으로 대형 프로젝트는 “사람이 많아 경직된 회사가 규칙을 지키면서도 유연하게 문제를 해결해야 하는 성격의 일”입니다. 뭔가 시작부터 답답해지죠?

대형 프로젝트, 얼마나 많을까?

SI 초보자는 궁금합니다. 큰 프로젝트에 가야 할지 말아야 할지. 그래서 이런 것들이 궁금합니다.

“대형 SI 프로젝트는 1년에 얼마나 발주될까?”, “얼마나 많은 회사들이 일을 할까?”, “거기서 일하는 개발자는 몇 명일까?”, “어떤 방식으로 일을 할까?” 등등.

장기적으로 보고 싶습니다. 이런 식의 통계가 있으면 좋을 것 같습니다.

“1년에 발주되는 프로젝트 중 발주금액 1,000억 원대 프로젝트는 X개, 100억 원대는 Y개, 10억 원 이하는 Z개.”

※ 발주금액 : “갑” 회사 입장에서는 “사업”이기 때문에 “사업비”라고 지칭하기도 합니다.

하지만 이런 통계는 없습니다. 삼성, LG 같은 일반기업이 자기네 회사 일을 정부에 보고하진 않거든요. 그래서 데이터가 공개된 곳을 뒤져봅니다. “나라장터”입니다. 공공부문 한정이라 상황이 다르겠지만 추정해 볼 수는 있죠.

※ 나라장터 : “조달청”이 운영하는 입찰사이트로 정부기관, 공공기관(학교, 협회 등)이 주로 이용하고 있습니다.

발주금액대별 프로젝트 건수 통계 <출처: 나라장터>

2023년 통계 중 “정보시스템 구축, 유지보수, 운영, 컨설팅” 등만 간추렸습니다.

“프로젝트 개수”를 봅니다. “SI 기업의 수주 기회”입니다. 연간 806건. 매주 15건씩 도전할 수 있군요. 1억 ~ 3억 원대가 49%를 차지합니다. 매주 7.5건씩 도전할 수 있습니다. 나머지는 10억 원대(12%)네요. 매주 1.8건씩 도전할 수 있습니다.

일반 기업체는 어떨까요?

체감상 일반 기업도 비슷합니다. 대부분 1억 원~2억 원대 규모로 주로 유지보수성 프로젝트들입니다. 정확한 통계는 없지만, 체감상 연간 발주량의 50%는 그런 업무로 추정됩니다.

SI 기업들의 먹거리는 대부분 1억 원~2억 원대의 프로젝트에서 나온다는 뜻입니다.

※ 참고 글: 1억 넘는 ‘진짜 프로젝트’는 어떻게 할까?

“발주금액 합계”는 SI 기업 입장에선 “수주금액”입니다. 대부분 “인건비”죠. 따라서 이를 환산해 보면 일자리 수를 추정할 수 있습니다. 전체 발주금액 가운데 10억 원 이상 프로젝트의 발주금액이 79% 나 됩니다. 개발자의 79%가 대형 프로젝트에 참여한다는 뜻이죠.

즉, 산업 관점에서 보면 개발자 일자리는 대형 프로젝트들이 만들고, SI 기업 매출은 작은 프로젝트들이 올리고 있습니다. 만일 누군가 “스타트업”을 한다면 작은 프로젝트를 잘하는 요령이 중요하겠고 “개인 프리랜서”로 일한다면 큰 프로젝트에서 잘하는 요령이 중요하겠네요.

제안서, 큰 프로젝트의 시작

발주금액이 1억을 넘어가면 절차가 복잡해집니다. 그래서 “제안요청서”로 시작을 합니다.

영어로 하면 Request For Proposal. 줄여서 RFP 라고 합니다. 고객이 만들고 싶은 걸 시시콜콜하게 적어 넣습니다. 일반기업이면 워드 파일, 공공기업이면 “한글”로 만듭니다.

보통 가이드를 따라 만드는데 일반기업이면 꼭 따라 하지 않아도 됩니다. 중요한 건 원하는 걸 잘 적어넣는 거니까요. 공공부문은 다릅니다. 규제가 있어서 엄격하게 따르는 편입니다.

그다음 홈페이지에 입찰 공고를 올립니다. 이런 걸 발주할 테니 답을 적어 오라는 거죠.

SI 기업들은 “제안요청서”를 보고 해결 방법을 적는데, 이를 “제안서”라고 합니다. 옛날에는 책처럼 만들었는데, 요즘은 그림책으로 만듭니다. 파워포인트를 쓰죠. 대형 프로젝트라면 400~500페이지 정도 됩니다. 1,000 페이지짜리를 만들 때도 있는데, 사업 규모에 따라 케바케입니다.

제안서 제출 직후에는 “평가발표”를 합니다. 예비 총책임자(프로젝트 관리자)가 직접 내용을 발표하고 평가자들이 질의응답을 합니다. 평가는 보통 이해당사자인 실무자들이 합니다. (공공기업은 프로세스가 좀 다릅니다.)

기술 점수와 가격 점수를 합산하는데, 평가 방법이 대부분 “제안요청서”에 나와 있습니다.

일반적으로 전 과정이 투명하게 진행됩니다. 규모가 큰 만큼 봐줄 여지가 전혀 없거든요. 평가자 입장에선 잘 안 되면 완전히 역적이 됩니다. 평생의 평판에 금이 가기도 하죠.

그런데 “제안요청서” 공고 기간이 보통 2~4주 정도입니다. 규모에 따라 바뀝니다. 짧게는 1주일만 공고하는 경우도 있죠.

※ 공공기업 공고 기간 : 7일, 10일, 14일, 30일, 45일 (금액에 따라 다름, 80억 원 이상 = 45일), 일반 기업은 자체 기준을 가지고 공지를 합니다.

하지만, 지나가던 SI 회사가 공고를 발견하고, 고객사의 고민을 제대로 이해한 다음, 우리 회사가 할 수 있겠구나라고 결심하고, 적합한 해결책을 찾아 제대로 된 제안서를 작성할 수 있는 시간으로는 절대적으로 부족합니다.

즉, 뜨내기 회사는 오지 마라는 거죠. 이미 그 고민을 알고 있고 해결할 방법이 있는 기업만 참여하라는 겁니다. 그렇다면 큰 기업들은 미리 그런 정보들을 알고 있다는 걸까요?

네, 고객은 “제안요청서”를 작성하기 전 시장조사차, 여러 기업을 미리 만납니다. 그래야 프로젝트 범위, 일정, 비용 등을 현실성 있게 세울 수 있거든요. SI 기업을 만나면 고객은 솔직하게 고민을 털어놓습니다. 해결해 줄 기업이 있어야 프로젝트 발주도 할 수 있거든요. 시스템을 만들어 주겠다는 곳이 없는데 사업을 벌일 수는 없겠죠.

즉, 제안요청서가 나오기 전 고객들은 대부분 여러 기업을 만난 상태입니다. 프로젝트를 둘러싼 고객의 고민들이 시장에 다 공유되어 있죠.

우리 회사는 이런 내용이 나올 줄 몰랐다고요? 이미 대상기업이 아니었던 겁니다. 아니면 대상기업임을 외부에 잘 알리고 있지 못한 겁니다.

물론, 고객이 기업 보안 때문에 일부 기업하고만 하는 경우도 있습니다. 이건 복잡한 이해관계가 섞여 있으므로 일반 대상인 이 글에서는 스킵합니다.

일반적으로 제안서는 계약서의 효력을 가집니다. 거짓말로 수주한 후 나중에 바꿀 수 없다는 뜻입니다. 그래서 진짜로 현실성 있게 씁니다. 두루뭉술하게 “열심히 할게요.”라고 쓰지도 않습니다. 그러면 진행 중에 덤터기 쓸 수도 있습니다. 일이란 게 하다 보면 자꾸 늘잖아요.

제안서는 아키텍트와 각 분야의 전문가들이 모여 씁니다. 짧은 제안 기간 내에 목표시스템까지 그리죠. 실제 개발만 하지 않을 뿐, 글과 그림으로는 개발을 다 끝냅니다.

즉, 대형 프로젝트는 결론을 미리 내어놓고 거기에 맞춰 구현하는 방식으로 진행됩니다. 기본적으로 “설계 후 시공”이라는 건설 방식을 따르죠.

들어가는 돈이 크다 보니 어쩔 수 없습니다. 실패는 용납하지 않습니다. 대형 프로젝트는 시작부터 성공을 담보해야 합니다. 어떻게 될지 모르는 “열린 결말”을 추구하는 경우는 없습니다.

그래서 대부분 비용을 줄이거나 프로세스를 효율화하는 프로젝트가 많습니다. 이미 투자 대비 비용 효과가 검증된 사안들이죠.

누가, 어떻게 프로젝트를 관리할까?

프로젝트 관리의 일반 구조 <출처: http://pgby.log>

프로젝트의 최종 결정권자는 PM(Project Manager)입니다. 프로젝트 기간만큼은 “CEO” 역할을 합니다. 프로젝트가 10억 짜리라면 10명~15명, 100억 짜리라면 100명~120명의 직원을 거느린 회사의 대표가 됩니다.

개발관리, 고객관리, 비용관리까지 모두 챙깁니다. 심지어는 협력사 직원들 월급까지 챙깁니다. 한 팀이 무너지면 다른 팀이 감당해야 하니까요.

그러다 보니 “프로젝트 관리”에는 위와 같은 내용이 몽땅 다 들어갑니다. 쉽게 말하면 성공하기 위한 모든 관리 활동을 하죠.

자세히 보면 스타트업에서 관리자가 하는 모든 일이기도 합니다. 물론 약간 딱딱한 버전이긴 하지만요. 어디나 일하는 건 똑같습니다.

팀 구성은 크게 “프로젝트 관리 조직”과 “프로젝트 수행 조직”(개발, 디자인)으로 나뉩니다. 프로젝트 관리 조직은 “PMO”(Project Management Office)와 “QAO”(Quality Assurance Office)로 나뉘고요.

“PMO”는 프로젝트가 잘 진행되도록 하는 팀입니다. 일정 관리, 문서 관리, 인력 관리 등을 하죠. “PM”(Project Manager)의 보조자 역할이자 직접적인 스태프 역할을 합니다.

소프트웨어 품질관리 프레임워크 <출처: https://thetest.kr>

“QAO”는 “소프트웨어 품질”을 관리합니다. 정확하게는 결과물이 만들어지는 과정을 통제하죠.

전통적인 산업에선 “제작 과정”을 잘 통제하면 좋은 “결과물”이 나온다고 믿습니다.

소프트웨어 사업도 어느 정도 맞긴 하지만, 특히 더 모두가 잘 해야 하고 제대로 해야 하죠.

2013년에 시작한 “국세청 차세대 시스템 구축 사업”이 있었습니다. 지금의 “홈택스”를 만든 대형 프로젝트였죠. 대한민국 직장인이 모두 여기서 연말정산을 하죠? 이 사업 때문에 편해진 겁니다.

이 프로젝트는 2,000억 원짜리였습니다. 통합 대상 시스템만 12개였고, 세부 기능이 1만 개를 넘었습니다. 관리해야 할 소스 파일 갯수가 5만 개를 넘었죠. 5만 개면 두어 명이 검수할 수 있는 상황이 아닙니다.

※ 12개 시스템 : 기준DB 정리, 탈세 혐의 분석시스템, 국세청 포털(일반인), 상담채널 통합, 납세자 CRM, 24x365 전자민원관리, 국세업무포털(직원용), 세정업무통합, 프로세스통합관리, 직원별 맞춤형 자동안내, IT 통합관리체계

절대로 “열린 결말”을 추구할 수 없는 프로젝트입니다. 세금이 2,000억 원이나 투입되었으니까요. 망했다면 한두 명 옷 벗는 일로 끝나지 않았을 겁니다. 가입자 수가 1,300만 명이 넘고 등록된 계정만 6,800만 개였습니다.

시스템이 잘 돌아가지 않으면 국민들에게도 금전 피해가 생깁니다. 민원이 빗발치고 피해보상도 해야 했죠.

실패를 가정할 수 없었습니다. 결론을 정해놓고 과정을 맞춰가야 했죠.

프로젝트 수행 : 폭포수 개발방법론

프로젝트 팀 구조 <출처: JBS.dev>

이제 현실적으로 “소스코드”를 생산해 내는 과정입니다. 업무 기능별로 팀을 쪼갭니다. 목표가 대부분 업무 자동화이기 때문에 “업무기능”이 곧 결과물입니다. 물론, 결과물이 다르면 팀을 나누는 기준도 달라집니다.

“전부 다 그런 거냐, 혹시 규칙이 있는 거냐?” 물을 수 있습니다. 아닙니다. 그런 경향이 있다는 거지 그게 규칙은 아닙니다.

폭포수 개발 방법론, 애자일 개발 방법론 <출처 : https://www.cuelogic.com/>

요즘은 흔하게 볼 수 있는 개발 방식의 비교입니다. 너무 많이 봐왔죠. 그런데 “폭포수(Waterfall) 방식”에 대한 상세한 설명을 흔하지 않습니다. 설명해 봅니다.

대형 프로젝트는 “결론”을 정해놓고 접근하는 방식입니다. “전체 결론”을, 그리고 “상세”를 채워나갑니다. 이미 알고 있는 길이니까 Try and Error를 반복할 필요는 없습니다. 그래서 단계별로 하나씩 프로젝트를 진행합니다.

이미 알고 있기 때문에, 설계를 아주 어마무시하게 상세하게 합니다. 이후 개발은 단순 코딩만 하면 되죠. 설계단계에서 모든 걸 다 예측하기 때문에 절대로 실패할 수가 없습니다.

정말 어려운 요건은 “솔루션” 구매로 해결합니다. SI 프로젝트는 신규 비즈니스를 “발명”하는 게 아니라, 맞춤복을 만드는 과정이니까요.

참고로, 남의 힘을 빌려 “발명”을 하면 원천기술을 뺏깁니다. 아무리 보안을 강조하고 법적 분쟁을 하더라도 결코 새는 기술을 막을 수 없습니다.

스타트업이 아웃소싱을 통해 “파일럿”을 만드는 이유는 “핵심 기능”이 아직 없기 때문입니다.

핵심 기능은 내부 직원을 고용해서 만드는 겁니다. 그건 SI로 만드는 게 아닙니다. 절대로, 네버!

폭포수 개발 방법론에 따른 개발 과정을 순서대로 봅시다.

1.요구사항 분석

가장 먼저 프로젝트 대상이 되는 요구사항들을 정리합니다. 프로젝트에서 해결해야 하는 목표입니다. 인터뷰를 하거나 기존 업무를 분석해서 엑셀로 정리합니다.

프로젝트 종료 시점에는 요구사항들과 매핑된 기능들이 모두 구현되어 있어야 합니다. 작동해야 하고, 검사까지 완료한 상태여야합니다.

눈에 보이지 않는 일들도 정리합니다. “비기능 요구사항”이라고 하죠.

즉, “요구사항 목록”은 해야 할 일의 목록입니다. 업무량을 측정할 때 기준이 되고 투입되어야 할 개발자 수를 짐작할 때 쓰입니다.

2. 설계

모든 기능을 담는 소프트웨어 구성, 하드웨어 구성을 설계합니다. 결제 기능을 포함한다면, 해킹이나 위변조가 불가능한 상황까지 고려합니다. 유지보수의 편의성 이런 것도 생각합니다.

3. 개발

기능을 나누어서 개발합니다. 팀을 업무별 파트로 나눕니다. “부가세 파트”, “연말정산 파트” 이렇게 말이죠. 파트의 책임자를 “파트 리더”라고 합니다.

이 파트는 업무적으로 하나의 완결성을 가집니다. 즉, 부가세 파트라면 부가세 처리 신청, 신고, 변경 등이 모두 개발 대상에 포함되죠.

4. 테스트

여기서 이야기하는 “테스트”란 일종의 통합 테스트입니다. 나누어 개발한 걸 다시 모아 합치죠. 그다음 그 기능을 테스트합니다. 점점 더 덩치를 키워가며 테스트하죠.

일반적으로 “통합테스트”라 함은 전체 시스템을 다 조립한 다음 진행하는 최종테스트를 말합니다. 실제 사용자들이 어떻게 사용할지 시나리오까지 정해놓고 이뤄집니다.

5. 오픈

사용자들이 실제로 사이트에 접속해서 써볼 수 있게 됩니다.

6. 인수인계

SI 프로젝트는 종료일에 철수해야 합니다. 그래서 고객사 운영팀에 인수인계를 하죠.

“이렇게 저렇게 쓰세요”라고 교육을 합니다. 사용된 솔루션의 계약서도 인계합니다.

이 단계가 끝나고 나면 고객으로부터 “최종인수확인서”라는 것에 사인을 받습니다.

이걸 받아야 고객사에 “프로젝트 결과물”이 “납품”된 겁니다.

7. 대금청구

“최종인수확인서”와 “세금계산서”를 재무팀에 제출하면 프로젝트 대금을 줍니다.

이제 돈을 받았으니, 정말 프로젝트가 끝난 겁니다.

잘 될까?

잘 안 됩니다. 우당탕탕합니다.

큰 프로젝트가 “결론”을 미리 정할 수밖에 없는 이유는 이해관계자가 많기 때문입니다.

금융, 정부 등 규제 산업은 일이 잘못되면 피해 규모가 큽니다. 관련 부서가 많다 보니 일 하나 하자면 정말로 이해관계가 복잡하게 얽히죠.

그래서 꼭 시작 전에 적정선을 합의합니다. 프로젝트 진행 중에 적정선이 달라지면 관계부서에 의견을 다시 물어야 합니다.

빨리 답이 올까요? 아닙니다. 어떤 때는 한없이 결정이 미루어지죠. 개발 일정도 한없이 길어집니다. 정말, 정말, 정말, 길어집니다.

그래서 이런 프로젝트는 절대로 “열린 결말”로 진행되지 않습니다. 범위와 내용까지 결론을 다 내린 상태에서 일을 시작하죠. 그래서 이런 이해관계를 미리 다 정리하고 나면 어느새 프로젝트는 대형화되어 있습니다.

촘촘히 계획을 세웠어도 모든 걸 다 예측할 수는 없습니다. 생각보다 큰 폭탄이 많이 터지죠.

하지만 정해진 결론 때문에 다른 과정을 선택하지 못합니다. 문제가 해결되지 않고 교착상태에 빠지죠.

적지 않은 경우 문제가 터질 때까지 교착상태가 해결되지 않습니다. 사고가 터진 후에야 수습하는 과정에서 교착상태가 풀립니다. 일단 사고가 터지면 각자의 이해관계가 희생되니까요.

규제 산업 분야는 또 다릅니다. 문제가 해결될 때까지 2~3년 동안 상황이 지속되죠.

그래서 스타트업은 절대 시작을 대형 프로젝트로 하지 않습니다. 그만한 돈도 없거니와 고객에게 첫인상을 “장애”, “오류”로 남길 수 없으니까요.

대형 프로젝트의 한계

대형 SI 프로젝트에는 몇 가지 문제가 있습니다.

실패를 허용하지 않는 분위기니까, 구성원 모두가 1인분의 몫을 해야 합니다. “초보자”가 설 자리가 없습니다. 당장 제 몫을 하기 힘드니까요. 그래서 신입사원이 유입되지 않습니다. 생태계가 말라가는 거죠.

구성원들의 동기도 약합니다. 프로젝트가 끝나면 결국 떠날 조직이거든요. 운영 중에 일어날 문제를 굳이 지금 꺼내어서 말할 필요는 없습니다. 살포시 묻어둡니다.

열정을 불태우는 건 자기 경력에 도움이 안 됩니다. 남의 회사니까요. 업무적으로도 금전적으로도 보상받을 길이 없습니다. 요구하는 만큼만 일하면 되죠.

PMO가 세세하게 일을 챙길 수밖에 없습니다. 일을 잘하기 위해 더 많은 일을 계획, 관리하게 되죠.

이상한 순환고리입니다. 100명짜리 중소기업인데 통제 수준은 높고 직원들 소속감은 없습니다. 주인도 안 보이고 한시적으로 일하는 손님들만 모인 조직이죠.

잘 될 리가 있을까요?

잘 안 됩니다. 우당탕탕합니다.

그럭저럭 일이 돌아갔던 시절도 있었습니다. 종이 장부 “회계”를 전산으로 바꾸던 시절이었죠. 한 번 정리된 “요구사항”은 프로젝트가 끝날 때까지 바뀌지 않았고, 중간에 등장하는 위험 요소도 없었습니다. 개발이 끝난 다음 손을 댈 일도 적었죠. 이미 만들어진 시스템도 현상 유지만 하면 되었습니다. 업무가 바뀌지 않았으니까요.

요즘은 아닙니다.

2015년에 오픈한 2,000억 원짜리 “국세청 차세대 시스템”은 어떻게 되었을까요?

연간 250억 원씩 운영 비용을 쓰는 “운영, 유지보수 프로젝트”가 되었습니다.

“우와, 250억 원이라니 단순 유지보수에 그런 큰 돈을 준단 말이야?” 아닙니다. 단순유지보수는 아니고 그만한 업무량이 있죠. 업무 변화에 맞게 시스템도 자꾸 뭔가 바뀌어야 합니다.

그런데 그 비용이면 아예 정직원을 뽑는 게 낫지 않을까?

물론 정부 조직 내에도 전문가들이 있긴 합니다. 하지만, 인력 수가 절대적으로 부족하죠.

잘 되게 하려면?

프로젝트의 “결론”은 정해져 있지만 “상황”은 그렇지 않습니다. 계속해서 변하죠.

“국세청 차세대 프로젝트”는 프로젝트 진행 중 세법 개정이 세 번이나 되었습니다. 개정 사항 중 무시할 수 없는 건 반영할 수밖에 없었죠.

프로젝트는 살아 움직이는 생명체입니다. 아무리 완벽하게 설계를 해도 “상황”은 “계획”을 뛰어넘죠. “이 문제를 해결해 줘”라고 한 다음 멈추어 있는 경우는 절대 없습니다.

시작 시점에 모든 요구사항을 반영했다 하더라도, 프로젝트 중반에는 항상 새로운 문제가 생깁니다. 기능을 정의하고 코드를 개발하는 순간에 말이죠. 시작할 땐 보이지 않았던 문제들입니다.

조치할 내용이 관계 부서에 불리할 때도 있습니다. 그럴 때는 커뮤니케이션을 새로 시작해야 하죠. 난감합니다.

본 프로젝트가 아직 완성되지도 않았는데 사이드 프로젝트가 런칭됩니다. 데이터 정리가 끝나지도 않았는데 데이터를 달라고도 하고요.

PMO는 이렇게 계속되는 갈등 상황을 해결해 가야 합니다.

결국 “고객”과 끊임없이 커뮤니케이션하는 수밖에 없죠. 최종적인 의사결정권자는 고객이거든요.

“폭포수 개발방법론”이라고 하지만 사실은 “애자일 방법론”입니다. 조금 빡셀뿐.

프로젝트 끝나고 나면 10년은 늙습니다. 멘탈도 멘탈이지만, 건강도 많이 나빠집니다.

애자일이냐 아니냐

“설계가 끝날 때까지 기다리세요.”

“개발이 안 끝나서 볼 수 없어요.”

“디자인이 안 나와서 보여줄 수 없어요.”

이런 대화가 오고 간다면, 다 망하는 프로젝트들입니다.

“설계가 된 부분까지만 보여드릴게요.”

“정리가 다 되진 않았지만, 이야기는 들려드릴 수 있어요.”

“전체적으로 그림이 정리되는 건 2주 후에나 가능해요.”

반면에 이건 되는 프로젝트들입니다.

차이가 뭘까요? 대화입니다.

“후자” 케이스는 문제 해결을 위해 대화의 장이 열리고 있음을 쉽게 알 수 있습니다.

그러다 보면 위험 요소를 미리 발견하고 제거하기도 합니다. 긴장감을 낮추죠. 그런데, 적지 않은 프로젝트가 “전자”처럼 일합니다. “개발방법론”을 방탄으로 사용하죠.

왜 그럴까요? 경험상 보고, 상황공유가 문제해결에 전혀 도움이 안 되었기 때문입니다. 보고를 해도 기능 개발에 필요한 시간을 얻어낼 수 없고, 문제 해결을 도와달라고 부탁할 곳도 없으니까, 커뮤니케이션을 포기하는 겁니다.

칸반이나 간트 차트로는 개발이 제대로 진행되고 있음을 확인할 수 없습니다. 내용을 알 수 없으니까요.

내용을 알려면 메인 아키텍트가 개발 중인 소스코드를 확인할 수 있어야 합니다.

의도한 대로 만들어지고 있는지 확인할 수 있는 유일한 방법이죠.

또, 의도한 대로 만들어지고 있는지 확인할 수 있는 유일한 사람이고요.

프로젝트가 커지면 책임자도 많아집니다. 혼자 다 확인할 수 없으니 QC(Quality Check) 담당자도 생기죠. 이런 과정은 대부분 복잡한 문서로 남깁니다. 보고 절차도 복잡해지죠.

하지만, 문제해결이 되지 않는다면 애자일이든 폭포수든 모두 다 공허한 외침입니다.

대형 프로젝트를 할 때 사람을 모으는 이유는, 해야 할 일을 100개로 잘라서 100명에게 나누어주기 위함이 아닙니다. 물론 그 목적도 있지만, 100명이 힘을 모아 하나의 돌멩이를 치워야 할 때도 있죠.

마치며

대형 프로젝트는 여러 가지 이유로 이렇게 어렵게 진행됩니다. 책임의 무게 때문이죠.

문서도 만들고 절차도 지켜야 합니다. 때문에 작은 기업들에게는 기회가 잘 오지 않죠.

작은 회사로선 큰 프로젝트를 경험해 볼 기회가 많지 않습니다. 다만 개인 개발자는 비교적 기회를 얻을 수 있습니다 특히 아키텍트나 리더로 올라서고 싶다면 공부할 수 있는 것들이 많습니다.

대형 프로젝트도 케바케가 많은데 이번 시리즈에선 이 정도로 갈무리할까 합니다.

다음 편은 좀 더 평범한 이야기에 집중해 보겠습니다.

]]>