개요 AI 시대가 오면 개발자는 무엇을 더 갈고닦아야 할까. 예전 같으면 새로운 프레임워크, 언어, 아키텍처, 성능 최적화 같은 것들을 먼저 떠올렸을 것이다. 물론 지금도 중요하다. 개발 기본기가 필요 없어진다는 말은 절대 아니다. 그런데 AI를 실제 개발에 깊게 써볼수록, 앞으로 더 중요해질 능력은 오히려 소프트스킬에 가깝다는 생각이 든다. 표현력, 기획력, 커뮤니케이션 능력, 맥락을 정리하는 능력, 사람과 합의하는 능력. 이런 것들은 예전부터 중요했다. 하지만 개발 업계에서는 종종 부가 능력처럼 취급됐다. 개발을 잘하면 말이 조금 부족해도 넘어갔다. 커뮤니케이션이 거칠어도 결과물이 좋으면 어느 정도 용인됐다. 하지만 이제는 그게 점점 어려워질 것 같다. 왜냐하면 AI가 구현 비용을 낮추고 있기 때..

개요 AI가 개발을 정말 잘해주는 시대가 됐다. 요즘 AI로 개발을 해보면, 예전 같으면 꽤 오래 걸렸을 작업들이 금방 끝난다. 신규 기능 개발이나 기존 기능 수정 정도는 웬만하면 큰 문제 없이 해준다. 사이드프로젝트 규모에서는 더 체감이 크다. 내가 하고 있는 사이드프로젝트들은 규모가 커봐야 4만 줄에서 7만 줄 정도다. 이 정도 규모에서는 AI가 컨텍스트도 꽤 잘 따라오고, 구조도 생각보다 잘 잡아준다. 대규모 마이그레이션이나 검증이 빡세게 들어가는 작업이 아니라면, 유료 플랜 하나로 회사 업무와 사이드프로젝트를 병행하는 것도 가능하다. 그러면 이제 개발 지식은 별로 필요 없어졌을까? 나는 아직은 아니라고 생각한다. 현시점에서는 개발 지식이 여전히 필요하다. 그리고 AI가 더 똑똑해져도 한동안은 ..

개요 요즘 회사에 다니면서 사이드프로젝트를 꽤 많이 굴리고 있다. 1D1S, Rutsubo, Laiteu는 이미 출시해서 운영 중이고, HIARC-Platform은 예전에 했던 프로젝트를 전면 리팩터링하고 있다. 여기에 아직 출시하지 않은 앱도 2개 정도 있다. 이렇게 적어놓고 보니 나도 좀 이상하긴 하다. "아니 회사도 다니면서 이걸 왜 이렇게까지 하지?" ...라고 물으면, 사실 거창한 이유는 없다. 그냥 프로덕트 만드는 게 재밌다. 현재 신분상 겸업을 할 수 없어서 수익을 내고 있는 것도 아니고, 당장 큰돈이 되는 것도 아니다. 그런데도 계속 만들게 된다. 자기만족도 있고, 언젠가는 수익을 만들 수 있지 않을까 하는 기대도 있다. 하지만 제일 큰 이유는 내 머릿속에 있던 것이 실제로 굴러가는 ..

개요 프론트엔드 개발자라면 누구나 한 번쯤 이런 순간이 온다. 디자인 시스템이 없어서 매번 버튼 스타일을 복사-붙여넣기 하는 게 답답하거나, 레거시 코드가 섞인 컴포넌트 파일이 500줄을 넘어가는 걸 볼 때 참을 수 없는 충동을 느낀다. "이거 내가 싹 정리해서 공통 컴포넌트로 만들면 대박이겠는데?""지금 쓰고 있는 라이브러리 너무 구려. 요즘 뜨는 걸로 바꾸면 개발 속도 빨라질 텐데." 시작은 언제나 순수한 열정이다. 불편함을 해소하고, 코드를 우아하게 만들고 싶다는 선의다. 하지만 잠시 키보드에서 손을 떼고 냉정하게 생각해 보자. 그거, 정말 지금 우리 팀에 필요한 거 맞나? 혹시 나만의 기술적 만족감을 채우기 위한 욕심은 아닐까? 오늘은 현직 개발자들과의 대화 도중 나온 주제를 바탕으로, 주니..

개요 컴포넌트를 만들다 보면 필연적으로 간격을 어디에 줄 것인가에 대한 고민에 빠지게 된다. 예를 들어, 리스트에 들어갈 `UserCard`라는 컴포넌트를 만든다고 가정해보자. 리스트 아이템 사이에는 20px의 간격이 필요하다. 이때 가장 쉬운 방법은 `UserCard` 자체에 `margin-bottom: 20px`을 주는 것이다. "어차피 이 카드는 리스트에서만 쓰니까, 알아서 간격을 가지고 있으면 편하잖아?" 하지만 프로젝트가 커지고 `UserCard`를 다른 곳(가로 스크롤 뷰, 모달 내부, 그리드 레이아웃 등등)에서 재사용하려고 할 때, 내부에 심어둔 이 margin은 굉장히 거슬리는 무언가가 돼버린다. ▼ 나는 "자식 컴포넌트는 패딩이나 마진 같은 외부 간격에 대해 전혀 몰라야 한다"는 ..

개요 국제화(i18n)를 구현하다 보면 번역 파일을 어떻게 관리할 것인가?라는 질문을 마주하게 된다. 처음에는 하나의 거대한 JSON 파일에 모든 번역을 때려넣으면 될 것 같지만, 프로젝트가 조금만 커져도 수천 개의 키가 뒤엉키게 된다. 그래서 이번 글에서는 국제화 파일을 페이지별로 분할해서 관리하되, 빌드 시점에 자동으로 병합하는 방식을 소개하려고 한다. 단순히 이렇게 하면 된다고 결론부터 내리기보다, 왜 이런 접근이 필요했는지, 그리고 실제로 어떻게 구현했는지의 흐름을 따라가보자. 문제파일 분할의 필요성국제화 파일을 단일 파일로 관리하면 처음에는 간단해 보인다. en.json 하나, ko.json 하나, 끝. 더 필요하면 es.json 혹은 ja.json 정도. 하지만 프로젝트가 커지면서 문제가 ..

개요 프로그래밍을 하다 보면 반드시 한 번쯤은 "모델 검증 코드를 어디에 둘 것인가?"라는 질문을 마주하게 된다. 처음에는 대수롭지 않아 보이지만, 프로젝트 규모가 조금만 커져도 코드의 유지보수와 팀 내부의 합의에 직접적인 영향을 주는 논쟁거리로 떠오른다. 현업 개발을 시작한 지 얼마 되지 않았지만, 각종 프로젝트들을 경험해보며 여러 아키텍처 글과 실전 코드들을 뒤적이다가 "내가 정말 제대로 이해하고 있나?", "지금 선택이 과연 최선일까?"라는 의문을 반복해서 던지곤 한다. 그래서 이번 글에서는 모델 검증 코드를 모델 내부에 둘지, 아니면 외부의 별도 Validator로 뺄지를 결론부터 단순히 내려버리기보다, 흐름의 주권, 즉 책임이 어디에 머무르고 언제 이동하는가라는 관점에서 보려고 한다. 그전에...

개요이전에 Flutter글에서 async/ await 개념에 대해 공부하면서 아래의 글을 작성한 적이 있었다. ▼ [Flutter] 동기와 비동기 개론개요 동기와 비동기, 프로그래밍을 공부하다보면 항상 등장하는 개념이다. 중요한 개념이고 꼭 알아야한다고 하지만 이게 왜 중요한 개념인지 잘 이해하지 못하고 넘어간 적이 많다.▼ 하지만noguen.com 해당 글의 내용이 잘못된건 아니지만 (다시 읽어봤을 때는 아직까지는 잘못된 점을 못찾았다) 동기와 비동기를 다르게 보는 시각이 있다는 이야기가 있어서 이에 대해 정리하려고 한다. 제어 흐름으로 본 동기와 비동기동기와 비동기의 개념 동기는 Synchronous, 비동기는 Asynchronous로 한국어로 봤을 때는 약간 헷갈리는 면도 조금 있다. 동기라는 말..

개요 Flutter뿐만 아니라 프런트엔드 개발을 하다 보면 앱 내부에 이미지를 넣어야 할 때가 있다. 이런 상황에서 일반적으로 두 가지의 포맷을 사용하곤 하는데, 그 두 포맷이 svg와 png다. (jpeg는 투명도가 없기에 사용하지 않는다.) figma를 보고 작업을 하다보면 디자이너가 아이콘들을 svg 포맷으로 주곤 한다. 평소에는 별생각 없이 svg 파일을 받아 사용했는데 문득 의문이 들었다. 'svg를 주로 사용하는 이유가 뭐지?', 'png도 같은 역할을 하는데, 둘의 명확한 차이에 대해 나는 알고 있었나?'. 그래서 개발에서 둘의 차이에 대해 조금 더 깊게 알아보기로 했다. 우선은 간단하게 각각의 특징에 대해 알아보고 성능 상의 차이에 대해 알아보자. 각각의 특징SVG 포맷 SVG는 Sc..