Thoughts2020. 4. 19. 06:50

그러니까 요약하자면 전자파의 유해성, 또는 인간에 대한 영향을 주장하는 대부분의 연구는 통계적 근거가 박약한 헛소리로 받아들여져 왔다는 겁니다. 물론 앞으로도 그럴 거구요. 이제 인류는 전자기파의 직간접적 혜택이 없이는 살아가기 어렵습니다. 그러니 그 이득을 압도할만한 확실한 증거가 나오기 전까지, 대부분의 우려는 그저 '통계적으로 무의미한' 주장으로 간주되고, 사람들이 '증거'라고 믿는 사건들은 그저 '사례'로 치부될 겁니다.

 

그런 사례 몇 가지 들어보실까요?

 

2018년 7월에 미국 콜로라도에서 본인이 '특별한 능력'을 갖고 있다고 주장하는 한 대학원생이 무작위로 선택한 20군데 장소에서 가장 가까운 기지국 위치를 '감으로' 알아내는 실험을 합니다. 결과의 정확성을 주정하기 위해 눈은 가렸고, 운전은 친구가 하도록 했으며, 본인은 대략적인 방향만 지시했죠. 그런데 그 결과가 아주 놀라왔습니다. 20번 가운데 18번을 맞춘 거에요. 

 

2019년 6월에는 '무선통신 알러지'가 있다고 주장하는 한 소년의 이야기가 대한민국 공중파에서 방송됩니다. 이 소년은 LTE 신호가 잡히는 곳에서는 살 수가 없다고 주장했는데, 검증을 시도한 리포터가 소년과 함께 기지국 근처로 가자 소년의 피부에서 접촉성 알러지 환자에게서 흔히 보이는 반응이 나타나 사람들을 놀라게 했죠. 결국 그 소년은 도시를 떠나 무선통신 신호가 쉬이 잡히지 않는 변두리로 이사를 가야만 했어요.

 

이런 이야기를 들으니 무슨 생각이 드시나요? 저는 현대적인 교육을 제대로 받은 개인이라면 이런 이야기들은 그저 흥미거리로만 들어 넘겨야 '정상'이라고 생각합니다.

 

실제로 첫 번째 사례의 경우, 실험의 모든 과정을 유튜브로 공개했는데 덧글을 보면 진지한 반응은 거의 없었어요. 대부분이 그 실험을 마술 공연 취급했죠. 그와 다른 의견을 가진 이들은 미친 사람들 취급을 받았는데, 실험을 진행한 당사자들조차 그런 반응에 가타부타 말이 없었고 실험의 진실성을 어떤 식으로든 방어하려 들지 않았기 때문에, '마술일 뿐'이라는 의견은 곧 대세가 되었습니다. 

 

두 번째 에피소드의 경우에는 좀 더 심해서, 프로그램이 방영된 후 한두달 뒤에는 아무도 그 일을 기억하지 않을 지경이 되었죠. 그 소년이 소개된 프로그램 자체가 아무 주제나 일회성 가십으로 만들어 버리기로 악명 높은 프로그램이어서 그랬던 것도 있고, 프로그램이 소년을 다룬 방식 자체가 워낙 진지하지 않았기 때문에 시청자 입장에서는 그 현상이 어떤 사회적 중요성을 갖는지 되돌아 볼 필요가 없어서 그렇기도 했습니다. 그런 반응에 실망한 부모가 뒤이은 관심을 아예 거부해 버린 탓도 있고요.

 

그래서 그런 사건들에 대한 제 생각은 뭐냐고요?

 

저도 현대적인 교육을 꽤 오랫동안 '제대로' 받은 개인이니까, 사실 그런 사례들을 다른 방식으로 소비할 이유는 없죠. 하물며, 제 인생에 무슨 대단한 여유가 있길 하나요, 아니면 그런 사례들을 통계적으로 유의미한 수준의 연구결과로 정리해야만 할 사명같은게 존재하길 합니까. 이 일에 꾸준한 관심을 둬 본들, 저 뿐만 아니라 이 세상에도 아무런 실익이 없는 거에요.

 

그래서 내 생각은 아주 명확하고, 이런 일들을 대하는 내 자세도 단순해요. 지금 보고 계신 이 기록들에는 아무런 가치도 없다는 것이죠. 그러니 그저, 세상에 이런 일도 있습디다, 정도로 들어 두시는게 맞아요. 거기 동의하시면, 제가 그 소년을 찾아갔던 이야기도 들려드리죠.

Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2020. 4. 14. 12:48

인간의 중추신경계와 부신수질 내에 니코틴에 반응하는 리셉터들이 존재한다는 것은 꽤 잘 알려진 사실입니다. 저는 이런 리셉터들이 대체 언제부터 인간의 몸에 자리하게 되었는지에 대해서는 별 관심이 없습니다. 그러니까 그 부분에 대해서는 이야기하지 않기로 하지요.

 

사실 리셉터, 혹은 수용체라고 불리는 것은 간단하게 보자면 일종의 스위치입니다. 특정한 화학 물질에만 반응하는 스위치. 인체에 특정한 종류의 물질이 흘러들면, 딱 하고 그 스위치가 켜지는 거죠. 이 스위치는 세포 내부와 연결되어 있어서, 스위치가 켜지면 그 세포가 동작하는 방식에 변화가 생깁니다. 니코틴의 경우에는 이 변화가 혈관을 수축시키기도 하고, 신진대사를 다소 빨라지게도 합니다. 중요한 것은, 리셉터가 반응한 결과로 내 몸에 유의미한 변화가 생긴다는 것이죠. 

 

이 유의미한 변화를 우리는 신호 전달 과정으로 해석할 수도 있습니다. 다시 말해, 세포 밖에서 일어나는 세건을 세포 안에서 해석 가능한 신호로 변환하여 전달하는 과정요. 인간의 감각 기관은 바로 이 신호 전달 과정, 그러니까 수용체가 구현하는 신호 전달 과정 위에 구축되어 있어요. 빛이라는 외부 신호가 시신경이 해석 가능한 신호로 변환되어 전달되는 체계가 없었다면, 우리는 세상을 볼 수 없었다는 겁니다.

 

그럼 이제 전자파 이야기로 돌아가보죠. 전자파, 그러니까 인간이 인공적으로 만들어 낸 이 파장이 신체에 어떤 식으로든 영향을 미칠 수 있다는 이야기는 오래전 부터 나왔습니다. 물론 그 중 상당수는 과장되어 있거나 허위죠. 가령 전자레인지가 돌아가는 동안에는 그 주변에 있으면 곤란하다거나.

 

이런 난감한 주장의 상당수는 전자파에 대한 일종의 미신적 공포에서 비롯된 것입니다. 이런 전자기파들이 우리 일상을 지배하기 시작한 것은 인류 역사에 있어서 최근에 집중적으로 일어난 사건이에요. 잘 알지 못하는 것에 하루종일 둘러싸여 산다는 것. 충분히 두려울 수 있는 일이에요. 과학적으로는 용납하기 힘든 일이지만요. 

 

아무튼 그래서, 그러니까 전자파가 정말로 인체에 영향을 미치는 것인지 과학적으로 검증하기 위한 연구도 나름 오랫동안 진행됐습니다. 특히 와이파이 같은 무선 통신 기술이 인체에 미치는 영향에 대한 연구는 많았죠. 그러나 이런 연구 대부분이 어떤 유의미한 통계적 결과를 얻어내지는 못했어요.

 

몇가지 종류의 수용체가 무선통신 기술에 쓰이는 전자기파의 간접적 영향권 내에 '있을 수도 있다'는 것 정도를 주장하는 연구는 있었습니다. 가령 이런 것이죠. 와이파이 신호에 과다 노출되면 특정 종류의 스트레스성 자극이 신체에 가해지고, 그 덕분에 신체에서 특정 종류의 화학 물질이 만들어지기 시작하며, 그런 물질들이 특정한 리셉터들을 자극하기 시작하면 우리 몸은 이런 저런 방향으로 변화하기도 한다는 것 말이죠. 그런데 그건 곧 무선통신 신호에 반응하여 특정 종류의 화학 물질을 만들어 내라는 신호를 우리 세포에 전달하는 리셉터도 있다는 뜻 아닌가요? 맞습니다. 그런 수용체가 있을거라고 간접적으로 추론해 볼 수 있죠. 그러나 '있을 수도 있다'고 말씀드린데서 짐작하시겠지만, 이런 연구들 가운데 어떤 통계적 유의미성에 도달하거나, 가시적이고도 확증적인 결과를 제시한 데 성공한 연구는 거의 없습니다. 특정 파장의 전자기파를 지속적으로 쪼였더니 거의 몇 퍼센트의 확률로 뭐가 어떻게 되더라, 여기까지 도달한 연구가 없었다는 거죠. 

Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2020. 4. 12. 04:45

"원고 하나를 처리해 줄 것을 부탁했어요."

 

그녀가 건축가 선생에게 관리해달라고 부탁한 것은 집 하나 뿐만이 아니었다. 

 

"비밀번호는 아실 거라고 하더라구요."

 

그는 오륙년은 족히 되었음직한 큼지막한 랩탑을 내게 건넸다. 내가 비밀번호를 알고 있을 거라고? 잠시 당황했으나 답을 알아내는 데는 시간이 오래 걸리지 않았다. 내가 그녀와 친밀한 사이가 아니라는 것, 그리고 그녀와 나눈 이야기들이 그렇게 많지 않다는 것이 큰 도움이 되었다. 

 

"아, 네."

 

"그리고, 이 옆 방을 쓰시면 됩니다."

 

그러니까 내게 주어진 임무는, 최대 한 달 가량을 그녀의 집에 머물면서 그녀가 생전에 남긴 원고가 잘 '처리' 될 수 있도록 하는 것이었다. 그러나 대관절 그 '처리'라는 것은 무엇을 의미하는가. 출판인가, 폐기인가, 아니면 그도 저도 아닌 다른 어떤 것인가. 그것은 온전히 내게 맡겨져 있었다.

 

건축가 선생이 떠나고, 나는 서쪽으로 큼지막한 창이 나 있는 방에 짐을 풀고, 샤워를 하고, 장을 보고, 노트북을 켰다. 그리고 "아니오"를 패스워드로 입력했다. 패스워드 입력 창 아래 있는 "패스워드 잊음?"이라는 질문에 대한 답이었다. 

 

- 제가 가장 좋아하는 소설에 이런 대목이 나와요. 중요한 비밀이 숨겨진 컴퓨터에 로그인해야 하는데, 컴퓨터 주인이 무슨 비밀번호를 썼는지 모르는 거죠. 그래서 그 주인공의 생일, 가족 이름 등등 생각할 수 있는 거의 모든 정보들로 잠금을 풀려고 시도하는데 잘 안되는 거에요. 그렇게 하루 이틀 일주일을 썼다고 생각해 보세요. 당연히 열이 받겠죠? 그래서 "패스워드를 아십니까?"하고 묻는 컴퓨터에게 홧김에 "no"라고 답을 해 버렸는데, 맙소사. 그게 비번이었던 거에요.

 

- 아니 비번 이야기까지 나한테 해도 되는 거에요? 내가 기사에 실어 버리면 어쩌려고.

 

- 제가 좀 쓸데 없는 말이 많아요. 그리고 작가가 열 명이나 되는데 이런 이야기까지 실을 지면이 있으세요?

 

잠금이 해제된 계정의 '내 문서' 폴더에는 '리셉터'라는 디렉터리가 있었고, 그 안에 그녀가 남긴 원고가 있었다. 창밖은 어둑해져 있었고 거리는 고요했다. 컵라면 냄새가 방안에 퍼지는 것을 느끼며 나는 컴퓨터 앞에 앉은 생전의 그녀 모습을 떠올렸다. 그녀는 창작의 재료를 주로 꿈에서 얻는다고 했다. 뭔가 이상한 꿈을 꾸면 그 꿈에 대해 한참을 고민하고, 그 의미가 무엇일지 고민하게 된다고 했다. 그래서 특기는 낮잠이요, 취미는 몽상이라고도 했다. 

 

하지만 사뭇 귀엽기까지 한 그 취미와 특기에 어울리지 않게, 그녀가 남긴 원고의 문체는 이번에도 건조하기 짝이 없었다. 나는 컵라면 하나와 맥주 두 캔을 비우며 그 원고를 읽었다. 내용인 즉슨 이러했다. 

Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2020. 4. 10. 07:51

그래서 그녀와 20년을 동네 친구로 지낸 건축가 선생님은 두 달 간 그 방을 깨끗이 개조해 주었고 그녀는 그 방에서 세상의 모든 신호와 차단된 채로 혼자만의 조용한 죽음을 맞이하게 된 것이었다.

 

몇 명의 친구들, 그러니까 생전의 그녀가 부르기만 하면 만사를 제쳐두고 달려올 정도의 친구 몇 명은 그녀가 세상을 등진 후 며칠 뒤에 그녀 명의로 배송된 등기 우편을 받았다. 그 내용인 즉슨, 편지를 받는 대로 자기 집에 한 번 들러 달라는 것이었다. 스마트폰을 이용해 전달하는 것이 훨씬 어울릴 정도의 간단한 편지여서, 모두는 바로 무언가 잘못되었다는 것을 알아차렸다.

 

장례식은 간소했지만, 그녀의 유해가 납골당에 안치된 이후에도 친구들은 그녀가 유서에 남긴 소망들을 들어주기 위해 바쁜 시간을 보내야 했다. 그 중 첫 번째가 바로 그녀가 남긴 그 집의 소유권 문제를 처리하는 것이었다. 그녀는 그 집의 등기를 친구들 몇 명 앞으로 돌려놓기를 원했는데, 조건이 있었다. 2045년이 오기 전까지는 처분하지 말 것과, 아무도 실제로 거주하려 들지 말 것. 또한 유서에 나열된 사람들은 일정이 중복되지 않는 한 언제든 숙소로 이용할 수 있도록 배려할 것이며, 집의 관리 책임은 집을 개조하는 데 도움을 준 건축가 선생에게 맡길 것 등이었다. 조금 당황스럽긴 했지만, 내 이름도 그 가운데 있었다. 

 

나는 그녀와 친밀한 관계였던 적이 없었다. 시애틀로 이주한 다음에는 더더욱 그랬다. 가끔 페이스북을 통해 안부를 묻는 정도의 친분을 유지하긴 했지만, 그녀와 나의 관계는 어디까지나 공식적으로만 존재하는 어떤 것, 그러니까 사적인 냄새라고는 없는 어떤 것이었다. 내가 그녀와 친분을 맺게 된 것은 2015년의 여름. 그러니까 내가 '주목할만한 신간' 면의 담당 기자로 일하고 있었을 때였다. 당시 열 명의 신출내기 SF 작가들이 모여 거의 자비 출판에 가까운 형태로 작품집을 출간했는데, 그녀의 단편이 거기 있었다. 

 

그녀의 단편은 인공 지능이 세상을 어떤 과정으로 집어삼키게 되었는지에 대한 역사서 형식을 띠고 있어, 전통적인 소설과는 거리가 멀었다. 소설이라면 응당 따라야 할 전통적 형식미의 가치를 중요하게 따지는 사람이라면 거부감을 느낄만한 형태였다. 하지만 다루는 사건의 내용에는 자못 흥미로운 구석이 있었다. 간단히 요약해 보자면 이렇다.

 

사건의 무대는 2024년. "텅빈 물탱크"라는 장편 소설이 출간되어 베스트셀러가 된다. 줄거리에는 다소 난해한 구석이 있으나 사건의 매듭을 풀어나가는 데 있어 기호학을 활용하는 품새가 에코를 연상시키는 맛이 있고, 다소 신경증적인 주인공의 내면을 탐구하는 문체가 가히 거장의 그것이라는 평을 받은, 단연 독보적 화제작이었다. 당연히 작가에 대한 관심도 높아졌으나, 출판사는 작가와 맺은 협약을 이유로 들어 그에 대한 어떤 정보도 공개할 수 없다는 기본 방침만 반복할 뿐이었다. 문체의 유사성, 단어 선택상의 버릇 등을 증거로 실제 작가를 맞춰 보려는 시도도 여러 번 있었으나, 당연하겠지만 그 중 어떤 것도 확증될 수는 없었다. 그러나 소설이 출간된 지 1년이 지난 뒤, 한 통계학 박사과정 학생에 의해 그 작가의 실체가 밝혀지게 된다. 제임스 미치너의 팬이었던 그 학생은 "텅빈 물탱크"가 제임스 미치너의 "소설"이라는 책 에 등장하는 가상의 작품명이라는 데 착안, "소설"에 쓰인 단어와 그 출현 빈도를 계산하여, 그것을 "텅빈 물탱크"에 쓰인 단어 및 그 사용 빈도와 대조하기에 이른다. 결과는 100% 일치. 그 결과가 의미하는 바는? "텅빈 물탱크"는 단순히 "소설"에 쓰인 단어를 임의의 방식으로 재조합한 것일 뿐이라는 것이었다.

 

기술적으로 가능한 이야기인지의 여부는 둘째치고, 그런 상상의 사건을 만들어 내는 능력에는 눈길을 끄는 데가 있어서, 나는 그녀와의 인터뷰에 조금 더 많은 시간을 썼다. 내가 그녀에게서 받은 첫 인상은, 그러니까 앞서도 말한 것 같긴 하지만, 선량한 사람, 그리고 세상에 대한 건강한 소망이 지나칠 정도로 많은 사람이라는 것이었다. 그녀를 반짝거리게 했던 그 모든 것들이 사실 내겐 없는 것들이어서, 당시 내가 좀 더 한가했다라면 그녀와 조금 더 친해져 보려고 애를 썼을 것 같기도 하다. 하지만 나는 고작 몇 달 앞으로 다가온 이민 일정 때문에 지면 하나를 채우는 것도 힘겨웠고, 깊이 있는 관계를 만들 틈은 더더욱 없었다. 

 

그래서 유서에 내 이름이 있다는 이야기를 들었을 때 나는 놀랐다. 대체 왜? 

Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2020. 4. 6. 15:26

* 뻔한 이야기지만, 이 글의 저작권은 글쓴이에게 있습니다.

 


"차이가 바로 느껴지시죠?"

 

그의 어조는 생각만 해도 가슴 뿌듯한 작품에 대해 설명하는 작가의 그것이었다.

 

"네, 그렇네요."

 

그리고 그 뿌듯함에는 근거가 있었다. 문이 닫히자, 통신사 시그널 부터 와이파이까지, 세상과 나를 이어주던 인터넷의 모든 흔적이 깨끗이 사라져버린 것이다. 

 

"완벽하네요."

 

내가 휴대폰을 들여다보며 중얼거리자, 그는 음영 지역이라고는 찾기 어려운 도시 한 복판에서 어떻게 이런 일이 가능했는지 꼼꼼하게 설명하기 시작했다. 전문용어가 섞인 그의 말을 온전히 다 이해하기는 어려웠지만, 간단히 요약하면 특정 대역 주파수에 대한 차폐 성능이 뛰어난 도료, 단열재, 그리고 벽지를 내장재로 사용했기 때문에, 문을 닫는 순간 거의 모든 종류의 무선 통신 시그널로부터 완전히 격리된 공간이 만들어 진다는 것이었다. 

 

"아, 물론 내장재만으로는 100% 완벽한 차단이 이루어질 수 없습니다. 아까 들어오실 때 이 집 앞 건물 옥상에 기지국 중계기 설치되어 있는 것 보셨죠?"

 

20평방미터 남짓 되는 그 짙은 초록색 방에는 1인용 소파 하나, 침대와 협탁, 그리고 작은 냉장고가 있었다. 그는 소파가 놓인 쪽 벽으로 걸어가, 그 벽에 손을 짚고는 나를 보았다. 무언가 이상한 부분을 눈치채지 못했느냐고 묻는 듯한 표정이었다. 

 

"그래서,"

 

하지만 정말로 내가 알아채기를 기다린 것은 아니었던 모양인지, 그는 곧바로 벽을 탁탁, 두들기며 말을 이었다. 

 

"창문도 없애야 했습니다."

 

그랬다. 그 방에 들어서자마자 답답한 기분이 들었던 것은 인터넷 신호가 끊겨서도 아니었고, 짙은 초록색 벽지 탓도 아니었던 것이다. 

 

"원래 여기가 창문이 있던 자리인데, 창문을 열면 바로 맞은편 건물이 보여요. 그리고 아까 말씀드렸듯이 그 옥상에..."

 

"... 기지국."

 

"네, 기지국 중계기가 있죠."

 

침대 옆 협탁 위에는 그녀의 평소 관심사와는 아무 관련이 없어 보이는 책들이 두어 권 놓여 있었고, 쇼파 위에는 갈색 무릎 담요가 구겨져 있었다. 냉장고는 거의 비어 있었고, 벽에는 어떤 사진도, 그림도 없었다. 인생에 대한 욕심으로 가득했단 평소 그녀의 모습과는 딴판인 인테리어였다. 나는 물었다.

 

"혹시 왜 이런 방이 필요했는지, 설명은 했었나요?"

 

그는 고개를 끄덕거렸다. 

 

"잠을 잘 수가 없다고 하더군요."

 

"... 네?"

 

"잠을 잘 수가 없다고 했어요."

 

내가 아는 그녀는, 선량한 사람이었다. 세상의 근심과 걱정거리들과 너무나 멀리 떨어져 있어서, 침대에 누워 눈을 감기만 하면 아무런 잡념 없이 잠들 수 있을 정도로 선량한 사람이었다. 너무 쉽게 잠드는 바람에 혼자 사는 데서 오는 두려움을 느낄 겨를도 없다는 게 유일한 걱정거리라던 사람이었다. 

 

"이해가 잘..."

 

"네. 저도 의아했죠. 보통 수면부족때문에 특별한 인테리어를 부탁하는 사람들이 있긴 하지만, 기껏해야 커튼에 좀 더 신경을 써달라거나, 방음이 좀 더 잘 되게 해달라 정도니까요. 그런데 인터넷 신호를 전부 막아달라? 이해도 안됐을 뿐더러, 그런 시공은 해 본 적이 없어서..."

 

"그래도 하시겠다고 하셨네요?"

 

"20년 친구 부탁이니까요. 캐물어도 그 이상은 이야기하지 않으려고 했고..."

Posted by 이병준
TAG 잡문

소중한 의견, 감사합니다. ^^

Thoughts2019. 10. 13. 07:03

그렇다면 개발자의 일상에서 불확실성은 어떤 형태로 등장하는가?

 

불확실성은 내가 잘 모르는 것, 그리고 내가 통제할 수 없는 어떤 것에서부터 등장한다. 내가 통제할 수 없는 것으로는 여러가지가 있지만, 주로 소프트웨어 납기에 관련된 것만 살펴보면 주로 다음과 같다.

 

  • 내가 이용하는 소프트웨어/서비스의 업데이트 주기 또는 릴리즈 사이클
  • 내가 속한 팀과 다른 서비스 소유자 또는 팀과의 협업 형태
  • 사용자로부터의 요구사항 
  • 시니어 리더십으로부터의 우선순위 변경 요청
  • 여러 프로젝트 사이의 컨텍스트 스위칭 오버헤드 
  • 내가 이용하는 소프트웨어/서비스의 가용성 

 

전부 시간을 들여 따져볼 가치가 있는 사항들이지만, 우선 제일 마지막 항목, 그러니까 내가 이용하는 소프트웨어/서비스의 가용성이 어떻게 내가 통제 불가능한 형태의 불확실성이 되기도 하는지 살펴보자.

 

보통 소프트웨어의 특정 기능('피처'라고 부르기도 하는)을 개발하고 납품하는 과정에 문제가 없으려면, 이용하는 소프트웨어/서비스의 가용성에도 문제가 없어야한다. 현대 소프트웨어는 복잡한 의존성(dependency)을 갖는다. 하나의 소프트웨어가 온전히 자족적으로 존재하는 경우는 이제 찾아보기 어려우며, 보통 하나의 제품은 다른 여러 소프트웨어/서비스에 의존한다. 여러분이 AWS/GCP 등에 의존하고 있다면, 여러분의 소프트웨어는 해당 클라우드 플랫폼이 제공하는 서비스들에 의존성을 갖는다. 여러분이 회사 내부적으로 공개된 다양한 서비스를 이용하여 소프트웨어를 개발하고 있다면, 여러분의 소프트웨어는 해당 서비스에 의존성을 갖는 것이다. 이 의존성은 프로젝트 개발 과정의 다양한 부분에 영향을 미치지만, 가장 결정적인 부분은 테스트이다.

 

여러분이 어떤 서비스를 만든다고 하자. 해당 서비스에 대한 변경사항을 배포하기 위해서는 다양한 테스트가 필요하다. 해당 변경사항을 머지한 이후에 서비스가 정상적으로 실행되는지는 가장 기본적으로 테스트해야 할 사항이다. 해당 변경사항을 머지한 이후에 해당 서비스의 응답 속도에 큰 변화가 없는지, 처리량에 큰 변화가 없는지를 검사하는 것은 조금 더 복잡하지만, 역시 필수적으로 요구되는 사항이다. 한편 사용자 경험 상에 어떤 부정적 변화가 없는지를 테스트하는 것은 훨씬 어렵다. 이런 부분까지 테스트하는 자동화된 툴을 도입할 수 있다면 좋겠지만, 그렇지 못한 경우도 있기 때문에 릴리즈 마지막 단계에서는 QA 엔지니어들의 도움을 받아 서비스를 수동 테스트하기도 한다. 

 

이 각각의 테스트는 단계적으로 이루어진다. 가령 서비스의 실행이 정상적으로 이루어지는지를 검사하는 것은 보통 알파 스테이지(alpha stage)에서 이루어지고, 서비스의 기본 기능에 부정적 변화(regression)이 없는지를 검사하는 것은 통상 베타 스테이지에서 이루어지며, 처리랑/응답속도/사용자 경험에 있어서 부정적인 변화가 없는지를 검사하는 것은 통상 감마 스테이지에서 이루어진다.

 

주목해야 할 것은 보통 알파/베타 스테이지에서 실행되는 서비스는 내부망을 바라보도록 설계되어 있어서, 해당 서비스가 의존하는 하위 서비스도 알파/베타 스테이지 버전을 이용하게 된다는 것이다. 한편 감마 스테이지에서 실행되는 서비스가 바라보는 타 서비스의 엔드포인트는 감마 엔드포인트, 그러니까 감마 스테이지에서 실행되는 서비스의 엔드포인트인경우도 있고, 실 서비스망에 위치한 서비스의 엔드포인트인 경우도 있다. 실 서비스에서 생성되는 데이터에 혼란을 야기하기 싫은 경우가 대부분이기 때문에, 보통은 감마 엔드포인트를 바라보도록 구성한다.

 

여기서 주의할 것은 내 알파/베타 스테이지 서비스가 이용하게 될 하위 의존성, 다시 말해 내가 이용해야 할 알파/베타 서비스들은 보통 굉장히 불안정하다는 것이다. 이름 자체가 알파/베타이므로 많은 팀들은 이들 스테이지를 그다지 적극적으로 관리하지 않는다. 이들 스테이지는 수시로 망가지고, 수시로 복구된다. 감마 스테이지 이후의 서비스가 정상적으로 동작하고 있다면, 많은 팀들은 알파/베타 스테이지에서 벌어지는 문제를 긴급하게 처리하려 하지 않는다. 실 서비스 망에서 지금 당장 벌어지고 있는 문제가 아니기 때문이다. 

 

그러나 망가진 알파/베타 스테이지 서비스는 해당 서비스에 의존하는 다른 팀들의 서비스 테스트를 곤란하게 만든다. 방금 머지된 서비스 변경 사항이 정상 동작하지 않는 것이 해당 변경사항에 끼어든 버그 때문인지 아니면 하위 서비스의 장애 때문인지 확인하기 어렵기 때문이다. 이 때문에, 많은 경우 시스템 변경을 A/B 테스트로 감싼 후 감마 스테이지까지 푸시한 뒤에 감마 스테이지에서 하위 서비스의 안정 버전을 이용해 테스트하는 고육책을 쓰기도 하는데, 보통 알파->베타->감마로 내 변경사항을 옮기는 데는 시간이 소요되기 때문에 (테스트되지 않은 변경사항을 코드리뷰하는 데는 갑절의 시간이 든다) 전반적인 개발 속도가 지연되는 결과를 낳고 만다. 

 

이런 형태의 불확실성은 프로젝트 계획 단계에서 추정하기가 어렵다. 그렇기 때문에 많은 개발자는 이런 문제가 생길 것으로 예상되는 태스크에 좀 더 큰 버퍼를 방어적으로 할당하기도 한다. 이런 버퍼는 프로젝트의 규모에 대한 추정치를 보수적으로 만들기 때문에, 전체 부서의 생산성에 큰 문제가 있는 것처럼 보이도록 만들기도 한다. 

 

이런 문제를 방지하는 좋은 방법이 무엇이냐에 대해서는 이견이 있을 수 있으나, 많은 개발자는 보다 공격적이고 선제적인 테스트 전략이 없이는 이런 형태로 드러나는 불확실성이 양을 줄일 수 없다는 데 동의할 것이다. 개발자가 변경사항을 마스터 브랜치에 머지하기 전에 e2e로 변경사항을 테스트할 수 있도록 허락하는 어떤 물리적 수단의 도입 없이는, 여러 팀이 지연 없이 협업하는 것 또한 물리적으로 어렵다. 

 

Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2019. 9. 26. 14:00

앞선 글에서 불확실성을 관리하는 것이 곧 커리어 관리가 될 수도 있음을 살펴봤다. 불확실성 관리가 없는 계획은 곧 신뢰할 수 없는 계획으로 바뀌게 마련이고, 신뢰할 수 없는 계획을 내놓고 납기일을 약속하는 개발자는 곧 관리자와 다른 팀의 신뢰를 잃게 된다. 

 

그렇다면 불확실성은 대체 어떻게 관리해야 하는가? 

 

불확실성을 관리하는 방법을 알기 위해서는 보통 불확실성이 어떤 형태로 드러나는지를 살펴봐야 한다. 형태가 없는 것을 관리할 수는 없는 노릇 아닌가. 그러나 불확실성의 형태를 살펴보기 전에 먼저, 한 가지만 살펴보고 넘어가자.

 

우리는 프로젝트의 불확실성을 적정 수준 이하로 관리하기 위해 애자일 방법론을 도입해 왔다. 애자일 방법론은 (특히 스크럼은) 2주 단위의 스프린트마다 새로운 목표를 세우고, 그 목표가 완수되는 정도를 측정함으로써 팀의 속도를 평가하고 그 결과를 다음 계획에 활용한다. 이처럼 프로젝트의 실행 과정을 더 이상 잘게 쪼갤 수 없을 때 까지 쪼개는 행위는, 2주라는 기간 안에 완료할 수 있다는 확신이 서는 (다시 말해 그 규모에 있어서 불확실성이 거의 존재하지 않는) 작업만을 스프린트의 실행 대상으로 삼는다는 것을 전제한다. 간단하게 들린다. 

 

그러나 '2주라는 기간 안에 완료할 수 있다는 확신이 서는 작업만을 스프린트에 포함시키는' 것 자체가 이미 만만한 작업은 아니라는 것을 우리는 깨달을 필요가 있다. 왜 그런가? 

 

여러분이 여러 팀으로 구성된 어떤 조직의 일원이라고 해 보자. 보통 이 조직은 어떤 공통의 목표를 달성하기 위해 함께 움직이지만, 각 팀은 그 팀이 관리하는 소프트웨어의 특성에 따라 상이한 개발 체계를 따르는 것이 일상적이다. 한 팀에서 당연한 일이 어떤 팀에게는 전혀 당연하지 않다. 이 간단한 한 문장은 굉장히 많은 것을 의미한다. 예를 하나 살펴보자. 많은 팀이 이용하는 플랫폼 소프트웨어를 관리하는 팀 A가 있다. 이 플랫폼 소프트웨어는 운 나쁘게도 다른 팀으로 하여금 특정 모듈을 스스로 업데이트하도록 강제한다. 그 문제 때문에 팀 A는 매주 한 번씩 소프트웨어를 릴리즈하며, 다른 팀으로부터 접수되는 코드 리뷰 요청을 전담하는 온콜(on-call)을 둔다. 이 담당자는 일주일에 딱 이틀간만 다른 팀으로부터 접수된 코드를 리뷰한다. 이런 개발 체계는 CI/CD를 당연시하는 팀 B에게는 재앙에 가깝다. 코드 리뷰 요청을 제때 넣지 않으면 일주일을 날린다. 리뷰된 코드가 제 때 머지되지 않으면 또 일주일이 날아간다. 팀 B의 개발자는 이 문제를 제대로 숙지하지 않은 탓에 2주, 그러니까 스프린트 1회 분량의 시간을 날리고 매니저로부터 문책을 당한 경험이 있다. 

 

이런 형태의 불확실성은 조직 형태와도 밀접한 관련이 있다. 어떤 조직이 크면 클수록, 각 팀의 규모가 작으면 작을수록 이런 문제는 도드라진다. 우리는 이것을 보통 커뮤니케이션 오버헤드(communication overhead)라는 말로 퉁치지만, 그 실체는 훨씬 복잡하다. 

 

 

 

Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2019. 9. 23. 09:43

개발자로서 당신의 커리어가 서쪽으로 가는 것은 당신의 능력이 인정받지 못하기 때문이다. 능력이 인정받지 못하는 데는 여러가지 이유가 있지만, 그 가운데 가장 으뜸은, 당신이 약속한 일정이 번번이 어겨지는 것이다. 

 

왜 이것이 가장 큰 이유인지는 보통 회사라는 곳에서 납기일이 어떻게 관리되는지를 살펴보면 이해하기 쉽다. 

 

당신의 회사는 보통 몇 단계의 보고 체계를 따른다. 이 보고 체계의 상층부에서는 큰 그림의 우선순위를 정하고, 그 우선순위에 따라 납기 일정을 맞춘다. 보통 이 납기 일정은 아래쪽 팀이 보고한 추정치에 근거하는데, 이 추정치가 부정확하면 부정확할 수록 위쪽으로 보고되는 수치의 정확성은 낮아진다. 이 수치의 정확성이 낮아지면 프로젝트는 일정 대로 마쳐지지 못하게 되고, 그렇게 되면 누군가는 문책을 당한다. 일정에 맞춰 수립했던 사업 계획이 망가졌기 때문이다. 

 

이런 일이 자주 생기면 누군가는 문책성 인사를 당하게 되어 있다. 당신의 매니저가 이런 저런 이유로 파면되었다는 소식이 들린다면, 대체로 그것은 이런 이유 때문이다. 

 

그렇기 때문에 매니저들은 자신에게 화살이 돌아오는 상황을 어떻게든 피하려고 한다. 그렇다면 매니저는 과연 누구에게 책임을 돌리려고 할까? 아마 개발자일 것이다. 개발자는 매니저에게 일정 추산치를 제공하는 사슬의 가장 마지막에 위치하고 있다. 매니저는 개발자에게서 들은 대로 모든 일정을 역산한다. 

 

여기까지 이해하고 나면, 우리는 프로젝트 진행에 있어, 그리고 개발자의 커리어 관리에 있어서 가장 중요한 기술이, 프로젝트의 규모를 산정하는 데 있어서 불확실성의 수준을 평가하고 그에 비추어 계획을 수립하며 그 계획의 각 단계를 가급적 더 잘게 쪼갤 수 없는 단위로 분할하여 우선순위를 정하는 능력이라는 것 또한 미루어 짐작할 수 있게 된다. 

 

개발자의 능력을 평가할 때 아름다운 코딩 능력을 최 우선으로 삼지 않는다는 것이 많은 개발자에게 아마 부당하게 느껴질 수도 있을 것이다. 처음에는 너무나 단순하게 보였던 문제가 실제로 프로젝트가 진행됨에 따라 거대한 빙산으로 변모하는 상황은 그다지 드물지 않다. 그런 상황에서 프로젝트를 이끈 개발자, 그리고 결국 끈기있게 모든 것을 성사시킨 개발자에게 일정 지연 책임을 묻는 것은 그다지 온당하지 않다고 항의할 개발자도 많을 것이다. 

 

그러나 일정을 지키는 것은 개발자 이전에 직장인으로서 반드시 준수해야 할 사항이다.

 

밥 마틴은 이것을 Professionalism이라는 단어로 묘사했다. 그는 역저 "Clean Coder"에서 직업인이 반드시 가져야 할 이 '윤리'의식을 "commitment"에 대한 "responsibility"로 서술했다. 다시 말해 어떤 작업을 완수하겠다는 책임의식으로 묘사한 것이다. 

 

직장인에게 있어서 이 책임의식만큼 중요한 것은 없다. 직장에서 한 두 번 눈감아줄 수 있는 '실수'나 '실패'는 보통 이것을 말한다. 이것이 거듭되면, 보통 해당 직원은 저성과자로 분류되어 해고 수순을 밟거나 특별 교육 대상자로 분류된다. 이런 사람들은 보통 회사를 떠나고 나면 다시는 그 회사로 돌아가지 못한다. 최종 평가 기록이 회사 데이터베이스에 남기 때문이다. 

 

Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 이동욱

    저도 이제 곧 취업을 할 텐데 이 부분을 주의해야할 것 같습니다.

    2020.05.13 12:21 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2018. 2. 4. 04:46

앞선 글에서는 커뮤니케이션에서 오는 스트레스를 개인적인 차원에서 다루는 여러가지 방법에 대해서 살펴봤다.


그러나 말했듯이 직장에서 생기는 커뮤니케이션 문제는 개인적인 차원에서 온전히 소거해버릴 수 있는 것이 아니다. 절에 가도 그런 스트레스가 있고, 수도원에 들어가도 그런 스트레스는 생긴다. 사람과 함께 일할 수 밖에 없는 것이 인간의 운명이므로, 어쩔 수 없는 일이다. 조직이 있는 한 어쩔 수 없는 스트레스다. 문제는 그 수준이 어느 정도냐다. 


커뮤니케이션 오버헤드가 어떤 임계치를 넘어서면, 조직원으로부터 대략 두 가지 정도의 반응이 나온다. 일이니까 어쩔 수 없다는 반응과, 대체 왜 그런 일에 업무 시간을 써야 하는지 이해하기 어렵다는 반응 정도로 요약할 수 있다. 회사에서의 커뮤니케이션도 업무라는 관점에서 본다면 두 번째 반응은 지나치게 개인적으로 비춰질 수 있다. 


그러나 그런 해석은, 회사에서 일하는 개인들을 지나치게 얕잡아 보는 것이다. 설마 그렇게 어려운 과정을 거쳐서 회사에 입사한 사람들이 일과 사생활도 제대로 구별 못하겠는가? (물론 간혹 가다 그런 사람도 있긴 하다.) 


따라서 두 번째 종류의 반응이 나오기 시작하면, 그런 반응을 보이는 사람들을 질책하기 보다는 그 반응이 어디서 오는지를 제대로 살펴야 한다. 그리고 이런 일은 조직이 해야 하는 일이다. 


조직의 책무


조직에게 이런 책무가 있다는 사실을 조직이 깨닫지 못하면, 다시 말해서 구성원의 스트레스 레벨 관리 또한 조직이 응당 신경써야 (not 전적으로 책임져야) 하는 부분임을 깨닫지 못하면, 그 조직의 구성원들은 아마 다른 직장을 찾기 시작할 것이다. 그런 일이 벌어지기 시작하면 해당 조직 입장에서도 힘들어지기 때문에, 미리 미리 관리를 하는 것이 좋다. 


이런 문제를 관리하는 좋은 방법 중 한 가지는, 관리자 레벨에 있는 사람들을 '관리'하는 것이다. 보통 대부분의 조직에서 커뮤니케이션의 허브 역할을 하는 사람들은 관리자이므로, 그런 사람들에게 있는 문제를 관리하는 것이 요령이다. 관리자가 커뮤니케이션 문제를 다루는 데 능숙하면 조직원들이 스트레스를 덜 받지만, 관리자가 아무 생각이 없거나 자기 멋대로면 그 관리자에 연결된 모든 구성원들이 대단한 피해를 보기 시작한다. 그리고 아마 실제로 관리에 들어가보면 확인할 수 있는 사실이겠지만, 대부분의 커뮤니케이션 문제는 대체로 관리자 때문에 생긴다 (목소리가 클 수 밖에 없기 때문이다).


따라서 관리자와 구성원 간의 상호작용 문제에 있어서 만큼은 상향평가를 어느 정도 하는 것이 바람직하다. 


문제는 상향 평가를 어떤 식으로 하는 것이 좋느냐이다. 한국은 암묵적인 도제식 군문화가 지배해왔던 사회라 상향 평가에 굉장히 민감했었지만 (대기업일 수록 더 그렇다) 최근들어 상황이 많이 바뀌기 시작한 것 같다. 따라서 어떤 식으로든 일단 커뮤니케이션 부분에 관해서 만큼은 상향 평가를 시작하고 보는 것이 좋다. 대부분의 IT 관련 개발조직에서 사람들에게 가장 많은 스트레스를 주는 부분이 커뮤니케이션이기 때문이다 (아마 대부분의 실무레벨 개발자들이 그럴 것이다). 


그러니 '어떤 식으로 해야 하지?'라는 문제에 너무 골몰하지 말고, 일단 하고 보자. 모 회사 처럼 트위터 스타일로 한줄 평만 받아도 좋다. 일단 하기 시작하면 큰 도움이 된다. 


IT 프로젝트의 어쩔 수 없는 오버헤드(?)들


조직 내의 커뮤니케이션 오버헤드를 적절히 관리하는 또 한 가지 요령은, IT 프로젝트 진행 과정상 어쩔 수 없이 겪어야만 하는 커뮤니케이션 오버헤드의 상당수는 (스탠드 업 미팅, 요구사항 회의, 디자인 리뷰, 코드 리뷰) 개인의 창의성과 시간을 측정 가능한 수단으로 환산하고 관리해야만 하는 '관리상의 필요' 때문에 어쩔 수 없는 부분이라는 것을 모든 개발자에게 납득시키는 것이다. 이런 오버헤드는 공장에서 공정관리를 위해 필수적으로 요구하는 절차와 같은 수준의 오버헤드기 때문에, 사실 제거할 수 없다. 그런 것 까지 안하는 조직은 보통 그만 그만한 수준의 소프트웨어만 만들어내다가 망하게 마련이고, 그런 곳에서 일하는 개발자는 보통 더 크고 유명한 회사에 가서 왕창 깨져보고 나서야 왜 그런 절차들이 필요했는지 깨닫는다. 


그리고 이걸 납득시키는 가장 좋은 방법은, 프로젝트 괸리에 숙달된 사람을 적어도 한 명 이상 프로젝트에 포함시키는 것이다. 보지 않으면 믿지도 않는 것이 사람 심리고 개발자들도 예외는 아니다. 프로젝트의 '공정' 관리가 어떻게 이루어지는 지 알도록 해야 잡음이 생기지 않는다. 기한에 맞춰서 납품만 하는 것이 소프트웨어 개발 프로세스가 아니다. 리스크를 지정 수준 이하로 괸리하는 것이 그 핵심이고, 그 노하우를 활용하지 않으면 결국 그 결과물로 가장 많은 피해를 보는 사람은 개발 당사자다. 그 사실을 똑바로 보도록 하는 것이 중요하다.


다음 글에서는 직장인의 커리어 관리에 관한 스트레스에 대해서 집중적으로 살펴보자. 


Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 이직 준비중인 2년차 개발자입니다.
    본문에 나온 내용에 공감하고
    그것 때문에 이직을 준비중입니다.
    좋은 글 감사합니다.

    2018.03.25 13:38 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2017. 12. 31. 11:21

앞선 글에서는 생각을 조금만 달리하면 스트레스에서 벗어날 수 있을지도 모른다는 이야기를 했다.


그러나 그렇게 쉬우면 스트레스가 아니다. 정말로 스트레스에서 벗어나려면 이것 저것 따져봐야 할 것이 많다.


스트레스의 한 가지 요인으로 '욕심'과 '자존감'에 대해서 이야기했다. 거의 모든 문제가 이 두 단어에 연결되어 있지만, 스트레스가 드러나는 표면적인 양상만 두고보면 그 두 가지로 쉽게 치환하기 어려운 문제도 많다. 


그 중 대표적인 것으로, 인간관계를 들 수 있다. 이 문제는 사실 굉장히 재미있는 문제다.


많은 사람들이 회사에 일하기 위해서 간다. 그런데 막상 입사하고 보니 정작 일로 받는 스트레스보다 사람 때문에 받는 스트레스가 더 많은 것 같다. 가령 이런 식이다. 


"저, 이 일을 작년에 진행하셨던 것으로 알고 있는데, 브리핑을 좀 해 주실 수 있을까요?"


"지금 바빠요. 담주 까지는 어렵습니다."


이렇게 나오면 그 일은 담 주 까지는 진행하기 어렵다. 좀 친절하게 이야기했으면 모르겠는데, 말투까지 으시딱딱하면 절로 열까지 받는다. 내가 저런 인간하고 같이 일하려고 그렇게 열심히 공부했나 싶다.


또 다른 사례를 보자. 이 번은 여사원의 경우다. 열심히 일하려고 입사했는데, 내가 비서인줄 아는지 커피를 타오라지 않나, 회식자리에서 술만 거나하게 취하면 정신머리를 안드로메다 너머에 널어놓고 왔는지 평소에는 꿈도 못꾸던 스킨십을 해 대는 동료들 때문에 스트레스가 이만 저만이 아니다. 


회식 다음날만 되면 정말 다들 꼴보기 싫고 일이 손에 잡히지 않는 것은 당연지사. 


이런 것도 당연히 인간관계 스트레스다.


이 쯤 되면 이런 말이 목구멍까지 올라온다.


"인간관계를 하려면 내가 SNS를 하지 회사에 입사했겠냐?"


앞 글에서 잠깐 언급했듯이, 인간은 자기가 가장 시간을 많이 쏟는 데서 스트레스를 받는다. 여러분이 인간관계에서 굉장히 다양한 스트레스를 받는다면, 그것은 그 회사에서 보내는 시간 가운데 상당수가 커뮤니케이션에 집중되어 있다는 뜻이다. 물론 회사가 코드 공장이 아닌 만큼, 회의 없이 또는 어떠한 형태의 커뮤니케이션도 없이 자리에 죽치고 앉아서 코드만 생산하는 식으로 꿈같이 일할 수는 없다. 하지만 이런 인간관계 스트레스가 회사 생활을 지배할 정도로 커졌다면 문제다.


그럼 이런 문제는 어떻게 해결하나?


아쉽게도 개인적인 차원의 노력만으로는 해결하기 어렵다. 


커뮤니케이션에서 오는 스트레스를 개인적인 차원에서 전부 해결하려면 도인이 되는 수 밖에 없기 때문이다. 


불가능하긴 하지만, 말이 나왔으니 그런 도인이 되려면 어떻게 해야하는지 한 번 짚어보고 넘어가자.


그런 도인이 되기 위해 갖춰야 하는 핵심적 역량은 다음과 같다.


  • 자기 자신을 회사의 부속품으로만 여길 것

  • 일에 지나치게 많은 개인적 가치를 부여하지 말 것

  • 나는 남보다 못하다는 마음 가짐을 '진심으로' 가질 것

  • 자기 일을 시간 내에 끝낼 수 있다는 것만을 중요하게 여길 것

  • 기술적인 말만 할 것

  • 아무런 생각 없이 즉시 신고할 것


그 각각의 의미는 사실 이 글을 읽는 각자 조금만 고민해도 쉽게 알 수 있는 것들이지만, 이 글을 읽는 모든 분들이 필자만큼 게으르다는 가정 하에 한 번 하나씩 짚어보고 넘어가보자.

첫 번째. 자기 자신을 회사의 부속으로만 여기는 마음가짐은, 자기 자신을 뭔가 중요한 존재로 여기는 마음가짐을 거세함으로써, 자존심이 상처받을 가능성을 최대한 낮춰준다. 진심으로 겸손하면 커뮤니케이션에서 스트레스를 받지 않는다. 보통 스트레스는 자존심이 조각날 때 찾아온다.

두 번째. 일에 가치를 부여하기 시작하면 커뮤니케이션 때문에 일이 지체되었을 때 스트레스를 받게 된다. 일은 일일 뿐이다. 그 일은 지구를 구하는 문제와는 대체로 아무 관련이 없으며, 데드라인이 오기 전까지 잘 마무리되기만 하면 여러분의 승진이나 성장에도 대체로 큰 영향을 미치지 않는다. (그 정도로 중요한 프로젝트를 하고 있다면 아마 이런 글 따위를 읽을 시간이 없을 것이다.) 

세 번째. 첫 번째와 크게 다르지 않다. 겸손한 자만이 밤에 쉽게 잠들 수 있다. 겸손하라. 숙면은 스트레스에도 그만이다.

네 번째. 두 번째와 크게 다르지 않다. 자기 몫의 일을 제 때 정확히 올바르게 끝내는 데만 집중하라. 그러면 '저 새끼 때문에 일이 지연되고 있어!' 라거나, '내가 저 인간 때문에 시간을 얼마나 낭비했는지! 왜 저 인간과 한 팀인거야!' 같은 생각에서 벗어날 수 있다. 이 글을 읽는 대부분의 독자들께서는 아마 관리자가 아니며, 그저 개발자일 것이다. 그렇다면 팀 내의 특정 직원 때문에 생기는 프로젝트의 지연은 관리자가 해결할 몫이지 여러분 문제가 아니다. 문제가 생기면 관리자에게 보고하고 그가 해결하도록 내버려 두자. 여러분 일도 아닌 일에 시간을 낭비하면 피곤해진다. 관리자가 해야 할 일까지 가로채면 곤란하다는 것이다 그렇지 않은가 관리자도 월급을 받는데.... 물론 관리자가 여러분에게 그런 일을 떠 넘겼을 때는 다른 문제다.

다섯 번째. 말했듯이, 사람은 가장 많이 시간을 쓰는 일에서 가장 많은 실수를 한다. 이 글을 읽는 여러분이 만일 다변가라면, 그 만큼 여러분 때문에 스트레스 받을 사람도 많을 것이다 (니가 몰라서 그렇지). 그러니 회식 자리가 아니라면 기술적인 이야기만 하도록 하자. 여러분이 쓸데 없이 내뱉은 말이 비수가 (스트레스가) 되어 여러분 가슴에 되돌아와 꽂히는 일이 없도록 하자. 

여섯 번째. 개인적 차원에서 해결하기 어려운 문제가 생기면 고민하지 말고 신고하거나 매니저에게 알리자. 물론 쉬운 일은 아니지만 인터넷 덕에 많은 것이 달라졌다. 세상이 달라졌음을 한 번 믿어보도록 하자. 

(다음에 계속) 


Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 좋은 말이네요 다음 글도 기대해봅니다 ㅎㅎ

    2018.01.16 09:42 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 주니어 개발자입니다. 좋은 글에 치유받고 갑니다!
    종종 들려서 치유하고 가겠습니다. 선배님.

    2018.01.18 01:54 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2017. 12. 28. 06:26

공기업 생활을 십삼년간 하고 팔자에도 없는 사기업 생활에 도전한지도 어언 삼년이 훌쩍 넘었다. 새해를 맞아 그 삼년 간 깨달은 것을 몇 번에 걸쳐 적어 보려고 한다. 오직, 그저, 까먹기 전에. 


아마 누군가에게는 도움이 될지도 모를 교훈들이지만, 이 글을 읽는 여러분들께서는 모름지기 '인생은 케바케'라는 대전제에 입각하여, 지나치게 심각하게 받아들이지는 말아 달라는 당부 말씀도 드리고 싶다. 세상에는 이 글보다 심각하게 따져봐야 할 문제들이 차고 넘친다. 이 글에서 말하려는 교훈들이 여러분의 성에 차지 않는다면, back 버튼을 누르면 그만이다. 스트레스 받지 마시라.


스트레스는 어디에서 오는가  


스트레스 없는 직장생활을 하기 위해서는 스트레스가 어디에서 오는지 부터 깨달아야 한다. 


좀 이상하게 들릴 수도 있겠지만, 스트레스는 보통 여러분이 잘 하는 것에서부터 온다. 잘 못하는 것으로부터 오지 않는다. 


여러분이 수영 초보자라고 하자. 수영 초보자가 수영을 잘 못하는 것은 당연하다. 그러니 매일 같이 물을 먹어도 스트레스를 받을 일은 좀처럼 없다. 물을 먹는 것이 당연하기 때문이다. 


수영 초보자가 수영에서 스트레스를 받는 것은 대체로 언제부터 시작되느냐면, '시간을 많이 투자한 것 같은데 실력이 좀처럼 늘지 않는다는 것을 깨닫는 순간'부터 시작된다. 다른 초보자가 보기에는 꽤 잘 하는 것 같은데, 자기 자신이 슬슬 부족함을 느끼기 시작하는 것이다. 그러면 스트레스가 생긴다. 


달리 말해, 스트레스의 근원 중 상당수는 '더 잘 하고 싶은 욕심'이다. 잘 하지만 더 잘 하고 싶은 것이다. 자신의 능력이 자기 기대에 못 미칠 때 스트레스를 받는 것이다. 


여러분 중 상당수는 단순히 먹고 살기 위해 개발자의 길을 택한 것이 아니라, 개발에 남들 보다 재능이 있는 것 같아서 개발에 뛰어들었을 것이다. 개발이 재미있는 일이었기 때문에 개발에 뛰어 들었을 것이다. 그런데 희한하게도, 직장을 잡고 일을 하는 순간 부터 개발이라는 것이 마냥 즐겁지만은 않은 일이 되어 버린다. 스트레스를 받는다. 힘들다. 왜인가? 


생각만큼 잘 되지 않기 때문이다. 


나름 잘 한다고 생각했는데, 동기에게 치이고 상사에게 지적받고 매니저에게 혼난다. 자존감이 낮아지고 자기 능력에 회의가 생긴다. 이러니 스트레스를 안 받을래야 안 받을 수가 없다. 힘들고 불행하다. 사는 게 사는 것 같지 않다. 


이런 스트레스는 어떻게 해소해야 하는가? 


이런 스트레스를 해소하려면, 당장의 자기 감정만 살피는 근시간적인 생각을 버려야 한다. 그리고 다음 사실을 받아들여야 한다.


  • 실패야 말로 가장 좋은 선생님이다

  • 깨지면서 배운 것들이 가장 오래 간다


어디서 많이 듣던 소리다. 뒤집어 말하면 케케묵은 공자님 말씀이란 소리다. 다시 말하면 하나 마나 한 소리이며 피부에 잘 와닫지 않는다는 소리이다.

그러나 이런 '하나 마나' 한 소리들이 그토록 오랫동안 인류 공통의 교훈이 된 데에는 다 이유가 있다. 

필자는 공기업 생활을 13년간 했는데, 이 기간 동안 한 가지 단언할 수 있는 건, 개발자로서 개인적 실패 경험이 0에 가까왔다는 것이다. 당연히 자존감(또는 자만심)이 하늘을 찔렀으며, 아마 많은 사람들이 뒤에서 '오만 방자한 인간 같으니'하면서 수근 댔을 것이나 듣지 못했다. 개발자로서 실패한 적이 없으니 당연히 스트레스 또한 0에 가까운 나날들이었다. 

그러나 지금 생각해보면 그 13년간은 개발자로서 나에게 해 준 것이 아무 것도 없다. 그 오만 방자했던 시간 덕에 사기업 이직의 꿈을 꾸었고 지금은 아마존 미국 본사에까지 와 있으니 딱히 아무 것도 해 준 것이 없다고 하기에는 좀 어폐가 있긴 하지만, 사기업으로 이직한 뒤에 내가 겪었던 오만가지 수모를 생각하면 '아무 것도 없다'는 말은 꽤 정확한 수사다. 왜? 내가 시니어 엔지니어로서 주니어들에게 보여줄만한 경험이 아무 것도 없다는 사실을 그 때 가서야 깨달았기 때문이다. 

개발자로서 실패하고 깨지는 경험을 좀 더 일찍 했으면, 40대 중반에 개발자로 살면서 이렇게 피곤하지는 않았을 것이다. 

자. 그러니 여러분이 지금 직장에서 굉장히 스트레스를 받고 있으며, 그것이 여러분이 매일 같이 겪는 실패의 경험 탓이라고 하자. 최소한 그것은 몇 가지 긍정적인 사실을 드러내 준다. 첫 번째는 여러분이 '더 잘 하고 싶은 욕심을 가진 인간'이라는 것이며, 두 번째는 그 경험들이 여러분을 진정한 개발자로 단련시켜주고 있다는 사실이다. 

그러니, 너무 스트레스 받지 마시라. 오히려 더욱 감사하게 생각해야 할 일이다.

그래도 스트레스를 받는다고?

그렇다면 그 원인은 다른 곳에 있다. 뒤 이은 글에서는 그 '다른 이유들'에 대해서 짚어보도록 하겠다. 




Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. ㅎㅎㅎ 하소연 잘 읽었습니다. 듣기 좋은 아무리 들어도 기분 좋아지지 않는 것도 공감하고요.

    https://coderlife.tistory.com/94

    전에 적었던 개발자가 피해야할 8가지 유형인데 함께 봐주시면 감사하겠습니다.

    2019.09.07 14:58 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2017. 9. 30. 15:36

시애틀에 처음 도착한 것이 9월 23일이니까 드디어 미국에 온지도 만 2년이 넘었다. 세월은 정말로 화살처럼 날아가 사라진다. 그 진부한 속담이 뼈속 깊이 사무치게 되면 나이를 먹은 거라던데, 드디어 정말로 나이를 먹은 모양이다. 


새로 배속된 부서는 음성 쇼핑 기술을 개발하는 부서다. 소위 '알렉사' 덕에, 아마존에서 가장 잘 나가는 부서가 되었다. 그래서 그런지 지원자도 많고, 사람도 그만큼 많이 뽑으려고 한다. 그러나 일주일에 서너번씩 면접관으로 뛰어도, 그 가운데 합격자를 보기란 여간 쉽지 않다. 인기가 많은 부서일수록 문턱도 높은 법이다. 그 문턱을 높이는 사람들은 바로 이곳에서 일하는 엔지니어들. 최고의 기술자들과 함께 일한다는 자부심이 있으니, 굳이 의식하지 않아도 문턱은 어느새 조금씩 높아진다. 그러니 그들을 만족시켜 함께 일할 기회를 잡기란 여간 어려운 일이 아니다. 나야 마음 넓은 매니저 덕에 운이 좋아 여기까지 왔지만, 그렇지 못한 사람들은 아마존의 '변방' 부서에서 허드렛 일부터 배워가며 이곳까지 오기도 한다. 그렇게 성장한 사람들일수록 깐깐하기도 그지 없다. 


조직이 급속도로 커지다보니, 한 개 층만 쓰던 부서는 어느새 서너개 층을 동시에 써야 될 정도로 덩치가 커졌다. 내가 속한 팀도 예외는 아니라서, 팀원들이 한 곳에 모여 앉을 수 없는 지경에 이르렀다. 보통 이런 지경까지 되면 부서에 할당된 공간을 늘린 후 자리를 재배치하게 되는데, 덕분에 어제는 짐을 싸버리고 일찍 퇴근, 오늘은 옮겨진 짐을 풀어 정리만 하고 (짐을 옮겨주는 직원들이 따로 있다) 다섯시에 퇴근했다. 내 자리는 조만간 책임 엔지니어로 승진할 거라는 소문이 무성한 능력 좋은 선임 엔지니어 옆 자리다. 보통 능력 좋은 사람이 창가 자리를 꿰 차고, 남은 사람들이 나머지 자리를 나눠 갖는다. 나는 다행히 그 친구 옆이라, 바깥 풍경에서 그다지 멀지 않다. 


나이가 들면 신기할 일이 없어진다는데, 나는 아직도 매일 매일이 신기하다. 매일 매일 새로운 사건이 터지고, 새로 배울 것들이 생기고, 새로이 적응해야 할 일들이 벌어진다. 그러나 그 가운데 가장 신기한 것은 내가 아직도 여기에서 일하고 있다는 것이다. 특히 나이 30 초반에 잘나가는 선임 엔지니어가 되어 있는 동료들을 보고 있으면, 정말 내가 어떻게 이렇게 오래 버틸 수 있었는지 의아할 때가 한 두 번이 아니다. 


그러나 오늘만큼은 몇명 없는 사무실에 조용히 앉아 한 가지 일에만 집중하며, 스스로에 대한 의구심이나 회의는 잠시 잊어버릴 수 있었다. 집중할 수 있는 시간, 조용한 시간은 그래서 중요한 것이다. 그런 시간이 많으면 많을 수록, 자기가 가장 잘 하는 일로 돌아갈 수 있기 때문이다. 제일 잘 하는 일을 자주 하면 자신감이 커진다. 자신감이 커지면 버티기 쉽다. 


Posted by 이병준
TAG 아마존

소중한 의견, 감사합니다. ^^

  1. 비밀댓글입니다

    2017.10.24 11:03 [ ADDR : EDIT/ DEL : REPLY ]
    • 남겨주신 글 잘 봤습니다. 좋은 학교에서 포스닥까지 하고 계신다니, 앞으로가 더욱 기대됩니다.

      적지 않은 나이에 미국으로 건너와 늦깎이 도전을 하고 있자니, 왜 사람들의 그토록 안정된 삶을 추구하는지 조금은 이해할 것 같은 기분입니다.

      하지만 그럴 때 마다 미국으로 건너올 때 했던 생각들을 되새기곤 합니다. '그 때 그 일을 저질렀더라면 인생이 어떻게 달라졌을지 궁금해하다 죽고싶지는 않다.'

      조금은 거창하게 적었습니다만, 매일 매일의 사투를 견딜 수 있게 해주는 나름의 신념을 나누고 싶었다는 정도로 이해해주시면 좋겠습니다.

      건승을 빕니다.

      2017.10.28 17:14 신고 [ ADDR : EDIT/ DEL ]
  2. 비밀댓글입니다

    2020.07.02 17:30 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2017. 9. 26. 06:54

미국에서 프로그래머로 일하려면 영어 문제를 어떻게 해결할 것인지 진지하게 고민해봐야 한다.


본인의 경우 영어 문제를 심각하게 생각하지 않았다가 시니어 개발자로 채용되는 바람에 첫 출근하는 날부터 영어 문제로 굉장히 고생을 많이 했다. 시니어 개발자에게 최 우선으로 요구되는 덕목 가운데 하나가 커뮤니케이션 기술이기 때문이다. 게다가, 현지에서 접하는 언어 장벽은 생각보다 굉장히 높았다. 커뮤니케이션이고 나발이고 간에 뭐가 들려야 일단 시작이라도 해 볼 것 아닌가... 당황스럽게도 정말 첫 한 달 간은 (사람마다 분명 다를테지만) 아무것도 들리지 않았다. 스탠드업 미팅 뿐 아니라 모든 중요 미팅에서 상대가 무슨 말을 하는지 눈치 코치를 동원해도 정말 아무 것도 알아들을 수 없었다. 


그래서 궁여지책으로 보이스레코더를 구입한 다음 동료들에게는 양해를 구하고, 참석하는 모든 미팅을 녹음하기 시작했다. 그리고 나서 출퇴근길에 듣고 또 들었다. 그래도 안들리는 건 안들린다는 걸 깨닫고 좌절한 날이 며칠이던가... (안습)


그렇게 고생에 고생을 거듭한 지 몇달 후, 드디어 무언가 알아들을 수 있게 되었다는 것을 남몰래 기뻐하면서 훌쩍거리던 날이 생각난다. 왜 아니 그렇겠는가. 미국에 와서 일에 적응하기도 힘이 드는데, 언어 문제를 해결하기 위해 오디오북을 사고, 듣고, 받아 쓰고, 그래도 안 들리는 것들은 죽어라 외우고, 그리고 졸린 눈을 비벼가면서 출근하고, 자신에게 실망하고... 이짓을 반복하다보면 초인이라고 해도 지치게 마련이다. 도무지 뭘 알아듣는 것 같지 않아 보이니 동료들에게 무시당하는 일도 다반사. 자존감이 바닥나면 무릇 항우라고 해도 자진의 길을 택하는 법. 정말 다 때려치우고 돌아가기 직전까지 간 날이 하루 이틀이 아니었다. 


해서, 미국길을 고민하는 많은 개발자에게 가장 먼저 조언하고 싶은 것 중 하나는, 영어 실력을 키우라는 것이다. 


내가 동원한 방법은 다음과 같다. 


* 신기술은 무조건 영어로 접할 것 (Coursera 강의, YouTube 동영상)

* 오디오북 받아쓰기 

* 현지인 대화 녹음하고 반복 청취 

* 원어민 멘토 구하기 

* 한국인 커뮤니티 회피

* 한국 방송 회피 (무조건 CNN/영어방송)

* 영어 라디오를 들으면서 따라할 수 있는 건 무조건 따라하기

* 적극적으로 영어 발표 준비


그러나 이렇게 해도 한동안은 굉장히 고생할 것이다. 미국 도착한지 이년이 지난 지금도 나는 고생하고 있다. 그래서 의식적으로 다음과 같은 것들을 하려고 애쓴다. 커뮤니케이션 문제가 나의 유일한 단점으로 받아들여지도록 만들기 위해서. 


* 팀원들을 위한 툴 고안하기

* 남들보다 코딩 많이 하기 / 좋은 코드 많이 짜기

* 같은 문제를 겪는 아시안계 주니어 개발자 멘토하기 

* 등신같은 실수를 두 번 이상 반복하지 않기 위해 노력하기 

* 팀 내 프로세스 개선에 적극적으로 참여하기 (특히 신입 개발자를 위한) 

* 시키지 않아도 알아서 하는 일 늘리기 


이렇게 해도, 나는 여전히 커뮤니케이션 문제를 나의 유일한 단점으로 만들 수 없다. 


그러니 뭐니 뭐니 해도 가장 중요한 것은 다음이다.


* 관두고 싶더라도 버티기 


버티기 앞에 장사 없다. 


Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. mulder

    '관두고 싶더라도 버티기' 마지막 문장이 확 꽂히네요. 직장생활을 견디기 위한 가장 큰 덕목이지요. 미국까지 가시게 될줄 몰랐는데 그 나이에 나라까지 옮겨 새롭게 시작하시니 정말 대단하다는 생각이 들고 존경스럽습니다. 저는 마흔에 건강문제가 생겨 쉬고 있습니다만... 언제나 기본은 건강! 부디 타국에서 건강하게 잘 지내시길 바랄게요, 홧팅요~

    2017.10.05 21:55 [ ADDR : EDIT/ DEL : REPLY ]
  2. 감사합니다 건강하세요

    2017.10.07 11:40 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2017. 3. 6. 15:34

지난번에 예고 하였듯이, 오늘은 바람직한 링크드인(LinkedIn) 이력서의 비결을 알아보자.


'바람직한 링크드인 이력서'란 무엇인가를 알기 위해서는, 내가 가고 싶은 회사에서 어떤 기준으로 이력서를 고르는지를 소상히 알아보는 것이 순서이리라. 


아마존을 기준으로 살펴보면 (다른 기업들도 대동소이하리라고 생각되지만), 대략 다음과 같은 기준으로 이력서를 고른다.


1. 어느 회사를 다녔나?

2. 어느 학교를 다녔나?


그러나 보통 2는 1보다는 덜 중요하다. 미국 리크루팅 팀이 한국 대학 순위에 대해서 별로 신경쓰지 않기도 하거니와, 보통 리크루팅 팀이 채용 대상으로 하는 주니어-시니어 엔지니어는 2년 이상의 경력을 가진 사람을 말하기 때문이다. 경력자를 뽑는 경우에는 대체로 어디에서 일했는지만 본다고 생각하면 된다. 따라서 위의 두 기준은 대체로 아래의 한 가지 기준으로 수렴한다.


1. 어느 회사를 다녔나?


자... 그러면 바람직한 글로벌 이력서를 만들기 위해서는 좋은 회사에 들어가야 한다는 역설적인 결론에 도달한다. -_- 


미국 현지 리크루팅 팀이 주로 보는 한국 기업은 다음과 같다.


1. 샘숭

2. 엘쥐

3. 네이버

4. 넥슨

5. 카카오

6. NHN ENTERTAINMENT

7. ... (생각하기 귀찮아서 이하 생략)


그러니까 여러분이 생각하는 바로 그 기업들을 미국에서도 주목하고 있다고 보면 된다. 


... 그러니 어쨌던 2년 이하의 비경력자는 미국 진출하기가 쉽지 않다. 일단 국내에서 2년 이상의 경력을 쌓도록 하자. 가급적이면 해외에서도 알고 있을만한 굴지의 소프트웨어 회사면 유리하다. 


이 글을 쓰고 있는 필자의 링크드인 이력서는 어떻게 생겨먹었을까? 아래의 링크를 보자. 


https://www.linkedin.com/in/bjlee72/


보시다시피 별거 있다면 있고 없다면 없는, 평범한 이력서다. 아마 이 이력서에서 아마존 이전의 가장 쓸만한 경력은 NHN ENTERTAINMENT일텐데, 아마존에서도 그거 한줄 보고 연락한 것 같다. 


그러니 해외 취업을 꿈꾸고 있다면 국내에서 좋은 기업에 입사해 최소 2년간 열심히 일하도록 하자. 그러면 좋은 해외 기업에서도 높은 확률로 연락이 올 것이다. 그러니 링크드인 프로파일은 절대로 한글로 적지 말자. 구사 가능 언어 목록에는 꼭 영어를 명시하자.


다음 시간에는, 모든 개발자에게 공통적으로 심각한 문제 가운데 하나인 '영어'에 대해서 잠시 살펴보도록 하겠다.




Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2017. 3. 3. 04:22

오늘은 미국에서 프로그래머로 일하는 방법을 알아보자. 그 첫 번째 시간이다. 


미국에서 프로그래머로 일하는 첫 걸음이 뭐라고 생각하는가?


미국에서 프로그래머로 일하려면 일단 미국에 가야한다. 


미국에 가는 방법은 여러가지가 있다.


1. 비행기

2. 배

3. ?


이 중 가장 쉬운 방법은 비행기를 타는 것이다. 물론 돈이 좀 든다. 이 돈을 내가 직접 내면 너무 아깝다. 그러니 공짜로 갈 수 있는 방법을 알아봐야 한다.


공짜로 가는 방법에는 여러가지가 있으나, 가장 보편적인 것은 출장일 것이다. 그러나 회사에서 돈들여서 출장을 보내줬더니 면접이나 보러다니고... 그러다가 ㅈ망하기 딱 좋다. 


가장 좋은 방법은 일단 면접에 합격하고 미국 취업 비자를 받은 다음 해당 회사가 지원해주는 트랜스퍼 패키지를 이용해서 미국에 가는 것이다. 그러면 죄 공짜다. 


그러니 결론은 하나 뿐이다. 일단 면접에 합격해야 한다. -_-


그러면 한국에서 면접에 합격하려면 어떻게 해야 하나?


한국에 자주 와서 대규모 채용 행사를 진행하는 회사를 눈여겨 봐뒀다가 면접을 보면 된다. 대표적인 회사로 아마존이 있다. 일년에 두어번씩 한국에서 채용 행사를 하니 그 기회를 이용하면 된다. 


한국에서 열리는 채용 행사를 통해 면접을 보는 경우, 대개의 경우 당일 바로 당락 통보를 받으므로 편하다. 


그런대 대관절 채용 행사에 초청은 어떻게 받나?


보통 아마존 같은 곳에서 채용 대상 직원을 물색하는 방법은 다음의 몇 가지다.


1. 링크드인 이력서

2. 아마존 직원을 통한 추천


따라서, 취업하고 싶은 회사에 아는 사람이 없으면 링크드인 이력서를 잘 써서 검색 대상이 되는 수 밖에 없다.


다음 시간에는 링크드인 이력서를 잘 쓰는 방법을 알아보자. 




Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 담덕

    우선 영어를 해야되죠? ㅠㅠ

    2017.03.04 13:48 [ ADDR : EDIT/ DEL : REPLY ]
  2. 다음 편이 기다려지네요. 다음 편에서 관리자님의 링크드인 이력서도 예시로 들어주시면 좋을 것 같습니다.

    2017.03.05 23:05 신고 [ ADDR : EDIT/ DEL : REPLY ]