오타 많은 동료 때문에 괴로운가요? 사람을 탓하기 전에 시스템을 보세요

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

개발자라면 누구나 한 번쯤 등골이 서늘해지는 순간을 겪습니다. 저 역시 주니어 시절, 운영 환경 설정 파일에서 콤마 하나를 빠뜨리는 바람에 서버를 내려버린 기억이 있습니다. 그때의 식은땀은 아직도 잊히지가 않네요. 오늘은 최근 해커뉴스(Hacker News)에서 화제가 된 한 사연을 통해, '실수하는 동료'와 '그걸 지켜보는 팀'이 어떻게 공존해야 하는지 이야기해보려 합니다.

얼마 전 "오타를 많이 내는 동료를 어떻게 도와야 할까요?"라는 제목의 글이 올라왔습니다. 사연은 이렇습니다. 동료 A는 성실하고, 학습 속도도 빠르고, 테스트 코드 작성에도 열정적인 훌륭한 개발자입니다. 하지만 치명적인 단점이 하나 있습니다. 바로 '오타'입니다. 특히 린터(Linter)나 컴파일러가 잡아주지 못하는 설정 파일(Config), 쉘 스크립트 등에서 잦은 오타를 내고, 이게 스테이징을 넘어 프로덕션 장애로까지 이어진다는 것이죠.

작성자는 동료에게 난독증(Dyslexia)이 있는 건 아닐까 의심할 정도로 상황이 심각하다고 했습니다. 팀 분위기는 험악해집니다. "도대체 왜 이렇게 부주의해?"라는 비난이 나오기 시작했고, 당사자는 방어적인 태도로 변해버렸죠.

이 글을 읽으며 저는 기술 리더로서 깊은 고민에 빠졌습니다. 과연 이건 그 동료 개인의 '부주의' 탓일까요? 아니면 그 실수를 걸러내지 못한 우리 '시스템'의 문제일까요?

"더 꼼꼼히 보세요"는 해결책이 아닙니다

솔직히 말해, 사람에게 "실수하지 마세요"라고 말하는 것만큼 무책임한 피드백은 없습니다. 인간은 본질적으로 실수를 하는 존재입니다. 특히 고도의 집중력을 요하는 코딩 업무에서, 텍스트 패턴 인지에 약점이 있는 동료에게 단순히 '정신 똑바로 차리라'고 하는 건 고문이나 다름없습니다.

문제의 핵심은 '오타가 프로덕션까지 흘러가는 파이프라인'에 있습니다.

사연 속 동료는 자신의 실수를 인정하기보다 테스트 커버리지를 늘려야 한다며 방어적으로 나옵니다. 심리적으로 몰려 있기 때문입니다. 동료들이 자신을 '짐'으로 여긴다고 느끼는 순간, 심리적 안전감(Psychological Safety)은 무너지고, 방어기제는 더 강한 고집으로 나타납니다.

이때 필요한 건 감정적인 지적이 아니라, 감정이 배제된 '도구'의 개입입니다.

AI를 '냉철한 동료'로 채용하세요

풀링포레스트에서 우리는 AI를 적극적으로 활용합니다. 단순히 코드를 짜주는 것을 넘어, 인간 관계의 완충제 역할로도 씁니다.

해커뉴스 댓글 중 눈에 띄는 솔루션이 있었습니다. 바로 Claude Code나 AI 기반 리뷰 봇을 활용하는 방법입니다. 예를 들어, PR을 올리기 전 터미널에서 /review 나 /security-review 같은 명령어를 통해 AI에게 먼저 검수를 받게 하는 것이죠.

이 방식이 왜 효과적일까요?

1. 감정이 없습니다: 동료가 "여기 오타 또 냈네요"라고 하면 잔소리처럼 들리지만, AI가 "Config 파일 12번째 줄에 키 값이 일치하지 않습니다"라고 리포트하면 그저 해결해야 할 '버그'로 받아들여집니다. 자존심이 상할 일이 없죠.

2. 문맥을 이해합니다: 단순한 스펠링 체크를 넘어, AI는 코드의 의도를 파악합니다. "이 변수는 위에서 선언된 DB_HOST를 의도한 것 같지만 DB_HOT로 작성되었습니다" 같은 맥락적인 지적은 기존의 정적 분석 도구가 하기 힘든 영역입니다.

우리가 지향해야 할 방향은 동료의 약점을 비난하는 것이 아니라, 그 약점을 기술로 보완해 주는 것입니다. 그 동료가 가진 성실함과 열정을 살리면서, 오타라는 '노이즈'를 AI 필터로 걸러내는 것이 리더가 해야 할 일입니다.

시스템을 '단단하게' 만드세요

도구 도입과 더불어 구조적인 개선도 필요합니다. 오타가 잦다는 건, 시스템이 지나치게 '문자열 기반(Stringly Typed)'으로 되어 있다는 방증일 수 있습니다.

• Config의 코드화: YAML이나 JSON 대신 TypeScript나 Go 같은 타입 안전(Type-safe) 언어로 인프라를 정의하세요(IaC). 컴파일 단계에서 오타를 잡을 수 있습니다.

• 유효성 검사 강화: 쉘 스크립트처럼 오타에 취약한 부분은 파이썬이나 고수준 언어로 전환하고, 입력 값에 대한 엄격한 스키마 검증(Schema Validation)을 도입해야 합니다.

작성자의 말처럼 동료가 직접 테스트 코드를 짜게 하면, 본인이 낸 오타를 그대로 테스트 코드에 복사할 위험이 큽니다. 크리티컬한 로직의 테스트는 동료 간 크로스 체크를 하거나, AI에게 "이 설정 파일의 엣지 케이스 테스트를 짜줘"라고 요청해 인간의 편향을 깨뜨려야 합니다.

결론: 완벽한 사람은 없습니다

동료가 방어적인 태도를 보인다면, 그건 그가 나쁜 사람이라서가 아니라 두렵기 때문일 겁니다. 자신의 실수가 팀에 피해를 준다는 사실을 누구보다 잘 알고 있을 테니까요.

그 동료를 따로 불러 "난독증 아니냐"고 묻는 건 최악의수입니다. 대신 이렇게 제안해 보세요.

"우리 팀 전체의 생산성을 위해 AI 리뷰 봇을 도입해 보자. 나도 요즘 자잘한 실수가 늘어서 기계의 도움을 좀 받고 싶다."

문제를 개인의 결함이 아닌, 팀이 함께 해결해야 할 기술적 과제로 프레임(Frame)을 바꾸는 것. 그것이 건강한 엔지니어링 문화를 만드는 첫걸음입니다. 풀링포레스트가 AI를 통해 일하는 방식을 혁신하려는 이유도 바로 여기에 있습니다. 기술은 결국 사람을 돕기 위해 존재하는 것이니까요.