AI는 실력을 대신해주지 않고, 드러낸다.

어딜 가나 AI 에이전트에 대한 이야기를 듣게 된다.사람 하나를 더 고용한 것처럼, 유능한 주니어 개발자를 옆에 앉혀 둔 것처럼 말한다. 그 말이 완전히 틀렸다고 하기도 어렵다. 분명히 빠르고, 생각보다 많은 일을 해내고 있다.AI 에이전트를 본격적으로 사용한 지도 벌써 수개월이 흘렀다. 유튜브 요약기 구조를 따라 만들어보는 것에서 시작해,AI 기반 서비스들이 제공하는 가치를 일부 직접 구현해보기도 했다.최근에는 tauri를 활용해 데스크톱에서 겪는 작은 불편을 해소하는 도구를 직접 만들어 사용하고 있다. 몇 번의 경험이 쌓일수록, 묘한 감정이 든다.누구나 쉽게 원하는 제품을 뚝딱 만들어 낼 수 있는 시대다. 이미 눈앞에 와있다. 그렇다면, 경쟁력은 어디서 오는가. 누구나 AI를 통해 빠르게 만들어낼 수..

성장이라는 것을 오랜 시간 동안 오해했던 것 같다.더 많이 알고, 더 많이 쌓는 일이 곧 성장이라고 믿었다. 하지만 시간이 지나며 성장은 덜어내고 정리하는 능력에 가깝다는 것을 느낀다.무엇을 더할지가 아니라 무엇을 비워낼지, 무엇을 먼저 둘지, 무엇을 과감히 보내줄지가 성장을 가른다.무상 (無常)모든 것은 계속 변화하며, 고정된 상태로 머물지 않는다는 불교의 근본 교리세상은 끊임없이 바뀐다.관계도, 요구도, 우리가 일하는 환경도 끊임없이 흐른다. 모든 것은 서로 기대어있고, 혼자서는 완성되지 않는다.어느 한쪽으로 기울어진 극단은 쉽게 무너지기 마련이다. 일하는 태도 역시 흐름을 전제로 만들어야 한다.오면 만나고, 가면 헤어지고, 말 걸면 대답하면 된다.제품도 팀도 그렇다.중요한 것은 “붙잡기”보다 “흘려..

애초에 어떻게 설계했어야 했을까?복잡한 정책들이 얽혀있는 제품 관련 논의 중, 동료로부터 이런 질문이 나왔다.아무도 답을 모른다. 정답이 없는 질문이다.이렇게 제품 기능이 발전될 줄 누구도 몰랐고, 설계가 잘못되었다는 사실은 뒤늦게 천천히 찾아온다.현재 상태를 잘못된 설계라 판단하고, 새로운 설계로 바꾼다 하더라도 언젠가 또다시 “애초에 어떻게 설계했어야 했을까?”라며 말하고 있을지 모른다.잘못된 설계는 단순히 실패가 아니다. 과정에서 우리는 어떤 선택이 문제를 일으키는지 몸소 겪었고, 언젠가 비슷한 상황에서 이 방향으로 가게 된 가면 고려해야 할 것들과, 안 된다는 확실한 근거를 얻게 된다.만약 잘못된 설계를 한 번도 경험하지 않았다면,더 나은 구조에 대한 고민조차 할 수 없었을 것이다.실패는 없다...

드라이기를 하나 사는 데도 우리는 생각보다 많은 과정을 거친다.“드라이기가 필요해”라는 단순한 목적에서 시작해, “온라인에서 살까? 오프라인에서 살까?”, “쿠팡에서 찾아볼까?”, “어떤 브랜드가 좋지?”, “이 제품은 평이 괜찮네?”, “근데 가격은 좀…” 수많은 선택지를 탐색하고, 비교하고, 고민하다 결국 하나를 선택한다.이런 사고의 흐름은 단순히 소비에서 끝나지 않는다.우리의 사고는 대부분 이런 구조를 따른다.요구사항(목적): 어떤 필요나 문제 인식사고: 다양한 가능성 탐색과 브레인스토밍고려: 조건에 따라 비교와 판단결정: 최종 선택과거에는 이 모든 과정을 스스로 처리했지만, 이제는 AI가 그 일부를 도와준다. 예를 들어 “드라이기 추천해 줘”라고 말하면, AI는 브랜드, 성능, 가격 등 다양한 정..

사용자 중심 설계는 제품의 성공을 위해 반드시 필요하다. 하지만 때로는 사용자를 위한다는 마음이 오히려 제품을 망치는 결과를 초래하기도 한다.디자이너의 지나친 우려는 오히려 사용성을 떨어뜨리기도 하고, 개발과정에 복잡성을 추가하기도 한다.한마디로 "과잉친절"이다. 보다 효과적인 접근방법은 없을까?테슬러의 법칙과 복잡성의 본질사용자 경험(UX) 분야에는 유명한 법칙이 하나 있다. 바로 테슬러의 법칙(Tesler’s Law)이다.모든 시스템은 일정 수준 이상의 복잡성을 줄일 수 없으며, 줄인 복잡성은 어딘가로 이동될 뿐이다.제품 설계 과정에서 피할 수 없는 복잡성은 반드시 존재하며, 디자이너가 간소화하지 않은 복잡성은 고스란히 사용자의 몫이 된다는 것을 의미한다. 과잉친절은 복잡성을 제품에서 사용자에게로 떠..

AI를 실제 업무에서 활용하며 왠지모를 불안함을 느끼신 적이 있나요. AI에 기대는 것 같아서 불안해요.AI가 너무 잘하니까.., 내가 설 자리가 없어지는 느낌이에요.AI 자주 활용하다보니, 내 사고력이 퇴화되는 느낌이에요.좋은 질문을 하며, 적절히 활용하고 “나”의 판단으로 완성하는 것AI를 함께 일하는 동료라고 생각하면 조금 달라집니다.이것이 진짜 “AI 활용 능력”입니다. 지난 주말, 많은 시간을 Cursor와 Copilot이 지원하는 여러 모델들을 활용해 코드를 작성해보고, ChatGPT의 모델들과 대화하고 흐름을 분석하는 실험에 투자했습니다.이 과정을 통해, 프롬프트의 구조, 설계에 따라 AI의 반응이 완전하게 달라진다는 걸 체감합니다.'AI 아직 멀었네' 라고 생각했던 것이 파일럿의 문제였다는..

무언가를 만들어 나간다는 것은 단순한 창조 행위가 아니다.오히려 기존의 것들을 깊이 이해하고, 필요에 따라 조합하며, 점진적으로 발전시키는 과정에 가깝다. 메이커에게는 두 가지 상반된 사고방식이 필요하다.하나는 '해석'하는 능력이다. 이미 존재하는 것을 분석하고 의미를 파악하는 것.다른 하나는 '추론'하는 능력이다. 보이지 않는 것까지 예측하고 새로운 가능성을 탐색하는 것. 이 두 가지 사고방식이 어떻게 작용하는지, 영화 식스 센스(The Sixth Sense, 1999)를 통해 살펴보자.결말을 알고 사건을 해석하는 것 - 해석의 관점식스 센스를 처음 본 사람이라면, 영화의 결말에서 큰 충격을 받았을 것이다."말콤 박사는 처음부터 유령이었다!" 처음에는 눈치채지 못했던 사실이 밝혀지는 순간, 우리는 영화..

동료와의 1:1 미팅에서 예상치 못한 인정을 받았다.원래도 그랬지만, 최근 정책을 꼼꼼히 확인하고 리포트하시는 모습이 인상적이었습니다. 세심한 일처리로 내가 인정하고 있던 동료에게 같은 인정을 받으니 감회가 새로웠다.내가 어떻게 행동했는지, 그리고 어떤 사건이 나에게 변화를 가져왔는지 대화를 나누었다. 미팅이 끝난 후에도 여운이 오래 남았던 터라, 글을 작성하는 이 시점은 몇 개월의 시간이 지난 후임에도, 그때의 기억이 생생하다.1년, 2년 그리고 3년차에 접어들며 흐려졌던 나의 사고회로가 다시금 정리되는 느낌이었다. 입사한 지 얼마 되지 않았던 때가 떠오른다.제품을 바라보는 데 있어 다소 이상한 사고방식이 필요하다는 것을 깨달은 지 얼마 되지 않은 시점이었다. 이 글을 남기는 이유는 하나다.미래의 내가..

useRef는 언제 사용하나요?DOM 조작 및 접근: 특정 DOM 요소에 접근하거나 조작할 때 사용값의 변경 추적: 값이 변경되더라도 리렌더링되지 않는다는 특징을 활용, 값이 유지할 때 사용const ref = React.useRef(null);{children}; useRef를 통해 렌더링 이후 해당 DOM 노드를 참조하고, 컴포넌트가 언마운트될 때 다시 null로 설정됩니다.렌더링 이후 특정 DOM 요소에 접근하기: useEffect와 callback refuseEffect를 사용한 경우useEffect를 통해 렌더링 이후 특정 DOM 요소에 접근할 수 있습니다.const ref = React.useRef(null);React.useEffect(() => { if (ref.current) { ..

우리는 모두가 설계자이자 이해당사자입니다. 업무와 일상에서 끊임없이 문제를 해결하고 결정을 내리는 과정 속에서 우리는 설계자의 역할을 맡기도 하고, 때로는 다른 사람의 결정에 영향을 받는 이해당사자가 되기도 합니다. 설계자는 복잡한 문제를 풀어내며 더 나은 솔루션을 찾기 위해 노력하고, 이해당사자는 그 솔루션이 자신의 상황에 어떻게 영향을 미칠지 고민합니다. 하지만 이 둘의 경계는 생각보다 명확하지 않습니다. 설계자의 결정은 이해당사자에게 직간접적으로 영향을 미치고, 이해당사자의 피드백은 설계자의 다음 결정을 좌우합니다. 결국, 설계자와 이해당사자는 서로의 역할을 넘나들며 상호작용하고, 이러한 과정 속에서 갈등과 협력, 그리고 새로운 기회를 만들어 갑니다. 따라서 설계자와 이해당사자가 서로의 입장에서 공..

TypeScript의 꽃🌷이라 할 수 있는 타입추론(Type Inference)과 Generic Type의 부분 타입추론 문제에 대해 알아봅니다. 이 주제에 대해 관심이 생긴다면 꼭 끝까지 파헤쳐 개념을 이해하시길 바랍니다. 이 글은 타입스크립트를 활용해 보았으며, Generic Type에 대한 기본적인 이해가 있음을 바탕으로 합니다. TL;DR TypeScript Generic은 완벽하지 않습니다. 조금 더 자세히 말해보자면 Generic의 부분적인 추론은 완벽하지 않습니다. TypeScript는 모든 Generic에 대해서 추론해 낼 수 있지만, 부분적인 추론에 대해서는 지원하지 않습니다. (적어도 현재까지는) 부분 추론 타입이 제한되는 상황에서 Generic Function에 대해 정상적인 추론을 ..

개발과 비개발의 충돌: 논리와 현실의 간극우리가 해결해야 할 문제는 종종 논리적 가능성과 현실적 가능성의 중간지대에 놓여 있습니다. 특히 개발직군과 비개발직군 사이에서 더 극명하게 드러나곤 합니다. 개발직군은 제품의 안정성과 신뢰성을 유지하기 위해 엣지 케이스까지 고려하며 논리적 결함을 허용하지 않으려는 경향이 있습니다. 모든 가능한 상황을 예측하고 대비해야 한다는 압박 속에서, 개발자들은 논리적 완결성에 집중합니다. 반면, 비개발 직군은 현실적인 가능성, 즉 시장의 요구와 고객의 실제 사용 패턴과 상황에 더 큰 무게를 둡니다. 그들에게는 제품이 사용될 현실적인 환경과 고객의 경험이 더 중요한 요소로 작용합니다. 이런 관점 차이로 종종 개발직군이 중요시하는 논리적 접근을 비개발직군에게는 지나치게 복잡하거..

기존 코드가 복잡하고 이해하기 어려울수록(코드를 만드는 데 더 많은 투자가 이루어질수록) 코드를 유지해야 하는 압박감을 더 많이 느낀다. 여기서 매몰비용의 오류가 발생한다. 매몰비용의 오류? 미래에 발생할 한계 편익과 한계 비용을 비교하여 의사결정을 해야 함에도 불구하고 사람들이 과거에 지출된 매몰 비용을 고려함으로써 비합리적으로 선택하는 현상 성급한 추상화를 피하라 공유하는 코드를 통해 매개변수를 전달하고 조건부 경로를 추가하고 있다면 이미 추상화가 잘못된 것이다. 추상화가 잘못된 것으로 판단된다면 가장 좋은 전략은 다시 중복코드를 생산해 무엇이 옳은지 보는 것. 즉, 잘못된 추상화에 대처할 때 가장 빠른 방법은 되돌아가는 것이다. 이것은 후퇴가 아니라 더 나은 방향으로 나아가는 길이다. 중복된 부분을..

shadcn이 얼마전 vercel팀에 Design Engineer로 합류했다는 소식이 들려왔습니다. 앞으로도 오픈 소스 커뮤니티를 위한 커스터마이징 가능한 UI 컴포넌트를 계속 만들어낼 것이라고 하며, 근시일 내 놀라운 무언가를 출시할 것만 같습니다. 현재 회사에서 활용중인 antd의 커스터마이징 어려움을 느낀 직후 이 프로젝트를 보고(당시 이 프로젝트는 완전 초기) Design System을 구축하는데 있어서 괜찮은 선택이지 않을까 생각했었는데, 발전되는 모습을 지켜보고 있자니 그때보다는 조금 더 기울어진 것 같습니다. 역사와 함께 알아보는 흐름 shadcn/ui는 눈에 띄지 않는 이름에도 지난 몇 달 동안 인기를 끌었습니다. 주요 이유로는 스스로를 라이브러리라고 부르기를 거부하기 때문인데요, 모든 C..

interface를 써야한다. type을 써도 괜찮다. 이에 관한 의견 차이가 약간 있었고, 이에 타입 선언 규칙을 정리했다. 그래서 무엇을 쓰는게 좋은건가? 나는 사실 Declaration Merging이 필요한 경우를 제외하곤 Type alias만을 사용하는 쪽이긴 한데 깊게 들어가서 차이를 비교해보니, interface를 적절히 사용함으로써 개념적인 정리와 이해에 대한 장점이 있었고 (프로젝트마다 다르겠지만)성능적인 이점도 있는 것을 알게 되었다. 결론은.. "객체" 에 대해서 interface를 선호하고, Inheritance 관련한 부분 이외엔 type을 사용하는 쪽으로 정리했다. 😄 이 글은 그 정리에 대한 결과이다. Primitive types 💡 Primitive types을 사용할 때 t..

올해 6월 중순 새로이 시작한 사이드 프로젝트 팀원들과 서비스 오픈을 앞두고 1박 2일간의 나들이를 다녀왔다. (처음 계획을 전달받았을 때 서비스 오픈을 앞두고 1박 2일간의 해커톤인 줄 알고 굉장한 기대를 했다...) 결론부터 말하자면 오랜만에 MT와 같은 느낌으로 바람도 쐬고, 맛있는것도 먹으며, 좋은 시간을 보내며 리프레시할 수 있었다. 그리고 같은 프론트엔드 개발자 분과의 대화를 통해 다시 무언가를 깨닫게 된 의미 있는 시간이었다. 팀원분은 나와 마찬가지로 디자이너에서 전직한 1년차 프론트엔드 개발자이며, 현시점에서 각 분야의 일한 기간이 나와는 정확히 반대인 케이스다. 지난밤, 프로젝트 진행 간 어려운 부분이 있으시다며 다음날 카페에서 라이브 코딩으로 알려주실 수 있는지 물어보셨다. 거절할 이유..

Next.js의 개발 서버는 기본적으로 3000 포트에서 실행되도록 설정되어 있습니다. 개발 환경에 따라 다른 포트에서 개발 서버를 실행해야 경우가 종종 생기는데 이를 변경할 수 있는 방법을 알아봅시다. 1. 직접 변경하기 // package.json { ... "scripts": { "dev": "next dev -p 3005", "build": "next build", "start": "next start" } ... } -p 옵션을 통해 뒤에 입력된 포트로 개발 서버가 실행됩니다. 2. 환경변수 사용하기 // package.json { ... "scripts": { "dev": "next dev -p ${PORT-3000}", "build": "next build", "start": "next st..

개발자로서 Git은 매우 중요한 부분입니다. Git과 상호작용 하지 않고 하루를 보낼 수는 없습니다. 일반적으로 터미널에서 Git을 실행하거나 Sourcetree와 같은 GUI도구를 사용합니다. 우리는 Git의 명령어를 기억하고, 작성하는 것이 어렵고 소모적인 것을 알고 있습니다. GUI툴을 사용한다면 Git 명령어를 외울 필요가 없어 정말 쉽게 사용할 수 있습니다. 직관적으로 보이고 또 강력한 부가기능들도 포함되어 있습니다. 하지만 터미널에서만 Git을 실행하는 것을 좋아하는 fan이 분명 존재합니다. 터미널 fan을 위한 효율적인 어떤 방법이 없을까요? 우리는 Git Alias를 설정해 Git 명령어를 별칭으로 저장해 Git을 좀 더 쉽고 빠르게 사용할 수 있습니다. 그럼 Git Alias는 어떻게 ..

개발자로서 업무를 진행하다 보면 자연스럽게 markdown을 접하고 사용하게 됩니다. 마크다운은 텍스트 기반의 경량 마크업 언어로 쉽고 간단하게 서식이 있는 문서들을 작성하는데 용이합니다. README.md는 물론 issue template, pull request template를 만들어 사용하기도 하고 어떤 분들은 TIL과 스터디 자료를 정리해 개인 리포지토리에 저장하기도 합니다. 저 또한 마찬가지로 클린코드 스터디를 진행하며 md파일로 정리했던 섹션이 있었습니다. 저는 마크다운으로 작성하며 내용이 많아지니 미리 보기에 대한 니즈가 있었습니다. VS Code 내에서 관련 Extension이 있는지 찾아보고 사용해보니 그 외의 기능들도 경험이 좋아 추천하고자 글을 작성합니다. Markdown All i..

github의 pull request는 draft 상태로 올릴 수 있는 기능이 존재합니다. * private 리포지토리는 유료 플랜이 필요 Draft 상태의 PR은 작업중인 상태로 Merge를 막을 수 있습니다. 언제, 어떻게 사용할 수 있을까요? 현재 회사에서는 Draft PR을 다음과 같은 규칙을 만들어 활용하고 있습니다. 1. topic으로 다른 개발자와의 의견 조율 및 소통이 필요할 때 2. 변경사항이 많아 리뷰가 힘들어짐을 방지하기 위해 PR을 나누어 올릴 때 순차적으로 Merge하기 위해 즉, PR을 올리는 행위는 테스크가 완료되어 코드리뷰를 하고 Merge하기 위한 것으로 정리할 수 있었기에 git-action은 그 시점에서 필요한 것이고, Draft PR에서도 git-action이 동작하는..

프로젝트 진행 간 아래와 같은 문제가 발생한 경험이 있나요? 1. 같은 커밋에 위치했는데 A 개발자는 프로그램이 문제없이 동작하고, B 개발자는 프로그램이 에러가 발생한다. 2. 변경사항을 pull 받고 install 했더니 코드의 변경사항은 없는데 package-lock.json파일의 변경사항이 있다. 너무나 익숙하지만 어떤일을 하는 녀석인지 대부분 모르고 지나가는 package-lock.json에 대해서 내용을 정리해 글을 작성합니다. package.json 그리고 package-lock.json 기본적으로 package.json은 npm에 패키지를 배포하기 위해 반드시 필요한 "문서"입니다. 또한 프로젝트의 의존성 관리를 위한 명세라 할 수 있습니다. npm 버전 5 이상에서 npm install을..

여느날처럼 프로젝트를 둘러보며 둘러보며 코드를 구석구석 청소하고 있었다. 그러던 중 약 10개월 전 작성 된 코드중 정상적으로 동작하지 않는 코드를 발견했다. 해당 코드의 commit history가 남아있어 PR을 살피며 이부분은 명백히 프로그램이 개발자의 의도에 따라 동작하지 않는 버그로 판단을 내릴 수 있었다. 나는 당연하게도 본래 의도한 대로 동작할 수 있도록 코드를 정리하며 해당 버그를 수정했다. 오랜시간 보고되지 않고 숨어있던 버그를 해결한 것에 안도감과 뿌듯한 마음이 들었다. 그런데 버그를 수정한지 며칠 후 해당 부분이 제대로 동작하지 않는다는 리포트가 들어왔다. 여지껏 그렇게 동작하던 것이 프로그램의 버그였고 지금에서야 정상적으로 동작하는것이 맞다. 하지만 사용자 입장에서는 그간 사용해왔던..

개발직군에 대한 관심도가 날이 갈수록 증가하며 사내에서도 다른 분야의 직원들이 생기기 시작했다. 누군가는 취미로, 만들고 싶은 아이템을 실현하기 위한 도구로 또는 커리어의 전환을 위해 각자의 목적을 가지고 있었다. 개발팀 내에서는 이들을 위해 사내 개발 스터디 그룹을 만들고 지원하고자 하는 계획을 세웠다. 그 첫걸음으로, 회의를 통해 '개발자가 되고싶은 히치하이커를 위한 안내서'라는 큰 주제 아래에서 각자 준비해 발표하도록 했다. 나는 디자이너에서 전환한 비전공자 출신 프론트엔드 개발자다. 그 과정에서 힘든점도 있었고 누구보다 그 상황을 이해할 수 있을 거라 생각했다. 그렇기에 나와 같은 상황의 동료를 이끌어 줄 수도 있다는 생각에 기대와 설렘이 있었고 한편으로는 걱정이 되기도 했다. 발표를 준비하며 출..

진행 중인 프로젝트 내 비슷한 로직을 처리하는 Modal UI가 10개가량 존재하는 것을 발견했다. 자연스럽게 컴포넌트로 추출되었을 법 한데 무엇 때문인지 각각 존재하고 있었다. // 초기 컴포넌트의 형태 type Payload = { foo: string; bar: string; baz: string; }; type WithRequestComponentProps = {}; const WithRequestComponent = ({}: WithRequestComponentProps) => { const { register, handleSubmit } = useForm(); const onSubmit: SubmitHandler = (payload) => { // 서버로의 요청 }; return ( ); };..

이직 후 새로운 회사에서는 이전까지 프로젝트 일정을 핑계 삼아 제대로 하지 못한 Pull Request(PR)와 코드 리뷰 문화에 익숙해지기 시작할 때쯤 느꼈던 불편한 부분들과 이를 어떻게 개선하고자 하였는지에 대해 경험을 공유합니다. 어떤 문제가 발생했나? 제목에만 의존적인 PR 거의 대부분이 제목에만 의존적인 PR로 제목과 함께 변경된 코드들로만 내용을 Reviewer가 추측하고 있었고, 간혹 리뷰를 직접 말로 주고받고 하다보니 중복되는 Comment가 발생하기도 했다. 개발자는 코드로 말한다지만... 코드가 자신을 설명할 수 있다면 정말 좋겠지만, 문제영역과 깊숙하게 연관되어 있는 내용에 대해서는 코드만으로 설명이 어려울 때가 많았다. 오랜 기간 진행되어온 프로젝트로 각자 담당하고 있는 파트가 존재..

최근 가벼운 Next.js를 활용 한 프로젝트를 진행하며 사용자 인증 관리를 NextAuth.js를 통해 구현해보았다. Next.js 프로젝트에서 간편하게 인증관리를 할 방법이 없을까 고민을 하고 있던 차 NextAuth.js를 알게 되었고, 가벼운 프로젝트기에 부담 없이 적용해보았다. NextAuth에서 제공하는 많은 Provider 중에 Credentials를 이용하여 사용자 인증을 구현, 관리하도록 세팅했다. 실 적용하는데에는 크게 문제가 없었고, 배포 이후 클라이언트 측의 IE 환경에서의 문제가 발견되었다. 로그인 진행이 안 되어 관리자 페이지는 확인 못 하였으나... (생략) Problem 1. NextAuth는 수시로 /api/auth/session을 요청하며 수시로 로그인 상태인지를 확인하도..