처음엔 제목만 보고 코드의 질을 이야기하는 글타래일 거라 생각했는데.. 생각지도 못한 내용이었다.

개발자로서의 양심에 관한 글이었는데.. 정말 깊게 생각해볼만한 내용이었다.

원글 : https://www.vobour.com/book/view/T3gYPaPH9eFiqw7WJ

여전히 부끄러운 코드 (The code I’m still ashamed of )

당신이 직업이 코드를 작성하는 일이라면, 아마도 경력에 있어 어느 시점에 노골적으로 비윤리적이지 않다면 약간의 속임수를 쓰는 코드를 요구할지도 모릅니다.

실제로 저에게도 이런일이 2000년에 일어났습니다. 그리고 그것은 저에게 있어서 결코 잊을 수 없는 일이었습니다.

저는 6살 때 처음으로 코딩을 시작했습니다. 그렇다고 제가 신동이라는 건 아닙니다. 그 당시에 저는 아버지에게서 많은 도움을 받았으니 말이죠. 저는 정말 코딩에 푹 빠져 있었고, 그것이 너무나 좋았습니다.

15살 무렵 저는 아버지의 컨설팅 회사에서 아르바이트를 하고 있었습니다. 주말과 여름동안 웹사이트를 만드는 일과 비지니스 어플리케이션 용 작은 컴포넌트를 작성하는 일을 했습니다.

제 보수는 정말 적었습니다. 하지만 아버지께서 지금도 얘기하시듯이, 방과 보드가 무료였고, 꽤 귀중한 직장 경험을 할 수 있었던 것은 사실입니다.

나중에, 저는 몇몇의 프리랜서 코딩 일을 통해 번 돈으로 학업에 보탬이 되기도 했습니다. 지역의 중소기업을 대상으로 소수의 초기 전자 상거래 사이트를 만드는 일도 했습니다.

21살이 되었을때, 저는 캐나다 토론토에있는 마케팅 회사에서 정규직으로 코딩 작업을 했습니다.

그 회사는 의사가 설립했으며, 대부분의 고객은 대형 제약 회사들이었습니다.

캐나다에서는 제약 회사가 처방 의약품을 소비자에게 직접 광고하는 방법에 엄격한 제약이 있습니다.

그렇기 때문에, 이러한 회사들은 약이 어떤 증상을 나타내는지에 대한 일반적인 정보를 제공하는 웹 사이트를 만들었습니다. 그런 다음, 사이트를 방문한 사람이 처방전이 있다는 것을 증명 할 수 있다면, 그 약에 대한 더 구체적인 정보가 있는 포털에 접근 할 수 있도록 하였습니다.

제가 배정 된 프로젝트 중 하나는 여성을 위한 약을 포함했습니다. 웹 사이트의 디자인과 스타일은 고객이 특히 10대 소녀를 타겟팅하고 싶어 한다는 것을 분명히 했습니다.

이 웹 사이트의 특징 중 하나는 소녀에게 일련의 질문을 던지고 그 답을 바탕으로 약을 추천하는 것이었습니다.

이 웹 사이트는 분명히 어떤 특정한 약물에 대한 광고 사이트가 아닌 일반적인 정보 사이트인 것처럼 했다는 것을 기억하길 바랍니다.

요구 사항을 받았을 때, 퀴즈에 대한 질문과 각 질문에 대한 객관식 답이 포함되었습니다.

요구 사항에서 빠진 것은 퀴즈가 끝날 때 나와 있는 답을 통해 그다음에 어떻게 해야 하는지에 대한 것이었습니다. 퀴즈의 답을 통해 어떤 약을 추천 할지를 어떠한 규칙으로 결정을 해야하는지가 빠져있었죠.

저는 이것에 대해 매니저(Account Manager)와 이야기 했습니다. 그녀는 고객에게 이메일을 보냈고, 요구 사항을 알려 줬습니다. 저는 그것을 기반으로 코드를 작성 했습니다.

웹 사이트를 고객에게 보여주기 전에, 프로젝트 매니저는 테스트를 위해 퀴즈를 풀어 보더니, 저에게 왔습니다:

“퀴즈가 제대로 안되는데요?” 그녀가 말했습니다
“음. 뭐가 잘못 됐나요?” 제가 물었습니다.
“음, 제가 퀴즈에 어떤 답을 하든, 가장 좋은 치료약으로 클라이언트의 약을 추천하는 것 같은데요. 제가 알레르기가 있다고 대답했을 때 또는 이미 약을 먹고 있다고 대답 했을 때 빼고는 말이죠.”
“네. 요구 사항에는 무조건 고객의 약을 추천하도록 되어 있는데요.”
“아, 그럼 알겠어요.”

그리고 그녀가 나갔다.

처음 그 요구 사항을 받았을 때 저는 망설였습니다. 어린 소녀들을 속이기 위해 디자인된 것을 코딩하는 것이 잘못되었다고 말했어야 했는데 말이죠. 하지만 사실, 저는 그 당시에 많은 걸 생각 할 수 있는 상황이 아니었습니다. 해야 할 일이 있었고, 그저 그 일을 했을 뿐입니다.

그때 우리가 한 일은 모두 불법이었습니다. 저는 우리 팀에서 가장 어린 개발자로서, 제 나이에 비해 많은 돈을 벌고 있었습니다. 결국 저는 이 사이트의 목적이 특정 약을 보여주기 위한 것이라는 것을 알았습니다. 그래서, 저는 이 전략을 “마케팅”이라고 생각했습니다.

클라이언트는 이 사이트에 매우 만족했습니다. 그래서인지, 대표는 저와 전체 팀을 멋진 스테이크 저녁 식사에 초대했습니다.

저녁을 먹은 날, 사무실을 떠나기 직전 동료가 제게 온라인 뉴스 보도에 대한 링크를 이메일로 보냈습니다. 그것은 제가 웹 사이트를 만들었던 약을 복용 한 어린 소녀에 관한 이야기였습니다.

그녀가 자살했다는 내용이었습니다.

그 약의 주요 부작용 중 심각한 우울증과 자살 충동이 있음이 밝혀진 것 입니다.

제게 이메일을 보낸 동료는 저녁 식사에 오지 않았습니다.

저 역시 무엇인가 어렵고 어색했지만 어쩔 수 없이 그곳에 갔습니다. 저는 뉴스 보도를 한 번도 언급하지 않았습니다. 스테이크를 조용히 먹고, 억지로 미소를 지을 뿐이었죠.

다음날, 저는 여동생에게 전화했습니다. 여동생은 당시 19 살이었습니다. 제가 그 프로젝트를 진행하는 동안 실제로 여동생이 그 약을 처방 받았음을 알게됐습니다.

우리는 처음에 모든 것이 우연의 일치 일 뿐이라고 생각했습니다. 어딘지 모를 불안감이 찾아 왔습니다. 저는 동생에게 즉시 그 약을 끊으라고 얘기했고, 고맙게도 동생은 제 얘기를 들었습니다.

제가 자살과 심각한 우울증에 대한 저의 입장을 합리화 할 수 있는 수많은 변명거리가 있습니다. 심지어 지금도, 이전의 환자들과 소송이 진행 중입니다.

제가 그일에 전혀 관여하지 않았다고 주장하는 것은 쉬운 일 일지도 모릅니다. 그래도, 저는 절대로 그러한 코드를 작성하는 것이 괜찮다고 생각 해본적이 없습니다.

그 저녁 식사가 끝나고 얼마되지 않아, 저는 그만 두었습니다.

개발자로서, 우리는 잠재적으로 위험하고 비윤리적인 관행에 맞서는 최후의 방어선 중 하나입니다.

우리는 소프트웨어가 운전을 대신하고, 당신의 가족을 축구 연습장으로 데려다 줄 미래에 점점 다가가고 있습니다. 이미 의사가 질병을 진단하는 데 도움을 주는 인공 지능 프로그램도 있습니다. 이런 것들이 곧 처방약을 추천해주는 상상은 어려운 일은 아닙니다.

소프트웨어가 계속해서 삶의 모든면을 차지하면 할수록 더욱 중요한 것은 우리가 윤리를 지켜나가는 것이고, 우리의 코드안에 항상 윤리적인 측면을 고려해야 한다는 것입니다.

그 날 이후로 저는 항상 코드를 작성하기 전에 이 코드가 미칠 영향에 대해서 몇 번 생각해 보려고 노력합니다. 당신 역시 그렇게 되기를 바랍니다.

이 글은 Bill Sourour의 The code I’m still ashamed of를 번역한 글입니다. 전문 변역가가 아니라서 오역이 있을 수 있습니다. 지적해주시면 수정하도록 하겠습니다. 원문은 아래에서 확인 하실 수 있습니다.

Tags: 개발, 개발자, 반성, 양심

원글 : https://www.facebook.com/groups/codingeverybody/permalink/1178978255476042/

신입사원을 뽑기 위해 이력서를 보고 있습니다. S/W 개발자가 선호할만한 회사가 아니기에 고스펙 지원자는 찾아볼 수도 없지만 이력서를 보면 과연 개발자로 지원을 한건지 생각을 하게 하는 이력서가 태반입니다.
이력서를 검토하고 추리고 연락해서 면접을 보는데 드는 시간과 노력이 취업준비생이 취업하기 위해 하는 노력에 비하면 아주 작지만 그래도 꽤 많은 시간을 들여야 해서 이력서를 검토하고 지원자를 가려 내는 나름의 노하우가 생겼는데, 모든 경우에 맞지는 않겠지만 참고 하시기 바랍니다.

1. 첫번째 검토시 성장과정이니 성격 등 장황하게 써 놓은 문장은 보지 않습니다. 지원동기도 일반적인 얘기인지 우리 회사나 제품을 한번이라도 찾아 보았는지, 내가 원하는 기술에 대한 경험이 있는지 빠르게 훑어 봅니다. “개발자에게 가장 필요한 덕목은 의지와 인내라고 생각합니다”류의 문장이 있으면 바로 접습니다.

2. 정보처리기사니 하는 각종 자격증은 쳐다 보지도 않습니다. 1종 운전면허 자격증 같은 경우는 쓰지 않느니만 못합니다. 운전기사를 뽑는 게 아니잖아요. 정성스럽게 쓴 이력서를 기업 담당자가 꼼꼼히 읽어 보리란 생각은 버리세요. 저는 하루에 많게는 100개 이상의 이력서를 봐야 할 때도 있습니다. 10분씩 잡아도 야근까지 해야 가능합니다. 내가 내세우고 싶은 것이 눈에 띄도록 해야 하며 그러기 위해서는 불필요한 것들은 최대한 배제해야 합니다. 어찌 보면 사진 찍는 것과 비슷합니다.

3. 특히 S/W개발자가 되려는 사람은 본인이 경험한 언어와 플랫폼, OS 등에 대해 눈에 띄게 정리할 필요가 있습니다. 단순히 C, C++, C#, JAVA 등으로 나열하는 것은 큰 의미 없습니다. 어느 정도 수준이고 어떤 프로그램을 작성해 봤는지를 어필할 필요가 있습니다. (1차를 통과하기 위해서는 제일 중요합니다)

4. 개인의 포트폴리오가 있으면 한번 더 보게 됩니다. 포트폴리오를 작성할 때에는 목차에서 전체를 한눈에 볼 수 있도록 하세요. 목차에는 해당 프로젝트의 제목, 팀인지 개인인지, 간략한 설명40자 미만)과 사용한 기술 등이 들어가야 하며, 상세 페이지에서는 사진을 곁들인 프로젝트에 대한 설명을 넣어 주세요. 어려웠던 점과 극복 과정 등을 간략하게 추가해 주시고 팀 프로젝트인 경우에는 각 팀원이 맡은 역할을 적어 주셔야 합니다. 그리고 폰트는 고딕체를 사용하세요. 샘물체니 특이한 폰트는 눈길을 끄는 것이 아니라 짜증을 부릅니다. 하지만 너무 많은 프로젝트는 역효과가 있을 수도 있습니다. 지난번 어느 지원자는 학교 수업시간 과제까지 모두 정리해서 제출을 했더군요. 그 노력은 가상했지만 그 중에서 우리 회사에 맞는 것들만 좀 추려서 냈으면 어땠을까 싶습니다.

5. 지원을 하시기 전에 그 회사에 대해 먼저 알아 보십시오. 입사했다가 생각했던 것과 달라서 후회할 수도 있고 이력서에 그 회사나 그 회사 제품에 대한 언급을 하고 이를 자신이 입사하고 싶은 이유와 연결시키면 우선 좋은 인상을 줍니다. 반면에 다른 회사에 지원했던 이력서를 복사해서 갖다 붙였구나 하는 생각이 들면 서류 통과 힘듭니다.

Tags: 개발자, 신입, 이력서