조부모님과의 경험이 구체적으로 어떤것이였나요?

최근 주민등록증을 분실해 재발급을 받는 과정에서 여러 인증 절차를 거쳐야 했는데, 비교적 젊은 세대인 저에게도 절차가 다소 복잡하다고 느껴졌습니다.

반면, 은행의 고령층 맞춤형 키오스크는 큰 버튼, 명확한 안내, 단순한 절차 덕분에 저희 조부모님도 혼자서 입출금을 쉽게 처리하실 수 있었습니다.

이 두 가지 경험이 대조되면서 ‘왜 일상적으로 꼭 필요한 공공 서비스들은 사용자 경험이 이렇게까지 차이가 날까?’라는 의문이 들었습니다. 물론 환경적 제약도 존재하겠지만, 결국 사용자의 상황과 시나리오를 얼마나 깊이 고려한 설계인지가 서비스 편의성의 핵심이라는 점을 다시 한번 깨닫게 되었습니다.”

"KOSA 교육과정에서 가장 인상 깊었던 프로젝트나 학습 내용은 무엇인가요?”

첫 번째로, 깃 기반 협업 경험입니다.
브랜치 전략 설정, 코드 리뷰 문화, 커밋 메시지 컨벤션 통일 등 실제 팀 개발 환경에서 필요한 협업 방식을 체계적으로 익힐 수 있었습니다.

두 번째는 다양한 관점의 중요성을 배운 점입니다.
하나의 기능을 놓고도 팀원마다 서로 다른 사용자 시나리오와 해석이 나왔고, 이를 바탕으로 여러 관점에서 접근하는 것이 얼마나 중요한지 깨달았습니다. 이러한 차이를 조율하며 기능의 우선순위를 논의하고 결정하는 과정이 큰 도움이 되었습니다.

세 번째는 문제 해결 과정에서의 협력 경험입니다.
프론트 화면의 통일성 문제로 어려움을 겪었을 때, 팀원들과 적극적으로 논의하며 해결책을 찾았습니다. 다양한 레퍼런스 사이트를 함께 분석하고 벤치마킹하며, 서로 구현한 부분의 의도와 디자인 기준을 공유하면서 문제를 효과적으로 정리해 나갈 수 있었습니다.

"동료와 함께 성장한다고 했는데, 실제로 팀원에게 도움을 준 경험이 있나요?”

팀원 중 한 분이 AI 기반 API를 설계하는 과정에서 어려움을 겪고 계셨습니다. 저 역시 AI를 활용한 API를 구현한 경험이 있었기에, 개발 중 마주했던 문제점과 해결 방법을 미리 공유해드렸습니다.

저는 새로고침 시 반복적으로 발생하는 API 호출 문제를 Redis 캐시와 조건문 로직을 통해 해결한 경험을 이야기했습니다. 다만 팀원분의 기능은 데이터가 빠르게 쌓이고 자주 변경되는 특성이 있었기 때문에, Redis 캐시보다는 DB에 직접 저장하는 방식이 더 적합하다는 의견을 전달드렸습니다.

이후 팀원분은 해당 방향으로 개발을 마무리하셨고, 저는 이 경험을 통해 ‘경험 공유’가 단순한 지식 전달을 넘어 팀 전체의 역량을 높이는 중요한 과정이라는 것을 다시 한 번 깨달았습니다.

"팀원들과 지식을 공유한다고 했는데, 구체적으로 어떤 방식으로 공유했나요?

저희 팀은 주말을 제외하고 매일 같은 공간에서 프로젝트를 진행할 수 있었기 때문에,
매일 정기적인 회의를 통해 진행 상황을 공유했습니다.
각자의 작업에서 발생한 어려움이나 막히는 지점을 함께 이야기했고,
팀원 중 누군가 유사한 경험이나 해결 방법을 알고 있다면 서로 공유하며 문제를 함께 해결하려고 노력했습니다.

이러한 과정 덕분에 단순한 작업 분담을 넘어, 팀 전체가 함께 성장하는 협업 경험을 할 수 있었습니다.

"협업과 배려가 중요하다고 했는데, 협업 시 갈등이 생기면 어떻게 해결하나요?”

“협업 과정에서 갈등은 피할 수 없지만, 저는 갈등을 ‘더 나은 방향을 찾기 위한 과정’이라고 생각합니다.
실제로 트래블샷 프로젝트에서 도메인 구조를 정할 때 비슷한 경험을 했습니다.

프로젝트 초기에 저희 팀은 DDD 구조를 기반으로 개발을 진행했습니다.
당시 저는 각 팀원이 페이지 단위로 풀스택 역할을 나누어 개발하고 있었기 때문에,
‘페이지를 하나의 도메인으로 보는 것이 협업과 일정 관리에 유리하다’고 판단했습니다.

하지만 팀원들의 생각은 달랐습니다.
페이지 단위로 도메인을 나누면 같은 비즈니스 로직이 여러 페이지에서 중복되고,
결과적으로 유지보수성이 떨어진다는 의견이 나왔습니다.
또한 비즈니스 로직이 산재될 위험이 있어,
“어떤 기능이 어디 도메인에 포함되는지”가 오히려 더 모호해질 수 있다는 점을 팀원들이 지적해 주었습니다.

이 갈등 상황에서 저희는 감정이나 개인 취향이 아니라 기준과 근거를 중심으로 논의했습니다.
각 접근 방식의 장단점을 비교하고 실제 개발 이후의 유지보수, 확장성을 함께 고려했습니다.
그 결과, 저희는 ‘하나의 테이블을 중심으로 독립적인 비즈니스 기능을 수행하는 구조’를 도메인 기준으로 정하는 것이 더 합리적이라는 결론에 도달했습니다.

이 경험을 통해 느낀 점은,
갈등이 생겼을 때 중요한 것은 의견의 충돌이 아니라
서로의 관점을 이해하고 “프로젝트 전체에 가장 이로운 선택”을 찾기 위한 소통이라는 것입니다.
저는 앞으로도 갈등이 생기면 감정보다는 근거, 개인보다는 팀과 프로젝트 전체를 기준으로 문제를 해결하려고 합니다.”

모든 세대를 위한 기술이 되어야 한다고 했는데, 개발할 때 실제로 어떻게 반영하나요?”

기억숲 프로젝트를 진행하면서, 고령층 사용자에 대한 UX 고려를 실제로 반영한 경험이 있습니다.
프로젝트의 목적이 치매 예방을 위한 추억 인지 게임이다 보니,
고령층이 최대한 쉽게 접근하고 사용할 수 있도록 UI/UX 설계에 특히 신경을 썼습니다.

우선, 게임 시작 절차를 단순화했습니다.
복잡한 회원가입이나 로그인 절차를 배제하고, 보호자가 공유해주는 하나의 링크만 클릭하면 곧바로 게임이 시작되도록 흐름을 구성했습니다.
이를 통해 고령층 사용자가 스마트폰이나 웹 사용에 익숙하지 않아도 문제없이 게임을 할 수 있도록 했습니다.

또한, 트랴블샷 프로젝트에서는 에러 메시지를 명확하고 구체적으로 작성했습니다.
단순히 “오류가 발생했습니다” 와 같은 추상적인 문구 대신,
“여행 일정을 선택해 주세요”, “다음 단계로 이동하려면 버튼을 눌러주세요”처럼
사용자가 다음 행동을 이해할 수 있도록 안내 메시지를 세분화했습니다.
이러한 예외 처리 방식 덕분에 고령층 사용자뿐만 아니라 보호자도 더 직관적으로 서비스를 이용할 수 있었습니다.

이 경험을 통해, 기능을 만드는 것뿐만 아니라 사용자의 상황을 고려한 설계가 얼마나 중요한지 다시 한번 깨달을 수 있었습니다.