성장을 위한 IT 콘텐츠,
동료들과 함께 읽고 싶다면?
요즘IT 슬랙봇으로 간편하게 받아보세요!
함께 성장하는 요즘IT인의
실무 라이브러리
소프트웨어 산업에는 하루에도 수십 개의 새로운 약어와 개념이 등장합니다. 특히나 빠르게 변하는 AI 기술 같은 경우라면 더욱 말입니다. AI를 제대로 맛보게 해 준 챗GPT와 같은 LLM이 우후죽순으로 등장하더니, 지금은 또 메타의 라마로 대표되는 SLM 혹은 sLLM이라는 게 나오고, AI를 완성시키는 AGI라는 개념도 이해해야 하는데, 또 검색-증강 생성이라며 RAG라는 말이 심심치 않게 들립니다. 배경 개념을 알고 거기에 쉬운 스토리를 붙이면 이해에 어렵지 않습니다. 최소한 이 글을 끝까지 읽으신다면 RAG에 대한 이해는 제가 책임지겠습니다. 자, 시작합니다.
한창 MSA(Microservices Architecture)로의 전환을 진행하는 중이었던 저희 팀은 새로운 branch 전략이 필요한 상황이었습니다. MSA로 전환하면서 기존 정기 배포 방식은 버리고 수시 배포를 하기로 결정했기 때문이었죠. Git-flow, Github-flow, Gitlab-flow를 포함해 여러 branch 전략을 살펴보았지만, 팀 환경에 꼭 맞는 branch 전략은 없었습니다. 그래서 팀의 요구 사항과 환경에 맞는 branch 전략을 직접 만들기로 결정했습니다.
삼성전자에서 십몇 년 전 PRD를 처음 접한 이후로 어디를 가나 저는 PRD를 작성해야 한다고 주장하는 사람이었습니다. 반대로 어느 곳에서도 ‘제대로’ PRD를 쓰는 조직을 만나지는 못했습니다. 그런 조직에서 일하는 방식, 제품을 만드는 과정은 대체로 비슷합니다. 스크린 플로우를 그리고, 여기에서 출발해 피그마나 스케치로 프론트 제작을 먼저 하고 있었습니다. PRD에 대해서는 ‘그런 건 느리다’ 라거나 ‘이렇게 하는 게 더 빠르고 잘한다’는 입장이 많았고, ‘PRD 같은 건 삼성전자 정도 되는 조직에서나 쓰는 거’라는 반응도 있었습니다. 그런 이들을 위해 오늘은 PRD를 작성하는 목적은 무엇이고, 누가 써야 하는가에 대해 얘기해 보겠습니다.
레거시 코드 정리는 모든 개발자에게 피할 수 없는 과제이자 커다란 부담이다. 특히 시간이 지나면서 유지 보수가 어려워진 코드는 점차 기술 부채로 쌓여가며, 프로젝트의 장기적인 성장을 방해하는 요소로 작용하게 된다. 최근 레거시 코드 정리 작업을 맡게 되었고, 최대한 안전하게 코드를 변경할 방법을 찾기 시작했다. 검토할 코드 양이 많아 일정 산정부터 쉽지 않았지만, 동료들에게 조언을 구하며 체계적으로 접근해 큰 문제 없이 마무리할 수 있었다. 내가 얻은 교훈은 레거시 코드를 정리할 때는 무엇보다 코드의 안정성을 최우선으로 해야 한다는 것이다. 오늘은 코드의 안정성을 해치지 않고, 레거시 코드를 정리하는 방법을 이야기해 보고자 한다.
성장을 위한 IT 콘텐츠,
동료들과 함께 읽고 싶다면?
요즘IT 슬랙봇으로 간편하게 받아보세요!
개발자는 소프트웨어 개발 프로젝트에서 디자이너와 협업할 일이 많습니다. 피그마(Figma)는 이러한 협업을 원활하게 해주는 툴로서 현재 다양한 UI/UX 디자인에 사용되고 있는데요. 개발자가 피그마를 활용하면, 디자인을 코드로 변환하는 작업을 더 효율적으로 할 수 있어 개발 생산성을 높일 수 있습니다. 또한 피그마는 1인 개발이나 소규모 프로젝트에서 빠르게 아이디어를 구체화할 때 유용하게 활용할 수 있는 도구이기도 합니다. 이번 글에서는 피그마의 기본 개념을 살펴보고, 개발자 관점에서 자주 사용하는 기능과 활용 팁을 정리해 보았습니다.
SI 만렙 개발자는 돈은 많이 벌까요? 당연히 많이 법니다. 하지만 스타트업 같은 파격적인 대우는 없습니다. 아웃소싱 시장이 파격적이지 않거든요. 누구나 아는 유명한 개발자가 있을까요? 글쎄요. SI 시장에선 유명세가 크게 도움이 되지 않습니다. 그렇다면, SI 하다가 네이버 갈 수 있을까요? 갈 수 있습니다. 그렇게 가신 분들이 꽤 있습니다. 다만 수능처럼 1년 재수한다고 갈 수는 없습니다. 이번 편은 “SI 회사”에 취업하는 사회 초년생들을 위한 글입니다. 어떻게 일하고 어떻게 성장할 것이냐, 라는 고민에 도움이 되면 좋겠습니다.
요즘 AI를 도입하지 않는 기업을 찾아보기 어렵습니다. 그만큼 모든 산업 분야에서 AI를 활용하여 업무 효율을 높이고, 서비스를 개선하려는 노력이 활발히 이루어지고 있습니다. 하지만 AI를 도입하여 좋은 성과를 이루어내는 것은 꽤 어려운 일입니다. 우스갯소리로 AI를 ‘돈 먹는 하마’라고 부르는 것도 사실 농담이 아닙니다. AI를 도입해 투자 수익률을 달성하지 못하는 경우가 허다하니까요. 실제로 POC 단계에서 끝내는 이유도 투자 수익률을 감당하지 못해서 끝내는 경우도 많습니다. 그렇다면 어떻게 해야 좋은 성과를 이루어 낼 수 있을까요? 그 해답은 아마 ‘MLOps’에 있을지도 모릅니다.
오늘날 빠르게 변화하는 업무 환경에 따라 효율성을 극대화하고 반복 작업을 줄이는 자동화가 점점 더 중요해지고 있습니다. 한편 자동화와 함께 콘텐츠의 생산과 분석의 관점에서 생성형 AI가 활용되기 시작했습니다. 이런 변화에 맞춰 이번 글에서는 GPT 모델을 사용하는 챗GPT API와 구글 앱스 스크립트를 결합한 자동화 예제를 다루려고 합니다. 예제에서 사용할 두 가지 기술 모두 비교적 쉽게 구현할 수 있지만, 강력한 자동화 도구입니다. 기업이나 조직, 커뮤니티 등에서 구글이 제공하는 서비스 기반으로 업무를 자동화하는 방법을 소개하겠습니다.
몇 달 전에 썼던 <의사소통이 즐거운 개발자의 3가지 능력>이 인기 글이 되었습니다. 무엇보다 많은 분들이 의사소통에 대해 관심을 가지고 있다는 사실이 반가웠습니다. 저 역시, 최근에 설계에 관한 글을 썼는데, 이를 두고 지인들과 대화를 나누는 과정에서 인식의 다양성을 느끼는 동시에 의사소통의 중요성을 깨달을 수 있었습니다. 특히 자신이 익숙한 경험이나 지식을 대할 때, 다른 사람의 인식과 경험을 내게 익숙한 대로 판단하거나 걸러내지 않고 그대로 받아들일 수 있다면 사고의 폭을 넓힐 수 있다는 생각이 들었습니다. 개발자의 의사소통에 대해 더 확장해 얘기해 보고자 이런 경험과 관련이 있거나 연상되는 사건을 추려서 글로 엮어 보았습니다.
이제 WinForm을 다루는 개발자들은 무언가 새로운 것을 개발하는 업무는 거의 없는 상황에 놓였다. 그보다 묵을 대로 묵은 옛 선배들의 레거시 코드를 리팩토링하거나 이를 참고해 기능을 확장하는 경우가 많다. 일반적으로 개발 분야에서 리팩토링이란 “결과의 변경 없이 코드의 구조를 재조정함”을 의미한다. 다만 WinForm에는 GUI 디자이너, Win32 컨트롤, Form 등 독자적인 클래스 라이브러리가 있으므로 이와 같은 환경에 적용할 리팩토링 방법을 이해해야 한다. 스마트팩토리 분야에서 가장 많이 쓰이는 .NET WinForm의 리팩토링 방법을 다뤄 보겠다. 예제와 함께 작가가 스마트팩토리 분야에서 직접 WinForm 개발을 해오면서 중요하다고 생각한 몇 가지 전략을 소개하고자 한다.
지난 9월, 인스타그램은 18세 미만 사용자를 보호하고자 <인스타그램 10대 계정(Teen Accounts)>이라는 새로운 기능을 도입했습니다. 앞으로 모든 10대용 계정이 비공개 계정으로 전환될 예정입니다. 그에 따라 10대들의 인스타그램 사용 경험도 바뀔 것으로 보이는데요. 10대 계정의 비공개 전환이 이들의 SNS 경험을 어떻게 바꿀지 탐구해 보려고 합니다. 챗GPT(ChatGPT)와 피그마 AI 플러그인으로, 하루 만에 리디자인부터 검증까지 마친 과정을 공유합니다. 특히 민감한 사회적 이슈에 UX 디자이너가 AI 도구를 활용해 어떻게 혁신적으로 대응할 수 있을지 살펴보겠습니다. AI 디자인 접근법에 대한 구체적인 가이드도 함께 정리할게요.
여러분이 크롬 브라우저에서 youtube.com으로 들어간다고 가정해 볼게요. 이때 브라우저는 클라이언트의 역할을 합니다. 이 브라우저가 유튜브의 서버 컴퓨터에 요청을 보내 사이트 코드를 받아오는 거예요. 그러면 우리는 그 정보를 받아 사이트를 쓸 수 있게 됩니다. 그런데 여기서 궁금증이 생깁니다. 인터넷에 연결된 수많은 컴퓨터 가운데 이 유튜브 사이트의 서버 컴퓨터는 어떻게 찾을 수 있을까요? 이번에는 그 물음에 대한 답을 하려고 합니다. 웹을 이해하기 위해 알아야 할 핵심 지식, IP, DNS, URL의 기초 개념을 파헤쳐 보겠습니다.
이력서 멘토링을 인연으로 저와 멘토/멘티 관계를 맺은 유남주 님은 주니어 백엔드 개발자입니다. 어느 날 커피챗을 신청한 유남주 님이 다짜고짜 게릴라 인터뷰를 해도 되겠냐고 묻습니다. 인터뷰 받는 사람에게 주제를 알리지 않고 즉석에서 날 것 그대로 대답을 받기 위한 방식이라고 하는데, 왜 그런 인터뷰를 하는 걸까요? 별로 내키지 않아 하는 저를 유남주 님이 설득합니다. ‘스타트업 대표로서 비용을 절감하기 위한 엔지니어링적 시도’를 주제로 이야기 나누고 싶었다고 하네요. 인터뷰 방식은 긴장되지만, 주제가 흥미로웠습니다. 어디 한 번 이야기 나눠볼까요?