Offcanvas

How To / 개발자 / 데브옵스 / 리더십|조직관리 / 소프트스킬

속뜻을 찾아라··· 관리자가 알아둘 만한 개발자 언어 15가지

2018.02.28 Peter Wayner  |  CIO


‘데브옵스’(DevOps)
데브옵스(DevOps)라는 단어는 마치 ‘개발자(Developer)’와 ‘작전(Operations)’의 합성어 같지만, 이는 사실은 코드와 서버 구동을 원활하게 유지하기 위한 프로세스를 일컫는다. 이러한 프로세스는 상당히 복잡해 전문 인력이 요구되고 있다.

그럼에도 불구하고 데브옵스 팀에 업무를 위임하는 프로그래머의 목소리에서 때때로 약간의 우월감이 느껴지는데, 이는 아마 실력 있는 요리사가 테이블 셋팅을 다른 이에게 맡기는 것과 비슷한 감정을 느끼기 때문일 것이다.

프로그래머들은 자신의 임무는 데이터 구조에 대한 독창적이고 좋은 아이디어를 내놓는 것이며 이를 실제로 집행하고 구동하는 것은 다른 이들에게 맡기면 된다는 생각을 가지고 있다. 즉 데브옵스란 개발자들에게 있어 ‘그다지 폼 나지 않는, 하지만 누군가는 꼭 해야 하는’ 일이라고 할 수 있다.

‘API’
시인 로버트 프로스트(Robert Frost)는 프로그래머는 아니었지만, ‘무언가 담을 사랑하지 않는 것이 있어서’(Something there is that doesn't love a wall)라는 그의 문구는 API를 아주 잘 설명해 준다.

프로그래머들이 API를 좋아하는 이유는 다름아닌 분명한 경계와 그 경계를 넘을 시 결과에 대한 분명한 규칙을 제시해 주기 때문이다. 이처럼 확실한 구분 짓기를 함으로써 API 벽 바깥에 있는 이들은 안에서 일어나는 일에 대해 크게 신경 쓰지 않을 수 있게 되었다.

그렇지만 프로그래머가 말하는 API는 단순한 경계 짓기를 넘어서서 ‘통제’에 관한 것일 경우가 많다. API 벽을 만드는 팀이 API 규정도 정하게 되는데, 이로 인해 API를 남용 하기 위해 ‘비 표준적’수단을 사용하는 개발자들에 대한 불만의 목소리가 나오기 쉽다.

물론 다른 이들은 API 팀에서 정하는 액세스 규칙 및 서비스 조건이 보다 오픈되기를 바랄 것이고, 결국 논쟁이 발생하게 된다. 개발자들 사이에 API에 대한 이야기가 나올 때는 어쩌면 API의 장점에만 집중하는 것이 최선일지도 모른다. 프로스트 역시 ‘튼튼한 담장이 행복한 이웃 관계를 만든다’(Good fences make good neighbors)라고 말했던 것처럼 말이다.

‘임무에 더 적합’(Better suited / The right tool for the job)
개발자들은 프로그래밍 언어 및 그러한 언어를 지원하는 코드베이스를 배우는 데 많은 시간을 보낸다. 개발자들에게는 공부가 곧 실력과 몸값 상승으로 이어지기 때문이다. 때문에 개발자가 자신이 잘 아는 것에 대해 열렬히 변호하는 것도 자연스러운 일이다.

어떤 태스크에 X또는 Y가 ‘더 적합하다’고 말하는 개발자가 있다면, 그는 사실 어느 특정 스택에 보다 깊이 뛰어들기 위하여 오래 전 자신이 내렸던 선택을 그저 정당화하고 있을 확률이 크다.

이럴 때 최선의 대응은 그저 고개를 끄덕이고, 웃으며 동의해 주는 것이다. 설령 의견이 다르다 한들, 굳이 논쟁을 해서 얻을 것이 없다. 현대의 프로그래밍 언어들은 모두 역량 측면에서 비슷한 수준을 보이고 있으며 표면적인 차이만을 보이고 있기 때문이다.

예컨대 파이썬을 사용하는 프로그래머들은 파이썬이 괄호 대신 만입을 사용해 코드를 블록으로 분해할 수 있다는 사실을 자랑스러워 할 것이다. 물론 그렇다고 해서 다음 프로그래밍 프로젝트에까지 파이썬을 사용해야 한다는 것은 아니다.

‘범위 추가’(Scope creep)
모든 프로젝트는 처음에 원대한 꿈을 가지고 시작된다. 그리고 운이 좋으면 50% 정도의 완성률을 보이며 막을 내린다. 그렇지만 얼마나 큰 꿈을 꿀 것인가를 정하는 것은 결코 쉬운 일이 아니다. 지나치게 보수적인 태도를 취하다가는 충분히 이룰 수 있는 것도 성취하지 못하고 끝난다. 반면 너무 비현실적인 목표를 세운다면 결과적으로 무엇 하나 제대로 이루지 못한 채 끝날 확률이 높다.

범위추가(scope creep)라는 표현이 있다. 이 표현은 처음에는 충분히 현실성 있는 목표였던 것이 갈수록 이러저러한 부가적인 목표가 더해지면서 점차 불가능한 무언가로 변질되어 가는 과정을 일컫는다. 자꾸만 새로운 아이디어를 더하려는 매니저에게 브레이크를 걸 때 개발자들이 방어적으로 사용하는 표현이기도 하다.

효과가 있냐고? 그럴 때도 있고 아닐 때도 있다. 매니저가 “우리도 욕심을 좀 내 보자” 라는 표현보다 “이대로 하던지 아니면 그만 두라”고 대응해 온다면 방법이 없다.

‘문화적 적합성’(Cultural fit)
부족 사회를 형성하고 무리 지어 전쟁과 사냥을 일삼던 시대는 이제 머나먼 과거의 일일 뿐이라고 생각하는가? 그렇다면 당신은 아마 개발자들이 ‘기업 문화에 부합하는 인재’라는 표현을 어떻게 쓰는지 모르고 있는 것이다.

이 표현은 사실 “나와 꽤 비슷한 사람”에 다름 아니다. 물론 일각에서는 ‘기업 문화에 부합하는 인재’라는 표현이 특정 인종, 성별을 배제할 때 쓰인다고 보고 있지만, 경우에 따라서는 프로그래밍 언어, API 등을 비롯한 기술적 문제에 대한 논의에 쓰이기도 한다. 누구나 자신이 가장 익숙하고 편안하게 느끼는 기술적 툴, 생각, 방식이 존재하며 이러한 ‘익숙한 영역’ 밖에 존재하는 이들을 가리켜 ‘기업 문화에 안 맞는다’고 표현하는 것이다.

‘리팩토링’(refactoring)
프로그래머가 “실수를 시정하겠다”거나 “당장 모든 것을 뒤엎고 새로 하겠다”고 말한다면 스스로의 무능을 인정하는 것처럼 들린다. 하지만 “리팩토링 하겠다”고 말하는 순간 뭔가 매우 과학적이고 대단한 것을 하는 것 같은 느낌을 준다. 그러니 어느 프로그래머가 실수를 시정함에 있어 이 표현을 사용하지 않을까?

‘피쳐’ vs. ‘버그’
프로그래머가 ‘피쳐(feature)’에 대해 얘기한다면 그것은 (아마도 자신이 직접 썼기에) 코드가 마음에 든다는 뜻이다. 반대로 ‘버그(bug)’에 대한 얘기를 꺼내면 이는 (높은 확률로 다른 팀에서 썼기 때문에) 그 코드가 마음에 안 든다는 얘기다.

생각보다 버그를 찾아내는 일은 프로그래머들에게도 쉽지 않은 작업이다. 코드는 스스로를 정의한다. 어떤 개발자들은 아예 버그라는 것은 존재하지 않는다고 말한다. 그저 아직까지 코드가 쓰여지지 않은 유즈 케이스가 있을 뿐이라는 것이다.

이런 철학적 논쟁에 여러분까지 말려 들어가서는 안 된다. 분명한 것은 목표한 작업을 제대로 끝낼 수 없을 때는 그것이 버그이든 피쳐이든 관계 없이 수정되어야 한다는 사실이다.

‘클루지’(Kludge)
클루지(kludge)란 일을 ‘정석대로’ 처리할 충분한 시간이 없어서 임시 방편으로 도입하게 되는 임시 절차를 가리키는 구어적 표현이다. ‘임시땜빵’이라고도 표현할 수 있겠다. 프로그래머들은 일단 클루지로 일을 처리한 후 코드를 더해 리팩토링하려 할 것이다. 그리고 그 다음 팀은 이 프로그래머의 리팩토링을 클루지로 파악하고 또 다른 리팩토링을 하게 될 것이고 말이다. 그렇게 클루지 싸이클은 돌고 돈다.

‘루저’(Luser)
과거 테크놀로지 커뮤니티에는 기술적인 문제는 관련된 교육을 받은 전문가들만이 다룰 수 있으며 이러한 전문성을 갖추지 못한 ‘루저(luser, 비전문가)’들은 다른 일에 신경 쓰는 게 더 낫다는 거만한 태도가 팽배해 있었다. 그러나 오늘날에는 거의 찾아보기 힘들어 졌다. 테크놀로지 플랫폼의 성공이 그러한 플랫폼을 사용하는 노즈의 숫자로 평가되는 마당에 프로그래머가 그러한 태도를 고수하기란 어렵다.

그렇다고 해도, 테크놀로지에 대해 전혀 아무것도 모르는 일반인들의 삶을 편리하게 만들어 주기 위해 과연 개발자가 어느 정도로 노력해야 하는가라는 질문은 남아 있다. ‘대체 능력도 없는 얼뜨기들을 위해 프로그래머의 귀중한 시간을 얼마나 더 낭비해야 하는 것일까? 그럴만한 가치는 있는 것일까?’라는 의문이다. 이를 결정하는 것은 결국 관리자의 일이다. 이런 결정을 맡겨 놓는다면 JSON 데이터 스트럭처가 정규 표현으로 가득해지는 모습을 보게 될 것이다.

* Peter Wayner는 16권의 기술 서적을 저술한 작가이자 인포월드 전문 기고가다. ciokr@idg.co.kr 

CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.