개발자는 소프트웨어 개발 프로젝트에서 디자이너와 협업할 일이 많습니다. 피그마(Figma)는 이러한 협업을 원활하게 해주는 툴로서 현재 다양한 UI/UX 디자인에 사용되고 있는데요. 개발자가 피그마를 활용하면, 디자인을 코드로 변환하는 작업을 더 효율적으로 할 수 있어 개발 생산성을 높일 수 있습니다. 또한 피그마는 1인 개발이나 소규모 프로젝트에서 빠르게 아이디어를 구체화할 때 유용하게 활용할 수 있는 도구이기도 합니다. 이번 글에서는 피그마의 기본 개념을 살펴보고, 개발자 관점에서 자주 사용하는 기능과 활용 팁을 정리해 보았습니다.

SI 만렙 개발자는 돈은 많이 벌까요? 당연히 많이 법니다. 하지만 스타트업 같은 파격적인 대우는 없습니다. 아웃소싱 시장이 파격적이지 않거든요. 누구나 아는 유명한 개발자가 있을까요? 글쎄요. SI 시장에선 유명세가 크게 도움이 되지 않습니다. 그렇다면, SI 하다가 네이버 갈 수 있을까요? 갈 수 있습니다. 그렇게 가신 분들이 꽤 있습니다. 다만 수능처럼 1년 재수한다고 갈 수는 없습니다. 이번 편은 “SI 회사”에 취업하는 사회 초년생들을 위한 글입니다. 어떻게 일하고 어떻게 성장할 것이냐, 라는 고민에 도움이 되면 좋겠습니다.

레거시 코드 정리는 모든 개발자에게 피할 수 없는 과제이자 커다란 부담이다. 특히 시간이 지나면서 유지 보수가 어려워진 코드는 점차 기술 부채로 쌓여가며, 프로젝트의 장기적인 성장을 방해하는 요소로 작용하게 된다. 최근 레거시 코드 정리 작업을 맡게 되었고, 최대한 안전하게 코드를 변경할 방법을 찾기 시작했다. 검토할 코드 양이 많아 일정 산정부터 쉽지 않았지만, 동료들에게 조언을 구하며 체계적으로 접근해 큰 문제 없이 마무리할 수 있었다. 내가 얻은 교훈은 레거시 코드를 정리할 때는 무엇보다 코드의 안정성을 최우선으로 해야 한다는 것이다. 오늘은 코드의 안정성을 해치지 않고, 레거시 코드를 정리하는 방법을 이야기해 보고자 한다.

요즘 AI를 도입하지 않는 기업을 찾아보기 어렵습니다. 그만큼 모든 산업 분야에서 AI를 활용하여 업무 효율을 높이고, 서비스를 개선하려는 노력이 활발히 이루어지고 있습니다. 하지만 AI를 도입하여 좋은 성과를 이루어내는 것은 꽤 어려운 일입니다. 우스갯소리로 AI를 ‘돈 먹는 하마’라고 부르는 것도 사실 농담이 아닙니다. AI를 도입해 투자 수익률을 달성하지 못하는 경우가 허다하니까요. 실제로 POC 단계에서 끝내는 이유도 투자 수익률을 감당하지 못해서 끝내는 경우도 많습니다. 그렇다면 어떻게 해야 좋은 성과를 이루어 낼 수 있을까요? 그 해답은 아마 ‘MLOps’에 있을지도 모릅니다.

오늘날 빠르게 변화하는 업무 환경에 따라 효율성을 극대화하고 반복 작업을 줄이는 자동화가 점점 더 중요해지고 있습니다. 한편 자동화와 함께 콘텐츠의 생산과 분석의 관점에서 생성형 AI가 활용되기 시작했습니다. 이런 변화에 맞춰 이번 글에서는 GPT 모델을 사용하는 챗GPT API와 구글 앱스 스크립트를 결합한 자동화 예제를 다루려고 합니다. 예제에서 사용할 두 가지 기술 모두 비교적 쉽게 구현할 수 있지만, 강력한 자동화 도구입니다. 기업이나 조직, 커뮤니티 등에서 구글이 제공하는 서비스 기반으로 업무를 자동화하는 방법을 소개하겠습니다.

저는 다국적 IT 회사에서 10년 가까이 일하면서 다양한 나라의 개발자와 엔지니어를 만났습니다. 오랜 기간 그들과 협업하는 과정에서 개발자의 영어 구사 능력에 자연스레 관심을 가지게 되었습니다. 한편 그 회사에서 일하는 한국인 개발자들과 함께 할 기회도 많았습니다. 그들이 다른 나라 개발자에 비해 뒤지지 않는 뛰어난 개발 실력을 갖추고도, 오로지 영어 때문에 능력을 온전히 평가받지 못하는 모습 역시 보고는 했습니다. 이번 글에서는 개발자가 영어 공부를 해야 하는 이유를 사실과 데이터에 근거해 살펴보고자 합니다. 글의 마지막에는 제 개인적인 견해를 바탕으로 ‘개발자에게 영어가 중요한 또 다른 이유’를 덧붙이고자 합니다.

한창 MSA(Microservices Architecture)로의 전환을 진행하는 중이었던 저희 팀은 새로운 branch 전략이 필요한 상황이었습니다. MSA로 전환하면서 기존 정기 배포 방식은 버리고 수시 배포를 하기로 결정했기 때문이었죠. Git-flow, Github-flow, Gitlab-flow를 포함해 여러 branch 전략을 살펴보았지만, 팀 환경에 꼭 맞는 branch 전략은 없었습니다. 그래서 팀의 요구 사항과 환경에 맞는 branch 전략을 직접 만들기로 결정했습니다.

소프트웨어 산업에는 하루에도 수십 개의 새로운 약어와 개념이 등장합니다. 특히나 빠르게 변하는 AI 기술 같은 경우라면 더욱 말입니다. AI를 제대로 맛보게 해 준 챗GPT와 같은 LLM이 우후죽순으로 등장하더니, 지금은 또 메타의 라마로 대표되는 SLM 혹은 sLLM이라는 게 나오고, AI를 완성시키는 AGI라는 개념도 이해해야 하는데, 또 검색-증강 생성이라며 RAG라는 말이 심심치 않게 들립니다. 배경 개념을 알고 거기에 쉬운 스토리를 붙이면 이해에 어렵지 않습니다. 최소한 이 글을 끝까지 읽으신다면 RAG에 대한 이해는 제가 책임지겠습니다. 자, 시작합니다.

몇 달 전에 썼던 <의사소통이 즐거운 개발자의 3가지 능력>이 인기 글이 되었습니다. 무엇보다 많은 분들이 의사소통에 대해 관심을 가지고 있다는 사실이 반가웠습니다. 저 역시, 최근에 설계에 관한 글을 썼는데, 이를 두고 지인들과 대화를 나누는 과정에서 인식의 다양성을 느끼는 동시에 의사소통의 중요성을 깨달을 수 있었습니다. 특히 자신이 익숙한 경험이나 지식을 대할 때, 다른 사람의 인식과 경험을 내게 익숙한 대로 판단하거나 걸러내지 않고 그대로 받아들일 수 있다면 사고의 폭을 넓힐 수 있다는 생각이 들었습니다. 개발자의 의사소통에 대해 더 확장해 얘기해 보고자 이런 경험과 관련이 있거나 연상되는 사건을 추려서 글로 엮어 보았습니다.