불과 2년 전까지만 해도 저는 서류 탈락과 면접 불합격 통보를 일상처럼 받아들이고 있었습니다. 그렇게 수십 통의 거절 메일을 받으며, 개발자로서 부족하다고 느끼던 시기가 있었죠. 그러나 이제는 구직 활동조차 하지 않았는데도 여러 곳에서 이직 제안을 받는 상황이 되었습니다. 아마 비슷한 고민을 하는 분들이 있을 겁니다. 회사 업무만으로는 뭔가 부족하다는 느낌, 더 성장하고 싶은데 방법을 모르겠다는 생각… 저도 그랬습니다. 회사 프로젝트는 론칭이 미뤄지기도 하고, 정확히 어떤 기여를 했는지 드러내기도 어려웠죠. 이 글에서는 제가 오픈소스 프로젝트 ‘NotionPresso’를 진행하며 배운 것들을 공유하고자 합니다. 오픈소스 주제를 선정하는 방법부터 구조 설계, 커뮤니티와의 소통, 그리고 결과물을 발전시키는 과정을 담았고, 이 여정을 통해 오픈소스라는 새로운 도전에 대한 작은 동기를 얻을 수 있다면 좋겠습니다.
PM이 성장하는 지점에 대해 정확하게 설명하기 위해 역설적으로 접근하려고 합니다. “우리가 어떤 상황에 놓여 있다면 성장 지점에 도달하지 못하는가, 왜 PM으로서 성장하지 못할 것이라고 생각하는가”에 대해 얘기해 보기로 합시다. PM의 성장은 제품 개발 프로세스 전반부에 뿌려둔 씨앗으로 후반부에서 결실을 맺을 때, 그 수확과 함께 이루어집니다. 무엇보다 숙련되어 가는 것과 성장하는 것이 다르다는 얘기를 하고자 합니다. 언제 어디서나 그렇겠지만, 개인도 숙련되는 것만으로는 만족할 수 없고 조직도 숙련되는 것만으로는 충분히 행복할 수 없습니다. 단순한 숙련과는 다른 차원에서 성장의 기회는 필수적이어야 합니다.
“서비스를 위한 AI를 개발한다”라고 할 때는 학습 데이터셋이 없는 경우가 많습니다. 물론 준비된 경우도 있겠지만, 실무에서는 없는 경우가 꽤 많죠. 테스트 데이터셋도, 어떻게 테스트 할지에 대한 방법도 정해져 있지 않고요. 이게 실제 서비스를 개발할 때 맞닥뜨리는 상황입니다. 그 대신 주어지는 다른 하나가 있습니다. 그게 뭐냐 하면, 서비스 요구 사항입니다. 오늘은 서비스 목적으로 AI를 개발하는 것이 학습 목적의 모델 개발과 얼마나 다른지 중점적으로 알아보고자 합니다. 실제 회사에서 서비스 목적으로 AI를 개발하는 일에 대해 상세히 알아볼게요.
이미 많은 QA 조직에서 시행하고 있는 것처럼 29CM QA팀도 앱 테스트 자동화와 API 테스트 자동화가 실행되고 있습니다. API 테스트 자동화의 경우 API 자체의 수정이 그리 빈번하지 않은데요. 신뢰성에 문제가 발생할 수 있는 부분은 바로 앱 테스트 자동화입니다. 신규 개발 기능이 추가되거나, 기존 기능이 업데이트되는 등 변동과 함께, A/B 테스트로 인한 UI 차이도 계정마다 발생할 수 있습니다. 이로 인해 테스트 자동화 수행 시 테스트 결과가 Fail인 경우가 자주 발생하게 되었고, 결과적으로 테스트 자동화 수행 결과의 신뢰성이 떨어지게 된 것이죠.
클릭 수 줄이기는 자칫 잘못하면 큰 문제를 일으킬 수 있습니다. ‘간결함’에 집중한 나머지 기본 기능조차 찾기 힘들게 만들어진 앱도 있죠. 마치 눈을 가리고 루빅스 큐브를 풀려고 하는 느낌이랄까요. 이처럼 모든 작업을 단 한 번의 클릭(또는 제로 클릭)으로 줄이려고 하면 확장성이 떨어집니다. 그러다 최종 상태는 결국 모든 콘텐츠를 하나의 페이지에 다 담고, 각각의 액션에 대한 버튼이 따로 달려 있는 이상한 상황이 되는 겁니다. 그래서 좋은 UX는 단순히 클릭 수를 줄이는 데 그치지 않고, 그 이상의 목표를 가지고 있어야 합니다.
이제 WinForm을 다루는 개발자들은 무언가 새로운 것을 개발하는 업무는 거의 없는 상황에 놓였다. 그보다 묵을 대로 묵은 옛 선배들의 레거시 코드를 리팩토링하거나 이를 참고해 기능을 확장하는 경우가 많다. 일반적으로 개발 분야에서 리팩토링이란 “결과의 변경 없이 코드의 구조를 재조정함”을 의미한다. 다만 WinForm에는 GUI 디자이너, Win32 컨트롤, Form 등 독자적인 클래스 라이브러리가 있으므로 이와 같은 환경에 적용할 리팩토링 방법을 이해해야 한다. 스마트팩토리 분야에서 가장 많이 쓰이는 .NET WinForm의 리팩토링 방법을 다뤄 보겠다. 예제와 함께 작가가 스마트팩토리 분야에서 직접 WinForm 개발을 해오면서 중요하다고 생각한 몇 가지 전략을 소개하고자 한다.
이력서 멘토링을 인연으로 저와 멘토/멘티 관계를 맺은 유남주 님은 주니어 백엔드 개발자입니다. 어느 날 커피챗을 신청한 유남주 님이 다짜고짜 게릴라 인터뷰를 해도 되겠냐고 묻습니다. 인터뷰 받는 사람에게 주제를 알리지 않고 즉석에서 날 것 그대로 대답을 받기 위한 방식이라고 하는데, 왜 그런 인터뷰를 하는 걸까요? 별로 내키지 않아 하는 저를 유남주 님이 설득합니다. ‘스타트업 대표로서 비용을 절감하기 위한 엔지니어링적 시도’를 주제로 이야기 나누고 싶었다고 하네요. 인터뷰 방식은 긴장되지만, 주제가 흥미로웠습니다. 어디 한 번 이야기 나눠볼까요?
AI와의 커뮤니케이션이란, AI로부터 원하는 답변을 얻기 위해 프롬프트를 체계적으로 잘 작성하는 것부터 시작한다. 하지만 “무엇을 도와드릴까요?”라고 묻고는 명령만을 기다리는 빈 대화창을 보고 있으면 어떤 말로 시작할지 쉽사리 떠오르지 않는다. 정확하게 말하면 ‘어떤 방식으로 질문을 던져야 의도한 대로 답변이 나올지’ 예측하기가 어렵다. 실제로 프롬프트를 잘 작성하는 작업은 AI 도구를 제대로 활용하기 위해 가장 중요한 일이다. AI로부터 원하는 값을 얻기 위해 프롬프트를 체계적으로 작성하는 일, 이를 ‘프롬프트 엔지니어링’이라고 부른다. 이번 글에서는 UX 디자인 분야에 초점을 맞춰 프롬프트 엔지니어링 방법에 대해서 정리해 보았다.
얼마 전 와이콤비네이터에 참가한 한 스타트업이 실리콘밸리 개발자 및 오픈소스 커뮤니티를 발칵 뒤집어놓는 사태가 벌어졌습니다. ‘오픈소스 AI 코드 에디터’를 내세운 스타트업 PearAI가 바로 그 주인공입니다. PearAI의 창업자 듀크 팬 (Duke Pan)은 오픈소스의 철학을 자신들의 제품뿐 아니라, 제품 개발 과정 전반에 적용하겠다며 관련 유튜브를 함께 공개했습니다. 여기에서 당당하게 자신들의 AI 코딩 에디터가 VSCode와 Continue.dev의 ‘클론’이라고 공개적으로 밝히기도 했습니다. 문제는 Pear AI가 오픈소스인 원 프로젝트에 Pear Enterprise License라는 자체 폐쇄 라이선스를 붙인 것이 알려지면서 시작되었습니다.