개발자로 살아가면서 어려움을 겪는 것은 피할 수 없는 일입니다. 기술적 실력이 모자라서 그럴 수도 있고, 개발하고 있는 분야에 대한 도메인 지식이 부족해서 그럴 수도 있죠. 또한 동료와의 커뮤니케이션, 정치적인 요소, 일정의 압박, 회사의 재정 상태처럼, 개발 그 자체와는 직접적으로 상관이 없는 외부적인 요소로 인해 어려움을 겪기도 합니다. 오늘은 이러한 어려움의 유형 중에서도 문제 해결(Problem solving) 과정에서 겪는 어려움에 대해 집중해 보려고 합니다. 왜냐하면 외부적인 요인은 개발자 개인의 노력과 능력만으로는 통제할 수 없는 상황이 많으니까요. 반면 문제 해결 과정에서 겪는 어려움을 분석한다면 내가 어떤 이유로 인해 혼란스러움을 겪고 있는 상태인지 알 수 있고, 그에 맞는 적절한 해결 방법을 선택할 수 있을 것입니다.
이번 강의, 문과생이라고 표현하기는 했지만, IT 업계와 멀리 떨어져 있던 모든 분을 위한 강의입니다. “아무리 들어도 이게 무슨 소리인지 모르겠어요” 하면서도 IT 세상에 적응하고 싶은 분, 소통에 자신감이 떨어진 분들을 대상으로 합니다. 조금 더 쉽게 용어를 해설하며, 직장에서 커뮤니케이션을 잘 할 수 있는 방법에 초점을 맞춰 볼게요. 강의를 들으면 무엇을 배울 수 있을까요? IT 기업에서 개발자들과 잘 소통할 수 있습니다. 진짜 소통을 위한 액기스만 담았습니다. 짧은 콘텐츠지만, 집중해서 평생 써먹을 여러 용어와 개념을 같이 익혀봅시다.
2024년의 상반기가 끝나고 어느덧 평가 시즌이 다가왔다. 소심한 성격의 소유자인 나는 평가 시즌이 다가올 때마다 불안감에 휩싸이곤 한다. 내가 불안한 이유는 ‘최악의 평가를 받으면 어떡하지?’라는 생각과 나의 단점을 지적받는 것이 두렵기 때문이다. 어느 유명한 경영학자는 사람들에게 자신이 가진 단점을 고치려고 하기보다, 장점을 극대화하는 데 집중하라고 조언했다. 그러나 단점을 극복하려 노력하지 않고, 그대로 둔다면 결국 언젠가 내 발목을 잡을지도 모른다. 그렇다면 어떻게 도움이 되는 방향으로 피드백을 수용할 수 있을까? 이번 글에서는 내가 단점을 극복하고 성장할 수 있었던 방법과 생각을 공유해 보고자 한다.
태블릿PC에서 주로 쓰이던 arm64 아키텍처가 애플의 M1 노트북에 적용되며 arm64 기반 노트북 시장이 가파르게 성장하기 시작했습니다. 일반 노트북 시장뿐만 아니라 각 클라우드 사에서도 독자적으로 개발한 arm64 기반 컴퓨팅 인스턴스를 출시하고 있습니다. 이러한 흐름에 발맞춰 쿠버네티스 컨트롤 플레인 노드의 구성 요소 또한 arm64 기반을 지원하는 추세입니다. 따라서 나만의 arm64 기반 쿠버네티스 클러스터를 만들어 보며 이러한 변화에 대비할 수 있는 시간을 가져보도록 하겠습니다.
내가 방문했거나, 검색했던 혹은 무언가를 구매했던 사이트와 관심사 등을 분석해, 가장 최적의 광고를 어디서든 접할 수 있게 되었습니다. 광고주 입장에서는 가장 효과가 좋을 만한 타깃의 고객에게 광고를 효과적으로 전달하고자 할 것입니다. 따라서 소비자의 행동, 관심사, 인구 통계학적 정보 등을 기반으로, 맞춤형 광고를 제공해 효과를 극대화하는 것을 목표로 합니다. 이는 모두 ‘애드테크(Ad-Tech)’ 기술로 인해 가능한 것인데요. 이번 글에서는 애드테크 서비스의 주요 IT 컴포넌트가 어떻게 소비자와 광고주, 그리고 광고 게시자의 프로세스를 수행하는지 그 원리를 살펴보고자 합니다.
AI 도구는 제 개발 방식을 획기적으로 바꾸었습니다. 눈에 띄는 개발 생산성 향상을 경험할 수 있었죠. 특히 최근에는 구글에서 출시한 ‘제미나이’를 개발 프로젝트에 도입하여 사용하고 있는데요. 단순 코드 작성뿐만 아니라 개발 문서 작성, 지메일/유튜브 연동 등으로 다양한 작업에 유용하게 쓰고 있습니다. 실제 개발 프로젝트의 코드 마이그레이션, API 개발 작업 등에 활용하기도 했죠. 그 결과 제미나이는 “개발 실무에서 한 번쯤은 반드시 써봐야 하는 도구"라고 결론내릴 수 있었습니다. 제가 직접 사용하며 정리한 제미나이 사용 팁과 프로젝트 활용 사례를 공유하고자 합니다.
최근 우리는 하루하루 놀랍도록 빠르게 발전하는 인공지능을 보고 있다. 그런 와중에 인공지능이 미칠 긍정적인 영향과 혁신에 대해 기대하는 목소리, 부정적인 영향을 우려하는 목소리 역시 쏟아지고 있다. 일부에서는 인공지능에 대한 전망이 지나치게 과대평가 되었다는 그저 무시하기 어려운 의견 역시 제기되고 있다. 이번 글에서는 (1) 인공지능이 과대평가 되었을 가능성 (2) 그럼에도 인공지능은 혁신을 가져올 것이라는 가능성 (3) 혁신을 인정하지만, 부정적인 영향이 더 클 것이라는 가능성을 논의하고자 한다. 그럼 각각에 대해 살펴보도록 하자.
이번에 소개할 인물, 서지영 님은 개발자로 시작해 DBA를 거쳐 AI&데이터 스페셜리스트로 커리어를 쌓아 나가고 있습니다. 무려 두 번의 직군 전환을 성공적으로 이뤄낸 건데요. 물론 쉽지는 않았습니다. DBA로 갈 때는 우선 팀장님에게 이 일이 꼭 필요한 이유를 담은 기획안을 써내야 했습니다. 그전까지 회사에 DBA란 직군 자체가 없었기 때문이죠. AI 전문가로 넘어갈 때는 일과 공부를 함께 했습니다. 주에 2번, 대학원 야간 수업에 늦지 않으려 언제나 달렸고, 그렇게 늘 땀에 젖어 수업을 들었다고 합니다. 두 번이나 직군을 바꾼 이유는 단순합니다. ‘적성에 맞는’ 일을 ’10년이 지나서도’ 하기 위해서입니다. 그에게 성공적인 직군 전환의 방법과 AI 시대에 직장인으로 살아남는 방법을 들었습니다.
25년 차 개발자로 꾸준히 멘토링을 하다 보니 신입 개발자의 이력서를 볼 일이 많습니다. 신입 또는 경력이 짧은 주니어 엔지니어의 이력서는 대체로 비슷합니다. 조금 과장해 표현하면, 이름과 연락처를 가렸을 때 모두 같은 사람이 낸 이력서처럼 보이기도 하죠. 특히 “자신이 한 일을 사실 위주로 간결하게 쓰라”는 조언을 따른 이력서는 더욱 분별력이 떨어집니다. 저는 이런 형식을 신입이나 주니어에게 추천하지 않습니다. 신입 개발자는 ‘자신이 한 일’이 아닌 ‘자기 자신’을 이력서의 주제이자 주인공으로 삼고 작성해야 합니다. 좋은 이력서를 쓰는 방법을 함께 알아봅시다.