visual-studio-code

6 개의 포스트

github

각 토큰에서 더 많은 것을 얻기: Copilot이 컨텍스트 처리와 모델 라우팅을 개선하는 방법 (새 탭에서 열림)

GitHub Copilot은 에이전트형 작업이 길어질수록 단순히 토큰을 줄이는 것이 아니라, 반복되는 컨텍스트와 도구 정의를 효율적으로 재사용하고 작업에 맞는 모델을 선택해야 한다고 설명합니다. 이를 위해 VS Code에서는 프롬프트 캐싱과 지연된 도구 로딩을 개선하고, Auto 기능은 작업 난이도와 실시간 모델 상태를 바탕으로 적절한 모델로 라우팅합니다. 목표는 품질을 유지하면서 불필요한 비용과 지연을 줄이는 것입니다. ## 프롬프트 캐싱과 지연된 도구 로딩 - 긴 Copilot 세션에는 지침, 저장소 컨텍스트, 대화 기록, 도구 목록, 작업 상태 등 반복적으로 전달되는 정보가 많습니다. - **프롬프트 캐싱**은 반복되는 프롬프트 접두부의 모델 상태를 재사용해 매 요청마다 같은 내용을 다시 계산하지 않도록 합니다. - **도구 검색(tool search)**은 모든 도구의 전체 스키마를 처음부터 컨텍스트에 포함하지 않고, 모델이 필요할 때 관련 도구 정의만 불러옵니다. - MCP 도구, 터미널, 파일 조작, 워크스페이스 검색 등 도구가 많아질수록 이 방식의 효과가 커집니다. - 사용 가능한 도구의 범위는 넓게 유지하면서도, 현재 작업과 무관한 도구 정의가 매 턴마다 차지하는 토큰 비용을 줄일 수 있습니다. ## 작업별 모델 자동 선택 - Auto는 “현재 작업에 어떤 모델이 가장 적합한가?”를 자동으로 판단합니다. - 빠른 설명, 특정 파일의 간단한 수정, 여러 파일에 걸친 복잡한 변경은 요구되는 추론 수준이 서로 다르므로 동일한 모델을 사용할 필요가 없습니다. - 평가 결과 모든 작업에서 항상 최고 성능을 내는 단일 모델은 없었습니다. - 효율적인 모델이 더 적은 비용으로 같은 결과를 내는 경우가 많지만, 복잡한 추론이나 디버깅에서는 강력한 모델이 더 유리합니다. - Auto는 필요할 때만 더 강한 모델로 전환하고, 단순한 작업에는 효율적인 모델을 사용해 품질과 비용 사이의 균형을 맞춥니다. ## Auto의 라우팅 기준 Auto는 모델의 현재 상태와 작업의 특성이라는 두 가지 신호를 함께 사용합니다. - **실시간 모델 상태** - 모델의 가용성, 사용률, 응답 속도, 오류율, 비용을 동적으로 추적합니다. - 성능이 좋은 모델이라도 현재 과부하 상태이거나 응답 오류가 많다면 최적의 선택이 아닐 수 있습니다. - 따라서 작업을 처리할 능력뿐 아니라 현재 안정적으로 응답할 수 있는지도 고려합니다. - **HyDRA 기반 작업 인식 라우팅** - HyDRA는 추론 깊이, 코드 복잡도, 디버깅 난이도, 도구 오케스트레이션 필요성 등을 분석합니다. - 먼저 해당 작업의 품질 기준을 충족할 수 있는 모델들을 선별한 뒤, 그중 가장 적합한 모델을 선택합니다. - 게시글의 평가에서는 HyDRA가 품질과 비용 절감 수준을 조정할 수 있음을 보여줍니다. - 한 운영 지점에서는 Sonnet보다 높은 성능을 내면서 12.9% 비용을 절감했고, 다른 운영 지점에서는 품질을 균형 있게 유지하며 72.5%를 절감했습니다. - SWE-bench 평가에서 보수적 설정은 70.8% 해결률로 OpenRouter Auto와 동률을 기록하면서 3.3배 높은 절감 효과를 보였습니다. ## 캐시를 고려한 모델 전환 - 매 턴마다 모델을 바꾸면 유연성은 높아지지만, 기존 프롬프트 캐시가 깨져 오히려 비용이 증가할 수 있습니다. - 같은 모델을 계속 사용하면 대화의 프롬프트 접두부를 여러 턴에 걸쳐 재사용할 수 있습니다. - Auto는 다음과 같은 **자연스러운 캐시 경계**에서 주로 모델을 다시 선택합니다. - 첫 번째 요청: 아직 재사용할 캐시가 없는 시점 - 컨텍스트 압축(compaction) 이후: 이전 대화를 요약하면서 프롬프트 접두부가 초기화된 시점 - 그 사이에는 선택된 모델을 유지해 캐시가 축적되도록 합니다. - 즉, 모델 라우팅 자체의 이득뿐 아니라 모델 전환으로 발생하는 캐시 손실까지 함께 계산합니다. ## 여러 언어를 지원하는 라우팅 - Copilot은 영어뿐 아니라 다양한 언어로 사용되므로 라우팅 모델도 다국어 환경에서 작동해야 합니다. - 라우팅 모델은 CJK, 유럽 언어권 등을 포함한 16개 언어군의 대화 데이터로 학습되었습니다. - 19개 언어에서 추출한 VS Code Chat 텔레메트리 평가에서 언어군별 라우팅 정확도는 영어 기준선과 4포인트 이내의 차이를 보였습니다. - 언어군 사이에 통계적으로 유의미한 품질 격차도 나타나지 않았습니다. Copilot의 효율성을 높이려면 모든 정보를 매번 다시 보내거나 모든 작업에 가장 큰 모델을 사용하는 대신, 반복 컨텍스트는 캐시하고 도구는 필요할 때 불러오며 작업 난이도에 맞는 모델을 선택하는 것이 효과적입니다. 특히 긴 에이전트 세션에서는 모델 전환으로 캐시가 손실되지 않도록 하는 전략이 비용과 응답 속도 모두에 중요합니다.

github

초보자를 위한 GitHub: VS Code에서 Git과 GitHub 시작하기 (새 탭에서 열림)

VS Code는 Git과 GitHub 기능을 통합해 편집기를 벗어나지 않고 저장소 초기화, 브랜치 관리, 변경 사항 검토, 커밋과 푸시를 수행하게 해준다. 이 글은 Git과 GitHub의 차이를 설명하고, VS Code에서 로컬 폴더를 Git 저장소로 만들고 변경 사항을 GitHub에 올리는 초보자용 흐름을 단계별로 안내한다. 이를 통해 도구 간 전환을 줄이고 개발 작업의 생산성을 높일 수 있다. ## Git, GitHub, VS Code의 관계 - **GitHub**는 코드 저장소를 호스팅하는 서비스다. - **Git**은 소스 코드의 변경 이력을 관리하는 프로그램이다. - Git은 명령줄뿐 아니라 VS Code 같은 편집기에서도 사용할 수 있다. - VS Code는 Git 기능을 내장하고 있어 GitHub와 연계된 버전 관리 작업을 편리하게 수행할 수 있다. - 실습을 위해 Git과 VS Code를 먼저 설치해야 한다. ## 폴더를 Git 저장소로 초기화 - VS Code에서 **Explorer → Open Folder**를 선택해 코드가 들어 있는 폴더를 연다. - 왼쪽의 **Source Control** 아이콘을 클릭한다. - **Initialize Repository**를 선택하면 해당 폴더에 로컬 Git 저장소가 생성된다. - 하단 왼쪽에서 현재 브랜치 이름을 확인할 수 있으며, 기본 브랜치는 보통 `main`이다. - Command Palette에서 **Git: Rename Branch**를 실행해 브랜치 이름을 변경할 수 있다. - macOS: `Shift-Command-P` - Windows/Linux: `Ctrl-Shift-P` ## 파일 추적과 스테이징 - 저장소를 초기화하면 기존 파일 옆에 `U` 표시가 나타난다. - `U`는 **Untracked**, 즉 아직 Git이 추적하지 않는 파일이라는 뜻이다. - 파일 옆의 `+` 버튼을 클릭하면 해당 파일이 스테이징된다. - **CHANGES** 옆의 `+` 버튼을 누르면 변경된 모든 파일을 한 번에 스테이징할 수 있다. - 스테이징된 파일은 `A`로 표시된다. - `A`는 파일이 추가되었지만 아직 커밋되거나 GitHub에 업로드되지는 않았다는 의미다. ## 커밋 생성 - Source Control 패널 상단의 입력란에 변경 내용을 설명하는 커밋 메시지를 작성한다. - 필요하면 Copilot 아이콘을 사용해 커밋 메시지를 생성할 수 있다. - **Commit** 버튼을 누르면 스테이징된 변경 사항이 로컬 Git 저장소에 기록된다. - 커밋은 변경 사항을 GitHub에 업로드하는 것과는 다르며, 이후 별도의 푸시 작업이 필요하다. ## 브랜치 생성과 전환 - 주요 기능을 개발할 때는 `main` 브랜치에서 직접 작업하기보다 별도 브랜치를 만드는 것이 권장된다. - Command Palette에서 **Git: Create Branch…**를 실행한다. - 예를 들어 `new-features` 같은 브랜치 이름을 입력한다. - VS Code는 새 브랜치를 생성한 뒤 자동으로 해당 브랜치로 전환한다. - 현재 브랜치는 화면 하단 왼쪽에서 확인할 수 있다. ## 코드 변경 사항 확인 VS Code의 편집기 여백인 **gutter**는 코드 변경 유형을 시각적으로 표시한다. - 초록색 선: 새로 추가된 코드 - 파란색 표시: 기존 코드가 수정된 부분 - 빨간색 화살표: 코드가 삭제된 부분 - 변경된 파일은 Source Control 패널의 **CHANGES** 아래에 표시된다. - 파일에 마우스를 올리면 다음 작업을 수행할 수 있다. - 파일 열기 - 변경 사항 폐기 - 변경 사항 스테이징 - CHANGES 영역에서도 여러 파일의 변경 사항을 한꺼번에 검토하거나 스테이징할 수 있다. ## diff로 변경 내용 비교 - Source Control 패널에서 파일 이름을 클릭하면 변경 전후를 나란히 비교하는 diff 화면이 열린다. - diff 화면에서는 어떤 코드가 추가·수정·삭제되었는지 확인할 수 있다. - 오른쪽 위의 `…` 메뉴에서 **Inline View**를 선택하면 변경 전후 내용을 하나의 화면에서 볼 수 있다. - Inline View에서는 diff 화면 안에서 직접 코드를 수정할 수도 있다. ## 실용적인 작업 흐름 - VS Code에서 폴더를 연다. - Git 저장소를 초기화한다. - 기능별 브랜치를 만든다. - 코드를 수정하고 Source Control에서 변경 사항을 검토한다. - 필요한 파일을 스테이징한다. - 의미 있는 커밋 메시지와 함께 커밋한다. - 이후 변경 사항을 GitHub에 반영하려면 푸시 작업을 수행한다. 이 글은 제공된 내용 기준으로 diff 확인 단계 이후에서 본문이 중단되어 있으며, GitHub 원격 저장소 연결과 실제 푸시 절차는 포함되어 있지 않다.

github

범용 접근성 에이전트 구축과 그 과정에서 얻은 교훈 (새 탭에서 열림)

GitHub는 개발자가 접근성 질문에 즉시 답을 얻고, 배포 전 단순하고 객관적인 접근성 문제를 자동 수정하도록 실험적인 범용 접근성 에이전트를 운영하고 있습니다. 이 에이전트는 3,535개의 풀 리퀘스트를 검토해 68%의 해결률을 기록했지만, 접근성을 자동으로 “해결”하는 만능 도구가 아니라 기존 엔지니어링 노력을 보완하는 역할로 설계되었습니다. 특히 조직이 축적한 구조화된 접근성 이슈와 수정 사례가 에이전트의 정확도와 실용성을 높이는 핵심 자산이 되었습니다. ## 접근성 에이전트의 목표와 성과 - GitHub Copilot CLI와 VS Code 통합 환경에서 접근성 관련 질문에 신뢰할 수 있는 답변을 제공합니다. - 프런트엔드 코드가 변경된 풀 리퀘스트를 자동으로 검사합니다. - 단순하고 판단 기준이 명확한 접근성 문제는 코드 제안 형태로 자동 수정할 수 있습니다. - 현재까지 3,535개의 풀 리퀘스트를 검토했으며, 68%의 해결률을 기록했습니다. - 가장 많이 발견된 문제는 다음과 같습니다. - 구조와 관계를 보조공학 기술이 명확히 이해하도록 표현하지 못한 문제 - 대화형 컨트롤의 이름이 불명확한 문제 - 중요한 상태 변화나 공지를 사용자에게 전달하지 못한 문제 - 이미지 등 비텍스트 콘텐츠에 텍스트 대안이 없는 문제 - 키보드 포커스 이동 순서가 논리적이지 않은 문제 예를 들어 시각적 배치와 DOM·스크린 리더 읽기 순서가 서로 다른 경우, 에이전트는 `row-reverse` 대신 DOM 요소 순서를 바꾸고 일반적인 `flex-direction: row`를 사용하라고 제안할 수 있습니다. ## 접근성을 바라보는 관점 - 사회적 장애 모델에 따르면 장애와 사용 장벽은 개인뿐 아니라 환경의 설계 방식에서도 발생합니다. - 디지털 서비스에서도 잘못 구성된 UI가 보조공학 사용자에게 장벽을 만들 수 있습니다. - 따라서 에이전트의 목표는 접근성을 독립적으로 완성하는 것이 아니라, 동료 개발자가 장벽을 더 빠르게 발견하고 제거하도록 돕는 것입니다. - 모든 상황을 자동으로 처리할 수 있는 “실버 불릿”으로 에이전트를 홍보하지 않았습니다. - 에이전트의 책임 범위를 현실적으로 정의한 덕분에 실험을 빠르게 시작하고 조직 내 동의를 얻을 수 있었습니다. ## 규제와 사전 투자 - 유럽 접근성법(EAA)이 시행되었고, 미국 장애인법(ADA) Title II도 2027년 4월부터 WCAG 2.1 AA 준수를 법적 완료 기준으로 삼을 예정입니다. - LLM 기반 에이전트는 접근성 트리를 읽고 이를 바탕으로 UI를 분석하거나 조작할 수 있습니다. - 조직이 아직 수동으로 접근성 문제를 식별하고 수정하는 체계를 마련하지 않았다면, 향후 에이전트를 구축할 때도 불리해집니다. - 자동화는 기존의 접근성 품질 관리 체계를 대체하는 것이 아니라, 이미 검증된 문제와 해결 방식을 활용해 확장하는 방식으로 효과를 냅니다. ## 구조화된 이슈 데이터의 가치 GitHub는 에이전트 도입 이전부터 접근성 문제를 일관되게 기록하고 검증하는 시스템을 운영했습니다. - 문제 신고용 구조화된 템플릿 - 재현 절차 - 심각도, 담당 서비스 영역, 적용 가능한 WCAG 성공 기준 등의 메타데이터 - 문제를 해결한 풀 리퀘스트와의 연결 - 수정 완료를 판단하는 명확한 수용 기준 - 모든 접근성 이슈를 하나의 저장소에 중앙화 이처럼 일관된 형식으로 축적된 이슈와 코드 변경 내역은 에이전트가 참고할 수 있는 고품질 학습·검색 자료가 되었습니다. LLM의 비결정적이고 유연한 매칭 능력도 비슷한 코드와 문구를 찾아내는 데에는 장점으로 작용했습니다. ## 일반적인 지침만으로는 부족한 이유 - 전문 영역에서 “접근성 모범 사례를 따르라”는 식의 짧고 추상적인 지침만으로는 충분하지 않습니다. - 주요 LLM은 접근성이 부족한 코드가 포함된 수십 년간의 자료로 학습되었기 때문에, 접근성 안티패턴을 생성하는 편향을 보일 수 있습니다. - 따라서 에이전트가 실제 조직의 코드 스타일과 문제 해결 관례를 반영한 구체적인 사례를 참고해야 합니다. - 수동으로 접근성 문제를 분류하고 수정한 기록은 다음 요소를 함께 포함합니다. - 실제 제품 맥락 - 조직의 코딩·문서화 규칙 - 적용된 WCAG 기준 - 문제를 해결한 코드 - 수정 여부를 검증하는 조건 - 이런 사례 기반 자료는 단순한 체크리스트보다 에이전트의 판단과 코드 제안에 훨씬 강력한 기반이 됩니다. ## 실용적인 결론 접근성 에이전트를 도입하려면 먼저 사람이 접근성 문제를 일관되게 기록하고, 재현 절차와 WCAG 기준, 실제 수정 사례를 축적하는 것이 좋습니다. 에이전트는 전문가의 판단을 대체하기보다 반복적이고 객관적인 문제를 빠르게 발견·수정하는 보조 수단으로 운영해야 하며, 그 한계를 명확히 정의할수록 조직 내 신뢰와 도입 효과가 커집니다.

gitlab

Contagious Interview IDE 공격을 탐지하고 방지하는 방법 (새 탭에서 열림)

Contagious Interview 캠페인은 가짜 채용 과제로 피해자가 악성 저장소를 VS Code에서 열고, `tasks.json`을 통해 악성 명령을 실행하도록 유도한다. 글은 VS Code 자체보다 운영체제에 가까운 `node-pty`의 `spawn-helper` 실행을 탐지하는 EDR 규칙과, IDE 작업 자동 실행을 비활성화하는 하드닝을 함께 적용해야 한다고 주장한다. 이를 통해 인포스틸러 설치와 기업 네트워크 접근 권한 탈취를 실행 전에 차단할 수 있다. ## Contagious Interview 공격의 진입 방식 - 공격자는 가짜 면접·코드 리뷰를 미끼로 피해자에게 악성 코드 저장소를 다운로드하고 VS Code에서 열도록 유도한다. - 저장소의 `.vscode/tasks.json`에는 프로젝트를 열 때 자동 실행되는 작업이 정의될 수 있다. - VS Code는 해당 저장소를 신뢰하도록 승인해야 작업을 실행하지만, 피해자는 면접 과정이라고 믿어 무심코 신뢰를 부여할 가능성이 높다. - 악성 작업은 `runOn: "folderOpen"`을 사용해 폴더를 열 때 자동 실행되며, 화면에 거의 표시되지 않도록 설정할 수 있다. - 예시 명령은 운영체제별로 다음 단계 악성코드를 내려받아 실행한다. - macOS: `curl ... | bash` - Linux: `wget ... | sh` - Windows: `curl ... | cmd` - 이후 인포스틸러가 비밀번호와 암호화폐 정보를 탈취하고, 지속성을 확보해 피해자의 기업 네트워크 접근 권한을 악용할 수 있다. ## IDE보다 낮은 계층을 겨냥한 탐지 - 특정 VS Code 기능만 탐지하면 VS Code 포크나 유사한 Node/Electron 기반 IDE를 우회 경로로 사용할 수 있다. - GitLab은 운영체제에 더 가까운 프로세스 생성 계층을 조사했다. - VS Code는 하위 프로세스를 실행할 때 널리 사용되는 `node-pty` 라이브러리를 활용한다. - `node-pty.spawn()` 호출은 자체 바이너리인 `spawn-helper`를 실행하며, 이 프로세스는 Node 애플리케이션의 자식 프로세스로 생성된다. - `node-pty`는 주당 다운로드 수가 100만 회 이상인 널리 사용되는 라이브러리이므로, 이 계층을 이용하면 특정 IDE에 종속되지 않는 탐지가 가능하다. ## 백그라운드 실행과 사용자 실행의 구분 - GitLab은 Purple Team 훈련으로 공격 경로를 재현한 뒤 EDR 텔레메트리를 분석했다. - VS Code에서 백그라운드 작업을 실행할 때는 주로 `spawn-helper`가 호출된다. - 사용자가 통합 터미널을 열거나 직접 프로세스를 실행하는 등 전면적인 상호작용이 있을 때는 `Code Helper` 바이너리가 사용된다. - 따라서 `spawn-helper`를 기반으로 탐지하면 사용자가 인지하지 못한 상태에서 실행되는 IDE 작업에 집중할 수 있다. - 일반적인 개발 활동에서 발생하는 의도적 프로세스 실행을 제외해 오탐을 줄일 수 있다. ## `curl | shell` 패턴과 행위 기반 튜닝 - `curl | bash`는 Homebrew 설치처럼 정상적인 용도로도 사용될 수 있으므로 단순 문자열 탐지는 오탐 가능성이 있다. - 하지만 사용자가 인지하지 못하는 백그라운드 작업에서 해당 명령이 실행되는 것은 조직 환경에서 비정상적일 수 있다. - GitLab은 다음과 같은 조건을 결합해 탐지 규칙을 조정했다. - 부모 프로세스가 IDE의 `spawn-helper`인지 - 작업이 백그라운드에서 실행됐는지 - 외부 URL에서 데이터를 내려받는지 - 다운로드한 내용을 셸로 직접 파이프하는지 - 이 방식은 모든 백그라운드 작업을 차단하지 않고, 드물고 위험한 실행 조합만 경고하도록 설계됐다. - 조직 내 많은 개발자가 매일 VS Code를 사용했음에도 구현 후 오탐이 발생하지 않았다고 설명한다. ## 다층 방어와 IDE 설정 강화 - EDR을 이용한 런타임 탐지는 악성 작업이 실제로 실행되는 순간을 포착하는 방어선이다. - 동시에 조직 전체 설정을 배포해 VS Code의 작업 자동 실행 자체를 비활성화하면 공격 표면을 줄일 수 있다. - 특히 저장소를 열 때 자동으로 실행되는 작업을 제한하면 `runOn: "folderOpen"` 기반 공격을 예방하는 데 효과적이다. - VS Code뿐 아니라 동일한 Node 기반 구조와 백그라운드 작업 기능을 가진 IDE 포크에도 같은 원칙을 적용해야 한다. 실무적으로는 IDE 작업 자동 실행을 기본 비활성화하고, EDR에서 `spawn-helper`의 백그라운드 프로세스 생성과 `curl/wget | shell` 패턴을 함께 모니터링하는 방식을 권장한다. Gmail·채용 플랫폼 등 초기 유입 경로에 대한 보안 교육과 저장소 신뢰 승인 절차도 병행해야 한다.

figma

VS Code 방식: 개발자의 이너 (새 탭에서 열림)

개발자의 생산성을 높이려면 코드 작성 자체보다 코드와 디버깅에 몰입하는 ‘이너 루프(inner loop)’를 최대한 끊기지 않게 해야 한다. VS Code는 외부 도구로 이동하는 횟수를 줄이고, 협업·프로젝트 관리·AI 지원 기능을 편집기 안으로 통합해 몰입과 협업을 함께 달성하려 한다. 궁극적으로 도구를 오가는 마찰을 줄이는 것이 코드 품질뿐 아니라 개발자의 만족도와 에너지에도 영향을 준다는 주장이다. ## 이너 루프와 아우터 루프의 구분 - **이너 루프**는 코드 작성, 컴파일, 디버깅을 코드 에디터 안에서 반복하는 집중 작업 과정이다. - **아우터 루프**는 버그 트래커 확인, 티켓 업데이트, 동료와의 Slack·Teams 대화, 문서 검색, 프로젝트 관리 등 에디터 밖의 활동을 의미한다. - 여러 프로젝트를 동시에 진행하면 브라우저, API 문서, 터미널, 데스크톱을 계속 오가게 되며 집중력이 분산된다. - 몰입 상태가 유지되면 코드의 엣지 케이스와 향후 확장 계획 같은 맥락을 머릿속에 유지할 수 있다. - 반대로 컨텍스트 스위칭이 발생하면 이러한 맥락이 사라져 생산성과 코드 품질이 떨어진다. ## 편집기 안에서 집중력 유지하기 - VS Code의 **Zen Mode**는 사이드바 등 불필요한 UI를 숨겨 방해 요소를 줄인다. - 화면 구성이 바뀔 때마다 뇌가 새로운 UI에 적응해야 하므로, 작은 UI 변화도 누적되면 집중을 방해할 수 있다. - 개발자는 필요한 확장 기능을 선택해 자신의 작업 방식에 맞게 편집기를 구성할 수 있다. - 단일 도구의 사용성을 개선하는 것만으로는 충분하지 않으며, 도구 사이를 오가는 행위 자체를 줄여야 한다. ## 아우터 루프를 이너 루프로 가져오기 - GitHub에서 풀 리퀘스트를 확인한 뒤 다시 에디터로 돌아오는 과정처럼, 작업 중 도구를 전환하면 흐름이 끊긴다. - 가능한 경우 다음 기능을 코드 에디터에 직접 통합해야 한다. - 협업자와의 커뮤니케이션 - 코드 리뷰와 풀 리퀘스트 처리 - 프로젝트 관리와 티켓 확인 - 디자인 및 API 문서 참조 - Figma for VS Code 확장 기능을 사용하면 VS Code에서 디자인을 직접 확인하고 검사할 수 있다. - 필요한 협업이나 프로젝트 관리 작업을 현재 작업 공간에서 처리하면 불필요한 브라우저 전환을 줄일 수 있다. ## AI를 활용한 작업 흐름 보완 - 생성형 AI는 개발자가 작성 중인 코드를 분석해 다음에 필요할 가능성이 높은 코드를 미리 제안할 수 있다. - 제안이 작업 흐름을 방해하지 않는 방식으로 제공되면 코드 작성 속도와 집중력을 동시에 높일 수 있다. - 글에서는 GitHub Copilot 사용 시 코딩 속도가 55% 향상되었다는 GitHub의 보고와, AI 사용 개발자의 75%가 더 큰 성취감을 느꼈다는 조사 결과를 소개한다. - AI의 가치는 단순한 속도 향상뿐 아니라 개발자가 반복 작업에서 벗어나 더 만족스럽게 일하도록 돕는 데 있다. ## 협업도 몰입을 깨지 않는 방식으로 - 협업은 필수지만 회의와 실시간 채팅, 메시지 왕복은 개발자의 집중을 끊을 수 있다. - 이상적인 협업은 한 사람이 다른 사람의 작업을 중단시키는 방식이 아니라, 서로 각자의 이너 루프를 유지하며 진행하는 것이다. - VS Code는 GitHub 기능을 편집기에 통합해 다음 작업을 에디터를 떠나지 않고 수행하도록 지원한다. - 이슈 작업 - 코드 리뷰 - 풀 리퀘스트 작성 및 제출 - 모든 협업이 실시간이어야 하는 것은 아니며, 비동기 댓글과 리뷰를 활용하면 집중과 협업을 함께 유지할 수 있다. ## 개발자 행복으로 이어지는 선순환 - 도구 간 전환이 줄어들면 작업의 마찰과 반복적인 불편이 감소한다. - 몰입 상태가 길어질수록 생산성뿐 아니라 개발자의 에너지와 만족도도 높아진다. - 개발자 도구를 만드는 팀은 기능을 추가하는 것뿐 아니라, 개발자의 흐름을 방해하는 요소를 지속적으로 제거해야 한다. - 장기적으로는 코드 에디터가 개발에 필요한 모든 도구를 연결하는 통합 작업 공간이 되는 것이 이상적인 방향이다. 개발팀은 자주 발생하는 도구 전환 지점을 먼저 파악하고, GitHub·디자인 도구·문서·프로젝트 관리 기능을 에디터와 연동하는 것부터 시작하는 것이 좋다. 또한 알림을 줄이고 비동기 협업을 기본값으로 삼으면 집중력을 보존하면서도 협업 품질을 유지할 수 있다.

figma

개발 모드: 개발자를 위해 더 (새 탭에서 열림)

Figma는 개발자를 단순한 디자인 파일 소비자가 아니라 제품 개발의 핵심 사용자로 보고 Dev Mode를 구축했다. 초기에는 디자인을 코드로 자동 변환하는 codegen 중심 접근을 택했지만, 실제 조직의 다양한 기술 스택과 협업 방식에는 한계가 있음을 발견했다. 결국 Dev Mode는 코드 생성만이 아니라 디자인 탐색, 변경 비교, 개발 도구 연동 등 개발자에게 맞춘 작업 환경을 제공하는 방향으로 확장됐다. ## 디자인과 개발의 경계를 줄이려는 Figma의 목표 - Figma는 처음부터 디자이너만을 위한 도구가 아니라 제품 관리자, 개발자 등 여러 직군이 함께 문제를 해결하는 공간을 지향했다. - 2017년 프로토타이핑과 개발자 핸드오프 기능을 선보이며 디자인과 코드 사이의 협업 흐름을 개선하려 했다. - 개발자들은 디자인 작업 중인 파일을 직접 확인하고 여러 핸드오프 방식을 실험했지만, 기존 Figma는 개발자 업무에 최적화된 도구는 아니었다. - Dev Mode는 디자인을 검사하고, 변경 사항을 비교하며, VS Code에서 작업하는 기능 등을 제공하는 개발자용 환경으로 출시됐다. ## 개발자 관점을 확보한 Visly 인수 - Figma 사용자 중 개발자가 약 3분의 1을 차지했지만, 개발자의 작업 방식과 도구 선호도에 대한 실질적인 직관은 부족했다. - 2021년 Figma는 React UI 컴포넌트 개발 도구를 만들던 Visly를 인수했다. - Visly 팀은 개발자 도구에 대한 연구와 실제 개발 경험을 Figma에 가져왔고, Dev Mode 개발을 가속했다. - 인수의 핵심 효과는 개발자를 대상으로 조사하는 것에서 나아가, 개발자처럼 생각하고 제품을 설계할 수 있는 팀을 확보한 데 있었다. ## 개발자를 2차 사용자가 아닌 핵심 사용자로 설계 - 기존 개발자들은 디자인 협업 때문에 Figma에 들어오지만, Figma가 자신들을 위해 만들어졌다고 느끼기 어려웠다. - Dev Mode 팀은 개발자가 디자인 모드의 복잡한 상호작용을 배울 필요 없이, 자신의 작업 방식에 맞는 인터페이스를 사용해야 한다고 판단했다. - 개발자 중심 기능으로 다음과 같은 아이디어를 검토했다. - 컴포넌트 플레이그라운드 - 코드 스니펫 - GitHub, Storybook 등 개발 도구와의 플러그인 연동 - 개발자 전용 리소스 - 중요한 관점은 개발자가 디자인 도구 안에서 장시간 생활한다는 전제가 아니라, 기존 개발 환경과 연결되는 보조 작업 공간을 제공하는 것이었다. - 베타 사용자 피드백과 고객 요청을 지속적으로 수집해 기능 우선순위에 반영했다. ## codegen 중심 접근의 출발과 한계 - **Codegen**은 정해진 규칙이나 명세를 바탕으로 디자인에서 코드를 자동 생성하는 방식이다. - Dev Mode 초기에는 디자인을 코드로 변환하면 개발 속도가 크게 빨라질 것이라고 보고 codegen을 핵심 방향으로 삼았다. - 자동 변환이 잘 작동하는 경우 프로젝트 작업 시간을 수시간에서 수일까지 줄일 수 있었다. - 그러나 테스트 환경에서 codegen이 작동하는 것과 실제 조직의 개발 프로세스에서 유용하게 작동하는 것은 달랐다. - 기업 규모, 팀 구조, 기술 스택, 개발 워크플로가 서로 다르기 때문에 모든 조직에 동일한 코드 생성 규칙을 적용하기 어려웠다. - 따라서 Dev Mode의 가치는 완성된 코드를 일괄 생성하는 데만 있지 않고, 개발자가 디자인 의도를 이해하고 자신의 코드베이스와 방식에 맞게 구현하도록 돕는 데 있다는 방향 전환이 필요해졌다. ## 실용적인 시사점 디자인-개발 협업 도구는 자동 코드 생성만으로 문제를 해결하기 어렵다. 조직별 기술 환경과 개발자의 실제 작업 흐름을 고려해 디자인 검사, 변경 추적, 코드 정보 제공, 기존 개발 도구와의 연동을 함께 지원해야 하며, 개발자를 제품의 부차적 사용자가 아닌 핵심 사용자로 설계하는 것이 중요하다.