01. 당신이 당신의 문제를 스스로 만든다
1편: 당신이 당신의 문제를 스스로 만든다
왜 이 글을 쓰게 되었나
3년차, 5년차가 되어도 영어 문서 앞에서 주눅드는 개발자들을 많이 봤습니다. 보통 “영어 잘하는 사람들이나 보는 거 아니야?”라고 생각하며 블로그와 유튜브를 뒤적거리다가, 결국 더 큰 문제를 만들어내는 악순환을 반복하죠. 이 시리즈는 그런 분들을 위한 글입니다.
블로그 주도 개발: 지옥의 나날들
처음 웹 개발을 배울때, Spring Boot 구버전에서 Spring Security를 설정하고 있었습니다. JWT 인증을 구현해야 했는데, 한국어 블로그들을 참고해서 이렇게 짰습니다. 자세히는 기억 안 났지만 아마 Tistory 블로그를 참조했던 기억이 납니다.
@Configuration
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.antMatchers("/api/auth/**").permitAll()
.anyRequest().authenticated();
}
}
그러고 나서 컴파일을 하고 서버를 돌리려는데 이런 메시지를 보게 됩니다. deprecated? 이게 다 뭐지.
'WebSecurityConfigurerAdapter' is deprecated
'configure(HttpSecurity)' is deprecated
'authorizeRequests()' is deprecated
'antMatchers(String...)' is deprecated
검색해보니 더 이상 지원하지 않는 기술이라 안전하지 않은 기술이라 Bean 기반으로 고쳐야 한다는데… 하 모르겠습니다. 블로그나 검색해보기로 했습니다.
삽질의 연속
첫 시도: “Spring Security JWT 인증 구현” 구글링
- 상위 10개 블로그 다 읽음
- 전부 구식 방법 (WebSecurityConfigurerAdapter 상속)
- Stack Overflow도 2019년 답변들만…
두번째 시도: “Spring Boot 2.7 Spring Security 설정” 재검색
- 또 구식 방법들
- YouTube 영상도 전부 옛날 방식
- ChatGPT도 구식 코드 제공
여기서 ChatGPT 얘기를 좀 더 해보자면, ChatGPT나 다른 AI 모델들은 학습 데이터의 시점이 정해져 있습니다. 예를 들어 2023년까지의 데이터로 학습했다면, 2024년에 deprecated된 메서드는 모릅니다. 게다가 학습 데이터의 대부분이 이미 구식이 된 블로그 글들이라면? AI도 구식 코드를 “정답”이라고 알려주게 됩니다. 결국 AI에게 물어봐도 블로그 검색과 똑같은 문제에 빠지는 거죠.
3분만에 끝난 해결책
포기하고 Spring Security 공식문서를 열었습니다: https://spring.io/guides/gs/securing-web/
@Configuration
@EnableWebSecurity
public class WebSecurityConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests((authz) -> authz
.requestMatchers("/api/auth/**").permitAll()
.anyRequest().authenticated()
);
return http.build();
}
}
별 문제 없이 한번에 해결되는걸 확인할 수 있었습니다. 와. 제가 제 문제를 스스로 만들고 있었군요.
왜 이런 일이 반복되나?
IT 분야는 오늘 배운게 내일 쓰레기가 됨
웹 개발이나 AI 개발 같은 분야는 변화가 정말 빠릅니다. 물론 안정적이고 검증된 기술을 사용하는 대규모 사업체나 레가시 기술이 중요한 분야는 다르겠지만… 아무튼 실시간으로 업데이트가 가능한 분야 특성상 당장 어제까지 멀쩡하게 쓰던 메서드를 사용하면 경고가 뜨거나, 좀 엄격한 라이브러리의 경우 아예 컴파일 자체를 거부해버리기도 합니다.
많은 개발자들이 개발을 할때 문제가 생기면 ChatGPT에게 묻거나 블로그 글을 검색하곤 합니다. 한국어로 적혀있으니까! 근데 거기 적혀있는거 많은 경우에는, 현재 시점에서는 쓸모가 없는 내용입니다. 현재 시점에서는 업데이트가 되었을 확률이 높기 때문에. 구식 코드를 그대로 사용하면 나중에 문제가 될 수 있습니다. 당장은 작동해도 나중에 큰 문제를 일으킬 수 있어요. 마치 자전거 바퀴에 막대기를 끼우고 넘어지는 것처럼, 의도치 않게 스스로 문제를 만드는 셈입니다.
개발자들의 패턴
- 문제 발생
- “한국어로 된 게 없나?” 검색
- 구식/잘못된 정보로 삽질
- 결국 공식문서 참조
- “아, 진작 이거 볼걸…”
나만의 경험이 아니다
팀장: “React 18 Suspense 어떻게 쓰지?”
- 한국어 블로그: React 16 방식 안내
- 2시간 삽질 후 React 공식문서 확인
- 5분만에 해결
후배: “Docker multi-stage build 에러”
- Stack Overflow 2020년 답변으로 1일 삽질
- Docker 공식문서 Dockerfile best practices
- 10분만에 해결
동료: “AWS Lambda 콜드 스타트 최적화”
- 개인 블로그 3시간 읽기
- AWS 공식문서 Performance tuning
- 15분만에 핵심 파악
최신 정보는 모두 영어로 적혀있음
IT 생태계의 진실
- GitHub 스타 10k+ 프로젝트: 많은 경우에 영어로 작성되어있음
- 최신 기술 정보, 논문: 주로 영어로 먼저 공개
- 기술 정보 follow-up을 위한 최대 커뮤니티인 Hacker News: 모두 영어!
- 개인 해커로 활동하며 버그 바운티 활동: 정책이 영어로 적혀있고, PoC도 영어로 작성해야 함
- 공식 문서: 100% 영어 (한국어 번역 있어도 구버전)
영어를 공부하는 것이 아닌 기술 영어를 공부하세요
아무리 생각해도 영어를 공부하기 너무 싫을 수 있습니다. 학교에서 영어공부를 했던 경험이 부정적일 수 있고, 언어를 새로 배운다는 것 자체가 방대한 작업으로 느껴질 수 있기 때문입니다.
하지만 생각해보세요. 예를 들면 일본 애니메이션을 본 경험이 있다면, 일본어를 모르기 때문에 일본 애니메이션을 보는 것이 두려웠나요? 그냥 보는것이 재밌으니까 보죠. 그러면서 단어 하나씩 귀에 들리는겁니다. 마나부(배우다), 쿠우(먹다), 아소부(놀다)… 언어를 배우는 작업 자체가 처음부터 완벽하게 하는 것이 아닌 점진적으로 진행되는 일입니다.
우리가 어학시험 만점을 받으려는 것도 아니고 외국인과 자유자재로 대화하려는 것도 아닙니다. 그냥 기술 문서를 읽고 싶은 것뿐입니다.
기술 문서는 일반 영어와 다릅니다. 사용하는 단어도 제한적이고(대략 8천 개 정도 어쩌면 그보다 작음), 문장 구조도 비교적 단순하고 항상 보는 단어만 봅니다. 생각보다 달성 가능한 목표일 수 있습니다.
다른 사람들이 공식 문서 보고 한번에 문제 해결할 때, 우리도 블로그 뒤적거려가며 고생하지 않고 그렇게 할 수 있다면 좋지 않을까요?
다음 편 예고
그렇다면 어떻게 기술 영어를 효율적으로 배울 수 있을까요? 일반적인 영어 학습법과는 다른, 개발자를 위한 특별한 방법이 있습니다. 다음 편에서는 왜 IT 학습을 위해 영어가 필수인지, 그리고 기술 영어를 배우는 것이 생각보다 어렵지 않다는 것을 더 자세히 다뤄보겠습니다.
여러분도 공식 문서를 두려워하지 않고 바로 읽을 수 있게 되는 그날까지, 이 시리즈가 작은 도움이 되었으면 좋겠습니다.
⬅ 이전: 개요 | 다음: 2편 번역기의 배신 ➡ |