젝트

Java 21의 가상 스레드 알아보기 - 프로덕트 개발 아티클 #6

2026-06-29T00:00:17Z

가상 스레드의 정식 도입으로,thread-per-request 모델은 다시 현실적인 선택지가 되었습니다. Java 서버 애플리케이션에서 동시성은 늘 비용의 문제였습니다. 코드 관점에서는 thread-per-request 모델이 가장 읽기 쉽고 디버깅하기도 좋지만, 런타임 관점에서는 플랫폼 스레드가 비쌌기 때문에 무한정 늘릴 수 없었습니다. 그래서 우리는

설득력 있는 디자인을 위한 원페이저 - 프로덕트 디자인 아티클 #6

2026-06-22T00:00:16Z

왜 이렇게 디자인 하셨나요 디자이너가 실무와 면접에서 가장 자주 듣는 질문이자, 동시에 가장 대답하기 까다로워하는 질문입니다. 수많은 포트폴리오 리뷰와 업무 방식에 대한 인사이트가 많이 공개된 현재에도, 여전히 많은 디자이너들이 이 질문에 "그냥 이렇게 하는 게 나을 것 같아서요" 혹은 "시각적으로 이게 더 괜찮아서요"라고 대답합니다. 디자인은 본질적으로

생산성은 올랐는데, 사고력도 남아 있나요 - 프로덕트 개발 아티클 #5

2026-06-14T17:49:11Z

AI 도구를 둘러싼 대표적인 낙관론 중 하나는 다음과 같은 생각입니다. 단순하고 지루한 생각은 기계가 하고,사람은 더 고차원적인 생각을 하면 됩니다. 분명 매력적인 주장입니다. 하지만 이 문장이 늘 그대로 성립하지는 않습니다. 사소하고 반복적인 작업을 줄였다고 해서, 그만큼 더 깊은 사고가 자동으로 생기지는 않습니다. 오히려 개발에서는 지루하고 반복적인

디자이너는 왜 완벽해야 하는가 - 프로덕트 디자인 아티클 #5

2026-06-14T17:41:41Z

완벽주의와 완료주의, 무엇을 지향해야 하는가 최근의 자기계발이나 개인 성장에 대한 지침을 살펴보면, 완벽주의에 매몰되기보다는 일단 완료를 목표로 하라는 완료주의(Completionism)를 권장하는 경우가 많습니다. 이건 겉보기에 완벽주의가 실행력을 갉아먹는 부정적인 요소처럼 보이기 때문이라고 생각해요. 이러한 조언의 실제 의도는 완벽하지 말라는 것이 아

SonarQube Cloud로 코드 정적 분석 도입하기 - 프로덕트 개발 아티클 #4

2026-06-14T17:40:46Z

보통, 코드 품질은 '좋은 리뷰어'가 담당하는 영역이었습니다. 시니어 혹은 사수가 PR을 보며 리스크가 있거나 기술적으로 개선이 가능한 부분을 짚어주는 방식으로 코드 품질 향상을 이뤄내는 방식이에요. 이 글을 읽는 현업 개발자 분들, 그리고 젝트에서 사이드 팀 프로젝트를 진행하는 4기 구성원분들도 상호 코드 리뷰를 진행하실 것으로 생각되는데요, 작업 스코프

DesignOps: 디자이너의 확장된 역할 - 프로덕트 디자인 아티클 #4

2026-06-14T17:39:41Z

디자이너의 확장된 역할과 병목 현상 현대의 프로덕트 디자이너는 단순히 그래픽 결과물을 생산하는 역할을 넘어섰습니다. 이제 디자이너는 제품과 사용자를 연결하는 매체의 작동 원리를 파악하고, 전체적인 경험의 구조를 설계하는 개발 조직의 중요한 축을 담당해야 합니다. 과장 조금 보태자면, 디자이너는 도메인 지식부터 시작해서 우리 프로덕트에 어떤 기술이 왜 사용

Javascript V8 엔진의 객체 관리 방식 - 프로덕트 개발 아티클 #3

2026-06-14T17:39:24Z

JavaScript는 메모리를 직접 관리하지 않아도 되는 언어입니다. 변수를 선언하면 알아서 메모리가 할당되고, 더 이상 쓰지 않으면 가비지 컬렉터가 알아서 회수해 갑니다. C나 C++처럼 malloc과 free를 신경 쓸 필요가 없죠. 그런데 이 편리함이 때로는 함정이 됩니다. 메모리를 신경 쓰지 않아도 된다는 건, 엔진이 내부적으로 어떻게 메모리를 쓰

State 프로퍼티와 Focus에 대해 깊게 생각하기 - 프로덕트 디자인 아티클 #3

2026-06-14T17:39:03Z

Focus 상태를 State로 표현해도 될까? 디자이너가 디자인 시스템을 구축하거나 컴포넌트를 설계하는 상황을 가정해볼게요. 어떤 컴포넌트가 상호작용이 가능하다고 했을 때, 상호작용 상태 구성을 위해 'state'라는 프로퍼티를 만드는 것이 보편적입니다. 이 프로퍼티의 값으로는 다음과 같이 나열하는 것이 대중적인 것 같아요: 프로퍼티명: state값: r

사이드 프로젝트, SW 엔지니어링 관점으로 접근하기 - 프로덕트 개발 아티클 #2

2026-06-14T17:38:38Z

포트폴리오에는 비즈니스적으로 문제를 해결한 경험을 쓰세요. 여러분들은 이런 조언을 많이 들어보셨을 거에요. 그런데 이 조언은 막막하게 느껴질 수 있습니다. 100명의 사용자도 모으기 어려운 사이드 프로젝트에서 대체 어떤 비즈니스 문제를 해결할 수 있을까요? 여기서 말하는 비즈니스적 문제 해결을 '매출', '사용자 수', '투자 유치' 같은 키워드로만 이해

우리 팀은 왜 자꾸 규칙을 다시 쓰게 될까 - 프로덕트 디자인 아티클 #2

2026-06-14T17:38:11Z

디자인 규칙을 새로 쓰는 한이 있더라도 UX 개선이 우선되어야 할까요? 어느 날, 함께 프로젝트를 진행하는 동료 디자이너 A씨와 다음과 같은 대화를 나누게 됐다면: A씨: 콜아웃에 사용된 본문 텍스트 색상 말인데요, 지금 정의된 컴포넌트와 디자인 시스템 내 규칙대로 사용하게 되면 페이지 내 시선 흐름이 자연스럽지 않아요.나: 동의합니다. 그런데 콜아웃이 공

GitHub Issue와 PR에서 드러나는 협업 능력 - 프로덕트 개발 아티클 #1

2026-06-14T17:37:52Z

개발자의 역량은 ‘코드 작성’이 전부가 아니다 보통 개발자를 평가할 때 가장 먼저 보는 것은 역시 코드입니다. 얼마나 깔끔하고, 얼마나 효율적인지가 개발자의 역량을 평가하는 중요한 요소입니다. 하지만 몇 번의 프로젝트를 겪어보면 “코드를 잘 짜는 사람”과 “일을 잘하는 사람”, 그리고 “함께 일하고 싶은 사람” 은 다르다는 것을 알 수 있습니다. 실무에서

제품을 만드는 제품 - 프로덕트 디자인 아티클 #1

2026-06-14T17:37:25Z

우리 팀의 개발은 왜 느릴까 분명 다들 열심히 하고 있는데, 생각보다 개발 진척이 느리거나 일정을 맞추기 힘들 때가 있죠? 그럴 때 보통 기술이나 인력에 관해 문제를 해결하려 하는 것이 대부분입니다. 더 적절한 프레임워크를 선택하거나 편리한 라이브러리를 끌어 오는 경우도 있고, 개발자를 더 충원한다거나 일정을 더 촘촘하게 관리하는 것들 말이에요. 하지만