[카테고리:] IT

시니어 개발자가 되기 위해 무엇이 필요한지에 대한 글을 보면 대부분 소프트 스킬에 초점을 맞추고 있다. 기술을 최신 상태로 유지하고, 의사소통 방법을 배우고, 후배 개발자를 멘토링하라는 식이다. 이런 권장 사항은 모두 필요하고 적절하지만 솔직히 말해서 다소 공허하기도 하다. 사실 시니어 개발자와 주니어 개발자의 본질적인 차이는 소프트웨어 개발 현장에서 보낸 시간의 크기와 이에 따른 교훈이다. 이를 염두에 두고 시니어 개발자가 힘들게 얻은 경험을 통해 알고 있는 4가지를 정리했다.

명확성이 가장 중요하다는 것을 안다
인디오슬롯 | 카지노게임 개발자가 할 수 있는 가장 중요한 일은 읽기 쉬운 코드를 작성하는 것이다. 이는 너무나 당연한 것이므로 말할 필요도 없다. 하지만 세상에는 쉽게 읽을 수 없는 코드가 엄청나게 많다. 너무 많은 코드가 미래의 어느 시점에 누군가 읽어야 한다는 사실에 고려하지 않고 작성된다. 그리고 우리 대부분은 그 불쌍한 사람이 바로 내가 될 수 있음을 간과한다. 좋은 코드는 나중에 읽힐 목적으로 작성될 뿐만 아니라 디버깅을 목적으로 작성되기도 한다. 모든 언어가 다르고 모든 디버거가 각자의 방식으로 작동하지만, 코드는 항상 디버깅하기 쉬운 방식으로 작성해야 한다.

놀랍게도 읽기 쉬운 코드를 작성하는 것과 디버깅하기 쉬운 코드를 작성하는 것은 서로 밀접한 관련이 있다. 디버깅의 대부분은 특정 순간에 실행 중인 애플리케이션의 상태를 이해하는 것이다. 코드가 실행될 때 함수, 클래스 등을 명확하게 선언하면 디버거에서 해당 코드가 어떤 상태인지 확인할 수 있다. 또한 코드를 가독성 있게 만드는 장점도 있다.

인디오슬롯 | 카지노게임 코드의 명확성은 주석이 필요 없는 코드를 작성할 때도 중요하다. 일단 개발자가 코드에 주석을 달 필요가 있다고 느낀다면 그 이유를 자문해야 한다. 코드가 명확하지 않기 때문에 주석이 필요하다고 생각하는 것이 아닌지 의심해야 한다. 이런 의견에 동의하지 않는 이들도 있겠지만, 놀랍게도 세상에는 코드에 모든 줄에 주석을 달아야 하는 기업이 있다. 하지만 개발 업계에 오래 종사할수록 필자는 주석이 필요하지 않다고 더 강하게 믿는다. 코드에 주석을 달아야 할 필요가 있다고 생각되면 코드를 다시 작성하는 것이 맞다. 주석이 필요하지 않도록 처음부터 코드를 작성하는 것이 더 좋은 방법이다.

복잡성이 대부분 코드 문제에서 비롯된다는 것을 안다
복잡성을 피하는 것은 좋은 코드를 만드는 데 매우 중요하다. 그리고 코드의 복잡성을 피하는 방법은 사실 간단하다. 단순하고 직관적으로 쓰되, 복잡한 것은 절대 작성하지 않으면 된다. 말장난처럼 들리겠지만 그렇지 않다.

실제로 복잡성은 피하기 쉽다. 한 가지가 두 가지 이상 기능을 수행하지 않도록 하면 된다. 실제로 소프트웨어에서 복잡성이 시작되는 부분이 2가지 이상 기능을 하는 엔티티다. 코드 베이스의 모든 엔티티가 단일 기능만 하도록 작성하면, 무엇이든 수정해야 할 때 하나만 고치면 된다. 클래스, 메서드, 함수, 코드 한 줄 등도 마찬가지다. 모든 것이 한 가지 이상의 일을 해서는 안 된다. 물론 ‘한 가지 일만 하는’ 모든 부분이 상호작용하면 복잡해 지기 마련이다. 하지만 무언가가 고장 나면 이를 고쳐도 고장 난 부분에만 영향을 미치고 다른 부분에는 영향을 미치지 않게 된다.

단, 텍사스홀덤( 인디오게임 | 슬롯 ) 코드에서 복잡한 것을 작성하지 않는 것과 복잡한 시스템을 만들지 않는 것은 다르다. 고급 스위스 시계가 복잡하고 정교한 기기이긴 하지만 기어와 스프링과 같은 단순한 부품이 모여 이 복잡성을 만들어내는 것과 같다. 이런 생각을 염두에 두고 코드를 작성하면 코드의 복잡성을 줄일 수 있다.

빠르게 가려는 유혹을 거부한다
네이비씰의 모토가 바로 “느림은 부드러움이고 부드러움은 빠름”이라는 것이다. 이들은 긴박한 상황에서 생사를 가르는 결정을 내려야 하지만 그럼에도 이런 모토를 갖고 있다. 직관적이지 않은 것 같지만 생각해보면 완벽하게 이해가 된다. 서두르면 실수를 저지르기 쉽고, 서두를수록 실수할 확률이 높기 때문이다. 실수하면 되돌리는 데 많은 시간이 걸린다. 서두르지 않고 천천히 진행하면 실수를 줄이거나 없앨 수 있으며, 실수를 하지 않으면 전체 프로세스가 더 빨라진다.

노련한 개발자는 이 원칙이 코드에도 적용된다는 것을 알고 있다. 서두르는 코드는 나쁜 코드다. 시니어 개발자는 시간을 들여 처음부터 올바르게 작업하면 실수가 줄어들고, 이해하기 어려운 코드가 줄어들며, 코드를 유지, 관리할 때 더 좋은 결과를 얻을 수 있음을 안다. 서두르면 좋을 것이 아무것도 없음을 안다. 이처럼 훌륭한 소프트웨어는 코드를 작성할 때 신중하고 사려 깊은 태도를 갖는 데서 시작한다.

장기적인 이익을 위해 단기적인 고통을 감수한다
우리 모두 해봤다. 주말 동안 새로운 기능을 개발하기 위해 모든 것을 해킹하고, 우리가 하는 일의 품질을 완전히 무시한 채로 작업한 경험말이다. 여기에는 여러 가지 이유가 있겠지만, 대부분 돈 때문이다. 월요일 아침에 자료가 없으면 잠재고객은 계약을 체결하지 않거나 경쟁사로 떠날 것이다. 때로는 컨퍼런스에서 프레젠테이션을 위해 데모를 완성해야 하는데 그 데모가 실제 기능으로 바뀌는 경우도 있다.

그리고는 우리는 항상 후회한다. 예외가 없다. 하지만 피할 수 없는 버그가 발견돼도 코드 자체를 수정하기가 어렵다. 기능들을 볼트로 끼워 맞췄기 때문에 애플리케이션의 다른 모듈이 손상돼 또 다른 비즈니스에 차질을 주기도 한다. 멈추지 않는 회전목마 같은 일이지만, 어쨌든 이런 일이 벌어진다. 유능한 선임 개발자는 이런 상황을 최대한 피하고, 문제가 발생했을 때 피해를 최소화하는 방법을 알고 있다.

정리하면 인디오슬롯 | 카지노게임 커뮤니케이션 기술과 후배 개발자를 멘토링하는 것도 시니어 개발자가 해야 할 중요한 일이다. 그러나 경험을 통해 알고 있는 것이야말로 시니어 개발자를 진정으로 차별화하는 요소다. 시니어 개발자는 코드를 명확하고 단순하게 유지하고, 천천히 진행하며, 긴 안목으로 바라보는 방법을 알고 있다.
editor@itworld.co.kr

원문보기:
https://www.itworld.co.kr/topnews/342346#csidx0f27da2c95ad7cc954cb2626663723b

한때는 프라이버시를 당연한 것으로 여겼다. PC가 처음 가정에 널리 보급되기 시작했을 때도 PC는 프라이버시를 위한 도구로 사용됐다. 디지털 백과사전이나 초기 온라인 데이터베이스를 이용해 가장 난처한 질문에 익명으로 답할 수 있었다.

하지만 인터넷 사용량이 증가하면서 개인 정보에 대한 통제력이 급격히 떨어지기 시작했다. 이제는 아무도 자신에 대해 공유되는 세부 정보를 완전히 통제할 수 없는 단계에 이르렀다. 점점 더 많은 기술 제품과 서비스가 삶 깊숙이 파고들고 있으며, 종종 사용자의 정보를 유출하기도 한다.

마이크로소프트 리콜(Recall)은 가장 대표적인 최신 사례다. 시간을 절약할 수 있는 새로운 기능인 리콜은 사용자가 하는 모든 작업의 스크린샷을 캡처한 다음, 지난주 봤던 요리 레시피나 몇 달 전에 동료가 보낸 메시지를 찾고 싶을 때 AI를 활용해 해당 데이터를 검색한다. 기본적으로 PC가 사용자를 감시하지만, 이는 사용자의 이익을 위한 것이다. 그리고 초기 발표에 따르면, 해당 기능은 호환되는 PC에서는 기본적으로 켜져 있다. 데이터를 저장하는 방식은 시스템이 손상되더라도 해커가 사용자의 모든 활동을 볼 수 있는 방식이다(이런 점에서 백신 프로그램이 항상 활성화되어 있는지 확인하기를 바란다).

리콜 기능이 공개된 후 거센 반발이 일자 마이크로소프트는 신속하게 리콜 기능을 개편했다. 기본적으로 꺼져 있도록 설정하고, 윈도우 헬로를 사용하도록 요구하고, 액세스할 때만 파일을 해독하는 적시 암호 해독(just-in-time decryption) 방식으로 전환했다. 대응 속도는 칭찬할 만했지만, 처음부터 이런 방식을 채택할 수 있었을 것이라는 의견도 있었다.

에어태그의 추적 기술이 얼마나 위험한 방식으로 악용될 수 있는지 이미 모두가 알고 있기 때문에 필자는 왜 리콜과 관련해 이런 해프닝이 일어났는지 알고 싶었다. 마이크로소프트는 스토킹을 위한 에어태그 사용에 대한 애플의 느린 반응에서 교훈을 얻고 온라인 위협과 데이터 보안에 대한 광범위한 지식을 쌓을 수 있는 기회가 있었다. 하지만 그렇게 하지 않았다.

30년 전에는 기술에 대한 낙관론이 타당했다. 세상은 덜 연결되었고 인터넷에 대한 액세스는 새로운 것이었다. 혁신은 최상의 시나리오에 초점을 맞췄다. 현관문을 열어놓아도 되는 작은 마을처럼 누군가 악용할 염려 없이 새로운 기능을 출시할 수 있었다.

이제 시대가 바뀌었다. 최근 여러 대기업과 보안에 대해 이야기해 보면 대기업도 이를 인지하고 있다. 또한 회의 테이블에서 목소리를 넓히고 더 많은 관점을 포함하려는 기업의 노력에 대해서도 이야기를 나눴다. 하지만 포용성은 정체성뿐 아니라 다양한 경험까지 포함한다. 디자인팀에 폭넓은 관점이 부족하거나, 있음에도 무시되는 것은 안타까운 일이다.

낙관론을 현실적으로 완화한다고 해서 제품의 기능이 약해지지는 않다. 오히려 선택의 폭이 넓어진다. 개인적으로 필자는 마이크로소프트 리콜이 현재 상태로 출시된다면 언제든 사용할 의향이 있다. 회사가 기술이 사용될 수 있는 모든 악의적인 방법을 진정으로 이해하고 보호 기능을 추가했음을 보여주는 명확한 조치를 취한다면 해당 서비스를 사용해 볼 가능성이 훨씬 높아질 것이다.

때로는 인터넷이 현관문을 굳게 잠그고 현관문 앞, 창문에도 철문을 설치해야 안심되는 거대한 대도시처럼 느껴진다. 연결성에 영향을 미치는 모든 기술 제품과 서비스는 사람을 이동시키는 자동차와 같다. 하지만 이런 자동차를 판매하는 사람은 주차하기 전에 차 내부의 귀금속을 모두 비워야 한다는 도시 사람의 조언을 듣지 않는 듯하다. 스티어링 휠 잠금장치만 추가하고, 다녀오니 자동차 유리창이 깨져 있다는 사실에 놀랄 뿐이다.

원문보기:
https://www.itworld.co.kr/opinion/341835#csidxb677805460993e88a003db475170e91