[Legacy] cannot resolve symbol 'springbootapplication'

당시 내 생각을 이슈에 두서 없이 정리한 글이다.

연차가 몇 년인데 아직도 이런 걸로 시간이나 빼앗기고 있는 모습을 보니 너무 억울하고 한심했다.

Legacy 분류에서는 이런 두서 없이 쓴 글을 복기하며 다시는 이런 일이 없도록 스스로를 타박해보려고 한다.

 

결론만 보셔야하는 개발자들을 시간을 위한 TL;DR

• cannot resolve symbol 'springbootapplication' 오류 발생
• 원인은 .idea 폴더에 남아있던 잘못된 설정 정보
• 해결 방법: .idea 폴더 삭제 후, IntelliJ에서 프로젝트 재오픈 → Gradle 설정 자동 재설정
• 교훈: 로그를 믿자. 컴퓨터는 잘못 없다.

 

생각하면서 일하기

소프트웨어 엔지니어에게 생각하면서 일하는 것은 선택이 아니라 생존 전략이다.
“혹시 이거 아닐까?”라는 가설을 세우고, 마치 BFS 탐색처럼 여러 가능성을 하나하나 확인해 나가는 것도 중요하다.
하지만 우리가 가진 가장 강력한 도구는 로그(log)다.

요즘 일하면서 정답은 언제나 로그에 있다고 느낀다.

A* 알고리즘처럼 가장 유력한 경로를 우선 탐색하는 것이 에러 해결의 핵심이다.

이번 포스팅은 내가 겪은 한 가지 오류와, 그것을 해결하기까지의 사고 흐름을 정리한 기록이다.
문제는 단순해 보였지만, 나를 한 시간 넘게 붙잡아 두었던 고약한 녀석이었다.

 

문제 발단

팀의 사내 API와 의존성을 정리하면서, 메인 브랜치에 변경사항을 머지한 뒤 로컬 테스트를 진행했다.
그런데 실행하자마자 다음과 같은 에러 메시지가 튀어나왔다.

package javax.validation.constraints does not exist

 

처음엔 아주 단순한 생각이 스쳐갔다.
“아, 뭔가 의존성이 빠졌구나.”

그래서 다음처럼 validation starter를 추가했다.

implementation 'org.springframework.boot:spring-boot-starter-validation'

 

그리고 ./gradlew clean build — 빌드 성공.
에러는 사라졌다. 해결됐다.

라고 생각했다.

 

더 큰 문제 발생

다시 프로젝트를 IntelliJ에서 열어보니, 익숙한 빨간 물결이 눈에 들어왔다.
그리고 다음과 같은 메시지:

cannot resolve symbol 'springbootapplication'

 

심지어 @SpringBootApplication 뿐 아니라 @RestController, @RequestMapping 등

온갖 Spring 관련 어노테이션에 빨간 줄이 그어져 있었다.

이쯤 되면 머릿속은 혼돈 상태에 빠진다.

• IntelliJ 인식 문제인가?
• Gradle 캐시 깨졌나?
• JDK 문제일 수도?
• 아예 Gradle DSL이 꼬였나?

하지만 생각을 다잡고, 가장 처음 IntelliJ에서 띄울 때 나왔던 힌트를 다시 떠올렸다.

 

A* 알고리즘처럼 힌트를 중심으로 추적하기

우리는 종종 로그를 무시하고, 자신이 가진 경험이나 감으로 문제를 해결하려 든다.
하지만 컴퓨터는 감정을 갖고 있지 않다.
잘못된 지시는 정확하게 잘못된 결과로 되돌려줄 뿐이다.

이상하게도, 프로젝트 이름이 이전 프로젝트의 이름으로 되어 있었다.
그 상태에서 IntelliJ는 Gradle이 아닌 자체 캐시된 설정(.idea 폴더) 을 그대로 사용하고 있었던 것이다.
사실 처음부터 IntelliJ는 다음과 같은 경고를 띄우고 있었다.

Some modules cannot be resolved.

 

하지만 무시하고 지나쳤다.

 

해결: 컴퓨터는 잘못이 없다

결국 .idea 폴더를 통째로 삭제하고, 프로젝트 루트 디렉토리를 IntelliJ에서 다시 열었다.
그러자 Gradle 설정을 새로 import하겠냐는 메시지가 떴고, 그대로 진행하니 모든 문제가 깨끗하게 해결되었다.

IntelliJ에서 Gradle sync → 프로젝트 설정 자동 복구 → 빨간 줄 사라짐

 

결론적으로 문제는 코드나 라이브러리가 아니라 IDE의 메타 정보(.idea) 였다.
Gradle 캐시를 날릴 필요도, JDK 설정을 바꿀 필요도 없었다.
컴퓨터는 언제나 말귀를 잘 알아듣는다. 다만, 내가 엉뚱한 말을 하고 있었을 뿐이다.

 

마무리하며

에러 메시지 하나로 시작된 문제는, 생각보다 더 깊은 원인을 가지고 있었다.
겉으로 보이는 cannot resolve symbol 메시지는 단지 표면적인 증상이었다.

진짜 문제는 내가 설정을 제대로 전달하지 못했다는 점이다.

이번 경험을 통해 다시 한 번 느꼈다.

 

생각하면서 일해야 된다. 그래야 시간을 아낀다.

(이어폰끼고) 딸깍. 안 되네. 다음 혐의점. 딸깍. 안 되네.

이러면 안 된다.