Go-swagger的Golang和AngularJS项目结构

I'm relatively new to Golang, having used Node.JS with AngularJS on a previous project, and am having trouble with Golang being very opinionated about project structure. Our Go code exists in a repository that also contains our HTML, CSS, and JS code, so that our "web UI" is a single checkout. The Go server serves up static pages to let AngularJS do the heavy lifting client-side, and provides a fairly complex RESTful API for interacting with a piece of embedded hardware. We use local includes in the Go server code to workaround the fact that the code isn't actually in GOPATH. The folder structure is roughly (subfolders not shown):

/ <-- repo root, checked out wherever you want (not in GOPATH) fonts/ scripts/ <-- all the AngularJS code server/ <-- all the Go code styles/ views/ <-- all the HTML code

I'm now working with the go-swagger library to generate a Swagger spec from comments in our Go server code, since the Swagger UI provides a convenient UI for interacting with our server API. However, I've found that a significant portion of the go-swagger parser can't be used if your code is not within GOPATH. I can get go-swagger to work if I copy the server folder into the GOPATH src directory and run it there, but I obviously don't want to do that every time I update the API or add new routes.

I imagine that I will have to make some changes either to our folder structure or our build process, but I'd like to understand the most logical way forward. Ideally, we would add a new task to our Gruntfile to generate the swagger spec by calling into go-swagger, and that spec would be copied into the default location for Swagger UI so that we can serve up the correct API spec with each build. I understand how the task should operate, but it doesn't work with our current project structure. So:

• Should we break the Go server code into its own repo that we check out in GOPATH? We have other tools (like ffjson) that are also unhappy with our Go code existing outside of GOPATH, so perhaps this is worth the effort to update our build process to handle.
• Is there a way to modify GOPATH (or add to it like PATH) such that go-swagger (and ffjson) can work in our existing repo structure? This seems like the easiest path, if it's possible. I've tried checking out our "UI" repo in GOPATH, but that didn't work initially (perhaps it would work if I updated our imports to use the arbitrary paths from the repo root to the server folders).
• Something else entirely? As I said, I'm pretty new to Go, and this project already existed for a few years when I came on board, so I'm not familiar with the ins and outs of Go just yet.