'분류 전체보기'에 해당되는 글 1246건

간혹 필드에서 일하다가 보면, 같은 작업에 대해서 이상하게 설명도 잘 안하고,  알려주지도 않는 분들이 있다. 여러가지 이유가 있을 수 있다. 그 일에 대해서 잘 모를 수 있거나, 알긴 하는데 설명이 안되거나, 노력없이 여기까지 낼름 받아 먹는 뽄세가 마음에 안들거나, 아니면 자기 밥그릇에 대한 수호의지일 수도 있다.

이 분들에게 꼭 말하고 싶은 것은, 지금 우리가 하는 일은 IT이고, 프로그램 개발이고, 기술로 먹고 산다는 점이다.

1. 부품이 아닌 생각을 구체화 하는 직업의 특성

보통 생산 라인은 표준화된 도구와 표준화된 부품, 그리고 표준화된 작업환경을 통해서 일률/획일적인 방식으로 생산을 하게 된다. 모든게 동일한 방식의 동일한 재료로 정해진 대로 작업하므로 개개인의 게으름 혹은 이해 부족이 눈에 띄게 나타날 수 있는 구조를 가지고 있다. 정말 계산 대로 움직임을 통제할 수 있다. 그런데 IT, 특히 개발작업은 이런 계산이 사실 매우 어렵다. 출발점이 아예 다르기 때문이다. 아무리 표준화 한다고 해도 생각하는 방식을 표준화 할 수 는 없기 때문이다. 같은 A를 알려주어도 A 혹은 A’  심지어 B로 이해할 수 있다. 게다가 이를 표현 하는 방법도 최소 표준이기 때문에, 결국 그 목표치에 이르는 단계나 흐름은 개발자 각각이 다른 모습을 보일 수 밖에 없기 때문이다. 결국 XP(eXprence Programming)에서는 고전적인 산술 방식의 산출 방식을 거부하고, 대신 과거 데이터를 기반으로 “속도”라는 것을 측정하는 방법을 취하고 있다. 그것도 겨우 갸우 대안으로 말이다.

각기 다른 생각을 갖기 때문에, 그 결과물도 매우 다를 수 밖에 없는데, 서로 다른 생각을 합치기 보다 자기만의 것만을 취한다고 독점한다고 보자. 표준화도 안된 생각들이 제각각이라면 그 결과는 어찌될 지 눈에 보이지 않을까?

2. 기술의 발전 속도

IT, 프로그래밍은 주위 시스템의 발전속도를 못쫒아 갈정도로 어마어마하게 성장하고 발전해 있다. 그런데 이 기술은 지속적인 형태로 발전하게 될 수 밖에 없는데 그것을 혼자만 독점을 하겠다는 것은 스스로 고인 물을 자처하겠다는 의미이다. 예전 인터넷이 그리 발전하지 못한 시절. 모든 것을 책에 의존할 수 밖에 없을 때에는 어느정도 기술 독점을 인정 할 수 밖에 없을 때도 있었다. 외부에 조언을 들을 수 밖에 없었고, 우리나라 기술자들은 미묘하게 다른 이들에게 잘 알려주지도 않는 특성을 갖고 있어 특히나 그런 모습을 자주 볼 수 있다. 하지만, 지금은 인터넷을 통해 Stack Overflow와 같은 유명 Q/A 사이트에 가보면 정말 다양한 생각들에 대한 질문 답변을 쉽고 볼 수 있고, 필요하면 질문하고 그 답을 얻을 수도 있다.

즉 기술의 독점은 스스로 고립을 갖게 만들고, 스스로 도태되는 지름길이다. 딱 그 정도만 아는 수준이 될 수 밖에 없다.

3. 복습 그리고 발전

다른 이들에게 기술의 설명이나 이전을 하게 되면, 스스로 자신의 기술 습득 정도를 돌아보는 좋은 기회가 된다. 정말 잘 아는지, 무엇을 잘 모르는지가 명확해진다는 의미이다. 설명을 하다가 정확하게 설명이 안된다면, 분명하 잘 모른다는 의미가 될 수 있다. 이 모든 절차에 대한 확실한 이해가 되어야 다른 이에게 설명이 가능한 것이다.

4. 업무의 전이

정말 미련 곰탱이들이 스스로 일을 혼자 짊어지게 되는데, 이 경우 자신을 찾는 이들은 분명 늘어는 나지만 결국 그 일들의 처리에 온 신경을 다 ㅆ고 있게 된다. 결국 새로운 업무는 제대로 손도 못대고, 예전 작업만 계속 무한 반복한다. 최악의 경우 휴가를 가도 전화를 받고, 원격에서 수정하고 관리해야 된다 .휴가 같지 않은 휴가를 보내게 된다. 더욱이 퇴사 이후 3~6개월동안 계속 전화를 받을 수 밖에 없다. 인수 인계라는 것이 있지만, 그것 아무리 잘해줘도 내용에 대한 심화학습이 없는한 쉽게 이해도 안된다. 처음부터 잘 알려주었다면, 그다지 인수인계할 필요도 거의 느끼지  못하지 않을까?

여러가지 이유들이 있겠지만, 최소한 기술에 대한 공유는 다함께 가져가는게 좋지 않을까? 혼자만 알고 있어야 할 특별한 이유가 있지 않는 이상. 완전 공유가 어렵다면(회사 보안 방침상?) 회사 내, 아니 최소한 같은 팀원끼리는 공유해야 하지 않을까 싶다.

그렇게 대단한 기술인지는 모르겠지만 말이다.

2018. 12. 12. 오전 11:17

이젠 사용하지 않긴 하는데, 과거에 계정을 만들어 가상회사로 구성한적이 있다.

처음에는 Google Apps를 만들어쓰다가, Naver 측에서 만든 이 서비스도 나름 괜찮을 것 같아 계정을 만들어서 유지했다. 더욱히 회사에서 갑자기 이메일 서버에 대한 이슈가 생겨 약 6개월간은 이 서비스를 이용하기도 했다. (생각보다는 매우 편리하고 빠르게 동작했다.)

중간에 고객 측에서 클라우드 접속에 대한 보안정책이 생기면서 접속이 되지 않아 다른 서비스로 갈아타긴 했다.

물론 예전에 만들어놨던 계정은 그대로 둔 상태로 방치해 놓고 있었다.

그러다, 결국 12월 01일을 기점으로 서비스 종료 및 데이터 삭제가 왔다.

뭐, 아쉬운 것은 없고(이미 백업도 끝났고) 더 이상 쓸일이 없어서 지금은 그냥 내비두고 있다. Google Apps에서도 무료버전은 더 이상 가입을 받고 있지는 않지만, 이전 가입자에 한해 아직은 무료 버전을 쓰게 해주고 있다.

돈을 벌어야 하는 회사 입장에선 당연한 결과이겠지만, 최소한 10인 미만 회사들을 위해서 무료, 아니 무료가 아니라도 거의 헐값에 가까운 비용으로 이용할 수 있게 했으면 좋았을 텐데 싶다. ( 지금은 1인당 6000원의 서비스로 제공된다.)

돈도 돈이지만, 사실 다양한 케이스의 다양한 경험치들을 모으고 더 많은 사람들이 쓰게 해서 더 나은 서비스를 구축하는게 더 좋지 않을까?

좀 바보 스럽다고 생각한다.

18. 12. 4. 오후 3:08

가끔 컴퓨터 관련 개발자들에 대한 각종 드라마나, 영화, 소설들을 보게 되면, 매우 Greek 한 존재로 나올 때가 많다. 의사 소통 문제를 안거나 대인관계에 심각한 문제를 갖고 있는 경우가 많다. 물론 그런 형태로 갖는 사람들이 적지는 않은 편이다. 꼭 컴퓨터 관련 개발자가 아니라도 다른 분야에서도 보이기 때문이다.그래서 가끔 의사소통 문제 혹은 대인관계의 문제가 있어도 개발자라면 문제가 없다고 간주하는 경우를 종종 보게 된다.

안타깝지만, Boo-Boo(틀렸다) 이다.

혹시 저런 타입이라고 한다면 혼자 개발을 하거나 스스로가 제시한 문제를 해결하기만 하면 모를까, 직장에서 컴퓨터가지고 개발을 하고 있다면 저런 타입인 경우 사실상 일을 못한다고 볼 수 있다.

일단 회사에서 컴퓨터가지고 개발을 한다고 한다면, 제일 먼저 요구사항을 확인하고 분석해야 한다. 문제는 이 요구사항이라는 것이 결국 타인으로 부터 묻고 확인하고 제시해야 한다는 점이다. 아예 시작 부터 타인과의 대화를 하고 대인관계를 유지해야 한다.

아아, 이런 일은 헤더(Project Manager, Leader)의 일이라고 간주하는 경우도 보게 되는데, 안타깝지만 이 역시 Boo-Boo이다. 고객과 대화하지 않더라도, 결국 헤더와 대화를 하고 대인관계를 해야 하는데 이것은 또 어떻게  할 것 인가?

특히나 이 분야의 작업은 무형의 내용을 대화를 통해 구체화를 하고, 개발자의 손에서 유형의 무언가로 만드는 작업이다. 즉 무엇하나 나온 것 없이 서로 대화하고 확인하여 구체화 시키는 작업이기 때문이다. 이 때문에, 아무런 자기 생각도 없이 개발자라고 칭하면 매우 잘못 생각하고 있다는 것이다. 혼자 생각하고 혼자 고민해서 모든 것이 나온다면 좋겠지만, 스스로 보았을 때 스스로가 그 정도 천재라면 모를까, 결국 Stack Overflow나, Code Project 같은 사이트를 참고하여 개발하고 있다면 천재가 아님을 스스로 증명하는 것이다.

최소한 회사를 통해 돈을 받고 개발하고 있는 개발자라면, 제일 먼저 상대와 대화를 하려 노력하고 서로의 의견을 파악할 수 있는 능력을 키워야 한다. 그리고 스스로 무엇을 해야 할지, 어떻게 해야 할지를 고민하고 생각하면서 그 내용을 다시 상대방과 대화를 나누면서 정립해야 한다. 만일 지금도 아무 생각 없이 위에서 받은 지시 내용을 받고, 애매한 지시라고 휙 넘기고 명시된 내용만 짜고 있고, 대화도 거의 안하고 있다면, 개발자가 아닌 그냥 코더 – 그냥 아르바이트 생, 단순 작업 노무자 - 정도라고 생각했으면 좋겠다. 즉 6개월이든 6년이든 교육 받아서 하는게 아니라, 그냥 하루 정도 대충 교육 받고 매일 같은 컨베인벨트에서 매일 같은 동작을 하고 있는 로봇 정도라는 의미다.

가르침이 없어서, 내용을 잘 몰라서, 뭘 해야할지 잘 모른다면, 주변에게 묻거나, 책을 읽거나, 스스로 다양한 관점으로 고민하고 고민하고 생각이나 했으면 좋겠다. 타인들의 유희 활동 다 하고 문화생활 누리면서 시간을 흘려보내지 말고 말이다.

2018. 12. 4. 오후 2:26

이번 광군절을 이용해서 물건을 구매했다.

피규어 인데, 하나는 스파이더맨 다른 하나는 아이언맨이다.

둘째 아들이 요 근래 번개맨과 함께 스파이더맨 노래를 부르길래 이 참에 구매를 했다. 주문은 11일날 했는데, 최종 중국에서 출발한 시점이 19일이라… 거의 포기했는데, 오늘 도착했다고 해서 얼마다 다행인지..

아들 생일이 몇일 남지 않은 시점에 제시간에 도착해서 정말 다행긴했다.
문제는….

아이언맨이 빠졌다.
딱 스파이더맨만 온 상태.
일단 클라임을 걸려면 10일은 더 있어야 된다고 해서.. 일단 대기 중이긴 한데 설마 물건을 따로 따로 보낸걸까???

그래도 다행인점은 아들이 좋아하는 스파이더맨이 와 있다는 점이랄까?

2018. 11. 22. 오후 9:31

2018. 11. 21. 오후 3:43

MS SQL을 통해서 컬럼 전체 정보를 수집하는 방법이다.
이 중, 테이블 이름, 스키마 이름, 컬럼 이름, 컬럼 타입, 컬럼 길이, 기타설명 정도를 표시하는 쿼리다. 만일 전체 내용을 확인하고 싶으면 컬럼 표시한 내용에서 “*” 를 넣어 컬럼들의 내용을 모두 표시한 뒤 확인하는 것도 방법이다.

SELECT 
 tb.name as TBNM, 
 sch.name as SCHNM, 
 sc.name as COLNM, 
 tp.name as COLTYPE,  
 tp.max_length AS COL_LEN,  
 sep.value as DESCT
FROM sys.tables as tb
INNER JOIN sys.columns sc on tb.object_id = sc.object_id
INNER JOIN sys.schemas sch on tb.schema_id = sch.schema_id
INNER JOIN sys.types tp on tp.system_type_id = sc.system_type_id
left join sys.extended_properties sep 
 on tb.object_id = sep.major_id 
  and sc.column_id =  sep.minor_id 
  and sep.name = 'MS_Description'

2018. 11. 21. 오후 3:37

이 내용은 모두 내 편견으로 시작한다. 지금까지 필드를 뛰면서 다양한 사람들과 만나 윗사람으로 아랫사람으로 같이 일을 하면서 느낀점이다. 당연히 전반적인 세대를 대표하는 말이 될 수 없고, 과학적 분석이 아닌 개인적인 느낌적 느낌이라는 점을 밝힌다.

내가 76년 생이다 보니, 보통 70년대 초반분들은 내 상사로 만났다. 물론 일부는 직급상 내 밑으로 오신 분도 종종 있긴 하다.

일단 선임에 대한 대우는 철저하게 챙기는 편이다. 부당한 대우를 받았을 때 가급적이면 뒤로 삭히거나 뒤따마를 깠으면 깠지, 대놓고 반항하거나 뭐라 하지 않는다. 도리어 예의를 갖추어 최대한 챙기는 편 같았다. 수저, 젓가락에서 부터 물 따르는거와 같은 약간 사회내 자체적으로 생긴 룰? 같은 것을 최대한 존중하며 따른다. 말 짧은 것도 용서가 없다. 군대 처럼 까/다까지도 있고, 존댓말은 최대한 활용하여 말하곤 한다. 물론 좀 친해지면 짧아지기도 하지만, 그 단계까지 가는데 좀 시간이 많이 걸리곤 한다.

일을 대하는 태도도 많이 다르다. 다소 부족하거나 부당한 일 맡김이 있어도 나름 끝내보려고 온갖 일들을 수행한다. 사실 여기서도 뭔가 치열하게 진행하는 경우가 많다. 워낙 세대 자체가 인원이 많아서 그런지 경쟁에 대해서도 적극적인 참여를 하고 경쟁에서 지는 것을 억울해 하는 경향이 많다. 그러다 보니 일 접근에 있어 매우 적극적이다. 모르는게 있으면 찾아보고 물어보며 적용해보고, 깨지더라도 꿋꿋한 편이다.

아마도 요즘 IT 업계 내 꼰대라고 불리는 분들이 이 분들이지 않을까?

하지만, 이 분들은 중간에 낀 세대같아서 전 세대 분들의 꼬장 같이 잘 펼치지 못하는게 현재 이지 않을까 싶다. 이 분들이 사원이고, 전세대 분들이 과장, 대리 일때, 험하게 일시키는거 다 받아주면서 일했는데, 지금은 그렇게 시키면 바로 퇴사 각이라 옛날 분들 처럼 못한다고 생각한다.

(물론 그렇다고 예전 분들의 꼬장이 미화되거나 부활 되는건 아니다.)

2020. 5. 18. 오후 5:30

이 내용은 모두 내 편견으로 시작한다. 지금까지 필드를 뛰면서 다양한 사람들과 만나 윗사람으로 아랫사람으로 같이 일을 하면서 느낀점이다. 당연히 전반적인 세대를 대표하는 말이 될 수 없고, 과학적 분석이 아닌 개인적인 느낌적 느낌이라는 점을 밝힌다.

이른바 X 세대. 개성이 톡톡 튀기 시작하는 세대 같다. 물론 노골적으로 개성 넘치지는 못하지만, 최소한 70년대 초반생 분들과 비교해 볼 때, 튄다.

선임을 챙기긴 하는데, 좀 선별적으로 챙긴다. 자신의 마음에 드는 선임을 잘 챙기고 마음에 들지 않을 때는 적당히 예의를 차리거나 무시한다. 간혹 싸가지 없다라는 말을 종종 듣게 된다. 물론 잘 챙기는 선임으로부터는 신임을 받긴 하지만. 그렇지만 대개의 경우 선임의 부당한 요구나 문제점들을 불만을 갖긴 하지만, 하긴 한다. 뒤에서 불만을 표하긴 하지만, 대놓고 표현하기도 한다. 대개 친해지면 다소 말이 짧아지는 경향도 있다.

집단 보다는 개인적인 성향이 서서히 강해진다. 모이라면 일단 모여는 주는데, 불만이 좀 있고, 간혹 아예 단체 활동 회피하는 사람들이 종종 생긴다. 이 경우 마음에 맞는 일부 인원들 끼리 모이는 경우도 많다. 그룹이 만들어진달까?

일을 대하는 태도는 전반적으로 70년대 전반 분들과 유사하다. 좀 진지하게 진행을 한다고 할까? 그렇다고 아주 경쟁적으로 받기보다 다소 선별적으로 받는 것 같다. 100개의 일이 있다면 8~90 정도는 받지만, 부당하거나 마음에 안드는 일은 여러가지 형태로 거부한다. 적극적으로 모르는 부분에 대해서 찾아보고 물어보고 적용은 하지만, 깨지는 경우 2~30%  확률로 감정적으로 대응되기도 한다.

이 쪽도 꼰대 쪽에 붙기는 한다. 70년대 생 전반 분들보다는 적지만, 그래도 “나 때는…” 이 붙는다. 그리고  2~30대 시절 IT 기반 기술이 막 발전하는 시기를 살아오다 보니 최소한 예전 분들보다는 IT 기반 활용이 다소 유리한 편이다.

이 쪽도 다소 낀 세대긴 한데, 80년대 생 쪽의 성향으로 점점 변해가다가 보니, 애매하게 대응 비교된다. 좀 자기 색이 강한 편이다 보니 정해진 대로 하기도 하지만, 대개의 경우 자신만의 루트를 찾아 일을 수행하는 경향이 강하다.  꼰대질도 하긴 하지만, 그 꼰대질이 꼰대질임을 스스로 인지할 수 있는 편이다.

2020. 5. 18. 오후 5:42