프로그래머 험난한 여정, IT업계에서 일한지 30년 SI회사 IBM 대형 프레임워크 시스템 코볼(COBOL)하던 시절 C# java javascript 파워빌더 ERP시스템 개발 유지 보수

IT업계에서 일한지 어언 30년에 가까워지고있다. 물론 옛날이라 SI전문 회사에 입사해서 대형 프레임워크 환경에서 IBM 모니터 키보드 두드리며 도트프린터로 소스 출력해서 배워가며 개발하던 시절이 있었다. 그러더니, 급변하는 환경에 세상이 달라지고 있다는 걸 직간접으로 경험, 체험해본 것이 이제 와서 보니, 나름의 재산인가 싶다.

 

우리나라 IT기술 수준이 얼마정도인지 상대평가를 하지 않으면 뉴스를 통해서 본 걸로는 중국이 1등이고, 우리나라는 동남아 어떤 나라들과 어깨를 나란히 하는 22위라는 소식을 듣고 터무니 없는 것 같기도 하고, 중국스럽기도 하고, 다른 뭔가가 있는 것 같아서 푸념을 늘어놓고 싶었다.

 

학교에서 프로그래밍을 배웠다고 말할 수 있다. 이미 컴퓨터가, 윈도우가, 매킨토시가 어느 정도 발전했을 즈음이었으니까, 1990년대에는 IT업계가 붐을 일으킬 정도여서, 대형프레임워크 시스템이 슬슬 힘을 잃어가는 시점이었던 것으로 기억된다.

 

서울풍물시장 2층 (동묘 근처)

 

물론 당시의 IT용역회사는 나름 큰 규모의 선박회사와 관련된 협력회사들의 전산망을 관리하는 역할을 하고 있었다. 오랫동안 해온 것은 오래된 장비를 보면 눈치챌 수 있었겠지만, 당시로는 변화되지 않는 시스템이라 생각했던 것 같다.

 

 

 

 

 

 

그래서 서버실 담당자는 2교대나 3교대를 해서인지 잠시 얼굴을 보고는 퇴근해버리고, 퇴근 때 나타나서 식사를 하고 다시 돌아와서는 서버실로 잠적해버린다. 늘 잠이 눈에 달린 선배들은 사람 좋은 표정을 하고 있었지만, 나름의 고충이 있었던 것으로 기억된다. 일은 어렵지 않고, 월급은 따박따박 나오고, 결혼은 하지 않았고, 돈 벌 수 있는 투자 기회가 있다는 소문을 듣고 그동안 모아온 돈을 털려서, 월급을 땡겨서 돌려막고 있기도 했던 것으로 기억되는 세기말 풍경이다.

 

당시 대학에서는 IT에 사용될 랭귀지가 어떤 것이 주로 사용될지 알지 못했던 것 같다. 그래서 가르쳐준다는 것이 이미 사라진 것 같은 어셈블리어, FOTRAN, BASIC, COBOL 등이었다.

 

 

* Assembly Language(어셈블리어)

어셈블리어(영어: assembly language) 또는 어셈블러 언어(assembler language)는 기계어와 일대일 대응이 되는 컴퓨터 프로그래밍의 저급 언어이다.

프로그래밍 언어의 하나. 기계어에서 한 단계 위의 언어이며 기계어와 함께 단 둘 뿐인 저급(Low Level) 언어에 속한다.

기계어라는 게 컴퓨터 관점에서 바로 읽을 수 있다는 것 빼고는 인간의 관점에서는 사용이 불편한 언어이기 때문에 이를 보완하기 위해 나온 것이 어셈블리어다. 따라서 어셈블리어의 특징은 기계어 1라인당 어셈블리 명령어가 대부분 1라인씩 대응되어 있고 이를 비교적 간단하게 짤 수 있는 어셈블러를 통해 기계어로 변환되도록 한 것이다. 이 때문에 어셈블리어는 고급 언어와 기계어 사이에 있다 하여 '중간 언어'라고도 불린다. 그리고 기계어는 CPU가 채택한 명령어셋(ISA)에 따라 다 다르기 때문에 어셈블리어의 명령어 역시 통일된 규격이 없다. 또한 문법 아키텍처에 따라서도 다르고 어셈블러의 종류에 따라서도 문법/매크로 등이 제각각이다.

 

 

* FOTRAN(포트란)

포트란(Fortran, 이전 명칭 FORTRAN)은 1954년 IBM 704에서 과학적인 계산을 하기 위해 시작된 컴퓨터 프로그램 언어이다.

1950년대 말에 IBM의 존 배커스(John Backus) 외 6명의 전문가가 완성한 최초의 고급 프로그래밍 언어 중 하나이다. 알골과 함께 과학 계산용으로 주로 사용되고 매우 간결하고 엄격한 구문 형식을 가지고 있다. ANSI와 ISO에서 표준화되었다. 이름은 수식 변환기(FORmula TRANslator)라는 뜻으로, 이름 그대로 수식을 계산하는데 특화되어 있다. 수식 계산에 특화되어 있다는 것은

수식을 간단하게 표현할 수 있다.
수치 계산이 빠르게 수행된다.

라는 이념을 가지고 설계되어 있다는 것이다. 컴퓨터 공학에서는 죽은 언어로 인식하고 있지만 계산수학에서는 아직도 C와 더불어 활발하게 쓰인다. 역사가 유구한 것을 연구하는 전공의 공대나 자연대 대학원 학과에 진학할 경우 접할 수도 있는 언어이며 슈퍼컴퓨터로 뭔가를 해야 할 일이 생길 경우 높은 확률로 사용하게 될 언어이다.

 

 

* BASIC(베이직)

초심자용 다목적 기호명령부호(初心者用 多目的 記號命令符號，영어: Beginner's All-purpose Symbolic Instruction Code) 또는 단순히 베이직(BASIC, 문화어: 베이씨크)은 사용하기 쉽도록 설계된 범용 고급 프로그래밍 언어다. 1964년 다트머스 대학교의 존 케메니(John Kemeny)와 토머스 커츠(Thomas Kurtz)가 개발했다. 그들은 비과학 분야의 학생들이 컴퓨터를 사용할 수 있도록 하고 싶었기 때문이다. 그 당시에, 거의 모든 컴퓨터들은 과학자들과 수학자들만이 배우는 경향이 있는 맞춤 소프트웨어를 쓰는 것을 필요로 했다.


Beginner's All-purpose Symbolic Instruction Code
(초보자용 다목적 기호명령 코드)

프로그래밍 언어 중 하나로 간단하고 배우기 쉬운 언어로 잘 알려져있다. 본래 영어 단어 base의 형용사형인 basic의 발음을 따온 말로서 1986년에 제정된 외래어 표기법에 따르면 베이식이 정확한 표기이지만 한국에서는 베이직이라는 표기가 압도적으로 널리 통용되고 있다. 1980년대에 국내에 처음 소개될 때부터 잘못된 발음(베이직)으로 불렸으며 아예 교본 등 출판물에까지 베이직으로 표기되어 있었다. 수많은 한국인들이 basic이란 단어를 베이직으로 잘못 발음하게 만든 주범이 바로 BASIC이다.

소싯적에 컴퓨터 좀 만져본 1970~80년대생이라면 추억하는 이가 많은 프로그래밍 언어.

1963년 다트머스 대학교의 존 케메니(John Kemeny)와 토머스 커츠(Thomas Kurtz)가 개발한 꽤 유서깊은 언어이다. 본래는 대화형 메인프레임 시분할 언어로 설계되었으며, 퍼스널 컴퓨터에 채용됨으로써 널리 사용되는 언어가 되었다. 간단한 영어의 어구를 기반으로 한 명령이 쓰이므로 쉽게 배울 수 있다는 장점이 있으며, 이 때문에 대표적인 프로그래밍 교육용 언어로 보급되었던 언어이며 오늘날까지도 생명력을 유지하고 있는 언어이다.

 

 

*  C언어

C는 1972년 켄 톰슨과 데니스 리치가 벨 연구소에서 일할 당시 새로 개발된 유닉스 운영 체제에서 사용하기 위해 개발한 프로그래밍 언어이다. 켄 톰슨은 BCPL언어를 필요에 맞추어 개조해서 "B"언어(언어를 개발한 벨 연구소의 B를 따서)라 명명했고, 데니스 리치가 이것을 개선하여 C 언어가 탄생했다. 유닉스 시스템의 바탕 프로그램은 모두 C로 작성되었고, 수많은 운영 체제의 커널 또한 C로 만들어졌다. 오늘날 많이 쓰이는 C++는 C에서 객체 지향형이다.

1972년에 벨 연구소(Bell Labs)의 데니스 리치가 만든 범용(general-purpose) 프로그래밍 언어. 원래 명칭은 그냥 'C'지만 한국에서는 표제어에서도 볼 수 있듯 'C언어'라는 명칭으로 주로 부른다. 영미권에서도 Clang이라고 부르는 사례가 있다. 세계적으로 많이 쓰이는 프로그래밍 언어 중 하나이다.

 

 

* COBOL(코볼)

코볼(COBOL, COmmon Business-Oriented Language, 사무 지향 보통 언어)은 사무용으로 설계된, 영어와 같은 컴퓨터 프로그래밍 언어이다. 절차적, 명령형 언어이고, 2002년부터는 객체 지향 언어이다.

3세대 프로그래밍 언어로, 1959년에 처음으로 나왔다. 이후 여러 번 규격이 개정되어 현재는 객체 지향도 지원한다. 개념이 상당히 오래묵기는 했지만 처음부터 일반인도 쓸 수 있도록 만들었기에 배우기 어렵지 않은 편이다.

 

728x90

 

하지만 오랜 기간동안 IT업계에서 직장생활을 이어온 경험에 비춰 생각해보면, 프로그래밍 언어는 그렇게 중요한 것이 아니라는 생각이 든다. 물론 주로 업무 위주의 이해도를 갖고 고객이나 개발사의 협의에 의해 정해진 프로그래밍 언어를 사용하고, 그에 맞춰진 환경에서 개발을 해야 됐기에, 모르면 배워서라도 개발을 해야 하는 것이 당시의 분위기였다고 기억된다.

 

물론 해당 프로그래밍 언어를 사용해봤나? 개발해봤나? 프로젝트에 참여해봤나? 등을 궁금해하는 경우도 있긴 하지만, 다수 프로젝트에 참여해본 경험으로 생각해보면, 제대로 설계되지 않아서 삽질을 하는 프로젝트 말고는 랭귀지 때문에 문제된 경우는 없었다고 보는 것이 옳다고 본다. (물론 개인적인 의견이고, 다수 프로젝트에서 경험한 경험치에 의한 개인적인 생각임)

 

오히려 적어도 짧은 기간에 분위기를 읽고, 어떻게 해야할지를 파악할 수 있는 눈치가 있으면, 적어도 전공자이거나, 비전공자라도 경험치만 있다면 누구나 할 수 있는 프로젝트가 적지 않다고 말하고 싶다.

 

언젠가부터 어떤 DB를 사용하느냐에 따라서 개발이 좌지우지되는 현실을 마주하게 됐다. 그래서 앞서 서술한대로 어떤 프로그래밍 언어를 사용하느냐, 할 줄 아느냐는 별로 중요하지 않게 되어버렸다.

 

좀 옛날 이야기지만, 개발은 프로그래머가 하고, 화면은 디자이너가 그리는 나름 분업으로 진행되는 프로젝트도 있었다. 별로 효율적이지 못했지만, 당시에는 경험치가 없어서 그게 맞는 줄 알고 그렇게 실수를 했었던 것 같다. 껍데기는 통일된 기준만 있으면 되고, 내부에서 돌아가는 걸 어떻게 구현하느냐가 더 중요하다는 걸 나중에야 알게 되었지 싶다. 그래서 요즘에는 초반에 디자이너가 그림만 그려주거나, 기준만 잡아주고 탈출한다. 계속 있어봐야 더이상 할 게 없으니, 부담도 적고, 뒷끝도 없어보이기도 했다. (살짝 부럽지만...)

 

그래서 요즘은 주로 ORACLE DB를 사용한다. 

 

* 오라클 데이터베이스

오라클사의 RDBMS 제품명

오라클 데이터베이스(Oracle Database 또는 Oracle RDBMS)는 미국 오라클(Oracle)사의 관계형 데이터베이스 관리 시스템의 이름이다. 현재 유닉스 환경에서 가장 널리 사용되는 RDBMS이다. 검색이나 업데이트용 언어로는 국제표준화기구의 표준

다른 DB도 있지만, 주로 사용되는 DB다. IBM에서 만든 DB2도 있다.

 

* DB2

IBM DB2는 IBM에서 1983년에 발표된 상업용 관계 데이터베이스 관리 시스템이다. MVS/XA와 MVS/370 운영체제에서 사용되며 SQL을 데이터 언어로 사용하여 다수의 사용자들이 여러 개의 관계 데이터베이스를 동시에 접근할 수 있는 대형 데이터베이스를 위한 시스템이다.

1990년대에는 대부분 DB2를 사용했고, 그래서 COBOL을 사용했고, 그래서 나름 안정적인 시스템을 구축해서 오랫동안 유지한 것으로 이해된다. IBM이 맛이 슬슬 갔던 걸 스스로 알지 못했던 시기였던 것 같다.

 

ORACLE이 나타나서 이렇게까지 공룡 IBM을 쓰러뜨릴 수 있었을지 누구도 예상하지 못했을 것이었나 보다. IBM이 부도 나는 것 아니냐는 소문이 IT업계에 돌았었고, 당시 대형 프로젝트인 국민은행 차세대 개발에 IBM이 깊숙히 관여하면서 개발자들을 동요하게 만들었던 기억이 있다.

 

* 1993년, 창사 이래 IBM의 최대 위기

IBM은 설립 시점부터 1980년대 중후반까지 컴퓨터 분야의 기술을 선도하고, 혁신적인 제품을 출시하며 그야말로 파죽지세로 성장했다. 하지만 1990년대 들어 규모의 비대화로 인한 비효율이 커지며 성장 활력이 크게 둔화되었고, 신규 사업 분야 진출, 연구 개발비 삭감 등의 문제가 발생하며, 일각에선 IBM이 망하는 거 아니냐는 우려도 나왔다. 미국에선 1980년대 PC 산업이 무분별하게 확장되다가 1980년대 후반, 1990년대 초반 조정기를 거치면서 수많은 컴퓨터 관련 회사들이 망하고 있었기 때문이었다.

 

* IBM

미국의 다국적 기술 및 컨설팅 회사

국제 사무기기 회사(國際事務機器會社, International Business Machines Corporation; IBM)는 미국의 다국적 기술 및 컨설팅 회사이다. 천공 카드 시스템을 고안한 허먼 홀러리스가 1896년 창설한 제표기기회사가 1911년에 국제시간기록회사, 컴퓨팅 스케일 컴퍼니, 번디 제조회사와 합병해 세운 전산제표기록회사(CTR)가 이 회사의 전신이다. 터뷰레이팅 머신의 자동 표작성기는 1890년의 미국 국세 조사(國勢調査)에 사용되어 대단한 위력을 발휘하였다. CTR은 한때 경영 부진에 빠졌으나 1914년 토머스 J. 왓슨을 사장으로 영입해 급성장의 계기를 이룩했다.

 

그 뒤에 다운사이징 붐이 일어서, 너도나도 다운사이징을 한다고 프로젝트가 넘쳐나던 시절이 있었다. 어쨌든 프로그래머로 밥벌어먹고 살기에는 나쁘지 않은 상황이었다고 볼 수 있다. 그래서 이렇게 과거를 추억하며 역사를 되짚어볼 수 있지 않나 하는 ...

 

* 다운사이징

다운사이징은 은행 또는 회사 등과 같은 대기업에서 대형 컴퓨터로 수행했던 작업을 PC 또는 중소형 서버 등의 소규모 컴퓨터 여러 대를 근거리통신망과 같은 네트웍으로 연결하여 사용함으로써 작업을 수행할 수 있게 환경을 변경하는 작업이다. 이를 통하여 메인프레임과 같은 고가의 장비를 구입하지 않아도 되고, 장비 유지보수료나 전산기계실 운영비용 등이 절감될 뿐 아니라, 업무의 크기나 환경 변화에 정보시스템이 유연하게 대처할 수 있다는 장점을 내세워, 우리나라에서는 90년 초반에 유행처럼 번지던 정보시스템의 조류이다.

그러나, 일부 은행의 다운사이징이 결국 실패로 평가되면서, IBM을 비롯한 대형 메인프레임 제조업체를 중심으로, 다운사이징은 환상일 뿐이며 기업에 중요한 업무는 중앙의 대형 컴퓨터를 중심으로 이루어져야한다는 주장을 펼치기 시작했는데, 이미 사이즈가 작아진(다운사이징을 한) 정보시스템을 다시 키운다는 의미로 업사이징(up sizing)이라는 분위기가 조성되기 시작하였다.

한편, 지나친 다운사이징도 또 지나치게 업사이징에 의존하는 것도 모두 문제가 있으며, 무릇 모든 업무는 그 중요성이나 크기에 맞도록 최적의 정보시스템을 설계하고 도입, 운영해야한다는 개념이 바로 라이트사이징(rightsizing)이다.

사실 "down"이라는 용어에는 부정적인 용례가 많지만, 다운사이징은 일반적인 의미의 down과는 전혀 상관이 없는 단어이다. 정보시스템에서의 다운사이징이라는 용어는 1980년대 초에 '메인프레임보다 더 우수하고, 더 싸고, 더 빠르고, 더 유연하며, 더 신뢰성 있는' 대안을 주창했던 IBM 왓슨연구소의 직원이었던 Henry P. Downsizing의 이름에서 따온 것이다. 당시 상황으로는 그의 이러한 주장이 다른 사람들로부터 무시당하기에 충분했으며, 그 일화조차 별로 알려지지 않았지만, 다운사이징이라는 이름은 남게 되었다.

출처: http://www.terms.co.kr/downsizing.htm 

 

* 조직다운사이징(organization downsizing)

조직다운사이징은 이익 감소, 기업 조직구조 개편 및 기업운영의 변화등을 이유로 기업이 비용을 절감하고 자원 절약을 실천하는 것이다. 조직다운사이징의 단점으로는 직원해고, 급여삭감, 잔존 직원들에 대한 혜택의 취소 등과 같은 일에 너무 많이 의존한다는 것이다. 이로 인해 직원들의 사기가 저하되고 생산성이 떨어지는 등의 부작용이 발생할 수 있다. 장점으로는 효율성을 재활성화하고 비전을 명확히 하며, 미래에 대한 비전을 만들 수 있다는 장점이 있다. 즉, 다운사이징을 통해 기업은 비생산적인 부문을 수익성이 높은 사업으로 전환이 가능하다는 것이다. 다운사이징(downsizing)의 유래는 다운(down)과는 무관한 개념이다. 원래의 뜻은 작지만 신뢰있는 컴퓨터의 개발을 외친 IBM 왓슨연구소 직원인 헨리 다운사이징(H, Downsizing)의 이름에서 파생되었다.

경기가 IMF로 위축되면서, 정리된 회사들도 많았고, 또 새롭게 기회를 부여받아서 급성장한 회사도 있었고, IMF 탈출로 문제가 해결되나 싶을 정도로 경기가 반전을 치고 올라가게 된다.

 

대학 졸업하고, 뭔가 대기업에 들어가있을 법 하던 선배들이, 어느 순간 제조회사에서 일한다는 소문을 듣게 되고, 잘 다니던 은행이 문닫으면서 IT업계에서 일하면서 은행원 급여와 개발자 급여를 비교해보고는 순간의 선택이 10년을 좌우한다는 후회를 술만 마셨더 하면 읊어대던 형님도 있었고, 나름 IT회사 하나 만들어서 사장 노릇하는 형님도 만나게 된다.

 

각양각색의 전설을 지닌 형님들의 아픈 추억담이라고나 할까... 그런 형님들과 먹었던 오소리감투는 그야말로 크~~~

 

어쨌든 이제는 분위기가 좀 달라진다. 갑작스럽게 대형 IT회사들이 가상화폐, 암호화폐 시장이 급성장하면서 개발자들이 어딘가로 사라지는 현상을 접하게 된다. 그래서 기존 저렴하게 개발자들을 모아서 프로젝트를 했던 IT업체들이 단가를 올리기 시작하고, 급기야는 필자의 단가도 올라버렸다. 그런데, 문제는 물가가 엄청 올라버렸다는 것이 풀 수 없는 수수께끼처럼 불편한 상황을 만들었다. 결론적으로 단가가 오른 것이 아니라 그저 평타인 것이라 생각하며, 검소하게 살아갈 결심을 하게 됐다.

 

* 가상화폐

가상화폐(假想 貨幣, virtual currency 또는 virtual money)는 지폐나 동전과 같은 실물이 없이 네트워크로 연결된 특정한 가상공간(vitual community)에서 전자적 형태로 사용되는 디지털 화폐 또는 전자화폐를 말한다.

암호화폐는 가상화폐의 일종이라고 볼 수도 있다. 하지만 유럽 중앙은행이나 미국 재무부의 가상화폐 정의를 엄격하게 적용하면 가상화폐라 부를 수 있는 암호화폐는 거의 없게 된다. 그래서 미국 재무부 금융죄단속반(FinCEN)에서는 암호화폐를 가상화폐라고 부르지 않는다. 최근 대한민국에서는 가상자산으로 불리기도 한다.

 

* 암호화폐

디지털 자산의 일종

암호화폐(暗號貨幣, 영어: Cryptocurrency)는 '암호화'라는 뜻을 가진 'crypto-'와 통화, 화폐란 뜻을 가진 'currency'의 합성어로, 분산 장부(Distributed Ledger)에서 공개키 암호화를 통해 안전하게 전송하고, 해시 함수를 이용해 쉽게 소유권을 증명해 낼 수 있는 디지털 자산이다. 일반적으로 암호화폐는 블록체인이나 DAG (Directed Acyclic Graph)를 기반으로 한 분산 원장(Distributed Ledger) 위에서 동작한다.

 

어쨌든 가상화폐, 암호화폐 쪽으로 간 개발자들이 승승장구한다는 소식을 들으며 배아파하고 있는데, 이게 왠일? 갑자기 지각변동이 있었던지, 코로나19는 끝났지만 그 여파가 있는 것인지, 아니면 경기가 어려워진 것인지, 잘 다니던 직원을 정리하는 소식도 전해져서 맛보지도 못한 승승장구 분위기가 바뀌었구나 상상하게 되면서, 안분지족, 그냥 내 형편을 만족하기로 했다.

 

300x250

 

앞으로??? 는 어떻게 될 것 같은지 생각해보면, 현재의 엉터리같은 개발 환경은 쉽게 바뀔 것 같지 않지만, 이걸 어떻게든 실질적인 발전이나 개선으로 방향을 바꾸게 될 게임체인저(Game Changer : 게임의 판도를 바꿀 수 있는 것)가 나타날 것을 기대해본다.

 

이건 현실적인 불만토로이자, 반성이자 밝은 미래를 바라는 마음이다.

 

현재의 개발은 주로 ORACLE DB 기준, SQL을 사용할 줄 알면 대부분 가능하다. 그 외의 JAVA 개발 여부는 부차적인 것이라 봐도 무방하나,  C#, C++ 이어도 결과적으로는 DB를 읽고, 쓰는 것만 이해하고, 구현할 수 있음 된다고 보고, 나머지는 프로젝트의 기준에 따라 눈치 빠르게 움직이면 된다고 본다.

 

* SQL

SQL(/ˈɛs kjuː ˈɛl/, 또는 /ˈsiːkwəl/, Structured Query Language, 구조화 질의어, S-Q-L)은 관계형 데이터베이스 관리 시스템(RDBMS)의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어이다. 관계형 데이터베이스 관리 시스템에서 자료의 검색과 관리, 데이터베이스 스키마 생성과 수정, 데이터베이스 객체 접근 조정 관리를 위해 고안되었다. 많은 수의 데이터베이스 관련 프로그램들이 SQL을 표준으로 채택하고 있다.

데이터베이스 시스템에서 자료를 처리하는 용도로 사용되는 구조적 데이터 질의 언어. 에스큐엘, 혹은 시퀄이라고 읽는다.

 

* 질의어

질의어(영어: query language)는 데이터베이스와 정보 시스템에 질의를 할 수 있게 하는 고급 컴퓨터 언어이다.

질의어는 크게 데이터베이스 질의어인지 정보 검색 질의어인지에 따라 나뉠 수 있다. 차이를 들면, 데이터베이스 질의어는 사실로서의 질문에 대한 사실로서의 답변을 제공하려는 반면, 정보 검색 질의어는 질의와 관련된 정보를 포함하는 문서 검색을 시도한다.

 

 

IT업계에 개발자가 부족하기 때문이다. 옛날에는 정말 퇴근이 어려울 정도로 차세대를 하고, 프로젝트를 하곤 했었다. 초반에만 정시에 퇴근하고, 중반 후반에 가면 미친듯이 몰아쳐서, 일부는 죽음 직전에 이르기도 하고, 그 주변에 놀면서 퇴근하는 이들이 같이 밥먹으며 위로해주는 비정상적인 상황이 있었다.

 

이제는 그런 세상이 아니다. 잘만 조절하면 적절한 업무를 해나갈 수 있다.

 

내가 못해서 못하는 것이 아니고, 팀이나 사수가 못해서 고생하는 경우가 있는데, 이런 경우는 탈출을 해야 한다고 본다.

 

다행인 것은 경험치가 사라지지 않는 것이고, 그 경험치로 새로운 경험치를 쌓을 수 있는 환경이 된다는 것이다. 그렇게 어느 정도 경험치를 쌓고 나면 나름 홀로서기를 할 수 있는 수준이 되는데, 그건 실력이 뒷받침되어야 하는 것이겠고, 아울러 인간관계에서 주고받는 관계가 되어야 하고, 썩은 동아줄인지, 짱짱한 동아줄인지 잘 파악해서 선별, 관리해서 일할 수 있게 된다는 것이다.

 

※ 용어설명 출처 : 나무위키, 위키피디아 등