나에 대해
저는 기술 자체보다 그 기술이 어떤 불편을 해결하는지에 관심이 있습니다.
기능 하나를 만드는 것보다 사용자가 서비스를 이용하는 흐름이 자연스럽게 이어지는지를 함께 생각하려고 합니다.
- 개발 환경 웹과 데스크톱 앱을 함께 개발해 본 경험이 있고, 모바일까지 확장하는 프로젝트도 진행하고 있습니다.
- 관심 있는 경험 환경이 달라져도 사용자가 연결 방식을 의식하지 않고 서비스를 이어서 사용할 수 있는 경험에 관심이 있습니다.
- 기술 선택 새로운 기술을 접하면 일단 적용하기보다, 지금 해결하려는 문제에 필요한지 먼저 생각합니다.
선택의 우선순위
안정성 · 사용자 경험
→ 성능 · 유지보수성
→ 개발 속도개발할 때
문제를 다루는 순서
- 재현 발생한 문제를 먼저 재현합니다.
- 관찰 로그와 실행 결과를 확인합니다.
- 원인 좁히기 확인한 내용을 바탕으로 원인을 좁혀 갑니다.
서버 오류, 배포 문제, 외부 API 연동, 성능 저하처럼 원인이 바로 보이지 않는 문제를 여러 번 이런 방식으로 다뤘습니다.
구현 전에 정리하는 것
- 데이터 구조 ERD를 작성하고 데이터 흐름을 정리합니다.
- API와 서버의 책임 API 명세와 서버 간 역할을 가능한 한 먼저 정리한 뒤 구현합니다.
성능이나 구조상의 문제가 보이면 동작한다는 이유만으로 그대로 두지 않으려고 합니다. 다만 성능 개선 자체가 목적은 아닙니다.
안정성과 사용자 경험을 해치지 않는 범위에서 성능과 유지보수성을 개선하는 방향을 선호합니다.
협업할 때
팀 프로젝트에서는 백엔드 개발자뿐 아니라 PM과 PL 역할도 맡아 보았습니다.
- 역할과 일정 조율 일정이 밀리면 진행 상황을 함께 확인하고, 업무가 특정 사람에게 몰리지 않도록 역할과 일정을 다시 조정한 경험이 있습니다.
- 의견을 비교하는 방법 의견이 다를 때는 설명에 그치지 않고, 직접 구현하거나 테스트할 수 있는 형태로 만들어 비교하려고 합니다.
- 함께 마무리하기 제가 제안한 변경으로 팀원의 작업이 늘어나면 일정 안에서 함께 마무리할 수 있도록 구현을 돕기도 했습니다.
- 함께 문제 풀기 팀원과 자료를 함께 찾아보거나 짧게 페어 프로그래밍을 해 본 경험이 있습니다.
- 학습 공유 Java와 Spring을 함께 공부하기 위한 스터디를 직접 운영한 적이 있습니다.
- 피드백 반영 피드백을 받은 뒤 Git 협업 방식을 바꾼 경험이 있습니다. 익숙한 방식도 더 나은 방법이 있다면 수정하려고 합니다.
PR · 코드 리뷰
- 변경 범위 한 가지 목적에 맞게 작게 나눕니다.
- 설명 변경 이유와 검증 결과를 함께 남깁니다.
- 검토 기준 요구사항 충족과 오류·경계 상황을 확인하고, 가독성·구조의 일관성·보안·성능을 함께 검토합니다.
검증 범위
덤핏의 작업 지침에는 변경의 영향과 위험도에 맞춰 검증 범위를 정하도록 해두었습니다.
- 개발 중 변경한 영역을 중심으로 확인합니다.
- 영향이 큰 변경 보안이나 여러 기능에 영향을 주는 변경, 병합·배포 전에는 검증 범위를 넓힙니다.
- 화면 변경 실제 브라우저와 모바일 환경에서도 확인합니다.
- 완료 보고 아직 확인하지 못한 부분을 함께 남깁니다.
AI를 활용할 때
AI는 정답을 대신 결정하는 도구보다 분석과 구현의 범위를 넓히는 도구로 사용하고 있습니다.
- 활용하는 단계 요구사항 정리, PRD 작성, 코드 초안, 오류 원인 분석, 문서 정리에 활용합니다.
직접 결정하는 것
- 설계의 출발점 DB 구조·아키텍처·라이브러리 선택은 가능한 한 먼저 초안을 작성하거나 방향을 구상합니다. AI와 대안을 분석한 뒤 적용 범위와 최종 판단은 직접 정합니다.
- 선택의 이유 기술이나 라이브러리를 제안받아도 왜 필요한지 설명할 수 없는 선택은 그대로 적용하지 않습니다.
- 정보를 공유하는 범위 비밀키와 인증 정보처럼 보안에 직접 연결되는 요소는 AI에 판단을 맡기지 않습니다. 무엇을 공유하고 어떤 정보를 코드·저장소 밖에서 관리할지는 사람이 직접 통제해야 한다고 생각합니다.
구현과 검토
- 역할 분리 구현을 담당하는 에이전트와 리뷰를 담당하는 에이전트를 분리합니다.
- 결과 확인 생성된 코드의 실행 결과와 로그를 확인하고, 기존 구조·요구사항에 맞는지 검토한 뒤 수정합니다. 변경 내용과 실제 검증 결과를 대조하는 절차를 두고 있습니다.
- 리뷰 반영 리뷰의 지적도 코드와 요구사항에 맞는지 확인한 뒤 반영합니다. 치명적이거나 중요한 문제는 해결하고 다음 단계로 진행하는 것을 기준으로 삼습니다.
결국 AI와 함께 개발할 때 제가 중요하게 보는 것은 누가 코드를 입력했는지가 아닙니다. 문제를 어떻게 정의했는지, 어떤 선택지를 검토했는지, 왜 그 방식을 선택했는지, 그리고 결과에 책임질 수 있는지가 더 중요하다고 생각합니다.