[SI에서 성장하기] ④ 24년 차 대기업 개발자 출신이 말하는 요즘 SI 현장의 변화와 과제

13분

2024.04.16.

대형 SI 프로젝트에도 녹아드는 애자일

프로젝트 현장에서 스크럼을 하는 것을 보는 것은 낯선 풍경이 아닙니다. SI 프로젝트의 마일스톤(일정)은 매우 엄격하게 관리되지만, 지라(Jira)를 통해 티켓(Ticket)을 발행하고, PM은 칸반(Kanban)으로 전체 현황을 보고, 일 단위 스크럼은 백로그(Backlog)들이 제대로 처리되고 있지 않아서 문제가 될 것인지를 3분 동안 재빨리 애자일 프랙티스(Agile practice) 중에 하나를 써서 막내 개발자의 주도로 리뷰하곤 하는 것은 요즘 프로젝트에선 자주 볼 수 있는 모습입니다. 프로젝트 수행 방법에 따라 조금씩은 다르지만 슬랙(Slack)과 디스코드(Discord)로 협업하고, 피그마(Figma)를 열어두고 원 팀(One team)으로 일하는 것을 보면 누가 기획자고 개발자인지 알 수 없는 경우도 있습니다. 이런 현장이 등장한 것은 애자일(Agile)과 린(Lean)이 많은 SI 프로젝트에서 수행방법으로 점차 도입되고 있기 때문입니다.

스크럼은 2000년대 초반, XP와 린과 같은 애자일 방법론의 기초로 알려져 있었지만, 소규모 팀에서 사용하는 기법으로만 활용되었죠. SI현장에서 스크럼 시간은, PM이 기능 구현이 되지 않은 모듈, 부러진 일정으로 개발자들을 다그치는 현장이자 상급자 주도의 조회 시간이 되곤 했습니다. 지금은 많은 SI프로젝트 현장에서 애자일 방식으로 일하는 문화가 흉내내기가 아니라, 새로운 문화로서 정착되고 있습니다. 그뿐만이 아니라 여러 변화들이 있다 보니, 시스템 인테그레이션(SI, System Integration), 즉 기존에 ‘시스템 통합’을 의미하던 SI 업종을 이제 다른 의미의 SI, 시스템 이노베이션(System Innovation)이라는 방식으로 불러야 하지 않을까 싶어지는 곳들도 많아지고 있습니다.

‘엔터프라이즈 애자일(Enterprise Agile)’이라고 부르는 대형 프로젝트에서의 애자일 적용 방법들이 계속 등장하고 있기 때문입니다. 특히 SAFe(Scaled Agile Framework)라고 불리는 현실적인 수준의 방법들이 등장하면서, 포츈 100대 기업의 70%가 애자일을 프로세스로 적용하고 있죠. 아쉽게도 해외 적용 사례들은 많지만, 국내 사례는 아직 많지 않습니다. 국내에서는 Scrum of Scrums(스크럼의 스크럼)이라는 스케일드 애자일(Scaled Agile) 방법이 적용된 곳들이 더 많이 눈에 띕니다. 이 방식은 작은 스크럼의 대표들이 모여 스크럼을 하는 방식으로 확장된 구조입니다. 이외에도 LeSS(Large-Scale Scrum) 같은 여러 방식이 있지만, 애자일 관련 내용은 다른 글을 통해 깊게 다뤄보도록 해볼게요. (이 얘기만 해도 하루 반나절은 될 테니까요.)

‘SI 현장에서 애자일을 적용한다는 것은 이상론이다’, ‘고객이 요구하는 문서화의 양만해도 엄청난데, Agile은 문서를 안 만들고 개발을 빨리하는 것이 아닌가?’라는 이야기를 하실지도 모르죠. 대규모 SI 현장에서 애자일을 적용하면서, 현실적인 고객의 요구사항에 대해 아래와 같이 절충안을 만들어 내기도 하고, 새로운 방법론으로 성공적인 결과를 도출해서 고객의 인식을 전환시키는 노력도 계속되고 있습니다.

필요한 문서는 만들기도 하고, Tool로 소통하고, 운영까지의 Iteration을 고민하기도 합니다. <출처: 작가>

애자일이 SI에 통할까? 애자일은 지속적인 개선이 핵심이고, 그것을 위한 자동화된 CI/CD와 개발환경, 이 모든 것들이 SI 수행 중에 준비되어 있어야 가능합니다. 디지털 트랜스포메이션(Digital Transformation)이나 AI기반 혁신을 고민하는 고객들의 눈높이를 맞추기 위한 필요충분조건으로, SI든 운영이든, 애자일이 기본 문화가 되어가고 있다는 거죠.

아직 많은 현장에서는 초기 계약수주 당시에 결정된 요구사항(RFP)에 대해 폭포수 모델(Waterfall)로 정해진 기능이 구현되었느냐를 따집니다. 하지만 글로벌 수준에서 경쟁하는 국내 고객들은 프로젝트도 애자일 방식으로 수행하고, 고객사 IT운영 인력에게 애자일로 일하는 방법도 교육해주기를 바랍니다. 프로젝트가 끝난 이후에도 애자일 방식으로 일할 수 있도록 ‘애자일 변화 교육’을 과제 수행 목록의 최상위에 첫 번째로 해달라는 요구도 늘어나고 있습니다.

민첩성, 품질성을 높이는 솔루션 기반 SI의 성장

집을 지을 때 현장에서 기둥 세우고, 바닥 다지면서 일하는 것이 아니라, 모듈화된 조립식 건물을 대부분 공장에서 만들고, 마지막에 현장에서 조립만 하는 것처럼 프로젝트가 진행되기도 합니다. 소프트웨어 분야에서도 특정 소프트웨어나 패키지를 고객에 맞게 구매해서 맞춤형으로 구축해주는 예전 방식보다 발전해서, SaaS(Software as a service) 형태로 클라우드 전환과 프로비저닝 등을 한 번에 처리할 수도 있게 되었습니다. 특히, 고객 회사의 사무실을 빌려서 일하는 것이 아니라, 대부분의 서비스는 개발자 회사에서 구축한 다음(Off-site 구축이라고 부릅니다), 릴리즈 단계에서 현장으로 투입되는 경우도 생겨나고 있습니다. 거기에 더해 SI 기업이 직접 SW를 개발해서, SI 현장에 들고 가는 경우도 많습니다.

SI 프로젝트의 특징은 대부분이 B2B, 기업 대상의 프로젝트가 많고, 기업의 사업영역(도메인)에서 새로운 경쟁력을 확보하고 앞서나가기 위해 이뤄지는 경우가 많죠. 그러다 보니 제조라면 MES와 공정관리, 물류라면 포워딩, 운송관리, 의료라면 EHR, 보험관리 등의 특화된 영역의 지식을 PM이 갖추고 있는 건 당연하고, 솔루션을 이미 갖추고 있는 회사가 경쟁력이 있죠. 그래서, SI업체 중에는 의료는 A사가, 국세청은 B사가, 금융은 C사가 잘한다는 평이 그냥 나오는 얘기는 아닙니다. 그렇게 한 분야에서 오랜 SI사업을 해오다 보면 역량이 쌓이게 되고, 그걸 서비스로 만들어서 누구나 사용하게 만들어보면 어떨까 하는 생각을 하게 되겠죠? 삼성SDS는 의료의 넥스메드 EHR이 있고, LG CNS는 공공 스마트시티의 시티허브(Cityhub), SK C&C는 AI투자관리 마켓 캐스터(Market Caster) 등의 다양한 솔루션을 내놓고 있습니다.

의료분야의 SI 프로젝트 수행 경험을 모아 SW 개발까지 이어지는 경우의 사례 <출처: 작가>

이런 과정은 SI 현장에서 신뢰성 높은 SW를 기반으로 신규 SI 프로젝트를 수행할 수 있고, 일명 ‘맨 땅에 헤딩’하듯 과제를 수행할 위험이 줄어들게 됩니다. 특히 의료분야 SI프로젝트는 초반 부실한 과제들이 많았지만, 이렇게 SI기업들이 자체 개발한 솔루션을 적용하거나, Cloud와 SaaS 기반 서비스를 활용하는 경우가 많아져서 투입된 개발자들이 기존 서비스를 클라우드와 MSA로 전환하여 시스템 성능을 향상시키는 등 더욱 고차원적이고 높은 수준의 일에 집중할 수 있습니다.

이런 과정을 통해 SI 현장에서 신뢰성 높은 SW를 기반으로 신규 SI 프로젝트를 수행할 수 있고, 일명 ‘맨땅에 헤딩’하듯 과제를 수행할 위험이 줄어들게 됩니다. 특히 의료분야 SI프로젝트는 초반 부실한 과제들이 많았지만, 이제는 이렇게 SI기업들이 자체 개발한 솔루션을 적용하거나, Cloud와 SaaS 기반 서비스를 활용하는 경우가 많아졌습니다. 그래서 투입된 개발자들이 기존 서비스를 클라우드와 MSA로 전환하여 시스템 성능을 향상시키는 등 더욱 고차원적이고 높은 수준의 일에 집중할 수 있습니다.

주 52시간 근무제, SI에도 ‘워라밸’의 밝은 빛이!

우리 회사의 PM과 아키텍트 분들에게 ‘요즘 SI 현장에서 가장 좋아진 게 뭔가요?’라고 여쭤보니, 모두 첫 째로 손꼽은 것이 바로 “주 52시간 근무의 영향으로 야근과 주말 근무가 줄어들고, 워라밸을 조금씩 찾게 된 것”이라고 입을 맞춘 듯 대답해주셨습니다. 예전에는 납기가 짧다 보니, 일정에 맞추기 위해 밤샘을 밥 먹듯이 했는데, 이제는 법으로 강제하다 보니 그렇게 일할 수가 없다는 거죠. 고객도 야근을 해서라도 기능을 수정하라는 요구를 무작정할 수 없습니다. 전에 밤샘해서 번갯불에 콩 볶듯이 만든 결과물보다, 워라밸 챙겨주면서 SI 프로젝트에 개발자들을 투입한 결과물이 오히려 훨씬 더 낫거나, 밤샘을 하지 않더라도 전체적으로 납기 일정을 비슷하게 준수할 수 있었던 경험을 하기도 했고요. 실제 많은 연구결과에서도 장시간 노동은 건강에 영향을 미쳐 일을 계속 할 수 없는 것 이외에도, 출근은 했지만 업무수행 능력이 저하된 상태가 계속된다는 것을 이미 증명하고 있습니다.

이러다 보니, SI 과제를 기획하는 고객 쪽에서도 그것을 감안해서 일정과 예산을 수립할 수밖에 없습니다. 실제로 주 52시간 근무는 ‘근로기준법’에서 원래부터 있던 조항인데, 일주일 중에 ‘주말’은 일하는 것이 아니니, 월~금(52시간) + 토/일(16시간)을 계산하여 일주일 동안 68시간을 근무시켜도 문제가 없다는 식으로 운영하고 있었던 겁니다.* 헌법재판소에서도 합헌이라고 판결한 ‘주 52시간 근무 상한제’에서는 자발적으로라도 주 52시간 이상은 근무할 수가 없어요. 자발적으로 일한다고 서명한 문서가 있다 해도 그게 강압인지 아닌지 알 수가 없기 때문입니다. 이렇게라도 강제하지 않았다면 아마 SI업계의 가장 암울한 부분은 사라지지 않았을 겁니다. 개인적으로 개발자를 소모품으로 취급하는 근로방식은 앞으로도 절대 악용되지 않도록 해야 한다고 생각해요. 이렇게 법으로 강제된 덕분에 대기업이 과제를 수주하고, 외주 업체에게 부당한 업무를 과도하게 하도급하는 나쁜 관행들도 줄어들게 되는 효과도 있으니까요.

*개정 전에는 ‘근로기준법’의 ‘근로시간’에서 일주일의 의미를 명확히 규정하지 않고 있어, 월요일부터 금요일까지 법정근로 주 40시간에 연장근로 12시간 근무, 즉 52시간 근무를 할 수 있고, 그에 더해 휴일 근로 16시간을 더 할 수 있다고 해석해 68시간을 근무할 수 있었다는 의미. 그러던 것이 2018년 3월 20일 법 개정으로, 일주일에 휴일이 포함된다고 규정하며, 법정근로 주 40시간과 연장근로 주 12시간만 근무하도록 제한한 것이다.

두 번째로 좋아진 점으로 꼽았던 것은 교육 기회의 제공이었습니다. SI 프로젝트는 1년에 2회 정도, 길어지면 2년 가까이 되는 프로젝트도 있습니다. 그 기간 중에는 전혀 여유가 없다 보니 새로운 것을 배우고, 습득할 기회가 없고, 이러한 교육 기회 부재는 유능한 개발자들이 업계에서 이탈하는 이유가 되고 있죠. 실제 SI 업계에서 오랜 경험을 가진 분들에게 이탈하는 이유의 순위를 꼽아보라고 하면, 1위가 과중한 업무 강도, 2위가 성장의 기회가 부족하다는 것이라고 말할 정도니까요. (‘일하면서 알아서 배워’라고만 강요하는 것과 교육 기회는 완전히 다른 얘기입니다.)

그래서 우리 회사는 개발자들에게 프로젝트가 비는 기간에는 교육 프로그램이나 컨퍼런스 참여, 저명한 IT개발자를 초대하는 세미나를 개최하는 등 교육 기회를 적극적으로 제공했습니다. 특히 개발자는 온라인이나 오프라인이나 개발자 커뮤니티에 참여할 때 만족도가 높아진다는 것을 감안하여, 밋업(Meetup) 참여나 지원도 강화하고, 해커톤, 오픈소스 프로젝트 참여 등도 독려하고 있습니다. (그럼에도 불구하고, 바쁜 와중에 교육 기회가 아직도 부족한 것도 사실이에요.)

프로젝트 현장마다 PM과 그라운드 룰에 따라 조금씩은 다르지만 ‘유연한 근무시간제’, ‘원격 근무 옵션 적용’, ‘회의 없는 날’, ‘컨퍼런스 데이’ 등을 정해두고, 건강한 일과 삶의 균형을 지원하는 자율성을 부여하기도 합니다. 인터뷰 말미에 이런 변화에도 불구하고 점점 더 SI 현장에서 ‘주니어 개발자’를 보는 것이 힘들어지고 있어서 안타깝다는 얘기도 꼭 해달라고 하셨어요.

SI에서 가능한 성장의 기회와 한계

개발자들이 실망하고 낙담하고, 불행해 하는 상황은 여러 가지가 있습니다. ‘열정과 신념을 가지고 개발하던 프로젝트가 결과를 내지 못했을 때’는 그나마 긍정적인 실패니까, 뭐라도 얻을 수 있다고 생각할 수 있죠. 그렇지만, ‘본인이 만든 시스템이 아무런 피드백을 받지도 못하고, 사용자에게 도움이 되지도 않는 경우’라거나, ‘지루하고 반복적인 단순 작업을 해야 하거나, 오래된 레거시(legacy) 코드를 유지보수나 하는 경우’에 개발자는 ‘그만두고 싶다’는 생각 밖엔 떠올릴 수 없습니다. ‘풀스택 개발자’로 성장하는 원대한 꿈을 꾸고, IT업계에 발을 들인 사람들이 많지만 실제는 지루한 유지보수에 파묻혀 시간을 보내는 경우가 많고, ‘풀스택’이라고 하는 사람들은 깃허브(Github)를 Ctrl+C, V만 해본 것을 ‘숙련자 수준’의 무언가를 해본 것처럼 생각하는 경우도 많습니다. 물론, 일상적인 유지보수와 디버깅, 코드리뷰의 생활화는 필요한 일이지만, 성장의 기회를 찾기는 쉽지 않습니다.

사실 SI는 IT운영 유지보수보다는 몇 배나 많은 다양한 일을 해야 하고, 수많은 이해관계자들과 머리를 맞대고 일할 수밖에 없습니다. 요구사항에서 불필요한 부분을 쳐내야 하고, 매일 다르게 발생하는 이슈를 해결하기 위해 고객과 파트너와 협상도 해야 합니다. 도입하기로 한 솔루션에 대해 벤치마킹하고, 기존 시스템과 연결하면서 발생하는 기술적인 문제는 벤더를 불러 장시간 토론을 해야 하는 경우도 생기죠. (토론이라고 썼지만, 실제로는 서로 죽일 듯이 싸우는 경우를 많이 봤습니다. 물론 제가 자주 이기지만, 져주는 게 이기는 것인 경우도 있습니다.) 이건 고참인 PM만 하는 것이 아니라, 말단의 개발자까지 나누어 처리해야 하는 일입니다.

어떤 기능을 버리고, 고객을 어떻게 설득할 것인가를 기획자와 함께 고민하며 커뮤니케이션 역량이 성장하고, 새로 도입할 기술에 대해 솔루션 업체와 논의하면서 점차 풀스택 개발자가 되어가며, 파트너 개발자들과 진척 상황을 공유하며 일하는 와중에 협업의 가치를 깨닫게 됩니다. 그러면서 그 업종의 전문지식이 쌓이게 되고 컨설턴트를 능가하는, 소위 ‘쌈 싸 먹는’ 수준에 도달하는 것은 당연한 일이 되는 거예요. 물론, 이것을 ‘나 혼자만 레벨 업’하는 것으로 달성하기는 불가능합니다. 많은 이들과 부대끼면서 배우고 성장하는 SI만의 ‘모험적 성격’에서 비롯되는 ‘위험’이자 ‘기회’라고 생각합니다.

그런 면에서 SI는 참으로 일하기에 매력적인 곳이라고 주장한다면, 그건 현실을 모르는 얘기라고, 허황된 반쪽짜리 이야기가 될 겁니다. 위에서 말한 성장을 위해서는 전제가 되어야 할 사항들이 꽤나 많습니다. 먼저 SI현장을 지원하는 조직과 프로세스가 탄탄해야 합니다. QA와 테스트, UX 등의 표준과 절차가 SI 현장이 아닌 본사에서 지원하며, 개발자들이 과제의 목표를 달성하는 데만 집중할 수 있도록 해야 합니다.

그다음으로, 지원에 인색해서는 안 됩니다. 무료로 제공되는 IDE를 쓰고, 필요한 게 있으면 오픈소스 중에 괜찮은 것을 찾아서 어떻게든 원가를 줄이라고 하는 것이 아니라, 최신의 좋은 소프트웨어와 하드웨어를 지원해 주면서, 회사의 기술 스택을 최신화해야 합니다.

그리고, 가장 중요한 것은 HR입니다. SI 현장의 구성원들은 기획자, 영업, 개발자를 비롯해 모두가 전문가이며, 프로페셔널한 프리랜서라고 생각하면서 HR은 그들과 협력해야 합니다. 물론, 규모가 있는 대형 SI 기업이나 이런 고민들을 할 여유가 된다는 점을 고려하면, 대형 SI 기업이 중소SI 업체나 파트너사들과 동반 성장을 위해 더 많은 고민을 같이 해야 한다는 과제도 더할 수 있을 것 같습니다.

24년 차 시니어 개발자의 SI에 대한 변화 이야기, 나아가 앞으로 이렇게 바뀌면 더욱 좋겠다는 이야기를 읽어주셔서 감사드립니다. 짧은 지면에서 이 모든 문제들에 대한 해결법을 이야기하는 데는 부족함이 있고, 구체적인 해결법을 떡하니 내어놓을 수는 없습니다. 다만, 작은 변화들 속에서 희망과 해결의 실마리를 조금은 볼 수 있었으면 합니다. 그리고, SI 현장에서는 수많은 시니어 개발자들이 주니어 개발자분들의 합류를 기다리고 있다는 얘기로 이 글을 마무리할까 합니다. 다음에는 AI와 애자일, 다른 재미난 주제들로도 찾아뵙도록 하겠습니다.

로그인하고 자유롭게 의견을 남겨주세요.