(IT용어정리) 데브옵스 (DevOps)
Vložit
- čas přidán 28. 08. 2024
- #데브옵스 #DevOps #개발자 #클라우드 #IT창업 #창업 #취업 #IT취업 #개발 #코딩 #coding
이번시간은
IT용어정리 - 데브옵스 (DevOps)
공유합니다
* 영상과 관련한 기술블로그도 함께 보시면 도움이 많이 됩니다.
techhans.tisto...
구독과 좋아요 그리고 댓글은 영상제작에 큰힘이 됩니다
* Track
ThePath by OliverMichael
------
* License
Background Music (BGM): Using the Artlist license
![클라우드 엔지니어 vs 데브옵스 엔지니어 [임종진 부장/알리바바클라우드, 고우성의 잇터뷰45 ]](http://i.ytimg.com/vi/rDInP0L3qIA/mqdefault.jpg)
![클라우드 엔지니어 vs 데브옵스 엔지니어 [임종진 부장/알리바바클라우드, 고우성의 잇터뷰45 ]](/img/tr.png)
(단기) 자바스프링 (온라인) 과정은 매달 온라인으로 신청/진행
- 한달만 함께 공부하면 개발자가 되기 위한 기초 스킬 완벽대비
- 자세한 내용은 아래 링크 공지 글 확인 (커리큘럼, 진행방법 등)
cafe.naver.com/turtlecoding/43
영상들 많이 보고 오다가 이렇게 정리기 잘되고 요약을 잘 해주는 영상은 이 영싱이 최고였던거 같아요! 바로 구독 갑니다! 감사합니다!
의견 감사합니다~!
영상 항상 잘보고 있습니다.영상과 관련없는 질문인데요 만약 클라우드 엔지니어로 신입으로 들어가서 기존 인프라 자동화하는 iac업무를 위주로 하는게 커리어적으로 괜찮을지 궁금합니다!
IaC(infra as code)는 기존 SE(시스템엔지니어)가 하던 업무가 클라우드로 넘어오면서 자연스레 테라폼(AWS 경우 cloudformation)등을 이용해서 인프라를 자동 또는 쉽게 관리하는 기술(?) 정도입니다. 그러므로 이런 업무를 하는 것이 인프라(클라우드)엔지니어입니다. 만약 이런 업무를 3년정도 하고 나서 어떤 느낌일지 상상이 갈것입니다(단순업무) 그길로 계속 간다면 좋은 것이고 기본이 탄탄해 지는 것이고 다른 것을 꿈꾼다면 한번더 도약을 위해서 기술을 익혀야 하겠고, 그러한 기술이 어렵지만 데이터(클라우드) 엔지니어로 넘어가시라고 말하고 싶습니다. 늘상 얘기하지만 인프라(클라우드)엔지니어는 수명이 10년 넘어가기 힘듭니다. 참고하세요
@@hanstech7027 답변 감사합니다. 추후엔 k8s를 기반으로한 SRE쪽으로 영역을 넓혀가면서 말씀하신거처럼 결국 최종적으로는 MSA상에서 다양한 데이터를 분석하는 방향으로 생각하고는 있었는데요. 신입입장에서 초기커리어으로선 어떨지가 궁금했습니다! 사실 공부는 개발쪽으로 많이했는데 데브옵스+백엔드를 가져가는 경우는 별로없나요?
@@JMPARK-dc7eh 개발쪽으로 공부를 많이 했다니깐 다행이네요. 거기서 부터 출발입니다. 사실. 인프라 하나만으로 먹고 살기 어려워요. SRE나 DevOps도 아키텍트 이기에 대용량시스템을 많이 다루면 다룰수록 자신의 커리어는 높아지겠지만 기회가 많지는 않죠.그러나 요즘은 워낙 시스템환경,개발환경이 좋아져서 테스트는 얼마든지 해볼 수 있습니다.장기적으로 개발자->데브옵스-아키텍트로 성장하는 것이 가장 추천드리고요. 백엔드라면 데이터쪽을 이야기하는 것이라면 길이 나뉩니다. 개발자->데이터개발자(ML,DL개발자)->데이터아키텍트 로서 시작은 개발자이지만 점차 자신의 영역을 확보하면서 고급기술자로 넘어가야 하는데, 데브옵스 아키텍트는 대용량의 경험이 필수 이고 데이터아키텍트는 대용량의 데이터경험이 필수로서 일하면 거의 끝이라고 보면됩니다. 그런 경험이 운이 좋으면 빨리 올수도 있어요. 그러나 그것이 좋은 것은 아닙니다. 개발자로서 성장하는 나이도 정해져 있기에 굳이 어린나이에 아키텍트가 될 필요는 없습니다. 어차피 커리어가 쌓이면 아키텍트가 되는 것일뿐. 개발자로 일하는 시기가 있기에 개발자를 먼저 추천드리는 것입니다.
@@hanstech7027 좋은 말씀 너무 감사드립니다. 최종적으론 아키텍트로서 성장하고 싶은데 개발경력이 부족한상태로 바로 데브옵스영역으로 넘어가는것이 괜찮은것인지가 고민이었는데 많은 도움이 되었습니다
지난해 약30년 근무한 직장을 그만두고 일본의 IT기업에 이번에 입사를 하여 ,일본에 입국했습니다. 나름 내실있는 물류솔류션 업체인데 전체직원 약50명정도의 중소기업입니다. 다음주 출근하여 상황을 봐야되겠지만 고객들의 요구사항 관리도 아직 이메일로 주고 받고 있어서 레드마인 등의 도입을 비롯 업무를 효율적으로 개선할 수 있는것을 구상중에 있습니다.
설명해주신 데브옵스를 적용하기 위해 투자가 필요한 부분과 사내에 변화관리가 필요한 것들은 어떤 부분일지 알려주시면 큰 도움이 될것 같습니다.
대단한 결심과 도전 이십니다. 리스펙입니다. 저도 적지 않은 연차이지만 저보다는 선배님이시군요~ 신입사원때 국내에서 일본히타치등의 하도급 개발자로 몇차례 프로젝트를 수행한적이 생각나네요. 아시다시피 일본 IT기술은 상당히 보수적으로 접근하기 때문에 해당 기업의 서버 규모를 파악하시고 전체적으로 컨테이너화가 필요한지가 구별이 되어야 할거 같습니다. 결국 데브옵스의 배포 자동화의 기초는 도커기반이기에 기업의 서버운영에 있어서 도커환경을 허용하느냐 안하느냐에 따라 데브옵스 환경이 될거 같습니다. 그러나 일반적인 CI/CD 환경으로 구성할 수도 있기에 말씀하신대로 레드마인이나 JIRA, GIT, 슬랙(또는 confluence) 등의 형상관리를 1차적으로 도입하며, 개발팀과 운영팀과의 진행과 협업의 기반으로 애자일(agile) 방법론 등도 부분 도입할 수 있겠습니다. 이런 기반을 기업에서 이해하고 전파하고 안정하기 까지 노력이 상호간에 필요할 수 있을 거 같습니다. 인프라도 점차 클라우드(멀티클라우드)로 전환하는 것도 고려할 수 있을 거 같습니다.
@@hanstech7027 정성있는 답변에 감사드리고 도움이 되었습니다. 개발자로 시작하여 특화된 업무영역(해운)에서 오래 있다보니, 개발에 손을뗀건 20년 정도되었고 가끔 SQL은 보고 있었지만 주로 컨설팅 또는 기술영업을 했던 관계로 어느사이에 IT지식 및 감각이 많이 떨어졌네요. 이해력도 마찬가지고요 ㅠ 기회가되면 시간은 걸리겠지만 반복해서 학습한후 회사의 현황을 파악하여 솔루션들을 소개하고 및 개선제안을 해보고 싶네요. 고객이 50여군데가 있는데 도커 및 레드마인(무료라서요) 등이 필요한 부분은 데브옵스로 가기위한 솔루션이네요... 큰 도움이 되었습니다. 이제 제가 먼저 학습을 하면서 소개할 자료를 준비하고 번역하여 1달 뒤에 발표하는 것을 목표로 해봅니다^^. 막히는게 있거나 필요한 자료가 있으면 조언구하고 싶네요..