sitelink1  
sitelink2  
sitelink3  
sitelink4  
sitelink5  
extra_vars6  

나는 2002년에 월드컵때 대학을 졸업하고

2004년도에 첫 IT회사(N사)에 입사한 후

다음해에 일본 SI시장(I사)에서 일을 하다가

2008년도 중반에 한국에 돌아와 T사의 RND 부서에 15년을 재직하였다.

 

T사의 RND 부서에서도 5년간은 실제 제품 개발에 매진하였고

나머지 10년간은 제품 품질에 대한 요구관리라는 보직으로 업무를 수행하였는데

마지막엔 결국 구조 조정에 따른 권고 사직을 통보 받게 되었다.

내나이 50도 안된 나이에 빠른 권고사직 덕분인지

그동안 나의 시야를 가리고 있던 베일을 빠르게 걷어낸 계기가 되었던 해프닝이었다.

 

T사에 재직중일때만해도 내가 개발하는 제품에 대해서 객관적인 시각을 잠시 가질 기회가 있었지만

지금도 여전히 내가 개발한 프로그램에 대한 평가는 나조차도 매우 혼란스럽다.

 

그 이유는 다음과 같다

 

오늘 우연찮게 내가 한때 자주 갔던 개발자커뮤니티에 내가 개발한 제품에 대한 순수한(?) 악플을 만나게 되었다.

절반은 욕설과 비난이 뒤섞여있어 오히려 발화자가 주장하는 논제가 비난에 촛점을 맞춘것처럼 보였는데

주요 골자는 기술적인 한계에 대한 원색적인 비판이었다.

그리고 그에 대한 댓글들의 내용들도 주욱 살펴봤는데

결론은 알 수 없다였다.

 

제품에 대한 한계는 이미 개발때부터도 알고 있던 내용인데

이를 커버해주는게 시장에서의 인지도로 평가되는 영업력과 정치력이다.

수많은 공공 si 프로젝트에서 채택되어 수많은 개발자들에게 해당 기업의 솔루션 사용을 강요 받아왔던 현실때문에

si 프로젝트를 수행해야 하는 개발 실무자들은 t사의 제품을 울며 겨자먹기로 학습하고 사용해야만 했었다.

 

하지만 그렇다고 무조건적인 비난만 받을 물건은 아니다.

이제 막 전산에 발들이는 개발 신입들에게는 해당 기업의 제품을 이용하면 ui design 작업의 진입 장벽을 낮추어주어 나름 작업 효율성을 많이 높여주었기 때문이다.

다만 그렇게 발들인 후의 문제는... 급격한 상승곡선의 기술 장벽에 맞닥뜨리는데

그 장벽을 넘어서기 위해 필요한 도우미들이(기업의 레퍼런스와 교육) 지극히 제한적이라는데 있다.

심지어 그 장벽 너머에서 오픈소스와 같은 다른 솔루션들은 꽤나 안정적인 모양새이지만

t사의 제품은 도저히 벗어나기 힘든 기술 제약의 늪에 빠져버리게 된다.

 

그런 상황에서도 개인적으로는 조금도 양심의 가책을 느끼진 않았다.

왜냐하면 해당 솔루션의 생태계 안에서 일거리를 찾는 우리 모두는 t사의 제품을 이용하여 지금까지 근근히 생계를 유지해 왔기 때문이다.

삼성이 그렇게 악덕 기업이라고해도 우리의 가정에 삼성 가전 하나쯤은 반드시 있는 것과 같은 이치이다.

 

직접적인 피해자로써 해당 기업의 제품을 일부러 기피하지 않는 이상 자본주의 사회에서 우리는 문명의 이기를(利機) 버려가면서까지 원시인처럼 살 수는 없는거다.

도구가 맘에 안들면 다른 도구로 바꾸면 되는데 그 도구를 쥐어주는 사람이 누구인지가 중요하기 때문에

굳이 도구에 대한 비판적인 자세는 개발자라는 개인의 직업 의식에 있어서도 그렇고 플랫폼으로써 개발 생태계를 만들어낸 기업의 윤리 의식에도 어떠한 의의도 없기 때문이다.

 

도구를 만들어내는 기업은 자신들의 생존을 위해 딱 필요한 만큼만 개선해 나아갈뿐 더이상의 비용은 들이려 하지 않는 것이 인지상정이다.

그래서 자신이 개발자라면 도구가 마음에 들지 않더라도 도저히 회피 할 수 없는 상황속에서

도구의 딱 필요한 부분만 취하는데 만일 도구의 문제점을 찾아내었다면 개발사에 개선을 요청하던가

아니면 스스로 그에 대한 대안을 발굴해 내든가 그것도 아니면 다른 솔루션으로 대체하는 것이 현명한 일이었다.

 

무엇보다 자신의 작업 결과물을 보다 더 높은 수준으로 끌어올리는데에 도구를 가리지 않는 모습이 가장 바람직한 직업 의식일 것이다.

 

그리고 그렇게 더이상 개선이 불가하거나 다른 경쟁 도구들의 사용성에 밀려 무쓸모가 되는 제품은 시장에서 자연스레 사장 될 수 밖에 없을거다.

그래서 이젠 위에 언급한 악플의 내용은 공허한 외침으로만 느껴지고 있다.

번호 제목 글쓴이 날짜 조회 수
공지 Software Development Trend (with Java) 황제낙엽 2024.01.19 592
152 SBOM(Software Bill of Materials) & FOSSLight 황제낙엽 2025.04.04 34
151 현재 유행하는 AI 들을 이용하는 방법 황제낙엽 2025.01.31 55
150 SAP GUI AI Agent를 생성했습니다. 황제낙엽 2025.01.12 65
149 프로그래밍에서 polling 의 의미 황제낙엽 2025.01.05 71
148 [Gemini] server 에서 client 의 function call 를 위한 방안과 특징 황제낙엽 2025.01.03 53
147 Gretty 와 Jetty 에 대하여 황제낙엽 2024.11.01 115
146 naver(네이버) developers에서 제공하는 OAuth REST API 관련 링크 황제낙엽 2023.12.31 98
145 (bing) 소프트웨어의 일반적인 버전 관리 규칙 황제낙엽 2023.10.24 72
144 kakao(카카오) developers에서 제공하는 OAuth REST API 관련 링크 황제낙엽 2023.10.22 107
143 식품(상품) 바코드를 조회하여 제품 정보 획득하기 file 황제낙엽 2023.08.07 286
142 식약처(식품의약품안전처) 공공데이터 API 황제낙엽 2023.08.07 124
141 서비스 이용약관과 개인정보 처리방침 황제낙엽 2023.07.15 66
140 프로젝트 운영 관리 소프트웨어로 100% 자동화된 '데브옵스(DevOps)' 구축하기 (LG CNS) secret 황제낙엽 2023.07.12 65
» 개발자이기 전에 노동자로써의 삶에 대한 고찰 (지극히 개인적인 사설) 황제낙엽 2023.02.28 104
138 [SDC22 키노트 요약정리] 더 쉽게, 끊김 없이 매끄럽게! ‘캄 테크’ 향해 진화하는 미래의 집 황제낙엽 2022.12.24 133
137 변수 네이밍 표기법 종류 file 황제낙엽 2022.11.30 81
136 이미지에서 텍스트를 추출하는 OCR 방법들 file 황제낙엽 2022.09.23 110
135 지수(과학적 표기법, "E") 서식 지정자 (2) 황제낙엽 2021.07.06 139
134 REST API 제대로 알고 사용하기 황제낙엽 2021.06.02 130