ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 상상도 못한 오류에 대처하는 자세
    Today I Learned 2022. 8. 27. 23:55

     

    목요일에 올라온 추가 퀘스트 과제인 프로젝트 배포를 무려!!! 저녁에!!! 진행하고 있다. (걱정 마십쇼... 일요일이 가기 전까지 다른 것들 포함해서 다 해내고 말 것입니다.. 저는 잠을 모르는 싸나이기 때문에!)

     

     

    동료분이 올려주신 아주 깔끔한 강의 정리본이 있어서 정리본과 강의를 교차해서 봐가면서 배포 과정을 진행하고 있었다. 배포를 진행하던 도중 강의에는 나오지 않는 오류들이 여럿 나타났다.

     

    그 시작은 다음의 두 종류의 오류였다.

     

     

     

    첫 번째로는 사용하는 buildpack을 탐지할 수 있도록 무언가 세팅을 해줘야 하는 것 같았다. 안내 페이지에 들어가서 확인해보니 

    이런 식으로 세팅을 해주라는 것 같아 php만 우리가 사용하는 언어인 java로 바꿔서 설정을 적용했다.

     

    두 번째로 뜬 오류는 만약 특정 branch로 분기해있는 상태에서 push할 경우 <브랜치명>:main으로 push하라고 하는 것 같아 브랜치명을 붙여 push를 시도했다.

     

     

     

    또 본 적이 없는 오류가 나왔다. pom.xml이라는 파일을 찾을 수 없다는 오류인 것 같은데, 생전 들어본 적이 없는 파일 이름이라 일단 구글에 검색을 시도했다. 검색 결과로 나온 여러 게시물들을 교차해서 봤을 때 알 수 있었던 대략적인 내용은 pom.xml 파일은 Java 프로젝트 관리 도구의 하나인 Maven에서 사용되는 상수 값, 빌드 정보, 의존성 등 여러 정보들에 대한 내용을 담는 파일이라는 것이었다.

     

    30분 정도를 문제에 대해 검색하고 Heroku에서 안내하는 문제 해결과 관련된 안내 페이지를 살펴봐도 어떤 것을 수정해야 하는지 도저히 감도 오지 않아 돗자리에 같이 있던 동료들에게 도움을 요청했다.

     

     

    동료들 역시 pom.xml이 없다는 둥의 문제는 처음 본다며 당황한 기색이 역력했지만, 곧 다방면으로 문제 해결 방법을 다같이 모색하기 시작했다. 여러 조언들을 듣고 그 중 일부를 적용했다. 먼저 web-01-spring git 저장소의 브랜치의 하나인 해당 프로젝트 파일을 통째로 복사했다. web-01-spring 디렉터리 밖에 새 디렉터리를 만들고 거기에서 새로 git 저장소를 만든 뒤 복사된 프로젝트를 가져와 다시 Heroku remote에 push를 시도했다. 아쉽게도 똑같이 pom.xml 파일이 없다는 문제를 출력했다.

     

    다음으로는 Heroku 쪽에서 기존에 생성한 app 대신 새 app을 다시 생성하고, 새 git 저장소의 remote를 새로 생성한 app으로 변경해 push를 시도했다. 이번에는 push가 잘 수행되는 것을 확인할 수 있어 배포 과정을 일단 이어나갈 수 있게 되었다.

     

     

    글을 이어 쓰는 동안 발견한 차이점이 있다. 새로 생성한 app 쪽에서는 프로젝트가 gradle이라는 것을 인식하고 있다는 점이다!

     

    두 app의 차이가 보이고 있다.

     

    첫 번째로 만든 app에서는 프로젝트 관리 도구를 인식하지 못하고 있고, Buildpacks가 heroku/java로 지정되어 있다. 내가 설정해 준 것인데...

     

    두 번째 app은 Buildpacks가 heroku/gradle로 설정되어 있었다. 두 번째 app은 별도로 Buildpacks를 직접 설정해주지는 않았었다.

     

    지금 상황은 이렇다. 첫 번째 app에서 문제가 발생한 원인은 정확히 모르겠는데, Gradle을 사용하는 프로젝트에서 문제를 발생시키지 않으려면 두 번째 app처럼 설정을 해 줘야 한다는 점이다.

     

     

     

    이처럼 상상도 못했던 문제를 해결하기 위해 오늘은 다음과 같은 과정을 거쳤다.

    • 이전처럼 혼자 문제를 오랜 시간 붙잡고 있지 않았다. 동료들에게 문제의 공유를 시도했고 동료들 또한 문제를 완전히 해결해주지는 못했지만 문제 해결을 위해 다양한 접근법을 제시해 주었고 그 방법들 중 문제를 해결할 수 있는 방법이 있었다.
    • 정확한 문제의 원인을 알기 위해 개발질문에 질문을 시도했다.

     

    메가테라 웹 개발자 과정이 결코 혼자 하는 과정이 아니라는 것을 다시금 느꼈던 토요일 밤의 문제를 마주하고 해결하는 과정이었다.

     

    내가 모르는 부분들은 어쩌면 동료들은 알고 있을 수도 있고, 내가 생각하지 못한 접근법을 동료들과 상의하면서 도출해낼 수도 있다. 정확한 원인을 알기 위해 무엇을 캐치해야 하는지 트레이너 분들이 생각의 유도를 도와줄 수 있다.

     

     

    항상 벽에 부딪히는 과정의 연속이지만, 벽에 부딪히는 과정을 동료들과 함께하기에 몸은 아파도 마음은 외롭지 않다.

     

     

     

    댓글

Designed by Tistory.