top bar

글 목록

레이블이 etc인 게시물을 표시합니다. 모든 게시물 표시
레이블이 etc인 게시물을 표시합니다. 모든 게시물 표시

2020년 1월 29일 수요일

오랫만에 하는 생각 정리

 잘 나가던(내가 아니고) E-커머스 회사의 개발자 생활을 마치고, 현 직장으로 이직한지도 1년하고도 몇개월이 지났다. 이직한 곳은 대기업 통신사. 이직을 결심했을 당시 주변 사람들에게 가장 많이 들었던 말은 ‘그 회사는 내가 행복한 곳이 아니라 내 가족이 행복한 회사’라는 것이었다. 뉘앙스를 조금만 생각해봐도 알겠지만 다소 부정적인 이야기였다.

직장인으로서 행복이 뭘까. 아니, 개발자로서 행복은 뭘까. 이 부분에 대해서는 나 자신만의 확고한 신념이 있다. 물론 정답은 아니겠지만.

 나는 소프트웨어 개발을 좋아한다. 0과 1로 이루어진 컴퓨터 세상이 흥미롭고, 내가 노력과 공을 들여 작성한 나름 깔끔하고 우아한(?) 코드가 ‘제대로’ 동작할 때 희열을 느낀다. 클라우드 기반의 MSA가 대세인 요즘 (한편에는 모놀리식으로 돌아가자는 이야기도 있긴 하지만...), 관련하여 다양한 기술스택을 배우고 적용하는 것 또한 재미있는 도전 거리이다. 아마 죽을때까지(?) 공부해야 할 것 같은 컴퓨터 공/과학의 이론들도 빼놓을 수 없겠다. 마지막으로 방금 열거한 모든 지식을 동료들과 공유하고 함께 성장 한다면, 개발자로서 이보다 더 기쁘고 성취감이 있는것은 세상에 없지 않을까.

이러한 생각들에 비추어 볼때, 과연 내가 현재 근무하고 있는 곳은 개발자로서 이러한 성취감과 행복을 느끼게 해주는 곳일까? 그동안 느꼈던 몇가지를 짧게 정리하고자 한다.


“여기 직접 개발 하나요?”



 면접 말미에 ‘궁금한 점 없어요?’에 대한 내 질문이었다. 아마 많은 사람들이 이 회사의 ‘개발 조직’에 대하여 같은 의문을 품을 것이라 생각한다. 왜냐하면 이 회사의 ‘소프트웨어 개발’ 이라고 하는 것은 거의 대부분 ‘외주 개발’이라고 소문이 나 있기 때문이다. 하지만 다행히도 돌아온 답변은 '네 개발 많이 합니다’ 였다.

 이 회사에서 말하는 것은 바로 ‘내재화’. 뭐 쉽게 말하면 서비스 개발을 이 회사에 소속되어있는 개발자들이 ‘직접’ 한다는 거다. 입사를 하고 몇달을 지내다보니, 내가 들었던 답변은 확실히 맞는 말이었다. 물론 한창 개발자들을 여기저기서 뽑고 있는 상황이었기 때문에 인력이 부족할 수 밖에 없었고, 이를 (같은 계열사인) ‘Business Patner'의 인력들로 대체하기는 했다. 하지만 (내가 우려했던) 그들에 대한 일방적인 ‘관리’를 한 것이 아니라, 동료로서 함께 개발 업무를 진행했다는 것은 참 다행스러운 일이었다.

 그럼에도 불구하고, 내가 속한 조직과 또 몇몇개의 조직을 제외하면 서비스 개발의 거의 대부분이 아직까지도 ‘외주 업체’의 의존도가 높은 것이 사실이다. 태생이 IT 서비스 회사가 아닌 소위 말하는 ‘텔코(Telco)’이기 때문에, 회사의 이러한 행보가 하루아침에 변화 할 수 없다는 것을 감안하더라도 아쉽기는 하다.


열려있는 다양한 기술스택



 대기업에서는, 기존 서비스를 보다 ‘더’ 안정적으로 운영하기 위해 요즘 유행하는 도구나 기술에 대해 보수적인 태도를 취할 것이라 생각했다. 하지만 막상 내가 있는 조직의 기술 스택을  살펴보니 내 생각이 조금은 틀렸다는 것을 알게 되었다. 대부분의 주요 컴포넌트들이 'Spring Boot’로 구동되고 있었고, RabbitMQ와 Kafka, Redis 등 각종 미들웨어 뿐만 아니라 'Spring Cloud'에서 제공하는 다양한 도구들을 이용한 소규모 MSA 아키텍쳐까지 존재했다. 조금 투박하긴 하지만 Jenkins + Ansible 을 이용한 배포는 나름 편리했으며, 로깅과 모니터링을 위해 구축되어 있었던 ELK, TICK 스택의 도구들 또한 견고했다. 또 조만간 AWS나 GCP 등 Public Cloud를 도입할 것이라는 이야기가 들려오고 있다.

 뭐 여기까지는 새롭다고 하기엔 요즘 여러 회사들이 으레 사용하는 기술 스택(또는 플랫폼)이지 않느냐 라고 할수 있을지 모른다. 하지만 내가 이 회사에 입사해서 생각보다 새로운 기술적용에 열려있다고 강하게 느낀 것은 바로 ‘스칼라’ 였다. 내가 속한 팀이 담당하고 있는 대중교통 시스템에는 다양한 컴포넌트가 있는데, BIS (Bus Infomation System)도 그 중 하나이다. 이름에서 알 수 있듯이 버스의 실시간 위치정보와 도착정보를 제공해주는 녀석이다. 당연히 대중교통 서비스에서 굉장히 중요한 축을 담당하고 있는 이 컴포넌트가 전부 다 ‘스칼라’로 되어 있었다.

 스칼라가 이제 막 출시한 따끈따끈한 언어는 아니다. 하지만 여전히 자바와 스프링이 주류인 한국 IT 업계로 비추어 볼때, ‘대기업’인 이 회사에서 ‘비주류’인 언어로 중요한 컴포넌트를 구축했다는 것은 놀라운 사실이었다. 물론 이것은 어디까지나 내 기준. (스칼라 도입의 히스토리와 그 효과는 논외로 하겠다)


개발문화는?




출처:  Wikipedia

 ‘문화’라는 단어는 위에서 언급되는 것처럼 수많은 컨텍스트에서 달리 해석되는 묘한 단어이다. 한편, 개발자들 사이에서도 ‘개발 문화’라는 말은 오래 전 부터 그들만의 의미체계를 가지고 있어왔다. 그렇다면 이 ‘개발 문화’는 무엇일까?

 지극히 사견일 수 있지만, ‘개발 문화’는 ‘좋은 품질의 소프트웨어를 ‘함께' 만들고자 하는 일련의 행동’이다. 모두가 잘 아는 ‘코드리뷰’나 ‘Pair Programming’에서 부터 여러가지 효과적인 설계 방법론의 도입, DevOps와 SRE에서 말하는 수많은 원칙과 도구들, 그리고 ‘애자일’까지.. (언급하지 않은 모든 것들 포함) 이 모든 것들이 결국은 좋은 소프트웨어를 만들고 유지보수 하기 위한 좋은 개발문화 속에 있는 것들이 아니던가.

 사실 위에서 언급한 요소들을 완벽하게 실천 및 적용하는 조직은 많지 않을 것이라 생각한다. 그만큼 좋은 ‘개발 문화’는 쉽게 바꿀 수도, 만들어 낼 수도 없는 것이다. 다만 이러한 것들을 ‘추구’하는 분위기라면 이야기가 다르다. 처음엔 뜬구름 잡는 소리처럼 들려도, “좋은 품질의 소프트웨어를 만들고자 하는 일련의 행동”들을 추구하고 권장하는 문화에 속해 있는 개발자의 사고는 거기에 맞추어 지기 마련이며, 그것은 개발자 개인의 성장과 그것을 통한 조직의 성장, 서비스의 성장으로 귀결된다. 요즘 많은 메이저 IT 회사들이 ‘기술 블로그’나 여러 기술 세미나를 통해 자신들만의 개발문화, 즉 ‘분위기’를 홍보하는 것은 바로 이런 것들을 어필해서 좋은 개발자들의 이목을 끌려는 목적이 크다고 본다.

그래서 이 회사의 개발 문화는 어떠할까? 사실 ‘전사' 차원에서 ‘개발자’와 ‘기술’을 중시하는 문화를 장려하고 있진 않은것 같다. 그래서 이 회사의 개발문화에 대해서는 딱히 할말이 없다. 하지만.. (아래 계속...)


좋아질 것 같다.



 위에서도 언급 했지만 내가 속한 개발 조직은, (내가 알기로) 대략 17년도 말 즈음에 조직 재정비를 시작하여 18년도, 그리고 작년 19년도에 굉장히 많은 개발자를 채용했다. 특히나 N사, K사, C사, W사 등 이름만 대면 알만한 IT 회사로부터 좋은 개발자 분들이 많이 오셨다. 물론 유명 IT 회사 출신이라고 무조건 좋은 개발자라고는 할 수는 없겠으나, 그래도 기술을 중시하는 기업문화 또는 개발문화를 경험한 분들이 많다는 것은 긍정적인 변화의 가능성을 높일 수 있는 것이라 생각한다.

 작년 말 조직 개편으로 인한 어수선한 분위기 속에 반가운 메일을 받았다. 조직 내 어느 한 팀에서만 비정기적으로 시행 하던 ‘Tech Meetup’을 이번에 조직 전체로 확장하게 되어서 세션 발표자와 참석자를 모집한다는 내용이었다. ‘기술 공유’ 또한 아주 좋은 개발 문화의 한 요소라고 생각하기에, 매우 환영 할 만한 일이었다.  게다가 더 큰 범위의 기술조직 차원에서 ‘Tech Culture’를 개선하려는 움직임도 보인다. 이러한 일련의 상황들로 비추어 볼때, '개발 문화'는 계속 좋아 질 수 있지 않을까?


정리


그래서, 글머리에 썼던 '이 회사는 개발자가 다니기 행복한 회사인가?'라는 자문에 대한 자답은, '잘 모르겠다'이다(...). 조금은 허탈한 결론일 수 있겠지만, 그만큼 '행복'이란 것은 어떤 특정한 환경이나 상황으로 쉽게 정의할 수 없다는 것이 내 생각이다.

 결론적으로, 주어진 환경에서 내가 할 수 있는 최선을 다해 일하고, 동시에 나만의 행복을 찾아가는 것이 필요하다는 생각이 든다. 물론 필요하면 어떤 방식으로든 환경을 바꿀 수 도 있다.

 몇년전(...)까지만 해도 나름 열심히 블로그 포스팅을 했었다. 뭐 그때도 내 블로그를 찾아오는 사람들은 많지 않았지만, 누가 보지 않더라도 글이 하나 둘씩 차곡차곡 쌓여가고 내가 공부한 것이 내 것이 되는 것을 느낄때 참 즐겁고 뿌듯했던 기억이 있다. 배우고, 공유하고, 적용하는 것. 그것이 내가 추구했던, 지금도 추구하는 행복임을 다시금 떠올리며 글을 마친다.





2017년 7월 19일 수요일

[잡담] 기술 말하기

커뮤니케이션과 기술 글쓰기



몇년전에 친구녀석이 나에게 이런말을 한 적이 있다.

"IT 개발자는 거의 혼자 하는 일이 많지 않아?"

워딩은 위와 비슷했지만 그 뉘앙스는 마치, "개발자들은 사무실 구석에 박혀서 혼자 일에 몰두하는 히키고모리 아니냐"라는 느낌이어서 상당히 불쾌 했었던 기억이 있다. 그 말에는 별다른 반박을 하지 않고 넘어 갔었다. (한마디 해줄껄.. ㅋㅋ)

단언컨데, 개발자는 '커뮤니케이션 능력'이 가장 중요하게 여겨지는 직업들 중 하나다. 실무에서 다루는 코드베이스는 보통 엄청나게 거대한 데다가, 보통 작게는 십수명에서부터 수십명의 개발자가 하나의 형상관리 저장소를 바라보고 (물론 Git과 같은 분산 버전 관리 시스템이라면 각 로컬에 저장소를 clone 하겠지만, 결국 원격 저장소는 하나다.) 업무를 진행하게 된다. 때문에 조직내의 안정화 된 룰을 기반으로 한 실무자간의 효율적이고 명확한 커뮤니케이션이 없을 때 프로젝트가 엉망진창이 될 것은 안 봐도 비디오다.



* 브랜치 중심의 개발
git 기반의 개발 프로세스 에서는 수많은 개발자들이 브랜치를 만들고 삭제하고 
Merge하는 일이 수도 없이 일어 난다. 그것도 하나의 코드베이스를 가지고 말이다.


내가 직전에 근무했던 회사 대표님은, 코드의 품질을 아주 많이 강조하는 분이셨다. 그분은 그것과 동시에 '기술 글쓰기' 도 중히 여기셨는데, '기술 글쓰기' 사내 교육을 만들어 개발자들로 하여금 필수로 수강하게 할 정도였다. 이는 방금 위에서 언급한 "커뮤니케이션"과 맥락을 같이 한다.

요즘 중소기업에서부터 대기업, 각종 벤처회사에 이르기까지 회사 업무의 대부분이 전산화 되어있고, 주로 '이메일'을 주고 받으며 소통을 한다. 특히나 개발자들간의 이메일을 통한 커뮤니케이션은 "기술 글쓰기" 그 자체다. 따라서 이러한 글쓰기에 능숙하지 않으면 서로 각자의 메일 본문을 이해하기가 힘들게 되면서 메일 핑퐁이 늘어나게 되고, 업무 효율은 그만큼 떨어 질 수 밖에 없다.


기술 말하기



'기술 글쓰기'는 이만큼 중요하다.
하지만 나는 더 나아가 '기술 말하기'에 대해서 이야기 하고 싶다.

예를 들어, 'AOP'에 대해서 말로 설명한다고 해보자.
분명히 아래처럼 말하는 사람이 있을 것이다.

"메서드의 앞뒤로 무언가 작업을 하게 해주는 거 아니에요?"

당연히 틀린말은 아니지만 아주 많이 부족하고 '허접'한 설명이다. 만약 경력이 적지않은 개발자가 이런식으로 말을 한다면 실력을 의심해야 할 필요가 있다. 좀 더 정확한 설명은 아래와 같을 것이다.

"'횡단 관심사'를 모듈화 하여 여기저기 산만하게 퍼져있는 코드의 중복을 제거하고, 단일책임원칙(SRP)에 충실한 클래스를 설계하는데 도움을 준다. 흔히 AspectJ나 Spring AOP가 많이 쓰이며, Advice를 작성하고, Pointcut을 설정하여 적용하게 된다. 보통은 트랜잭션 이나, 로깅, 인증 처리에 사용된다."

물론 위의 문장도 완벽하게 AOP를 설명하고 있지는 않지만,
'전자' 보다는 확실히 명확하고 기술적인 말하기다.

종종 '기술 글쓰기' 보다 '기술 말하기'를 더 많이 해야 할 때가 있다. 메일로 글을 주고 받는 것보다 직접 찾아가 말로 설명하는것이 때로는 훨씬 빠르고 정확하기 때문이다. 하지만 '빠를' 수 는 있을지언정 '정확'하게 전달하기란 쉽지 않다. 이 때문에 '기술 말하기'의 중요성을 강조하고 싶은 것이다.

물론 어려운 일이다. 나 스스로도 항상 커뮤니케이션에 신경 쓰려고 노력하고, 대화 할 때 좀더 정확하게 전달 될 수 있는 단어와 용어를 선택하려고 애쓰지만 잘 안될 때가 많다.

그러니까 이 글은, 나 자신에게 바치는 글이 되겠다.
더 노력하고 더 내공을 쌓아야 한다.


2016년 3월 10일 목요일

고통은 결속을 낳는다.

 대륙을 횡단 하면서 가장 기억에 남는 날은 조슈아 나무 국립공원을 지나던 날이었다. 나는 일행에서 50킬로미터쯤 뒤처져 있었는데, 기온이 40도에 육박해서 그늘을 찾지 않을 수 없었다. 16킬로미터쯤 더 가자, 기찻길 옆으로 금속 지붕의 헛간이 하나 나오고, 헛간 옆 콘크리트 위로 15센티미터 가량의 그늘이 떨어져 있었다. 머리를 그늘로 가게 해서 몸을 뉘었다. 훅훅 더운 바람이 끼쳐 왔다. 그저 잠시 해를 가리기만 하면 되었다. 

 80킬로미터나 더 가야 한다는 것과 어쩌면 그 구간이 내 평생 최악의 고통일 수 있음을 알았다. 하지만 그곳에서 나는 '이야기'를 떠올렸다. 갈등이 아무리 힘들지라도 주인공이 용감히 운명에 맞선다면 결국 모든 갈등이 그에게 복으로 돌아온다는 사실을 떠올렸다. 인간이 견뎌내서 복이 되지 않을 갈등이란 없다. 씩 웃음이 났다. 즐거웠다는 말은 아니지만 왠지 웃음이 났다. '지금은 힘들지만 소중한 추억이 될 거야.' 그런 생각이 들었다. 
그리고 정말 그렇게 되었다.

                                                                                                        <천년동안 백만마일 中>