나는 예전부터 피드백이 고팠다. 특히 나를 성장시킬 수 있는 양질의 피드백에 큰 갈증이 있었다. 첫 회사에서 CTO님께 종종 여쭤봤던 것 같다. 제가 뭘 더 하면 성장할 수 있을까요? 어떤 점을 채워나가야 할까요? CTO님은 무리하지 말고, 페이스 잃지 말고, 성장에 대한 욕구를 변치 않게 지금처럼만 하면 된다고 말했다. 지금처럼만 해서 될까요? 그리고 성장에 대한 욕구 변할것 같지 않은데... 사람은 생각보다 금방 변하더라구요. 씁쓸하게 말씀하시던 CTO님의 그 말이 오래도록 잊혀지지 않는다. 지금 생각해보면 그 말을 듣고 오기가 생겼던 것 같다. 남들은 다 변하더라도 나는 변하지 말아야지. 늘 치열하게 노력해야지. 진짜 잘해져야지. 주말 내내 놀지는 말아야지. 최소한 하루는 뭐라도 의미있는 일을 해야..

정말로 내가 하고 싶은게 무엇일까? 돈을 많이 버는 것? 얼마가 내가 만족할만한 많은 돈인가? 말 그대로 나는 무엇을 하고 살고 싶은지, 앞으로 5년 후, 10년 후에 어떤 일을 하고 싶은지에 대한 고민이 많다. 학창 시절에는 성인이 되고 직장인이 되면 진로고민(?)은 더 이상 하지 않을 줄 알았는데, 나름 획일화된 평가 시스템과 방향성이 제시되던 학창 시절과는 다르게 지금은 어떤 길이 후회가 적은 길일지에 대해 예측하기가 더욱 어렵다. 인생에 있어서 좋은 기회라는 것은 내 선택과 노력으로 어느정도 이끌어낼 수 있는 것이라고 생각하면서도, 찾아온 그것이 기회인지 아닌지를 판단하는 것이 너무나도 어렵다. 정말 좋은 기회인지 아닌지 판단하기 어려우면 기회라고 볼 수 없는게 아닌가? 싶은 생각도 들고...? ..

연 초에 회고를 6시간 동안 쓰다가 날려먹은 이후... 회고를 다시 쓸 엄두가 나지 않아 하염없이 미루고 있었다. 문득 이러다가 2년치 회고를 쓰겠다는 생각이 들어 빠르게 압축본으로 적어보려고 한다. 상반기 재작년 말에 이직을 한 후, 작년 상반기에는 새로운 조직에 적응하며 배우는 게 참 많았다. 개발팀의 학습 문화나 코드 리뷰 문화에서 얻은 것들을 체화하고, 그 과정에서 사용하지 않았던 근육을 사용하는 듯한 고통과 짜릿함을 동시에 느꼈던 시기였다. 테스트 코드 React 유닛테스트 코드 작성을 시작하면서 테스트란 무엇이고 왜 해야 하는지, 그리고 유지보수 가능한 테스트 코드 작성을 위해 무엇을 고려해야 하는지에 대한 고민과 인사이트를 많이 얻은 시기이다. 역설적으로 테스트 코드를 작성하다가 잘못된 컴포..

하루하루 AI관련 생태계의 확장과 새로운 기술에 대한 뉴스가 쏟아진다. 따라가기가 벅차다. 아니, 사실 못 따라간다... 사내 콘텐츠를 바탕으로 한 챗봇을 만들어 보려고 주말 동안 PoC를 했다. 스프린트에 정식으로 반영되어 이번 스프린트부터 타 스쿼드에서 시범적으로 작업에 들어간다. 콘텐츠 텍스트를 임베딩해서 vector store에 갱신하고, 유저 쿼리시 콘텍스트를 함께 제공하는 방식이다. 유저에게 꼭 필요한 정보들이 제대로 전달되지 않는 이슈가 있던 스쿼드에 먼저 도입된다. 할 수 있는게 너무 많아서 질식할 것 같다. 하나씩 꾸준히 놓치지 않고 따라가야지.... 너무 격변의 시기다

2023년에 들어서며 업무 방식의 큰 변화가 있었다. 다름 아닌 재택일 수가 현행 2일(화, 목)에서 4일(월요일만 출근)로 바뀐 것인데, 1분기 실험적으로 프로덕트 팀에 적용해 보고 유지 혹은 철회, 확대 등을 결정하게 되는 것 같다. 이러한 변화가 쉽게 이뤄지지는 않았다. 프로덕트 팀에서의 꾸준한 어필이 있었고(재택시 업무 효율 향상과 몰입에 도움이 된다는 점) 이직을 하거나 퇴사를 하신 분들 중에서도 근무 환경에 대한 불만이 어느정도 있었기 때문이다. 최근 카카오를 필두로 전사 재택이던 기업들이 재택 기조를 철회하는 등 변화의 바람이 불고 있는데, 우리 회사는 왜 재택근무 일수를 늘린 것일까? 팀원들이 건의한 부분이 적지 않겠지만, 근본적으로는 '몰입'이라는 키워드에 집중했기 때문이다. 나만 하더라..

질문과 답변을 번역기로 돌려서 어색한 부분이 다소 존재합니다 Q: 유지보수 가능한 코드란? A: 유지 관리 가능한 코드는 이해하고 수정하기 쉬운 코드입니다. 여기에는 일반적으로 깨끗하고 잘 문서화된 모듈식 코드 작성이 포함됩니다. 유지 관리 가능한 코드는 논리적 방식으로 구성되어야 하며 표준화된 코딩 규칙을 사용해야 합니다. 또한 새로운 버그를 도입하거나 기존 기능을 중단하지 않고 쉽게 업데이트하고 확장할 수 있는 방식으로 설계해야 합니다. 유지 관리 가능한 코드의 궁극적인 목표는 다른 개발자(또는 원래 개발자)가 시간이 지남에 따라 코드 베이스를 쉽게 수정하고 업데이트할 수 있도록 하는 것입니다. Q: 개발자의 관점에서 보다 실용적이고 유지 관리 가능한 코드의 예를 들어 주시겠습니까? A: 물론입니다...