안녕하세요. 취업준비 중 어느 분야를 선택할지 고민하다 질문하게 됐습니다. SI(시스템 통합)와 SM(시스템 관리자) 분야는 어떤 식으로 돌아가는지 궁금합니다. 취업 준비생들이 궁금해할 내용을 중심으로 몇 가지 질문하겠습니다.
ⒸDaniel Korpai
1. 중소기업과 대기업에서 쓰는 프로그램이 다른데 어떤 걸 준비해야 할까요? 중소기업은 MySQL/MS-SQL 대기업은 Oracle/MS-SQL을 주로 사용한다고 들었습니다. 참고로 저는 MySQL을 공부하고 있습니다.
2. 외근과 내근의 비율을 알고 싶습니다. 또한, 타지에서 몇 달간 일해야 할 경우, 그 이유가 궁금합니다.
3. 요즘 공고들을 보면 워라벨이 좋다고 하던데 과연 현실은 어떤가요?
4. 이 분야를 계속하면 DBA(데이터베이스 관리자)가 될 수 있나요? 개발하다가 DBA가 된 경우도 있다는데 이건 어떻게 생각하세요? 멘토님의 견해가 궁금합니다.
5. ERP(전사적자원관리), SE(시스템 엔지니어) 직무는 DB와 얼마나 관련 있으며, SI와 SM 업무와 어느 정도로 다른가요?
6. 면접을 어떻게 보셨는지 궁금합니다. 저는 면접 볼 때 너무 긴장해서 준비한 것을 다 못 보여줬거든요. 이런 부분을 어떻게 극복할 수 있을지 멘토님의 생각을 듣고 싶습니다.
질문이 좀 많습니다. 모든 답변을 부탁하기엔 염치가 없는 것 같아 가능하신 것만이라도 답해주시면 감사하겠습니다.
💬 박재선 멘토의 답변
SI와 SM, 실무에선 명확히 구분하기 어렵다
안녕하세요. 미세먼지 때문에 힘든 겨울이네요.
ⒸMarkus Spiske
SI와 SM은 사실 비슷하면서 다른 업무를 일컫는 것 같다고 생각합니다. 학문적으로는 SI는 시스템 개발, SM은 시스템 관리라고 하지만 이를 엄밀히 분리하기는 어렵습니다. SI가 끝나면 SM이 이어지기도 하고 SM을 하면서도 SI를 같이해야 할 때도 있어서 실무 현장에서 둘을 명확히 구분하기가 쉽지 않습니다.
조금 더 구체적으로 이야기하자면 이런 식이지요. 가령 A라는 시스템을 새로 만든다고 가정하겠습니다. A 시스템을 사용하게 될 이들이 원하는 시스템을 만들고자 다양한 직무의 사람들이 인터뷰와 회의를 거쳐 시스템을 설계하죠.
개발자들은 이 설계를 바탕으로 개발하고 최종적으로 테스트를 거쳐서 사용자들에게 시스템이 공개됩니다. 보통 여기까지를 SI라고 하죠.
그렇다면 A 시스템 오픈 후 개발자들이 이 일에서 바로 손을 뗄까요? 대부분 그렇지 않습니다. A 시스템을 가장 잘 아는 사람은 바로 A시스템을 설계하거나 개발한 사람이기 때문이죠.
그래서 이분들이 남아서 A시스템을 운영하기 시작합니다. 보통 이 부분을 SM이라고 말합니다. 어떤 시스템도 초반부터 완벽할 수 없기에 버그. 치명적인 오류, 개발 당시 생각하지 못했던 내용을 마주하며 해결해나갑니다. 그러면서 시스템은 차츰 안정적이게 되겠죠.
여기까지는 교과서적인 설명입니다. 사실 설계/개발하던 사람 입장에서는 이전에 했던 개발을 운영하면서 계속 이 일을 손에 쥐고 있어야 합니다. 게다가 추가 요구사항이 생기면 또다시 시스템을 설계하고 개발하는 반복을 거듭합니다.
그래서 SI와 SM의 구분이 모호해집니다. 어쩔 수 없이 구분은 하지만 현장에서 일하는 사람은 SI인데 SM같기도 하고 SM인데 SI같기도 하고 그런 상황을 겪게 되거든요.
Ⓒkelli tungay
기업이나 부서에 따라 사용 프로그램도 다릅니다
중소기업과 대기업에서 쓰는 프로그램 역시 엄밀하게 구분하기 어렵습니다. DBMS(데이터베이스 관리시스템) 쪽을 예로 들자면 아무래도 중소기업이 오픈 소스인 MySQL을 많이 쓰겠지만, 대기업에서도 많이 도입하는 추세입니다. 카카오 뱅크가 MySQL로 시스템을 구축함으로써 국내IT업계에 많은 화두를 던지기도 했고요.
물론 과거에는 비싸고 고가용성을 자랑하는 Orcale 이나 DB2 등이 대기업 시스템에 많이 사용됐습니다. 하지만 요즘엔 구분과 영역이 뒤섞였습니다.
다만 취업을 준비하는 입장에선 어떤 것 하나만을 선택해야 한다는 부담을 떠안을 수밖에 없죠. 저는 조금 편안한 마음으로 준비하기를 권합니다. 가령 멘티님이 대기업에 입사하고자 Oracle을 집중적으로 공부했는데, 입사한 기업/부서에서 더 이상 Oracle을 쓰지 않으면 공부한 게 도루묵이 될 수도 있잖아요.
어떤 회사의 특정 DBMS를 공부하는 것 보다는 모든 DB에서 사용하는 AnsiSQL 같은 부분에 더 집중해서 공부하는 게 더 유익하다고 생각합니다. 입사한 회사나 배치된 부서/프로젝트에 따라 사용하는 프로그램이 달라질 수도 있다는 점을 항상 기억하세요.
Ⓒunsplash
외근이 잦은 부서와 그렇지 않은 부서의 차이
외근 여부는 회사나 부서 상황에 따라 달라집니다. 어느 업종이나 비슷할 겁니다. 벤처 기업이라도 R&D 위주의 업무를 한다면 보통 본사나 소속 연구소에서 지속근무 할 테고, 솔루션 커스터마이징이나 CS 부서에서 일한다면 외근이 잦겠죠.
대기업도 마찬가지입니다. S 전자에서 일하더라도 어떤 사람은 출장이 너무 많아서 힘들고 어떤 사람은 사무실에만 근무하는 데 지겨움을 느낄 겁니다. 가고 싶다고 손을 들어도 안 보내주기도 하며, 갖은 핑계를 대도 다녀와야 하는 게 출장이죠.
일반적으로 IT기업은 고객에게 솔루션이나 시스템 구축을 해줌으로써 이익을 창출하기에 고객이나 프로젝트에 따라 외근의 많고 적음이 결정됩니다. 개발자가 자기네 건물에서 근무해주길 바라는 고객사가 있는 반면 결과만 좋으면 되니 보안상의 문제로 타 회사 사람이 자신의 건물에서 근무하는걸 꺼리는 고객사가 있을 수도 있지요.
그렇기 때문에 기업의 규모보다는 어떤 일을 어떻게 하느냐에 따라 외근과 내근의 차이가 발생한다고 보면 됩니다. 굳이 구분하자면 연구개발 조직은 내근이 많은 편이고, 고객이 따로 있고 고객에게 납품해야 하는 조직이라면 외근이 많겠죠.
타지에 오래도록 나가는지의 여부도 고객과 프로젝트에 따라 달라집니다. 프로젝트의 개발기간이 길고 먼 곳에서 진행된다면 아무래도 타지에서 근무할 가능성이 높아지겠죠. 그러나 대부분 회사는 직원들의 의사를 존중하고자 노력합니다. 불가피한 상황도 있으니까요
ⒸBeenicebeelove
야근을 지양하는 문화가 확산하는 추세
제가 처음 사회생활했던 10년 전에 비하면 현재 워라벨이 많이 좋아졌습니다. 당시엔 정말 몇 밤을 지새우며 일하는 경우가 비일비재했죠. 저보다 연배가 높으신 분들은 그렇게 밤새우는 것을 자랑 또는 추억 삼아 이야기 하셨고요.
확실히 과거보다 워라벨에 대한 인식이 많이 달라진 것 같습니다. 특히 52시간제 근로 도입 이후 무의미한 야근을 지양하고자 많은 곳에서 노력하는 걸 듣고 보고 느낄 수 있습니다.
하지만 IT라는 직업군의 특성과 개인의 마인드에 따라 자타의적으로 야근해야 하는 상황이 발생하곤 하죠. 저는 불필요한 야근은 하지 말자는 주의라, 제 판단에 필요한 야근만 해야 한다고 생각합니다.
DBA 대부분이 개발로 일을 시작합니다
DBA 직무는 DBMS에 깊은 지식을 갖춰야 합니다. 저는 개발을 베이스로 하고 있어서, DBA만큼의 지식을 갖추진 못했지만, 개발자가 DB를 완전히 멀리할 수는 없어서 규모가 작은 경우 혹은 DBA가 부재일 경우 그 자리를 메꿀 정도의 지식은 갖고 있습니다.
다만 DBA는 단순하게 DB를 운영하는 정도에 그치지 않는다는 점을 알아야 합니다. 시스템 개조를 비롯해서 요즘엔 데이터 모델링 및 *하둡 같은 빅데이터 시스템까지 영역을 넓히는 추세입니다.
제가 뭘 어떻게 해야만 한다고 감히 말하긴 어렵습니다만, 확실하게 말할 수 있는 것은 IT 업종 내 직무별 이동은 다른 업종보다 훨씬 수월하다는 사실입니다. 멘티님이 희망하는 직무가 있다면 노력 여하에 따라 그 일을 하게 될 수도 있습니다.
ⒸLee Campbell 저는 개발이 좋아서 개발로 직무를 정했을 뿐이지 개발하다가 DBA가 되신 분들도 많고 우연히 DB를 시작해서 DBA가 되신 분들도 많습니다.
사실 개발로 시작해서 DBA가 되는 게 대부분입니다. 처음부터 DBA로 신입을 뽑는 경우는 거의 없습니다. 학부생의 경험과 실력으로 DBA가 바로 될 수 없기 때문입니다. 그에 반해 개발직은 학부생의 경험과 실력으로 일단 시작은 가능하죠. 물론 100%는 아닙니다. 하지만 대부분 그러하다는 겁니다.
제가 아는 DBA 분들 대부분이 개발로 시작했다가 우연한 기회를 통해서 혹은 본인의 의도로 DBA가 됐습니다. 개발업무를 하다 DBA가 되는 것은 지극히 자연스러운 일 중 하나입니다.
직무별 연관성을 따지지 않아도 되는 이유
ERP, SE 직무와 DB의 연관성 혹은 SI SM과의 연관성은 위에서 얘기했듯 단정 지어 말하기 어렵습니다. ERP는 여러 IT업종 중 하나를 의미하는 것이고 SE/개발자/DBA 등은 직무의 일종이며 SI/SM은 시스템 입장 중심의 IT 일을 수행하는 사람들을 구별하는 별칭 정도거든요.
ERP는 어떤 기업의 모든 자원(돈/사람/제품/원료 등)을 관리하는 하나의 시스템을 의미하는 용어입니다. ERP 시스템을 새로 만든다고 가정한다면, 당연히 SE/DBA/개발 직무의 사람들이 모여서 만들어야 합니다.
그렇게 새롭게 만드는 과정이 SI이고 다 만들고 운영하면서 개선하고 또 만들고 하면 SM이 되겠죠. 이것을 따로 나눠서 이야기할 수는 없다고 생각합니다. SI/SM을 하더라도 DB가 안 쓰일 수도 있고 DB를 쓴다고 DBA를 꼭 두는 것은 아닐 수도 있거든요.
SE 직무가 인프라만 담당한다면 DBA가 따로 필요하지만 SE 직무 담당자가 DB 세팅도 같이 한다면 DBA를 겸한다고 봐도 되겠죠.
취업 공고에 올라오는 SI/SM/SE/DBA/DB 등의 용어들이 표기만 다르고 하나를 가리키는 것일 수도 있고 반대로 모두가 다른 직무를 의미하는 것일 수도 있습니다. 취업 준비생 입장에선 명확히 알 수 없으니 저도 그 부분이 아쉽다고 생각합니다.
하지만 실무에서도 그게 모두 구분되어서 움직이는 게 아니니 그렇게 쓰일 수밖에 없다는 생각도 들고요. 만약 공고에 명시된 내용을 명확하게 파악하고 싶다면 저나 주변 선배들에게 조언을 구하거나 해당 기업에 전화해서 확인하는 게 좋을 것 같습니다.
Ⓒben white
내가 ‘갑’이라고 생각하고 면접에 임하세요
면접은 누구에게나 어렵습니다. 떨리기도 하죠. 특유의 분위기라는 게 있으니까요. 사실 회사가 갑이고 내가 을이 되는 자리라서 더 그렇게 느껴질지도 몰라요.
그래서 저는 회사가 을이고 내가 갑이 되자 라는 마음으로 면접을 준비합니다. "내게 이런저런 경험과 지식이 있어서 회사가 진행 중인 이런 일에 큰 도움이 될 건데 나 안 뽑을 거야?" 이런 식으로 말이죠.
그런데 사실 그렇게 마음먹어도 면접장이라는 환경 자체가 부담입니다. 누구나 면접이 끝나면 아쉽습니다. 물론 만족스러울 때도 있지만 100% 만족하는 면접이란 없다는 게 제 생각입니다.
다만 면접을 보다 보면 어느 정도 익숙해지고 노련미도 생기니까 연습 삼아서라도 면접을 보라고 후배들에게 조언하는 편입니다. 이런 제 답변이 애매하게 느껴질 수도 있겠지만, 면접엔 답이 없거든요. 제가 면접관이었을 때 너무 떨어도 점수를 높게 준 적이 있고 자신감이 넘쳐도 점수를 낮게 준 적도 있습니다.
면접관과의 케미도 면접에 영향을 미치기에 실제 실력 40%에 운이 60% 정도 통한다고 생각합니다. 그래서 떨어져도 운이 없어서지 실력이 없어서는 아닐 거라고 생각하죠.
멘티님 질문에 고민을 많이 한 흔적이 보입니다. 이렇게 노력하는 분이라면 약간의 운에 약간의 경험만 더하면 좋은 결과를 거둘 수 있지 않을까 생각합니다.
저를 비롯한 IT 분야에서 근무하는 분들이 시스템 오픈 시점이나 장애 발생 시 갑작스럽게 대응해야 할 때 스트레스를 많이 받습니다. 저 개인적으로는 신기술이 많이 나오고 있는데, 그런 기술들을 따라잡는 게 즐겁지만 한편 부담스럽기도 합니다. 멘티님도 이런 현장의 고충을 알았으면 해서 말해봤습니다.
더 알고 싶은 내용이 있다면 추가로 질문 주세요. 얼른 미세먼지가 걷히고 맑은 하늘을 봤으면 좋겠습니다. 모두의 마음도 말이죠.
*하둡: Hadoop. 여러 개의 저렴한 컴퓨터를 마치 하나인 것처럼 묶어 대용량 데이터를 처리하는 기술.
저는 (흔히) 크게 알려지지 않은 대학교를 졸업하고 벤처기업을 거쳐 삼성SDS에 신입공채를 통해 입사하였습니다. 9년간의 IT서비스업 경험을 토대로 디지털화 하고 있는 현대카드에 경력 이직하여 SW개발 및 데이터엔지니어로 업무를 수행하다가 새로운 비즈니스 영역으로 발을 넓히고 있는 NCSoft 로 옮겨 데이터 플랫폼 엔지니어로서 오늘도 일하고 있다가 카드회사에서 클라우드 환경기반의 AI플랫폼을 담당하고 있습니다. 저는 삼성SDS에 재직할 당시 3년이상 '삼성직업멘토링' 에 참가하였고, 이후 다양한 곳(온/오프라인)에서 만난 친구들과 인생의 선배와 후배로 인연을 이어가고 있습니다. 멘토라서, 멘토로서 이야기 하기 보다는 선배와 후배로서, 대한민국에서 직장생활을 하는 사람 또는 IT를 하는 사람이라는 공동체 의식속에서 이야기하고 서로가 서로에게 도움이 되면 좋겠다고 생각하는 사람입니다. 어떤 이야기든 서로의 생각을 나눌 수 있었으면 좋겠습니다. 어려워 마시고 편하게 이야기 할 수 있기를 희망합니다 :D
ⒸDaniel Korpai
팔로우
