처음 크롬을 접했을 때의 희열을 잊을 수 없다. 브라우저와 계정이 직접 연동된다는 것은 아주 큰 편리함을 가져다주었다. 몇 년간 크롬의 모든 것이 좋기만 했다. 하지만 새로운 구글 계정을 만들면서 이야기는 달라졌다. 구글 계정을 여러 개로 나눈 이유는 일과 취미를 분리하기 위함이었다. 그리고 두 번째 계정으로 크롬을 사용하게 되면서 전에는 보이지 않던 단점들이 눈에 들어오기 시작했다. 그때 아크 브라우저를 만나게 되었고, 그동안의 답답함이 해소되는 경험을 했다. 이번 글에서는 개발자의 관점에서 크롬을 정말 사랑하면서도 느꼈던 약간의 아쉬움, 그리고 아크가 그것을 어떻게 개선했는지 리뷰를 통해 살펴보고자 한다.
프로그래밍 언어는 소프트웨어를 개발하는 데 사용되는 도구이며, 이를 통해 다양한 기능을 수행할 수 있는 소프트웨어가 만들어집니다. 특히 우리는 복잡한 계산이나 데이터 분석을 할 때, 다양한 프로그래밍 언어와 소프트웨어를 사용합니다. 그러나 소프트웨어마다 계산 방식이나 수학적 라이브러리가 다를 수 있어, 동일한 문제를 다루더라도 결과가 다를 수 있습니다. 이러한 차이를 최소화하여 데이터 분석의 일관성을 유지하는 것은 매우 중요한 과제입니다. 이번 글에서는 이러한 소프트웨어 간 계산 차이의 예시(Rounding)와 이유를 살펴보고, 이러한 문제를 해결하고자 진행 중인 ‘CAMIS’ 연구 프로젝트에 대해 알아보겠습니다.
지난 7월 안데르센호로위츠는 금융 및 법률 실사 전문 AI 에이전트를 개발하는 소프트웨어 기업 ‘Hebbia AI’의 시리즈 B 라운드를 리드하며, 다음과 같은 용어를 전면에 내세웠습니다. “Service-as-a-Software” AI 시대에서 소프트웨어 산업은 근본적인 패러다임 전환을 앞두고 있다는 시각이 설득력을 얻고 있습니다. Service-as-a-Software는 보다 근본적인 변화입니다. 단순히 단어의 앞뒤를 바꾼 것 같지만 그 의미는 훨씬 심오합니다. ‘서비스의 소프트웨어화’ 시대는 당연히 사람이 수행해야 했던 많은 서비스를 소프트웨어가 대체함을 의미합니다. AI 에이전트로 대표되는 이런 서비스들이 빠르게 보급되면서 우리가 소프트웨어에 기대하는 기능 자체가 변화하고 있는 것입니다.
일반적으로 프롬프트는 ‘지시한다’, ‘말을 전한다’라는 뜻을 가지고 있습니다. LLM(Large Language Models)에서 프롬프트는 AI 모델에게 내리는 지시 사항 혹은 첫 대화의 물꼬를 뜻하는데요. 프롬프트를 설계하는 기술을 ‘프롬프트 엔지니어링(Prompt Engineering)’이라고 합니다. 프롬프트 엔지니어링은 AI 모델에게 특정 상황과 요구사항을 잘 지시하여, 기대하는 결과물을 만들게 하는 새로운 방식의 코딩입니다. 마치 우리가 프로그래밍 언어로 컴퓨터가 할 일을 로직으로 풀어내듯, 프롬프트에 자연어로 할 일을 지시하는 겁니다.
리액트는 프론트엔드 개발에서 가장 널리 사용되고 있는 자바스크립트 라이브러리입니다. 컴포넌트 기반 아키텍처와 가상 DOM 등의 개념을 도입하였으며, 여러 글로벌 기업이 리액트를 활용하여 웹 애플리케이션을 개발하고 있습니다. 이러한 리액트의 장점을 최대한 활용하기 위해서는 리액트의 기본 개념을 이해하고 적절한 성능 최적화 기법을 적용해야 합니다. 이에 본 글에서는 리액트 개발 시 알아야 할 기본 개념을 정리해 보고, 리액트 컴포넌트와 훅, 개발자 도구 및 성능 최적화 팁을 살펴보고자 합니다.
채용 담당자는 서류 전형에서 이력서를 본 다음 포트폴리오를 봅니다. 서류를 보는 순서는 대수롭지 않아 보이지만, 실제로는 대수로이 봐야 합니다. 다음 채용 전형 단계로 넘어가려면, 포트폴리오 유무와 관계없이 이력서에서 승부를 봐야 하거든요. 당연한 말처럼 보이나요? 그러나 이력서로 승부를 보려 하지 않는 경우가 생각보다 많습니다. 포트폴리오를 힘주어 만들고 정작 이력서는 부실한 거죠. 특히 신입 개발자는 아무래도 이력서를 만들기 어려우니, 포트폴리오로 스스로를 더 자세히 표현하려고 하는 듯 합니다. 크나큰 실책입니다. 포트폴리오를 만들 때 흔히 하는 실수로는 무엇이 있을까요?
지난주 IT 업계는 마이크로소프트발(혹은 크라우드스트라이크발) IT 대란 소식으로 정신이 없었습니다. 특히 항공사 시스템이 다운되어 항공편이 취소되었다거나, 증권거래소를 비롯한 금융사들도 서비스가 중단됐다는 등의 소식을 전하며 전례 없는 최악의 ‘IT 대란’이라고 명명하기도 했는데요. 그러나 한국에서는 최악의 IT 대란이라는 표현이 무색하게 그 피해 규모가 크지 않았습니다. 일부 저가 항공사와 게임사 등을 비롯해 약 10개 기업에서 피해가 발생했을 뿐, 주요 통신사와 빅테크 기업들은 큰 문제가 발생하지 않았다고 발표했습니다. IT 의존도가 낮은 국가라면 모를까, 한국은 IT 강국에 속하는 국가임에도 상대적으로 피해가 적었던 이유는 무엇일까요?
개발자를 준비하는 많은 분들이 자기 PR 목적으로 코드를 공유합니다. 그러나 가독성이 좋지 않은 코드를 공유한다면, 오히려 역효과가 날 수 있습니다. 코드를 통해 여러분이 고민한 내용을 온전히 전달하기 위해서는 가독성을 높이는 것이 중요합니다. 이번 글에서는 코드 스타일 외에 가독성 높은 코드를 작성할 수 있는 몇 가지 방법을 알아보겠습니다. 저 또한 개인 블로그에 코드를 공유할 때 항상 신경 쓰는 내용인 만큼, 이번 글을 통해 앞으로 코드를 공유할 때 한 번씩 적용해 보면서 점점 더 좋은 코드를 작성할 수 있으면 좋겠습니다.