[자기소개서] 갈등해결 이렇게 작성해보자
개발자에게 원하는 갈등해결 스토리
오랜만에 자기소개서 작성법 글을 쓰게 되었다.
오늘은 기업의 자기소개서 항목 중 빈출도가 높은 자기소개서 문항인 '갈등해결 문항' 작성법을 알아보도록 하겠다.
사실 굉장히 작성하기 쉬운 항목인데! 많은 취업준비생들과 이야기를 나누다 보면 '갈등해결' 항목 작성을 생각보다 어려워 하더라.
또는 안타깝게도 본인은 잘 썼다고 생각했는데, 실제로는 평범했던 경우가 많았다.
다행인 건, 못 쓴 경우는 거의 없다는 사실이다. 반대로 말하면 대부분이 평범하고 유사하게 작성하는 항목이라는 뜻이겠다. 그렇기 때문에 조금만 더 다듬어서 차별화 포인트를 가져간다면 충분히 나를 돋보이게 만들 수 있는 항목이기도 하다!
이번 시간에는 일반적인 '갈등해결 작성방법'은 제외하고, 여러분들이 자기소개서 작성시에 가장 많이 놓치는 부분에 대해 이야기해 보겠다.
1. 첫번째, 갈등이 없었어서 쓸만한 소재가 없다고 하지 말자
생각보다 위와 같은 말들을 컨설팅 시 많이한다. 프로젝트 할 때 팀원들과의 관계가 너무 좋았어서 갈등이 진짜 없었다는 것! 그렇다면 이쯤에서 '갈등'의 정의가 무엇인지 살펴보자
출처 : 네이버 사전
주로 '갈등이 없었다' 라고 말하는 분들은 갈등의 정의에서 1번, '서로 적대시하거나 충돌함' 에 포커싱을 두고 생각하고 있는 듯 하다. 한마디로 팀원과 내가 서로 대판 싸우고 불화가 있었던 상황을 '갈등'으로 인지하고 있는 것이다. 하지만 그 앞의 단어를 보면 '개인이나 집단 사이에 목표나 이해관계가 달라' 라는 서술도 있다. 한마디로 '갈등' 이란 '팀원들과 이해 관계가 다르거나 의견이 다른 경우' 도 포함한다는 뜻이다. 그렇게 본다면 정말 프로젝트 내내 '의견이 다른 경우가 없었을까? 이해관계가 다름으로 인해 생각이 다른 경우가 없었을까?
사소하게는 프로젝트 기획방향성에 대한 의견 차이부터 어떤 기술이나 프레임워크를 쓸까에 대한 의견 차이, 주요 기능에 대한 의견 차이, 역할 분장에 대한 이해관계 차이 등 개발 단계별로 의견 차이가 있었던 경우를 생각해 본다면 갈등사례를 보다 쉽게 생각해 낼 수 있을 것이다.
2. 두번째, 갈등해결 전 원인 분석을 넣어보자.
많은 취준생들이 갈등을 잘 해결했다고 쓴다. 소통과 경청 설득력 등을 통해서 말이다. 하지만 왜 이러한 갈등이 일어났는지 원인을 분석하는 경우는 자주 보지 못했다. 하지만 프로젝트에서 기술이슈가 발생했을 때에도 원인을 알아야 해결할 수 있듯이 사람관계에서도 갈등의 발생원인을 알아야 해결할 수 있다. 아래는 DBR이라는 경영잡지에서 제시하고 있는 갈등 발생의 원인과 예시, 해결방안이다.
(예전 자료이지만 내용이 좋아서 시간이 된다면 전문을 읽어보길 추천한다. DBR 경영잡지 : 갈등 원인을 알아야 정답 찾는다)
여러분들의 갈등상황은 어떤 원인으로 부터 출발했는가?
PJT 3주만에 팀원 7명 중 3명이 취업을 해서 위기가 닥쳤을수도 있고(구조의 충돌 )
백엔드와 프론트엔드가 서로 업무적으로 갈등이 있었을 수도 있고(이익의 충돌)
동일한 역할을 담당한 팀원끼리 명세서 해석을 서로 다르게 해서 갈등이 있었을 수도 있다(해석의 충돌)
아니면 그냥 성격이 너무 다르고 안맞아서 갈등이 있었을 수도!(다름의 충돌)
원인을 분석하면 솔루션은 다르게 들어갈 수 밖에 없다. 성격이 너무 달랐다면 공감하고 친밀해 지는게 해결방법이 맞을 수도 있겠다. 그런데 소통과정에서 정보 해석의 오류나 비효율이 있었다면은 공감과 친밀감으로 해결되는 문제는 아니었을 것이다. 정보 해석의 오차를 줄이기 위해 소통방식을 바꿨거나 소통 툴을 추가했을 수도 있다. 따라서 원인을 분석하고 나면 그다음 해결방안에 대한 내용을 쓰는 것이 생각보다 자연스러워 진다. 물론 원인 분석이 자기소개서에 꼭 들어가야 하는 건 아니다. 안 써도 합격하냐고 묻는 다면 그렇다!! 하지만 분석 내용 자체를 자기소개서에 담지는 않더라도, 한번쯤 갈등의 원인을 구분지어 보면 해결방안 작성의 실마리가 풀릴 것이기에 원인을 분석해 보기를 추천한다!
3. 세번째, 갈등 해결 과정을 구체적으로 작성하자.
두번째 스탭을 통해 우리는 갈등의 원인을 분석했다. 그런데 이렇게 다양한 원인에서 비롯된 갈등일텐데 대부분은 '잘 경청' 하고 '잘 공감' 하고 '잘 설득' 해서 해결했다고 작성한다. 중요한 것은 '무엇을 서로 공감했고, 어떻게 설득했는지' 구체적인 방법론인데 말이다. 또한 많은 현업개발자 분들이 자기소개서에서 '갈등해결' 문항을 통해 파악하고자 하는 것은 인간적인 덕목이나 성품을 알고싶어서라기 보다는 개발과정에서 조직에서 발생될 수 밖에 없는 의견차이를 어떻게 좁혀가는 사람인지를 알고싶은 것이다. 따라서 갈등해결 과정을 보다 구체적으로 작성할 필요가 있다.
예를 들어보자.
AI를 통한 개인별 코디 추천 어플리케이션을 개발한 팀이 있었다.
기획 과정에서는 AI를 통해 전신을 인식하고 성별, 나이, 체형, 희망 스타일, TPO, 희망 금액에 맞는 추천 알고리즘을 개발하려고 했는데, 생각보다 진행 속도가 늦어져 프로젝트 마감이 얼마 남지 않게 되었다.
어느 기능까지 구현할 것인가에 대해 나는 성별, 나이, 스타일 까지만을 제시했고,
다른 팀원들은 끝까지 다 해보자고 주장한 상황이다.
Q1 갈등의 원인은 무엇인가?
- 마감기한까지 어느정도 기능까지 구현이 가능한지 서로 생각하는 수준과 정보의 해석이 다르기 때문
Q2 해결 방법은 무엇인가?
- 서로 어느정도 까지 구현을 희망하는지 수준에 대한 정보 오차를 줄인다. 그리고 시뮬레이션을 통해 각 기능별 실제 작업 가능 일정을 예측하여 다른 일정상 불가능하다는 것을 이해시키고, 완성도 있는 프로젝트 결과물을 도모하자고 팀원들을 설득한다.
그냥 설득한 것이 아니다. 정보의 오차를 줄이고, 시뮬레이션을 통해 일정이 불가하다는 것을 설득했다. 자기소개서에서 알고 싶은 것은 이러한 갈등 해결을 위한 다양한 방법과 시도이다. 따라서 위와 같이 갈등해결 스토리를 정리하고 자기소개서 작성을 시작한다면 훨씬 더 구체적으로 갈등해결 스토리를 작성할 수 있을 것이다. 이렇게 갈등해결 자기소개서 작성법을 알아보았다.
4. 네번째, 실전 적용해 보기
자 그럼 이제 이러한 갈등의 종류 중 취업준비생들이 자주 사용하는 프론트엔드/백엔드 간의 업무 역할 차이로 인한 의견차이나 비효율적인 소통을 해결했던 내용을 예시로 들어보자. 갈등 상황을 제시하면서 보통은 바로 해결한 결과를 보여주는데, 내가 제시하는 방법은 해당 사건에 대한 원인을 먼저 분석하고 해결방안을 자연스럽게 연결하라는 것이다.
아래의 두개 자기소개서 예시를 비교해 보자.
예시1) 갈등 상황 - 해결을 위한 노력 - 결과 제시
게임 추천 웹서비스를 개발할 당시, 프론트엔드와 백엔드 간 업무 역할 차이로 인해 의견차이와 중복되는 코드 작성 등 비효율적인 소통 문제가 발생했습니다. 초기에는 API 명세가 불명확해 데이터 처리 방식이 달라졌고, 기능 구현 과정에서도 서로의 입장을 충분히 이해하지 못해 충돌이 잦았습니다.
이러한 문제를 해결하기 위해 먼저 팀 내 역할을 명확히 구분하고, Swagger를 활용한 API 문서화를 제안하여 개발 초반부터 데이터 구조와 응답 형식을 통일했습니다. 또한, 매일 짧은 스탠드업 미팅을 통해 진행 상황을 공유하고, 구현 전 협의하는 문화를 조성했습니다. 이 과정을 통해 중복 작업을 줄이고, 서로의 기술적 관점을 이해하는 계기가 되었습니다.
그 결과, 기능 구현 속도와 완성도가 높아졌을 뿐만 아니라, 팀원 간의 신뢰와 협업 능력도 향상되었습니다. 이 경험을 통해 저는 의사소통이 기술만큼 중요하며, 갈등은 오히려 더 나은 협업 방식을 만드는 기회가 될 수 있다는 것을 배웠습니다.
이 글을 읽으며 이것도 괜찮은데?? 할 수도 있겠다... 물론 심각하게 못쓴 자기소개서는 아니다. 하지만 아래의 자기소개서를 읽어보면 생각이 달라질 것이다.
예시2) 갈등 상황 - 갈등 원인 분석 - 해결을 위한 노력(여러개) - 결과 제시
게임 추천 웹서비스를 개발할 당시, 프론트엔드와 백엔드 간에 반복되는 소통 오류와 의견 차이로 비효율이 자주 발생했습니다. 프로젝트 초반, 각자의 개발 일정에만 집중한 나머지 API 명세가 명확히 정리되지 않았고, 기능 구현 전에 사전 협의가 부족했습니다. 이로 인해 동일한 기능을 중복으로 개발하거나, 데이터 형식 불일치로 디버깅 시간이 늘어나는 등 업무 충돌과 오해가 반복되었습니다.
저는 이러한 갈등의 근본적인 원인이 ‘소통 구조의 부재’에 있다고 판단하고, 다음과 같은 해결책을 제안하고 실천했습니다.
첫째, Swagger를 활용한 API 명세 공유 시스템을 도입하여 사전에 데이터 구조를 정의하고, 변경 사항을 실시간으로 관리했습니다.
둘째, 매일 짧은 스탠드업 미팅과 이슈 공유 문서 작성을 통해 서로의 진행 상황과 기술적 이슈를 공유하는 루틴을 만들었습니다.
셋째, 개발 초기에는 간단한 기능이라도 먼저 공통 스펙에 맞춰 목업 데이터를 주고받으며 테스트하는 과정을 거쳤습니다.
그 결과, 중복 작업은 거의 사라졌고 개발 속도가 향상되어 예상하였던 마감일 보다 시간을 3일 단축하였습니다. 그 덕분에 테스트 과정에 시간을 더욱 투입할 수 있었고, 완성도 높은 서비스를 구현할 수 있었습니다. 이 경험을 통해 저는 문제의 원인을 분석하고 시스템적으로 개선해 나가는 것이 갈등 해결의 핵심이라는 교훈을 얻었고, 개발 역량 못지않게 소통과 협업 능력도 프로젝트의 성패를 가르는 중요한 요소임을 체감했습니다.
어떠한가? 누가 더 소통과 협업에 대한 명확한 기준과 가치관을 가지고 적극적으로 협업하는 사람으로 느껴지는가? 여러분들과 나의 선택이 동일할 것이라고 생각된다.
